# Presentation: 909596

## Facilitating Code Exchanges Between GFDL and NCAR: Code Kernelization 

- Richard.Hemler@noaa.gov

## Goal: To reduce the effort required to transfer physics modules between models and modeling centers

## Strategy

- 1) Identify and isolate the FMS dependent code features from the “guts” of the parameterization
- 2) Define a procedure to allow the parameterization (perhaps without some of its functionality) to be run in the non-FMS model while the code changes needed to provide full functionality are developed.

## Implementation

- 1) Define a kernel “driver” module which will contain the FMS dependent code. In theory, all code mods needed to attach the parameterization to the non-FMS model will be made to code at or above this level in the calling tree.
- 2) The rest of the code is placed in “kernel” files which contain no FMS dependencies and should not need any modification for use in the non-FMS model.

## Implementation – Donner Deep Convection Parameterization

- In FMS, moist_processes.F90 is the routine which starts, executes and ends the donner deep convection (DDC) parameterization.
- The non-FMS user will need to determine where DDC will be attached in that model, and make sure the needed input arguments are available there and the output fields are properly processed upon exit.

## Implementation – Donner Deep Convection Parameterization

- For the DDC parameterization, the kernel driver file is donner_deep.F90. This file contains the module donner_deep_mod.
- The kernel files are designated as ..._k.F90:
- cumulus_closure_k.F90
- donner_cape_k.F90
- donner_cloud_model_k.F90
- donner_deep_k.F90
- donner_lscloud_k.F90
- donner_meso_k.F90
- donner_rad_k.F90
- donner_types_k.F90
- donner_utilities_k.F90

## FMS Dependencies in DDC

- The following processes in DDC rely on the FMS infrastructure code. In order to execute the fully implemented DDC parameterization, code to support these functionalities must ultimately be provided by the non-FMS model.
- 1. Defining the tracers to be transported by deep convection.
- 2. Netcdf diagnostic output.
- 3. Column diagnostics available with DDC.
- 4. Namelist processing.
- 5. Restart file processing.
- 6. Runtime error message processing.
- 7. Calculation of saturation vapor pressure.

## FMS Dependencies in DDC

- However, DDC may be executed and will produce proper model temperature and moisture tendencies with the first six of these dependencies simply removed.
- Therefore, if one removes the first six functionalities and provides an interface to the saturation vapor pressure calculation  compatible with DDC’s requirement, the non-FMS model may be run with DDC included.

## Saturation vapor pressure -- FMS

- FMS uses lookup tables for saturation vapor pressure.
- The kernel routines access the saturation vapor pressure via the use of an entry in a “kernel module”. This module is FMS-independent.
- Use sat_vapor_pres_k_mod, only : lookup_es_k
- Call lookup_es_k (temp, es, nbad)

## Saturation vapor pressure – Non FMS model

- Two suggestions:
- EITHER
- 1) Provide a sat_vapor_pres_k_mod containing the interface as described above. That interface would then provide the vapor pressure using the non-FMS model’s algorithm.
-  OR
- 2) Provide a non-module subroutine lookup_es_k. This would require removal of the
-                 “use sat_vapor_pres_k_mod”
-     statements in the kernel routines, but would avoid the creation of the sat_vapor_pres_k module.

## Quickstart Procedure

- A procedure has been defined and documented which allows DDC to be run with the first six functionalities defined above removed.
- This procedure is described in detail (for the memphis version of the code) in a .ps file which may be checked out from the FMS repository, along with versions of moist_processes.F90 and the donner_deep.F90 in which these changes have been implemented.

## Quickstart Procedure

- Among the code changes needed:
- Pass dummy arguments to donner_deep_init
- Eliminate reading of the nml file – use default settings
- Remove code to process the restart files
- Remove calls accessing the tracer manager to get tracer names
- Remove calls which process error messages
- Remove code setting up the column diagnostics invocation
- Remove code involved with netcdf output file processing
- Remove use statements in the kernel driver module
- Add code to define (or obtain) the geophysical constants needed in the kernel driver
- Remove several subroutines in the kernel driver module

## Summary

- The DDC parameterization has been put in a form intended to allow easy porting of it to non-FMS-based models.
- In addition to having the needed input fields provided through argument lists, those features which depend on the FMS model infrastructure have been identified and isolated.
- Procedures to handle the saturation vapor pressure calculation and to run DDC without the other infrastructure-dependent features are defined.
- The functionalities that must be returned for a full implementation of  DDC in the non-FMS model are defined.