Computing Workshop
Online/Databases/Detector Description Session
Paris
18th November 2015
Detector Description for the
current detector
basic principles
essential & weak points from the reconstruction and simulation
viewpoints
Gloria Corti, CERN
Credits to Chris Jones, Wouter Hulsbergen, Sajan Easo, Dima Popov
The (obvious) Scope
Model the experimental setup in the software
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
2
Detector Description framework
✔ Single source of detector information for all LHCb software
… BUT sometimes different ‘views’ are needed
Application
Manager
Message
Service
JobOptions
Service
Particle Prop.
Service
Other
Services
G. Corti
Converter
Converter
Converter
Event
Selector
Event Data
Service
Transient
Event Store
Persistency
Service
Data
Files
Algorithm
Algorithm
Algorithm
Detec. Data
Service
Transient
Detector
Store
Persistency
Service
XML
Files
Histogram
Service
Transient
Histogram
Store
Persistency
Service
Data
Files
Computing Workshop - 16 Nov 2015
Detector Description
3
A little historical background
Very first implementation of the framework for Detector
Description presented at CHEP’00
Concepts are the same
Radovan Chytracek et al.
Fully functional implementation with connection to a very first
implementation of Conditions Database at CHEP’03
The Detector Description framework has not essentially changed since
then. Technologies behind the scenes have.
Sebastian Ponce et al.
Alignment framework in CHEP’06, Juan Palacios et al.
Doc entry page - http://lhcb-comp.web.cern.ch/lhcb-comp/Frameworks/DetDesc/default.htm
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
4
Using it in the context of the applications
Used for over 14(11) years. DC04 was the first production where
used in all applications
DB technologies and tools have been evolving but framework
itself rather stable
Customizable
Current detector described in all of its evolutions from 2001 to few
months ago
All upgrade TDRs studies have been done with it with n-options
Complexity of detector data has strong influence on timing of
navigation
Major rewrite with this in mind and introduction of tracking simplified
geometry
Some weak points for things that we did not really consider at
the time…
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
5
Basic Principles and Components
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
6
Two hierarchies of description
Two tree structures
independent but
connected
with hook for other
detector data
calibration,
alignment, …
Breakdown of detectors
Identification
LogicalVolumes, i.e. unplaced
dimensioned shapes
PhysicalVolumes, i.e. placed
volumes
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
7
Logical Structure
The basic object is a Detector Element
Identification
Navigation (tree-like)
DetectorElement is an information
center
DetElement
*
Able to answer any detector related question

E.g. global position of strip#, temperature of
detector, absolute channel gain, user
parameters, etc.
MyDetector
Placeholder for specific code

