1 / 20

Persistent Analysis Objects Muon Persistency

Persistent Analysis Objects Muon Persistency. Norbert Neumeister µ -PRS meeting February 10, 2004. Outline. What are analysis objects Why persistent analysis objects COBRA interfaces Muon Persistency Impact on Muon/MuonReco software. Introduction.

bracha
Download Presentation

Persistent Analysis Objects Muon Persistency

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. Persistent Analysis ObjectsMuon Persistency Norbert Neumeister µ-PRS meeting February 10, 2004

  2. Outline • What are analysis objects • Why persistent analysis objects • COBRA interfaces • Muon Persistency • Impact on Muon/MuonReco software Norbert Neumeister

  3. Introduction • Analysis Objects (reconstructed objects): • clusters, RecHits, track segments, etc. • tracks, vertices, muons, electrons, jets, etc. • Persistent analysis objects • store the result of event reconstruction DST/ESD • need a first prototype for DC04 • Persistency • Use COBRA/POOL • Use RootTrees (rootcint) • User defined persistency (e.g. ntuple like RootTree) Norbert Neumeister

  4. RecObject Persistency Requirements: • Ability to make the data part of the object persistent • Ability to store relations between RecObjects • Ability to query for the stored objects, and trigger reconstruction if the stored objects do not correspond to the query Norbert Neumeister

  5. Analysis Objects • Reconstructed objects are hierarchical: • High-level objects are constructed from lower level objects • Examples: Jets are constructed from Tracks, Vertices are constructed from Tracks, etc. • At the lowest level all objects are constructed from raw data (Digis) • A single reconstruction algorithm (aka RecUnit) may use several instances of lower level algorithms simultaneously • Reconstructed tracks from various algorithms (Kalman Filter, DAF, GSF) may be combined in a high level object. Norbert Neumeister

  6. Problems • Collection of RecObjects is identified by a string • RecUnits (reconstruction algorithms) are just identified by a string (e.g. GlobalMuonReconstructor) • Dependencies on other RecObjects are not taken care of • The hierarchy of RecUnits is not handled. • A RecObject provided by a RecUnit may depend on • other RecUnits (in general a tree of components) • their associated parameters • the versions of the algorithms used It is necessary to get the configuration used to create the objects together with the object collection! Therefore a collection of reconstructed objects is not just identified by a string! Norbert Neumeister

  7. Requirements (I) • A collection of reconstructed objects is defined by: • Type of reconstructed object • Name of algorithm • similar to the current string • identifies the algorithm builder • Version of algorithm • the developer must set the version of an algorithm • avoid new version when only documentation is changed • ParameterSet(parameters of all algorithms but not of all components) • ComponentSet(dependency on other RecUnits) • Calibration • Save full dependency and check state of underlying objects • i.e. collection of jets depends on tracks and CaloClusters, tracks depend on tracker digis, etc. • Guarantee same results for same configuration Norbert Neumeister

  8. Requirements (II) • The user can access a collection of reconstructed objects by specifying the RecObject type and a RecQuery (see later) • Provide only one documented user interface to retrieve reconstructed objects: RecCollection • No pointer to G3EventProxy should be necessary • default is current event • new RecCollection interface Norbert Neumeister

  9. Configuration • The full configuration is defined by: • Name • Version • ParameterSet • ComponentSet • CalibrationSet • RecConfig defines the full configuration of a RecUnit • Defines “equal” operator • The operator returns true only if all parts compare equal • Every reconstruction algorithm needs a default configuration! • RecQuery • defines a subset of the full configuration • can obtain the full configuration from a registered RecUnit Norbert Neumeister

  10. RecConfig Settings Order of initialization: 1) defaultConfig of the algorithm • That’s the only place where parameter names and types are defined 2) .orcarc: Every parameter is configurable with the following syntax • AlgorithmName:ParameterName = value • overwrites 1) 3) The current RecQuery overwrites 2) For components same sequence as for parameters in a recursive way: AlgorithmName:ComponentName:ParameterName = value Norbert Neumeister

  11. ParameterSet (I) • A class that contains the complete set of RecUnit parameters exposed as configurable by the author • If a RecUnit is implemented by several algorithmic classes, like a TrackReconstructor which uses SeedGenerator, TrajectoryBuilder, etc. then all parameters of all such classes are grouped in a single parameter set • The Parameters of lower level algorithms are not part of the parameter set of a high-level algorithm Norbert Neumeister

  12. ParameterSet (II) • Parameters are organized as pair of string and value (name, value) • The name is in the scope of the ParameterSet and can be reused in other ParameterSets • The only way to instantiate a non-empty ParameterSet is by using a ParameterSetBuilder (prevent from changing an existing ParameterSet) • The following types are supported: int, bool, double, string • For double the equal operator allows tolerances • If nothing set explicitly all parameters are default values • Usage: ParameterSetBuilder builder; // add integer builder.addParameter(“numberOfTracks”,10); // add double with tolerance builder addParameter(“deltaRCut”,0.6,0.002) ParameterSet ps = builder.result(); int nTracks = ps.value<int>(“numberOfTracks”); Norbert Neumeister

  13. ComponetSet A B C D E F G • If a RecUnit uses the result of other RecUnits, like a Vertex algorithm uses reconstructed tracks, it should fully specify the configuration of the lower level RecUnits via RecConfigs. • A ComponentSet is a set of pairs (name, RecQuery) • The name is in the scope of the concrete component • The ComponentSet is a set of all RecQuery objects • use a recursive query! RecUnits: A, B, C, D, E, F, G B, C, D, E, F, G are components of A In addition RecUnit A can use a list of algorithms (TrajectoryBuilder, TrajectoryCleaner, TrajectorySmoother). Norbert Neumeister

  14. RecCollection Retrieving (persistent) objects: MyRecObj inherits from RecObject RecCollection<MyRecObj> myobjects(RecQuery("Name_of_algorithm“)); cout << myobjects.query() << endl; RecCollection<MyRecObj>::const_iterator it; Recommendation: Use RecCollection instead of AutoRecCollection or RecItr in ORCA. Don’t use RecItr, AutoRecCollection anymore. Norbert Neumeister

  15. Usage RecQuery q(“JetFinder”); q.setParameter("ConeSize", 0.77); RecQuery myTF(“TrackFinder”); q.setComponent("TrackReconstructor",myTF); ... RecCollection<Jet> myjets(q); cout << myjets.size() << endl; cout << myjets.query() << endl; Norbert Neumeister

  16. Muon Object Track RecObj BasicRecTrack value semantics proxy TTrack RecTrack ConcreteRecTrack PRecTrack RecMuon IsolatedRecMuon Norbert Neumeister

  17. Persistent Muon • Persistent Track data: • First and last Trajectory State • Track quality criteria • Chi^2 (smoothed) • Number of degrees of freedom • Number of hits used in the fit • Number of “lost” hits • Persistent RecMuon data: • innermost and outermost Trajectory State • Vertex extrapolated State (MuonUpdatorAtVertex: stateAtIP, stateAtVertex) • Track quality • TrajectoryState persistency as for Tracker • TRecRef<TTrack> muonTrack • TRecRef<TTrack> trackerTrack • Foresee a reference to “Seed” for L2 and L3 reconstruction Norbert Neumeister

  18. Muon Reconstruction • For the time being we have four different muon reconstruction algorithms implemented: • StandAloneMuonReconstructor • GlobalMuonReconstructor • L2MuonReconstructor • L3MuonReconstructor • Convert all four algorithms into RecAlgorithm<RecMuon> • must inherit from RecAlgorithm<T> • The result of the reconstruction (e.g. RecMuon) must inherit from RecObj • Each algorithm must have a registered Builder • inherit from RecBuilder<AlgorithmName> • In first iteration no RecAlgorithm components • SeedGenerator is a first candidate for a configurable component Norbert Neumeister

  19. Muon Isolation • We have a variety of isolation algorithms • calo, pixel, tracker; combined; on HLT or offline; • based on simple deposit, probability, nominal efficiency… • The result of any algorithm can be summarized in a single float variable • User cuts on: can choose efficiency vs. rejection • The variable can have whatever meaning • The user must know the meaning • Nominal efficiency, e.g. cut > 0.97 ⇒ ε = 97% on signal • Simple deposit in GeV (the most requested in the past: if not provided • Bottom line: 1 algo ↔ 1 float • RecMuon has no isolation information stored • Create additional RecObj: IsolatedRecMuon • Has a reference to a RecMuon and one float. • Result of 2 isolation algorithms are in 2 different RecCollection<IsolatedRecMuon> Norbert Neumeister

  20. Summary • Status • First implementation in COBRA_7_6_0_pre1 and ORCA_7_7_0_pre1 • Works on a toy example • Persistent Tracker Tracks in CORCA_7_7_pre3 • Should be used by all high-level subsystems • For all analysis objects: Tracks, Muons, Electrons, Jets, etc. • Muon software: • Hope to have a first version by the end of the week • Start with a RecMuon class prototype • Test with standalone muon reconstruction Norbert Neumeister

More Related