You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, let's articulate our strategy for using physical constants in mam4xx:
Every C++ function in mam4xx should use exactly the same values for physical constants that are used by the corresponding subroutine in mam4.
The above statement should be interpreted literally. We are using whatever values MAM4 uses, even if they are inconsistent across parameterizations, within a parameterization, or just plain wrong. In general, this means a C++ function can have its own set of constants, depending on the situation in the corresponding Fortran subroutine.
This strategy may seem crazy, but it allows us to confine our attention to porting errors when we compare output from C++ and Fortran implementations.
Tracking Inconsistencies
When you encounter an inconsistent value of a physical constant while porting MAM4 Fortran source to C++, please add a comment next to it in the C++ file with the tag BAD_CONSTANT and describe the problem if it's easy to summarize. For example:
constexpr Real pi = 4.13; // BAD_CONSTANT!! Very bad accuracy--no circles possible
This allows us to quickly search for BAD_CONSTANTs throughout the code so we can return one day and fix them. The procedure for fixing these constants is, sadly, outside the scope of this issue.
The text was updated successfully, but these errors were encountered:
jeff-cohere
changed the title
MAM4 physical constants: log issues here!
MAM4 physical constants
Nov 16, 2022
We should include numerical constants. I have seen these type of constant when a developer wants to avoid a scenario that produces nan or inf, e.g., division by zero.
Bad constants. I know we're doing a straight refactor because of a deadline, but when bad constants exist for bad purposes, such as dubious handling of floating point arithmetic, I vote for getting rid of them. Bad constants that have physical (rather than numeric) implications likely have to stay.
First, let's articulate our strategy for using physical constants in mam4xx:
The above statement should be interpreted literally. We are using whatever values MAM4 uses, even if they are inconsistent across parameterizations, within a parameterization, or just plain wrong. In general, this means a C++ function can have its own set of constants, depending on the situation in the corresponding Fortran subroutine.
This strategy may seem crazy, but it allows us to confine our attention to porting errors when we compare output from C++ and Fortran implementations.
Tracking Inconsistencies
When you encounter an inconsistent value of a physical constant while porting MAM4 Fortran source to C++, please add a comment next to it in the C++ file with the tag
BAD_CONSTANT
and describe the problem if it's easy to summarize. For example:This allows us to quickly search for
BAD_CONSTANT
s throughout the code so we can return one day and fix them. The procedure for fixing these constants is, sadly, outside the scope of this issue.The text was updated successfully, but these errors were encountered: