Implementing an Interactive Simulation Data Pipeline for Space Weather Visualization

Department of Science and Technology

Institutionen för teknik och naturvetenskap

LIU-ITN-TEK-A-018/044--SE

Implementing an Interactive

Simulation Data Pipeline for

Space Weather Visualization

Matthias Berg

Jonathan Grangien

LIU-ITN-TEK-A-018/044--SE

Implementing an Interactive

Simulation Data Pipeline for

Space Weather Visualization

Examensarbete utfört i Medieteknik

vid Tekniska högskolan vid

Linköpings universitet

Matthias Berg

Jonathan Grangien

Handledare Emil Axelsson

Examinator Anders Ynnerman

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga

extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida

http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page:

http://www.ep.liu.se/

Linköpings universitet

Linköping University | Faculty of Natural Sciences

Master thesis, 30 ECTS | Media Technology and Engineering

202018 | LIU-ITN/LITH-EX-A--2018/001--SE

Implementing an Interactive

Simulation Data Pipeline for

Space Weather Visualization

Jonathan Grangien

Matthias Berg

Supervisor : Emil Axelsson Examiner : Anders Ynnerman

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c

Jonathan Grangien Matthias Berg

Abstract

This thesis details work carried out by two students working as contractors at the Commu-nity Coordinated Modelling Center at Goddard Space Flight Center of the National Aero-nautics and Space Administration. The thesis is made possible by and aims to contribute to the OpenSpace project.

The first track of the work implemented is the handling of and putting together new data for a visualization of coronal mass ejections in OpenSpace. The new data allows for observation of coronal mass ejections at their origin by the surface of the Sun, whereas previous data visualized them from 30 solar radii out from the Sun and outwards. Pre-viously implemented visualization techniques are used together to visualize different vol-ume data and fieldlines, which together with a synoptic magnetogram of the Sun gives a multi-layered visualization.

The second track is an experimental implementation of a generalized and less user involved process for getting new data into OpenSpace, with a priority on volume data as that was a subject of experience.

The results show a space weather model visualization, and how one such model can be adapted to fit within the parameters of the OpenSpace project. Additionally, the results show how a GUI connected to a series of background events can form a data pipeline to make complicated space weather models more easily available.

Acknowledgments

The authors would like to extend a big thank you to professor Anders Ynnerman for the amazing opportunity and experience of working with OpenSpace abroad at NASA. Thank you Emil for coordinating, introducing us to OpenSpace, helping us with logistical matters, and guiding us through the project. It has been a very interesting time made possible by you and for that we are ever grateful.

Thank you Dr. Alexander Bock for helping us with many questions on Slack when we needed help and you were in the same time zone. You were always extremely helpful and seemingly all-knowing.

Thank you Masha for receiving us with a warm welcome and caring so much about us during our stay. Thank you Leila, for helping and guiding us throughout our stay even though you were so busy and had so much to do all the time. Asher – thank you for the help, and also Rick, Justin, Chiu, Chistine, thank you for all the lunch and board games company, it was always something to look forward to during the day.

Neel, you were a great friend in DC and in the office. Thank you for all the discussions and suggestions even though you were not an official connection, it was very pleasant. Thank you for hanging out, driving us sometimes and sharing laughs with us, and a huge thanks for helping us find a living situation in DC that not only was affordable, but really made our stay something else. Good luck with everything.

Doctors Temkin, Bahtia, and Drachman, may your research prosper and your IT issues be few. Your intelligent conversations were very interesting and your esteemed histories at NASA are very inspiring.

Finally, a warmest thank you to Rahul, Claire, Matt, John, Jonah and the rest of the Wakpack family for putting up with us and letting us experience DC with all of you. You made our stay eventful, bright and joyful. We will not soon forget our adventures to Tropicalia and Madams Organ, just to name a few, and our brunch endeavours at Hugo’s. We will not forget Landmines and Two Friends. Our stay was truly wonderful thanks to all of you. Thank you.

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Research questions . . . 2 2 Background 3 2.1 OpenSpace . . . 3

2.2 Community Coordinated Modelling Center . . . 4

2.3 Space weather . . . 4

2.4 CME data . . . 6

2.5 Space weather models . . . 6

2.6 Building upon previous work . . . 7

3 Related work 8 3.1 Exploring CMEs with OpenSpace . . . 8

3.2 Bringing OpenSpace to a wider audience with GUI development . . . 8

3.3 Volume rendering . . . 9

3.4 iSWA . . . 9

3.5 Kameleon Live . . . 9

4 Visualization of the MAS Model 11 4.1 Data format and conversion . . . 11

4.2 Adapting the data . . . 11

4.3 Different data together in a visualization . . . 13

4.4 Observing the CME . . . 15

5 Pipeline 16 5.1 Design of the front end . . . 16

5.2 Transfer function preset selector . . . 18

5.3 Implementation Overview . . . 19

5.4 Output . . . 20

6 Results 22 6.1 Visualization of the MAS model . . . 22

7 Discussion 26

7.1 Results . . . 26

7.2 Method . . . 27

7.3 Do One Thing and Do It Well . . . 28

7.4 The work in a wider context . . . 28

8 Conclusion 30 8.1 Future Work . . . 31

List of Figures

2.1 A CME during its blast into space, taken by the SOHO spacecraft on February 27, 2000 . . . 5 3.1 A screenshot of an animation showing an alert of a space weather event . . . 9 3.2 Screenshot of the upper part of Kameleon Live where the user selects data and

views some information of it. A part of the plotted data is shown. . . 10 3.3 Screenshot of the slice configuration part of Kameleon Live . . . 10 4.1 Screenshots taken of two different files with different time stamps being rendered

within OpenSpace. The left image shows a correctly formatted file and the right image shows what an erroneous file looked like. . . 12 4.2 Two images of the same time step in the volume data sequence. The left is the

density (ρ) as it is in the data, the right is the density multiplied with r2, the radial unit to the power of two. . . 12 4.3 A time step of the CME visualized where the Sun is toggled off, making it apparent

that the data the Solar body normally obstructs have been removed. . . 13 4.4 One time step of the CME with density and temperature toggled on. The

