Status report on the definition of persistent tracker b/t...

13/12/2005 [email protected] 1

Status report on the definition of persistent tracker b/t objects

Marcel Vos, INFN Pisa

Thanks to those who took the trouble to provide feedback: W. Adam, V. Ciulli, S. Cucciarelli, S. Gennai, M. Konecki, D. Kotlinski, P. van Laer, F. Moortgat, F. Palla, A. Rizzi, F.P. Schilling, T. Todorov,

I. Tomalin, C. Weiser

Special thanks to T. Boccali and L. Lista


IntroductionNew framework is advancing: Digis, clusters and RecHits have been defined.

Luca Lista (analysis tools) and Tommaso Boccali (reconstruction) coordinate persistent storage of reconstructed objects(*):-RECO (formerly known as DST, ~500 kB/event, available to few in tier 1 + selected tier 2)

-AOD (basis of large majority of physics analyses, ~50 kB/event)

PRS groups are expected to provide requirements / feedback through contact persons. Today’s discussion should lead to the tracker b-τ wish list

(*) not strictly limited to reconstructed objecs, contains MC truth objects


IntroductionPersistify reconstructed objects for two purposes:• to freeze the reconstruction after a significant amount of CPU time has been spent.

•Re-reconstruction of higher-level objects can carry on from here. Example: rerun vertex finder without having to redo tracking.

•Especially important for tracker b/τ as track reconstruction consumes a very large fraction of CPU budget.

•finalize reconstruction, enter analysis•visualize results (fill histograms).


Introduction

From DST kick-off document:

EDM requirementsAny DST structure must support the three basic usage patterns that are at the foundation of our EDM.1.“Bare ROOT” Mode – Meant to enable easy inspection of event content, as well as simple calculations based on information stored in High Level Objects (Di-Jet mass, W transverse mass…).2.“Lite” Mode - Here we talk about analyzing the data interactively by loading a small number of ROOT libraries (e.g. DataFormats…) and writing code that can be used within the framework (e.g. Jet clustering, b-tagging…) as well as interactively. 3.“Full FW” Mode – no explanation is required here. This is the context where full provenance tracking is available, DB accesses and Geometry usage are needed, and so on.


Introduction<-- Cut-out of ExRootAnalysis TRootTrack class: purely intended for plotting of reconstruction results

Data members of PRecTrack onORCA DST


Introduction

Both RECO and AOD are ROOT TTree, each branch corresponds to a collection of reconstructed objects

The AOD is expected to be created by deleting branches in the RECO TTree. The AOD is therefore a sub-set of RECO with the exact identical format.

From DST kick-off document:Associative containers Vs. composite classesWe should store associated information to more basic objects in separate branches rather than create new object types. For instance, instead of having a collection of object of type JetWithTracks, we could have a collection of Jets in a branch, and a collection of vectors of tracks in a branch, with a one-to-one association to the jet objects. Or, instead of a collection of BTaggedJet objects we could have a branch with b-tagging info objects associated to jets. Another example, instead of having a collection of IsolatedMuons, we could have an auxiliary collection of MuonIsolation variables in a separate branch associated to muons


Introduction

Prototypes already exist for many objects, among which track and vertex:

http://cmsdoc.cern.ch/swdev/viewcvs/viewcvs.cgi/CMSSW/?cvsroot=CMSSW

In the next slides, I go through the requirements accumulated so far. Requirements that I propose to include in the b-tau specifications are written in red.


Simulated tracks/vertices

Unanimous response from everyone in b-τ that answered request for feedback:

Analysis requires association of reconstructed tracks/vertices with simulated tracks/vertices fromGEANT.•(i.e. something similar to what was known in ORCA as TkSimTracks and TkSimVertex)

•Examples: determination of efficiency and fake rate of track collection, optimization track quality cuts for vertexing or tagging, verification of muon/electron ID

•Should we assume navigation to full OSCAR output (in some tier1) to be practically impossible for nearly all users? (question to sofware)

•Not yet part of prototype, but consensus Tommaso/Luca that this is needed


Simulated tracks/vertices

Full GEANT information is very heavy: which subset of tracks do we want to store? (afterpT and η cuts)

a) signal only

b) + in time pile-up

c) all

• For each track, what do we want to store?1) momentum + vertex + link to parent (in HepMC)

2) the above + SimHits pertaining to tracks

3) the above + all SimHits

• Do we want the association to be stored on RECO (depends on CPU time, non-intrusiveness with respect to reconstructed tracks and answer to the above) yes/no?

• in RECO only, or keep in AOD? (depends on event size and thus on the answers to allother questions)

• What is the relation between RecTrack and SimTrack (and RecVertex and SimVertex) classes? Inherit from a common Track containing track parameters + vertex / just two classes owning the same objects / something entirely different….


