OO/C++ Reconstruction Model based on GEANT3

1. OO/C++ Reconstruction Model based on GEANT3 Yuri Fisyak, Valery Fine, Pavel Nevski, Torre Wenaus Lecce Moun Software Workshop

2. Outlook • Inducement (ATLAS specific) • Motivations • Advantages and limitations of GEANT3 geometry • ``Compact’’ and ``open’’ geometries • Hits/Digits structure • User interface : iterators • Conclusions Lecce Moun Software Workshop

3. Inducement • RD event data model which provides interface to AtlSim Zebra files has to be replaced by DC 1, part 2. • AtlSim can provide output for geometry and hits/digits as ROOT-files. • The present ATLAS framework (Athena) does not allow at least now to use ROOT classes directly. • The idea is to use in Athena algorithms iterators over geometry and hits/digits which don’t depend on ROOT (interfaces). • Concrete implementation of these iterators of cause depends on ROOT classes but this implementation is not seen by Athena algorithms. This talk is devoted to this concrete implementation. Lecce Moun Software Workshop

4. Motivations • One the main task which has to be solved by a reconstruction is to provide access to geometry and calibration information for a given hit/digit and vise versa. • A lot of current HENP experiments still have their most detailed geometry in GEANT3. It looks very attractive to be able to access this geometry description from the modern OO/C++ reconstruction. • As an example, in ATLAS Muon reconstruction access to detailed detector description, including ``dead’’ material information, is mandatory because of very high performance requirements. Lecce Moun Software Workshop

5. Advantages of the ``compact’’ geometry model An existing experience with GEANT3 allows to formulate so called ``compact’’ detector model. It provides a model for “ideal” detector : • which accounts symmetries of the detector, and • it is ``compact’’ because it doesn't contain any duplicationof the geometrical nodes, • an example of such type geometry is the ATLAS detector GEANT3 description which contains ~30M copies of ~7 K different types of volumes. Lecce Moun Software Workshop

6. ATLAS Detector View With G3 Lecce Moun Software Workshop

7. Limitation of ``compact’’ geometry However this ``compact’’ model cannot facilitate the real reconstruction needs : • a subset of geometrical nodes (detector elements) might have their own unique list of parameters: • calibrations, • alignment, • … The OO model where each “physical” detector element corresponds to the dedicated object instance we will call "open" geometry. This “open’’ geometry also is very suitable for detector response (hits, digits) structuring. Lecce Moun Software Workshop

8. Compact and Open geometry • Even though the "open" structure looks very attractive it is still non realistic to keep it in memory for whole detector. • Thus geometry model for reconstruction has to contain a combination of “compact” geometry for whole detector and “open” one for its subset. Lecce Moun Software Workshop

9. Compact & open geometry in ROOT • A geometry package is being developed within ROOT framework to provide such functionality. • The package uses of ROOT Geometry classes (root/g3d) • TShape (TBRIK, TCONE,…), TMaterial, TMixture, TRotMatrix • The package includes: • the "compact" model with multiple reuse of geometry objects, providing a C++ detector view "a la GEANT3" (root/table): • TVolume and TVolumePositon classes; • the “open” model which is created by a request for a subset of the compact presentation and contains full description, where each detector element is presented by a separate object: • TVolumeView class Lecce Moun Software Workshop

10. TVolume and TVolumeView: hierarchical container of containers List of positions List of nodes TVolume TVolumePosition (relative wrt parent) TVolumeView TShape TVolumePosition (position wrt global) TMaterial TVolumePosition TVolume TVolumeView TVolume List of daughter nodes Lecce Moun Software Workshop

11. TVolume and TVolumeView (cont.) • TVolume: • does not know aboutits position, • can be positioning in any part of the geometry tree with respect to ``parent’’ TVolume, • provides only downstream navigation I.e. you can find children of the given TVolume but you don’t know its parent. • TVolumeView: • does know about its position with respect to any fixed system of coordinates (global, with respect to parent, …), • Provides navigation both downstream and upstream, • can contain any information (calibrations, …) unique for the given node. Lecce Moun Software Workshop

