S. Digel, 4 October 2005
In our events files (FT1), time is measured with respect to a reference time, as seconds since January 1, 2001. In fact, the same should go for the pointing/livetime history (FT2) files as well. In FITS, reference times are defined using the keyword MJDREF, which is the Modified Julian Date of the reference time. The usage is historical, but it does the job. MJDREF is expressed in days, and can in principle have a fractional part. Our value is 51910.
Should we use absolute times (and if so, how do we specify them), or should we use MET?
My vote is for MET, but a reasonable question is how much of a nuisance it will be because realistic MET values at the start of the mission will be in the 200,000,000+ range. Should we allow a 'simulation start date' parameter in sources that allow times to be specified? This would not supplant the reference time for MET, but instead be available as a convenience.
For generating the simulated data for checkout 3, we had trouble because the FT2 file had MJDREF = 54101 (January 1, 2007). It turns out that gtobssim (or possibly more properly GPS) does not check the MJDREF value when it uses an FT2 file to generate interpolated positions and attitudes. This resulted in event files with MJDREF = 51910, and formally the FT1 and FT2 files did not overlap in time.
Keeping in mind that for LAT data MJDREF is being used to define the reference time for MET, it really, truly should not change, and I think it is reasonable for GPS and the science tools to not be willing to accept any other value for it than 51910. But they should at least check that the value is 51910.
Currently the 'blazar' source (SpectralTransient) uses MET. GRBobsmanager internally assumes that the times in the GRB source specifications are with respect to January 1, 2007, but GPS assumes that they are MET. PulsarSpectrum is immune to the choice of MJDREF because all of the pulsar timing epochs are specified as absolute MJD values.
As mentioned above, they should check that MJDREF entries of input files are correct, and should complain and quit if they are not 51910. The should also use 51910 as the MJD of the reference date for absolute times. I don't think that the tools currently check MJDREF for correctness, although I think that tools like gtbary use whatever value of MJDREF is present as the reference date for the absolute times of the events.
I suppose that we can get along with having MJDREF = 51910 encoded in template (*.tpl) versions of the FT1 and FT2 headers, because it will not change. In terms of managing the templates, as Jim has pointed out, we can do better than having more than one copy of each template file - for example, copies of ft1.tpl exist in fitsGen, observationSim, and tip, and they are not all the same. And they are not necessarily consistent with the most up-to-date versions of the science data products that Masa maintains.
We should keep the template files in only one place and have all of the packages that want them look there. Regarding consistency with the most current definitions, I guess that won't come automatically unless the template files themselves represent the definitions.
Also, although we could have versioning keywords in the template files themselves, we do not currently do so. In principle, the tools could know what versions of the data product definitions they had been 'certified' for and at least give a warning if the version of an input file is different.