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.

[grantfirl]

So, when using this, one needs to remove the state_update scheme from the SDF and put this scheme as the last process-split scheme, right?

[grantfirl]

Could one interpret the data as constant for all time if a time dimension is missing rather than error?

[dustinswales]

Not at the moment, but that's a good idea.

[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.

[grantfirl]

Could you help me understand why this is setting physics_process(1) instead of physics_process(iprc)?

[dustinswales]

@grantfirl In response to your comment above regarding physics_process(1) vs. physics_process(iprc).
I added the metadata related to the active scheme to this type, which gets allocated by the number of physics process set in the namelist, but I only need to use the (1) index for the active metadata, since there is only one active scheme.
Two questions:

1. Do we want to be able to have multiple "active" schemes? (I think so)
2. Should I create a second DDT here with the metadata, and data, for the active scheme(s)? This would clean up the interface to the simulator a bit.

[grantfirl]

OK, now I think I'm confused. You're using "active" as opposed to "simulated", right? They're mutually exclusive? If so, ya, I thought that we would be able to have any combination of "active" and "simulated" schemes, not one active and the rest simulated.

[grantfirl]

Nice job on implementing this. It's probably a good idea to go ahead and merge this and if there are additional "features" that need to be added, we can add an issue to address them later.