temper-ature has burst outwards and the density is following, appearing to “push” the temperature forward. The magnetogram is projected on the model of the Sun. . . . 13 4.5 The three magnetogram textures implemented in the visualization. From top to

bottom they are filtered at field strength of 20G, 100G, and 1000G respectively. . . . 14 5.1 Small component that the user first interacts with. The component is rendered

after the user clicks “DATA LOADER” in the bottom bar menu. . . 17 5.2 Visual representation of the main functionality and the communication in the

pipeline. . . 19 6.1 Fieldlines forming the magnetic flux rope using data from the bastille day event

in OpenSpace. . . 22 6.2 The MAS model density visualization of the bastille day event CME with

corre-sponding fieldlines in OpenSpace. . . 23 6.3 The temperature visualization of the Bastille day event CME in the beginning,

middle and the end of the simulation time when viewed from left to right. . . 23 6.4 How the visualization was observed by scientists. The idea is to start by looking

close up at the flux rope, then angled from the side, zoom out as the visualization is played out. . . 24 6.5 The GUI window that the user interacts with to prepare volume data. . . 25

1

|

Introduction

This thesis is carried out at the National Aeronautics and Space Administration (NASA) and is implemented within the scope of OpenSpace. OpenSpace is an open source project devel-oped with aims to accurately simulate and visualize the known universe, and portray space phenomenon and missions for public disseminations. More information about OpenSpace is presented in section 2.1. This chapter gives an introduction to the thesis by describing the motivation and underlying purpose behind the work.

1.1

Motivation

OpenSpace is an application that allows the user to interact with space phenomena and vi-sualized data in a three dimensional perspective. This is useful as many scientists today primarily visualize e.g. space weather data in two dimensions, and in some cases the added perspective can contribute understanding and appreciation for the data.

However, many non-developer users have difficulties using the application. The appli-cation is developer friendly in a way that the code base is modularized and designed with an script file system where the developer can write script files in the Lua language to call functionality from the engine to render data. To be able to write these files a certain knowl-edge of the engine and the scripting system is required. In addition, certain types of data, i.e. volume data, need to be formatted to efficiently rendered in OpenSpace. This is done with a command line interface (CLI) based system, where the developer writes a script file and runs a CLI program to execute it.

OpenSpace has been demoed to Scientists and researchers at NASA Goddard Space Flight Center (GSFC) and researchers at the CCMC workshop in April 2018. They express interest to use OpenSpace in research or for demonstration purposes, but also express a need for a better user experience. If OpenSpace is more intuitive to use, its adaptation among scientists could be more widespread, and consequently support for the project could be increased.

Certain thesis projects have and are working with ways to increase the general user friend-liness in different scopes of the OpenSpace application; more details are provided in section 3.

This leads to the problem specification of this thesis work. New data was provided with the request to visualize it in OpenSpace. This was data of the MAS model, researched, cal-culated and provided by Predictive Science Inc, a research company based in San Diego that cooperates with NASA. Implementing this data in the software is a study of what difficulties and implementation issues can be encountered when simulations different to ones previously visualized in OpenSpace are implemented. To experiment with how to get around these is-sues, we propose a concept to streamline this process for general users, where a graphical user interface (GUI) tailored to the subject data and to the typical users is researched, and a pipeline that converts data and provides the interface with relevant parameters is imple-mented. The ideal outcome of the experiment is that the user does not need to interact with the software specific code base and to get stuck on issues, but rather interact solely with the GUI when getting the subject data into OpenSpace and having it rendered in a visualization.

1.2. Aim

1.2

Aim

The aim of the thesis is to conduct a study in implementing a certain data set of space weather data for visualization in the three-dimensional simulation software OpenSpace, and to then use insights thereof to propose an experimental contribution. The results of the study itself is a contribution of a space weather visualization of particular subject data in OpenSpace. The goal with the experimental contribution is to research how to get around discovered problems in a way that becomes streamlined for the user, and to experiment with how to simplify the process of importing and handling new space weather data in OpenSpace.

The reduction in the amount of steps for taking new volume data and getting it visualized can be one of several different steps in making OpenSpace more accessible for the scientists at NASA. A primary goal of doing so is to incorporate the daily usage of OpenSpace more and more for the CCMC-group.

1.3

Research questions

To support and realize the aim of the thesis, the following research questions have been for-mulated.

1. What data adaption steps are required for visualizing an arbitrary space weather data model in a three-dimensional simulation software?

2. What components and data specific parameters are important for the design of a graph-ical user interface that lets the user interact with volumetric data of a space weather model?

3. How can an infrastructure of a data pipeline in a three-dimensional visualization software be realized so that streamlined handling and formatting of research data is achieved?

2

|

Background

This section provides background necessary for better understanding the work of this the-sis. Presented here is information of the OpenSpace software, the collaboration between Linköping University and the scientists at NASA and the underlying theory of space weather.

2.1

OpenSpace

OpenSpace is an open-source multidimensional astro-visualization platform. [1] [2] It aims to simulate and visualize the known universe by portraying phenomena like space weather and space missions, across the astronomical scale differences. The scale of things – the vast differences in distance and sizes – in astro-visualization software can be problematic due to naturally occurring large values hitting the floating point precision limits. OpenSpace circumvents this with a method that dynamically assigns frames of references for different spatial systems to provide the highest possible numerical precision for all objects. [3]

Development of the OpenSpace started at Linköping University, Sweden, and eventually gained funding and partnerships with the American Museum of National History in New York, NASA, the New York University and the University of Utah, to name a few. Devel-opment of the project has been driven by Master’s students, researchers, and full time de-velopers. The project is an open source successor to the preceding commercialized software Uniview. [4]

Visualization of scientific data for public dissemination

By visualizing data from NASA space missions and other sources, OpenSpace helps bridge the gap between scientific research and the public dissemination of it. [5] The public is in-formed and educated through story-telling and guided exploration in an interactive experi-ence. An example of data from a space mission visualized for the public is the internationally broadcast public dissemination of the 2015 Pluto flyby mission, where OpenSpace was used to visualize the New Horizons space craft and the functions of its instruments as it observed Pluto. [6]

The software can be used to explore planetary surfaces for which data exists using an implementation of planetary mapping. [7] Streamed from online sources, the images are ac-quired dynamically and processed to derive height data. As a resulting example, OpenSpace has been used to visit the surface of Mars down to meter-scale in immersive environments, giving the viewers the experience of interactively visiting the surface of another planet through simulation.

