What ORCA developers need to know about Persistent Analysis Objects

1. What ORCA developers need to know about Persistent Analysis Objects Norbert Neumeister RPROM meeting February 2, 2004

2. Outline • What are analysis objects • Why persistent analysis objects • COBRA interfaces • How to make analysis objects persistent • HOWTO for ORCA developers • Example 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. COBRA/CARF • Up-to-now the only CARF mechanism for accessing RecObjects via a RecCollection was by string • Limitations: • No way to specify algorithm parameters in the query, or to get several RecCollections that differ only by algorithm parameter values • No way to specify reconstruction algorithms for lower level objects, like tracks for vertices • No way to know what parameters were used when reading a RecCollection Norbert Neumeister

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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. Norbert Neumeister

16. 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

17. Recipe for Developers (I) • All objects you want to make persistent must inherit from the class RecObj • class Track : public RecObj • class Jet: public RecObj • For references to other reconstructed objects one must use TRecRef or TRecVec instead of pointers • E.g.: The class Jet owns a TRecRef<Track> for the leading track and a TRecVec<Track> for the jet constituents • The reconstruction algorithm must inherit from the class RecAlgorithm templated with the object type it has to reconstruct • class JetAlgo : public RecAlgorithm<Jet> Norbert Neumeister

18. Recipe for Developers (II) • For all algorithm classes on has to implement the methods: • static RecConfig defaultConfig(); • virtual Name name() const { return defaultConfig().name(); } • virtual Version version() const { return defaultConfig().version(); } • virtual void reconstruct() • In the static method defaultConfig() the developer must fully specify the configuration of the algorithm. The configuration consists of: • name (string) • version (string) • list of parameters (pair of string and type) • list of components (pair of string and RecQuery) • … see example Norbert Neumeister

19. Recipe for Developers (III) • A builder class must be provided using the class RecBuilder: • It will create a RecUnitFactory with same name as the RecUnit • It will establish the connection between transient and persistent objects • The simplest way is to do it like this: static PKBuilder< RecBuilder<JetAlgo> > jetbuilder("JetBuilder"); RecBuilder<JetAlgo> is equivalent to RecBuilder<JetAlgo,Jet> RecBuilder<JetAlgo, PJet> in case one needs a persistent jet class • In the src directory one has to provide two additional files • classes_def.xml, • classes.h Norbert Neumeister

20. RecBuilder • The RecBuilder registers itself • One can only query for an RecCollection corresponding to a registered RecBuilder • The RecAlgorithm is instantiated at the time of the query • That’s where the names of parameters and components are checked. An exception is thrown if they don’t match. Norbert Neumeister

21. Example • Trivial example which shows how to make reconstructed objects persistent in the CARF framework. • The example is based on a simple jet object which is built from track objects. • A jet contains a container of the tracks (constituents) and a reference to the most energetic track. • I addition to the object classes (Track, Jet) there are two fake track reconstruction classes TrackAlgo1 and TrackAlgo2 inheriting from a common base class TrackAlgo and a jet reconstruction algorithm (JetAlgo) • Have a look: /afs/cern.ch/cms/Releases/ORCA/prerelease/ORCA_7_7_0_pre1/src/CARF/PersistencyExample Norbert Neumeister

22. Summary • Proposal for a new RecObject interface • Status • Prototype has been implemented (PRS + CCS) • Define a clean interface: • Review now • Use it for DC04: get experience in producing DSTs • Should be used by all high-level subsystems • For all analysis objects: Tracks, Muons, Electrons, Jets, etc. Norbert Neumeister