The following is the result of the discussion we had on December 16, 2015 about creating a set of unified sims library packages to provide basic functionality required by CatSim, OpSim, and MAF. I have sub-divided the functionality into what I think are logical categories, each representing a hypothetical separate eups package. This can, of course, be reorganized if dependencies become too complicated. The hope is that we will be able to implement all of this with minimal dependence on compiled packages from the DM stack.
OpSim, CatSim, and MAF each have structs which they use to store data about the LSST site (CatSim allows users to specify other site data if they want). We should adopt a single formalism for this.
The coordinate functionality we need to support is:
Transformation between equatorial, galactic, ecliptic, and horizontal
coordinates (including calculating parallactic angle)
Transformation from RA, Dec to healpix coordinates
Calculation of airmass (mostly, we just need to choose a single convention
for what we mean by “airmass”; i.e. are we just using sec(Z)?)
Transformation between different telescope orientation parameters
(i.e. going from rotSkyPos to rotTelPos). Currently, the principle
ambiguity here is whether OpSim uses the beginning or the middle of
an exposure when calculating altitude, azimuth, and parallactic angle
for converting from rotSkyPos to rotTelPos. See JIRA issue SIM-1091
Tracking the altitude and azimuth of the Sun, Moon, and planets and then
converting those coordinates into rise and set times.
OpSim currently has classes specifically designed to track the positions
the Sun and the Moon. We should evaluate whether we want the rest of
sims to simply adopt these classes.
We also need to keep track of Moon phase.
Transformations between time scales (TAI, UTC, TDB)
OpSim requires a method to store the positions of bright stars so that
the SOCS knows when it is pointing at them. This method may need to be
able to correct those positions for proper motion, parallax and radial
velocity. There will be 1000s of stars in this catalog.
Most of these feature are provided in PALPY (though, as Tim Jenness has pointed out, we would have to add some significant code to go from Sun/Moon alt, az to rise and set times). They are also provided in astropy. We must decide whether or not we want to write our own thin wrappers to PALPY, or officially adopt the astropy.coordinates framework. There is some concern that astropy.coordinates may not yet be as fast as working with numpy arrays of floats. An advantage of astropy.coordinates is that it automatically handles angle units. We would no longer have to carry around two copies of each method (one for radians; one for degrees).
It should be possible to implement this functionality in such a way that its only external dependency will be either PALPY or astropy (or both). We may need Healpy to implement the (RA, Dec) to healpix transformation, but that can be implemented in a separate package, if we want.
Photometric quantities that we need to be able to calculate are:
An official, sims-wide method for calculating m5 from sky brightness.
Official methods for calculating FWHMeff and FWHMgeom.
Official wrappers for Peter’s sky brightness model to help calculate
when twilight begins (for the purposes of OpSim).
We should determine a method for keeping track of coorections to filter
throughputs due to airmass and/or position on the focal plane.
We should be able to implement this functionality in a pure python package
without any external dependencies.
NEO science will need methods to propagate orbits through time. This will need to be a totally new package, as it will draw in dependencies (pyorb/oorb and fortran at least) that nothing else in the stack requires.