[Yt-dev] parallelism when ngrids < nprocs

Britton Smith brittonsmith at gmail.com
Sun Feb 20 15:15:21 PST 2011


The changes to the mpi_catarray were made to fix issues that came up from
doing slices in parallel where some processors contained no grids of
interest.  As long as that still works, there shouldn't be a problem.

Britton

On Sun, Feb 20, 2011 at 6:09 PM, John Wise <jwise at astro.princeton.edu>wrote:

> 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<ncpu issue that you bring up; I'm
>> sorry it caused you an issue!  Your fix looks fine to me.
>>
>
> Thanks for letting me know how this bug possibly arose.  I'll go ahead and
> push the change.
>
>
>  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.
>>
>
> Good to know.  I just didn't want to push a change that could've been
> extended to other formats :)
>
> Thanks again,
>
> John
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110220/1a0eb1f1/attachment.htm>


More information about the yt-dev mailing list