<div dir="ltr">Thanks very much for your help. I only used ~64GB of memory for 1024^3 particles on a 512^3 mesh (using covering_grid). This essentially cut memory usage in half by my guess.<div><br><div><br></div><div><img src="cid:ii_1468bc3c125b2698" alt="Inline image 1" width="410" height="323.28057553956836"></div>
</div><div>(I know this could be made to look better!, vmin,vmax etc.)</div><div><br></div><div>BG<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 10: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">Hi Brendan,<br>
<br>
(Snipped most of the rest of the message.)<br>
<br>
Alright, I've issued a pull request that wraps in a few changes that<br>
for me dropped memory usage considerably.<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/pull-request/945/reduce-memory-usage-for-particle-octrees" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-request/945/reduce-memory-usage-for-particle-octrees</a><br>

<br>
There are other things that need to be done; the most prominent is<br>
that we absolutely need to figure out how to substride on octrees.<br>
Basically, what we're constrained by is that the way the derived<br>
fields work, the size of the data chunk being operated on in spatial<br>
mode (i.e., Nzones) is the fundamental size by which we allocate<br>
memory during the processing of a field.  So if we need five fields to<br>
generate the sixth one, we have to have those Nfields resident in<br>
memory during the generation.  As it stands, the octree system is not<br>
flexible enough to do substrides on these, which means we have  pages<br>
of that size getting allocated, which is where the big increase in<br>
memory during the computation of "index","cell_volume" takes place.<br>
<br>
Fixing this overlaps with moving to forest-of-octrees, so I am going<br>
to try to up the priority of that.<br>
<br>
-Matt<br>
<div class="im HOEnZb"><br>
On Tue, Jun 10, 2014 at 3:00 PM, Brendan Griffen<br>
<<a href="mailto:brendan.f.griffen@gmail.com">brendan.f.griffen@gmail.com</a>> wrote:<br>
> Thanks very much Matt! I've improved things at my end as well with my script<br>
> (non-yt related). Hopefully the confluence of the two changes will enabled a<br>
> successful run.<br>
><br>
> Thanks.<br>
><br>
> Brendan<br>
><br>
><br>
> On Tue, Jun 10, 2014 at 3:57 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> Hi Brendan,<br>
>><br>
>> I think I've found the problem -- volume is making too many copies.<br>
>> I'm working on a fix.<br>
>><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br></div>