Bringing in shared constants

[xylar]

@hyungyukang raised the issue:
#170 (comment)

should we start thinking about creating a shared constants file ?

I feel strongly that these need to come from:
https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/share/util/shr_const_mod.F90
or that we need to come up with a way to check that our constants have not deviated from these if they are separate.

I asked how Scream handling this, and @mwarusz said:

Not sure that they do:

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/components/eamxx/src/physics/share/physics_constants.hpp#L46

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/share/util/shr_const_mod.F90#L16

[xylar]

I'm sure not big on Omega and Scream keeping track of our own sets of constants. MPAS-Ocean's constants are different from the shared values in several annoying ways. Let's try very hard to avoid this!

[mwarusz]

I was wrong, the pi value in Scream and shr_const_mod matches. It is just that shr_const_mod specifies more digits that can be represented. After looking more at these two files, I haven't found a constant that doesn't match. We still need to decide if we want to have our own file with the same values, or somehow get constants from one of these two files.

[xylar]

I think a separate location is problematic. I have that myself in MPAS-Tools:
https://github.com/MPAS-Dev/MPAS-Tools/blob/master/conda_package/mpas_tools/cime/constants.py
I at least check it in CI to make sure the constant match:
https://github.com/MPAS-Dev/MPAS-Tools/blob/master/conda_package/mpas_tools/tests/test_cime_constants.py

[mwarusz]

Actually, I was able to find at some constants that really don't match. The Earth's radius and the Earth's rotation rate:

In Scream:

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/components/eamxx/src/physics/share/physics_constants.hpp#L96

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/components/eamxx/src/physics/share/physics_constants.hpp#L98

In shr_const_mod:

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/share/util/shr_const_mod.F90#L20

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/share/util/shr_const_mod.F90#L19
which comes out to be 7.29212351699037485E-05

Also it seems that Scream dynamics has some constants that differ from Scream physics:

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/components/eamxx/src/physics/share/physics_constants.hpp#L28

https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/components/homme/src/share/cxx/PhysicalConstants.hpp#L19

[xylar]

That's not good. Those kinds of inconsistencies are hard to fix later (e.g. when we have just done some of that in MPAS-Ocean, it required ~100 year simulations to evaluate the consequences) and they have real, physical consequences on the behavior of the coupled model.

[vanroekel]

I strongly agree with @xylar, having a separate constant file for omega seems a very bad idea to me.

[rljacob]

cc @bartgol @AaronDonahue

[rljacob]

I would suggest that we keep the shared physical constants in a text file which any program could ingest to get the shared values. shr_const_mod.F90 would be modifed to use that.

[bartgol]

I would suggest that we keep the shared physical constants in a text file which any program could ingest to get the shared values. shr_const_mod.F90 would be modifed to use that.

That seems reasonable. Now let's fight on the format :) Since EAMxx is in C++, I would vote for yaml. XML is also a reasonable choice, but since we already interface with yaml, that would save us from adding other dependencies and interface with other readers.

Tbc, EAMxx has also rolled its own constants file, but I am more than happy to just load in an existing file, so that all components agree on the value of constants. I am also fine with the driver exposing some functions along the line of

function get_physical_constant (name)  return (c)

(possibly with both a C and Fortran interface, or maybe making this function C-interoperable) leaving the burden to read the text file just to the driver...and possibly to the components trying to run in standalone mode.

[bartgol]

I found this repo in the ESCOMP org on github. Perhaps E3SM-Project could have its own or fork it (adding the constants we use/care about), with a few different formats. E.g., a namelist (for fortran), yaml/XML/json for C/Python. It seems like a reasonable thing for our org to have...

[xylar]

@bartgol, I would definitely be in favor of having a small external repo that houses a YAML file with the shared constants like in the ESCOMP link you shared. I don't feel strongly about whether there should be a parsing tool and I don't think a way to convert to a namelist would be better than just parsing the YAML file in shr_const_mod.F90.

The big advantage of the shared external repo is that it could easily be a submodule of E3SM and could also be used for other related repos like MPAS-Tools.

[bartgol]

My only reason for having a namelist file was to avoid adding another dep for a fortran parser for yaml (which I don't think we currently have). That said, I have never liked namelists, so I'd be pumped to see our F90 interact directly with yaml files instead.

I could start a repo with a constants yaml file, and a small README. Maybe we should quickly discuss what format do we want for that. The ESCOMP dictionary contains a lot of attributes for the constants:

         - name: stefan_boltzmann_constant
            value: 5.67036713E-08
            units: W m-2 K-4
            prec: double
            type: strict
            relative_uncertainty: 2.3E-06
            description: "
              Proportionality constant between the power emitted by
              a black body and the fourth power of its temperature, 
              according to Stefan-Boltzmann's law.
            "

I can't find the meaning of "type" in their docs, but anyways, I think name, value, units, and description are probably enough for our needs. I do like how they grouped them in sets though (math constants, fundamental constants, water constants, etc).

[rljacob]

I would like us to just use the Physics Constants Dictionary. Although it currently lives in an NCAR repo, it was created as part of ICAMS and is meant to be used by all U.S. weather/climate models. Although we may be the first to actually do it.

[bartgol]

I would like us to just use the Physics Constants Dictionary. Although it currently lives in an NCAR repo, it was created as part of ICAMS and is meant to be used by all U.S. weather/climate models. Although we may be the first to actually do it.

Looking at that dictionary, it doesn't have many constants. I'm pretty sure we may want to add more. Maybe we could fork it?

Edit: but I'd still vote in favor of having an E3SM specific repo. Besides certain cryptic entries (what is type: strict?) or the fact that we don't really care about the "relative uncertainty", I don't really like the name of the sub-groups, as they are not self-explanatory for people not already familiar with them. E.g. IAPWS1995, SORCETIM2008, CODATA2014,... I would much prefer to see sections named mathematical, fundamental_physical, geophysical, atmospheric, etc.