GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Analytical Objectives for Science Tools for DC2 for DC2 S. W. Digel Stanford Linear Accelerator Center Gamma-ray Large Area Space Telescope

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Outline Goal of this talk/discussion is a prioritized list of new tools/features to be implemented for DC2 –Is a goal the same thing as an objective? –My presentation is subjective: The requirements and goals for science analyses in DC2 need to be written down some place with more detail than in a PowerPoint presentation Standard Analysis Environment vs. ‘Science Tools’ Summary of status of SAE Some SAE objectives for DC2 not already discussed this week –and some SAE tools that are explicitly not part of DC2 Other objectives for Science Tools for DC2

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Science Tools & the SAE ‘Science Tools’ has been a catch-all term for the tools for astronomy –This is not my term, and should not be taken to imply that what comes before is not science The Standard Analysis Environment is the collection of science tools being developed jointly with the GSSC for high- level analyses of LAT (or LAT + GBM) data. –Conceptually SAE is a subset of Science Tools

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Status of SAE tools* Likelihood analysis [list the tools – with mapping to initial designations] –gtcntsmap, gtdiffresp, gtexpmap, gtlikelihood, gtlivetimecube, gtpsf, gtsrcmaps, gttsmap Source identification –gtsrcid Pulsar analysis –glbary, pulsePhase, gtpsearch, gtpulsardb, blind period search GRB analysis –gtevtbin, gtrspgen (pathway to Xspec), and new temporal analysis tool, spectral-temporal model fitting Observation simulation (high-level) –gtorbsim, gtobsim Utilities –gtselect –event display (to be a Web service) Status key Already used in at least one checkout Prototype exists Does not exist yet * Updated from Diffuse & Source Catalog workshop, May 2005

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Notes on status Development model is spiral – iterations with evaluations (science tools checkouts and data challenges) –6-week build cycle adopted after DC1 (thanks to James Peachey) –‘Already used’ designation does not imply that tool is complete, but is meant to imply that remaining issues are a matter of refinement

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, gtsrcid (w/ catalogAccess) Jürgen Knödlseder has prototyped the source identification tool, using the catalogAccess classes designed by Dirk Petry and implemented by Aymeric Sauvageon The prototype has fairly limited functionality – which is good –Basically v0 can be used to look for positional coincidences between LAT sources and astronomical catalogs –See glast.slac.stanford.edu/sciencetools/workshops/May05DiffuseCat/agenda.htm This is already good enough for DC2; further improvements in functionality are planned in advance of DC2 –The design allows for fairly general identification strategies, e.g., depending on radio flux ratios, or radio & X-ray properties in separate catalogs Quantitative assessments of probabilities of counterpart identification are the ideal, but may not be attainable, and the Catalogs group needs to study this issue and potential alternatives

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Event display (server) From the SAE perspective this is related to the server planned at SLAC that will provide access to the digi and recon information that the event display needs, so that science tools users can look up events by event number Discussion seemed to converge on having a Web-driven event display – no tool to install or support – with either canned views or limited control options Riccardo thinks that this can be done with Fred; I think that Tony may have plans to do it with Wired I can’t say that this should be a DC2 goal. Certainly the data servers at SLAC need to come first.

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, SAE tools that explicitly are not part of DC2 A tool (A4) was originally specified for blind periodicity searches, but we probably will not develop it as part of the SAE –Certainly the LAT team wants to be in this business, but sensitive searches are going to be the work of specialists GRB spectral-temporal modeling (A10) will not be implemented for DC2 –Possibly not ever as a guest investigator tool. It is specified as a very sophisticated modeling tool for simultaneously fitting spectral and temporal variations of a GRB – useful if you have global models with few enough parameters that you can learn something

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Other objectives for Science Tools for DC2 Source detection tool –See Isabelle Grenier & Jean Ballet’s talk in this session GRB detection tool [right?] AGN light curve, … –In general, specialized analysis needs that come from the collaboration science working groups. They may also come with developers Source simulation needs not already covered… Also needed: CALDB representation of IRFs, dotting the i’s on the data product formats, IRF display,ROOT-FITS converter… The Ephemeris Computer tool that Masa Hirayama described today for querying the pulsar ephemeris database will be very useful for pulsar studies in DC2 – It is not formally part of the SAE but it should be not SAE

GLAST LAT Project DC2 Software Workshop, GSFC, June 27-29, Getting to DC2: Priorities for development (Highest to lowest) Taking the data servers for granted, and under the assumption that GBM-related developments are covered by GBM + GSSC, and that diffuse emission model work is covered by the Diffuse CSWG Highest priority should be definition of event classes and characterization of the IRFs; this certainly would benefit from IRF visualization Masa’s tool for querying the pulsar ephemeris file More functionality for GRB temporal analysis tool (A7)? Event display Web service [will also require defining event numbers] [Highest priority for the SAE overall is development of good user-level documentation – not really an analysis objective] [User interface issues – like GUIs – also technically are not analysis objectives]