Forcing the SCM

I have been the primary user and promoter of the WRF SCM.  In the process, I have given a lot of thought to how forcing is or should be done.  I think it's time to give similar thought to the forcing strategies of the CCPP SCM.  This probably needs to be a group process, so the result accomodates as many future users and uses as possible. I am under no illusion that I understand everything that people might want to do with the SCM.

One thing that might be considered a bug in the existing gmtb_scm_forcing.F90:  When vertical velocity is used, momentum variables are advected with w, while thermodynamic variables are advected with omega.  This should work, but I don't see a reason for both w and omega variables to exist and to be used differently.

In WRF SCM, there are two scales of advection available, regular and "large scale."  The main reason for this is to allow two different relaxation timescales to be used.  I implemented the second scale to accomodate the forcing provided by the original specification for the KNMI Testbed, many years ago.  In recent times, I have not found a need for two scales.  See dyn_em/module_force_scm_xy.F in WRF for details.

Also in WRF SCM, forcing (advection) of variables can be switched on and off individually.  If vertical advection is switched on, all variables are advected vertically.  Horizontal advection can be switched on or off for wind, temperature, and moisture.  This provides flexibility for different kinds of cases.  Forcing due to Coriolis is always on, unless SCM forcing is switched off entirely.

One specific deficiency in the current CCPP SCM forcing is that there is no way to use forcing by Coriolis only.  In a low-level jet case, I don't want to force the wind, but I do need Coriolis forcing.  I coded this into the default case of my own version, but there should be a general solution.

I would be happy to participate in a group to design a complete(?) solution.

Wayne Angevine CIRES/NOAA CSL