[Yt-dev] 1024^3 HOP problems

Matthew Turk matthewturk at gmail.com
Thu May 7 15:39:53 PDT 2009


Additionally, to track when it is not using preloaded fields (and you
might want to preload creation_time if necessary) you can add a line
inside the function yt/lagos/DataReadingFuncs.py:readDataPacked that
prints out the grid id, the field, and says it's hitting the C code.
In a standard run of:

yt hop my_data_file --parallel

that function should never get called.  If it is, we have not fixed it.

-Matt

On Thu, May 7, 2009 at 3:35 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Stephen,
>
> Remove all definitions of g_objs and replace g_objs in the call to
> _preload with self._data_source._grids .
>
> This is the fix to your patch; in r1300 I have made other necessary changes.
>
> -Matt
>
> On Thu, May 7, 2009 at 12:55 PM, Stephen Skory <stephenskory at yahoo.com> wrote:
>>
>> Matt,
>>
>>> I'm hammering down on the memory usage now.  There seems to be a bug
>>> somewhere in preloading that I am attempting to locate.  We may be
>>> carrying around extra arrays with the new patch you sent.
>>
>> I've been suspicious of that because the preloading runs aren't any faster than the vanilla ones, but shouldn't they be substantially faster? Especially on Lustre where the major hangup is with opens?
>>
>> Thanks for this, by the way.
>>
>>  _______________________________________________________
>> sskory at physics.ucsd.edu           o__  Stephen Skory
>> http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student
>> ________________________________(_)_\(_)_______________
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>



More information about the yt-dev mailing list