Discussion related to adding a CCPP-provided physics function library

[grantfirl]

Throughout the physics there are numerous instances where the same formulation is used, but different code.

Some of the notable repeat offenders are:

• Functions to compute saturation-vapor pressure
• Computation of cloudiness
• Tridiagonal solvers.
• Random numbers

Pros: consistency across physics, code re-use, reduced burden on developers(?)
Cons: more code to maintain by DTC(?), pushback from developers(?)

[ligiabernardet]

Discussion at the CCPP Visioning Workshop:

• Saturation functions are a priority for consistency
• Need to be careful to dive too much into this because many hosts have their own saturation functions, but just need a way for CCPP schemes to “legally” call host subroutines – possible to put in CCPP and have host access from CCPP?
• Schemes used outside of CCPP may still need to carry their own saturation function for portability reasons
• Consistency across the model (including postprocessing) and best software practices are two (complementary) goals