Integrated Modelling Analysis Suite requirements on Interfaces and Link to ITER Parties

1. Integrated Modelling Analysis Suiterequirements on Interfaces and Link to ITER Parties F. Imbeaux IM Design Team, CEA IRFM 8 June 2011

2. Outline • Link to ITER Parties requirements • Interface Requirements • Hardware • Software • Communication • User Interfaces

3. Link with ITER Parties Research Institutes • The users of the IMAS will both be onsite ITER and working from sites within the Parties Institutions. External users will be working in potentially all Use Case categories foreseen for the IMAS and shall be able to access it transparently from outside • The IMAS shall be accessible from the Parties Research Institutes. For performance / scalability reasons this implies likely local installation of the IMAS in Parties Research Institutes

4. Link with ITER Parties Research Institutes • The IMAS shall be open to accept physics / technology software components from the Parties Institutions. • The component shall adhere to the IMAS Standards • Interfaces shall follow the IMAS Data Ontology requirements • The component shall undergo the same physics documentation and validation criteria as any other IMAS component

5. Link with ITER Parties Research Institutes • From Plasma Research Use Cases Scenario/campaign development, Model Validation, Model Improvement and Physics Development: • The IMAS shall have the capability to access and model experiments from other facilities. • Parties Research Institutes shall be able to store simulations results (possibly done with software outside of the IMAS) as IMAS data.

6. Link with ITER Parties Research Institutes • In order to allow for an effective collaboration on IMAS development and usage and validation, • The IMAS and its components shall be developed and maintained under a collaborative development environment

7. Hardware Interfaces • The IMAS shall be primarily run on an in-house computing hardware (initially likely a moderate size Linux cluster). The IMAS shall also be run at the ITER Parties Research Institutes, with their responsibility to provide the adequate hardware/software. • Some of the IMAS components or workflows shall require distributed / High Performance Computing, which may be outside ITER • For Plasma Operation Use Cases Pulse Planning, Pulse Execution and Plasma Reconstruction, sufficient hardware resources with guaranteed availability shall be allocated. These resources may be specifically reserved for these applications in order to guarantee to complete all calculations within the required Plasma Operation time scales • The detailed technical characteristics/requirements of the IMAS hardware are difficult to estimate 10 years ahead of ITER operation and it shall evolve during ITER operation. A plan for continued hardware upgrades for the IMAS shall be developed, depending on the Plasma Research and PCS Development strategies during the ITER construction period.

8. Software Interfaces • Software interfaces are discussed Thursday morning (general) and Friday afternoon (interface to PCS)

9. Communication Interfaces • During Pulse Execution (Live Display) and Plasma Reconstruction (Level 2), data flowing outside the POZ shall be analyzed by the IMAS in quasi-real time as they arrive in the outside POZ storage. It is assumed that this will be done with standard data access methods + synchronization / triggering information • During Pulse Execution (Live Display) and Plasma Reconstruction (Level 2), the output of the IMAS shall be available within the control room, a priori through an air gap via screens (conversely supplying data back to the POZ through the Operation Request Gatekeeper would need further justification owing to the inside POZ constraints) • For Plasma Research Use Cases mainly and maybe Plasma Operation Use Cases in the future, the IMAS shall handle communication with distributed/HPC resources • For All Use Cases, the IMAS shall GET/PUT data in the ITER database in a format which shall be recognized at the ITER project level, i.e. also outside the IMAS • Communication of data through private files shall be forbidden for traceability / reproducibility reasons

10. User Interfaces (1) • During workflow development: • Editing of the workflow, its parameters and the parameters of its components, done directly from a graphical interface or written as a script • Graphical visualization of the workflow • Link to standard debugging tools • Capability to interactively pause the workflow during its execution • visualize and edit its parameters, the workflow component parameters and any data used by the workflow during pause • resume execution with the updated parameters. Capability to resume for one "time-step" of a loop only. Capability to restart from the beginning. • Capability to insert break points to resume up to next break point (if specific workflow permits)

11. User Interfaces (2) • During workflow parameterization (by a User prior to a run): • Graphical Interface for the preparation of input data • Visualization and editing of any IMAS data, including pulse parameterization waveforms • Selection of any IMAS data to be used as input by the workflow and linking them to the workflow components that are using them • Visualization and editing of the workflow parameters and the parameters of its components. This shall be available: • In a generic and systematic form (for all the parameters of any workflow) • In a specific form (for widely used standardized workflows, simplified workflow-specific interfaces shall be developed) • Selection of the output data for final storage • Interface for parameterize the link to the PCS Simulator • Local access to the modules/parameters documentations

12. User Interfaces (3) • During workflow execution: • Workflow monitoring (at least: status of workflow parameters, which components are presently running). This shall be available both in interactive and batch modes • Log file for collecting all textual messages from the workflow • Data visualization while the workflow is running. This shall be available both in interactive and batch mode • Capability to interactively pause the workflow during its execution and to • visualize and edit its parameters, the workflow component parameters and any data used by the workflow during pause • resume execution with the updated parameters. Capability to resume for one "time-step" of the loop only. Capability to restart from the beginning. • Capability to insert break points to resume up to next break point (if specific workflow permits) • Triggering interactively specific events (e.g. pellets, ELMs, NTMs, …) shall be done using the previous requirements, i.e. activating specific parts of the workflow by interactive modification of the workflow parameters (pause, select an event, resume)

13. User Interfaces (4) • For Data Mining, a graphical interface to • Send queries to the ITER data catalogue. Typical queries could be: • All pulses (and segments) having NBI power above a given value. • All pulses having disrupted • All pulses related to a given experimental topic (as organized by the future ITER program committee) • All versions of processed data (e.g. core profiles) related to a particular pulse segment • All simulations done with a particular module related to a given pulse • All occurrences of data (at a subsystem level) related to a given pulse / simulation and/or run numbers • All validated simulated pulse segments with certain characteristics (e.g. NBI power and beta above a given value) • All pulses (and segments) with a list of diagnostics available in specified time intervals • Possibility to use several of these queries • Display tables with the reference of the data and the data itself resulting from the query • Browse and visualize any data resulting from the query • Export the output of the query in various formats (CSV, binary)