[yt-dev] Why are particle masses returned in code units?

Sat Apr 5 18:40:11 PDT 2014

On Sat, Apr 5, 2014 at 6:29 PM, Matthew Turk <matthewturk at gmail.com> wrote:

>
> On Apr 5, 2014 9:10 PM, "Nathan Goldbaum" <nathan12343 at gmail.com> wrote:
> >
> > My fix ended up not working.  Matt, you're totally right about the
> aliases.  I'm not sure how to resolve this without changing the 'standard'
> particle field names, since we currently use enzo field names.
> >
> > I've filed an issue to track this here:
> https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-differently-than
> >
>
> What if we namespaced particles as "frontendname_particles" instead of
> "io" (or "frontendname_particletype") and then aliased them to "particles"
> or "particletype"?
>

+1. A natural extension of the fluid field system.

This will also make it easier to define 'standard' particle types like
'dark_matter', 'tracer', or 'stars', while preserving access to the native
on-disk fields for each particle type, which might have arbitrary names
like 'DM' or 'STAR'.  We'll eventually need something like that to have a
uniform field naming system for analyzing star formation rates or halo
properties in a code-agnostic fashion.

> >
> > On Sat, Apr 5, 2014 at 5:43 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> >>
> >>
> >> On Apr 5, 2014 8:35 PM, "Nathan Goldbaum" <nathan12343 at gmail.com>
> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> >> >>
> >> >>
> >> >> On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343 at gmail.com>
> wrote:
> >> >> >
> >> >> > Hi all,
> >> >> >
> >> >> > Does anyone know why particle fields are turned in code units?
>  For example:
> >> >> >
> >> >> > >>> import yt
> >> >> > >>> ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
> >> >> > >>> ad = ds.all_data()
> >> >> > >>> print ad['all', 'particle_mass']
> >> >> > [  5.24322377e-06   5.24322377e-06   5.24423058e-06 ...,
> 2.51688903e-06
> >> >> >    2.52040900e-06   2.52345330e-06] code_mass
> >> >> > >>> print ad['all', 'particle_position_x']
> >> >> > [ 0.50070677  0.50118382  0.50118984 ...,  0.49867166  0.49857796
> >> >> >   0.49865383] code_length
> >> >>
> >> >> I think positions should be in code units, as John mentioned. Masses
> and other things being in code units is a mistake; file an issue? I think
> it's quite recent.
> >> >
> >> >
> >> > Oh ok.  I think I have a fix actually, PR incoming.
> >>
> >> I suspect it is because we don't add field aliases for particles. So
> this is by design, and if we add aliases it will probably work fine. But
> the "io" designation doesn't lend itself well to having an alias, which
> "frontend" to "gas" does.
> >>
> >> >>
> >> >> >
> >> >> > For fluid fields, we have aliases for on-disk fields that get
> returned in code units, but the 'standard' yt fields are all in CGS by
> default:
> >> >> >
> >> >> > >>> print ad['gas', 'density']
> >> >> > [  4.92775113e-31   4.94005233e-31   4.93824694e-31 ...,
> 1.12879234e-25
> >> >> >    1.59561490e-25   1.09824903e-24] g/cm**3
> >> >> >
> >> >> > >>> print ad['enzo', 'Density']
> >> >> > [  1.78469285e-01   1.78914800e-01   1.78849414e-01 ...,
> 4.08816836e+04
> >> >> >    5.77886836e+04   3.97754906e+05] code_mass/code_length**3
> >> >> >
> >> >> > I guess we don't really have a distinction like that on the
> particle side of things.
> >> >> >
> >> >> > I tend to think that it should be easier to access particle fields
> in CGS units and that we should default to having 'standard' particle
> fields in CGS, just like the fluid fields.
> >> >> >
> >> >> > That said, looking at YTEP-0003, it seems we focused mostly on
> fluid fields and didn't think very hard about how particle fields should
> work.  For example, 'particle_mass' is never mentioned.
> >> >> >
> >> >> > I realize that completely refactoring the particle fields will be
> a fair bit of work so we may not be able to change things before yt 3.0 is
> released, but I think this should be part of the discussion as we develop a
> more consistent set of rules for how yt fields should work, including
> multifluid, multiparticle, and multispecies datasets.
> >> >> >
> >> >> > I'd love to hear other's thoughts on this.
> >> >> >
> >> >> > -Nathan
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >>
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140405/f2ac436b/attachment.htm>