M.Frank CERN/LHCb Detector Description  Motivations and goals  Review and overview  Geant4 interface  Mokka drivers  …

M.Frank CERN/LHCb DD4hep Status

M.Frank CERN/LHCb Design Principles (1)  Separation of data and behavior  Data are fully accessible (no encapsulation!)  Behavioral classes are wrappers around objects containing data only  There may be many behavioral wrapper implementations using the same data objects  User chooses “most suitable” behavior  One “data-object” may be shared among many behavioral wrapper instances

M.Frank CERN/LHCb Design Principles (2)  The geometry implementation is based on TGeo(ROOT)  Take advantage of existing functionality  if necessary extend  TGeo has support for alignment, visualization, etc.  Increasing usage of the ROOT plugin mechanism  instantiate specialized components  Detector elements  Readout segmentations  Sensitive detectors

M.Frank CERN/LHCb [My] Goals for These Two Days  Establish a roadmap how to proceed  Get an idea which activity to emphasize  Use of the detector description in simulation eventually replace existing simulation  Use of the detector description in reconstruction emulate (or replace) gear?  Use for alignment  …

M.Frank CERN/LHCb Geometry Expansion  From compact xml file  No strict dtd  Cascaded xml parsing. Example:  Geometry description  Geant4 setup  Expansion with python possible (=>Pere)

M.Frank CERN/LHCb Display Geometry Recon- struction Geant4 Detector Description: LCDD Sections and Clients Implicitly contains geometry description

M.Frank CERN/LHCb DD4Hep: DetElement Description Detectors Readout Visualization DetElement id name type Envelope [TGeoShape] Log.Volume [TGeoVolume] 0…n volume: 1 visattr: 0…1 0…1 mother 1 Material [TGeoMedium] 1 volumeRef 1 [TGeoMatrix] transform: 1 solidRef 1 detector: 1 materialRef 1 GDML content children 1..n PlacedVolume [TGeoNode] placements: 0…1 Alignment Conditions  ROOT only provides the geometry  Rest is us

M.Frank CERN/LHCb Shapes and Solids  Palette ~complete. New shapes added on demand.

M.Frank CERN/LHCb Specialized Detector Elements  Central element of the detector description  Describes subdetector hierarchy  Requires flexibility and extensibility  Flexibility: Specialize the behavior of your DetElement  Specialized access to the (sub)detector hierarchy tree  Implement specialized wrapper using existing detector element hierarchy  Possibility to cache 3 transformations  to parent  to world  to self-defined detector element

M.Frank CERN/LHCb Extended Detector Elements  The “flexible” approach with wrappers defines flexible behavior using the same data  Pure wrappers tend to be slow if complicated calculations need to be redone for every query  It is not possible to store subdetector specific parameters, which are not described by the geometry example: TPC pad-height, pad-width etc.  To ensure fast operations specialized wrappers must be able to store extra subdetector parameters and take advantage of local cache  local extensible cache must be provided  Cannot be planned: different wrappers for the same DetElement may maintain different caches

M.Frank CERN/LHCb Extended Detector Elements  Two approaches implemented  Extend underlying data object using inheritance  Possible once, at construction  Attach extension object (see Astrid’s work)  Identified by typeinfo  Any number of objects  Attachments for  Simulation  Reconstruction  …

M.Frank CERN/LHCb DetElement Extensions: Example MyExtension* e = new MyExtension(...); DetElement* d = lcdd.detector(“TPC”); d.addExtension (e); Extension* e = d.extension ();  Extensions exist for “DetElement”, “SensitiveDetector” and “Segmentation” objects  Extension using inheritance exist for “Segmentation” objects for building fleaxible readout-descriptions  Extensions must have a destructor and a copy constructor

M.Frank CERN/LHCb Detector Element Status  Detector reflections  Require deep copies of DetElement trees  Clones extensions  For inherited extensions, subclasses must implement “clone” method – acceptable or confusing ?

