The GlueX Simulation Framework

1. GEANT4 Tutorial Workshop Newport News, May 22-26, 2006 R.T. Jones, UConn The GlueX Simulation Framework Monte Carlo detector simulation analysis

2. Outline • The GlueX experiment • Data flow model for GlueX • Major simulation components • detector geometry+fields description • detector state description • detector response and noise • event source(s) • output event stream(s) • Status and plans

3. 1. The GlueX experiment • a major new experiment to search for mesons with excited glue, requiring a new hall (D) and 12 GeV. • ~80 physicists representing 30 institutions. • Software working group: offline online David Lawrence David Abbott simulations reconstruction analysis fast physics Richard Jones Paul Eugenio

4. Simulations toolbox for CDR (ca. 2002) • MCFast (HDFAST) • reliable for acceptance, resolution • sufficient for many detector design decisions, PWA studies • 100 events/Gflops-cpu • in production until end of 2004 • Geant 3 (HDGeant) • reliable for e-m interactions, backgrounds • sufficient for development of reconstruction software • 10 events/Gflops-cpu • in production 2001 – present • major components designed for re-use with Geant4

5. 2. Data flow model for GlueX Monte Carlo Data Acquisition digitized signals in buffers reaction specification generation event building final state raw event record simulation conversion hits geometric reconstruction tracks /clusters kinematic reconstruction final state

6. 3. Major simulation components Monte Carlo generator geometry and fields command and control Simulation engine simulation log auxilliary results event record (MC data + hits)

7. Detector geometry + fields description • Decided collaboration mtg 3/2001: • standard geometry interface is needed • various simulation packages (MCFast, Geant, …) • reconstruction • event display • should be expressed in xml • Completed 5/2001: version 1.0 (based on AGDD) • prototype description of entire detector • interface to MCfast completed and tested • interface to Geant3 completed and tested • project web site http://zeus.phys.uconn.edu/halld/geometry

8. Detector geometry + fields description • Developments since 2001: • creation of schema for geometry package • upgrade to new XERCES-C v2 from Apache.org • interface to ROOT (visualization) added by E. Brash • magnetic field map regions introduced • interface to GEANT4 added by J. Langheinrich New interfaces are simple to build based on base classes that “walk” the xml geometry tree and extract relevant information.

9. Detector geometry + fields description • Why not switch to GDML? • no support for Region definitions (eg. magnetic fields) • no support for detector identifiers • less flexible scheme for placing multiple copies • less human-readable than AGDD (overuse of IDREF’s) • provided parsing tools are GEANT-centric • Why extend AGDD? • no support for Region definitions (eg. magnetic fields) • rapid development cycle needed for new projects • our schema (instead of the Atlas DTD) allows more powerful means to constrain user input to provide sensible results.

10. Detector state description • Detector state: run-dependent refinements to the geometry • detector alignment survey data • dead electronics channels • broken or shorted wires in a drift chamber • etc. • Policy decision: Any detector state information which can significantly affect the flow of particles and energy in the detector must be incorporated into the simulation geometry. Small alignment corrections, dead channel information and the like are not a part of the geometry description provided to the simulation, but must be applied as run-dependent corrections to the simulated data in a separate step prior to reconstruction.

11. Detector response and noise • Detector response: • conversion of energy deposition to pulse height • addition of statistical or sampling noise into the time or pulse height • introduction of electronic noise hits to the event • elimination of some hits due to inefficiencies. • Policy decision: The simulation must carry enough detector response capability to know how to add up the contributions from all particles in the event that contribute to the signal in a given electronics channel, ie. light attenuation, double-pulse resolution, and pileup are track-level simulation issues. Beyond that, all detector response corrections may be treated as hit-level simulation issues and be applied as to the simulated data in a separate step prior to reconstruction.

12. Event source(s) • Primary event source: external MC generator • existing legacy HEP tools • MC info must be copied to output stream • use uniform interface for event input and output • Other event sources: • internal single-particle generator (provided) • photon beam generator (interfaced)

13. I/O event streams • Decided at collaboration meeting 5/2001: • standard data model is needed • should be expressed in xml • Completed 9/2001: version 1.0 • data model for Monte Carlo generator samples • interface to genr8 completed and tested • interface to hdfast completed • interface to HDGeant completed • project web site http://zeus.phys.uconn.edu/halld/datamodel/doc

14. Example: MC event stream <HDDM class="s" version="1.0"> <physicsEvent eventNo="int" runNo="int"> <reaction type="int" weight="float" minOccurs=“1” maxOccurs=“unbounded”> <beam type="Particle_t"> <momentum px="float" py="float" pz="float" E="float" /> <properties charge="int" mass="float" /> </beam> <target type="Particle_t"> <momentum px="float" py="float" pz="float" E="float" /> <properties charge="int" mass="float" /> </target> <vertex minOccurs=“1” maxOccurs=“unbounded”> <product type="Particle_t" decayVertex="int" minOccurs=“1” maxOccurs=“unbounded”> <momentum px="float" py="float" pz="float" E="float" /> <properties charge="int" mass="float" /> </product> <origin vx="float" vy="float" vz="float" t="float" /> </vertex> </reaction> </physicsEvent> </HDDM> … event data ordered as shown above follows in packed binary … http://zeus.phys.uconn.edu/halld/datamodel/doc

15. Example: MC event stream, decoded <?xml version="1.0" encoding="UTF-8" ?> <HDDM class="s" version="1.0” version=“1.0” xmlns=“http://www.gluex.org/hddm”> <physicsEvent runNo="-9000" eventNo="1"> <reaction type="0" weight="0.000000"> <vertex> <product type="pi-" decayVertex="0"> <momentum E="5.937384" px="-0.197764" py="0.586868" pz="5.903338" /> <properties mass="0.140000" charge="-1" /> </product> <product type="pi+" decayVertex="0"> <momentum E="1.947875" px="0.001550" py="-0.182470" pz="1.934249" /> <properties mass="0.140000" charge="1" /> </product> <product type="proton" decayVertex="0"> <momentum E="1.052739" px="0.196214" py="-0.404399" pz="0.162411" /> <properties mass="0.938000" charge="1" /> </product> <origin t="0.000000" vx="0.000000" vy="0.000000" vz="0.000000" /> </vertex> </reaction> </physicsEvent> <physicsEvent runNo="-9000" eventNo="2"> . . . http://zeus.phys.uconn.edu/halld/datamodel/doc

16. HDDM: self-describing event streams Existing HDDM tools: • hddm-c:creates a c i/o library from a xml data model • hddm-c++: creates a c++ i/o library from a xml data model • hddm-xml:converts an hddm stream into a xml listing • xml-hddm: converts a xml listing back to an hddm stream • stdhep-hddm:converts stdhep files into an hddm stream • hddm-schema: reads an hddm template, writes a xml schema • schema-hddm: reads a xml schema, writes an hddm template • hddmcat: concatenate multiple similar hddm streams • xml-xml: pretty-print free-format xml for viewing http://zeus.phys.uconn.edu/halld/datamodel/doc

17. Status and plans • Goal: produce a working prototypeHDGeant4by end of 2006. • Component milestones: • hdds-g4 – complete project in collaboration with Hall B • hddm-c++– complete work on existing prototype • MC input – customize PrimaryGeneratorAction for MC input • readout –newG4readout classes for each subdetector • physics – create an appropriate list of physics processes • test – benchmark new simulation against HDGeant3 • Other pieces: run specialization, response packages