Add temporary global constants header file

[katsmith133]

Adds a global constants header file with many commonly used physical constants and conversion factors, and replaces uses of Gravity, Pi, and Pa2Dbar in several files. This is a temporary solution for a consolidated constants file (brough up in #179), to be replaced when a shared E3SM constants file becomes available. Values are a combination of what is in https://github.com/E3SM-Project/E3SM/blob/09b9b7e21e3d381eafa962e178a5951580e2fc74/share/util/shr_const_mod.F90 and https://github.com/E3SM-Project/Omega/blob/develop/components/mpas-ocean/src/shared/mpas_ocn_constants.F. Making the assumption that those are the agreed upon values we want to use (please correct me if I am wrong or if we want to add additional/remove unnecessary values).

Passes CTests on pm-cpu, pm-gpu, and frontier. Note: There is currently no documentation that goes with this PR and no new Ctests were added (though I am happy to add those if we think they are valuable).

Checklist

• Building
  • CMake build does not produce any new warnings from changes in this PR
• Testing
  • A comment in the PR documents testing used to verify the changes including any tests that are added/modified/impacted.
  • Unit tests have passed. Please provide a relevant CDash build entry for verification.

[philipwjones]

This is mostly fine. I have one needed change and two suggestions that others can weigh in on:

• this fails Ctests for the three Tendency tests (TEND_SPHERE, TEND_PLANE, TEND_PLANE_SINGLE_PRECISION), probably due to roundoff-level changes in expected results. So we either need to look into that or modify the expected values appropriately
• it might be good to have a Pi2 = 2.0*Pi since that combination is very common
• should we declare these as Real rather than double? When running in single-precision mode, this would prevent any extra conversions/truncations during computations

[sbrus89]

I think defining them as Real is a good idea. I talked about this a bit with @rljacob. Once the universal constants file is merged to E3SM, we can include it in this header and type cast variables to the Omega Real type (and rename variables).

[katsmith133]

This is mostly fine. I have one needed change and two suggestions that others can weigh in on:

• this fails Ctests for the three Tendency tests (TEND_SPHERE, TEND_PLANE, TEND_PLANE_SINGLE_PRECISION), probably due to roundoff-level changes in expected results. So we either need to look into that or modify the expected values appropriately
• it might be good to have a Pi2 = 2.0*Pi since that combination is very common
• should we declare these as Real rather than double? When running in single-precision mode, this would prevent any extra conversions/truncations during computations

Thanks, @philipwjones and @sbrus89!

Fixed the failed CTests. (I missed some hardcoded 9.8###s in those tests)
Added in TwoPi = 2 * Pi.
Declared as Real.
Rebased and replaced a few more constants in the code.
Note: I updated Pi = M_PI... if we don't like that, let me know. Or if we don't like the name I've chosen for any of the constants, I'm happy to change them.

Removing the "Draft" label from this PR now that the tests are fixed and the VertCoord has gone in.

[philipwjones]

Thanks for the changes. I verified it passes Ctests now. You could still propagate the new TwoPi into ManufacturedSolution, but I'll go ahead and approve this.

[brian-oneill]

Looks good. Ran the ctests successfully on chrysalis.

[katsmith133]

Question for the reviewers (@philipwjones, @sbrus89, @brian-oneill, @xylar, @mwarusz)... do we want to add things like SqrtTwo = 1.4142135623730951 or SqrtThree = 1.7320508075688772, like they are planning to add in the universal constants file (E3SM-Project#7719), and thus we can just replace the value here with that once it goes through and its consistent with the rest of E3SM? Or do we want to stick with the Kokkos::sqrt(2) option?

[philipwjones]

The hard requirement is that any quantity shared with other components should use common constants so that any quantities are calculated consistently. If we want to be safe, we should probably use all available constants from the shared constants file but we'll need to be sure to use them correctly in Kokkos kernels.

[xylar]

This looks good to me. I think it will provide a great place for the shared constants to plug in in the near future.

[xylar]

Actually, now that E3SM-Project#7719 has been merged, do we want to make use of that here? Or do we want to follow up later?

[xylar]

Presumably, the answer is later because this has already been stale awhile.

[sbrus89]

This looks great. Thanks @katsmith133!

[xylar]

I'm sorry to sneak in a last-minute request for this branch, but could we change:

Omega/components/omega/src/ocn/Tendencies.cpp

Line 182 in ba2f369

Err += TendConfig->get("Density0", this->WindForcing.SaltWaterDensity);

to use RhoSw instead of the Density0 config option?

Density0 is also used for the computation of the pseudo-height in the vertical coordinate and I think that should be the only use of Density0. (I'll follow up elsewhere to hopefully improve the commenting related to that config option.)

See #312

[katsmith133]

@xylar I will update this PR so that its not stale, and then include E3SM-Project#7719 and your suggestion for RhoSw in an update shortly. Thanks!

[katsmith133]

@xylar please let me know if this covers the changes you requested:

(1) changed it so that Tendencies.cpp uses RhoSw from GlobalConstants.h, instead of Density0 in Config.yml
(2) moved Density0 to VertCoord in Config.yml
(3) Included pcd_const.h from E3SM-Project#7719 into setting relevant constants in GlobalConstants.h (and as a part of this I had to update some tests that used the Earth's radius, as the one in pcd_const.h was just ever so slightly different)

And @sbrus89, @philipwjones, @brian-oneill, and @mwarusz, if you could all take one last look at this now that's I've made a few more changes, that would be great!

It compiles and runs on pm-cpu and pm-gpu.

[xylar]

@katsmith133, yes, these changes look excellent to me!

[philipwjones]

Looks fine to me and verified Ctests on Frontier cpu/gpu