1. IMAS – introduction to basic concepts

1.1. Key IMAS element: the Data Model

Joint scientific exploitation of ITER by multiple teams requires a Data Model to name and communicate physical and technical information → ITER Physics Data Model
The Data Model provides information for data providers and data consumers on…
- What data exist ?
- What are they called ?
- How are they structured as seen by the user ?
IMAS components use the ITER Physics Data Model to:
- Read & Write simulation results or experimental data
- Interface codes together

Aims at being the main gate to data for scientific exploitation, both for code interfacing and hands-on data browsing
is unique for simulated and experimental data (same data structures)
is device-generic → usable for ITER or any other fusion device
has precise design rules for global homogeneity
has precise lifecycle procedure to be able to evolve and be jointly developped by multiple teams

API providing access methods (read/write) to an ITER physics Database based on the ITER Physics Data Model
Provided in Fortran, C++, Matlab, Java, Python
The only effort for using the Data Model is to map the input/output of your code to the Data Model and add some GET/PUT commands
The access methods are writing to a local database stored in your account
These local databases can be shared among users (for reading only) and can be accessed remotely

For Integrated Modelling, the Data Model also defines Interface Data Structures (IDS). These are structures within the Data Model that are used as standard interfaces between codes
Solves the N2 problem (large number of components from various ITER members expected in IMAS)
The usage of the IDSs makes the coupling of codes straightforward if they are in the same programming language
The usage of the IDSs + AL allows coupling of codes even if they are not written in the same language
The usage of the IDSs does NOT constrain your choice of coupling method. Codes can be coupled as:
- Subroutines within a main program
- Executables within a script
- Components within a workflow engine

An Integrated Modelling simulation is described as a workflow with physics codes as components (modules)
The workflow engine allows users to
- Design the workflow
- Choose its components and tune their code-specific parameters
- Execute the workflow
The workflow engine will be used to help designing sophisticated workflows (e.g. Plasma Reconstruction chain, fully modularized Transport Solver, …)
- It is intuitive enough for allowing “mere users” developping their own workflows
- It hides the complexity of code coupling, data transfer, remote job submission, …
- It allows sharing codes and workflows
- It allows coupling to the PCS Simulation Platform
Component generator: is a user tool that turns an IDS-compliant physics code into a component of the workflow

The structure is layered so that functionalities are clearly separated
It is generic and independent of e.g. the launching script/workflow engine
The Physics solver part (dark green) is not changed, it is not linked to the ITER Data Model. It may use the ITER Data Model internally or not.
The architecture is identical to the case of a component called within a workflow engine
The Physics Subroutine can be directly reused to generate a workflow component – the IMAS Infrastructure provides a tool that generates the component (pink part) automatically
Exception: for codes handling massive amounts of data, Data Access is usually parallelised and must be done inside the physics_solver (no processor has enough memory to gather all data)