OpenSpace implements several techniques for visualizing space weather data, like direct

volume renderingand volume ray casting, both of which we describe in section 3.3.

Asset system

An asset system is implemented in OpenSpace to allow for users to add objects in the rendered scene. OpenSpace provides an interface for objects that exist in the scene with classes written

2.2. Community Coordinated Modelling Center in C++. These classes take as input parameters properties, a term for engine-wide variables. An asset file is a file written in the script language Lua, that contains a description of an instance of these classes by setting properties. The asset can then be loaded into the rendered scene on application start, or be added and removed during run-time.

Module system

OpenSpace applies a module system for each of its main features. Not all modules are re-quired for compiling the software which simplifies matters for developers as they can choose what modules can be excluded when compiling the program.

Properties and communication

The aforementioned engine-wide variables called properties can be set and updated from script files. A property is an extension of member variables that have unique identifiers, and the owners of properties are managed in a tree structure for dynamic access. A property has a list of callbacks that update listeners whenever the property variable value is changed.

OpenSpace uses a GUI built on web tools in order to provide more flexibility and easier utilities for GUI developers to work with than native tools can provide. The web GUI in OpenSpace is run as a JavaScript instance, and on the web GUI side, properties are read as they are updated by socket communication attached to the callbacks. The web GUI is built with the React library for JavaScript, which is designed to provide powerful way to develop complex user interfaces. [8]

The socket communication can handle JSON serialized data, which lets the developer implement functionality to send scripts made from the web GUI JavaScript side, to the C++ engine where they are queued to be executed. The scripts can be used to call functions in a module that are exposed via OpenSpace’s Lua API.

2.2

Community Coordinated Modelling Center

OpenSpace is collaborating with The Community Coordinated Modelling Center (CCMC) at the NASA GSFC. CCMC is a group of scientists and software developers at GSFC devoted to providing the scientific community with modern research models related to space weather. These models are used to study space weather and its complex physics, and the models are maintained by CCMC.

2.3

Space weather

Space weather is described by the US National Space Weather Program like so:

Space weather refers to conditions on the Sun and in the solar wind, magneto-sphere, ionomagneto-sphere, and thermosphere that can influence the performance and reliability of space-borne and ground-based technological systems and can en-danger human health. Adverse conditions in the space environment can cause disruption of satellite operations, communications, navigation, and electric power distribution grids, leading to a variety of socioeconomic losses. [9]

While Earth’s magnetospheric dynamics and galactic sources play an import role, almost all space weather phenomena refer to activity where the Sun is the source. [9] This implies eruptive solar phenomena like solar wind, solar flares, and coronal mass ejections (CME). Other phenomena are cosmic rays, and activity in the magnetosphere and the ionosphere. This activity can have a dangerous impact on technology both on and above the ground on Earth, and humans in space and high altitudes.

2.3. Space weather The physics of space weather is plasma physics. [9] The range of time scales can vary from the approximate 10´9_sof plasma fluctuations in the solar atmosphere to the 108_sof a full

so-lar cycle, while relevant spatial scales vary from the 1m scale of ionospheric plasma structures to the 108mscale of large-scale interplanetary plasma structures. When forecasting space weather there is a strong coupling between these scales, which makes it extremely challeng-ing.

Solar flares are large eruptions of energy. Energy released by flares can be that of the order of 1025_{J in scope. For comparison, the world’s annual energy consumption is about 10}20_J.

In flares, free magnetic energy is converted into heat, non-thermal particle acceleration and electromagnetic radiation. X-ray, Extreme Ultraviolet, and radio emissions as well as solar energetic particles are generated. These particles and emissions can all have space weather consequences. More details on consequences below.

With large solar flares, coronal mass ejections often follow, although CMEs can occur in-dependently. [10] The corona, the outer solar atmosphere, is structured by strong magnetic fields, and a CME is a release of billions of tons of bubbles and gas when magnetic fields are closed. This happens in correlation to regions of strong sun spots on the solar surface, which are caused by magnetic field flux. The corona material that is ejected at high speeds might then impact planets or spacecraft in its path. The total kinetic energy of a CME can be of the order of 1025_J.

Close to the solar surface, magnetic loops of flux can be observed. This is because flux goes out from a region of the solar surface where the magnetic pole is of one end of the spectrum, and back into a region where the magnetic pole is of the other end. These are called flux

ropes. In the beginning of a CME, a tight and small flux rope close to the surface can be observed. [11] As the CME occurs, this flux rope expands and the flux that goes between regions can no longer be held together and bursts as matter is flung outwards.

Figure 2.1: A CME during its blast into space, taken by the SOHO spacecraft on February 27, 2000 [10]

While space weather is the cause of the visually pleasant effect of the northern lights, it can have severe consequences. [9] Energetic charged particle acceleration can penetrate space suits and kill astronauts, making space weather forecasts essential to space walks. Airline passenger safety at high altitudes and the communication with the airplanes could also be compromised, which is why regions of the northern hemisphere of the Earth where the mag-netic field is strong are often avoided. If high amounts of energy damages satellites or space-craft it can compromise our GPS technology, which not only relates to digital maps but also is necessary for the credit card transaction system. Power grid systems on Earth can be dam-aged by geomagnetically induced currents that can be a hazard to the long conductor systems on the ground.

Forecasting and analyzing space weather is important to prepare humanity for these kinds of consequences. NASA launched in 2006 the STEREO A and STEREO B spacecrafts (“Ahead” and “Behind” respectively), that orbit along Earth’s orbit, one ahead of it and one trailing behind. [12] These spacecrafts take daily stereoscopic images of the Sun and provide

2.4. CME data its corona daily is the Solar and Heliospheric Observatory (SOHO). An example of a study of the corona can be seen in figure 2.3, which is a coronagraph image. A coronagraph image is obtained when an instrument places an object to block out the direct light from a star, making it possible for the image to collect light from the star’s surroundings.

2.4

CME data

