Sol-Terra: A Roadmap to Operational Sun-toEarth Space Weather Forecasting Mike Marsh1, David Jackson1, Alastair Pidgeon2, Gareth Lawrence2, Simon Reid2, Mario Bisi3, Mike Hapgood3, Yulia Bogdanova3, Jason Byrne3 1 Met Office 2 RHEA TECH 3 STFC RAL Space Sol-Terra Motivation Objective • “Develop a roadmap for the realisation of an operational end-to-end space weather forecast modelling system, and identify the main areas where further work is needed.” Context •Timeliness •Robust (24/7/365) •Verified •Evolution © Crown copyright •Quality software engineering •System/architecture •High quality service Scientific Domain Overview Owens et al., 2014 Model Review • Current space weather modelling capabilities • Scientific Background & Model Scope • Operational/Computational Aspects • Inputs & Coupling • Operational Sustainability Operational Forecast Potential Solar models © Crown copyright Heliosphere models Energetic particles Magnetosphere • Operational Constraints • Time Constraints – Computational/Data Latencies • Source Code Quality Assurance Factors • Documentation Standards Geomagnetic • Version Radiation Control (e.g. Git, Thermosphere Subversion) and neutral Ionosphere Field belts atmosphere • Error Handling • Languages, Dependencies • Verification & Ensembles Coupling Long Term Scientific Goal • “Understand the highly coupled chain of processes that link solar activity, the solar wind and the Earth’s magnetosphere to its upper atmosphere.” Forecasting Goal • Replicate this process chain with a suite of coupled models that is operationally viable Coupling © Crown copyright Gap Identification Architecture Operational System Architecture • Platforms • Distributed/cloud computing • Operational suite definition • Workflow/Scheduling © Crown copyright Operational Requirements Research 2 Operations © Crown copyright Model Transition Operational Requirements Development Practices R2O Model Uptake Research Impact Data Code • Language • Quality Assurance • Documentation • Version Control • Error Handling © Crown copyright • I/O – Traceability, Quality Check, Env • Workflow – Coupling, data xfer, optimisation • Standardisation– WMO, ISES, other? • Verification – Skill monitoring Met Office User & System Requirements User Requirements System Requirements •Robustness: models should run successively for a range of space weather conditions and handle errors appropriately and informatively, allowing operational service and IT support teams to understand and resolve problems. •Forecast Cycle: The model should run fast enough to be used within a forecasting cycle excluding data latencies (varies by domain and conditions). •Quality Assurance: High standard of code structure, documentation, error handling and version control allowing systematic model management i.e. perform acceptance tests, reviewing procedure for code changes and allow operational service and IT support teams to resolve problems. •Environment: Developed using appropriate operating system of operational centre (for Met Office this is Linux operating system). •Language: Source code available and model written in appropriate language (for Met Office this is Fortran, Python or Java. C and IDL may also be acceptable for critical models, however with lower operational support). •Licensing: License, IPR and terms of use for model and input data should be appropriate and obtainable. •Efficiency: Unless model is computationally very cheap, code should be parallelised to ensure HPC operation (supported OpenMP and MPI protocols). •Resilience: Fall back option of using a simpler configuration, other initialisation, repeat forecast, or alternative input data source to maintain continuous forecasting capability (e.g. solar or geomagnetic drivers as input) in case of technical issues (e.g. data availability). •Dependencies: Models should not have dependencies on nonstandard libraries not under the operational centre control (e.g. SolarSoft). •Coupling: Model should be suitable for coupling to other appropriate models with compatible boundary conditions and input/output parameters. • Timeliness: Data assimilated (NRT) and forecasts produced in a timely manner. • Data Model: Models should be data drivenUser rather than climatology. Space Weather • User Documentation: High standard of user Space Weather Operations documentation, describing model overview, Operational input/outputCentre and limitations on validity. Meteorologist • Evaluation: Model statistical verification skill (MOSWOC) scores defined to inform forecaster interpretation. Skill scores available to benchmark impact of replacing standalone model with coupled model, or to benchmark model upgrades. • Ensembles: Ensemble operation possible (unless deterministic models are shown to perform better). • Autonomy: Models should have the potential to run automatically, without human intervention, producing output for forecaster assessment. © Crown copyright System MOSWOC Infrastructure Sol-Terra Outputs/Impacts Synthesis of Domain Model Reviews • Identify gaps in capability/Areas of further development • Future research needs • Roadmap for coupled proto-operational forecast system Impacts • Capability of current space weather models to contribute to coupled operational suite • Requirements for R2O • Knowledge gaps academic community • Awareness of operational issues enabling R2O Impact © Crown copyright Improved Science Research Funding Research R2O Operations Research Impact © Crown copyright