ITER Needs and Requirements

1. ITER Needs and Requirements W.A. Houlberg Chief Scientific Officer, Integrated Modelling ITER Organization EU-US Workshop on Software Technologies for Integrated Modelling in Fusion Göteborg, Sweden 1-3 December 2010

2. Initial and Boundary Conditions • The seeds for the ITER IM Programme presented here were all sown by discussions in the Domestic Programmes • The ITER IM Programme is ambitious: • It is broad in scope • It entails physics objectives beyond what we are presently capable of describing with present theories or models, or have yet explored in experiments • It is designed to match the ambitions of the ITER Project • It can only be accomplished through strong collaboration between the IO and Domestic Programmes • The expectation is that Integrated Modelling will continue to mature over the ~30-year life of ITER: • The ultimate Integrated Modelling capabilities are not limited by present physics knowledge or tools • Theories, models, experimental observations and computing capabilities all will improve • We must build a framework to accommodate these improvements

3. Roles of Integrated Modelling • Applications of IM in ITER can be classified as either Plasma Operations support or Plasma Research support to identify more clearly the requirements, responsibilities, and users (customers) • Plasma Operations support: • IO has primary responsibility for development/adaptation and management – Integrated Modelling Analysis Suite (IMAS) • Available to all ITER Parties • Links to more extensive set of physics components and computing resources of the ITER Parties to enhance physics basis for planning • Plasma Research support: • ITER Parties have primary responsibility for development and validation of improved models • Many extended physics elements will remain proprietary (developmental) • Both areas require extensive collaboration between the IO and ITER Parties: • Further definition • Identification of candidate components and technologies • Implementation

4. Plasma Operations Support • Simulations applied to each ITER pulse: • Requires high reliability, computationally efficient (reduced models?) • Hundreds of physics simulation components under management of IO for use by all ITER Parties • Items in red incorporate physics models

5. Pulse Planning • Segment Simulation: • Derived from ITER’s long pulse capability • Each segment may assess a different set of conditions • Slow evolution of the toroidal current profile may create inter-dependence • Pulse Assembly: • Assumes the plasma in each segment independent of history • Include options (variations) for the operator to implement • Physics Validation: • Characterize uncertainty in the simulations • Can the PCS manage the plasma? • Output is a dataset of plasma parameters, demands on each component of the system, required diagnostic systems • Pre-Campaign System Validation: • Check whether systems demands are within expected machine capabilities (CODAC tools) • Organize pulses into daily campaigns: • Should be many more pulses than can be executed • Daily System Validation (repeat of Pre-Campaign System Validation)

6. Pulse Execution • Real-time (low latency) reconstruction: • Integral to successful execution of ITER pulses • Required for operation of the PCS in controlling the plasma • Displays of the evolution of plasma conditions and behaviour during a pulse • Live reconstruction (latency ~seconds): • Plasma reconstruction integrating results from several diagnostics for control room display superimposed on expected performance from the pulse file • Provides evaluation of the fidelity of the pulse planning, indications of unexpected behaviour, and guidance to the operator • Real-time and live reconstruction may have much overlap • Time slice analysis can provide further guidance to the operator • Forecasting (faster than real-time, long-term goal): • Launching a predictive simulation with a set of proposed actions plus initial conditions from present state • Reveals whether operating bounds may be exceeded by proposed actions • Forecasting tools must progress through validation tests

7. Plasma Reconstruction • A primary requirement for effective interpretive analysis of experimental results: • Automated system for integrated results from multiple diagnostic signals into a set of physically consistent parameters and profiles and error bars: • Generally an iterative process, constraints on time vs accuracy • May require corrections due to re-calibrations or other corrections from individual diagnostics • Higher levels of reconstruction: • Interpretative analysis of the plasma transport properties, generally requires models for the sources of particles, energy, torque and current drive, which cannot generally be measured directly, i.e. they require reuse of some of the same components used in predictive modelling • Data mining: • Searches for common characteristics • Determining operating limits from prior operation relevant to pulse validation • Detailed physics analyses, retuning of control algorithms and operation constraints, model validation and model improvement • Provides the connecting loop with the Plasma Research Support that enhances preparation for future sessions

8. Plasma Simulator • Development of a Plasma Simulator as an initial application: • Supports PCS testing of control algorithms • Provides a prototype application for development of the IM infrastructure • Can employ elementary plasma models for fast turn-around of initial test cases • Attention to extensibility will allow the PS to incorporate the comprehensive physics required for pulse simulation: • Modularity • Free boundary equilibrium • Full set of transport equations • Advanced CS methods (e.g. parallelization, grid computing) • Core, SOL, divertor and PWI • Coupling to the PCS in pulse simulation mode would: • Provide validation the that the PCS can control the pulse • Eliminate the need to employ approximations to the control system that are typically employed in predictive modelling codes • Dynamic coupling to the systems validation tools may also be envisioned