12. Exporting G3 geometryto ROOT Open geometry Compact geometry Mark ``Sensitive’’ volumes TVolumeView Iterator over developed G3 geometry as it sees a particle during propagation TVolume Lecce Moun Software Workshop

13. TVolume/TVolumeView browsing Full G3 tree 29’042’213 nodes 3512 marked nodes TVolume TVolume ctor TVolumeView TVolumePosition TVolume TVolumePosition TVolume structure TVolumeView structure Lecce Moun Software Workshop

14. ATLAS muon system in ROOT Lecce Moun Software Workshop

15. Hits/Digits The package also provides a generic hit/digit C++ class together with tools supporting navigation from hits to geometry and vice versa. . TResponseTable: self describing array of c-structs containing hits/digits information. • TIndexTable: list of indexes in TResponseTable array corresponding a given detector element (TVolumeView) in order to speed up the navigation from geometry to digits/hits structure. Lecce Moun Software Workshop

16. TResponseTable *mtuiHit = (TResponseTable *) g3->DataSet("Data/Hits/MUCH/MTUI"); mtuiHit->Print(0,5) TResponseTable *mtuiDigit = (TResponseTable *) g3->DataSet("Data/Digits/MUCD/MTUI"); mtuiDigit->Print(0,5); Response Table Muon/.make/AtlSim/.data/Data/Digits/MUCD/MTUI Allocated rows: 32 Table: MTUI [0] : [1] : [2] : [3] : [4] int TRACK 1 : 1 : 1 : 1 : 1 int ATLS/OUTE/MUCH 2 : 2 : 2 : 2 : 2 int BARI 10 : 10 : 10 : 10 : 10 int BXXI 12 : 12 : 12 : 12 : 12 int BSLI 1 : 1 : 1 : 2 : 2 int BWAI 55 : 109 : 164 : 5 : 6 float TIME 194.6 : 239.31 : 284.96 : 466.39 : 467.12 float Z 22.309 : 22.398 : 22.487 : 23.008 : 23.056 float TDR 0.4915 : 0.6205 : 0.7495 : 1.2695 : 1.2615 Muon/.make/AtlSim/.data/Data/Hits/MUCH/MTUI Allocated rows: 36 Table: MTUI [0] : [1] : [2] : [3] : [4] int TRACK 1 : 1 : 1 : 1 : 1 int ATLS/OUTE/MUCH 2 : 2 : 2 : 2 : 2 int BARI 10 : 10 : 10 : 10 : 10 int BXXI 12 : 12 : 12 : 12 : 12 int BSLI 1 : 1 : 1 : 2 : 2 int BWAI 55 : 109 : 164 : 5 : 6 float X -0.4155 : -0.5245 : -0.6325 : -1.0715 : 1.0635 float Y -0.2635 : -0.3325 : -0.4015 : -0.6805 : 0.6785 float Z 22.309 : 22.398 : 22.487 : 23.008 : 23.056 float TDR 0.4915 : 0.6205 : 0.7495 : 1.2695 : 1.2615 float TOF 0.29778 : 0.29875 : 0.29973 : 0.30544 : 0.30595 float CZ 0.02975 : 0.02975 : 0.02965 : 0.02945 : 0.02945 float CX -0.53645 :-0.53655 : -0.53655 :-0.53685:-0.53685 float CY 0.84345 : 0.84335 : 0.84335 : 0.84315: 0.84315 float STEP 2.7505 : 2.6445 : 2.5075 : 1.4435 : 1.4715 float LGAM 2.485 : 2.485 : 2.485 : 2.485 : 2.485 - Detector Id, path to detector element Hit/Digit parameters Lecce Moun Software Workshop

