[yt-dev] Parallelism and iteration

Britton Smith brittonsmith at gmail.com
Thu Feb 23 07:27:35 PST 2012


It looks to me like parallel_objects is more flexible and handles comms
better than the ParallelObjectIterator.  I think switching to them would
make it simpler to customize the parallel strategy of any given operation.

I'm definitely in favor of removing the serial warning for
parallel_objects.  I have put it into the HaloProfiler as a means of
dividing up halos for processor groups and often run the HaloProfiler in
serial.  It works just fine in this mode, so I don't see the need to have
the warning.

On Thu, Feb 23, 2012 at 9:34 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all,
>
> As some of you may know, I'm working on the geometry subsystem.  Right
> now I'm in the process of constructing incremental reads ("chunking")
> off disk, with intermediate reduction operations.  In the past, this
> was usually handled by individual tasks, such as profiles, in a pretty
> gross and manual way.  In fixing this up, I noticed we have three
> different parallel iteration methods.
>
> This question is probably best directed at Sam or Britton, but others
> might also have an opinion.  Is there any reason why, from within a
> subclass of ParallelAnalysisInterface, I wouldn't just use
> parallel_objects instead of the GridObjectIterator or GridIterator?
>
> As a related question, can I get rid of the warning for when running
> parallel_objects on a single processor?
>
> (The geometry handling is coming along nicely, I think.  Right now
> reading from objects works well (and is faster) and the abstraction of
> grids as opposed to octs or particles has worked well.  It's a ways
> from being feature complete, but if you want to play with it it's all
> in bb://MatthewTurk/yt-refactor .)
>
> -Matt
> _______________________________________________
> 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/20120223/ac2b4617/attachment.html>


More information about the yt-dev mailing list