Glossary

Autosubmit

Autosubmit is the workflow manager that is used to provide all core functionality of workflow handling. It reads the configuration, submits the jobs and obtains all the log files. The auto-icon project serves as an interface to make Autosubmit handle workflows for the ICON-ART model.

chunk

A member of an experiment can be split into several chunks (e.g. of a month length each). This can serve several purposes, e.g. to make one model run fit into the wall time or to run intermediate steps like re-initializations in between.

configuration

The configuration is everything that is processed by Autosubmit. It contains information about the general Autosubmit behavior, the involved platforms, the workflow to be run, details on the used model (e.g. ICON-ART version), location of input and output data and much more. The namelists that are used in the actual model run are strictly speaking not included in the configuration (but treated as an input file), however, some parts of the configuration actually modify the namelist (e.g. start and end date). Details on how to configure your experiment can be found in the step-by-step guide and on the pages on important config options and configuration files.

dependency

The set of jobs to be run creates the workflow through its dependencies. A job that has to be run after another depends on it. E.g. the model run has to be run after the initialization and after building the model, thus the model run depends on these two jobs.

experiment

This stands for a single experiment instance listed in the Autosubmit database and a corresponding folder in the common experiments folder. It has a specific configuration, a unique expid and runs on a specific (or multiple) platforms.

expid

This is the unique identifier that is assigned to each experiment by Autosubmit.

job

The whole experiment run is split in several jobs. Each job is a separate script that is executed on a specific platform and performs some tasks there, e.g. creating working directories, downloading input data or running the model. Each job can depend on other jobs that have to be completed before the job can be executed. This dependency structure creates the whole workflow.

member

For each start date one or multiple members can be run. This is meant e.g. for running an ensemble of simulations (not yet implemented) but can also be used if you only want to change a single (or a few) input parameters between different simulations.

model

This usually refers to the model to be run (i.e. ICON-ART). However, autosubmit describe prints the auto-icon project as the model (Model: git@gitlab.dkrz.de:auto-icon/auto-icon.git). This has internal reasons and should not be confused.

platform

A platform is an object, where Autosubmit can run jobs on. The platform LOCAL is always defined and refers to the machine that Autosubmit runs on.
Furthermore, each HPC system (e.g. Levante, Horeka, …) is also specified as one or more platforms. Generally, Autosubmit differentiates between the login nodes and the compute nodes. If there are significantly different queues/partitions specified on an HPC system, than even more platforms might be defined, one for each queue. A list of the platforms that can be used is here.

project

This term refers to auto-icon. Within a specific experiment, the project is located in the proj/git_project subdirectory (after the first creation). Here, of course, it can be modified to adjust the configuration.

start date

Each experiment can run for several start dates that run exactly the same configuration, however for multiple different start dates, e.g. 2020-01-01, 2020-06-01, 2021-01-01 (specified as DATELIST: 20200101 20200601 20210101).

workflow

The full set of all jobs, ordered with the dependencies, gives the whole workflow.