GLAST Large Area Telescope: LAT Science Analysis Software’s Use of Gaudi & ROOT Heather Kelly

1. Gamma-ray Large Area Space Telescope GLAST Large Area Telescope: LAT Science Analysis Software’s Use of Gaudi & ROOT Heather Kelly NASA Goddard Space Flight Center Science Systems and Applications Inc. For the GLAST LAT Collaboration SAS heather@slac.stanford.edu http://www-glast.slac.stanford.edu/software

2. GLAST Mission GLAST measures the direction, energy and arrival time of celestial gamma rays • LAT measures gamma-rays in the energy range ~20 MeV - >300 GeV • There is no telescope now covering this range!! - GBM provides correlative observations of transient events in the energy range ~20 keV – 20 MeV Launch: August 2007 Florida Orbit: 565 km, 28.5o inclination Lifetime: 5 years (minimum; 10 yrs goal)

3. GLAST Participation France Germany Italy Japan Sweden USA NASA - DoE Partnership on LAT LAT is being built by an international team Stanford University (SLAC & HEPL, Physics) Goddard Space Flight Center Naval Research Laboratory University of California, Santa Cruz University of Washington Ohio State University CEA/Saclay & IN2P3 (France) INFN & ASI (Italy) Hiroshima University, ISAS, RIKEN (Japan) Royal Inst. of Technology & Stockholm Univ. (Sweden) GBM is being built by US and Germany MPE, Garching (Germany) Marshall Space Flight Center Spacecraft and integration - Spectrum Astro LAT managed by SLAC PI – Peter Michelson

4. 0.01 GeV 0.1 GeV 1 GeV 10 GeV 100 GeV 1 TeV Active Galactic Nuclei Solar flares Unidentified sources Cosmic ray acceleration Pulsars Dark matter Gamma Ray Bursts GLAST science - the sky above 20 MeV

5. ACD Segmented scintillator tiles 0.9997 efficiency  minimize self-veto Data acquisition GLAST Large Area Telescope (LAT)  Si Tracker Tower pitch = 228 µm 5.52 104 channels 12 layers × 3% X0 + 4 layers × 18% X0 + 2 layers Good Energy Resolution DE/E ~ 10%; 100 MeV – 10 GeV ~ < 20%; 10 GeV – 300 GeV Single Photon Angular Resolution 3.5o@ 100 MeV 0.15o@ 10 GeV Grid (& Thermal Radiators) e+ e– 3000 kg, 650 W (allocation) 1.8 m  1.8 m  1.0 m 20 MeV – 300 GeV CsI Calorimeter Hodoscopic array 8.4 X0 8 × 12 bars 2.0 × 2.7 × 33.6 cm • cosmic-ray rejection • shower leakage correction 16 identical towers 300 Hz average downlink

6. GLAST Concept Low profile for wide f.o.v. Segmented anti-detector to minimize self-veto at high E. Finely segmented calorimeter for enhanced background rejection and shower leakage correction. High-efficiency, precise track detectors located close to the conversions foils to minimize multiple-scattering errors. Modular, redundant design. No consumables. Low power consumption (650 W)  Charged particle anticoincidence shield Conversion foils (W) Particle tracking detectors e+ e- • Calorimeter • (energy measurement) g detection – pair conversion telescope Pair production is the dominant photon interaction in our energy range

7. A Special Note • This talk discusses the LAT data format and software. • FITS and FTOOLs will be delivered to the user community. • Science End-Users view GLAST data as photon lists, tend to be taken in aggregate. • LAT team looks at data on an event by event basis. • Upon triggering GLAST freezes its detectors and writes out its buffers. • Once on the ground, the game is to separate gammas from background. (1000:1) • Determine best estimate for direction and energy. • Part of the LAT collaboration’s job is to provide the highest quality photon lists to the science user community.

8. Some Background • ~25 developers distributed across 9 time zones • VRVS (www.vrvs.org) and Instant Messaging (ICQ/Gaim) • Face-to-Face meetings twice a year • Close-knit team • Support Windows, Red Hat Linux, (perhaps Mac OS X) • Why Windows??? Visual Studio Development Environment • Currently ~35 MB of source code for: • Detailed Monte Carlo Simulation • Reconstruction and Calibration algorithms • I/O infrastructure • GLAST LAT software is open and available to anyone who wants it. • Brookhaven group - KOPIO • C++ was adopted for coding efforts – early on • By 1999, we had detailed Monte Carlo simulation and prototype reconstruction code. • This was before the proposal!!!

