Page History

Jump to the updates of 26 Sep 2008
Jump to the updates of 19 Aug 2008
Jump to the updates of 20 Nov 2007

New implementation! (Jan. 2012)

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.

Wiki MarkupBasically, 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. \ [anders\] The reasons for the forced stop/starts can be found [here|https://confluence.slac.stanford. edu/download/attachments/17880/borgland_runLength_SciOps10272006.pdf?version=1]. 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.

...

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.

Wiki MarkupThis 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? \ [anders\] Any time between an LPASTOP and the subsequent LPASTART is deadtime i.e. we did not take any data.

(D. Band 4/6/07) First, is this an ICD/FFD issue, given that every row provides the start and stop time? Second, I think it makes sense to increase the time resolution when necessary--perhaps we should establish an angular change criterion?

...

(Ormes, from e-mail 4/16/07) I don't know how the electronics was finally done. I do know these numbers, live and dead were supposed to be measured independently in the electronics. Maybe it was not done in the end.

Wiki Markup(_Borgland_, from e-mail 4/16/07) There is no deadtime counter since by definition the instrument is dead. There is only a livetime counter which increments in 50 ns tickes all the time the instrument is alive i.e. not busy/dead reading out etc. There is also an elapsed counter which is the total time. The livetime
fraction between events N and N+M is just
LiveTimeFraction = \ [Livetime(N+M)-LiveTime(N)\]/\[ElapseTtime(N+M)-ElapsedTime(N)\]

and the deadtime (for whoever is interested in that) is just 1 - LivetimeFraction.

...

5/16/07: Removing the DEADTIME column has been submitted as a JIRA request, https://jira.slac.stanford.edu/browse/DATAPROD-1^{Image Removed}

3. McIlwain coordinates

...

5/16/07: Adding the geomagnetic latitude has been submitted as a JIRA request, https://jira.slac.stanford.edu/browse/DATAPROD-2^{Image Removed}

4. IN_SAA column

...

I don't see any downside to including attitude quaternions, other than increased sizes for FT2 file, but I'm likewise not sure whether I see any big advantages either.

...

Here are additional items added on 19 August 2008

7. Rocking angle of the LAT

(Digel) The rocking angle of the LAT (i.e., the direction of the LAT z axis from the zenith) is not used directly by the Science Tools but it is of interest for evaluating the observing strategy and especially for assessing albedo backgrounds and loss of exposure for pointed observations. It can be derived from the direction of the LAT z axis and the zenith direction, but having it directly in the FT2 file would be more convenient.

9/26/08: We'll add this as ROCK_ANGLE. One commenter requested that this be a signed quantity - positive for rocking toward the north orbital pole - that is what we'll do.

8. Direction of the orbital pole

(Digel) Similarly, this information is not used in the Science Tools but having it conveniently available would be useful for evaluating observing strategies. The direction of the orbital pole can be derived from information already in the FT2 file but it requires, e.g., calculating cross products of zenith directions in successive time steps. Having the direction of, say, the northern orbital pole directly available in the file would be a convenience; the impact would be the addition of 2 floating-point columns. Also ft2Util would need to be updated. No existing FT2 file would 'break' as the result of this change.

9/26/08: We'll add this as RA_NPOLE, DEC_NPOLE. This is not needed by the Science Tools but is very convenient for browsing the pointing history, e.g., for selecting time ranges when a given direction was best covered by the LAT.

...

Here are additional items added on 26 Sep 2008 to summarize discussions that have taken place mostly via e-mail so far regarding needed updates for dealing with flight data.

9. LAT configuration flag

(Digel) This flag abstracts the MOOT key and filter selection settings to indicate whether the data can be considered the equivalent of 'nominal Science Operations' quality for the Science Tools. This ordinarily would apply to a whole run but needs to be a column in FT2 because in various data servers the distinctions between runs will be lost. Right now the quantities envisioned for this flag are 1 = nomSciOps or close enough; 0 = not recommended for analysis in Science Tools
9/26/08: We'll add this as LAT_CONFIG

10. LAT data quality flag

(Digel) This flag is the equivalent of the (per-run) data quality flags. It is defind on a per-run basis, but It needs to be a column in FT2 because in various data servers the distinctions between runs will be lost. Values currently envisioned are 1 = ok, 2 = waiting review, 3 = good with bad parts, 0 = bad
9/26/08: We'll add this as DATA_QUAL

See Draft FT2 Template 26 Sep 2008 for specifics