Hi Stephen, (I'll just talk here until people tell me to take it off list) The main reason why I developed the ellipsoid object is to analyze Halo statistics. I want to know how much baryon, dark matter, star particles are in each halo, without using the sphere object, because it often encloses too much extra volume. The sphere would be a good first order approximation, but I want to go to a more accurate, more representative object ... an ellipsoid. The ellipsoids are of course not perfect, one of the big draw back is the way I construct it (not doing any N^2 operations), it also encloses some open space beyond where the particles are found (especially in the longest axis), but I think it's usually quite a bit smaller than a sphere. I'll have to run it on a big halo dataset to back the previous statement and make it convincing of course. Ultimately I want to make the scatter plot of SFR vs the ratio of baryon_gas/DM. From preliminary results Pascal shown there's a clear correlation about how much gas there is to the amount of DM, to how much stars are forming. However, his halo region are made of rectangular boxes in IDL, not even spheres. So I want to do the same analysis in YT with the ellipsoids. My ellipsoid profiling is done in python script form, as posted on the YT dev in a pastebin, and I probably need help to make it into a native TY function like your halo profiler. Currently: - It reads your halo profiler output object - It gets the center and x,y,z of the particles - It figures out the A, B, C, e1, 2, 3 based on those information - Then it prints all that into another file, in the same order of Haloes as your profiler output has them listed, which is sorted by mass. Then I would feed the ellipsoid info into the ellipsoid 3D object that you've helped me look over. 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. Currently the user has to input center, A,B,C, e1,e2,e3 all separately, which is a lot of data. So I see cutting out center, A, e3 as a nice reduction. But maybe Britton's idea of using a rotation angle (single piece of info) in place of e2 (xyz 3 pieces of info) may be viable as well, as long as we know where to start counting and take degenerate case into account. Which way do you think is the best way of integration, or any better ideas? From G.S.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
I think I want to make the changes soon, but I'm not sure if we should discuss some details off list on how to best integrate this stuff into YT. I was envisioning that the ellipsoid profiling, constructing the ellipsoid object can be integrated with your Halo profiling some how.
I'll be available again later in the afternoon after group meeting
From G.S.
Hi all,
(quoting GSO)
So I think it is best to have e1 and e2. Â Having e3 calculated on the fly will save 3 columns off of the data file, and if we don't store the center and A that's another 4 columns. Â And if we go with the rotation angle idea it will save another 2 out of 3 columns, replacing 3 e2 components with 1 angle.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
(Quoting GSO)
Ultimately I'd want to analyze the DM and star particles in the ellipsoid separately, do I just use the derived field and particle ages to do that once the previous problem is solved?
(Quoting Matt's response)
I'll defer to someone else on this. Â The way stars are differentiated in Enzo -- although other codes seem to have gotten this right -- bugs me in its inconsistencies. Â (i.e., ages versus ParticleType. Â Not a fault of enzo, really, just inconsistent conventions for running simulations. Â :)
I agree with Matt on this confusion bit. But to answer your question, Geoffrey, yeah, you'll just do something like:
ct = Ell['creation_time'] select_stars = (ct > 0) star_masses = Ell['ParticleMassMsun'][select_stars]
or similarly with 'particle_type' in the first line.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org