Common Geometry (LCGO)

Introduction talks

gear_overview.pdf

Requirements

• Should be at least as functional as existing systems (org.lcsim, GEAR, Mokka, SLIC)
• Shoule enable smooth transition path from existing systems
• Should encourage interoperability between systems
• have no known principle short comings: "everything should be possible"

Implementation Ideas

• Three levels of API?
  • Low level (equivalent to Geant4 geometry objects)
    • Initially dumb objects, sufficient to create Geant4 geometry
  • Medium level (similar to GEAR::Vertex::API)
  • High level (allows finding which detectors exist)
• have collection of driver classes
  • one subdetector level
  • gcj comliant Java ( to be called from C++/Marlin)
  • read in 'free format' from parameters from xml elements
    • should probably be similar to compact/gear
• low level implemetation:
  • create "queue" of geometry instructions
    • logical volumes
    • physical volumes
    • placements
    • material
    • etc
  • have converters that go through queue of instructions and create
    • G4Detector
    • HepRep
    • GDML / LCDD
• medium and high level: GEAR interface(API)

points to cover

• GEAR++ interface deifinition (medium and high level)
  • tracking (and clustering PFA)
    • average material volumes
    • intersection with 'next' volume
    • dE/dx
    • field maps
  • volumes ?
  • local to global position
  • extensions of detectors ( a la gear)
    • e.g. #layers, thickness, width,...

• material database
• field maps
• properties (sampling fractions)
• readout properties
  • cellId <-> position
  • cellid range (noise simulation)
  • cell sizes
  • neighbors
• Vector and Matrix classes (also LCIO)
  • ThreeVector, Point3D
  • Planes, cylinders, ... ?
  • FourVector
  • SymMatrix (covariances)

lcgo schema