- A data structure or in memory representation of the information associated with a single supernova. This should access the
metadata
or properties of the SN, as well as the Time Series (light curve) information (potentially from multiple sources) each of which should have their own schema.- The code or schema variables should be stable define the standard variable names to be used by all our software.
- Each schema should have flags for stages. The minimal schema should be designed so that the usage is very broad. In practice, one should be using flags to turn on non-minimal schema used in almost any applications.
- It should be able to gracefully handle extra columns, for example if someone were to import an LSST dia object catalog with columns like aperture mag that are not part of the schema, it should be able to put the additional columns as additional columns inheriting the names. It should be possible to switch this of by providing a list of columns to import.
- This
At various times, everyone working on snmachine development has talked about refactoring snmachine. This came up in a short chat at the DESC collaboration meeting (Hiranya, Catarina, Christian, Rahul). One of the things we agreed upon was that it makes sense to have a common class for DESC SN (a bit of a rehash of an old idea from Pittsburgh, a few years back, where Robert and Kara played with snmachine). This should have the capability of accessing different datasets (starting with a few) that people need, and provide some common functionality. Since each analysis code needs to be doing the same thing, it makes sense not to re-invent that wheel from scratch.
An important functionality of such a code should be providing things in a usable format for DESC products like snmachine. But setting that requirement involves clearly stating what snmachine
requires. So, we need to discuss a few things:
- What data sets are essential for snmachine : A