[yt-dev] halo finding overhaul

Stephen Skory s at skory.us
Thu Nov 8 16:38:58 PST 2012


Hi everyone,

Matt, Chris Moody, and myself have started a bit of a conversation
off-list about overhauling the halo finding machinery that we would
like to bring here. This has been sparked by some recent work on the
Rockstar integration into yt. Matt will surely be able to summarize
these issues better, but here's how I understand things:

- As Matt wrote the halo finding stuff years ago, it isn't very
scalable to high levels of parallelism. In particular, halo object
information isn't as shared across parallel processes as they should
be. For some of the halo finders, data is localized to the processor
that "owns" the halo. When running in parallel, the local values need
to be broadcast to all the other processors when accessed. This is why
you get the halo mass with a function "halo.total_mass()" instead of a
simple class value "halo.total_mass". The "total_mass()" function (and
other halo object functions) is wrapped with a decorator that
broadcasts the value transparently.

I think it should be fairly straightforward to ensure that all halos
objects on all tasks know all the key bits of info, but it's not clear
to me how particle access would work.

- Matt has also raised the idea of creating "callbacks" for halo
finders. I don't understand this quite as well, but I think it means
that it would be possible to write functions that would operate on the
particles as the halo finder runs (or is finished finding halos but
before it returns) to ensure good parallelism and speed. He has also
mentioned that it would be possible for these callbacks to pull grid
information from Python if that was needed for the analysis.

What I don't quite understand here is where these callbacks would
actually operate? In c for HOP, in cython for Rockstar, and Python for
parallel HOP? Or would they happen between what the halo finder
returns and building the halo lists?

I probably have more things to say and ask, but I think I'll let Matt come in.

-- 
Stephen Skory
s at skory.us
http://stephenskory.com/
510.621.3687 (google voice)



More information about the yt-dev mailing list