FAQ: How is the surface treated in the SCM?

Submitted by grantf on Thu, 09/03/2020 - 09:01

How is the surface treated in the SCM?

For observational field campaign-based cases, if the case is over the ocean, the SST is supplied as input and the specified ocean physics scheme calculates the roughness length, surface fluxes, etc. For land-based cases, only specified surface fluxes are supported as of the last release, i.e. use of an LSM in the physics suite is not currently supported due to lack of initialization data for observationally-based field campaign cases. For these cases, the following conditions must be met:

  • surface sensible and latent heat fluxes must be provided in the case data file
  • sfc_flux_spec must be set to true in the case configuration file
  • the surface roughness length in cm must be set in the case configuration file
  • the suite definition file used must have been modified to use prescribed surface fluxes rather than an LSM. 

Note that there is no technical reason why land-based field campaign cases cannot be called with an LSM. If appropriate initial conditions are available (profiles of soil temperature and moisture that have been “spun up” to be consistent with the initial state and forcing), they can be used.

Also note that within ccpp/suites there are typically two copies of a given suite: one with its normal name and one with a “_ps” appended, which stands for “prescribed surface”. The “_ps” SDFs contain the exact same physics schemes as their regular counterpart, except for the scheme gmtb_scm_surface_flux_spec is substituted for all surface-related schemes. This CCPP scheme “backs out” surface-related variables from the specified surface fluxes for use in subsequent (e.g. PBL) schemes. Note that it is not necessary to specify that one should use a “_ps” SDF when running the model through the run script. If the case configuration file specifies sfc_flux_spec = True, the run script automatically chooses the “_ps” version of the suite to run.

As of the current release, using the SCM over a land point with an LSM is possible through the use of UFS initial conditions (see section 5.5 of the SCM User and Technical Guide). However, advective forcing terms are unavailable as of this release, so only short integrations using this configuration should be employed. Using dynamical tendencies (advective forcing terms) from the UFS will be part of a future release.

I cloned the master branch today (11/30/20) on Hera.  Compiled with no trouble.  Tried running the LASSO_20180914_s02 case with both GSD_v1 and RRFS_v1beta suites.  Surface fluxes are zero in both cases.  The log says that the specified flux version of the suite is being used.  I wonder if specified fluxes got broken when work was done to make running with LSMs possible.

I'm also seeing an error, apparently at the end of the run script, which is probably a separate problem:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "./run_gmtb_scm.py", line 400, in launch_executable
    sys.exit(os.system(cmd))
SystemExit: 0

Wayne Angevine

 

Wayne,

This should be fixed in the latest pull request (still needs review/merging at this point): https://github.com/NCAR/gmtb-scm/pull/217

Please wait until this work is merged to retest.

The issue turned out to be that changes in the PBL schemes within the CCPP are now requiring modified surface fluxes rather than the unmolested values that the existing CCPP scheme that backs out PBL-needed variables from specified surface fluxes had been providing. The changes that I did for the GABLS3 case to use an active LSM under a field-campaign based atmosphere are still in a branch and haven't been merged to master yet. I think that I'll get to this next.

-Grant