The specific answers can be coded by
“Physicists”
DetectorElement objects are shared by
all Algorithms
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
8
Volumes
Logical Volume
Contains the info of the Shape and Material of a Volume
Physical Volume
Contains the placement info of the Logical Volume
i.e. Physical location and orientation of a Volume.
Logical Volume also has
a)
the information regarding which other physical volumes are contained
in that Volume.
b) the graphics attributes needed for visualization.
c) user defined parameters needed for tracking, electromagnetic field.
d) flags to indicate if the volume is a sensitive detector (to create hits in
G4)
More info: LHCb-2004-020
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
9
Shapes: attributes to Volumes
Shapes in LHCb are Constructed Solid Geometry (GSG)
Simple shapes, i.e. Box, Tubs, Cons, Trd, Sphere, …
Easy to use and with better performance respect to other types
Combination of solids via Boolean Operations
Subtractions, intersections, union, …
Should be avoided for performance reason but sometimes the only
option
Also to avoid Boolean operations with disjoint solids and with those that
share surfaces
More info: LHCb-2004-018
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 10
Data Diagram
Points to
Resolved on demand
Inherits from
Lvolume
Solid
Material
*
Pvolume
Geometry
Info
DetElem
Calibration
Alignment
Condition
Readout
Condition
Condition
MuonStation
EcalCluster
Structure
G. Corti
Box
Isotope
Sphere
Geometry
Mixture
Element
Material
EcalClusterCondition
MuonStationAlignment
Condition
VeloReadout
Conditions
Computing Workshop - 16 Nov 2015
Detector Description 11
Detector Transient Store
A Standard Gaudi Transient Store
Ask for
Object
Algorithm
Retrieve
pointer
Detector
Data Service
Check
presence
Persistency
Service
Ask creation
Lvolume
Lvolume
Lvolume
DetElem
Transient Store
Cnv
Load
Geometry
Db
Tree-like structure
“Catalogs” of geometry, materials, structure
Items identified by logical names, in the form /xxx/yyy/zzz
Load/update on demand
Automatic update with new event
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 12
Persistent Representation
The detector description resides in a unique Detector
Description Database Partition (DDDB).
Part of CondDB
Shielded from actual DB technology via COOL interface
DDDB
LHCBCOND
DDDB
ONLINECOND
SIMCOND
XML is used as the language for the persistent representation
Syntax specified in DTD files
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 13
XML format ‘files’
Why did we choose XML at the time ???
Instead of inventing our own format use a standard one
a) Easy to read and to parse
b) Extensible
c) Easy to convert
d) Many tools
e) Extended using references
Considered as strategic technology a decade ago !
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 14
Persistency based on XML format ‘files’
a) Easy to read and to parse
b) Extensible
a) Uses the xerces-C parser
Could use any DOM parser
c) Easy to convert
d) Many tools
e) Extended using references
c) Converters used to build C++ objets
from XML
One converter per object type
Almost 1-to-1 mapping
e) Independent development for sub-detectors
b) Three main possibilities for users extensions to implement specific behaviour
- Usage of parameters in the XML code
- Specialization of the C++ objets
- Full extension, including XML, DTD and C++ converters
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 15
Things we had to cope along the way or
we found are missing by using it
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 16
Geometry in the simulation
Gauss delegates to Geant4 the transport of particles through the
experimental setup and the simulation of the processes that can
occur
A dedicated set of services,
algorithms and converters to
transform the geometry to be
simulated from the LHCb
transient detector description
into the Geant4 representation
Instantiation of Sensitive
Detector and Magnetic Field
objects, special simulation
XML tags
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 17
Passing the geometry to Geant4
Loops through the list of detector elements provided, finds the
corresponding LHCb volume elements, converts them to build
the volume tree structure for GEANT4.
IDetectorElement
IGeometryInfo
Geometry
Info
*
DetectorElement
Alignment
MuonStation
Specific
detector
description
Detector Description
G. Corti
ILVolume
Material
LVolume
ISolid
Solid
IPVolume
PVolume
SolidSolid
SolidBox
Geometry
Exploited in a 1 to 1
mapping when passing
the information to G4
GiGaDetectorElementCnv
GiGaLVolumeCnv
only called when given as
StreamItems
convert to G4 all its geometry
tree with their positions
Computing Workshop - 16 Nov 2015
Detector Description 18
Passing the geometry to Geant4
BUT detector information varying with time is separate from the
geometry structure
info about misalignment
IDetectorElement
position as given in geometry tree
IGeometryInfo
Geometry
Info
*
DetectorElement
Alignment
MuonStation
ILVolume
Specific
detector
description
Detector Description
Material
LVolume
ISolid
Solid
IPVolume
PVolume
SolidSolid
SolidBox
Geometry
Quite a bit of gymnastic to get back the position for the PVolume
from the corresponding DetectorElement
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 19
Applying the misalignment in the simulation
Misalignment is applied only for some sub-detectors during simulation
Misalignment info created for the list of ‘de’ for A and B.
In Gauss we will the Geant4 info for each ‘pv’ and try to find the corresponding
‘de’ to get the info from. Needs a unique path name correspondence.
lvA1, pvA1, deA1
(a)
lvB1, pvB1,deB1
l
lvA, pvA1, deA1
(b)
lvB, pvB,deB1
l
lvA2, pvA2, deA2
lvB2, pvB2,
l deB2
lvA, pvA2, deA2
lvB, pvB,l deB2
lvA3, pvA3, deA3
lvB3, pvB3,
l deB3
Example:
A= HPD
B= Si Anode inside HPD
✓
lvA, pvA3, deA3
lvB, pvB,l deB3
Example:
A= ST sensor
B= ST plane
✗
Need to change the schema in Gauss to support case (b)
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 20
Geometry in the reconstruction
Material description used in track fit for
estimating energy loss
estimating multiple scattering
Essential steps in Kalman filter
locate material intersections between any two ‘nodes’ on track
compute for each material intersection the e-loss and scattering using
known material properties
Precise aligned position is needed by all detectors.
e.g. for photon reconstruction in the RICH essential to know where each
mirror segment is and of each HPD and its internal silicon sensor
Knowledge of material around is also necessary
e.g. RICH needs to know the shape and position of the beam pipe to
correct for lost photons
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 21
Degree of details in the geometry
The degree of details varies depending on the scope*
RICH only need very basic shape of beam pipe and effectively has private
element for it
The track fit is not so sensitive to the actual position of the actual position
of the scattering planes


