S. Digel, 16 April 2005
The current draft (as of this writing, April 15) of the ICD is available here, which includes science data products passed between the ISOC and the GSSC, the GBM SOC and the GSSC, and science data products generated at the GSSC (and delivered to itself).
The ICD is only approximately an interface control document; it doesn't specify how the data are to be transferred but does describe the contents and formats (FITS) in detail, along with expected sizes and delivery frequencies.
The ICD originated with the work a few years ago of something called the Data Products Working Group, which was established by the then mission ground systems manager to get the LAT, GBM, and GSSC to talk to each other about expected data products and, wherever sensible to standardize the formats. The current ICD recognizably descends from the report of the DPWG.
Here is my understanding of the status of the LAT ISOC products currently in the ICD. (They are designated LS-###, with the L meaning generated by the LAT team and the S meaning received by the GSSC.) For the lower-level data products, we certainly care about the details of the definitions of the data products now, because we are using them with the science tools. For the higher-level products the driver for making good definitions now is that according to the development plan for the ground system, the GSSC needs to be able to receive (interpret, ingest) all of the science data products by early 2006 (I think).
Note that there's no Level 0 data on this list. That is because it is technically not a science data product, I guess because it comes from the MOC. Also, the GSSC will receive the Level 0 data directly from the MOC.
Are any science data products missing from the list below?
LS-002 Event Summary Data - The specification in the draft is quite out of date. The current FT1 is fine, I think, except that we will want to update the classification information that we stuck in for DC1. Also, Masa has summarized on the FITS Format Definition Working Group page some issues regarding the definition of FT1, e.g., the inclusion (or not) of direction and energy uncertainties.
LS-003 Low-level Calibration - We are not close on this, but it isn't (directly) a science tools issue. The low-level calibrations and their representations (in XML or in MySQL tables, I think) are still being sorted out. If LS-003 is a FITS product I think it is safe to say that we will not have any software that actually uses it although the intent in making this a deliverable data product is so that reconstruction, or calibration in general, could be reproduced (say, after the mission). That is certainly a worthy end, and I am not sure how to sort this out. [Late-breaking news: Richard and David seem to agree that this won't need to be in FITS; these are delivered as is.]
LS-004 LAT Instrument Response Functions - This is the CALDB representations of the Aeff, PSF, and energy redistribution functions. We had this for the DC1 response functions, and all of the machinery exists to actually use them with the science tools. CALDB is extremely flexible in how response functions can be specified, and we really don't know yet how we want to do it for DC2. Still, for the sake of the ICD it should be enough to specify that the response functions will be delivered in legal CALDB format and leave it at that.
LS-005 Pointing and Livetime History - The version in the draft ICD looks like what we actually are using (as FT2). We may end up using different time intervals in the tables, but that will not affect the format at all. See the issues that Masa has documented.
LS-006 Configuration History - This is another well-intentioned data product to allow retrospective reprocessing of the data, and its definition is not directly a science tools issue. Actually, the description in the draft ICD says that it is a record of all of the configuration register settings on the LAT. We won't have any software on the science tools side that uses this data product directly, and I think a FITS version would be of limited utility. Also, this may overlap an operations data product. Certainly somewhere we will be keeping track of this information. The GSSC is to receive all of the information that will be needed to maintain a processing and analysis capability. So I'm not sure how this should be sorted out.
LS-007 Transient Parameters - This was written to be the data product delivered when an alert is issued for a flaring source. It is probably ok, although certainly subject to refinement.
LS-008 LAT Source Catalog - This can be updated, based on discussions within the source catalog working group. Basically, we have converged on something simpler.
LS-009 Burst Catalog - Well, if we don't make a catalog of LAT bursts, then someone else will. The current specification is probably ok, but probably needs another look by the GRB science team.
LS-010 Interstellar Emission Model - I'd be inclined to go with the MapCube (GALPROP-derived) model that we are working on now. This may be refined as a result of the workshop next month. In any case, whatever format we use will be compatible with the science tools - we'll be sure of that.
All of the LS-### data product definitions need careful scrubbing regarding HEASARC conventions for keyword names and units of quantities, HDUCLASS keywords, etc. Also data product file names and sizes and delivery frequencies should be connected to the current understanding of reality (ideally traced to requirements documents, of course).