Terminology
The CPDN OpenIFS@Home uses slightly different terminology to what OpenIFS users might be used to.
OpenIFS@Home Ancillary Files
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
There is no fort.4 or namelist file and no 'ecmwf' directory as is common in the files downloaded from the ECMWF provided initial model files.
(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
In this case, to save space, make links between common files in each ensemble directory.