TARDIS SN GSoC 2017

====== TARDIS GSoC 2017 Ideas Page ======

===== A bit of astronomy and astrophysics background information =====

{{http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/SN1994D.jpg/480px-SN1994D.jpg}}

A [[http://en.wikipedia.org/wiki/Supernova|supernova]] (here we show SN1994D in the Galaxy NGC4526 - //image source: wikipedia//) marks the brilliant death throes of a star, during which it outshines its entire galaxy. It not only marks death, though: supernova ejecta change the evolution of the universe and enable the formation of planets and life as we know it. From the iron in your blood to the silicon in your laptop, supernovae return heavy elements assembled from the primordial hydrogen and helium left after the big bang.

There are still many mysteries surrounding supernovae (e.g. their precise origins, inner workings, ...). One way to study these objects in more detail is to split the light coming from these objects into its components (like using a prism) and analyzing the resulting data (which is called a spectrum). Here, we show spectra (black lines) of a number of different supernova types (//image courtesy Daniel Kasen and LBL//). Different chemical elements present in the supernova leave their mark on the spectra by imprinting characteristic features, so-called atomic lines (regions highlighted in colour). Thus, studying and interpreting such spectra allows us to identify what supernovae are made of.

{{http://supernova.lbl.gov/~dnkasen/tutorial/graphics/sn_types.jpg}}

With sophisticated computer simulations astronomers try to reproduce the observed spectra to draw conclusion about the properties of the supernova ejecta and ultimately the explosion mechanism and progenitor stars. TARDIS is such a numerical code. It calculates theoretical spectra based on a number of input parameters, such as the supernova brightness and the abundances of the different chemical elements present in the ejecta (e.g. Oxygen, Silicon, Iron, etc.). The main idea for this procedure is that by finding a close match between theoretical and observed spectra we identify the parameters that actually describe the supernovae.

===== The TARDIS project =====

As mentioned in the background information above, TARDIS is a scientific tool (more specifically a Monte Carlo radiative transfer code) whose primary goal is the calculation of theoretical spectra for supernovae. Below, you find the typical result of a TARDIS calculation. It shows the calculated synthetic spectra for a simple supernova model. This particular setup (''tardis_example'') is officially provided by the TARDIS collaboration on the [[http://tardis.readthedocs.org/en/latest/running.html|documentation]].

{{::tardis_example.png?600|}}

TARDIS aims to be an easy to use piece of software for research and training purposes. Unlike many other scientific codes, we have purposefully made it open-source. This enables scientists to use the code to analyze their observations, but also to review the code and potentially fix errors.

===== List of GSoC 2017 project ideas =====

In the TARDIS collaboration we first establish a detailed plan on implementing new features before starting the actual work. This is an important step that ensures that the entire TARDIS collaboration is informed about the development efforts and that the team members can help shape the ideas during the discussion phase. We call these documents TEP - TARDIS Enhancement Proposals. We already have a great list of ideas at https://github.com/tardis-sn/tep that we need help with. Some of these we have specially selected for GSoC 2017 and are listed with specific "warm-up" tasks below. But feel free to propose your own TEP and make a PR on that. 

If you use one of our TEPs, you can definitely add more detail to the implementation, but what we really want to see is a detailed timeline with milestones that shows us that you have thought about how to implement the feature in three months. For any questions about the projects, please ask on our mailing list [[https://groups.google.com/forum/#!forum/tardis-sn-gsoc2017|tardis-sn-gsoc2017@googlegroups.com]] or on [[https://gitter.im/tardis-sn/gsoc2017|Gitter]]. 

Putting in a Pull Request with the First objective is essential for each proposal to allow to see how you work. 

----

==== Expanding the Integration-Testing Framework ====

**Difficulty:** Easy

**Astronomy knowledge needed:** None

**Mentors:** @orbitfold

**Programming skills:** Python

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP001_extensive_test_suite.rst|TEP001]]

**GSoC Application Tag:** integration-testing

**Description:** Testing a scientific code like TARDIS is very important. We need to ensure that the scientific insights we gain using the code are not based on bugs. Open collaboration with GitHub is great, but the more people work on the code the more opportunities there are to introduce bugs. Making sure that the code doesn't change or only changes as we expect it, is thus an important part of TARDIS development. 

We have two types of tests: unit tests that verify small portions of the code and full-scale integration tests. The basis of the integration test framework was developed in GSoC2016 and should be expanded in this year:
 
  * currently we only verify that the output spectra remain the same. we'd like to expand that and check also different properties of our model against reference data (e.g. electron densities, ionization fractions, dilution factors)
  * hand in hand with expanding the verification process we will improve the reporting process which should contain detailed plots and comparison results
  * finally, different integration test suites should be defined. Our idea here is to have a set of tests which proceed relatively fast and can thus be executed frequently and another set of very expensive but very detailed and rigorous tests which will be repeated less often

**Your first objective if you choose to accept the mission:** Mark the TARDIS full test as slow and make it easy to enable it's execution only with a commandline option to `py.test`

----

==== Unit-Testing the Plasma Module ====

**Difficulty:** Easy

**Astronomy knowledge needed:** None

**Mentors:** @wkerzendorf

**Programming skills:** Python

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP001_extensive_test_suite.rst|TEP001]]

**GSoC Application Tag:** unit-testing

**Description:** 

One important piece of TARDIS is the calculation of the plasma state. That means that it is also crucial to ensure that the results from these calculations do not change unexpectedly. But we sometimes introduce changes that do affect the result in an expected way. This requires us to change the values that the test checks against in a controlled way. This project aims at making it easy for us to generate "reference" data and update this reference data. 


**Your first objective if you choose to accept the mission:** Look at the function 'test_partition_function.py' and try to replace the comparison values there and replace them with one loaded from a file. 

----

==== Reading Simulation from file ====

**Difficulty:** Easy

**Astronomy knowledge needed:** None

**Mentors:** @wkerzendorf

**Programming skills:** Python

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/tep014_model_from_file.rst|TEP014]]

**GSoC Application Tag:** reading simulation

**Description:** TARDIS studies how light travels through a supernova and how it ultimately appears to us. We are researching this process and thus are interested in analyzing TARDIS outputs in great deal. This means that we aim at capturing the full state of a TARDIS calculation in more detail. TEP002 implemented the functionality to store important data to a HDF5 file. 

The next step, which this project is all about, is to read the data again from the HDF5 and to restore a fully functional TARDIS simulation object. 


**Your first objective if you choose to accept the mission:** Use `tardis_example.yml` to generate a Simulation object (see the Quickstart guide on our documentation) and save it to an HDF5 file. Then write a script reading `Radial1DModel.time_explosion`. Hint: Have a look at `pandas.HDFStore`.

**Bonus objective**: Read all attributes of `Radial1DModel` and create a model identical to the one from the `tardis_example.yml`.

----

==== Atomic Datasets ====

**Difficulty:** Hard

**Astronomy knowledge needed:** Medium

**Mentors:** @lukeshingles, @shaching

**Programming skills**: Python, Parsing, Databases, SQLAlchemy

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP004_tardisatomic_restructure.rst|TEP004]]

**GSoC Application Tag:** atomic dataset

**Description:** In addition to the input parameters (brightness of the supernova, ejected mass of the different chemical elements, etc.), TARDIS requires data for describing the structure of atoms from different elements (e.g. a sodium atom is differently structured than an iron atom; see the figure for a quick overview for carbon).

{{:bohrmodel.gif}}

This data is not measured by astronomers, but is most often gathered in a lab by atomic physicists. As measurement equipment gets more and more precise, so do the measured structures of different elements. Thus these values update from time to time and are often available in simple ASCII files (http://kurucz.harvard.edu/atoms/1401/gf1401.gam). While we have compiled a small atom data set from some specific sources for our initial work, we would like to get a collection of parsers that can read the different ASCII formats of the group and put this information in a uniform database. 

For this project you would help us make parsers for a variety of formats from a collection of atomic data sources (see the TEP) and in the second part put this into a database. The assembled database will not only be very interesting for us, but also for many other fields of astronomy that do rely on atomic data. A useful resource of understanding atomic structure description can be found in http://www.physics.byu.edu/faculty/bergeson/physics571/notes/L27spectnotation.pdf.

In GSoC 2016 we created a package that compiles all of this information into a database named Carsus (see http://carsus.readthedocs.io/en/latest/). For this year we aim to strengthen the link between Carsus and TARDIS and also include more atomic data into Carsus.

**Your first objective if you choose to accept the mission:** Use the script (https://github.com/tardis-sn/carsus-db/blob/master/scripts/create_hdfstore.py) to generate an HDF store - then implement a meta table in the HDF file that stores the units of the columns. 

----

==== New module for the creation of spectra ====

**Difficulty:** Hard

**Astronomy knowledge needed:** Medium

**Mentors:** @unoebauer, @chvogl

**Programming skills**: Python, C, Cython

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP005_formal_integral.rst|TEP005]]

**GSoC Application Tag:** spectral synthesis

**Description:** TARDIS's main task is to create spectra that can be compared with observations. In order to use TARDIS to estimate parameters of real supernovae, we need to select TARDIS simulation parameters in such a way so as to produce spectra resembling those of real supernovae. When having a real spectrum, however, we don't know what those simulation parameters may be.

We use a method that uses random numbers to simulate the flow of light through the supernova envelope. But that also generates noise in the final output spectrum. We would like to implement a better solution for this, by using the formal integral solution developed by [[http://adsabs.harvard.edu/abs/1999A&A...345..211L|Lucy 1999]], as proposed in TEP005. In the figure below, the benefit of this new spectrum reconstruction method (shown as the thick black line) compared to the standard Monte Carlo counting approach (noisy histogram) is illustrated (//image taken from [[http://adsabs.harvard.edu/cgi-bin/nph-data_query?bibcode=1999A%26A...345..211L&link_type=ARTICLE&db_key=AST&high=|Lucy 1999, fig. 4]]//):

{{::lucy1999_formal_vs_mc.png?600|}}

A first basic Python implementation of this method has been realised during ESA's Summer of Code in Space 2016 program (SOCIS 2016). In this year, we aim at porting the scheme to the C-part of TARDIS. Furthermore, the Formal Integral method should be completed during this project by incorporating the effect of electron scattering and by interfacing the technique with the Macro Atom-based line interactions treatment of TARDIS (c.f. [[http://www.aanda.org/articles/aa/ref/2002/11/aa1428/aa1428.html|Lucy 2002]]). For this project we think that a firm physics or astrophysics background will be advantageous.

**Your first objective if you choose to accept the mission:** Implement the calculation of the source function in C. The current implementation is done in python with pandas. Assume the following function declaration with att_S_ul as the output and the storage structure as the input:

''void integrate_source_function (storage_model_t *storage, double *att_S_ul);''

**Hints:**    
Use the current Python implementation as a starting point and try to understand 
how to access the relevant data on the C-level.
To this end, you can have a look at the TARDIS documentation and see how the data 
for the macro atom scheme (e.g. transition_probabilities, transition_line_id, ...) 
is stored.

----



==== Handling nuclear decay in TARDIS ====

**Difficulty:** Medium/Hard

**Astronomy knowledge needed:** Low/None

**Mentors:** @unoebauer, @wkerzendorf

**Programming skills**: Python

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP007_isotopes_decay.rst|TEP007]]

**GSoC Application Tag:** nuclear decay

**Description:** Supernova are powered by the decay of radioactive elements and thus if we want to simulate
supernovae we also need to take this physical process into account. Currently, this is done in a very difficult and 
not easily extensible way in TARDIS. We have thought about adding more support for this and need your help with 
this. 


**Your first objective if you choose to accept the mission:** Make a Pandas DataFrame with columns atomic_number, mass_number, mass - then use PYNE [[http://pyne.io/|PYNE]] to write a function that takes this table decays it for 100 days and returns a table with the decayed masses. 


----





==== Improving the Tardis GUI ====

**Difficulty:** Medium

**Astronomy knowledge needed:** None

**Mentors:** @wkerzendorf, @unoebauer

**Programming skills:** Python

**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP012_gui_overhaul.rst|TEP012]]

**GSoC Application Tag:** gui

**Description:** Often we need more information about the model and the calculation than the mere spectrum. For example, we frequently need to investigate in detail how a specific spectral line feature forms, which ions and which specific line transitions contribute. For exactly this purpose a Qt-GUI was developed (see [[http://tardis.readthedocs.io/en/latest/gui.html#gui-explanation|here]]). It allows the user to easily analyse TARDIS runs and extract important physical information without knowing the exact inner data structure of TARDIS.

During GSoC 2017 we want to update and improve this GUI. As a first step, the GUI has to be made compatible with the current design of TARDIS, i.e. able to work with simulation objects. After this preparatory step, the GUI should be extended to contain the analysis tools which currently reside in the [[https://github.com/tardis-sn/tardisanalysis|tardisanalysis]] repository. Finally, an addon scheme should be developed/implemented which enables the user to easily add more analysis tools.

**Your first objective if you choose to accept the mission:**

At the moment, the GUI is incompatible with the current version of TARDIS and can't be started (Issue [[https://github.com/tardis-sn/tardis/issues/690|#690]]). Make a PR that implements the necessary minimal changes in the GUI to start with the current version of TARDIS. In this first task, it is not necessary to fix all potentially broken features but that the main GUI window can be started without errors.
TARDIS SN GSoC 2017

User Tools

Site Tools

Page Tools
