S. Digel, 21 September 2005
The checkout ends on Monday. No action yet in the Checkout 3 Confluence pages, where reports from reviewers will be collected. Some reviewers are specifically using Windows; Tom Stephens is running tools on Linux and Windows and comparing the results.
In no particular order, here are issues that I am aware of other than what has been reported and discussed in JIRA.
The problem generating photons that provide the right light curve for the checkout 3 gamma rays was traced to PulsarSpectrum's implicit assumption that the spacecraft position would always be analytically calculated and to a problem (obscure, I'd guess) with reading the spacecraft positions in the astro package (Razzano, Chiang). The problem may be solved in the latest incremental release (v6r0p3).
Julie had been interested in regenerating the checkout 3 data to clean it up for posterity. At this point, posterity is all it is worth cleaning up for. If it is regenerated, we should be sure to start with an FT2 file with the correct MJDREF. Also, if it is regenerated, we'll have a live time fraction <1.
Francesco pointed out that the GBM files have times measured with respect to the official MJDREF (Jan. 1, 2001) vs. what we used for Checkout 3 (Jan. 1, 2007). This causes him problems in running gtbin, and maybe other problems. Nicola is looking into where the shift back to the official MJDREF occurs; I guess the symptom is as if gtbin does not use absolute times for binning, which is entirely plausible.
Aside from the MJDREF issue, not-completely-standard definitions of the formats of the event files have caused some problems. At the level of the names of the extensions, and how GTIs are used, we have to be on the same page.
No profound problems have been reported with GRB analysis, likelihood analysis, or pulsar analysis, although successes have not been reported either.
Working mostly. The installer now includes the MSVCR71D.dll Microsoft C runtime library (as well as the MSVCR71.dll for the day when we distribute non-debug builds) with the tools. This, and including it in the Path defined in the wrapper scripts of the tools that for one reason or another need this DLL, makes most of the tools run. The exceptions are gtburstfit, gtobssim, and gtorbsim, which think they need MSVCR71D.dll, but the RM does not provide a path to it in the wrapper scripts. This is apparently a subtle problem of dependencies and maybe of CMT and has not been subject of a quick-and-dirty fix.
Gino Tosti (and I) have not been able to run gtbin under Windows, getting a PIL exception after the first prompt. I hope to play with this some more. I also need to post Gino's report to Confluence; he has tried most of the tools under Windows, all except the ones that use XML files.
ModelEditor does not connect to ds9, but I don't know if that is a solvable problem [answer: Maybe]. Otherwise, ModelEditor does seem to run.
Also, a real, live, actual new user pointed out that the Workbook instructions on installing the science tools don't actually get around to describing what the bin directory is for or how to run the tools, e.g., by modifying the Path variable.
The wrapper scripts for the tools set up PFILES to point to the parameter file that is in the pfiles directory of the directory tree for the tool currently being run. This is not particularly convenient, and there may be no straightforward way to override this by having the equivalent of, say, setenv PFILES "." in one's .cshrc file. [This has been solved, although I guess I jumped to the conclusion that the user will want the current working directory to be the place where the parameter files are written. Some rational users prefer to have them collected in a separate directory.]
In general, running the science tools under Windows would be more convenient if the general (futility-type) FTOOLS were available under Windows, too, but they are not. Francesco points out that Xspec is not available for Windows, either.