...
Proposed resolution: Omit SKYX/Y columns. Reluctantly, I also recommend that we should not include Galactic coordinates either.
(Chiang) I think it is probably better to draw the line after adding Galactic coordinates. I am often asked by people who are browsing the data using fv, ds9, ROOT, etc. why we don't have Galactic coordinates in the FT1 file, especially since in gamma-ray astronomy it is incredibly useful to know the location of a source relative to the Milkway.
13. Live time
(Digel) Way back when (until early 2003), the events file was defined to include a column called 'Deadtime' which was to be the 'Deadtime accumulated since the start of the mission.' It was removed, partially because Masa pointed out that information that relates specifically to the LAT belong in the FT2 file. Also, live time turns out to be more convenient to work with.
...
(McEnery) I think that we should define this so that 0 is the bottom (thick) of the tracker and 15 is the top (thin) layer. This is consistent with the definition used in the reconstruction code, but is opposite to the current definition (where 0 is the top of the tracker).
(Chiang) If we keep CONVERSION_LAYER as a column, then I would go even further and include in the numbering scheme the tracker layers that do not have radiators. This would help guard against any ambiguity regarding where the conversion occurred since we would be using the same layer ids that are used in the reconstruction code. However, ultimately, we may choose to omit the CONVERSION_LAYER information in favor of an EVENT_CLASS variable.
19. EVENT_CLASS
(Chiang) There would be a one-to-one correspondence between IRF "subtypes" and possible EVENT_CLASS values. Presently, there are only two possible event classes, Front and Back, indicating in which set of radiators the conversion occurred. As the instrument calibration and IRF implementation evolve, there will likely be more classes than just two. An advantage of using EVENT_CLASS over something like CONVERSION_LAYER is that such a scheme helps ensure that the user will only be able to make cuts that are supported by our IRF implementations.