<div dir="ltr">Hi Matt,<div><br></div><div>Thanks for the informative reply.  I'm definitely up for looking into this this week.</div><div><br></div><div>Britton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, May 13, 2014 at 7:56 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Mon, May 12, 2014 at 2:26 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Hi Matt,<br>
><br>
> Sure, I'm doing the following with the rockstar_halos data on<br>
> <a href="http://yt-project.org/data" target="_blank">yt-project.org/data</a>:<br>
><br>
> pf = load("rockstar_halos/halos_0.0.bin")<br>
> dd = pf.all_data()<br>
> print dd["particle_mass"].size<br>
> for chunk in dd.chunks([], "io"):<br>
>     print chunk["particle_mass"].size<br>
><br>
> This dataset has two files, but running this, I only get one chunk with the<br>
> same size as the all_data container.<br>
<br>
</div>I've looked into it, and this is my fault for how the particle<br>
datasets are currently set up.  I knew this a little bit ago, but it's<br>
been long enough since I last looked at it that I've forgotten.  Right<br>
now, this is the *biggest* problem with particle datasets.  There is<br>
no support for sub-selecting data components as is.  There are two<br>
things:<br>
<br>
1) If you select a small region, it will not read all the data files<br>
-- it knows the ones to read.<br>
2) There's only one chunk, regardless of what you select.<br>
<br>
This is because right now, everything lives inside the single global<br>
octree.  This is something I worked on last fall, but didn't finish.<br>
Essentially, what needs to happen is to convert the single global<br>
octree to a forest of octrees, similar to how RAMSES, ART, ARTIO are<br>
set up in yt.  The reason it's somewhat harder for particle datasets<br>
is that many of the operations we do on particle datasets<br>
(specifically on SPH) require neighboring particles, so the selection<br>
needs to be somewhat fuzzier to ensure boundary particles are<br>
included.<br>
<br>
This is something that's essentially ready to go, but when we started<br>
pushing for 3.0, I put it off on my todo list until 3.1.  It's going<br>
to be a major blocker not too long from now -- we're already hitting<br>
that point -- so the sooner we get to 3.0 the sooner we can do this.<br>
In NYC this week I can talk with you in person and maybe we can figure<br>
out a game plan for trying to implement this, if you want to have a<br>
go.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Britton<br>
><br>
><br>
> On Mon, May 12, 2014 at 2:19 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> Hi Britton,<br>
>><br>
>> On Mon, May 12, 2014 at 2:16 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>> wrote:<br>
>> > Hey all,<br>
>> ><br>
>> > I'm working on changing how HaloCatalog objects loop over halos from a<br>
>> > model<br>
>> > where every processor has to hold the entire halo list to a model in<br>
>> > which<br>
>> > we loop over "io" chunks.  This will make the HaloCatalog scale much<br>
>> > better<br>
>> > to extremely large catalogs.  My understanding was that an "io" chunk<br>
>> > was<br>
>> > essentially one file on disk.  However, when I try to get io chunks from<br>
>> > any<br>
>> > one of the various halo catalog frontends, there seems to only ever be a<br>
>> > single chunk that contains everything, regardless of how many files on<br>
>> > disk<br>
>> > the data is spread over.  Is there a way to change this so that an io<br>
>> > chunk<br>
>> > represents the data from a single file?<br>
>><br>
>> That sounds like a bug; IO should be single file at a time.  Can you<br>
>> show me how you're checking?<br>
>><br>
>> -Matt<br>
>><br>
>> ><br>
>> > Britton<br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> ><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>