MAM4 physical constants

[jeff-cohere]

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.

[odiazib]

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.

For example:

const Real zero_div_fac = 1.0e-37; from calcsize

[jeff-cohere]

From @pbosler in #72:

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.