21/5/03J.E Campagne Opera Framework: Status Report

21/5/03J.E Campagne Data flow and link: proposed 6/9/01 Information TrackKinematics MCHits Particles Processing MCParticles MC Data Cooked Data GenParticles Digitisation OpRec OpRoot OpVMC Digits TracksElement Real Data Link between data Pattern Tracking Generation MCVertices

21/5/03J.E Campagne OpRoot/OpTreeConvert u At Strasbourg, it was decided that OpRoot will be replaced by OpVMC at a certain point, so the output of OpVMC/OpRoot should be the same (MC Particles/Vertices + Hits): a Hierarchy ROOT Tree. u OpRoot has been updated (Dominique/Muriele) for the geometry basically, but the code was judged too dirty to change safely the TTree, so OpTreeConvert has been setup to transform the OpRoot Tree into the official event by event TTree.

21/5/03J.E Campagne TTrees/Folders (proposed 30/10/02) RunRun information header Run/EventEvent information header Run/Event/KinList of Vertices and Particles generated Run/Event/ /HitsList of MCHits produced in detector Run/Event/ /RawList of Real Raw data of detector Run/Event/ /DigitsList of Digits from Hits or Raw Run/Event/Trig & Trig/ Trigger Header + trigger info per detector Run/Event/Reco/ED/TelementElectronic detectors list of Track Elements Run/Event/Reco/ED/TkineElectronic detectors list of Track with kinematics infos Run/Event/Reco/ED/TidElectronic detectors list of Track with identification Run/Event/Reco/ECC/…Same as ED for ECC/scanning result (naive) green: exists in present hierarchy

21/5/03J.E Campagne TTree access: OpIO/TreeManager u To access the Opera TTree, it has been decided that a tool should be provided to unify the operations, avoid end-user additional code, and it should be accessed by other applications: TreeManager in OpIO. u Along the path from Generation to Reconstruction and further analysis, information will be added to the TTree. To unify operations and avoid end-user additional code, a Storage Manager (OpAlgo semantic) is provided: Tree2Tree in OpIO. Tree2Tree is based on TreeManager utility. Tree2Tree is used by other applications: OpDigit, OpRec.

21/5/03J.E Campagne ROOT IO & Memory data u The philosophy of OpAlgo is to avoid a direct connection between user algorithm and the storage facility. This is directly provided by Tree2Tree and the mapping between Memory Opera Data (OpData) and persistant data based on ROOT IO (OpRData). At present has been validated: –MC Particles (primary & secondary) and MC Vertices with inter-relation (a lot of work!): Particles have a link to their production vertex (decay), and the vertices have a link to their incoming particle and the set of outgoing particles. –All XYZHits: XYZ for detector –Preliminary XYZDigits –TrackElement/TrackKinematics

21/5/03J.E Campagne Current work u OpDigit: –Takes the TTree after the OpRoot/OpTreeConvert and provides the digit structures. –Skeleton for other applications that will use Tree2Tree: »Example of RunManager and AlgoManager (OpAlgo language) in the context of the application »Generic DataLoader and all the LoadXYZ algorithms (XYZ are the OpData objects) in OpIO, and DataLoader can be inherited and tuned for the application »TDataStore (OpData): Memory repository to exchange OpData objects between Top AlgoManager »Generic DataSaver and all the SaveXYZ algorithms in OpIO, and DataSaver can be inherited and tuned for the application. –In debug phase, but one should provide asap the OpRData/OpData concrete classes for the final job. Already tested

21/5/03J.E Campagne Next work u OpRec: –Update the loading phase to be adapted to new OpData Digit definition and new tools developped so far in the context of OpIO. –Extend the Pattern to new detectors –Extend/Replace the Fit process u Documentation: –OpIO: should be done in priority –OpTest (or MyAna): skeleton of user analysis u Adore Ntupe to TTree (HBookToRoot), Tree2Tree exist, now may be Tree2Ascii (storage but not load !) should be done?

21/5/03J.E Campagne Apologizes u It has taken much more times than foreseen in January 03: –OpTreeConvert (1200 lines): »All the OpRoot Ttree were based on Primary entry and not on event by event entry »We have decided to inter connect the MCParticles and the MC Vertices –Op(R)Data: MC Particle, MC Vertices + Hits: »The definition takes some times for instance: Hit has link to the Local Particle, the Primary particle and the Mother particle –TreeManager: (1100 lines) »TRef/TRefArray features of Root, understanding the necessity of the « Used» list. By product, it is not necessary to load everything to work… –Tree2Tree: (2200 lines) »Long to debug and time wasted due to Memory Leak in ROOT 3.3/5 => ROOT 3.5/4

21/5/03J.E Campagne Milestones ? u Generation OK (Dario, Lionel) u OpRoot patched, can be considered as “final” (Dominique, Murièle, Lionel) u ODD geometry checked, still some minor upgrades (Dominique) u OpDigit under development (Jean-Eric) u OpRec almost final (Jean-Eric) u full simulation run during June ? u Gen+Hits+Digits+Tracks TTree delivery end of June ? u conversion back to zebra ntuple ?