between any two hits we see a number of material objects
replacing these by one ‘average’ object may be enough
The ‘full’ geometry can be used for everything but it has a cost*
many elements
locating intersections is time consuming (80% of fitting time)
other experiments don’t do it this way
*
G. Corti
The same applies to the geometry in the simulation
Computing Workshop - 16 Nov 2015
Detector Description 22
Simplified material description
In 2007 a `simplified geometry’ was developed to be used for
the track fit
The `simplified geometry’ has only O(30) volumes
only boxes and cylinders
finesimplified
grainedgeometry
in the Velo
reminder:most
what the
looks like
velo region
●
●
there are a total of 28 volumes: 19 boxes and 9 cylinders
Behind the VELO, 19 boxes & 9 cylinders
●
–
for 'RF foil' (5-12mm), 'velo (12-45mm) and 'support' (45-250mm)
In cylinder
the VELO,
3 sections (RF, sensors, support)
behind the velo, it is all very simple: just a few boxes
y
rich1
magnet
T-station
inside the velo-region it is more complicated
–
split in three z-sections
rich2
Z
heavy cylinder representing beam-pipe connection near exit window
The track fit is entirely oblique to which
geometry is used
5
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 23
6
Simplified material description
Volumes are assigned a ‘material composition’, by running
simulated particles through the detector and averaging ‘real’
material in each of the ‘simplified’ volumes
exit window
tracing ‘reconstructable’
particles through the
detector we characterise
the material that actual
tracks will see in each of
the ‘simple’ volumes
that's a beast!
colours symbolize
rad thickness
> 0.001
> 0.01
> 0.05
line is 5 mrad
(eta~3.6)
●
I haven't found a satisfactory solution for this yet
–
boxes and cylinders just don't do it
severely affects chi-squares and momentum pull for large eta
Defining a suitable set of volumes
was (is) hand work
–
●
similar problems in TT-station and magnet region
keep the number as small as possible
but still try to separate dense from less dense regions
G. Corti
Computing Workshop - 16 Nov 2015
7
Detector Description 24
Simplified material description, validation
the result is validated by looking at
track parameter resolution and pull distributions at various positions
along the track
track chi2 distribution
•
•
shows pull of impact parameter in x versus eta and phi
black is full geometry and blue is simplified geometry
from ‘recent’ talk by Michael Alexander
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 25
Simplified geometry considerations
The main drawback to current implementation is that it has no
connection to real geometry
It means, for instance
for every update to the full geometry, necessary to manually run a job to
compute new material constants, but cannot update the volumes
if the velo is open, or not centered at (0,0,0), the ‘simplified velo’ is still
closed and still centered at (0,0,0) !
The current simplified geometry is not appropriate for the RICH
because integrates materials with very different densities
Could choose differently the material in the RICH regions
Somebody ambitious could develop procedure that generates
simplified geometry automatically, including volumes
should look at how other collaborations solve this!
Simplified geometry could partly be used also in the simulation
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 26
Parallel geometry (in simulation)
The simplified geometry coexists in the detector description in a
‘parallel’ path
More then one in different paths used at the same time for different
purposes?
Need to be made ‘automatically’: with extern processing or with ‘tags’?
In Geant4 two separate geometries
Mass geometry where particles are tracked
Parallel geometry where particles are not tracked but can create hits.
Volumes can overlap with those of the mass geometry
Want to use the parallel geometry in the future for scoring
planes for material scans (and possibly for fastMC and readout
geometries)
Investigate parallel path in TDS with parallel geometry in Geant4
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 27
Some random topics related to geometry
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 28
Do we have enough shapes?
Geant4 has even more CSG
shapes.
GEANT4 also has:
• BREPS (Boundary Represented
Solids)
• Tessellated Solids, i.e. Volumes
defined by a number of facets.
Useful for importing complex
shapes created by CAD systems.
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description
Importing geometry from CAD
CAD geometries cannot be used as-is but sometimes very useful
to do so
Tools exist to transform STEP files into GDML files for Geant4
Used for example for some RF foil studies, but not so trivial!
One of this tools developed by some engineers also in LHCb
Our DTD not too different from GDML
Are we interested in this for the upgrade? Purely for support structure?
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 30
Geometry for other simulation engines
Fast MC in various forms is one hot topic at the moment. Need
to give ‘some’ geometry.
Embedded in Gauss can use Detector Description, but need to transfer it
in the form understood by external engine used (if any)
Use simplified geometry for simple acceptance?
For radiation studies we use a completely separate application,
FLUKA.
Its own geometry description.
For current detector ported by hand.
Full geometry not always appropriate and part of the environment
missing
Some connections to Geant4 geometry possible (FLUGG) but with
limitations
Keep the status quo for the upgrade or is there something that we could
use?
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 31
Tools: geometry checkers, visualization
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 32
Tools
Tools to help in designing and checking the geometry both in the
LHCb and in the simulation engines exists and are essential
① Write and check consistency of XML ‘file’
② Visually verify volumes are where they are supposed
to be in the LHCb world
③ Check for overlaps in the LHCb world
④ Do (2) & (3) in simulation engine (Geant4) world
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 33
Exploring and visualizing
Until now the first tests to check a geometry were done with
Panoramix
Useful for quick overview of detector geometry, material inventory, XML
debbugging
Access to Geometry and Structure with different reference systems
Need a tool like this
for the upgrade (and
not only) with a fast
loading time
Does not need to be
connected to the
events
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 34
Visualizing the simulation geometry
Gauss can run in interactive mode and visualize the geometry
using Geant4 tools
DB  LHCb Geometry  Geant4 Geometry
 Geant4 graphics
 GDML  …