9. Why Use a Framework? • By 1999, we had plenty of code – but it was unmaintainable. • Our MC generator was custom built, planned move to Geant4 • Looked to re-use existing code as much as possible • HEP offered a number of packages: CLHEP, Geant4 • Small team, of distributed programmers, with varying amounts of OO C++ programming experience. • Provide one code system for simulation, test data analysis, and flight operations. • Needed organization and clear lines of division between the components of our code. • Flexible • Extensible

10. Gaudi Framework • An Object Oriented C++ Framework • “The implementation of an architecture which defines a structure flexible enough to support all types of physics data processing needs..from simulation to analysis to visualization.” • http://proj-gaudi.web.cern.ch/proj-gaudi/welcome.html • Promotes the creation of small maintainable components which can be loaded at runtime • Components = algorithms, services, I/O, etc • Standard Gaudi interface for each type of component • Embraces the division of data from algorithms • Gaudi provides a number of basic services such as: • Event Data Service (TDS) – a fancy OO common block! • Messaging and Logging Services • Infrastructure for I/O where various output formats may be supported • Provides standard event loop • Job parameters are handled via an input ASCII file • Optional Python interface

11. Example of Using Gaudi Tools Retrieve tool by name via base class    IEnergyCorr* m_lastLayerTool;    sc = toolSvc()->retrieveTool(m_lastLayerToolName, m_lastLayerTool);  m_lastLayerTool->setTrackSlope(slope);  m_lastLayerTool->doEnergyCorr((*it)->getEnergySum(),(*it)); Refer to base class functions. Does not know which concrete tool it is. Concrete classes that customize behaviour Tools id’ed by name in ascii config file (“jobOptions”)

12. Data flow in the Gaudi framework Source Generators Raw data Level 0 SimulationAlgorithms G4 Root TransientDataStore PersistencyAlgorithms DigitizationAlgorithms ACD, TKR, CAL, Trigger NtupleService Level 1 ReconstructionAlgorithms User-DefinedAlgorithms Ready for astronomy ACD, TKR, CAL Ntuple MC Real Data

13. Gaudi Interface to Geant4 Usurp this! http://www-glast.slac.stanford.edu/software/core/documentation/reviews/G4Generator/g4greview.pdf

14. FRED: Our Event Display

15. What is ROOT? • http://root.cern.ch (circa 1995) • A floor wax and a dessert topping • Machine independent file format • An analysis toolkit written in C++ • Created to address the needs of large scale data analysis • Object I/O • Self-describing files • Utilizes gzip algorithm for compression (user controlled) • Typically store event data in trees • C/C++ interpreter for command line analysis • PyROOT – python interface

17. Pretty Pictures

18. Why ROOT? • As of 1999, our output was tab-delimited ASCII ntuples • GLAST code is Object-Oriented C++ • A OO friendly file format seemed better suited for our needs • Store our objects “as is” in ROOT • Either read them back into our sim/analysis framework • Or use ROOT/JAS or any ROOT capable analysis toolkit to perform analysis. • Open-source, widely used within the HEP community • Well supported and good user documentation • Pledged backward compatibility • Development is actively extending and improving the system • Planning support for multi-core • Adding context-sensitive help

19. Persistent ROOT Output • Four types of ROOT files: MC, Digitization, Reconstruction and ntuple. • Two Levels of Output at end of Reconstruction: • Root Trees • Basically, all the output of all steps of reconstruction • Enough information to read back in and continue reconstruction from that point • Detailed offline analysis for reconstruction algorithm improvements • Main component of System Tests • Output Ntuple • A detailed branch which contains enough information for checking of reconstruction performance • The analysis data which is ultimately FITisfied.

20. Provides standardized structure Free, source code available Pick and Choose Components Python Interface OO Not well documented Steep learning curve Slow start up during loading Requires use of DataObject interface Advantages and Disadvantages GAUDI DISADVANTAGES ADVANTAGES ROOT • Steep Learning Curve for users unfamiliar with OO • C/C++ interpreter can be flaky • Up to now, has required use of TObject interface • Open-source • Strong user support and documentation • OO • Python interface • Extending capabilities

21. Have you seen these men? Navid Golpayegani P.13Release Manager Tony Johnson P.24JAS3 Richard Dubois P.7Overview of SAS Tom Stephens P.61SSC Data Server Max Turri P.26Scientific plotting Dan Flath P.35Data processing Pipeline