1 / 19

CMS Production in 2000

CMS Production in 2000. Persistency in high level trigger, reconstruction and analysis. Vincenzo Innocente, David Stickland. ORCA Project. Top Down design of entire project impractical Gain experience by deploying the project in phases ORCA 1 (Dec 1998)

brownmichelle
Download Presentation

CMS Production in 2000

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. CMS Production in 2000 Persistency in high level trigger, reconstruction and analysis Vincenzo Innocente, David Stickland

  2. ORCA Project • Top Down design of entire project impractical • Gain experience by deploying the project in phases • ORCA 1 (Dec 1998) • Basic reconstruction in all sub detectors • Tolerated wrapped Fortran where appropriate • ORCA 2 (Spring 1999) • OO Implementations of all major components • More detailed digitization pileup etc. • ORCA 3 (Oct 1999) • General persistency implemented • Useable for Trigger Studies • In “Production” • ORCA 4 (Feb 2000) • Satisfy “Functional Prototype” Milestone. • A “complete” reconstruction package • More than a set of reco algorithms! We are Here CMS Production in 2000

  3. Use Cases • Simulated Hits Formatting • Digitization of Piled-up Events • Test-Beam DAQ & Analysis • L1 Trigger Simulation • Track Reconstruction • Calorimeter Reconstruction • “Physics” Reconstruction • Physics Analysis CMS Production in 2000

  4. Persistency • Currently we use GEANT3 simulation via CMSIM package. Migration to GEANT4 during 2000 • Digitization is very expensive in CPU • (200mb events for each signal event at high-luminosity) • Need to be able to save intermediate results • Objectivity Database • Use of Database is transparent to user program. No user code needs to be changed. • Objectivity handles etc, do not appear in user code • All Objectivity access is via CARF Framework • In ORCA 3 we make persistent: • Calorimeter digits (after pileup, noise etc) • Calorimeter trigger information • Muon hits and digits and trigger information • Generator tracks and vertices CMS Production in 2000

  5. ORCA and HLT • Trigger (HLT)/Physics studies have been first “user” for ORCA. • In October 99 we ran ORCA as a production job reading CMSIM signal and minimum bias files and filling two large databases with persistent ORCA results. • Used by Physicists studying HLT • 19 CPU’s running production (Linux and Sun) • Two production federations • Multiple AMS to reduce interference / timeouts • Automatic tape backup to HPSS as jobs complete • Automatic copying to two user federations • 30k events/day processed (>700GB in Obj/Db) • Calorimeter pileup requires 200 minimum bias events (=70MB) for every signal event! • Ran essentially faultlessly CMS Production in 2000

  6. First (1999) HLT studies with ORCA HEPEVT ntuples Zebra files with HITS CMSIM Pythia MC Prod. Objectivity Database ORCA Digitization DB pop. ORCA user Analysis ORCA ntuple production User Analysis User Analysis Analysis ntuples PAW CMS Production in 2000

  7. ORCA 2000 production • First ORCA production in October 99 was very successful, but ORCA prod.2000 must have much more functionality: • All data will be in the database • Every CMSIM run will have its objects in many database files • Single Db file contains concatenation from many CMSIM runs (65k files Objectivity limit) • Many layers of apparently autonomous federations actually synchronized by enforcing common schema and unique DbID’s CMS Production in 2000

  8. MC Processing 2000 Muon (FZ)User Minimum Bias JetMet …... JetMet G3 Hits and Tracks Each box is an independent production running in “parallel” ORCA Xings &Digis ORCA RecObjs JetMet Also required: Online late clustering and selection (clustering to oblivion) Offline selection and cloning CMS Production in 2000

  9. Selective Tracker Digitization Trigger Calorimetry Muon Tracker Trigger Calorimetry Muon Select Trigger Calorimetry Muon Tracker CMS Production in 2000

  10. Objectivity Database Objectivity Database ytivitcejbO esabataD ORCA Production 2000 Signal Zebra files with HITS HEPEVT ntuples CMSIM MC Prod. MB Catalog import Objectivity Database ORCA Digitization (merge signal and MB) Objectivity Database ORCA ooHit Formatter ORCA Prod. Catalog import HLT Algorithms New Reconstructed Objects Objectivity Database HLT Grp Databases Mirrored Db’s (US, Russia, Italy..) CMS Production in 2000

  11. ORCA 2000 Db Structure One CMSIM Job, oo-formatted into multiple Db’s. For example: FZ File Few kB/ev MC Info Container #1 ~300kB/ev 1 CMSIM Job ooHit dB's ~100kB/ev Calo/Muon Hits ~200kB/ev Tracker Hits Multiple sets of ooHits concatenated into single Db file. For example: MC Info Run1 MC Info Run2 ~2 GB/file Concatenated MC Info from N runs. MC Info Run3.. Physical and logical Db structures diverge... CMS Production in 2000

  12. March 2000 Production Plans.. • 2 Million CMSIM events at 1 CPU-minute/event • 2 Million events ORCA reconstructed with High-luminosity pile-up 1 CPU-minute/event • 2-4 Tera-Bytes in Objectivity/Db • 4 x 106 CPU-minutes = 400 CPU-weeks • ~6 Production-Units • import existing catalogs, • schedule and monitor jobs • ooTidy and copy to hpss • export new catalog and system files • ~1-2 Production Units off CERN site • Copy of all data at CERN in HPSS, use of IT/DB AMS-backend to stage data to ~1TB of disk pools • Mirroring of Data to a few off-site centers, including trans-Atlantic CMS Production in 2000

  13. R&D toward real Object DB Persistent Objects which load their own code Vincenzo Innocente

  14. Action “on Demand” Compare the results of two different track reconstruction algorithms Rec Hits Rec Hits Rec Hits Detector Element Hits Event Rec T1 T1 T2 Rec T2 Analysis CMS Production in 2000

  15. Loading issues • Analysis code could access T1 and T2 through a common abstract TRACK interface: the user may not be interested to T1 and T2 concrete classes • Analysis does not know if T1 and T2 have been actually already reconstructed. It should not be required to load the corresponding reconstruction code if T1 and/or T2 already exist as persistent objects. • Analysis code is required to be bound only to the library required by TRACK. • In accessing T1 and/or T2 the corresponding libraries should be loaded. • Reconstruction may require some additional libraries CMS Production in 2000

  16. “RecObj” Object Model CMS Production in 2000

  17. Objectivity Subtleties • When Objy open a persistent object it steals the pointer to the virtual table from the compiler. • Apparently, one can still call not virtual methods of the base class while the concrete class virtual table is not yet there. • Receipt to load its own code: • open a persistent object: the virtual table pointer may still be zero • call a not virtual method which loads the library containing the definition of the concrete class the object belong to • close the object • open it again : the virtual table pointer is now properly set! CMS Production in 2000

  18. CARF2000 Event Structure CMS Production in 2000

  19. Framework Persistency Services • Transactions • Metadata and event collections • Define the logical persistent object structure • Physical clustering • Access to persistent event structure • effectively shield physics modules from the underlying technology CMS Production in 2000

More Related