Why are particle masses returned in code units?
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
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
FWIW, I recall discussions about leaving particle positions in code units in line with leaving cell centers and cell widths in code units. Otherwise, I agree. John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com
On Apr 5, 2014, at 7:39 PM, Nathan Goldbaum <nathan12343@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
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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.
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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.
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@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
On Apr 5, 2014 8:35 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk@gmail.com>
wrote:
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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@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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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-dif... On Sat, Apr 5, 2014 at 5:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Apr 5, 2014 8:35 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk@gmail.com>
wrote:
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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@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
_______________________________________________ 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
On Apr 5, 2014 9:10 PM, "Nathan Goldbaum" <nathan12343@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-dif...
What if we namespaced particles as "frontendname_particles" instead of "io" (or "frontendname_particletype") and then aliased them to "particles" or "particletype"?
On Sat, Apr 5, 2014 at 5:43 PM, Matthew Turk <matthewturk@gmail.com>
On Apr 5, 2014 8:35 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk@gmail.com>
wrote:
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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
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
wrote: 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. 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@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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Sat, Apr 5, 2014 at 6:29 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Apr 5, 2014 9:10 PM, "Nathan Goldbaum" <nathan12343@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-dif...
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@gmail.com>
On Apr 5, 2014 8:35 PM, "Nathan Goldbaum" <nathan12343@gmail.com>
wrote:
On Sat, Apr 5, 2014 at 5:33 PM, Matthew Turk <matthewturk@gmail.com>
wrote:
On Apr 5, 2014 7:39 PM, "Nathan Goldbaum" <nathan12343@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
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
wrote: 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. 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@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
_______________________________________________ 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
_______________________________________________ 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
participants (3)
-
John ZuHone -
Matthew Turk -
Nathan Goldbaum