...
Proposed resolution: Include EVENT_CLASS as Jim describes in place of CONVERSION_LAYER and as a way to encode other classes that we come up with. After discussion with Jim, I think we should also have a column called something like CONVERSION that would indicate, e.g., by value 1,2, or 3 whether the event is FRONT, BACK, or CAL-ONLY. This would be in addition to EVENT_CLASS, although until we have other ways defined to discriminate other kinds of response functions it will have the same value.
...
| Anchor | ||||
|---|---|---|---|---|
|
(30 June 2006) Here are a few more issues that have arisen in the run-up to Ground Readiness Test 5, which has the ISOC transferring a realistic FT1 file to the GSSC, who will verify that it is consistent in every testable way with the detailed specifications in the Science Data Products File Format Document (Word file). The FFD has not been finalized and several loose ends have been recognized regarding the specification of the FT1 headers and columns.
...
Proposed resolution: Modify makeFT1 to write TSTART and TSTOP to 6 decimal places.
21. Names of columns for diffuse responses
(Digel) For analyses with gtlikelihood with models that diffuse emission terms (i.e., most unbinned analyses with gtlikelihood), the overall execution time can be sped up with precomputation of parts of the likelihood function using gtdiffresp. This tool writes new columns to the FT1 files that it processes. The columns are named for the response functions used and the names of the diffuse emission terms in the source model (XML) file. For DC2, the diffuse responses were precomputed in this way.
Tom Stephens has pointed out that the resulting column names (DC2::Extragalactic Diffuse and DC2::Galactic Diffuse for the files that we made for DC2) violate HEASARC standards in a couple of ways. (Note that in these column names DC2 stands for the set of response functions used.) The standards do not allow spaces or colons; the only non_alphabetic or numeric character allowed is '_'.
The space in the source name is easy to get rid of, by using a source model XML file that gives the diffuse sources names without spaces. Actually, in anticipation of the Galactic diffuse emission model being updated fairly often, the names should include a version number anyway, like GalacticDiffuse_v0.
The delimiter between the response function name and the source name can be changed as well (at the startup cost of breaking the use of existing diffuse response columns or maybe writing a tool to change column names in existing FT1 files). Jim confirms that whatever reads the diffuse responses constructs the column name that it is looking for and checks to see whether the FT1 file contains it. For this '_' is just as good as '::'.
We should go ahead with making the change to the delimiter that gtdiffresp writes and gtlikelihood assumes in the diffuse response columns, but because the response functions and standard diffuse models will be changing fairly frequently between now and at least the first year of the mission (making existing diffuse response precomputations only of historical interest, I think that we should not include any diffuse response columns in the FT1 files that we send to the GSSC from here on out.
Proposed resolution: Change the response function-source name delimiter from '::' to '_'. In future, omit diffuse responses in FT1 files that are delivered to the GSSC.
22. AUTHOR, CREATOR, ORIGIN, SOFTWARE and VERSION keywords
(Digel) We are currently carrying these keywords in the definition of the primary header for the FT1 format used by the science tools (ft1.tpl),
but are not usually assigning values to them. In order to pass the verification test of GRT 5, we will either have to remove them or give them (meaningful) values. Here are my suggestions:
AUTHOR - According to the HEASARC recommendations for the CREATOR keyword, AUTHOR is supposed to be a citation of a publication related to the contents of the file. This should be removed; I think that David has already done this in the FFD.
CREATOR - This is supposed to be the name and version of the program that created the file. In the case of FT1 files that are delivered to the GSSC the name would be 'makeFT1'. I suppose that the best choice of version number would be the version of fitsGen (currently v2r4), so the CREATOR string would be 'makeFT1 v2r4'. Can makeFT1 determine its own version number? Otherwise, I think that having to manually edit the template file would be a maintenance problem and the better solution would be to omit CREATOR.
ORIGIN - This should be 'LISOC' for the files that makeFT1 writes.
SOFTWARE - This is defined as the version number of the tool that generated the file; if makeFT1 can determine what its version number is, then we should have it set SOFTWARE accordingly.
VERSION - This is defined as the release version of the file. We used this for the first time with the regenerated DC2 data (assigning them VERSION = 2). I don't think that makeFT1 currently has a way to know what version number to assign. It should optionally take a version number as input, and if none is specified, should set VERSION = 1 in the output file.