EKAT icon indicating copy to clipboard operation
EKAT copied to clipboard

Physical constants

Open pbosler opened this issue 4 years ago • 13 comments

Question

What would be the best (or at least acceptable to a majority) way to handle physical constants in a consistent manner throughout scream?

This issue has come up in several recent discussions (e.g., @PeterCaldwell, @AaronDonahue ) and at least 2 issues: haero issue #6 ( @jeff-cohere and @pbosler ) scream pr #579 (@tcclevenger, @ambrad)

For discussion:

  1. Currently, different parameterizations often define the same constants, but with different numbers of significant figures and/or units. The ideal solution is to use NIST-defined values for each constant, defined in a single location (file or struct) that dynamics and parameterization can use/alias with local variables as needed.
  2. Suppose people agree with that statement; where should such code live? Physical constants have nothing to do with Kokkos, but EKAT already contains other supporting features like ekat::units that are also unrelated to performance portability, but generally useful to everything in E3SM, so I'm inclined to put physical constants in EKAT (@bartgol).
  3. We've found that some constants require double precision (e.g., they may be very small or very large, or they may be required by possibly ill-conditioned algorithms) whereas others can be single precision. How should these requirements be handled in scream & ekat?
  4. What should the timeline be for this work?
  5. Should this be a forward looking c++ only change (to avoid BFB issues), or should it include fortran as well?

pbosler avatar Sep 17 '20 22:09 pbosler