Development of Persistent Analysis Objects for Muon Reconstruction in High-Energy Physics

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