Reorganizing the handling of constants in MOM6

[alperaltuntas]

Within the CESM framework, we would like to use the constants from CIME which are shared by all other CESM components, instead of the constant values set by FMS. See:
https://github.com/ESMCI/cime/blob/master/src/share/util/shr_const_mod.F90

Handling of constants in MOM6 code makes this a bit challenging.

In MOM6, there is a MOM_constants module with only three constants, two of which is directly imported from the FMS's constants_mod module (that are HLV and HLF). In the rest of the code, about 20 other constants from FMS's constants_mod are imported in multiple MOM6 modules.

Here is my suggestion:

(1) MOM_constants module should be the sole interface between FMS's constants_mod module and MOM6. In other words, all FMS constants should be imported by MOM_constants first. Then, other MOM6 modules should import those constants from MOM_constants.

(2) Move MOM_constants module to the cap level (i.e., config_src). This would allow, say, CESM to override the FMS constants with the constants obtained from CIME's shared constants module.

If the above plan sounds good, and unless someone has a better suggestion to achieve this, I am happy to take on and implement the above two changes in NCAR fork.

[alperaltuntas]

Since I don't have permission to assign anyone or label this, I am mentioning @adcroft @Hallberg-NOAA @marshallward @gustavo-marques

[marshallward]

Point (1) seems very reasonable and is a design goal, since src/framework is supposed to be the only point of contact with FMS. But as an FMS interface module, MOM_constants also probably ought to remain in src/framework.

But having said that, the only other references I can see to constants_mod are in src/ocean_data_assim/MOM_oda_driver.F90 (I'm guessing that's an oversight, and also not an issue for you).

On my branch:

[marshall@argus mom6]$ grep -ir constants_mod config_src/ src/
config_src/nuopc_driver/mom_ocean_model_nuopc.F90:  use stock_constants_mod, only : ISTOCK_WATER, ISTOCK_HEAT,ISTOCK_SALT
config_src/nuopc_driver/mom_cap.F90:use constants_mod,            only: constants_init
config_src/mct_driver/mom_ocean_model_mct.F90:  use stock_constants_mod, only : ISTOCK_WATER, ISTOCK_HEAT,ISTOCK_SALT
config_src/coupled_driver/ocean_model_MOM.F90:  use stock_constants_mod, only : ISTOCK_WATER, ISTOCK_HEAT,ISTOCK_SALT
src/ocean_data_assim/MOM_oda_driver.F90:use constants_mod, only : radius, epsln
src/framework/MOM_constants.F90:use constants_mod, only : HLV, HLF
src/tracer/MOM_tracer_flow_control.F90:                             !! stocks_constants_mod of the stock to be returned.  If this is
src/tracer/MOM_tracer_flow_control.F90:                             !! stocks_constants_mod of the stock to be returned.  If this is

and most of those are false positives.

Is this something more specific to the NCAR fork? Or am I searching for the wrong thing?

[alperaltuntas]

the only other references I can see to constants_mod are in src/ocean_data_assim/MOM_oda_driver.F90

You are right. I was searching in the wrong directory.

Upon closer review, it looks like there are two fundamental differences in handling of constants in MOM6 vs CESM.

• Constants in MOM6 are fairly decentralized. Modules usually set their own constants, either to hardcoded values, or to values read from MOM_input.
• CESM constants are declared to be parameters, i.e., are unmodifiable, whereas constants in MOM6 aren't usually parameters and instead are assigned at runtime (e.g., the radius of earth is 6.378e6 by default, but may be changed via get_param).

So I am not sure how it would be viable to coordinate these two approaches at this point.

Regardless of coordination, some issues I noticed due to decentralized constants approach in MOM6:

• Von Karman's constant is set to 0.40 in MOM_ice_shelf, while it is set to 0.41 in MOM_set_diffusivity.F90 and MOM_energetic_PBL.F90. In MOM_mixed_layer_restrat.F90 and MOM_bulk_mixed_layer.F90, von Karman's constant is not declared as a variable, but hardcoded to be 0.41 in formulas. Yet, in MOM_CVMix_KPP.F90, it is a runtime parameter.
• Similarly, deg2rad is set to two different values in MOM_hor_visc.F90 and gsw_mod_teos10_constants.f90 (although it looks like the latter isn't used anywhere). Again, I think, deg2rad and rad2deg should be defined only in MOM_constants. The same goes for pi.
• The density of fresh water is hardcoded to 1000.0, once in MOM_tidal_mixing, and twice in MOM_ice_shelf. I feel like it should be defined in MOM_constants once and for all.
• Four modules (MOM_open_boundary.F90, MOM_verticalGrid.F90, MOM_ice_shelf_dynamics.F90, MOM_ice_shelf.F90) keep their own copies of G_EARTH. They are all read from MOM_input, so no value discrepancy issue there, but still...
• I believe this list goes on if I look further.

[MJHarrison-GFDL]

Totally agree @alperaltuntas . I have a pending PR which addresses this in MOM_oda_driver.

[adcroft]

By "constants" do you mean model parameters or do you mean physical constants like the speed of light in a vacuum? There are very few real constants used in an ocean model (I'm struggling to think of more than one right now - see below).

I think the need to coordinate values for run-time parameters between components in a coupled system is worth addressing. Right now, requiring the parameters to be consistent involves scripting outside of MOM. The way parameters are handled appears to be distributed but in fact is not - generally one processor reads the parameter file. It appears to be distributed because any module can access a parameter but to do so it must define it consistently - there is a runtime warning if it is inconsistent. I think we could evolve what is called the "file parser" to treat parameters more dynamically so that a set_param() could be used to programatically set run-time parameters. This would then allow us to add to the top-API a way of coordinating parameters during initialization. A constants module like fms_constants with fortran parameters is most definitely the wrong way to go - as I said, there are very few actual fixed or known constants to be used. The file parser is actually closer to solving this problem that it might appear based on the name, but it is itself a bit messy so needs work.

Concerning the parameters you've mentioned:

• Von Karman is not a constant but has an experimental range and varies between experiment and application. I don't think it's possible or right to have one number shared between the different parameterizations.
• pi is not a physical constant but a special number and is best defined by the math library. We think the most accurate ways to obtain pi is either as 4.*atan(1.), 2.*asin(1.), or 2.*acos(0.). "0", "1", "2" and "4" are perfectly representable in floating point so the only variability is in the math library. At least on the systems I have access to, those three definitions produce the exact same number (bitwise). However, sin(pi) and cos(pi/2) are not zero. There is no floating point representation of x near pi that I've found that gives sin(x)=0 for the math library on our machine (gaea). Given that the local definitions are deterministic I don't see a need to introduce a global constant for pi. I agree the different definitions could become inconsistent but if a math library does that to us we have bigger problems.
  • we have no control over the value of pi used in TEOS10.
• density of freshwater is not a constant (and only equals 1000.0 at about 4C, 1 atm).
• G_EARTH is a run-time parameter because it varies between model configuration and between spherical planets. Strictly speaking, it shouldn't be a constant even for Earth, but should vary systematically with both latitude and depth.

Concerning the three numbers in MOM_constants.F90:

• "HLV" and "HLF" and obtained from fms_constants only to provide a default value for the run-time parameter. These are fall back values and should remain run-time because i) we disagree with the values chosen by the meteorologists, and ii) these might/should become variables (e.g. functions of salinity, etc.).
• CELSIUS_KELVIN_OFFSET is a true constant defined to be precisely 273.15 K and can be a fortran parameter. Incredibly, the fresh water freezing point was once coded in FMS as 273.16 K (long story) which is a warning about trusting someone else's idea of the value of a constant.

[alperaltuntas]

Thanks, Alistair! Let's talk more about this in an upcoming dev call.