Hi John,
On Sun, Feb 20, 2011 at 5:22 PM, John Wise
Hi all,
I was calculating some quantities for a halo list with 32 processors, and it broke when it tried to calculate derived quantities for small halos with less than 32 grids within its sphere. I fixed it for enzo datasets and posted the diff here.
http://paste.enzotools.org/show/1511/
First it broke in the preload function when the grid list is null, and it tried to get a field list from the first grid. That was easily fixed by returning data = None. Then I had to modify the mpi_catarray function to consider a null dataset (len(data) == 0).
The mpi_catarray function has caused some problems lately. We had to
change a few things around to get it to work with inline in a
particular way, but the specifics escape me now. I think that it was
this change that broke the ngrids I don't like how I modified the preload function because it only applies for
the enzo frontend. Is there another routine that can be modified that
affects all data formats, so this fix can be generalized? Nope! As of right now, Enzo's the only code that implements preload.
I suspect that any fix would have to be applied specific to each code,
but my gut feeling is that the only reason it came up in Enzo is
because of carelessness on my part; for some reason the IO Handler
instance doesn't know about its parent parameter file or hierarchy. I
think that a longer-term fix would be to avoid this ignorance, and
simply give unto the IOHandler a reference to the parameter file. I
think that if we removed the grids[0] call, otherwise preload() should
succeed. Your fix is great, thought.
I'd say push these changes, they look good. Thanks for the catch on these bugs!
-Matt Thanks,
John
_______________________________________________
Yt-dev mailing list
Yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org