30/09/08

5

Muon Spectrometer Detector Description

Outline:

- Present situation

- Dead Matter

- Validation

- GeoModel..

Laurent Chevalier, Andrea Dell’Acqua,

Jean Francois Laporte, Stefania Spagnolo, Dennis Wright

5

Detector description parameters chain: present situation

GeoModel

G4

Active part

Dead Matter

Oracle

Primary numbers

AMDB

automatic-translation

Reconstruction:

Moore

Muonboy

amdcTool

create

sql files

Active part

Dead Matter

derived from

XML

(not primary)

Only numbers NO structure

XML

converter

AMDB file

Id Dict name

Cabling maps

name

Active Part = GeoModel/G4 (<2microns)‏

Dead matter = GeoModel/G4 (with the new XML converter)‏

Volume description

Digitization

Data Decoding

new

30/09/08

5

amdb_simrec.r.03.03:

New feet

EEL update

Cabling maps name

Missing

Services ...

Update primary numbers
dead matter part

Validation:

on going in forward region

10GeV,100GeV

mu+/mu-

Eta [1.0,2.7]

Phi [0,45]

MuonGeoModel specific issues

separating readout geometry (Manager+XxxReadoutElement+MuonStations[with alignable transforms] used in reconstruction) from bulk of GeoModel infrastructure

no show-stoppers; 14.4.0 is a candidate for such migration

at the same time: cleanup and make as uniform as possible ( among technologies ) reconstruction interfaces

integrating recent improvements (cutout implementation) in production releases

in production: cutouts in MDT of BOG (feet region)

in 14.4.0 nightly builds: cutouts in all MDT(a few to fix in EC chambers)/RPC/TGC

validation issues: need to understand clearly the differences in the geometry model implemented with respect to previous version of the software for the same layout (a very few not yet fully understood)

memory: 50 MB or raw geometry (for simulation) [a fraction can be disabled in reco.]+ 80 MB for common-tracking interfaces [fully disabled in simulation]

too much, why not moving in the TrkGeometry to the use of “lighter” representations of HepTransform3D ?

MuonGeoModel (ReadoutGeometry) and EDM

Offline Data collections vs XxxReadoutElement granularity:

MDT data coll. (= MDT station) contains data in typically 2 MdtReadoutElements (one per multilayer)

RPC data collections (= plane of RPC at ~same radius in a muon station) groups data located in typically 2 RpcReadoutElements

CSC data collections = CscReadoutElements (in the staged-for-ever scenario)

TGC data collections = TgcReadoutElements

problem: in a loop over the collection the detector element has to be retrieved for each datum

Proposal, investigated and to be resumed

new extra layer of ReadoutGeometry: XxxDetectorElement (with granularity a la EDM)

XxxDetectorElement holding pointers to relevant XxxReadoutElements (they keep the entire functionality)

tried and tested for performance for Mdt (profiling with callgrind)

gain in the CPU timing for a loop over PRD in a MDT collection using the new schema: 50 %

see http://indico.cern.ch/conferenceDisplay.py?confId=28777 for more details

MuonGeoModel and Alignment data

Alignment parameters:

implementation of alignment parameters for a muon station (rotation angles + shift + order of transforms) coherent between optical alignment systems (barrel and end-cap) and MuonGeoModel.

reconstruction in mis-aligned geometry layouts widely exercised since CSC

little exercise of the use of alignment constants as condition data: i.e. changing constants during the run processing

FDR2b has been the best performance test of the system: MuonGeoModel reading from COOL alignment data for the barrel only, feeding to reconstruction algorithms (both Moore and Muonboy – via different mechanisms)

for the FDR2c multi-folder access in COOL ready: barrel optical constant + 2 sets of constants for EC but a lurking bug showed up (fixed).... need extensive exercise / stress tests !

MDT deformation parameters:

implementation of main effects (leaving tube straight) in place

starting checking implementation against ARAMYS (optical al. system in the EC)

access to deformation parameters in COOL to be finalised (no show-stoppers foreseen)

laurent chevalier

2008-09-30T10:18:16