190 likes | 359 Views
New geometry framework in MUON. I.Hrivnacova IPN, Orsay ALICE Offline week, CERN 21 February 2005. Motivation. Parametrisation of geometry Extraction of the positions of selected pieces in a detector geometry - “detection elements”
E N D
New geometry framework in MUON I.Hrivnacova IPN, Orsay ALICE Offline week, CERN 21 February 2005
Motivation • Parametrisation of geometry • Extraction of the positions of selected pieces in a detector geometry - “detection elements” • Make possible to use them as input parameters and so to take into account the alignment • Presentation at the last Offline week in September 2004 • Concentrated on the applied method • This presentation • Will give a more detailed description of the introduced framework classes and their implementation for MUON • Will cover the development since that time
Logical Geometry Structure • We have defined logical geometry units that represent sets of volumes in the geometry • Three level structure: • Module - the biggest unit in a detector • Envelope - non-virtual and virtual • Envelope constituent – constituent of a virtual envelope • Each unit represents a frame with respect to which its components are placed
Detection Element • In a logical geometry hierarchy it corresponds to an envelope • Detection element != a single volume in a MC geometry • In real detector: • Quadrant, slat, trigger chamber • Has an ID unique in the whole detector • Provides transformation between the global and its local frames • Object of alignment
Structural ObjectsClasses • The elements defined before are represented in the framework via correspondent classes: • Alice coding convention + need to make this group of classes retrievable among ~ 90 other MUON classes has resulted in long class names: AliMUON*Geometry*XYZ • To make presentation clear, AliMUONGeometry prefix will be skipped ... • The V prefix stands for abstract classes • Module, Envelope, EnvelopeConstituent, DetElement • Structural objects • EnvelopeStore, GeometryStore, VDEIndexing • Utility objects • Transformation representation: • TGeoMatrix class from Root
Building Geometry • User CreateGeometry function now have to define also the logical geometry elements • The framework builder classes help to simplify this: • User implements his detector construction class as a geometry builder derived from VBuilder associated with one or more Module object • The VBuilder base class provides utility functions for definition of Envelopes, EnvelopesConstituents and DetElements • Concrete examples of a user code were shown in the presentation at the previous offline meeting • The main Builder than takes care of geometry construction via all user defined registered builders
Procedure of Building Geometry • Definition of the logical structures (modules, envelopes, envelope constituents) and all volumes trees placed inside them • By UserBuilder : VBuilder objects • Placing the envelopes and their constituents with a composed transformation • Automatic procedure – using the data stored in modules and envelopes, by main Builder object • Definition of detection elements and storing their global transformations • By main Builder object
Geometry ParametrisationI/O • Transformations defined in the logical volume structure can be exported to/imported from files • Option whether these data will be taken from the files or from geometry definition in building geometry • Defined in main Builder: SetAlign(), GetAlign() functions • One file per user builder • Includes data for several geometry modules • Reading/writing files implemented in VBuilder • ASCII files – temporary solution until such a functionality is provided via AliRoot framework
Geometry Parametrisation I/0trasform_st1V2.dat Data format: CH moduleId nofDEs pos: x y z rot: thex, phix, they, phiy, thez, phiz DE deId envName copyNo pos: x y z rot: thex, phix, they, phiy, thez, phiz Example of station1 V2 data: CH 1 4 pos: 0. 0. 533.5 rot: 90. 0. 90. 90. 0. 0. CH 2 4 pos: 0. 0. 533.5 rot: 90. 0. 90. 90. 0. 0. DE 100 SQM1 1 pos: -2.6 -2.6 3.25 rot: 90. 0. 90. 90. 0. 0. DE 151 SQM1 2 pos: 2.6 -2.6 -3.25 rot: 90. 180. 90. 90. 180. 0. DE 150 SQM1 3 pos: 2.6 2.6 3.25 rot: 90. 180. 90. 270. 0. 0. DE 101 SQM1 4 pos: -2.6 2.6 -3.25 rot: 90. 0. 90. 270. 180. 0. DE 200 SQM2 1 pos: -2.6 -2.6 3.25 rot: 90. 0. 90. 90. 0. 0. DE 251 SQM2 2 pos: 2.6 -2.6 -3.25 rot: 90. 180. 90. 90. 180. 0. DE 250 SQM2 3 pos: 2.6 2.6 3.25 rot: 90. 180. 90. 270. 0. 0. DE 201 SQM2 4 pos: -2.6 2.6 -3.25 rot: 90. 0. 90. 270. 180. 0.
Geometry Segmentation • Segmentation defines the detector layout, topology of pads, which is not present in the geometry definition • In the current framework • User defined segmentations implement geometry functions (“get pad position”) in the global reference frame • Disconnected from geometry definition • In the new framework • User defined segmentations, derived from VDESegmentation base class, implement geometry functions in the local detection element frame • One general “global” segmentation per module, GeometrySegmentation, implement geometry functions in a global reference frame
Geometry SegmentationImplementation Bool_t AliMUONGeometrySegmentation::GetPadC( Int_t detElemId, Int_t ix, Int_t iy, Float_t& xg, Float_t& yg, Float_t& zg) { // Transform from pad to real coordinates if (!Notify(detElemId)) return false; if (!fCurrentSegmentation->HasPad(ix, iy)) return false; Float_t xl, yl, zl; fCurrentSegmentation->GetPadC(ix, iy, xl , yl, zl); fGeometryModule->Local2Global(detElemId, xl, yl, zl, xg, yg, zg); return true; }
Use of Geometry Segmentation • Geometry segmentation has different API from the old segmentation • Requires code transition from the old segmentation framework to the new one • Detection element ID has to be consistently used together with the new geometry segmentation • Added to hit, digit, ... class definitions
Present Status (1) • Framework classes: • In a separate library libMUONgeometry • Independent from MUON code • MUON specific classes that implement geometry are not included in this library • Geometry: • The whole MUON geometry (v1) is now defined via new framework • Still some problems to be solved • Too many volumes going to ALIC from some builders (misuse of virtual envelopes) • Overlaps for newly placed volumes
Present Status (2) • Segmentation • New segmentations per detection elements: • Station12, Slat stations, Trigger stations • All in CVS • AliMUONTest • Testing new segmentation framework (in CVS) • Instantiation of new geometry segmentations, printing pads positions, drawing pads • AliMUONFactory, AliMUONChamber, ... • In transition to the new geometry and segmentation framework • In development
Conclusions • Concept of detection elements • Consistent use of the same set of geometry transformations in both simulation and reconstruction • Possibility to read transformations from a data file • Concept of geometry modules – geometry builder classes per development teams • Framework classes fully independent from MUON specific classes