[Yt-dev] Forked depo

[Stephen Skory]

Geoffrey,

> (I'll just talk here until people tell me to take it off list)

Nah, yt development belongs on yt-dev!

> How do you think I should integrate this?  Should the ellipsoid profiling
> be done alongside the saving of the halo object as an optional thing the
> user can turn on, or leave it as a separate thing?  If together, I'd say
> the information should be stored in the binary file instead of the ascii
> output (or else it'll be a **** TON of columns, it already has tons).  If
> separate, then when the user wants to construct the ellipsoid objects,
> they would have to read in the halo object's information, set center,
> r_max=A, and then from the output of the ellipsoid profiler read in B, C,
> e1, e2, and e3 can be calculated on the fly.

There are several issues of integration discussed here. I'll do them separately:

1. Ellipsoid data storage. I agree that the ellipsoid data probably
shouldn't be added to the HopAnalysis.out file by default. Most people
don't want it and it would add a bunch of new columns. However, I
think that if a user does want to save the ellipsoid data, it should
go in the HopAnalysis.out file as added columns for each halo. And
adding as many columns as necessary is fine. I think we want to avoid
adding new input/output files for halos. We already have three, which
is plenty by my count. This will not be terribly difficult to
integrate.

2. Ellipsoid data retrieval. There are three ways that halo data is
pulled off disk in yt, presently.
a. In halo_objects.py, with LoadHaloes. This would not be terribly
difficult to modify to support ellipsoid data columns. No problem.
b. In the halo_profiler. This would also not be terribly difficult,
but it raises some issues I discuss below (4).
c. Halo merger tree. The ellipsoid data has no bearing on the merger
tree because the merger tree doesn't care about halo shape, only
particle membership.

3. Ellipsoid in halo analysis. There are several places in
halo_objects.py that assumes the halo is a sphere. It won't be
terribly difficult to add a switch that the user can specify that the
ellipsoid should be used for analysis or data retrieval. No problem.

4. Halo profiling. If you want to profile halos using the ellipsoid
container, you're going to have to think a bit about how you think it
should be done. Currently, the halo profiler works using concentric
spheres, binning quantities based on radius. Do you want to bin your
profiles based on radius? Or concentric ellipsoid shell? If it's the
latter, that's also new code that has to be written, I think.

> Which way do you think is the best way of integration, or any better ideas?

I'm willing to help you with 1,2a, and 3. What I need from you is your
most up to date code for defining an ellipsoid from the particles in a
halo, or you can point it to me in your fork of yt. halo_objects.py is
now a pretty big beast that I think I only understand fully, so I'll
do the integration there. But if your ellipsoid derivation code is
similar to what I saw a few weeks ago (but improved and vectorized, I
hope!) in function, these three tasks won't be hard for me to do.

Task 4 I think requires you to think about how you want to analyze the
halos. It sounds like you might only care about total quantities
inside the halo ellipsoid, and if so, you don't need to worry about
the halo profiler. But my bet is that someday someone's gonna ask for
a halo profile and then you'll have to decide how you want to do that.

In summary, tl;dr, here's how I think you should do things:

1. See about implementing Britton's idea of reducing the number of
parameters. You know more about this than anyone else. You can decide
if it's practical or not.
2. Once that's settled, give me what I need to do steps 1,2a, and 3, above.
3. At the same time we'll merge in your ellipsoid data container.

Any other issues like bug fixes and halo profiler improvements can
come later. How does this sound, Geoffrey? Any other comments from the
peanut gallery?

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