A three dimensional visualization of a CME can be implemented with volumetric data. A visualization algorithm like a ray marcher can traverse rays through the data and sample it, computing a resulting color for the pixel on the screen. Rendered data of scalar field points is henceforth referred to as a volume. Data of the magnetic field is rendered as fieldlines, a non-physical representation of the structure of the field. Fieldlines are simply lines traced from a set of data and would typcially visualize the structure of the density of a CME. While they are not physical, they are useful as they can visualize the flow of the phenomenon; the mass of a CME propagates in different directions. A visualization of fieldlines close to the Sun is preferrably done coupled with a synoptic magnetogram. A magnetogram of the Sun visualizes positive and negative regions of magnetic flow on the surface, typically in two contrasting colors. Fieldlines can visualize how the mass flows out from positive regions and either leaves the corona, or goes back in to the negative regions, where the ones that go back in make up flux ropes mentioned earlier. Fieldlines are good for visualizing the flux ropes, as you clearly see lines looping in and out from the surface.

At CCMC, volume data for CMEs are typically stored in NASA GSFC’s Common Data Format (CDF). [13] CDF is a data format for storage of scalar and multidimensional data. There is a software suite called Kameleon that can read and manipulate CDF formatted files [14]. Kameleon been in development at CCMC to handle input and output formats for space weather model data and has a high-level interface for interpolating said data.

2.5

Space weather models

Physics in the different parts of the heliosphere works in different ways, and therefore there is a need for different scientific models of it. The Magnetohydrodynamics Around a Sphere (MAS) model described in detail in this report can visualize physics close to the solar surface and up to 30 solar radii outwards. To go further out from the sun than 30 radii the ENLIL model would be used. To visualize solar physics around planet Earth to show how space weather interacts with Earth’s magnetic field, the BATS’R’US model is instead useful.

A CME with the MAS model

As mentioned in section 1.1, a new run of the MAS model has been calculated by Predictive Science Inc (PredSci), and was provided to CCMC with aims of visualizing it in OpenSpace. The MAS model aims to study the large-scale structure and physical dynamics of the solar corona, and its usefulness is in how close to the solar surface it simulates. [15] Visualizing the corona of the sun is interesting in part because much of it is unknown, for instance why the corona is many orders of magnitude hotter than the solar surface itself. NASA’s ongoing Parker Solar Probe mission may provide answers to scientific questions about the corona and the MAS model may be interesting for relevant visualization tools.

While the MAS model has been under development for a couple of decades, this re-cent data is an innovative magnetohydrodynamic (MHD) simulation of a particularly strong CME, that simulates the magnetically stable equilibrium before the CME occurs, and then how the eruption is initially triggered and continues in vast proportions. [16] The simulation allows us to observe the CME at its origin and initial state. At the time of this work, this simulation has only been visualized in two dimensions.

2.6. Building upon previous work The subject of the simulation is the Bastille Day event on July 14th, 2000. On this day, the sun had a powerful solar flare during solar maximum (period of high activity), after which followed a CME. [17] This is one of the greatest CME:s observed and it caused a strong geomagnetic storm on Earth as it hit the planet. Because of this magnitude of this event, it has been studied substantially and used as an example CME is different applications. Examples with great magnitude are interesting because of the challenges the measured data provide and also to serve as reminder of implications such events can have. Thus the Bastille day was chosen by PredSci as the subject for the detailed and time variant data of the MAS model run.

2.6

Building upon previous work

The theory behind space weather and why it is important to study, and therefore visualize, has been covered. OpenSpace has been used to visualize space weather before, and this work deals with new subject data and a way to help bring visualizing space weather in OpenSpace to wider audiences. As such, this work is connected to and made possible by work done to research and implement features in OpenSpace before it.

3

|

Related work

This chapter reviews other work that theory of this thesis will build upon or take into con-sideration. Some work looked at is on rendering methods and algorithms for visualizing space weather in OpenSpace. There is also a relation to projects that developed features that improve user experience in various ways. Lastly, work that is not OpenSpace but relates to space weather visualization in applications is described.

3.1

Exploring CMEs with OpenSpace

CME:s have been visualized in OpenSpace for the sake of public dissemination of space weather. ENLIL model data have been rendered with volume rendering together with images from the SOHO and STEREO space crafts in the visualization. [18] This allows the observer to compare the velocities of the volume rendering of the CMEs as they are seen directly from the instruments of the observing space crafts, providing context and validity to the visualization. Due to these comparisons and the three-dimensional environment, the public is presented with a more accessible way to disseminate the data. This allowed reaching a broad audience for the scientific research and discoveries.

As an example, a visualization of a CME with the ENLIL model looked at the magnetic structure visualized as fieldlines as the CME propagated from the Sun. The data of the CME starts from 30 solar radii out from the Sun and out in the solar system, showing how in hits Earth. The data worked with in the work detailed in this thesis paper deals with that inner part around the Sun that is missing.

3.2

Bringing OpenSpace to a wider audience with GUI development

Previous thesis projects carried out by students have been aimed at improving the general usability of OpenSpace. One project in particular is Eskilson’s implementation of an inte-grated web GUI in OpenSpace with tools like Chrome Embedded Framework and React. [19] This project paved the way for future work as it laid grounds for implementing interfaces in a flexible and powerful developer environment.

Another project that is yet to be published at the time of writing this report is one that worked on implementing a transfer function editor, which was done with the web GUI tools to allow users to interactively create and edit transfer functions for volume data in realtime. This project fits together with the subject project of this thesis, as different volume data sets require different transfer functions, and it fits well into a pipeline that brings in new data into the render scene via the GUI to also have the ability to create and edit the transfer functions.

A project that also makes use of the web GUI to bring OpenSpace to a wider audience is the one of Johansson and Khullar. [20] It implements a touch GUI, where features of OpenSpace are put together into different storytelling sessions with an intuitive GUI devel-oped for touch board hardware. This is related in scope to the subject project of this thesis in that it is to make the application more usable with the help of interfaces.

3.3. Volume rendering

Figure 3.1: A screenshot of an animation showing an alert of a space weather event [25]

3.3

Volume rendering

Previous work for OpenSpace has implemented direct volume rendering, with both cartesian and spherical volume ray casting, to visualize volume data. Direct volume rendering is the family of methods that render volume data directly without the process of first converting the data into a finite surface representation. Algorithms that do the latter take a long time to compute, and the results are finite and static.

