Summary of Science Tools Checkout 2, March 21-April 8, 2005

Reviewers (who actually submitted reports - not quite too late)

See News for Checkout 2 for links to the individual reports.  Also see the GLAST Science Tools issues in JIRA, specifically GRB10-13, STGEN10-12, PULS21-24

Overview of reviews

We have definitely made progress since the first checkout.  The checkout uncovered some bugs, which for the most part are fixed by now in the latest incremental release of ScienceTools.  In terms of functionality, we are close to where we'd like to be for DC2, although we are not as close in terms of usability (basically documentation in various forms, clarity of prompting and error handling, and GUIs).

Data access

• We did not explicitly review the server at GSSC, but I did not hear any complaints.

General tools

• I was somewhat confused about what constitutes a science tool, i.e., something we want to distribute for people to use.  map_stats and read_map are not in that category.
• exposure_cube (the close cousin of gtlivetimecube) takes a long time to run and probably does not scale well to year-scale observation times.  If it is fundamentally slow, we may decide that distributing exposure_cube output files (say for one-week or one-month intervals) would be useful.  The files would just add to cover longer time ranges.  We don't (or shouldn't) need both exposure_cube and gtlivetimecube.
• exposure_map maybe should be renamed gtexpmap and the existing gtexpmap should become something else.
• gtselect is limited relative to what cfitsio allows for selection

Observation simulation

• Scaling of execution times with numbers of sources is not proportionate; for some sources, the scaling is worse than others by a factor of a few and simulating a variety of source types in the same model takes significantly longer than the total time required to simulate each individually.
• Some of the timing-related keywords like TSTART are not (or were not) quite right in the FITS files generated by gtobssim
• The ObsSim.py interactive model editor got a good review, once a setup script was manually created.
• The PulsarSpectrum source effectively has source coordinates in more than one place (in the XML file and an ASCII file) for each pulsar.  It isn't clear which ones matter.

Likelihood analysis

• gtcntsmap overlaps the functionality of the generic FTOOL fcopy, and may not be needed
• Prompting order of the tools in the likelihood area may not be quite uniform, and whether 1 or 0 means "free" in source model definitions is not explained.

Pulsar analysis

• glbary still does not like having TSTOP equal to the last time in the FT2 file
• gtpulsardb doesn't complain or quit if the input pulsar name is not found in the database
• pulsePhase does not specify the units for 'epoch' when it prompts for them, and lets you enter any initial phase value

GRB analysis

• Likelihood analysis and XSPEC spectral fitting of GRBs did not report the same fluxes; the discrepancy was by an apparently constant ~20% fraction.  This should be checked to see which is correct (if either).  Potentially this relates to the calculation of response matrices in gtrspgen for XSPEC.
• gtbin initially was not calculating the correct exposure time; some useful FITS keywords are not written or not written correctly.

General question

• Are the tools supposed to report their version numbers when they run?  Some do, some seem to try to but don't appear to know their versions.  Is reporting versions a requirement?