M.Frank CERN/LHCb Fields  Interface present  Backend for constant, homogeneous or dipole field  User defined fields supported with plugin mechanism <field type="SolenoidMagnet" name="GlobalSolenoid" inner_field="5.0*tesla" outer_field="-1.5*tesla" zmax="SolenoidCoilOuterZ“ outer_radius="SolenoidalFieldRadius" />

M.Frank CERN/LHCb Conventions & Guidelines Stuff to sort out  Several decisions should be taken (next slides)  Technical stuff – should be simple  Need policies for homogeneous code  No detector description framework does liberate a user  To use the brain  It is mandatory, that the DetElement hierarchy is sensible  Otherwise you may display the detector  but the detector description may not be useful to serve other tasks  It would be good if we could establish a set of guidelines how to partition a given subdetector into detector elements

M.Frank CERN/LHCb Conventions: Rotations  Rotations: is the notation correct ? theta/phi/psi theta/psi/phi (closer to cylindrical)(around x,y,z axis) (into ring, up, beam)  ROOT uses Euler angles (phi, theta, psi) or Geant3 (polar,azimut of all 3 axis)  Triviality, things only need to be consistent  Need a convention – otherwise this will lead to confusion no end  Which is the usual convention ?

M.Frank CERN/LHCb Conventions: Compact Detector Conversion  Callbacks now support 1 sensitive detector/subdetector  Looks like not suitable for Mokka endcap A – barrel - endcap B are one subdetector But typically have different sensitive detectors  Maybe create and register sensitive detectors by hand?  No real restriction, but things may become confusing static Ref_t create(LCDD& lcdd, const xml_h& elt, SensitiveDetector& sens) { ECAL ecal(lcdd,elt,sens); return ecal; } DECLARE_DETELEMENT(SEcal03,create);

M.Frank CERN/LHCb Conventions: Compact Detector Conversion  Currently 1 high level DetElement/subdetector  Obviously OK for SLIC: model design  Mokka: endcapA, endcapB and barrel are 1 subdetector  Can be combined, but is this good?  Possible solution – like for sensitive detectors  Drivers create and register the detector elements  But why should then be the basic DetElement “special”?

M.Frank CERN/LHCb Thanks, which do not work  Wireframe displays currently do not work  + probably various other aspects, which only show up once the feature is used (ask Astrid!)

M.Frank CERN/LHCb Next: Geant4

M.Frank CERN/LHCb Geant 4 Gateway (1)  Idea: - walk through the geometry starting from “world” - convert the geometry from ROOT to Geant4 - all runs by magic  unfortunately this was a little bit naive  Geometry is automatically converted to Geant4  Materials  Solids  Limit sets  Regions  Logical volumes  Placed volumes / physical volumes  Fields  Sensitive detectors

M.Frank CERN/LHCb Geant 4 Gateway (2)  The problem are the sensitive detectors  Coupled to the detector construction  Coupled to the reconstruction, MC truth and Hit production  At LHC each experiment has it’s own set of SDets  Is this necessary ?  I added two simple sensitive detector types  one for tracking devices  one for calorimeter devices  But I doubt these two are sufficient  Hope: a well organized palette of useful SDets  Unfortunately I am not very experienced with this topic

M.Frank CERN/LHCb Geant 4 Gateway (3)  How should the sensitive detectors be organized ?  Sensitive detector hierarchy ?  One per subdetector, then dispatch  Is it enough to provide a palette of sensitive detectors ?  Which fit all possible detectors ?  How should they look like ?  Which stepping information must be stored ? Sorting out this issue will be essential for “generic” simulation programs

M.Frank CERN/LHCb Geant 4 Gateway Instantiation of sensitive detectors  Geant4 setup is performed by cascaded interpretation of second xml input  Avoid proliferation of geometry description  Setup Geant4 sensitive detectors <sd name="SiVertexBarrel" type="Geant4Tracker" ecut="10.0*MeV" verbose="true" hit_aggregation="position">

