[Yt-dev] Forked depo

gso at physics.ucsd.edu gso at physics.ucsd.edu
Wed May 11 15:42:39 PDT 2011


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





More information about the yt-dev mailing list