17. TIndexTable To speed up navigation over hits/digits information from detector elements it has been created hits and digits trees. The trees structure reflects one for the “open” geometry and contains only nodes with hitted detector elements. These nodes contain indexes (TIndexTable) of hits in Hits/Digits TResponse tables. TObjectSet TVolumeView TIndexTable TResponseTable Lecce Moun Software Workshop

18. Navigation The main goal of the above “compact” and “open” geometries and Hits/Digits trees is to provide straight forward navigation from hits/digits to geometry and from geometry to hits/digits. Because the ``geometries’’ and hits/digits are containers the way to navigate over them are iterators. The navigation is provided by two iterators: • TVOLUME::iterator over TVolume and TVolumeView structures and • ADigitIterator / AHitIterator Lecce Moun Software Workshop

19. Navigation : TVOLUME::iterator void VIter(){ TVolume *oute = (TVolume *) g3->Find(".const/Constants/Geometry/ATLS/OUTE"); // or // TVolumeView *oute = (TVolumeView *) g3->Find(".const/Constants/GeometryTree/ATLS/OUTE"); TVOLUME::iterator Iter(oute); TString BXXI("BXXI"); for (;(long) Iter != 0; Iter++) { TVolumePosition &pos = *Iter; TString Name(pos.GetName()); if (Name != BXXI) continue; pos.Print(); } } … Node: BXXI Position: x=404.401 : y=-976.31 : z=0 OBJ: TRotMatrix 508523 NodeView 1 : 2 : 3 : 1. -0.923879 : -0.382684 : -4.37114e-08 : 2. 0.382684 : -0.92388 : -4.37114e-08 : 3. 0 : 0 : 1 : Muon system Muon chamber Lecce Moun Software Workshop

20. ADigitIterator TObjectSet *BXXI = (TObjectSet *) g3->GetData("DigitsTree/ATLS/OUTE/MUCH[2]/BARI[10]/BXXI[12]"); for (ADigitIterator iter(BXXI); (int)iter != 0; iter++) { ADigit &digi = *iter; digi.Print(); } … Digit: TRACK 1 ATLS/OUTE/MUCH[2]/BARI[10]/BXXI[12]/BSLI[2]/BWAI[115] TIME 377.098 Z 23.2315 TDR 1.0015 E 0 Node: BWAI Position: x=1.95198e-06 : y=15.344 : z=-60 OBJ: TRotMatrix 520471 NodeView 1: 2 : 3 : 1. -4.37114e-08: 4.37114e-08 : -1 : 2. -8.74228e-08: 1 : -8.74228e-08 : 3. 1 : -4.37114e-08 : -8.74228e-08 : … Lecce Moun Software Workshop

21. Iterator in Athena Algorithm AGIterator iter; status = detStore->retrieve( iter, “Geometry" ); // get iterator from StoreGate iter.Reset(“ATLS/OUTE”); // start with Muon System Identifier MuonStation(7); // or whatever defines muon station for (;(long) Iter != 0; Iter++) { Identifier identifier = iter. Identifier(); if (identifier != MuonStation) continue; // or it can be use a Name string Name = iter.Name(); if (Name != “MuonStation” ) continue; if (iter.GetID() != 5) continue; …. HepTransform3D tras = *iter; } =================================== The interface has to be discussed and fixed but it clear that it has to provide: • transformation with respect to a given reference system (“ATLS/OUTE” in the case); • Identifier; • shape type and shape parameters; • material (may be ?); • …. Lecce Moun Software Workshop

22. Conclusions • It has beendeveloped a set of classes which have supported structures and provide parameters description of both ``compact’’ and ``open’’ geometries. This approach naturally accounts for alignment and detector calibration information. • It has been developed structure supporting hits and digits. • It has been developed iterators which provide navigation from hits/digits to geometry and vise versa. These iterators provide the navigation for persistent (ROOT) classes. • Still it is need to discuss what (transient) iterator should be exported into Athena Algorithms. Lecce Moun Software Workshop