Direct volume rendering was first implemented for CMEs outside of the scope of OpenSpace by Sand and Törnros. [21][22] It was later integrated in the software by Axels-son and Forsyth-Rosin. [23]

The volume ray casting alogrithm is used for direct volume rendering of space weather data. To go from data values to pixel color with ray casting, a non-physical ray for each pixel is projected from the camera into the scene. As the ray passes through the volume data at a set step size it gathers color intensity values from the data. These values are added up and result in a final color for the pixel of the rendered image. The BATS’R’US model uses a cartesian grid system, but some models like ENLIL and MAS use non-cartesian grids. Ordinary ray casting will then result in a distorted image.

3.4

iSWA

A system used daily to look at visualizations of space weather data at CCMC is the iNtegrated Space Weather Analysis System (iSWA). [24] This is a dissemination software system used by experts that do forecasting. The system plots and graphs data from space weather models in two-dimensional visualizations. An example can be seen in figure 3.1. Many scientists only look at two-dimensionally plotted data and express interest in browsing the same data in three dimensions, where OpenSpace is of use.

3.5

Kameleon Live

Kameleon Live is a software currently under development at CCMC as of writing this docu-ment. [26] The software is a web application that makes visualizations and analysis of CCMC model data with a cloud service in the web browser. The tool is meant to be able to be used by scientists to upload CCMC model data and get a fast look at what the data looks like in interactive mathematical plots. It is also for education purposes; the tool has been presented at a space simulation summer school. There is a set of data ready to browse in the tool so that external data is not necessary.

The tool is related to how interfaces for exploring CCMC model data can be designed. The fact that this is a modern tool in use at CCMC makes it valuable for comparison. In

3.5. Kameleon Live

Figure 3.2: Screenshot of the upper part of Kameleon Live where the user selects data and views some information of it. A part of the plotted data is shown.

Figure 3.3: Screenshot of the slice configuration part of Kameleon Live

development of the tool certain design decisions have been made like slider UI components for selecting values in certain ranges, and how and what model information is presented. As one aim of this thesis report is to explore options for a GUI suitable for OpenSpace that deals with the same kind of data, it is relevant to compare with Kameleon Live. Kameleon Live also allows the user to slice in the data interactively by configuring slices with corresponding color scales.

Figure 3.2 shows the top part of the Kameleon Live application. The user would start in-teracting with the page here by selecting data from the dropdown menu and seeing it plotted out. We see information about the model: The name of the model, the type of data whether spherical or cartesian, and the variables of the coordinate system. This information is derived from the variables of the model data CDF file.

Figure 3.3 shows the part of the application where a slice is configured. This area is mostly full of options. For setting the ranges of the data dimensions R, LAT and LON, slider UI components are chosen. These are suitable for the interactiveness of the application, because even though the application might be slow to render updates of the slider values, a user will have the visual feedback of what value was tried in relevance to the full range of values. Considered just as an input element the sliders do give visual feedback of what the minimum and maximum values are, but if the user wants to set an exact value they might be finicky. This is a design decision that implementation of a GUI for the thesis project may take into consideration.

4

|

Visualization of the MAS Model

A part of the implemented work is visualizing a recent simulation of the Bastille Day event CME in OpenSpace. The simulation is an expensive calculation based on the MAS model of the event produced by PredSci, and because of its different nature compared to CME:s previously shown in OpenSpace, CCMC has expressed interest have it visualized in the same interactive and explorative way. Thus, we want to handle the data of this simulation to allow for usage in OpenSpace.

The data is time variant and consists of several variables in three dimensions for different physical properties and it varies with the recorded time steps. Perhaps the most prominent variable to visualize is the density, rho. The density shows the mass of corona particles that are propagated outwards in the CME.

4.1

Data format and conversion

The data needed to be converted in order to be used. The volume data is presented in spher-ical coordinates on a non-uniform grid. The volume data was given in hdf4 format, and had to be converted to the CDF format as that is what is handled by Kameleon. This was done at CCMC using scripts in the idl language. The different traces for the fieldline data were given as .dat files and were converted to JSON format. The fieldline renderer module in OpenSpace can handle the JSON format but does so with slower performance than necessary as the data is converted into binary output. However, this binary output can be saved during run-time in the first run of the data, and is from then on used directly.

4.2

Adapting the data

The data was adapted to be represented better in OpenSpace. This included leaving out cer-tain timesteps, excluding parts of the data now shown, and representing density differently.

Time stamps and removal of erroneous time steps

Time stamps were recorded in the fieldline data while they were not in the volume data. However, each file in both data sets were numbered accordingly as to what part in the se-quence they are in. A script was written and executed that wrote the time stamps from the fieldline time steps to the corresponding volume data time steps.

After the volume data had been converted from hdf4 files to CDF files at CCMC, it was noticed during visualization that some time steps in the volume data were erroneous. These time steps had values for the density variable that were too high, resulting in a full boundary box in the visualization. It is possible that data was corrupted during the conversion. It was decided with staff at CCMC that a certain number of steps in the sequence are preferable to show in a visualization as after a certain point the boundary of the calculated data can be seen clearly and appear too artificial. This was beneficial for handling the erroneous data as the faulty time steps were mostly towards the end of the sequence, which could now be cut off. Of the remaining time steps not too many were faulty so they were simply excluded from

4.2. Adapting the data

Figure 4.1: Screenshots taken of two different files with different time stamps being rendered within OpenSpace. The left image shows a correctly formatted file and the right image shows what an erroneous file looked like.

the visualization, allowing whatever previous time step data there was to be shown over the removed faulty one. Figure 4.1 shows a comparison between a correct and incorrect time stamp.

Multiplication with

r

for density data

Visualizing the density variable in the volume data directly gives a visualization where the volume gradually decreases in density the further it goes away from the sun. This is physi-cally true, but does not show where particular regions of density come from out of the solar surface as they are propelled outwards. A popular way to visualize density is therefore to, for each density point ρ, multiply the value by the spherical radius coordinate r, i.e. ρ ¨ r2. This keeps the value consistent for the density regions as they are propelled outwards, which allows the observer to see how the body of the volume travels and for a given point further out from the sun, where it came from on the surface.

