S. Digel, 8 November 2005
Last month we discussed some issues related to how time is handled in the science tools and the data products.
I think that we agreed that MJDREF = 51910 (start of January 1, 2001) is what we use as the reference time for MET and that the tools and sources internally use MET.
I proposed that the tools should check the value of MJDREF when they are processing an event file and complain and quit if it is not 51910. This was not universally accepted, but I am not sure what a sensible alternative would be, short of entirely ignoring or omitting MJDREF and just assuming that times are always measured with respect to January 1, 2001.
The question remains, too, of how we make times more straightforward to deal with. Someone (Masa or Jean, I think) proposed that we use TZEROn for the TIME column to set an offset time (like the MET of the launch). This is entirely sensible. (TZEROn is a FITS standard for binary tables. The T stands for Table, not Time, and it represents an offset to be applied to all values in the n-th column.)
Jim has suggested that by default (specified by a 'hidden' parameter in the .par file) gtselect should work in times with respect to TZERO for the time column of the current input file, this sounds like a good idea to me.
On the source simulation side, having something equivalent to TZERO, i.e., a reference MET value for the start of a simulation, would be a big convenience. Otherwise, the MET values corresponding to times during the mission will all be in the 200,000,000+ range. As we discussed last month, there's no good way that we can have a single reference time specified at the top of an XML file, per source library, say.
I'd like to propose that we modify all of the time-dependent sources to accept an additional parameter - a reference time in MJD with respect to which the times used in defining the source are measured. So, for example, a TransientTemplate source that is supposed to turn on for 10 ks starting at noon on November 9, 2008 (MJD 54779) is currently specified as something like
<source name="flaring_source">
<spectrum escale="MeV">
<SpectrumClass name="TransientTemplate"
params="0.2,2,247924800,247934800,transient_profile.dat"/>
<celestial_dir ra="80" dec="20"/>
</spectrum>
</source>
and would become something like
<source name="flaring_source">
<spectrum escale="MeV">
<SpectrumClass name="TransientTemplate"
params="0.2,2,54779, 43200, 53200,transient_profile.dat"/>
<celestial_dir ra="80" dec="20"/>
</spectrum>
</source>
Similar changes to the specifications of SimpleTransient, SpectralTransient, FitsTransient, and GRBobsManager (and how these sources handle the specifications) would be needed. If astro does not already have it, Toby can provide a conversion between the MJD of the reference time and MET.
Every transient source specification would have to include the MJD of the reference date.
Note that this change would not affect PulsarSpectrum sources, because their variations with time are already defined in terms of absolute time (in the 'DataList' file). The Pulsar source would have to be changed, too, most likely to have the reference time for phase 0 specified as an absolute MJD rather than in MET.
Another question related to time, from Jim: Who has got the time to make these changes? There's an opportunity cost in fiddling with the code for the sources, many of which were written by Jim. We can live with the sources the way that they are, and I do not expect that DC2 users will be writing complicated source models. The motivation for making the change in the near term probably boils down to convenience for specifying the DC2 sky model. The changes are not great, but we'd of course need to verify that they did not break anything.