All components must meet the following requirements.
Below is an overall list of ccsm requirements issues. Recommendations can be found in other areas of this document.
To facilitate system testing and to create more robust CCSM code,
all code integrated into the CCSM system must pass the following
signal trapping requirements. All code written for the CCSM should
be written with these requirements in mind.
Normally not all signal trapping will be on during production runs because of performance issues, but the code must meet these criteria during testing. All codes must pass:
All of these will be on all the time by default unless some performance degradation is found except
These will be turned on by default or via an ENV DEBUG flag. The debug flag might also turn on other options to be determined.
On the IBM machines, there are possible conflicts when using both signal trapping and the Mass library. For that reason, use of Mass must be turned off when carrying out signal trapping tests.
In general, the models should be able to be started from an arbitrary combination of initial or restart data with any start date. The most general cases may require significant user intervention in the scripts. However, the scripts and all components must support the three major run modes as set by ENV variables in the main ccsm script.
These three types of runs available in the CCSM framework are generally known as initial, continue, or branch. Their requirements are described below. The most general ENV variables that specify the run type will be
These variables will be set in the main run script and propogated to the component run scripts.
Initial runs are specified by setting the RUNTYPE to ``initial''. The only requirement for initial runs is that all models must be able to startup from reasonable datasets. These can be generic initial datasets, initial files based on previous model runs, or full precision restart files. There is no dependence of initial runs on previous case names or calendar dates. The initial date of the run will be set by the ENV variable
REQUIREMENTS:
and propogated to all components.
A continue run represents a bit-for-bit exact continuation of a previous run. In this case, it is assumed that the case name is not changed and that the date is continuous. All components must write restart files that will allow them to ``restart exactly'' under this scenario. In this case, RUNTYPE is set to ``continue'' and no other changes are required.
REQUIREMENTS:
RUNTYPE is set to ``branch'' to carry out a branch run. A branch run generally means that a case will be started from model restart files with a new case name and possibly a new start date. These types of runs are typically used when sensitivity or parameter studies are required or when runs, like historical or future scenarios, are being carried out.
The simplest scenario of a branch run is to continue a previous case with a new case name and a continuous date. Under this scenario, the new case must produce bit-for-bit exact restart in the same manner as a continue run.
The next scenario of a branch run would be to use a consistent set of restart files but to change both the case name and the start date. Under this scenario, there is no guarantee that the model will produce bit-for-bit exact restart because the date can be non-continuous.
The scripts and components must support the ability change both the case name and start date using ENV variables. The components can pick up the new start date from namelist input (using the ENV variables) or from the coupler at initialization. Exact restart is required if only the case name changes. Under the branch scenario, the primary ENV variables are
REQUIREMENTS: