Integrating New Capabilities in Operational Space Weather Systems

Integrating New Capabilities in Operational Space Weather Systems 29 April 2009 Brian Balm Program Manager

Objective • Identify Considerations and Share Lessons Learned to Better Enable Integration of New Space Wx Capabilities into Operations – New Models and Applications – New Data Sources 2

Space Weather Model Integration Model and Application Considerations Potential Sources Sensor Data Considerations Operational Requirement Opportunity for Coupling Operational Implementation Operational Models Operations Data Timeliness Applications SCINDA SEEFS C/NOFS RADAR HFCOMM Models Output Resolution/Format Information Assurance Heliospheric Model Ionospheric Model 3 Ingest / Decode Overall Cost Target Environment Product Generation Comm Processor Product Dissemination Maintenance Concept Radiation Belt Model Thermospheric Model Magnetospheric Model Data Access Validation Approach End User Applications

Steps for Incorporation of Models into Ops Integration of models and applications typically follow a standard sequence of steps. The collection of lessons learned allow for risk identification and adjustments early in the process: Operational Requirement Identified Candidate Models and Applications are Assessed Model Selection by Operational Group Final Validation of the Model (typically by independent agency) Integration and Test into Operational Environment Operational Use of Model / Application 4

Space Weather Model Integration New Data Source Considerations Potential Sources Space Sensor Data Occultation In-situ particle Operational Requirement Existing Data Type UV Optical X-Ray Considerations Magnetometer Ground Sensor Data Format/Growth Ionospheric Sounding Radio Data Reliability Operations Operational Models Data Access Data Source Duration Data Latency Optical Operational Implementation Ingest / Decode Comm Processor Product Dissemination Compatibility Models Radiation Belt Model Thermospheric Model Magnetospheric Model Heliospheric Model Ionospheric Model 5 Overall Cost Bandwidth Required Product Generatio n End User Applications

Space Model Integration Lessons Learned • Consideration: Data Format – Product generators could not use native model output format--required a postprocessor for translation to standard output; documentation was distributed for end users – Lesson: Provide model out put in format that is readily used • Consideration: Target Environment – After initial testing, processing runs were too slow to meet ops requirements-required trade studies to identify alternatives; model developer had to modify code to optimize performance – Lesson: Learn about timing requirements and implementation environment to ease transition to operations • Consideration: Maintenance Approach – Data rights issues can result in abandoning model. Government use often involves some level of third party access; baseline control helps avoid ambiguity over data rights. – Lesson: Ensure data rights, appropriate levels of support, and a disciplined approach to configuration management are in place 6

Space Model Integration Lessons Learned • Consideration: Data Timeliness – Two auroral boundary models were installed and execute side by side; one model is used as the primary forecast model because of data latency in the other model. The other model has a better depiction of the pole-ward boundary, but data latency is not sufficient forecasting – Lesson: In initial phases of model development, consider real-time data feeds, model performance, and data latency within the concept of operations • Consideration: Opportunity for Coupling – Established, documented interfaces facilitate smooth integration. Third party developers require operational interfaces. – Lesson: Deliver structured software and accommodate user requirements in interface documentation 7

Atmospheric Model Integration Lessons Learned • Consideration: Operational Requirements – New models provide many new parameters of value to military and other planners, addressing previously unmet requirement – Lesson: Understanding the users’ concept of employment and capability priorities could multiply applications of model output • Consideration: Validation of Results – Understanding and community acceptance of new models depends critically upon clear and convincing validation of model results – Lesson: Develop quantifiable and community accepted validation rules at the start – Lesson: Follow up with the model integrator and user to support validation in the operational environment • Consideration: Opportunity for Coupling – Coupling of models speeds delivery of capability and potentially improves model performance – Lesson: Design models with likely coupling in mind, to allow easier integration with other model components and physics packages – Lesson: Modeling components that run on the same grid simplify coupling 8

Conclusion—Top Considerations – Validation: Well thought-out model validation greatly facilitates integration, testing, and operational acceptance – Data Formats: Adherence to Do. D and industry engineering standards and data formats simplifies integration and reduces cost/schedule – Data Rights: Careful consideration on data rights and licensing to include configuration management is a primary element to ensure that the model can be integrated and supported after turnover to operations – Security: Elimination of security vulnerabilities during design and implementation expands number of domains where model can be used – Cost: Attention to overall costs increases likelihood of continued use by wide range of users 9