Open jzuhone opened 5 years ago
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')
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.
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
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.
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.