HitsDigis

Clusters

RecHits

Vitaliano and Chiara committed the RecHit code last week

#ifndef TrackingRecHit_H#define TrackingRecHit_H#include "Geometry/CommonDetAlgo/interface/AlgebraicObjects.h"#include "Geometry/Surface/interface/Plane.h"#include "Geometry/CommonDetUnit/interface/GeomDet.h"class TrackingRecHit { public: virtual ~TrackingRecHit() {} virtual TrackingRecHit * clone() const = 0; virtual AlgebraicVector parameters() const = 0;virtual AlgebraicSymMatrix parametersError() const = 0;virtual AlgebraicMatrix projectionMatrix() const = 0; virtual int dimension() const = 0; /// Access to component RecHits (if any)virtual std::vector<const TrackingRecHit*> recHits() const = 0; /// Non-const access to component RecHits (if any) virtual std::vector<TrackingRecHit*> recHits() = 0; /// Access to the GeomDet (essentially the Surface, with alignment interface) virtual const GeomDet& det() const = 0; virtual DetId geographicalId() const = 0; }; #endif


Hits

Should there be a global RecHit collection in the event? No one has explicitly requested this to be available on RECO.

Track reconstruction recalculates RecHit position and errors. UsedRecHits are stored on RECO and Persistent tracks on RECO containlinks to their UsedRecHits.

UsedRecHit branch not present in AOD (is it possible to store a few 1000 RecHits in 50 kB?). Link in Track becomes NULL in some elegant way.

Request on top of what is implemented: calibrated cluster charge


Tracks

It should be possible to refit the track from RECO information (requires UsedRecHits to be present)

It should be possible to rerun higher-level algorithms (vertexing, b-tagging, τ-tagging) on persistent track collection. On RECO or even from the AOD?

In the framework or also in “CMSSW-LITE”.

trivial solution for RECO is to recreate transient tracks by refitting (not very popular due to waste of CPU time, not possible for AOD)


TracksInformation on UsedRecHits:Number of (lost) hits + pattern (pack int with bit for each detector layer)

χ2 of RecHit in track fit (at least for innermost layers)

This is redundant with links to UsedRecHit on RECO, but needed on AOD

Track parameters and errors:at perigee on RECO and AOD: needed for any analysis, should take 0 CPU time

at innermost point (at least on RECO, at least for tracks that do not actually come from the interaction point)

at outermost point (RECO and AOD? for connection to calo clusters)

Create this information even for globally fitted tracks?


TracksInformation from track fit:χ2

NDF

Vertex:Reference to vertex


Example of new RECO: Trackclass Track {

public:Track() { }Track( float chi2, unsigned short ndof,

int found, int invalid, int lost,const HelixParameters & );

unsigned short foundHits() const { return found_; }

unsigned short lostHits() const { return lost_; }

unsigned short invalidHits() const { return invalid_; }

double chi2() const { return chi2_; }

unsigned short ndof() const { return ndof_; }

double normalizedChi2() const { return chi2_ / ndof_; }

const HelixParameters & helix() const { return helix_; }

int charge() const { return helix_.charge(); }

double pt() const { return helix_.pt(); }

double doca() const { return helix_.d0(); }

Vector momentum() const { return helix_.momentum(); }

Point poca() const { return helix_.poca(); }

dst::Error<6> covariance() const { return helix_.posMomError(); }

unsigned short found() const { return found_; }

unsigned short lost() const { return lost_; }

unsigned short invalid() const { return invalid_; }

double p() const { return momentum().mag(); }

double px() const { return momentum().x(); }

double py() const { return momentum().y(); }

double pz() const{ return momentum().z(); }

double phi() const{ return momentum().phi(); }

double eta() const{ return momentum().eta(); }

double theta() const { return momentum().theta(); }

double x() const { return poca().x(); }double y() const { return poca().y(); }double z() const { return poca().z(); }

private:Double32_t chi2_;unsigned short ndof_;unsigned short found_;unsigned short lost_;unsigned short invalid_;HelixParameters helix_;

};

Attributes:available with bare-root

Methods:available with root +library andframeworkmode

HelixParameters contain both 5-parametersand covariance. Should better be split explicitly…

Luca Lista


Modular event content• Different data layers can be configured• The required layers of detail can be used for

different applications

t t t t t tTrack … Kinematics(helix parameters)

T T T T TTrackExtra T … Track extrapolation,references to RecHits

h h h h hRecHit h h h h h h h h h … RecHits

Luca Lista


Interfacing to reconstruction• RECO Track and TrackExtra alone won’t allow

complex operations:– Extrapolation, intersection with detectors, refit, etc.