M.Frank CERN/LHCb Geant 4 Gateway Field, Steppers & Co.  Setup arbitrary objects with name value pairs  Used to define steppers and motion equations <attributes name="geant4_field" id="0" type="Geant4FieldSetup" object="GlobalSolenoid" global="true“ eps_max="0.001*mm" stepper="HelixSimpleRunge" equation="Mag_UsualEqRhs">

M.Frank CERN/LHCb Geant4: Proof  The basic mechanism works  Tried out with the ILDExDet(ector)  Geant4 ran on it  Saving the ROOT converted Geant4 geometry to GDML and reading it back with ROOT gives an identical result (no vis.attrs.)

M.Frank CERN/LHCb Mokka Conversion  First attempt  Code not terribly structured  Let’s finish with a few nice pictures…  All previously encountered problems were encountered

M.Frank CERN/LHCb Model: LDC00_01Sc vxd03

M.Frank CERN/LHCb Model: LDC00_01Sc mask04 sit00 ftd01 lumicalX

M.Frank CERN/LHCb Model: LDC00_01Sc coil00 yoke02 tpc02 lumicalX

M.Frank CERN/LHCb Model: LDC00_01Sc SEcal03

M.Frank CERN/LHCb Model: LDC00_01Sc  Geometry needs debugging  Visual inspection is probably not enough…  I see a gap between ECAL barrel and endcap  Is it real (for cables ….)?  or is it simply a bug? SEcal03

M.Frank CERN/LHCb This Exercise …  Has effectively shown all issues to be sorted out  Only the geometry is described  Hence the nice pictures  but besides these, this detector description is of limited usefulness … say: the brain was not used effectively  No sensitive detectors were assigned  No logical division into individual DetElements was done  Will be next step  Should not be too difficult, since logical detector parts tend to follow the main geometrical partitioning such as: Barrel => Staves => Modules

M.Frank CERN/LHCb Alignment

M.Frank CERN/LHCb Alignment Rotate and/or reposition

M.Frank CERN/LHCb Alignment: Usage in xml file <!-- -->

M.Frank CERN/LHCb Alignment  The interface is quite rudimentary and primitive  Allow the basic actions rotate and reposition shapes defined in the ideal geometry  Must evolve with input from users  Several uncertainties  The addressing of placed volumes is difficult to understand.  “Copy” number of volume in mother  Is xml the appropriate database format ?  How to improve ?

M.Frank CERN/LHCb Backup slides

M.Frank CERN/LHCb Motivation and Goal (1)  One detector description for the experiment’s lifecycle  DD requirements are not fixed  …they depend on experiment life cycle  Parameterization of ideal detector  After TDR: Transition from parameterized detector to real description  Readout structure  Alignment constants  Calibration constants Detector opt. CDR / LOI Detector opt. Construction TDR Operation LCD is here Shown summer 2011

M.Frank CERN/LHCb Motivation and Goal (2)  One detector description for all activities of the experiment  Simulation  Reconstruction  Analysis  Operation: Alignment, calibration, etc.  Visualization

M.Frank CERN/LHCb [My] Goals for These Two Days  Establish a roadmap how to proceed  Get an idea which activity to emphasize  Use of the detector description in simulation eventually replace existing simulation  Use of the detector description in reconstruction emulate (or replace) gear?  Use for alignment  …

M.Frank CERN/LHCb This is where we want to arrive: SLIC Generic G4 Driver Database (Mokka) get params Geant4 Detailed Geometry create volumes / vis attrs -Reconstruction -Alignment -Analysis Processor(s) Access according to needs detailed geo + visualization attrs Geant4 Visualization Event Display Parametrized Geo. geometry + visualization attrs There would be only one left for all subdetectors and all models Alignment const. Calibration const. Visualization attrs. Detector Description Geometry Expansion feed detailed geometry Shown summer 2011