[Yt-dev] Forked depo

[gso at physics.ucsd.edu]

Thanks Stephen, all of that sounds great.

I've actually never thought of plotting the profile, I guess when I wrote
earlier I meant profiling as getting the attributes, not in the radial
profile sense.  I don't see myself needed that capability immediately, but
it is possible that I may need it in the future.

If I'm going to plot a ellipsoid profile I see the intuitive thing to do
is not concentric circles but concentric ellipsoids.  Which means I'll
plot (some quantity) vs. Normalized R, where Normalized R is just 0 to 1
on the 3 principal axes.

Should I just put it off until later or do you think it'll be a lot easier
to implement it now while we're doing 1,2,3 anyway?  How much "new code"
is involved?  If it is a lot, and since I'm lazy, I'd vote for putting it
off for later :-)

From
G.S.

> 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)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>