EKAT
EKAT copied to clipboard
Physical constants
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:
- 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.
- 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). - 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?
- What should the timeline be for this work?
- Should this be a forward looking c++ only change (to avoid BFB issues), or should it include fortran as well?