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.
On Thu, May 7, 2009 at 3:35 PM, Matthew Turk firstname.lastname@example.org wrote:
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.
On Thu, May 7, 2009 at 12:55 PM, Stephen Skory email@example.com wrote:
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.
_______________________________________________________ firstname.lastname@example.org o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_(_)_______________ _______________________________________________ Yt-dev mailing list Ytemail@example.com http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org