Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the value of solar metallicity user-configurable? #88

Open
jzuhone opened this issue Jun 3, 2019 · 4 comments
Open

Make the value of solar metallicity user-configurable? #88

jzuhone opened this issue Jun 3, 2019 · 4 comments

Comments

@jzuhone
Copy link
Contributor

jzuhone commented Jun 3, 2019

There are several different values for the solar metallicity still in common use in the astrophysical literature (yes, it's silly but true).

We should find a way to allow the user to set their own value for the solar metallicity constant.

This originally came up on yt Slack.

@ngoldbaum
Copy link
Member

I don't think it's a good idea to make this configurable. For example, trident (or any other software built on yt) would need to account for this.

What about documenting that one can do something like this:

import unyt

unyt.define_unit("my_zsun", 0.012, tex_repr=r"Z_{\odot}")

# some function that returns data in dimensionless units understood to be a metallicity value
data = generate_data()

data.to('my_zsun')

@jzuhone
Copy link
Contributor Author

jzuhone commented Jun 3, 2019

It was pointed out on yt Slack that the value currently in unyt is now inconsistent with the one in Cloudy.

Different research groups use different values, and a new paper comes out every couple years or so with a non-trivial different measurement. So it seems to me we ought to have some way of handling this that’s at least quasi-official for ease and for portability across scripts.

@jzuhone
Copy link
Contributor Author

jzuhone commented Jun 3, 2019

See, e.g. here for an (incomplete) list of abundance tables that result in different values.

https://heasarc.gsfc.nasa.gov/xanadu/xspec/manual/node117.html

@ngoldbaum
Copy link
Member

I understand that there are different conventions in use. What I'm saying is that people should be careful about what they mean by "Zsun" and that it might be surprising if that meaning is user-configurable.

It would be better if people converted to unambiguous units at interfaces so when I load data from a simulation code that uses a different definition for the solar metallicity yt can then go ahead using its definition with no issues. This is possible if someone defines their own metallicity unit and not possible if they say at the top of their script that yt's solar metallicity unit really means something different for this one particular script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants