Embed Size (px)
Citation preview
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 simulationeventually replace existing simulation
Use of the detector description in reconstructionemulate (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 G
ea
nt4
Detector Description: LCDD Sections and Clients
Implicitly contains geometry description
M.Frank CERN/LHCb
DD4Hep: DetElement Description
Detectors
Readout
Visualization
DetElementidnametype
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 onlyprovides 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 geometryexample: 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 DetElementmay 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<MyExtension>(e);
. . . . . . . . . . . . . . . . . . . .
Extension* e = d.extension<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
<fields> <field type="SolenoidMagnet"
name="GlobalSolenoid" inner_field="5.0*tesla"
outer_field="-1.5*tesla" zmax="SolenoidCoilOuterZ“outer_radius="SolenoidalFieldRadius" />
</fields>
M.Frank CERN/LHCb
Conventions & GuidelinesStuff 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 hierarchyis 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 subdetectorBut 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 GatewayInstantiation of sensitive detectors
Geant4 setup is performed by cascaded interpretation of second xml input Avoid proliferation of geometry description
Setup Geant4 sensitive detectors
<geant4> <sensitive_detectors> <sd name="SiVertexBarrel" type="Geant4Tracker" ecut="10.0*MeV" verbose="true" hit_aggregation="position"> </sd></geant4>
M.Frank CERN/LHCb
Geant 4 GatewayField, Steppers & Co.
Setup arbitrary objects with name value pairs Used to define steppers and motion equations
<geant4> <properties> <attributes name="geant4_field" id="0" type="Geant4FieldSetup" object="GlobalSolenoid" global="true“ . . . . . . . eps_max="0.001*mm" stepper="HelixSimpleRunge" equation="Mag_UsualEqRhs"> </attributes> </properties></geant4>
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 partitioningsuch as: Barrel => Staves => Modules
M.Frank CERN/LHCb
Alignment
M.Frank CERN/LHCb
Alignment
Rotate and/orreposition
M.Frank CERN/LHCb
Alignment: Usage in xml file
<alignments> <alignment
name="/world_volume_1/B1_vol_0" shortcut="Box1">
<!-- <position x="0" y="0" z="0"/> <rotation x="0.5" y="0" z="0"/>--> <position x="-20" y="-10" z="-5"/> <rotation x="0" y="0" z="0"/> </alignment> </alignments>
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 parameterizeddetector to real description
Readout structure Alignment constants Calibration constants
Detector opt.
CDR / LOI
Detector opt.
Construction
TDR
Operation
LCD is hereShown 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 simulationeventually replace existing simulation
Use of the detector description in reconstructionemulate (or replace) gear?
Use for alignment …
M.Frank CERN/LHCb
This is where we want to arrive:
SLIC
Generic G4Driver
Database(Mokka)
getparams
Geant4
Detailed Geometry
create volumes / vis attrs
-Reconstruction-Alignment-Analysis
Processor(s)
Access according to needs
detailed geo+ visualization attrs
Geant4Visualization
Event Display
Parametrized Geo.
geometry+ visualization attrs
There would be only one leftfor all subdetectors and all models
Alignment const.
Calibration const.
Visualization attrs.
Detector DescriptionGeometryExpansion
feeddetailed
geometry
Shown summer 2011
