...

Multiple forecasts with restarts

There are several reasons why a user may wish to restart a forecast experiment. The increase in computational costs for simulating atmospheric composition may require to break a longer forecast experiment into individual sections ("legs"). Also, a restart will allow to initialise the meteorology in the model with data taken from an analysis of the current modelled time. 

Due to the time scales associated with the different chemical processes and the lifetime of chemical tracers with respect to their loss processes, it is often convenient to retain the chemical tracer fields in the model simulation and update only the driving meteorology at the time of the restart. In some applications, the model could even be initialised every single day with an up-to-date meteorological analysis field while the chemical fields are left to evolve.  The previous section described how chemical initial conditions can be created at the end of an experiment run, thus retaining the chemical tracer information from the previous experiment leg. 

We will here provide some examples of the principle steps required for restarting experiments.

Example 1:  Longer experiment with manual stop and restart

The experiment parameters need to be defined by editing config.h. The following settings are used for a 2-month experiment with a stop-and-restart after the first month. This will result in two experiment legs of 1 month duration each.

run_start_date="2010-01-01"
run_end_date="${run_start_date} + 2 months"
rst_freq="1 month"
USE_RESTART=true

The initial conditions for each leg need to be either created or gathered from a prepared repository.

prep-ic-icmcl-compo.sh  2010-01-01 2010-02-01
prep-ic-icmcl-compo.sh  2010-02-01 2010-03-01 

These processes can be run in parallel. The meteorological fields and initial conditions can be requested from the OpenIFS Data Hub. The wrapper script needs to be submitted for the first experiment leg. Once the experiment has completed, config.h needs to be edited to use the initial experiment data from the date and time when the first leg has stopped. Then the wrapper script for the second month should be submitted.

Example 2: Using a workflow script

The 4 jobs in the previous example, can be all triggered automatically and in a timely fashion with a single script. The  $OIFS_HOME/AC-experiments/platform/<platform-name>-workflow.sh templates provide examples that need to be adjusted for the local hardware and file paths. In this case the config.h file only needs editing once and instead of the batch job wrapper script the workflow script is submitted.