9. Testing the Plasma Control System Auxiliary Systems Diagnostics • A Plasma Simulator will act as a proxy for the tokamak to validate proposed discharges Integrated Modelling Analysis Suite Plasma Simulator Sources and Transport Models Synthetic Diagnostics Sensor Interface Actuator Interface Interface Control Module Plasma Control System

10. Validating proposed discharges • Simulation of ITER 15 MA pulse (Casper, CORSICA code) • Color – % of max coil current: • Green < 90% • Yellow > 90% • Orange > 98% • Red > 100% • ITER real-time plasma boundary software, developed by GA staff under ITER funding

11. Plasma Research Support • Design and upgrade studies: • Opportunities for design decisions diminishing, upgrade options will have to be evaluated over the longer term (see ITER Research Plan) • Scenario and campaign development: • Commissioning and scientific exploration plans in support of the IRP • Heating, fuelling and current drive strategies • Performance optimization within operational boundaries • Experiments that focus on specific physics issues • Identification of experiments on present facilities to validate model features • Model validation: • Until ITER begins operation, the only data available for model validation is produced by presently operating facilities in the domestic programmes • Model improvement: • Improved fidelity (renormalization, addition of missing physics) • Computational efficiency (note severe restrictions on clock time in many areas of operations support)

12. Plasma Research enhances Plasma Operations • Application of more advanced/detailed codes to selection of pulses: • Exploratory/developmental codes • Establish first principles basis for instability and operational bounds • Predominantly under management of ITER Parties • Require links ITER analysis suite/databases and computing grid

13. How will all this be done? • The ITER Integrated Modelling Programme is ambitious: • Models not yet tested under burning plasma conditions • Collaboration between IO and fusion community through Integrated Modelling Expert Group, International Tokamak Physics Activity, and contracts to develop/adapt suite of codes • Modelling will continue to mature over the ~30-year life of ITER: • Theories, models, experimental observations, computing • Requires modular simulation framework Development schedule: 2011 Conceptual Design 2012-2015 Plasma Simulator and infrastructure with reduced models 2015- Adapt detailed physics components, reconstruction codes, synthetic diagnostics, computing grid, …

14. ITPA and IMEG Roles • ITPA – emphasis on R&D activities: • Databases to describe plasma characteristics over a wide range of conditions, with particular emphasis on areas where theory and models provide inadequate coverage • Model development and validation against experimental observations • Projections to ITER operation using a combination of experimental observations and validated models • IMEG – emphasis on IM infrastructure: • Identification of a required core suite of in-house codes and tools for systematic prediction and analysis of every discharge and available to all ITER Members • Rely on adaptation of existing codes and tools • Core suite must be computationally efficient and well validated • Establishment of standards and guidelines for the core suite (documentation, verification, validation, modularity, maintenance, …) • Required for coordination and integration • Identification and implementation of means to link to more in-depth analysis of selected cases using codes available within the ITER Members IM Programmes • For example, more advanced physics models requiring high performance computing, new approaches to coupling physics • Definition and development of the internal and remote user environment

15. IM Infrastructure Contract – 1st Year Tasks • Conceptual Design – define functionalities of the ITER modelling infrastructure and technical solutions: • Framework for integrating physics components in a plasma simulation code • Framework for automated execution of codes for plasma reconstruction • Programming languages • Data model(s) for physics parameters and machine descriptions • Software and procedures for storing, retrieving and managing physics data • Hardware requirements for plasma modelling • User interfaces • Data visualisation tools • Standards and guidelines for documentation and traceability of physical data • Standards and guidelines for documentation and traceability of the codes and components used in a given simulation • Collaborative development tools (for ITER Party members to participate in joint development of physics software) • Remote data access and remote user access • Interfaces with software from ITER Parties running on facilities outside of the IO • Establish a timeline for development, installation, testing and the expected resource requirements of the deliverables. • Design to be reviewed by IMEG.

16. Expectations from this Workshop • The EU and US fusion programmes are addressing the software technologies that ITER will require for its IM Programme: • Integration of a full spectrum of codes to be used by a distributed community • Code management, execution, standards, data structures and communication, ... • Building a consensus among the EU and US efforts through joint assessments of these technologies will be of great benefit to ITER: • Establishes a stronger case for adoption by the other ITER Parties • First significant ITER plasma operation is expected in 2022 (H/He plasmas): • This allows plenty of time to develop and test new software technologies in parallel with improvements in the physics models and codes • The assessments must, however, accommodate the many different requirements of Plasma Operations and Plasma Research: • Robustness/exploratory • Computational efficiency/comprehensive first principles physics • Systematic execution/user steering