You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 20
Next »
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
![](/download/thumbnails/18476/lcgo_schema.png?version=1&modificationDate=1158779575000&api=v2)