Differences

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

--- ideas_page [2016/02/12 14:56]
unoebauer
+++ ideas_page [2016/04/27 12:26] (current)
wkerzend
@@ Line 1: / Line 1: @@
-====== TARDIS GSoC 2016 Ideas Page ======
+====== TARDIS SoCIS 2016 Ideas Page ======
 ===== A bit of astronomy and astrophysics background information =====
@@ Line 21: / Line 21: @@
 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 2016 project ideas =====
+===== List of SoCIS 2016 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 2016 and are listed with specific "warm-up" tasks below. But feel free to propose your own TEP and make a PR on that.
+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 TNo PEP - 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 SoCIS 2016 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-gsoc-2016|tardis-gsoc-2016@googlegroups.com]] or on [[https://gitter.im/tardis-sn/tardis|Gitter]].
+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-socis-2016|tardis-socis-2016@googlegroups.com]] or on [[https://gitter.im/tardis-sn/tardis|Gitter]].
 ----
-==== Testing ====
+==== Writing Models to file ====
 **Difficulty:** Easy
@@ Line 35: / Line 36: @@
 **Astronomy knowledge needed:** None
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP001_extensive_test_suite.rst|TEP002]]
+**Mentors:** @wkerzendorf, @yeganer
-**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.
+**Programming skills:** Python
-We have two kind of tests: 1) Unit tests that test small portions of the code. 2) Full tests that run the code with different settings and make sure that the outcome stays the same. This project concerns itself with the full tests.
+**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP002_model_hdf5.rst|TEP002]]
-We only use very few and not computationally expensive full tests as it is impractical for us to run these tests within our normal testing framework.
-Thus we want to add a new testing mode to our current test suite - the slow tests. We need your help with that!
+**SoCIS Application Tag:** model output
-**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`
-----
-==== Writing Models to file ====
-**Difficulty:** Easy
-**Astronomy knowledge needed:** None
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP002_model_hdf5.rst|TEP002]]
 **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 describes the ideas in some detail and we want you to help us to implement these.
 **Your first objective if you choose to accept the mission:** Write a `.to_hdf` function for the `MontecarloRunner` class in TARDIS that saves some of the important arrays to an HDF5 file.
-----
-==== Atomic Datasets ====
-**Difficulty:** Moderate
-**Astronomy knowledge needed:** None/Low - might be helpful
-**Programming skills**: Python, Parsing, Databases (SQLAlchemy experience would be great)
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP004_tardisatomic_restructure.rst|TEP004]]
-**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.
-**Your first objective if you choose to accept the mission:** Write a download function to download the atomic weights and symbols and so on from this page  http://physics.nist.gov/cgi-bin/Compositions/stand_alone.pl?ele=&all=all&ascii=html. Then build a simple sqlalchemy database with one table and put it in there. "Bonus objective": Write a parsers for (http://kurucz.harvard.edu/atoms/1401/gf1401.gam) using pyparsing.
 ----
@@ Line 89: / Line 55: @@
 **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]]
+**SoCIS 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. The benefit of this new spectrum reconstruction method compared to the standard Monte Carlo counting approach is illustrated below (//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]]//):
+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|}}
@@ Line 102: / Line 72: @@
 This project requires a bit of physics knowledge.
-**Your first objective if you choose to accept the mission:** Implement a simple counting estimator, storing the number of packets that come into resonance with each line transition. For this, look into the main Monte Carlo part of Tardis and find the location where the ''j_blue_estimators'' are incremented. This would be the place to insert the counters.
+**Your first objective if you choose to accept the mission:** Implement a simple counting estimator, storing the number of Monte Carlo packets that come into resonance with each atomic line transition. For this, look into the main Monte Carlo part of TARDIS and find the location where the ''j_blue_estimators'' are incremented. This would be a good place to insert your counters.
-----
+"Bonus objective:" Once the counter is properly working, you could try to implement an estimator for the line absorption rates (see Equation 11 in [[http://adsabs.harvard.edu/cgi-bin/nph-data_query?bibcode=1999A%26A...345..211L&link_type=ARTICLE&db_key=AST&high=|Lucy 1999]]). In an additional step, these level absorption rates could be used to calculate level absorption rates (see Equation 19 in [[http://adsabs.harvard.edu/cgi-bin/nph-data_query?bibcode=1999A%26A...345..211L&link_type=ARTICLE&db_key=AST&high=|Lucy 1999]]).
+**Hints:** As mentioned above, understanding what incrementing ''j_blue_estimators'' means, is the key to the first objective. Physically, it measures the energy of all photons which can come into resonance with a particular line. Photons/packets not necessarily have to interact with the line to be counted. The relativistic Doppler shift just has to shift their frequency far enough so that it matches the frequency of the line. Taking all this into account, you will realise that the ''j_blue_estimators'' behave very similar to the counter you are supposed to implement.
+----
 ==== Handling nuclear decay in TARDIS ====
@@ Line 113: / Line 85: @@
 **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]]
+**SoCIS Application Tag:** nuclear decay
 **Description:** Supernova are powered by the decay of radioactive elements and thus if we want to simulate
@@ Line 128: / Line 104: @@
 ----
-==== A better configuration system ====
-**Difficulty:** Medium
-**Astronomy knowledge needed:** None
-**Programming skills**: Python
-**Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP006_configuration_tags.rst|TEP006]]
-**Description:** TARDIS is a complex piece of software and has many options that can be switched on and off. This means that the Configuration modules have to be able to take a variety of input forms, parse them, validate that the input is in someway sensible (that if a float is expected there is no string given). We have thought about how to make this easier to use and have come up with YAML tags. They are a great way to parse strings to the right format and make sure that the input is valid.
-**Your first objective if you choose to accept the mission:** Parse the string `5 km/s` using YAML tags and convert it to an AstroPy quantity. **Bonus objective** Look how you would use JSONSchema to replace our validation system and write it in your application.
-----
 ==== Tighter integration of Atomic Data, Plasma and Model ====
@@ Line 151: / Line 110: @@
 **Astronomy knowledge needed:** Low
+**Mentors**: @yeganer, @wkerzendorf
 **Programming skills**: Python
 **Related TEP:** [[https://github.com/tardis-sn/tep/blob/master/TEP008.rst|TEP008]]
+**SoCIS Application Tag:** atomic/model/plasma integration
 **Description:** TARDIS needs to calculate the Plasma state very often during the runtime. TARDIS should also be able to use different modules with different approximations how to calculate the plasma state. Last year we updated the plasma module to allow a more modular approach. While we got far, this new framework is not yet completely embedded in the code and we will need your help with finalizing the integration.

TARDIS SN SoCIS 2016

User Tools

Site Tools

Differences

Page Tools