LC Detector Full Simulation

1
LC Detector Full Simulation
2
Requirements

• Need to be able to simulate different detectors
  easily and on the same footing.
• Same physics lists, cuts, etc.
• No re-coding!
• Need to be able to simulate detectors as close to
  as-built as practicable.
• Need a runtime geometry definition system which
  can handle realistic topologies.

3
Geometry Handling

• Drivers should target G4 elements
• finite list, fixed attributes, definite hierarchy
• Elements should be individually placeable.
• Will want to study misalignments
• All attributes need to be definable at runtime
• Geometry topology
• Materials
• Sensitive Detector definitions readout.
• Physics lists, Regions, cuts per region,

4
Sensitive Detectors

• Have already defined generic hit classes
• SimTrackerHit
• SimCalorimeterHit
• In our definition, trackers are not segmented.
• write out true MC hit positions
• digitization is post-Geant process
• For calorimeters, can identify and code for
  natural segmentation.

5
Calorimeter SD Segmentation

• Virtual readout, viz. do not create a G4 volume
  for each readout cell, rather use software to
  assign energy deposition.
• Cylinder
• either ?? (projective) or ?z (fixed cell size)
• Disk
• either r? (projective) or xy (fixed cell size)
• Box
• partition along u,v axes
• Handle offsets with smaller readout cells, then
  gang later to real segmentation.

6
Geometry Definitions

• Minimize runtime dependencies
• Strong preference against accessing a database at
  runtime.
• Prefer simple, portable file format
• No objection to database being the source of this
  file.
• Tight coupling to reconstruction software
• Only in sense of deriving using same
  description of the geometry.
• Strong objection to using Geant4 code as geometry
  system in reconstruction or event display!

7
Geometry Definitions

• System should be able to provide appropriate
  level of detail for the system
• Different requirements for full G4 simulation,
  fast simulation, reconstruction and event
  display.
• Different levels need to be commensurate
• e.g. amount and type of material used in tracker
  simulation needs to agree with that used in track
  reconstruction and fitting.
• Common source of geometry does not mean identical
  file formats for end users!

8
Event I/O

• Required
• Binary stdhep for MC particle input
• LCIO output
• Desired
• ASCII HepEvt
• ASCII GuineaPig

9

• If one accepts the requirement for a file-based
  input for controlling Geant4, the next question
  is what format should this file have?
• In the next two slides I provide some motivation
  behind our current preference for XML as the
  format.

10
Why XML?

• Simplicity Rigid set of rules, plain text
• Extensibility Add custom features, data types
• Interoperability between OS and languages
• Self-describing data
• can easily reformat (e.g. using XSLT)
• Hierarchical structure ? OOP
• Open W3 standard, lingua franca for B2B
• Many tools for validating, parsing, translating
• Automatic code-generation for data-binding
• Import/Export to most databases supported

11
Why G4 XML?

• XML Schema very useful for compile-time type
  safety and bounds checking.
• Prefer a G4-supported XML-based solution.
• Had hoped for common LHC solution.
• Investigated GDML.
• Looked promising ( but maybe overkill? )
• Missing features (e.g. sensitive detector
  definitions)
• Support?
• Looking at cost/benefit of developing solution
  from scratch.