B. Running Forecasts within ADAS

Running Model Forecasts within the ADAS Context

As mentioned in the introductory section here, in development mode, forecasts from cycled analyses and restarts are performed after the fact; they are not performed as automatic extensions to the predictor step of IAU (as done in FP-like settings). However, in many of the experiment template examples provided previously, forecasts are launched automatically by the main ADAS driving scripts at 1500 and 2100 UTC; the corresponding 1800 and 0000 UTC analyses. The actual forecast script, g5fcst.j, lives under FVHOME/fcst.

Users can also launch forecasts on their own by following steps similar to

cd FVHOME/fcst
touch forecast.19970704_09z
sbatch g5fcst.j

The length of the forecast is controlled by the CAP.rc.tmpl file under the FVHOME/fcst directory. By default, the example above will retrieve initial conditions from the underlying (user) experiment related to FVHOME. In these cases, the IAU tendency files are also retrieved as part of the initial conditions, this is because the forecast framework in ADAS integrates from the beginning of the IAU period, rather than another time (see below). Specifically, in the example case in the introduction when the ADAS cycle covers the period from 0900 to 2100 UTC, forecasts from a 1200 UTC analysis can be issued in three possible ways:

1. Starting at the end of the background period, i.e., 2100 UTC
2. Starting at the end of the IAU corrector step, i.e., 1500 UTC
3. Starting at the initial time of the cycle, i.e., 0900 UTC

The quickest and most economic way is (1) above since it avoids redundancy in redoing parts of the cycle; it simply picks up from where the ADAS cycling left off. However, the defaults in the ADAS are such that initial conditions for this case (i.e., the final state of the model integration at the end of the IAU predictor step) are never available. During corrector-predictor cycle, a complete set of restarts is only written at the end of the corrector step, i.e., at 1500 UTC in the example above. Launching forecasts from this time, option (2) above, would simply involve the basic model initial conditions and a setup of the model control file (AGCM.rc.tmpl) to let the model run free from the influence of the analysis, all such influence are retained in the restarts. This introduces some redundancy since it repeats the predictor part of the integration (already performed during the ADAS cycle). As oddly as it might seem, for practical (and historical) reasons related to model output management, option (3) is that embedded in the default settings. This option reruns the first 12 hours of the ADAS cycle -- and indeed a test of consistency in the regression tests makes sure it is indeed the case that outputs from the first 12 hours of the forecast agrees with corresponding ones produced during the cycle. A schematic representation of the equivalence between the ADAS cycle and parts a corresponding forecasts is found here

In the x-like experimental settings the length of the forecasts are controlled by files CAP_15.rc.tmpl and CAP_21.rc.tmpl: the former is set to run forecasts from 1500 UTC initial conditions for 33 hours; the latter controls forecasts from 2100 UTC initial conditions and is set to 123 hours (5 day and 3 hours). The initial time of these forecasts and their corresponding length is associated with machinery for deriving observation impacts through the Forecast-based Sensitivity Observation Impact (FSOI; e.g., Diniz and Todling 2019, and references therein); more on this in subsequent sections.

It is simple to turn off the automatic generation of forecasts while the ADAS cycles. This is controlled by the environment variable FCSTIMES in the main ADAS job scripts (e.g., g5das.j). Commenting out the settings for this environment variable shuts off any automation in the launching of forecasts. This is sometimes useful when the batch queues are too full or the user is mainly interested in the what happens in the cycle itself. As we have seen above, forecasts can always be issued after the fact; offline.

Assuming that initial conditions are available, that is, that the underlying ADAS has cycled through the period of interest, it is also possible to run multiple forecasts simultaneously. For example, the little script below can be placed in the FVHOME/fcst directory

#!/bin/csh
set hh = 21
set yyyy = 1776
set mm = 07
foreach dd ( `seq -f %02g  1 6` )
    set this_nymdhh = ${yyyy}${mm}${dd}_${hh}
    touch forecast.${this_nymdhh}z
    sbatch --export=this_nymdhh="${this_nymdhh}" g5fcst.j
  end
end

and executed at command line. In this example, seven forecast jobs are submitted to the batch queue for the 0000 UTC analyses from 1-7 July 1776. The user should know that in this mode (i.e., when a date and time is passed at command line to the g5fcst.j script), no automatic archiving of the output from the forecasts will take place; all output will be left under FVHOME/prog.
CAUTION: Depending on the level of priority queue these parallel forecasts can overtake the batch system, please be considered to others and run only a handful of these at a time.