LAT Science Tools: Status

1
LAT Science Tools Status Concept

• Seth Digel
• W. W. Hansen Experimental Physics Laboratory
• Stanford University
• digel_at_stanford.edu

2
Status of Science Tools

• Planning for the standard analysis environment is
  fairly advanced
• the set of analysis tools, utilities, and
  databases to be developed jointly with the GLAST
  Science Support Center
• concept is to include everything that a guest
  investigator (or LAT Co-I) will need for routine
  high-level analysis of LAT data
• Initial definition was undertaken by the SSC-LAT
  science tools software working group
• convened by Jonathan Ormes and Peter Michelson in
  early spring
• SSC representation David Band (science lead),
  Jay Norris (technical management), Bob Schaefer
  (software lead)
• LAT Toby Burnett (simulation software
  architect), Seth Digel (coordinator for science
  tools planning), Richard Dubois (SAS subsystem
  lead)
• meets weekly via VRVS (http//www-glast.slac.stanf
  ord.edu/ScienceTools/slwg/meetings)

3
Science Tools status (2)

• Requirements summaries and use cases
  (step-by-step descriptions of analysis
  procedures) were solicited from the LAT
  collaboration and the SSC to verify the
  completeness of the standard analysis environment
  (http//www-glast.slac.stanford.edu/ScienceTools/t
  ool_defs)
• A science tools software workshop was held June
  12-14 at SLAC
• goals were to review and refine the definition of
  the standard analysis environment, and to
  organize for detailed definition of the
  requirements
• 30 attendees (LAT SSC)
• http//www-glast.slac.stanford.edu/ScienceTools/wo
  rkshops/june02
• The workshop agenda was organized to have
  significant time devoted to breakout sessions for
  detailed discussions
• Conveners of the breakout sessions, selected by
  the SSC-LAT WG for their scientific and software
  backgrounds, sheperded the sessions along,
  reported on the progress, and are on the hook to
  organize the detailed requirements documents

4
Science Tools status (3)

• The development areas and their organizers are
• Databases and related utilities Bob Schaefer
  (SSC), Karl Young (LAT)
• Analysis tools David Band (SSC), Seth Digel
  (LAT)
• Likelihood analysis Pat Nolan (LAT)
• Pulsar-related Masa Hirayama (SSC)
• Source identification Isabelle Grenier (LAT)
• Gamma-ray burst-related David Band (SSC)
• Observation simulation Toby Burnett (LAT)
• User interface Jim Chiang (SSC), Heather Kelly
  (LAT)

5
Science Tools status (4)

• Current work
• defining the requirements in detail
• defining software development standards
• assembling a development schedule based on
  priorities and dependencies
• prototyping some tools and databases
• Must ensure that resources available (FTE-years)
  are consistent with needs so far no significant
  mismatch is indicated
• Next milestone is an internal review (with
  external reviewers) of the requirements and
  development plan, in September

6
Where do the requirements come from?

• The requirements summaries do not distinguish
  them, but several sources of requirements can be
  identified
• Some come from the mandate in the AO that a
  single analysis environment be developed for the
  LAT team and for external users supported by the
  SSC
• relates to integration of tools and the database
  architecture
• Some come from a formal agreement between the LAT
  team and NASAs HEASARC (High Energy Astrophysics
  Science Archive Research Center), literally the
  ultimate destination of the data and analysis
  tools
• e.g., the clear separation of the databases from
  the analysis tools, the requirements that the
  tools read and write FITS files, and the use of
  CALDB for response functions
• Other kinds of requirements
• Functional requirements for what a tool must
  accomplish
• Interface requirements for how a tool receives
  input and delivers output
• Performance requirements for how a rapidly a tool
  must function

7
Concept of the Analysis Environment

• The plan for the high-level analysis environment
  treats the LAT as an astronomical instrument
• Implicit in this assumption is that the
  high-level analysis can proceed with the
  instrument response functions
• IRFs are defined from beam tests and MC
  instrument simulations and monitored in flight
