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