• Such operation will be done with help of external classes

• Helper classes will be transient only, and can have all the required complexity– May access to Geometry, Alignments, B-Field, if

needed• Should keep in mind that complex helper class

structure can reduce the interactive usabilityLuca Lista


Tracks

In the future, we will have many different track fitters: Gaussian sum, DAF, pixel-only.

How many different types of track objects do we want on RECO? Currently, the answer in CMSSW is: 2 (track and muon).

What are the relations between the various types of tracks? Currently, the answer is: they use the same object as data member (HelixParameter).

ORCA inheritance tree for tracks: are we willing to give this up?


Vertex

Required data members of vertex object:

Double precision vertex position and covariance matrix

Simple precision weight of track in vertex fit, χ2, NDF

Reference to tracks associated to vertex

Reference to beam spot estimate


Vertex

ROOT interactive analysis should allow computation of:Distance between track and vertex

Compatibility vertex to beam spot

Association to MC vertex

This functionality has to present in the persistent vertex object

Framework based analysis should allow computation of:Vertex-constrained track parameters

Covariance matrix of each track to vertex position

Covariance matrix of each track to each other track

This functionality could live inside a transient object that can be created from the persistent vertex


Persistent references: Vertexclass Vertex {

public:

typedefedm::Ref<std::vector<dst::Track> >

TrackRef;typedefedm::RefVector<std::vector<dst::Track> >

TrackRefs;typedef TrackRefs::iteratortracks_iterator;

Vertex() { }Vertex( double chi2, unsigned short ndof,

double x, double y, double z, const Error & err, size_t size );

void add( const TrackRef & r ) { tracks_.push_back( r ); }

tracks_iterator tracksBegin() const { return tracks_.begin(); }

tracks_iterator tracksEnd() const { return tracks_.end(); }

size_t tracksSize() const { return tracks_.size(); }

double chi2() const { return chi2_; }

unsigned short ndof() const { return ndof_; }

double normalizedChi2() const { return chi2_ / ndof_; }

const Point & position() const { return position_; }

const Error & error() const { return error_; }

double x() const { return position_.get<0>(); }

double y() const { return position_.get<1>(); }

double z() const { return position_.get<2>(); }

private:Double32_t chi2_;unsigned short ndof_;Point position_;Error error_;

TrackRefs tracks_;

};

edm::Ref provides persistent referenceto objects stored in a container


b/τ tagging

A common input object for both groups that associates tracks to jets to be created by an EDProducer that sits in a lower-level subsystem: JetWithTracks

Reference to jet

Reference to tracks

A base output object common to all algorithmsReference to JetWithTracks

Reference to Primary Vertex

Concrete output objects implemented by algorithms


b/τ taggingChristian Weiser and Andrea Rizzi were kind enough to prepare a first

draft of the b-tagging input and output base classes.

??? Why are all references to vectors of tracks and vectors of jets???

Needs to be understood


b/τ tagging

Compare our proposal to what’s written in the DST kick-off document on Associative containers Vs. composite classesWe should store associated information to more basic objects in separate branches rather than create new object types. For instance, instead of having a collection of object of type JetWithTracks, we could have a collection of Jets in a branch, and a collection of vectors of tracks in a branch, with a one-to-one association to the jet objects. Or, instead of a collection of BTaggedJet objects we could have a branch with b-tagging info objects associated to jets. Another example, instead of having a collection of IsolatedMuons, we could have an auxiliary collection of MuonIsolation variables in a separate branch associated to muons

My feeling: whether this is a conflict or not, depends on how we implement the association between branches. If the btag-info object contains a reference to the jet, the two proposals are equivalent. If, however, the association is supposed to be implicit (through the index in the branch), both proposals are hard to unify.


Regional reconstruction

Regional reconstruction is a crucial functionality forthe tracker b/τ group: all HLT tracking, secondary vertex reconstruction inside b-jets.

It is also a declared priority for the new framework, but so far noworking solution.

Runs into the known problems (how to pass region to algorithms)


TechnologyTo successfully implement the tracker b/t persistent objects we need:Polymorfism (unified interface of all types of RecHits, Tracks, b-tagging)

Powerful set of tools: vectors, matrices…


Summary

Last week’s discussion identified some important requirements. Proper treatment of MC info already being addressed.

Based on today’s discussion, write and circulate thespecifications: the exhaustive list of requirements (M.V., this week)

Collect feedback on what’s possible from Tommaso/Luca and software people

Put names against several items: volunteers to write the code in close collaboration with Analysis tools and reconstruction groups are welcome.

Aim for first iteration of key objects in place by tracker software workshop (16th January)

Date post:	27-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Status report on the definition of persistent tracker b/t...

Documents