Figure 4.2: Two images of the same time step in the volume data sequence. The left is the density (ρ) as it is in the data, the right is the density multiplied with r2_{, the radial unit to the}

power of two.

High density within solar radius removed

The MAS model handles data close to the Sun, and provides a high density of data points within the body of the Sun, given that a model of the Sun is also rendered in the graphical scene. As the body of the Sun is visualized in our implementation, these data points will not

4.3. Different data together in a visualization be visible, and they are therefore removed to spare the ray caster from sampling those dense and high value points.

Figure 4.3: A time step of the CME visualized where the Sun is toggled off, making it apparent that the data the Solar body normally obstructs have been removed.

4.3

Different data together in a visualization

The CDF volume files were read with the Kameleon module to be visualized in OpenSpace. From the volume data, the variables density (rho) and temperature (T) were used. Veloc-ity data would also be of interest but a conversion that was done failed to give an accurate looking result. Multiple variables like the density and temperature put together in the vi-sualization can give value as the different quantities give context to each other. In our case, the way the temperature behaves was deemed to look non-physical by scientists, which is further discussed in section 7.1. Fieldlines are also rendered together with the volume quan-tities. The fieldlines visualize the magnetic field of the sun, and as the eruption occurs, they wrap around the density volume propelling outwards.

Figure 4.4: One time step of the CME with density and temperature toggled on. The temper-ature has burst outwards and the density is following, appearing to “push” the tempertemper-ature forward. The magnetogram is projected on the model of the Sun.

Textures of the synoptic magnetogram of the sun were requested from PredSci. The mag-netogram was generated with the model software using the Br variable of the data. The

4.3. Different data together in a visualization

Figure 4.5: The three magnetogram textures implemented in the visualization. From top to bottom they are filtered at field strength of 20G, 100G, and 1000G respectively.

magnetic regions are aligned with where the sunspots are located. The magnetogram is use-ful together with the fieldline visualization. As explained in section 2.4, some lines go out of the positive regions and back in to the negative regions, while other lines go out too far to come back and radiate outwards. These lines visualize the structure of the volume and the magnetic field.

The magnetogram is also time variant, but as opposed to the activity of the CME, during the few hours that the simulation is recorded little change in the visual appearance of the magnetogram would be seen. Therefore only one time step of the magnetogram (a single texture) from during the CME is used.

Three different versions of the magnetogram were provided, where the magnetic field is filtered at the strength of 20G, 100G and 1000G respectively, where G is the cgs unit gauss used to measure magnetic flux density. With a way to toggle the different textures with the press of a button, this allows us to better see the magnetic regions from far away in 3D space in the visualization, and to see a high resolution of smaller regions close to the flux rope in the beginning of the CME up close. See figure 4.5 for reference.

The textures were projected on the surface of the Sun sphere model and aligned with the data. In the time steps leading up to the eruption of the CME, a small flux rope on the surface can be observed, as described in section 2.4. The authors of the simulation inserted traces of a flux rope here as it is the source region for the CME. [16] The CME begins as a small shift in magnetic activity which destabilizes the flux rope and it can be seen how the magnetic loops are blown outwards and detach. On the solar surface where the flux rope is, the magnetogram visualizes two sides of opposing magnetic activity and a lot of smaller regions around it.

The data of the magnetogram was adapted by inverting the colors to make the originally white background black; this because it looks better with the rest of the rendered scene. The colors of the two magnetic polarities were in the process also inverted but changed back to red and blue in the image manipulation program used.

4.4. Observing the CME

4.4

Observing the CME

Per feedback from staff at CCMC, the visualization is suitably viewed from a story perspective as in the following steps. Figure 6.4 in chapter 6 provides visual reference.

1. Observe the flux rope fieldlines zoomed in close on it, close to the solar surface, with the highest detailed magnetogram texture. Movement of the flux rope just as the CME starts is interesting because you see how one small trigger of force destabilizes the flux rope.

2. Zoom out as the CME erupts, observing how the magnetic loops of the flux rope expand and detach

3. Toggle on lower detailed magnetograms while zooming out so you can see the regions better from a distance

4. Zoomed out further, toggle on the density volume rendering to see how the mass prop-agates

5. Zoomed out to where the Sun is small on the screen, toggle off the fieldlines and show only the density, and look at the Sun from different angles. Some angles make the visualization resemble a coronagraph, which makes it easier to relate to for scientists.

5

|

Pipeline

Aside from the adaptions to the data that were deemed necessary in the visualization im-plementation study, the user encounter some things that are unclear and need to be under-stood during the current multi-step process of importing and using data. Below are some OpenSpace specific things that were unclear.

Module interface Understanding and using the module interface. Syntax and functionality of the asset file scripts that interface with the rendering classes in the C++ API.

Conversion What tools to use and how in OpenSpace to convert the data to something OpenSpace can read, and more importantly what values to specify for relevant input parameters.

Coordinate system Coordinate system for the data and scaling it. Volume data is specified in a certain coordinate system and needs to be scaled with the data’s relevant radial unit in order to see anything in an intuitive scale.

The pipeline aims to allow simplified handling and formatting of raw data that the user wants to visualize in OpenSpace. To do this it also needs an accompanying user interface fit for the task. As mentioned in section 1.1, CCMC and others express interest in a more user friendly OpenSpace for non-developers. This chapter describes the track of this thesis work that experiments with making a small portion of OpenSpace more user friendly, the concept of a data-conversion-to-asset-creation pipeline.

As discussed in section 2.1, a feature of OpenSpace is the modular design that allows developers to implement features in a separated manner in different modules that may or may not communicate with each other. For instance, the web GUI introduced in section 3.2 is implemented as a module. We aim to realize the data pipeline by implementing an module that acts as a back end, to components added to the web GUI module that acts as a front end. This allows for some separation of concern. It also lets us use features of the low-level layer C++ engine, and the high-level layer with JavaScript that is powerful for GUI development.

5.1

Design of the front end

The front end for the pipeline, otherwise referred to just as the GUI, that the user interacts with is implemented in the web GUI for OpenSpace. React components were developed and designed to be consistent with the rest of the front end codebase. From here the user chooses to bring in data from outside of OpenSpace, or to visualize data previously saved when using the application.

