Design considerations in the prototype and areas of work

• Detail level of the simulation runtime selectable by subsystem
  • Work: examine how best to manage coexisting representations -- simple pointer-based scheme selecting among defined geometries or Geant4 tools supporting multiple representations
• Different detector representations constituted by
  • different volume trees under a shared mother envelope
  • detector response mechanisms associated with each representation
    • Work: examine compatibility of current Geant4 sensitive detector/hits design with the broadened notion of a detector response object that can encompass a parametrized treatment of the response
      • the 'sensitive detector' must in this case invoke a treatment that itself manages the propagation of the particle to the back of the detector (or stops it) and then returns control to Geant
      • output now a reconstruction-level object, not a 'hit'
    • Work: examine whether the sensitive detector mechanism is the way to wrest tracking control from Geant within a parametrized detector, or is a UserTrackingAction the way to do it, and if so, how to couple a detector's UserTrackingAction to its LogicalVolume representation?
    • Work: implementation work on parametrized treatment of DRC, EMC, IFR detectors could be begun with the present BaBar prototype
• Compatible with support for a range of tracking system treatments
  • smearing at 4-vector level; tracking may still be used to eg. find entry points at the outer detectors
  • swim track and build error matrix in idealized geometry accounting for material and measurement uncertainty, a la trkerr and MCFast
  • hit generation in fast geometry
  • hit generation in fully detailed geometry
  Work: there's an interesting and rewarding piece of work in building a fast tracking capability for Geant4 along the lines of trkerr and MCFast, exploiting optimized tracking in a constrained, idealized geometry within modelled tracking detectors and Geant4's heavily optimized volume navigation capabilities between volumes to track between detectors. Interest from MCFast, CDF, (...?) in working on this.
• Prototype should demonstrate the geometry and code migration path from BBSIM to Geant4-based simulation
  • Work: once the essential geometry types are available, existing BBSIM C++ code -- in particular the IFR -- can very easily be migrated to Geant4 and reorganized as a single code supporting both BBSIM and Geant4. Might motivate similar moves to C++ in other subsystems.
  • Work: the redesign of C++ IFR geometry, or new design work on other subsystems, to design geometry classes that encapsulate the geometrical information presently from the dbio database and generate the information to build a Geant4 representation could be begun now (restricting the target geometry primitives to the Geant3 set plus possibly those already in Geant4, given the rate of progress on Geant4 geometry)
  • Work: examine the state of hits and digitization thinking in Geant4 relative to BaBar, and flesh out and prototype a BaBar approach in the Geant4 context, giving design input to Geant4 in the process.
  • NB. the Gilchriese review endorsed our simulation design but asked for greater elucidation of the BBSIM to Geant4 migration path design and code reuse
• Prototype should demonstrate migration path to long term technologies
  • dbio to OODB: back end of the geometry classes is an encapsulation of the geometry database parameters that can be swapped out for a (quite possibly different) OODB representation without affecting either the code external to the classes or the class-internal methods building the required geometry information
  • XDR to OODB: Geant4's timescale suggests that in the next 6 months we should have Objectivity available in the prototype and can implement dual XDR and OODB output capability. Need to enunciate in general how it would work for the Sept review.
• Support the use in the prototype of a geometry identical to that of BBSIM. Capability is available from the G3toG4 package which converts an arbitrary G3 (ie. BBSIM) geometry to Geant4. Motivation is to evaluate physics performance (and benchmarking) of G4 relative to G3 under identical geometrical conditions.
• Framework compatibility
  • At an early stage, if not from the very beginning (certainly isn't in the Framework right now), incorporate into the Framework for effective coupling to reco/analysis, seamless connection to Framework hits/digitizations, access to graphics, etc.
  • NOT a released component of SRT buildable in the usual way. Geant4 will not be a SRT package.