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
1.2. The ITER Physics Data Model
- 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
1.3. Access Layer
- 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
1.4. First use case: User or code accessing Data Base through Access Layer
1.5. Interface Data Structures (IDS) to couple codes
- 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
1.6. Second use case: codes coupled together directly (same language) or through AL (different languages)
1.7. Workflow Engine and Component Generator to facilitate the development of Integrated Modelling workflows
- 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
1.8. Physics codes + Data Access wrapped into a workflow component
1.9. Workflow components coupled and executed within a workflow engine
1.10. The layered structured: from the physics solver to the launcher
- 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)
2. More details on the ITER Physics Data Model