CCPP AMS2020 Short Course | Modify a scheme

Modify a scheme

Let’s modify a scheme and re-run an experiment to see if we can obtain a reduction in the temperature bias profile. For this exercise, we will concentrate on the suite with the largest temperature bias (csawmg) and the most obvious culprit, the deep convection scheme. Further, assume that we are the laziest physics developer in the world and we will “solve” the temperature bias problem through brute force.

NOTE: the following steps have been provided for you in the modified source code instructions at the end of this page, but are described here for your information.

Looking at the suite definition file for the SCM_csawmg suite (file gmtb-scm/ccpp/suites/suite_SCM_csawmg.xml), we see that the deep convection scheme is called “cs_conv” (Chikira-Sugiyama convection). Its top-level CCPP entry-point subroutine (cs_conv_run) is found in the file gmtb-scm/ccpp/physics/physics/cs_conv.F90. The call to CS_CUMLUS produces tendencies of the state variables, including temperature, and they are applied in the code shortly thereafter.

We will define a new variable used to multiply the temperature tendency before it is applied to the temperature state. Rather than defining a local variable, we’ll turn it into a “tuning knob” by making it a namelist variable and pass it in to the scheme through the CCPP framework. Hint: We can assume that this variable does not already exist in any supported CCPP scheme or in the list of variables supplied by the host SCM for this course, although in practice, one should check to see if an appropriate variable already exists for our use.

The implementation begins with straight Fortran code. The variable is added to the argument list, declared as in INTENT(IN) scalar real, multiplied by the temperature tendency variable at the appropriate place in the code.

Since we modified the interface by adding an argument, we will need to add CCPP metadata and “advertise” that the scheme requires the new variable. Notice that the new variable has been added (in the right order) in the metadata for the subroutine cs_conv_run in cs_conv.meta.

At this point, IF the new variable already existed in the SCM’s list of CCPP-available variables, we would be done! After rerunning cmake to regenerate the software caps and make to compile, the modified code could be run. In this case, we will need to add the variable to the SCM and “advertise” that it is available for CCPP schemes to use. For the SCM, model control variables are contained within the GFS_control_type derived datatype found in the gmtb-scm/scm/src/GFS_typedefs.F90, so we will add the new variable (global_ttend_mult) there. Note that it is not necessary for the local variable names to match between the host and the physics scheme -- the CCPP standard name and other metadata needs to match, however. This derived datatype is initialized with a default value (1.0) in the control_intialize subroutine in the same file, and read in from the same physics namelist as other physics variables, potentially overriding the default.

Once the Fortran has been added, we will need to edit the SCM’s metadata by adding the new variable’s information in the appropriate place in gmtb-scm/scm/src/GFS_typedefs.meta (note that each derived datatype has its own section beginning with [ccpp-arg-table] in this file).

This completes the addition of a new variable on the physics side and the SCM host side. 

Using the default namelist for the SCM_csawmg suite would produce identical results at this point, so we’ll replicate the existing namelist for this suite with a non-default value for the new variable (global_ttend_mult = 1.15). See gmtb-scm/ccpp/physics_namelists/input_csawmg_short_course.nml.

Rather than having you implement these changes yourself, they have been provided to you in a tar file. Using the instructions below, extracting the tar file will put the modified files in the correct directories and update their timestamps so that cmake/make will know to recompile them and their dependencies. Note: This can be undone by running git checkout . on the top-level gmtb-scm directory and the ccpp/physics subdirectory.

Re-run the updated code and case

Finally, re-run the TWP-ICE case with the modified code and namelist (NOTE: this command is all one line, your browser may split the line, be sure to copy/paste it into one command!):

Let’s see how we did!

Re-run the plotting script using a new plot configuration file to plot all 4 runs of the TWP-ICE case.

Look in plots_twpice_short_course/comp/active. The temperature bias profile plot  (profiles_bias_T.png; also supplemental slide 32)  shows the 3 original suites alongside the modified csawmg suite (labeled csawmg+) on the plot. For this case, we have definitely improved the performance of this suite for this metric by brute force!

Open the temperature tendencies plot (profiles_mean_multi_T_forcing.png; also supplemental slide 33).