Many graphics drivers in GEANT4:
OpenGL, DAWN.
Need to make sure they work within
Gauss.
Recent example of Gauss with
G4-OpenGL
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 35
Checking for overlaps
Overlaps are a big cause of problems: crashes or, worse, strange
results
Main tool in LHCb is the Transport Service
Precise and reliable
For Gauss we also have Geant4 tools
Can enable checking at construction time
Use the Geant4 Dawn’s Visual
Intersection Debugger (aka DAVID).
Need to know how to interpret it.
Need to make it work again for the
upgrade detector
https://twiki.cern.ch/twiki/bin/view/LHCb/FAQ/GaussCheckOverlap
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 36
Final remarks
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 37
A personal view
Our Detector Description has served us well up to now
We can keep using it as-is with the current limitations
There is room for improvement, with non-negligible work
Better integration of simplified geometry
Redesign of how we pass it to the Geant4 simulation
Integration with other simulation engines to be looked at
Optimization of how the detectors themselves are structured in
the XML needed: particularly for the upgrade detector  huge
influence on timing!
Tools for checking the geometry are also essential
Should we be radical and change it completely?
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 38
References
Detector Description documentation entry point
http://lhcb-comp.web.cern.ch/lhcb-comp/Frameworks/DetDesc/default.htm
Tutorials
large section of Simulation 2012 tutorial, https://indico.cern.ch/event/175918/
Solids, volumes
LHCb-2004-018, LHCb-2004-020
Simplified geometry
Wouter’s original talks:
https://indico.cern.ch/event/10171/contribution/2/material/slides/0.pdf
https://indico.cern.ch/event/10728/session/2/contribution/19
More recent validation by Michael Alexander:
https://indico.cern.ch/event/385900/contribution/11/material/slides/1.pdf
G. Corti
Computing Workshop - 16 Nov 2015
Detector Description 39