1 / 10

Opera Framework : Status Report

Opera Framework : Status Report. Data flow and link : proposed 6/9/01. Link between data. Generation. MC Data. Cooked Data. GenParticles. Particles. OpRec. MCParticles. OpRoot. TrackKinematics. MC Vertices. TracksElement. Tracking. Information. MCHits. Real Data. Pattern.

swain
Download Presentation

Opera Framework : Status Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Opera Framework: Status Report J.E Campagne

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

  3. OpRoot/OpTreeConvert • 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. • 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. J.E Campagne

  4. TTrees/Folders (proposed 30/10/02) green: exists in present hierarchy J.E Campagne

  5. TTree access: OpIO/TreeManager • 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. • 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. J.E Campagne

  6. ROOT IO & Memory data • 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 J.E Campagne

  7. Current work • 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 J.E Campagne

  8. Next work • 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 • Documentation: • OpIO: should be done in priority • OpTest (or MyAna): skeleton of user analysis • Adore Ntupe to TTree (HBookToRoot), Tree2Tree exist, now may be Tree2Ascii (storage but not load !) should be done? J.E Campagne

  9. Apologizes • 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 andtime wasted due to Memory Leak in ROOT 3.3/5 => ROOT 3.5/4 J.E Campagne

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

More Related