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

2. R.T. Jones, Newport News, May 22 2006 2 Outline 1.The GlueX experiment 2.Data flow model for GlueX 3.Major simulation components detector geometry+fields description detector state description detector response and noise event source(s) output event stream(s) 4.Status and plans

3. R.T. Jones, Newport News, May 22 2006 3 1. The GlueX experiment mesons with excited glue 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: online offline David Lawrence David Abbott reconstructionanalysissimulations fastphysics Paul Eugenio Richard Jones

4. R.T. Jones, Newport News, May 22 2006 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. R.T. Jones, Newport News, May 22 2006 5 Monte CarloData Acquisition reaction specification digitized signals in buffers generationevent building final stateraw event record simulationconversion hits tracks /clusters final state geometric reconstruction kinematic reconstruction 2. Data flow model for GlueX

6. R.T. Jones, Newport News, May 22 2006 6 geometry and fields event record (MC data + hits) Monte Carlo generator Simulation engine 3. Major simulation components command and control auxilliary results simulation log

7. R.T. Jones, Newport News, May 22 2006 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 MCfast  interface to MCfast completed and tested Geant3  interface to Geant3 completed and tested  project web site http://zeus.phys.uconn.edu/halld/geometry

8. R.T. Jones, Newport News, May 22 2006 8 Detector geometry + fields description Developments since 2001:  creation of schema for geometry package  upgrade to new XERCES-C v2 from Apache.org ROOT  interface to ROOT (visualization) added by E. Brash  magnetic field map regions introduced GEANT4  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. R.T. Jones, Newport News, May 22 2006 9 Detector geometry + fields description Why not switch to GDML? Why not switch to GDML? Region definitions  no support for Region definitions (eg. magnetic fields) detector identifiers  no support for detector identifiers  less flexible scheme  less flexible scheme for placing multiple copies  less human-readable  less human-readable than AGDD (overuse of IDREF’s) GEANT-centric  provided parsing tools are GEANT-centric Why extend AGDD? Why extend AGDD? Region definitions  no support for Region definitions (eg. magnetic fields)  rapid development cycle  rapid development cycle needed for new projects schema  our schema (instead of the Atlas DTD) allows more powerful means to constrain user input to provide sensible results.

10. R.T. Jones, Newport News, May 22 2006 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: significantly affect the flow of particles and energy 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. R.T. Jones, Newport News, May 22 2006 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: track-level simulation issues hit-level simulation issues 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. R.T. Jones, Newport News, May 22 2006 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. R.T. Jones, Newport News, May 22 2006 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 genr8  interface to genr8 completed and tested hdfast  interface to hdfast completed HDGeant  interface to HDGeant completed  project web site h ttp://zeus.phys.uconn.edu/halld/datamodel/doc

14. R.T. Jones, Newport News, May 22 2006 14 http://zeus.phys.uconn.edu/halld/datamodel/doc Example: MC event stream packed binary … event data ordered as shown above follows in packed binary …

15. R.T. Jones, Newport News, May 22 2006 15 http://zeus.phys.uconn.edu/halld/datamodel/doc... Example: MC event stream, decoded

16. R.T. Jones, Newport News, May 22 2006 16 Existing HDDM tools: http://zeus.phys.uconn.edu/halld/datamodel/doc 4hddm-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 4hddm-xml:converts an hddm stream into a xml listing 4xml-hddm:converts a xml listing back to an hddm stream 4stdhep-hddm:converts stdhep files into an hddm stream 4hddm-schema:reads an hddm template, writes a xml schema 4schema-hddm:reads a xml schema, writes an hddm template 4hddmcat:concatenate multiple similar hddm streams 4xml-xml:pretty-print free-format xml for viewing HDDM: self-describing event streams

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