Introduction talks



to get a list of work items that need to be addressed klick on the link above 


  • 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

  • No labels