...
(Foschini) Perhaps it is better to keep all the above keywords in the events and GTI extensions and left blank the primary header. The latter is generally not used by common data analysis software.
(Stephens) I think they should stay in all the headers. The idea is that each extension can stand alone if necessary and have the relevant keywords. The only reason to leave them in the primary header is for
informational purposes. i.e. you just have to read the primary header and you know what the file is about.
2. HDUCLASS keywords
(Digel) I am not sure whether we adhere to the strict definition of a HDUCLASS1 = EVENTS file. The only column that we have in common with the specification of The Recommended Columns and Keywords for a FITS Event List is TIME.
...
(Foschini) OBS_ID can be used to identify the observation proposal of Guest Investigator programs, that should be activated during the second and the following years of operations. The OBJECT would be the on-axis target. With this respect I suggest to add also 4 more keywords, namely RA_SCX, DEC_SCX, RA_SCZ, DEC_SCZ for the equatorial coordinates (J2000) of the spacecraft X and Z axes during that particular pointing. This in the EVENTS HDU only. These keywords could be of help also during other observations to identify the centre of the field of view.
(Stephens) The GLAST data as planned to be distributed does not have pointings in the traditional sense
and there will be a lot of data that doesn't correpsond to a proposal from the GI program. The RA_SCX, DEC_SCX, RA_SCZ, DEC_SCZ keywords are mostly meaningless for the data as the spacecraft is constantly moving. The center of the "field of view" for the data extraction is already identify by the Data
Subspace Selection (DSS) keywords. It would be possible and might be of use to duplicate this in the
OBJECT keyword but I think the OBS_ID keyword would go away.
5. MC_TRUTH keyword
(Digel) I think that the original intent was that this keyword indicate whether the data are entirely Monte Carlo truth values (i.e., actual directions, energies, etc.). We do not actually have files like this, and I propose removing this keyword. gtobsssim does add a column MC_SRC_ID to the files it generates, but this is easy enough to check for without the MC_TRUTH keyword.
(Stephens) Actually I thought this was a flag like the old PSR_COLS keyword and indicated that there
were additional MC columns in the file. As we don't use this I think it can go away.
6. EVENT_ID column
(Digel) This is specified as a 32-bit integer. Right now, most likely the event IDs will be assigned by the LAT as a time stamp. Most likely we will need more than 32 bits to represent them, and of course they should look more or less like some kind of integer representation of the value in TIME. Right now, I don't know what to recommend for EVENT_ID.
...
(Digel) These are needed (and filled) by the pulsar timing analysis tools. I don't know whether they belong in the definition per se of the event file, because they can be added by the pulsar tools, but I don't feel particularly strongly if they stay. I do recommend that we make them floating point values instead of their current doubles.
(Stephens) They belong in the definition as they can be in the file, Even if they are not there in the
files delivered from the data server.
12. SKYX/Y issue
(Digel) The Guidelines for Science Tools Design page lists one outstanding issue for the definition of the events file, whether to add columns that give the coordinates of the events in some coordinate projection.
...