Differences

This shows you the differences between two versions of the page.

--- ideas_page [2019/01/12 00:04]
wkerzend
+++ ideas_page [2019/03/12 00:04] (current)
wkerzend
@@ Line 30: / Line 30: @@
 ----
 ==== Expanding the Integration-Testing Framework ====
@@ Line 37: / Line 39: @@
 **Astronomy knowledge needed:** None
-**Mentors:** @orbitfold
+**Mentors:** Vytautas Jancauskas, Ulrich Noebauer
 **Programming skills:** Python
@@ Line 47: / Line 49: @@
 **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:
+We have two types of tests: unit tests that verify small portions of the code and full-scale integration tests. Both of these test types are implemented with a framework. But the integration tests are difficult to use.
-  * 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`
+  * currently we mainly run the integration tests on an external server. We want to integrate them into our general Azure Pipeline continuous integration routine. We'd also 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. A framework exists but is currently not actively used.
+**Your first objective if you choose to accept the mission:** Setup the integration tests to run once a week on Azure pipelines given the examples at https://tardis.readthedocs.io/en/latest/running_tests.html
 ----
-==== Unit-Testing the Plasma Module ====
-**Difficulty:** Easy
+==== Atomic Datasets ====
-**Astronomy knowledge needed:** None
+**Difficulty:** Medium
-**Mentors:** @wkerzendorf
+**Astronomy knowledge needed:** Low/None
-**Programming skills:** Python
+**Mentors:** Luke Shingles, Mark Magee
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP001_extensive_test_suite.rst|TEP001]]
+**Programming skills**: Python, Parsing, Databases, SQLAlchemy
-**GSoC Application Tag:** unit-testing
+**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP004_tardisatomic_restructure.rst|TEP004]]
-**Description:**
+**GSoC Application Tag:** atomic dataset
-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. For this purpose we use unit tests of isolated parts of the plasma state calculations and compare the results to pre-computed reference data. Naturally, whenever we improve, expand or alter the implemented physics underlying the calculation, we have to also modify the reference data. This project aims at making it easy for us to generate and update reference and to automate this process.
+**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}}
-**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.
+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.
-==== Reading Simulation from file ====
+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.
-**Difficulty:** Easy
+**Your first objective if you choose to accept the mission:** download the atomic data from http://kookaburra.phyast.pitt.edu/hillier/web/CMFGEN.htm and read in the tabulated data contained in si2_osc_kurucz.
-**Astronomy knowledge needed:** None
+----
-**Mentors:** @wkerzendorf
+==== New stream-lined model file ====
-**Programming skills:** Python
+**Difficulty:** Medium/Hard
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/a1661c6b508b5aed341a2627e03a7ad9c3942f12/tep014_model_from_file.rst|TEP014]]
+**Astronomy knowledge needed:** Low/None
-**GSoC Application Tag:** reading simulation
+**Mentors:** Yssa Camacho, Stuart Sim
-**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.
+**Programming skills**: Python
-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.
+**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP007_isotopes_decay.rst|TEP007]]
+**GSoC Application Tag:** new-model-format
-**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`.
+**Description:** The main task that TARDIS accomplishes is to take a model of the exploded star and then simulate the transport of light resulting in a prediction of the observed spectrum. There are currently multiple formats to input the model. For this year, we aim to streamline this process and provide a single format for input. We will also provide converters for the legacy formats.
-**Bonus objective**: Read all attributes of `Radial1DModel` and create a model identical to the one from the `tardis_example.yml`.
+**Your first objective if you choose to accept the mission:** Combine the functionality from read_cmfgen_density and read_csv_isotope_abundances to read a single files that can interpret columns from both functions (https://github.com/tardis-sn/tardis/blob/master/tardis/io/model_reader.py).
 ----
-==== Atomic Datasets ====
+==== Jupyter notebook widget for TARDIS ====
 **Difficulty:** Hard
-**Astronomy knowledge needed:** Medium
+**Astronomy knowledge needed:** None
-**Mentors:** @lukeshingles, @shaching
+**Mentors:** Yssa Camacho, Laud Bentil
-**Programming skills**: Python, Parsing, Databases, SQLAlchemy
+**Programming skills:** Python, Jupyter
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP004_tardisatomic_restructure.rst|TEP004]]
+**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP012_gui_overhaul.rst|TEP012]]
-**GSoC Application Tag:** atomic dataset
+**GSoC Application Tag:** jupyter-widget
-**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).
+**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.
-{{:bohrmodel.gif}}
+QT for this type of application is no longer the ideal framework. Many applications now work with Jupyter notebook and we want to have a functional GUI that acts as a Jupyter widget. Once this is implemented, we would like to have several example notebooks that exist within the documentation so that it is easy for users to try it out themselves.
-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.
+**Your first objective if you choose to accept the mission:** Make a Jupyter notebook and embed it in the documentation that showcases the current way of running TARDIS and plots a spectrum.
-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.
+==== Distribution of TARDIS via conda ====
-**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.
+**Difficulty:** Medium
-----
+**Astronomy knowledge needed:** None
-==== New module for the creation of spectra ====
+**Mentors:** Wolfgang Kerzendorf, Vytautas Jancauskas
-**Difficulty:** Hard
+**Programming skills:** Python, conda
-**Astronomy knowledge needed:** Medium/High
-**Mentors:** @unoebauer, @chvogl
+**GSoC Application Tag:** conda
-**Programming skills**: Python, C, Cython
+**Description:** TARDIS is a tool to analyze transient phenomenon like supernovae. It is important for researchers to quickly install this tool to react to newly observed objects. Anaconda offers a quick and easy way to install python packages and its dependencies. For this project, we want to make it easy to install TARDIS via Anaconda.
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP005_formal_integral.rst|TEP005]]
+**Your first objective if you choose to accept the mission:** Make a conda packages for TARDIS following the instructions on https://conda.io/projects/conda-build/en/latest/source/recipe.html.
-**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]]//):
+==== Enable the Dask framework for parallel execution for TARDIS ====
-{{::lucy1999_formal_vs_mc.png?600|}}
+**Difficulty:** Hard
-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.
+**Astronomy knowledge needed:** None
-**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:
+**Mentors:** Tyler Pritchard, Christian Vogl
-''void integrate_source_function (storage_model_t *storage, double *att_S_ul);''
+**Programming skills:** Python, dask
-**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.
-----
+**GSoC Application Tag:** dask
+**Description:** Exploring different simulations of supernovae and comparing them with observations is one of the important tasks of TARDIS. This means that TARDIS needs to be run many tens of thousand times with different inputs. The Dask framework will allow TARDIS to be excecuted on multi-core systems and super-computers. This project aims to combine TARDIS with dask to make it easy to run many iterations of TARDIS.
+**Your first objective if you choose to accept the mission:** Use dask to run distributed TARDIS instances in parallel on your system. Use http://distributed.dask.org/en/latest/client.html as a guide to make a simple example.
-==== Handling nuclear decay in TARDIS ====
-**Difficulty:** Medium/Hard
+----
-**Astronomy knowledge needed:** Low/None
+==== Improve the C/Python interface ====
-**Mentors:** @unoebauer, @wkerzendorf
+**Difficulty:** Hard
-**Programming skills**: Python
+**Astronomy knowledge needed:** None
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP007_isotopes_decay.rst|TEP007]]
+**Mentors:** Wolfgang Kerzendorf, Christian Vogl
-**GSoC Application Tag:** nuclear decay
+**Programming skills:** python, cython
-**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.
+**GSoC Application Tag:**c_interface
-**Your first objective if you choose to accept the mission:** Make a Pandas DataFrame with columns atomic_number, mass_number, mass - then use [[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.
+**Description:** TARDIS is a hybrid code built on C/Cython/Python. Currently, there is a lot of interface code to port the python data structures from Python via Cython to C. This makes the code cumbersome to test and try out new things. There are now several new ways that promise to make this easier. We want to try to use cFFI and Apache Arrow to do this.
+**Your first objective if you choose to accept the mission:** use cFFI to provide an automatic interface for testing the parts in the montecarlo package instead of ctypes.
 ----
+==== Profile TARDIS ====
+**Difficulty:** Easy/Moderate
+**Astronomy knowledge needed:** None
+**Mentors:** Wolfgang Kerzendorf
-==== Improving the Tardis GUI ====
+**Programming skills:** python, cython
-**Difficulty:** Medium
-**Astronomy knowledge needed:** None
+**GSoC Application Tag:**asv
-**Mentors:** @wkerzendorf, @unoebauer
+**Description:** TARDIS is a code that prides itself on being relatively fast to compute a synthetic spectrum. We are also continuously adding additional microphysics in the code which sometimes requires additional calculation. It is important to understand how much this microphyiscs adds to the runtime of the code. For this we want to implement a benchmark in asv (airspeed velocity) that can automatically generate a report for us.
-**Programming skills:** Python
+**Your first objective if you choose to accept the mission:** implement a simple benchmark in asv.
-**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 2019 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 GSoC 2019

User Tools

Site Tools

Differences

Page Tools