1 / 23

Report on the recent Muon Software workshop

Report on the recent Muon Software workshop. S. Spagnolo for the Muon Group Muon software meeting, 30 April 2002. Agenda of the workshop. 17 April 2002 09:00-09:15 Introduction: Goals of the workshop 17 April 2002 09:15-11:50   Detector Description/Geometry Model 

sarah
Download Presentation

Report on the recent Muon Software workshop

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. Report on the recent Muon Software workshop S. Spagnolo for the Muon Group Muon software meeting, 30 April 2002

  2. Agenda of the workshop 17 April 2002 09:00-09:15 Introduction: Goals of the workshop 17 April 2002 09:15-11:50  Detector Description/Geometry Model  17 April 2002 11:00-15:00  Event Data Model  17 April 2002 13:50-17:00  Reconstruction Event Model  17 April 2002 17:00-17:20  Muon Spectrometer package restructuring  17 April 2002 18:30-19:00  Muon sw deliverables for DC1 phase 2  18 April 2002 09:00-14:00  Moore Workshop  18 April 2002 17:00-19:00  ATLAS Tracking EDM Session 19 April 2002 11:00-13:00  Closeout Transparencies of talks in http://documents.cern.ch/AGE/current/fullAgenda.php?ida=a02589 Goal of the workshop define deliverables for DC1, phase 2, i.e. Sept.-Dec. 2002 S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  3. Main items of the workshop • A new geometry model (following BN L workshop) • Toward the new event data model: raw data view and reconstruction view • Status of the muon software: planning for restructuring and deliverables for DC1 – phase 2 S. Goldfarb, discussion S. Rajagopalan, D. Adams, A. Nisati, L. Pontecorvo, A. Poppleton, discussion J.Shank, S.S., G. Stavropoulos, M. Biglietti, G. Cataldi, discussion S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  4. fromS. Goldfarb Current geometry model and data flow in the Muon-sw Excel Spreadsheets Parameter Book Technical Drawings graphics AMDB ASCII File graphics Common Blocks AGE Structures FADS/Goofy zebra zebra Athena graphics MuonDetDescr Interface GEANT4 Simulation GEANT3 Simulation objy graphics graphics Muonbox Reconstruction Moore Reconstruction S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  5. It must satisfy the following “minimal” requirements: (from the muon reconstruction side) efficient access to Detector Elements; provide shape, position, orientation, material; allow for the selection of a user-defined region; point to point navigation (with knowledge of crossed material) is not requested Functionality available (although inefficiently) in the current model Why a new geometry model (or shoortcomings of the present model) ? Mainly, to have a single source of Detector Description for all the applications with different interfaces to the clients. Geometry changes affect the interfaces, not the applications disentangle geometry description from event management AGDD status in the muon-sw: far from having a full translation of AMDB interface to GEANT4 trivial no path from AGDD to GEANT3 simulation no path to applications (Muonbox, Moore) Automatic DetDescr (C++ classes) from XML files S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  6. 9-10 Apr. 2002 BN L - The ATLAS Detector Description WorkshopA path for a coherent model for Detector Description in the experiment has been defined (based on the CDF geometry model) Geometry Model scope: maintain primary data; generate a single, common transient geometry model (hierarchical tree a la GEANT4) Reconstruction API: identifier  detector element hold info like shape, size, material, position, orientation, location in the hierarchy tree, construction and condition parameters High level geometry services (propagation, scattering) fall into the scope of the reconstruction Main components Primary numbers: define geometry hierarchy and digitization, material definition and identifier dictionary Geometry Model: geometry manager + geometry builders readout geometry, material builders, alignment updates S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  7. Goal:move to the new geometry model and to the new event data model at the same time (DC1 phase 2, DC2 – fall 2002) Short term plan:prototype the CDF geometry model in ATLAS Primary data MySQL (P. Nevski); AthenaSvc for MySQL done; Version selection service to be done; a working version by end of May How ? Geometry model Athena interf. (D. Quarrie, P. Calafiura, J. Boudreau) G3/G4 (A. Dell’Acqua, J. Boudreau, P. Nevski) conditional data (J. Boudreau, M. Shapiro, C. Leggett) XML build (C. Arnault, S. Bentvelsen, J. Boudreau) detector specific prototype (SCT, TRT, EM-endcap); a working group set-up for the MuonSpectrometer (D. Adams, S.Goldfarb, J.F. Laporte, G.Stavropouls, ) Unclear points: - where does AGDD enter the play ? (layer between MySQL and the CDF C++ classes or XML gets built from the geometry model) - how much of MuonDetDescr can be reshuffled in the muon implementation of the new geometry model ? - a scale caveat (20K volumes in CDF while 2.5M in ATLAS) S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  8. from M. Paniccia Muon AGDD Package in Athena Displayed with PERSINT The end-cap toroids described with compact AGDD S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  9. The overall scheme of data flow in simulation and in real data: Raw Data Toward the new event data model Hardware side: The data format must be defined at the ROD/ROB level and at the DAQ level. MDT: data-format documented and trained in the H8 test beam; RPC: defined, documentation close to appear TGC: documetation available CSC: work going on in BNL from L. Nisati from S. Rajagopalan S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  10. from L. Pontecorvo A real implementation: reconstruction data model and geometry model in H8 beam test data Basic object for reconstruction: MDTMultiLayer a collection of MDTHits in the same multilayer, where tracks are ~ straight lines. Its geometrical definition is given by GeoMDTMultiLayer, a collection of GeoMDTTubespointing to tube specific calibration constants (t0, r-t relations …). Primary numbers for the geometry description from AMDB / Identifier scheme close to the final approved scheme From MDTHits in one or more MDTMultiLayers, Tracks are built ascollections of MDTHits within one MDTMultiLayer or one chamber (a pair of MDTMultiLayers). Eventually Tracks from more than one chamber are merged into a TrackCollection Performance: rate of 300 Hz on a 800 MHZ linux machine for single track events. The algorithm will run as 3rd level trigger, besides of being monitoring tool, in the next beam tests. Planning to move to the Athena framework and integrate with existing reconstruction packages S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  11. Transient components of the Muon Reconstruction Software Event Data Model:Reconstruction Data (and algorithms) from D. Adams S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  12. DATA XDigit:concrete digit (identifier + data) XRecoHit:concrete digit interface for fitting (measurement + error) can be predicted from a TrackFit TrackFit: fit result (one point on the track, a surface where the 5 track parameters are given along with the covariance matrix) TrackState: data corresponding to a TrackFit (XRecoHit collection, missed active layers, fit quality, kinks) TrackSegment:collection of TrackStates; return TrackFit at any surface; holds a pointer to a Fitter XSurface:concrete surface where the XRecoHit or the TrackFit parameters are defined Algorithms Propagator:propagates a TrackFit to a generic Surface Finder:uses RecoHits to build TrackSegments Fitter:uses TrackSegments to build TrackFits A persistent representation is needed only for Xdigit and TrackSegment A persistent representation is needed only for Xdigit and TrackSegment S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  13. Generic XXXLinear External Identifier Algebra Package organizationand status ATLAS Detector MuonLinear MuonPtr Package holding all the abstract classes of the structure and the TrackFit class (a simple version exists, not in CVS) Description Algebra Muon MuonBase Identifiers Tracking Implemented for MDT (already in CVS); input doesn’t come yet from an identifier dictiorary Muon Muon MuonDigit specific Surface Container Muon Propagator1 Propagator2 RecoHit Implemented for MDT (already in CVS) Fitter1 Fitter2 Finder1 Finder2 A package helping memory management Plan to wrap existing finders and fitters into this generic structure S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  14. TrackParameters PerigeeParameters ScattererParameters might become TrackFits at different surfaces HitOnTrack (input to the fit, link to digits + track dependent calibration of position measurement) might become XRecoHit Track track status, TrackParameters, Collection of HitOnTrack might be split into TrackStatus and TrackSegment might be wrapped into Finder, Fitter, Propagator iPatTracka track fitting package in ID and Muon System nowan implementation of Finder, Fitter, Propagator tomorrow ? from A. Poppleton • 2 packages contain families of data classes • iPatTrackParameters(4 classes) • iPatTrack(~8 classes - plus some legacy classes) • 2 algorithmic packages • iPatTrajectory(5 classes)swim TrackParameters through Atlas magnetic fields (choice of parametrisation or RungeKutta integration) • iPatTrackFitterproduce FitQuality and fitted TrackParameters at various positions along the track trajectory S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  15. Tracking in Inner Detector and Muon Spectrometer • Sharing • The requirements leading to the muon tracking packages are shared with the inner detector • Muon and inner detector can benefit from sharing the development effort • A common output track class would facilitate the exchange of data between these groups and to other groups • We should strive to find common solutions • A first step: Muon-ID meeting (18-Apr-2002) a combined w.g. set up: D.Adams, S. Amstrong ??? S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  16. from J. Shank Package Restructuring following a proposal from D.Quarrie and D. Rousseau to separate data objects and algorithms in the existing packages: Algorithms depends on data object (output in TDS) Data dependency on algorithms is minimal reduce overall dependencies, data objects can be easily shared by different algorithmic objects We’ll follow this plan in Moore (exchange intermediate objects through StoreGate) in MuonDetDescr and MuonEvent (isolate ZEBRA dependent code) Subsequent package organization XXXAlgs Algorithms XXXCode Algorithmic code used by Algorithms XXXData ADL files and transient data XXXNaiveObjy Converters and NaiveObjy persistent classes XXXROOT Converters and ROOT persistent classes S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  17. RPC_Digits MooiPat Package MooMakePhiSegments PhiSegments MooMakeCrudeRZSegments MDT_Digits StepOne CrudeRZSegments MooMakeFineRZSegments FineRZSegments MooMakeiPatTracks MooiPatTracks MooMakeCrudeRZSegments CrudeRZSegments StepTwo MooMakeFineRZSegments FineRZSegments MooMakeiPatTracks MooiPatFinalTracks MooStatistics Package MooMakeNtuple MooNtuple from M. Biglietti Moore Restructuring done, in CVS S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  18. A proposal under study StepOne – StepTwo modules are very similar: same task/interface; differences in I/O transient objects, value of external parameters use inheritance Moore Restructuring AthenaAlgorithm MooiPat abstract base classes MooMakeCrudeRZSegments MooMakeiPatTracks MooMakeFineRZSegments StepOne StepTwo StepOne StepTwo StepOne StepTwo S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  19. Separation between Transient Data and Algorithms allows for various reconstruction paths selected by job_option An example: PhiSegments and RZSegments from LVL2 input Moore Restructuring from G. Cataldi MooiPat Package RPC_Digits MooMakeL2PhiSegments PhiSegments MDT_Digits An alternative reconstruction path done, in CVS MooMakeL2CrudeRZSegments CrudeRZSegments MooMakeL2FineRZSegments FineRZSegments MooMakeL2iPatTracks MooiPatFinalTracks MooStatistics Package MooMakeNtuple MooNtuple S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  20. from G. Stavropoulos Moore Performance Track finding in Barrel and End-caps for Layout M pT = 100 GeV No background PTrec/PTgen In samples with correlated background # tracks/event increases by ~15% RMS of prec/pgen increases by ~10% for tracks with pT = 20 GeV PT / GeV Ready to recontruct events simulated according to Layout O S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  21. Moore Performance in physics events: H  4 m from M. Paniccia Solid line: Invariant mass of the 4 generated muons at beam spot Dotted line: Invariant mass of the 4 reconstructed muons; track parameters are given at their first measured point Invariant mass /GeV S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  22. Layout O and G3 Decoding in Athena from S.S. Current status: MDT tube positions OK for all stations except BOH and BOG RPC gas gap positions OK for all stations, including new extra chambers TGC gas gap positions OK for all stations at z>0 (needs to verify the z symmetry of the descriptors and of the Geant 3 coding) Changes to MuonEvent and MuonDetDescr are “transparent” to reconstruction applications ? Yes for Moore, no for Muonbox in ATHENA (it uses MuonEvent but gets its own geometry description by reading amdb_simrec) CSC description Work going on in BNL (K. Assamagan) descriptors are ready, need to get CSC digit collections from the event and to get a decoding of the Geant3 digits S. Spagnolo, CERN 30 Apr. 2002, Muon Week

  23. Deliverables for DC1 - phase 2 Geometry Model: by the next sw-meeting (end of May) we’ll know the progress in the evaluation of the impact of the new geometry model; by the July muon-sw-workshop we’ll define the plan for DC1-2; Reconstruction Data Model: the new Digit package will be ready (BNL); the internal evaluation and development of the new proposal will follow the time scale of the Geometry Model Moore: restructured by DC1-2 accounting for dead material handling Layout P S. Spagnolo, CERN 30 Apr. 2002, Muon Week

More Related