This refers to all the input files that the OpenIFS model needs to run:

• initial data to start a forecast (normally obtained from ECMWF);
• ifsdata and climate files (downloaded from the OpenIFS ftp site);
• model namelist (only parts of the OpenIFS namelist can be uploaded, see below)

These ancillary files are stored in a zipped format on the CPDN repository.

Experiment information is read from the initial files GRIB metadata upon upload to the OpenIFS@Home repository and used to set the experiment id, date/time of forecast etc.

Experiment namelist

It's not possible to upload a complete model namelist to the OpenIFS@Home website. This is because some restrictions are necessary in order for the model to work correctly and efficiently when running on a volunteer's computer.

At the time of writing, the only part of the model namelist allowed to be uploaded is the 'NAMFPC', or 'FullPos' namelist, which controls all the model's output.  Even this is vetted by CPDN first to ensure the model does not produce more output than can be reasonably handled by the volunteer's computer and network for transfer of the results back to the CPDN database.

Apart from the model's NAMFPC output control namelist, the rest of the namelist is selected as a 'template' when the experiment on OpenIFS@Home is configured. Namelist experiment templates exist for different resolutions and different classes of experiments; for example 10 day NWP forecasts, seasonal forecasts etc. For more details please see the OpenIFS@Home dashboard and documentation, or contact the CPDN team directly.

Preparing Initial Files to Upload

The upload of initial files is made from the OpenIFS@Home Dashboard on the OpenIFS@Home portal. It expects the initial files to be laid out in a particular directory structure.

There are 3 types of permitted directory structures as illustrated in the diagram left. They correspond to whether multiple dates are present, and whether ensembles of initial data are being used.

(a) Single date.

In this case the directory structure would be as following:

% ls -R hijc     #  "hha4" is the experiment id in this example
hijc/2017041212:
ICMCLhijcINIT   ICMSHhijcINIT    specwavein         wam_subgrid_0
ICMGGhijcINIT   cdwavein         uwavein            wam_subgrid_1
ICMGGhijcINIUA  sfcwindin        wam_grid_tables    wam_subgrid_2

(b) Multiple dates.

This case is an extension of (a) but with multiple sub-directories, one for each date. The example below shows two dates but it's possible to use many more.

% ls -R hijc     #  "hha4" is the experiment id in this example
hijc/2017041212:
ICMCLhijcINIT   ICMSHhijcINIT    specwavein         wam_subgrid_0
ICMGGhijcINIT   cdwavein         uwavein            wam_subgrid_1
ICMGGhijcINIUA  sfcwindin        wam_grid_tables    wam_subgrid_2

hijc/2017041300:
ICMCLhijcINIT   ICMSHhijcINIT    specwavein         wam_subgrid_0
ICMGGhijcINIT   cdwavein         uwavein            wam_subgrid_1
ICMGGhijcINIUA  sfcwindin        wam_grid_tables    wam_subgrid_2

(c) Ensemble of starts and multiple dates

This is the more complex case. Not only are there multiple dates but for each date there are multiple ensemble members.

The directory structure will now look like: <expid>/<date>/<ens>/.

The following examples shows two dates, each with 3 ensemble members. By convention, there is always a '000' member.

% ls -R h76y       # 'h76y' is the experiment id in this case
h76y:
2016092500

h76y/2016092500:
000
001
002

h76y/2016092500/000:
ICMCLh76yINIT    ICMSHh76yINIT    specwavein         wam_subgrid_0
ICMGGh76yINIT    cdwavein         uwavein            wam_subgrid_1
ICMGGh76yINIUA   sfcwindin        wam_grid_tables    wam_subgrid_2

h76y/2016092500/001:
ICMCLh76yINIT ......    # lines omitted for brevity

h76y:
2016092512:

h76y/2016092512:
000
001
002

h67y/2016092512/000:
ICMCLh76yINIT    ICMSHh76yINIT    specwavein         wam_subgrid_0
.....   # lines omitted for brevity