(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?