CCPP scheme simulator

[dustinswales]

This PR adds a new functionality, a physics process scheme simulator, to the CCPP-physics.

Data-driven tendencies can be used to drive process schemes (e.g. PBL, Deep-Convection, etc..). The control over which schemes are used are set in a new physics namelist, scm_data_nml. These data tendencies are read in during the CCPP initialization stage, and applied during the _run stage, if requested by the nml. There are new interstitial variables for the data tendencies.

To use this feature on the host-model side the Suite Definition File (SDF) needs to be modified to include the ccpp_scheme_simulator scheme, and GFS_ccpp_scheme_sim_pre.

Caveats worth mentioning.

• This tool relies on using the GFS diagnostic physics tendencies from the "active" physics scheme. These are "bucket variables", Interstitial fields that are accumulated over the diagnostic interval. To avoid introducing new interstitials I decided to just use these, with the downside of having to run the host-model with a diagnostic interval that matches the physics timestep. The scheme simulator is intended to be agnostic to the host, so the coupling to the host is handled in an Interstitial module GFS_ccpp_scheme_sim_pre.F90. If a host had the instantaneous tendencies for the "active" scheme, they could bypass this interstitial step and pass directly into ccpp_scheme_simulator.F90.
• There are only four prognostic fields: heat, moisture and momentum. This could be extended to handle tracers, clouds, etc...
• Secondary coupling is not accounted for. The scheme simulator is dropped into a full SDF, just augmenting the prognostic state variables, and not any other scheme-to-scheme coupling (e.g. surface fluxes from radiation->surface scheme).

[yangfanglin]

Dustin, this is a great tool to have. Does this only work for SCM or for both SCM and full dimension models ?

[dustinswales]

Dustin, this is a great tool to have. Does this only work for SCM or for both SCM and full dimension models ?

@yangfanglin I plan on testing this in the full model in the coming days. Technically it shouldn't be a problem, the real "gotcha" is creating useful data tendencies to drive the model. For testing I've been using SCM output to create the temporal data tendencies to drive the simulators, but one could easily do the same with the UFS, creating temporal/spatially varying data tendencies.

[grantfirl]

@dustinswales Don't we need to check for flag_for_diagnostics_3D and flag_for_tracer_diagnostics_3D both being true if we're relying on the existing diagnostic variables? The SCM sets these to T by default and in the physics namelists, but it would probably be good to have a check for these somewhere since the functionality relies on them being T.

[grantfirl]

Also, the same comment applies by adding a check for fhzero = dt_phys.

[dustinswales]

@dustinswales Don't we need to check for flag_for_diagnostics_3D and flag_for_tracer_diagnostics_3D both being true if we're relying on the existing diagnostic variables? The SCM sets these to T by default and in the physics namelists, but it would probably be good to have a check for these somewhere since the functionality relies on them being T.

Good idea. Will do.