opera framework status report n.
Skip this Video
Loading SlideShow in 5 Seconds..
Opera Framework : Status Report PowerPoint Presentation
Download Presentation
Opera Framework : Status Report

Loading in 2 Seconds...

play fullscreen
1 / 10

Opera Framework : Status Report - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
data flow and link proposed 6 9 01
Data flow and link: proposed 6/9/01

Link between data


MC Data

Cooked Data












Real Data






J.E Campagne

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

ttrees folders proposed 30 10 02
TTrees/Folders (proposed 30/10/02)

green: exists in present hierarchy

J.E Campagne

ttree access opio treemanager
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

root io memory data
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

current work
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

next work
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

  • 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

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