• Also implicit is that background rejection is
  well in hand (i.e., meets performance
  requirements)
• Routine scientific analysis will not require
  modeling the charged particle background or
  making cuts to select good times by geomagnetic
  quantities

8
Components of the Analysis Environment
Flow is generally left to right, from Level 1 to
Level 2
Image/plot display (U8)
Pulsar ephem (D5)
Source model def. tool (U7)
Event display
Level 0.5
Pulsar phase assign (A3)
Likelihood (A1)
Point source catalog (D3)
Data extract (U1)2
Level 1 (D1)1
GRB spectral/temporal analysis (A6)
Src. ID (A2)
Catalog Access (U5)
Exposure calc. (U3)
Pt.ing/livetime extractor (U2)
Pointing history (D2)1
GRB physical modeling (A7)
Astronomical catalogs (incl. D4)
IRFs (D6)
Map gen(U4)
Interstellar emission model (A8)
Pulsar period search (A5)
Pulsar profiles (A4)
1 High-level observation simulators (not shown)
generate alternate versions of these. 2 Data can
also be extracted (sub-selected) from
previously-extracted Level 1 data sets.
9
Walk through

• Event display
• to be inherited from instrument simulation
• no path to higher-level analysis
• reference by event ID, useful for sanity check

10
Walk through (2)

• Connection to Level 1 processing
• intermediate utilities stand between the Level 1
  data and the analysis tools
• exposure calculation is separate as well it
  doesnt care about the source of the
  pointing/livetime information
• exposure calculation must match Level 1
  extraction parameters

11
Walk through (3)

• Known pulsars
• D5 represents timing information (radio)
  maintained during the mission
• after phase assignment, analysis can proceed as
  usual, or periodicity tests applied

12
Walk through (4)

• Other databases as input to high-level analysis
• Instrument response functions PSF, Aeff, Eng.
  res. (RMF)
• Interstellar emission model (tool or database?)
  is unavoidable

13
Walk through (5)

• Image/plot display
• Not actually free floating, resource for analysis
  tools
• Interstellar emission model (tool or database?)
  is unavoidable

14
Walk through (6)

• Source model definition tool
• specification of models (point sources, extended
  sources, diffuse) for likelihood analysis and for
  observation simulation (not shown)
• probably should indicate that the source model
  definitions can be written in files

15
Walk through (7)

• Core analysis tools
• likelihood analysis characterization of point
  and extended sources
• map generation for visualization, export any
  binning required for likelihood analysis will be
  internal to analysis

16
Walk through (8)

• Beyond Level 2
• LAT source catalog is related to likelihood
  analysis, but not connected by a standard
  analysis tool
• astronomical catalogs may be external resources

17
Toward the long-term schedule

• Milestones
• Review of standard analysis environment 2002/Q3
• SAS CDR 2003/Q1
• LAT CDR 2003/Q2
• Mock data challenge I 2003/Q4
• Mock data challenge II 2005/Q1
• Delivery of LAT 2005/Q3
• Review of standard analysis environment
• Requirements definitions for tools/databases,
  management plan, schedule
• SAS CDR
• Requirements definitions for additional (LAT
  team-only) software (e.g., monitoring for
  transients, inflight IRF monitoring,
  high-resolution spectroscopy)
• Progress on open issues, esp. Level 1 database
  and exposure calc.
• Definition of user interface

18
Toward long-term schedule (2)

• LAT CDR
• Example tool (e.g., map generation) to exercise
  programming infrastructure, utilities, and user
  interface
• Instrument response functions in CALDB
• Mock data challenge I
• Observation simulator (pointing history and
  sources)
• Level 1 database
• Core analysis tools, esp. likelihood, and
  supporting utilities
• Mock data challenge II
• All analysis tools and utilities (release 0)
• Delivery of LAT
• Entire standard analysis environment (release 1),
  with documentation
• Keep in mind that the standard analysis
  environment will be developed jointly with the
  SSC, not presented to the SSC in 2005/Q3