| Table of Contents |
|---|
...
05.1.1. The ITER Physics 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
...
- Main features:unique
- Aims at being the main gate to data for scientific exploitation, both for code interfacing and hands-on data browsing
- Unique for simulated and experimental data (same data structures)
- Device-generic → usable for ITER or any other fusion device
- Precise design rules for global homogeneity
- Precise lifecycle procedure to be able to evolve and be jointly developed by multiple teams
05.1.2. Interface Data Structures (IDS)
...
05.1.2.1. Introduction
- For Integrated Modelling, the Data Model 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
Data Model: Interface Data Structure
- The Data Model has a tree structure, for the sake of clarity
- At the top level, a collection of modular structures representing
- Abstract physical quantities (e.g. distribution functions)
- Tokamak subsystems (e.g. PF systems)
- These modular structures have the appropriate granularity for exchange in an IM workflow → they also represent standardised interfaces for communication between codes, named Interface Data Structure (IDS)Each Each IDS has an “ids_properties” substructure (metadata + comments + timebase usage)
- Each IDS has a “code” substructure (trace the code-specific parameters of the code that has generated this IDS)
- Each IDS has a generic timebase (“time”)
05.1.2.2. Documentation
- Obtaining documentation
- Automatically generated (type
dd_doccommand to see list of IDSes similar to this on picture above) - Accessed on following >>page<< of EUROfusion portal (more user-friendly GUI)
- Automatically generated (type
- Description of IDS contains:
- List of all IDSs. For each of them, a detailed documentation:
- Full path name: name of all variables of the IDSs, with their path in the structure. Replace “/” by the structure operator in a programming language, e.g. “%” in Fortran, “.” in C++, Matlab, Java, Python
- Description
- Definition
- Units in []
- In {}, whether it is STATIC (constant over a range of pulses, e.g. machine configuration), CONSTANT (constant over the pulse or the simulation), or DYNAMIC (time-dependent within the pulse or the simulation)
- Data_Type: indicates whether it is a string, an integer or a real, and its dimension (0D, 1D, 2D, …)
- Coordinates: for each dimension, the full path name to the related coordinate. If the dimension simply refers to a quantity not present in the Data Model
...
- , it is indicated as “1…N”
05.1.2.3. Time "slices"
Time is of course a key physical quantity in the description of a tokamak experiment. Present day integrated modelling codes all have their workflow based on time evolution. Time has however a hybrid status because of the large differences in time scales in the various physical processes. For instance, the plasma force balance equilibrium (which yields the surface magnetic topology) or Radio Frequency wave propagation are established on very fast ime scales with respect to other processes such as macroscopic cross-field transport. Therefore such physical problems are often considered as “static” by other parts of the workflow, which need to know only their steady-state solution. In fact such a configuration appears quite often in the physics workflows: a physical object that varies with time during an experiment (e.g., the plasma equilibrium) can also be considered as a collection of static time slices, and the other modules in the workflow will need only a single static time slice of it to solve their own physical problem at a given time.
05.1.2.4. Occurrences
There can be multiple instances, or “occurrences” of a given IDS in a
...
database entry . These occurrences can correspond to different methods for computing the physical quantities of the IDS, or to different functionalities in a workflow (e.g. store initial values, prescribed values, values at next time step, …). For modelling tokamak experiments, multiple source terms are needed because many different heating/fuelling/current drive mechanisms are commonly used simultaneously. In present day integrated modelling codes, this is usually done by pre-defining in the data structure slots for each of the expected heating methods. Moreover, the way to combine these source terms is also usually pre-defined, though present codes have some possibility to tune their workflows with a set of flags – still within a pre-defined list of possible options. In view of providing a maximum flexibility of the workflow (which can also be something completely different from the usual “transport” workflows), we have to abandon this strategy and go for multiple IDS occurrences. For each physical problem we have defined a IDS type that must be used to exchange information related to this problem. While the elementary IDS structure is designed for a single time slice, we have gathered all time slices referring to the same physical object in an array of IDS time slices. This array is the unit which is manipulated when editing workflows. We now introduce the possibility to have in a workflow multiple IDS occurrences, i.e. multiple occurrences of arrays of IDSs of the same type.
We may have in the workflow an arbitrary number of particular modules, each of them producing specific output. These output IDSs must be initially clearly separated since they are produced by independent modules, therefore they are stored in multiple occurrences of the generic IDS. The various source modules may be called at different times of the workflow, this is allowed since all occurrences are independent: they can have an arbitrary number of time slices and each has its own time base.
During a workflow, multiple occurrences of IDS of the same type can be used, when there are multiple actors solving the same physical problem. In most cases, these occurrences can be used for exchanging intermediate physical data during the workflow, i.e. data that the user does not want to store in the simulation results (such as all internal time step of a transport equation solver).
By default, the IDS name without specification of the occurrence number (e.g. “equilibrium”) corresponds to occurrence “0”. IDS occurrences above the default value (occurrence “0”) are accessed by concatenating the name of the IDS with the occurrence number, with a “/” in between. For example “equilibrium/2” is the name of the occurrence number 2 of the equilibrium IDS. Note that “equilibrium/0” is not valid (temporary limitation).
In the present implementation, there is a pre-set maximum number of occurrences of a given IDS usable in a Database entry or in a workflow. This number is indicated in the documentation in the “Max. occurrence number” column of the list of IDS table. This limitation should be removed in the future
Data Model documentation
Dynamically generated
Open the documentation by typing: dd_doc
What is in the documentation ?
...
...
IDS can be used in two different ways: Homogeneous timebase or not
- The Data Model provides the flexibility that every node has its own timebase. This is mandatory to represent experimental data as it has been acquired.
- pf_active%coil(i1)%current%data(itime)
- pf_active%coil(i1)%current%time(itime)
- However, a frequent use case is that a code will provide its output IDS(s) on a unique timebase
- Therefore there is a simplifying option to use an IDS structure with a homogeneous timebase, i.e. that will apply to all dynamic nodes of the IDS. This timebase is located at the top level of every IDS
- pf_active%time
- The ids_properties/homogeneous_time flag tells whether the IDS has been written with a homogeneous (unique) timebase (1) or not (0). In the latter case, the coordinates documentation provides the information on the localisation of the timebase in the structure.
- The code writing the IDS has the responsibility of defining this parameter and fill the appropriate time coordinate(s)
IDS and time slices
- An IDS potentially contains many time slices, possibly in different time bases
- Because this is used frequently during workflows, time slicing operations are allowed by the Access Layer
- GET_SLICE returns an IDS with all time dimensions of size 1 (representing thus a single "time slice"). Dynamic signals are interpolated (different options available)
- PUT_SLICE appends the content of an IDS variable (with all time dimensions of size) to an IDS stored on disk. This allows accumulating time slices in an IDS progressively during a time loop
- More options can be added in the future
- In a Kepler workflow, only the reference of the IDS is circulating, so operations can be performed on this IDS either in SLICE mode or in FULL mode (applies to the full IDS with all time slices)
Data Entries
- A Data Entry is a collection of potentially all IDS
- Multiple occurrences of a given IDS can co-exist, e.g. multiple equilibria calculated by different codes / assumptions
- A Data Entry is defined by:
- IMAS version
- User name
- Machine name
- Pulse number
- Run number
Conclusion
...
Useful links:
- The Physics Data Model User Guide is the technical reference for using IMAS and the Access Layer. You can find it (and many other information) on https://confluence.iter.org/display/IMP
...