The design of the interface aims to be consistent with the rest of the web GUI in OpenSpace in order to achieve familiarity. The existing code base makes that easy by providing shared reusable React components of which some are used, and also a visual theme.

The different input types that were deemed necessary to include in the GUI were gleaned from the process of handling and preparing the model data for visualization, previously de-scribed in chapter 4. Seeing as this process provided insight to how the different parameters

5.1. Design of the front end and modifications of the data impact the resulting visualization when changed, they were included in the GUI. The main parameter is what variable of the data to be selected and vi-sualized, e.g. density or temperature. However most of the parameters are with regards to positioning, scaling and limiting range and space of the visualization.

There are also data dependent default values for configurable parameters, read from the user selected data. The user has sane default values for output visualization dimensions and boundary parameters, where the user might be less likely to know what to input if not given anything to go by. Sane default values are important for the user to not have to make unfounded guesses on what to put in the different configurable fields in the GUI. For most cases the default values read from the data will not need to be changed. The meaning of the default values are explained where it is applicable, for example the appropriate unit is specified for the radius in spherical coordinates.

Meta data read from the user selected files is also used to present information. The user gets an overview of what the data is: The name of the model, whether it is spherical or cartesian formatted data, and what its radial unit is. This is similar to how Kameleon Live presents model information.

User Interaction

The process of interacting with the GUI can in general be summarized as a back and forth exchange of data between the user and the backend that processes the data, the reason of why will be explained presently.

The user interacts with the GUI by toggling it on or off from within the existing OpenSpace interface. From here the option of uploading and converting new data from disk or using previously converted files is presented, see figure 5.1. The main functionality of the GUI presents itself when choosing the first of these two options, and it is at that point users are able to browse for their files and select them. Upon file selection a background process is run which presents the GUI and the user with relevant meta data.

Figure 5.1: Small component that the user first interacts with. The component is rendered after the user clicks “DATA LOADER” in the bottom bar menu.

After selecting files, the possibility of changing the visualization data parameters presents itself. The meta data information is used as input preset values which means that if the user wishes to not alter the data the preset values will produce a sound visualization result.

Once the option to convert the chosen files is selected a progress bar, that fills depending on the number of currently converted files that have been converted, will tell the user that the requested action is currently being processed and approximate the remaining time of said action. After all selected files have been converted the data that has been converted will appear as the focus point in the screen, enabling the user to directly view their data and interact with it according to the OpenSpace environment.

5.2. Transfer function preset selector

Iterating on the Design

Evaluating a user interface in a structured manner is preferably done with user tests. Circum-stances and time constraints led to only one user test being carried out, but it gave valuable input. Tips here and there were also received from scientists, co-workers and developers in the OpenSpace group.

The informal user test was carried out on the Kameleon Live developer at CCMC, which is not good for pure evaluation of the intuitiveness of the interface. The input received led to the following changes:

• To clarify what unit the data is scaled in. Although users of CCMC models would be familiar with the fact that e.g. the ENLIL model is in radii of astronomical units, and the MAS model is in solar radii, it is necessary to show that the interface takes this into account and that the user does not need to adapt input values to some other scale. • Where input is dimensional, have the parameters of the fields correspond to the

coor-dinate system, e.g. r, phi, theta for data that is in a spherical grid, or x, y, z if the data is in a cartesian grid.

• Make it clear that the option of selecting grid type will affect the resulting visualization grid type rather than the values of the data. Said option is to decide what ray march-ing method is to be used. This was later removed in favor of bemarch-ing automatically set depending on the data.

• More descriptive information on selectable transfer function presets for the visualiza-tion. Only a small section of the GUI where images of the transfer function in use was implemented, but it is ineffective in that it does not show any value ranges that need to be known for the user’s particular data. More information on this is presented in the following section below.

One suggestion not implemented is that of a mathematical formula formatting feature, which is discussed in section 8.1

No further user tests have been conducted after the completion of the project and as a result no structured information was gathered after implementation of the suggestions.

5.2

Transfer function preset selector

It is useful if the pipeline can take the data selected and make it ready for use in a self-contained manner. For volume data this would include the transfer function for the rendered volume. A user who wants to render volume data configures the parameters to define how it will be rendered, but the appearance is primarily defined by the transfer function. An editor that defines a transfer function interactively such as the one implemented in the thesis work described in section 3.2 would do well here, but the implementation of that project in particular was not ready in time with this project. As a solution, presets for transfer functions were together with a section in the GUI where they can be selected.

The clear drawback with this method is that the users does not have the visualization to work with as the preset is selected, and the visual result of the transfer function applied to the volume can only be seen after hand. However, given that the pipeline outputs script files that can be edited in the same way as OpenSpace’s other script files this is mitigateable by the fact that the user has easy access to tweaking the transfer function file.

In order to help the user decide what preset is best fit, minimum and maximum values for what the ramps in each transfer function are applied to are shown below each selectable transfer function. This at least helps the user, who might know what values in the data set that would be interesting to set ramps for, know if the transfer function preset handles a range of those values.

5.3. Implementation Overview

5.3

Implementation Overview

A C++ OpenSpace module is implemented to serve as a sort of back end to the front end. The two together make up the pipeline. The module reads, “loads” and writes. Reading file directories is necessary to provide to the GUI information about previously handled data that can be loaded again without conversion. Reading is also gathering meta data from user selected files. Loading is a broad term referring to handling the data; selecting files on the computer disk, converting and preparing it for OpenSpace. Writing is because output files are created.

Converting files refers to using functionality in OpenSpace that uses Kameleon to read CDF data and create binary files that are faster to render.

The pipeline is mostly data communication between the web-based GUI and the C++ engine. The user interacts with the GUI and the C++ engine is triggered to load a file dialog for data browsing. Meta data is read from the files and presented in the GUI which the user further interacts with. Values set in the GUI are communicated back to the engine that converts data and creates files.

Figure 5.2 shows a visual overview of the pipeline. The boxes indicate some main func-tionality, while the arrows and accompanied text describe the communication between the front end and the C++ module. The different steps are explained in this section.

Figure 5.2: Visual representation of the main functionality and the communication in the pipeline.

5.4. Output

Selecting data

