Hi Stephen, I just chatted with Britton on the phone about this, and we came to a couple conclusions. * Right now, the halo profiler is about 10% away from running in parallel on *each* halo. i.e., each operation on the halos can be parallelized with a few more lines of work. * This method of parallelization is a bad way to go. * Volume decomposition is also not likely to be terribly useful, with the current means of IO. At some point in the future this could and will change, but for now a round-robin approach is the way to go. * To round robin this, two things need to happen -- * When projecting, we need to be able to set a flag to disable parallelization, ala '_processing'. I'll handle this, but it should be 1-2 lines of code. * The ParallelAnalysisInterface needs to be generalized to provide iterators over any object, not just _grids. Only a couple lines of code, but annoying. At that point, HaloProfiler can subclass ParallelAnalysisInterface and use that as the iterator over halos. The IO needs to be looked at briefly, but it should be mostly okay as is. I think this can be done in a couple hours. However, what I think the real problem is is that we need to ensure that the serial halo profiler doesn't break. To that end, I think we need to plan to apply Britton's sample parameter files to the RD0005-mine dataset, and run that in both serial and in parallel as our testing mechanism. My inclination is that we start working on this in isolation; I'll commit some changes I mention above tomorrow to the bitbucket yt repo, which I am also mirroring on hg.enzotools.org. -Matt On Fri, Mar 13, 2009 at 2:05 PM, Stephen Skory <stephenskory@yahoo.com> wrote:
Hi guys,
I brought this up a while ago and I'm not sure where we left it. I thought I needed it earlier, but it turns out I didn't, so I forgot about it. However, now I definitely have need to get virial masses for L7 haloes. A parallel halo profiler would make this a much more reasonable task.
I think I can probably figure out a way to do it myself (which would be a good thing for me to do) but I don't want to step on any toes or do it in a bad or inextensible way. Keeping that in mind, do any of you have some suggestions?
I think the best way is to parallelize similarly to HOP using sub-volumes to keep memory usage low for each processor. Then each process would only run on haloes in its sub-volume. This would make things nicer if parallel HOP is run before the profiler, data wouldn't have to be read multiple times.
Thanks!
_______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org