CAFÉ’: A possible scenario for progressing

1. CAFÉ’:A possible scenario for progressing Vincenzo Innocente CERN/EP Vincenzo Innocente

2. Documentation of Current Architecture • CARF (and Utilities) is being documented, according to a format proposed by Lassi, in the Framework of ORCA Reference Manual • CommonDet (detector-centric reconstruction sub-framework) should be documented next • Work on “Framework Use Cases” has started although they cannot be considered independent of the general analysis strategy that only now start to be re-discussed • some detailed scenarios already exists even in CTP Vincenzo Innocente

3. Architecture Review • Current Architecture is largely based on the analysis that CTP authors did of CMS requirements confronted with previous HEP software architectures (original design, before data taking started, and their evolution) • This kind of analysis can be “refreshed” with inputs from “new collaborators” and more recent experiences • We can try to volunteer some “non CTP author” to describe her/his view on software architectures (s)he had experience with Vincenzo Innocente

4. Different Software Later selected DAQ Not in original design Later more filters to DVNs and Ntpule Vincenzo Innocente

5. Analysis & Reconstruction Framework Physics modules Specific Framework Event Filter Reconstruction Algorithms Physics Analysis Data Monitoring Generic Application Framework Calibration Objects Configuration Objects Event Objects adapters and extensions Utility Toolkit ODBMS C++ standard library Extension toolkit Geant3/4 CLHEP Paw Replacement Vincenzo Innocente

6. Reconstruction Scenario • Reproduce Detector Status at the moment of the interaction: • front-end electronics signals (digis) • calibrations • alignments • Perform local reconstruction as a continuation of the front-end data reduction until objects detachable from the detectors are obtained • Use these objects to perform global reconstruction and physics analysis of the Event • Store & Retrieve results of computing intensive processes Vincenzo Innocente

7. Problems with traditional architectures • Traditional Framework schedules a-priori the sequence of operations required to bring a given task to completion • Major management problems are produced by changes in the dependencies among the various operations • Example 1: • Reconstruction of track type T1 requires only tracker hits • Reconstruction of track type T2 use calorimetric clusters as seeds • If a user switches from T1 to T2 the framework should determine that calorimeter reconstruction should now run first • Example2: • The global initialization sequence should be changed because, for one detector, some condition changes often than foreseen Vincenzo Innocente

8. The challenge • Determine what to run and in which order for a given input and a given user request • Cope with evolving environment • Modified detector read-out • New algorithms The answer cannot be “Rerun the complete reconstruction and analysis” Vincenzo Innocente

9. HEP Experiment-Data Analysis Quasi-online Reconstruction Environmental data Detector Control Online Monitoring store Request part of event Store rec-Obj Request part of event Event Filter Object Formatter Request part of event store Persistent Object Store Manager Object Database Management System Store rec-Obj and calibrations store Request part of event Data Quality Calibrations Group Analysis Simulation G3or G4 User Analysis on demand Vincenzo Innocente

10. Algorithm Algorithm Algorithm Rec Objs Rec Objs Rec Objs Reconstruction Model Geometry Conditions Sim Hits Raw Data Detector Element Event Digis Rec Hits Algorithm Vincenzo Innocente

11. 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 CaloCl Rec T2 Analysis Rec CaloCl T2 Vincenzo Innocente

12. Reconstruction Object Model All persistent objects are managed by the framework. Physics Modules access them through standard C++ pointers Vincenzo Innocente

13. Vincenzo Innocente