An option to select files is presented to the user in a following menu, see figure 5.1. The option calls functionality on the C++ side in the OpenSpace module api and loads an operating system specific dialog box to allow the user to select one or several files on the local disk. The fact that this dialog box is specific to each operating system has the advantage of familiarity, or consistency, with other experience of the user.

The functionality that runs the dialog box and handles the user input is run on a secondary thread. This is because the functionality to run the dialog naturally hampers the thread it is run on while waiting for the user to select input, and as such if it was run on the same thread as the rest of the graphical application, the rendered scene would be frozen. On the secondary thread, waiting for user input and also processing it does not cause hang ups for the rendered graphics.

From the files that the user has selected, the Kameleon suite is used in the case of volume data. From the CDF file, certain variables that describe the data are read with Kameleon and collected into a stringified JSON formatted object. The object is then set to an OpenSpace property that is read and presented to the user back in the Web GUI.

Information from the selected data

The data that was read and determined from the selected files consists of information that will help the user configure the output visualization. There is information about the type of data the user selected, namely what physical model it is (MAS, ENLIL etc.), what grid system it uses, if it is spherical or cartesian data, what visualization variables are available (density, temperature etc.) to choose from, and what unit the radius coordinate corresponds to in the physical model.

Conversion and preparation of data

When converting data as the convert button is pressed in the GUI, the C++ module converts files from CDF into a binary “rawvolume” format used by OpenSpace. The module uses the internal dictionary data structure to store the data file paths and parameter information. A dictionary is a table of pairs of key and value, where the value can be of any type, including another dictionary, and the key is used as a means of extracting that particular data. The data structure is used because it is frequently the input type in OpenSpace interfaces, in this case the conversion task interface and the Lua formatting class used later.

Variables necessary for usage in an OpenSpace asset file are gathered into a dictionary object and written to an output asset file along with others that contain the output data to go together with said asset file.

When the file is saved it can be loaded into the OpenSpace rendering scene with the en-gine’s asset manager functionality that handles the scene graph.

5.4

Output

A directory is specified to where output files and folders are written. The outputted files for volume data are:

.rawvolume file This is the binary file that CDF conversion outputs to. rawvolume is not a special format, it’s a way to distinguish binary data for volume rendering in OpenSpace. This is preserved in the pipeline.

.dictionary For volume rendering files, it has been a convention in OpenSpace to put logic that the renderer needs for each time step in a separate, accompanying file together with the data. This is preserved here.

5.4. Output transfer function file A file the pipeline outputs the user selected transfer function file to. The idea is that this file is easily editable even as the user has selected a preset transfer function.

.asset file This is the main file of the output. This file is formatted to be consistent with other asset files in OpenSpace, and it refers to the other files in the directory. The file is outputted to with indentation consistent with the script language Lua that it is written in, so the user can easily go in and edit the file.

The .asset file is the file that should be included in other asset files, if the user wants to use it in the way OpenSpace normally uses script files. The data is however loaded in automatically upon creation of the files, and if the files remain in the output directory they can be selected after starting the application from the GUI.

To output the data as .asset files was a revised decision after first defining the files in a different way. Originally the main output directory was hidden, and no asset file generated. The idea was to primarily have the application handle the files, and as such visually separate the generated files from user created ones. A “.state” file held variate values and the idea was that as the user changed parameters in the visualization, new values would continuously be written to the state file, like how other 3D engine visualizations handle saved files and data. This idea was scrapped in favor of not mixing different concepts in OpenSpace and keep a consistent design; the asset files are generated, but tie in with the rest of the code base and the other asset files in that they can be edited and used like any other, effectively also making the pipeline a prototype asset generator.

6

|

Results

In this chapter, two main features of the work will be presented. Namely the rendered adap-tation of the MAS model as it was included into OpenSpace and the web based graphical user interface designed for the loading of data.

6.1

Visualization of the MAS model

Presented here are images of the final rendering of the MAS model that is being visualized in OpenSpace. The different transferfunctions used have been adapted by the developers purely from visual feedback of the model. This means that the values represented most likely will not be entirely scientifically accurate. All final renderings have however been viewed by experts in the space weather field at NASA and the transferfunctions have been corrected after their expertise and input.

Magnetic Flux Rope

Image 6.1 shows the models flux rope emulation at the beginning of the simulation, right before the magnetic forces start propagating outwards from the sun and pushing a CME out into space.

Figure 6.1: Fieldlines forming the magnetic flux rope using data from the bastille day event in OpenSpace.

In the image, volume data is toggled off as the flux rope is best visualized with fieldlines, and volume data like the density is more interesting to observe as the CME propagates.

6.1. Visualization of the MAS model

Density

Image 6.2 shows the erupting CME at the end the time cycle of the recorded data.

Figure 6.2: The MAS model density visualization of the bastille day event CME with corre-sponding fieldlines in OpenSpace.

Temperature

Figure 6.3 shows time sequential data from the same bastille day CME but this time visualiz-ing the temperature of the said event. Note that in the middle of the simulation run-time the temperature seemingly stops emitting and then towards the end expands in size.

Figure 6.3: The temperature visualization of the Bastille day event CME in the beginning, middle and the end of the simulation time when viewed from left to right.

Observing the visualization

The visualization was observed by and presented on a large screen for scientists at NASA GSFC Heliophysics department and CCMC staff. When observing, the steps in section 4.4 were followed. A visual reference with the resulting visualization can be seen in figure 6.4.

6.1. Visualization of the MAS model

(a) Close up on stable flux rope (b) The flux rope expands

(c) The flux rope starts to destabilize (d) Unstable structure of the magnetic field

(e) Density is toggled on (f) A mass of material leaves the Sun

(g) Zoomed out (h) Different angle

Figure 6.4: How the visualization was observed by scientists. The idea is to start by looking close up at the flux rope, then angled from the side, zoom out as the visualization is played out.

6.2. The GUI

6.2

The GUI

The first interaction point of the newly implemented user interface is the button, labeled “DATA LOADER”, placed on the lower menu bar, see figure 5.1.

From here, if the user selects the “UPLOAD DATA” button and selects appropriate data files from disk, the following window is shown, see figure 6.5. In the figure, the different options for customizing the data can be seen. The window itself is presently divided into columns with equal space in between. On the left hand side the data parameters the user can change are presented and the right column contains general information about the selected data model.