Pointing and live time history (FT2, LS-005)
This is a fundamental data product used by the science tools. The current definition (version 10 of July 25, 2006 as of this writing) is posted on the Guidelines for Science Tools Design page maintained by Masa Hirayama. This page includes a link to the ft2.tpl template file that is the current working definition of the FT2 format as used by the Science Tools.
Basically, the file is intended to include the necessary information (other than tables of effective area) for calculating exposures. So it has the position and attitude of the LAT for regularly-spaced time intervals (nominally 30 seconds, although shorter intervals are used when the LAT enters and exits the South Atlantic Anomaly). As currently planned, SAA entry and exit will correspond to the stop and start time for the data taking 'runs' in flight. For orbits that miss the SAA, a run stop/start will be issued when the LAT crosses the orbital plane heading north. The reason for the forced stop/start has to do with preventing some counters rolling over for very long runs. For these stop/starts, the interval between the entries may also be less than 30 s. For each of the intervals in an FT2 file the accumulated live time is also recorded.
This page is open for comments, and for posting additional issues. For clarity, please add the comments in the section to which they refer, by editing the page directly. When the comments settle down, I will post as JIRA issues any specific changes that we converge on for the definition of the FT2 format.
1. Interval between entries in the FT2 file
(Digel) The 30-second interval was chosen as being relatively long but short enough (corresponding to ~2 deg of advance of the pointing position during scanning observations) so that the exposure could be calculated accurately. The thinking was that 2 deg is so much smaller than the FOV of the LAT that accurate exposures could be calculate with 30-second intervals.
Three questions:
GLAST will slew much more quickly when it is rocking - perhaps 15 deg per minute (? ) - I think the spec is 75 deg in 10 minutes but GLAST is said to be significantly faster. Do we care in terms of the time spacing of the FT2 entries? The science tools do not assume any particular spacing, so in principle a shorter interval could be used when the LAT is rocking. Is it worth worrying about?
And when the LAT is just scanning, can we make do with a longer interval, say 1 minute? How severe is the tradeoff in accuracy? The motivation for making the interval longer would be to make FT2 files smaller and to increase the speed of exposure calculations.
This is kind of a minor point, but may need to be clarified: During the time between the stop (LPASTOP) of a run and the LPASTART of the next (if a stop/start is issued outside an SAA passage - see above), the LAT will be dead as far as data taking is concerned. If a time interval is not explicitly included in an FT2 file, i.e., if the time of a START entry is not the same as the time of the previous STOP entry, we can just assume that the missing interval was dead time, right?
2. DEADTIME column
(Digel) For reasons that I no longer recall, we originally decided to keep track of both accumulated livetime (in each 30 second interval) and accumulated deadtime (since the start of the mission). The Science Tools do not use the DEADTIME column and makeFT2 assigns the value 1-LIVETIME to the column anyway.
I propose to remove this column from the definition of FT2.
3. McIlwain coordinates
(Digel) These are geomagnetic coordinates and presumably useful in some way for studying variations in residual background. The actual model we are using for the background depends on geomagnetic latitude, however, rather than the McIlwain L, B. I'm not entirely sure that we need (i.e., that anyone will use) L, B, but I won't propose removing them. I would like to propose including geomagnetic latitude, however, as an additional column.
4. IN_SAA column
(Digel) This is just a flag defined to be True if the LAT is in the SAA. Right now it is not entirely clear (to me) whether we will be getting spacecraft position and attitude information during SAA passages. This would have implications, e.g., for using the Low-Rate Science counters to monitor the boundaries of the SAA, and also would mean that an IN_SAA flag would be superfluous. I'll update (or remove) this entry when I find out the answer.
5. Extension Name for data extension in FITS file
(Stephens) I don't know if this has ever been discussed before but I noticed a discrepancy between the data and the documentation and thought I'd bring it up. We should verify that the science tools that both produce and consume this product are using the correct extension name (EXTNAME keyword value) for the extension containing the data and that that name matches what is in the documentation. The Science Data Products ICD and File Format documents list the extension name for this extension as 'LAT_POINTING_HIST'. It formerly used to be 'SC_DATA' and the last time I checked (mid-late January) the Science Tools were still set up to use this older name. While the name doesn't really matter, what does matter is that we are consistent across the tools and the documentation. The GSSC's data ingest system works off the ICD and that document is what the HEASARC will look to as well for the data formats so we need to keep it up to date and in sync with the software. Because of our requirements on data validation and tracking, if data arrives at the GSSC that doesn't match the format in those documents, the data will be rejected as bad. The bottom line is that we should settle on a name for this extension, have David Band put it in the document, make sure all the software are using that name, and be done with it.