...
(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.
...
(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.
...
(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