1. Muon Persistency Persistent Analysis Objects Muon Persistency Norbert Neumeister µ-PRS meeting February 10, 2004

2. Muon PRS meeting Norbert Neumeister2 Outline What are analysis objects Why persistent analysis objects COBRA interfaces Muon Persistency Impact on Muon/MuonReco software

3. Muon PRS meeting Norbert Neumeister3 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)

4. Muon PRS meeting Norbert Neumeister4 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

5. Muon PRS meeting Norbert Neumeister5 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.

6. Muon PRS meeting Norbert Neumeister6 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!

7. Muon PRS meeting Norbert Neumeister7 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

8. Muon PRS meeting Norbert Neumeister8 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

9. Muon PRS meeting Norbert Neumeister9 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

10. Muon PRS meeting Norbert Neumeister10 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

11. Muon PRS meeting Norbert Neumeister11 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

12. Muon PRS meeting Norbert Neumeister12 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 (“numberOfTracks”);

13. Muon PRS meeting Norbert Neumeister13 ComponetSet 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! A B C DEFG 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).

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

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

16. Muon PRS meeting Norbert Neumeister16 Muon Object Track RecObjBasicRecTrack TTrackRecTrack RecMuonConcreteRecTrackPRecTrack IsolatedRecMuon value semantics proxy

17. Muon PRS meeting Norbert Neumeister17 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 muonTrack TRecRef trackerTrack Foresee a reference to “Seed” for L2 and L3 reconstruction

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

19. Muon PRS meeting Norbert Neumeister19 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

20. Muon PRS meeting Norbert Neumeister20 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