1 / 28

Event Data Processing

This article discusses the current limitations of detector description in event data processing and proposes a future framework for addressing the needs of simulation, reconstruction, data analysis, calibration/alignment tasks, and physics analysis. The aim is to provide a coherent and structured detector description that can be used by all these applications. The article also highlights the benefits of a common description for subdetectors and the potential for reuse of common elements.

seitz
Download Presentation

Event Data Processing

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. Event Data Processing Philosophical changes of future frameworks Detector Description Other applications M.Frank CERN/LHCb

  2. Motivation • The detector description is part of the toolbox • I cannot be viewed independently from the corresponding application • There are different requirements for • Simulation • Reconstruction • Data analysis • Calibration/Alignment tasks • Physics analysis • The point is to describe the detector in a way all these applications are happy M.Frank CERN/LHCb

  3. Simulation – as it is nowOne sensitive detector as an example Database(Mokka) get params create volumes / vis attrs MokkaDriver( VXD03 ) GDML Geant4 feed params for fast geo Geometry(Gear) fast geo material budget Reco (Marlin) M.Frank CERN/LHCb

  4. Current Situation (1) • Detector description effectively is limited to • geometry • material description • Simulation uses Mokka drivers • Can only be altered by maintainer(s) • …And some modules will never change: author left, maintainer has no time, … • Reconstruction uses gear • May not be changed (at best enhanced) • backwards compatibility • Is this situation sufficient ? • for now sure … it works M.Frank CERN/LHCb

  5. For the Simulation this led to: • A rather coherent framework (Mokka-core) • Incoherent driver implementation • Each author did as good as he could • Development was driven by time pressureand minimal effort approach • A common design was not applied • Incoherent usage of the Geant4 geometry package • The placement of structures in space is anarchy • Some did it nicely with an envelope volume etc. • Others (e.g. my example) just places individual laddersinto the “world” • Ask Astrid… M.Frank CERN/LHCb

  6. Origin of the current situation (1) • Requirements are not fixed • …depend on experiment life cycle • Simple parameterization ofideal detector What is available is sufficient for this purpose. Hence, at this stage any further detector description development stopped. Detector opt. LCD is here CDR / LOI M.Frank CERN/LHCb

  7. Origin of the current situation (2) • Requirements are not fixed • …depend on experiment life cycle • Simple parameterization ofideal detector • After TDR: Transition from parameterizeddetector to real description • Readout structure • Alignment constants • Calibration constants Detector opt. LCD is here CDR / LOI Detector opt. TDR Construction Operation M.Frank CERN/LHCb

  8. Assumptions • Geant 4 is the de-facto standard for the simulation of HEP experiments • A detector description can be designed, which serves • Geant 4 and • experiment specific applications as there are: • Reconstruction • Physics analysis of reconstructed data • Calibration/Alignment applications M.Frank CERN/LHCb

  9. Geometry VXD Table ofContent TPC Readout …. Alignment What is “Detector Description” ? The way to access all properties of a (sub-) detector, which are necessary to process the event data from particle collisions • Like a library • With different shelves • Topic oriented M.Frank CERN/LHCb

  10. Geometry VXD Table ofContent TPC Readout …. Alignment What is “Detector Description” ? • With some librarian clerk giving books on request to clients • Clerk = API • Clients do not know the location of the books … M.Frank CERN/LHCb

  11. The Content of the Library • Detailed geometry description e.g. for simulation • Parameterized description for reconstruction • Readout structure (digitization + reconstruction) • Alignment constants Time • Calibration constants dependent • Visualization parameters (colors, wireframe, etc.) • … (not exhaustive) M.Frank CERN/LHCb

  12. Required Functionality • Detector optimization • Conversion from simple parameterization to detailed geometry • Now in G4 code (extracted to GDML file) • Construction phase • Support for fully featured simulation according to “true” geometry • Digitization and emulation of raw data from the detector • Provisional support for sub-detector specific data • Alignment etc. M.Frank CERN/LHCb

  13. Wrapup • A complete and structured detector descriptionseems to be missing (come to this one later) • Existing code will (or will not) change unless the author(s)see a clear advantage in using a common descriptionsuch as: • Generic G4 code • Common visualization (HEPREP, WIRED, …) • New functionality:- Provision to support alignment processors- Provision to calibration M.Frank CERN/LHCb

  14. From LHCb experience • Given a common syntax to describe subdetectors • You get many things for free, if *everybody* can adhere to a few conventions • Obvious synergy be reuse of common stuff • or more polemic: Not every subdetector has to learn how to describe a box of a given material to Geant 4 • Generic simulation code • Generic event displays • There is still the possibility to specialize according to a given sub-detector M.Frank CERN/LHCb

  15. Existing Restrictions • Needed is a backwards compatible solution • Simulation: • Existing drivers may not be broken • New drivers can take advantage of new concepts • But: New drivers will also have to support existing processors (gear parameter file) • Reconstruction • Existing processors must continue to work • New processors can take advantage of new concepts • Is there a solution ? M.Frank CERN/LHCb

  16. Let’s start again from what is present Database(Mokka) get params create volumes / vis attrs MokkaDriver( VXD03 ) GDML Geant4 feed params for fast geo Geometry(Gear) fast geo material budget Reco (Marlin) M.Frank CERN/LHCb

  17. This is where one wants to arrive: create volumes / vis attrs detailed geo+ visualization attrs Database(Mokka) Generic G4Driver Geant4 There would be only one leftfor all subdetectors and all models getparams Geant4Visualization GeometryExpansion Detector Description Access according to needs Alignment const. -Reconstruction-Alignment-Analysis Processor(s) Calibration const. feeddetailed geometry Visualization attrs. Parametrized Geo. Detailed Geometry Event Display geometry+ visualization attrs M.Frank CERN/LHCb

  18. This is where one wants to arrive: create volumes / vis attrs detailed geo+ visualization attrs Database(Mokka) Generic G4Driver Geant4 SLIC There would be only one leftfor all subdetectors and all models getparams Geant4Visualization GeometryExpansion Detector Description Access according to needs Alignment const. -Reconstruction-Alignment-Analysis Processor(s) Calibration const. feeddetailed geometry Visualization attrs. Parametrized Geo. Detailed Geometry Event Display geometry+ visualization attrs M.Frank CERN/LHCb

  19. Is an adiabatic change possible ? • Existing code must continue to workAt least with only minimal changes • Let’s see… M.Frank CERN/LHCb

  20. Let’s start again from what is present Database(Mokka) get params create volumes / vis attrs MokkaDriver( VXD03 ) GDML Geant4 feed params for fast geo Geometry(Gear) fast geo material budget Reco (Marlin) M.Frank CERN/LHCb

  21. Geometry – backwards compatibility create volumes / vis attrs Database(Mokka) get params Geant4 VXD03 feed parameterization Generic G4Driver get params Gear feed GDML gear file params Detector Description MarlinProcessor • full access to- parameterization- detailed description • material budget • according to needs SomeApplicationProcessor M.Frank CERN/LHCb

  22. Geometry – backwards compatibility create volumes / vis attrs Database(Mokka) get params Geant4 VXD03 feed parameterization Generic G4Driver get params Gear These are text files.Nothing has to be done to ONLY support old software feed GDML gear file params Detector Description MarlinProcessor • full access to- parameterization- detailed description • material budget • according to needs SomeApplicationProcessor M.Frank CERN/LHCb

  23. Structured Detector DescriptionRequired Conventions • Best is to pick “some” commonly used standard • e.g. Geant4 and SLIC use GDML • Additional data could be subsections • or references to external data • Common material definitions • Common visualization definitions • Volume declaration • ONLY the framework places things in the “world” • …. M.Frank CERN/LHCb

  24. Conclusions: Detector Description • A common structured detector description • implemented in a widely accepted syntax • possibly enhanced by detector specific items • would lead to a lot of synergy between various LCD apps: • Simulation • Reconstruction • Analysis-, Alignment- and Calibration apps • I think I showed a possible path • which does not break existing code • would allow now modules to take advantage thereof M.Frank CERN/LHCb

  25. Conclusions: Simulation • The current detector description looks to be insufficientin the long future • If it is possible to agree on either • a common detector description • or subparts (interface) of it required by G4 • A common simulation program for most of the HEP community is feasible • This would lead to sw scope beyond one experiment ===> We could ask for support from SFT / G4 M.Frank CERN/LHCb

  26. Backup Slides M.Frank CERN/LHCb

  27. Geometry – more logical to me Database(Mokka) MokkaDriver( VXD03 ) Geant4 create volumes / vis attrs detailed geo getparams Geometry Full details GDML Parameterization material budget fast geo (gear) feed params for fast geo Reco (Marlin) M.Frank CERN/LHCb

  28. Geometry – or better formulated create volumes / vis attrs MokkaDriver( VXD03 ) Geant4 detailed geo This interface does not exist Geometry Geant4Visualisation Database(Mokka) GDML getparams This interface is called gear fast geo+ material budget Reco Processor(Marlin) M.Frank CERN/LHCb

More Related