Monju ïc data fountain

1. Monjuïc data fountain Monjuïc data fountain Why The Fountain L1 & HLT data classes Interfaces for L1, HLT (offline) Jose A. Hernando (coffee with Mariusz Witek) Jose A. Hernando

2. Why? • Some of the problems I have encounter working with L1/HLT code • I can not use HLT in L1: I can not pass HLT tracks to L1decision • I can use L1 in HLT: I can not use L1 tracks as seed of HLT tracking • I can not do a partial reconstruction (only with VeloTT) • I have problems with the associators as they are specific • In conclusion: • The L1 (and HLT reconstruction) have very good performances. • But its code is monolithic and rigid and has no flexibility neither modularity • Solutions: • Separate the L1/HLT in small algorithm with specific task • a small algorithm that takes “Tracks” and compute L1decision • Realize that a user (me) mostly need an interface to some of the objects • I need a clear defined methods to access the data of the classes: an Interface. • L1Track3d and HltTrack are specific tracks used in these particular reconstruction • BUT I only need a “Track” (I do not need L1,HLT) • Step forward: • I asked for a code revision, and O. Callot volunteered to chair it. Jose A. Hernando

3. Interfaces ITrack ------- Status() = 0; State() = 0; Hits() = 0; Quality() = 0; Hits Tracks Vertex Particle • Interfaces: • Interfaces are the minimum public methods of a given type of classes. • I.e: L1Track3d or HltTrack are “Tracks” • Two levels of the code:internal and specific. • Internal : only uses interfaces • Specific: uses concrete class • The internal code is general and reusable. • I (user) only need “Track” and not “HltLongTrack” • The specific code handles specific needs. • I (developer) need HltLongTrack to store parameters. • The interfaces establish the input/output of your code (a protocol): • The user have security that interfaces are valid for many classes. • The developer has the freedom to implement its own specific classes • Interfaces harmlessly “modify” any existing class After Implementing the interfaces in the Event Model, ALL the current LHCb code still will work! Class HltTrack : public ITrack {}; Class L1Track3d: public ITrack {}; L13dTrack ITrack HltTrack user developer Jose A. Hernando

4. The key elements • Base or Interfaces? • Interfaces are lighter than bases. • Interfaces are just a simple definition (they are virtual) • Bases are concrete objects (they have data members) • Interfaces are easy to plug and remove: • Implementing interfaces do not alter your concrete class. The code is still working!. • Removing Base classes, will cut your concrete class. • Interfaces give your more freedom. • Maybe you do not store objects, just take it from others • Base classes are not bad either • If we often use them, it will be better to keep the objects • O.Callot moved with HltTrack in the right direction (other tracks (HLT)LongTrack). • The basic data elements of the trigger: • In the rest of the talk they are whatever we agree on them (Interfaces or Bases) For an proposal of Interfaces (see “Monjuïc” fountain talk). Hits Tracks Vertexes Particles Decision Jose A. Hernando

5. the Montjuïc data fountain Hits Matching matching tracks PID (fitted) tracks fitting Vertexes fitting geometry Particles • Any HEP reconstruction code will produce a “Montjuic” fountain • The trigger code is in fact a reconstruction & analysis code • These fountain elements are abstract general classes • The drawing of the fountain implies that an “abstract” concept of these objects exist • Defining these objects • We find the intrinsic methods of these objects. • What is track?, a vertex? (do not think in LHCb) Montjuic is a mountain in Barcelona with a beautiful and always changing fall and fountain Jose A. Hernando

6. The L1 Event Model • L1Track2/3d • 2 flavors • 2D: (r,z), (phi,z) • 3D: (x,y,z) access to 2D tracks • (r,z) (x,z) (y,z) • Access to the states • position and slopes (begin & end) VELO • Covariance matrix (begin & end) VELO • 1/P (from Velo-TT) • Quality of track: chiSq • Access to L1Clusters • 2d: L1Clusters • 3d: R & Phi L1Clusters • L1Cluster • Access to measurement • Central strip • size • ID (int) of sensor L1Cluster L1Track2d L1Vertex2d L1Track3d L1Vertex3d • L1Vertex2/3d • 2 flavors • 2D: access to 2D tracks • 3D: access to 3D tracks • Access to the position and cov. • point • covariance Jose A. Hernando

7. The HLT Data Event Model • HltTtrack • 3 internal flavors • Converstion to HLTtracks • Type: Velo, VTT, Long • Flags: status • Access to the states and (pid!) • Begin and end slopes at: • VELO, after Magnet • Pt • Covariance & errors • particleID, velo charge() • Access to VeloClusters/IT/OTClusters • Pointer to Ancestor track • HltHit (IT,OT) • Type • Measurement (driftTime), • Plane code & z() • Access to I/OTCluster • Flags: IsUsed(), nextIsClose() HltHit (IT,OT) HltTrack HltVertex VeloTrack VTTTrack LongTrack • HLTVertex • [Access to position and cov?] • Position & covariance • Access to HltTracks Jose A. Hernando

8. Proposal: Trigger Data Event Model L1Cluster L1Track3d L1Vertex3d ITgHit ITgTrack ITgVertex HltTrack HltHit HltVertex Particle.h • Proposal of Interfaces • I will propose a (draft) of interfaces for these classes: • The interfaces should be minimal but complete • Mostly accessing methods. • They are easy to extend and difficult to cut • The actual L1/HLT should implement the interface • This required to change the header file of L1/HLT classes • But the code will run the same as now. Jose A. Hernando

9. The Trigger Interface Data Event Model • ITgTtracks • (key) Type: (Velo2d, Velo, VTT, Long) • Tracks states: • (point) Position(), • (vector) direction() • p(), pt(), charge(), q/p() • (state) Access to the states (by key) • At VELO, (begin,end), At TT, • After Magner, MuonChamber • (vector<>) access to: • ITgHits (and quality) • (double) Quality (chiSq) • (bool) Status(key) • ITgHit • Access to measurements • (double) measurement() • (double) resolution() • Type & ID • (key: r,phi,x,u,v,OT) ITgHit ITgTrack ITgVertex ITgParticle • ITgVertex • (point) position() • (double) Quality • (Vector<>) access to: • ITgTracks (and quality) • ITgParticle: • (key) Type: (track, vertex, neutral) • (PID) Access to PiD and probability • Best • Access to State (several?) • Access to: ITgTrack, ITgVertex LHCb: Particle.h & Vertex.h (phys) are excellent classes Jose A. Hernando

10. Proposal: ITgPlane ITgPlane • The geometry elements are access by: PlaneID • They have 2 main methods: • position() • is_inside() • The rest of tracking components can be consider as a composite • We will have a collection of very small geometry objects but we will work with the interface. Class ITgPlane { // ID of the plane (key) type() const; (PlaneID) id() const; // geometry (point) position() const; (bool) is_inside(const point&, double tol) const; (status) z() const; [(string) id(key) const = 0;] }; ClassXSIDice : public ITgPlane{ (bool) is_inside(const point&, double tol) const; }; Class ITgPlaneComposite : public ITgPlane { (vector_of_planes)& planes() const; }; [operation:] order_planes_by_z(); bool XSIDice::is_inside(const point& p, double t) const point residual = p-m_position; if (fabs(residual.x()) > X/2+tol) return false; …. } Jose A. Hernando

11. Proposal: ITgHit ITgHit Class ITgHit { /// type of hit key: R,Phi,U,V,X, (key) type() const; /// status of the hit key: locked (bool) status(key) [set_status(key, bool);] /// measurement [u,strip] (double) measurement() const; (double) resolution() const; /// deal with the geometry [dices] (ITgPlane&) plane() const; [should bypass the geometry?] [(int) id(key)] /// about projection [OO] [(double) projection(const point&) const;] [(double) projection_error(const matrix&) const;] } /// operations order_by_z() order_by_residual(const point& pos) • They have 2 main methods: • measurement() • resolution() • Facilitate the access to geometry: • Associated with PlaneID • With projection methods we make easy the tracking part. • Projection: project and state (point) to the measurement “axis” • We will get a small collection of classes but we will use the interface • The status(key) trick allows to control the status of the class and and flagged • We can have many keys double USiHit::projection(const point& p) { u_proj = p.x()*m_cos_stereo+p.y()*m_sin_stereo; return u_proj; } Jose A. Hernando

12. Proposal: ITgTrack ITgTrack Class TrackState { (point) position() const; (vector) direction() const; (double) qovp() const; (matrix) covariance() cosnt; (double) p() const; (double) pt() const; (double) charge() const; }: Class ITgTrack { /// type key: V2d,Velo, VTT, Long (key) type() const; /// status of the track; key: V2d,V2dSel,Velo,etc (bool) status(key) const; [set_status(key, bool);] /// returns the state of the track /// key: VeloBegin,VeloEnd,TT,etc (const TrackState&) state(key) const; [set_state(key, const TrackState&); ] /// Returns the quality (chisq) of the track (double) quality() const; /// Returns the hits (vector_of_hits)& hits(key); // more quality information? [(double) quality(key);] [(double) quality(const ITgHit*&) ;] }; • A Track: • Is a collection of states • Made with hits. • With a quality of agreement with the hypothesis that make the track • We can access the states by key. • The states give “physical” quantities • Not all fields filled (cov) • The status(key) trick allows us to control the track Jose A. Hernando

13. Proposal: ITgVertex ITgVertex Class ITgVertex { /// type key: V2,V3,primary (key) type() const; /// status of the track; key: V2d,V2dSel,Velo,etc (bool) status(key) const; [set_status(key, bool);] /// info (const point&) position() const; (const matrix&) covariance() const /// Returns the quality of vertex (double) quality() const; /// Returns the tracks (vector_of_tracks)& tracks(key); /// more quality information? // quality = IP, IPS [(double) quality(const ITgTrack*&) ;] }; • A Vertex: • Returns a position • Made with tracks. • With a quality of agreement with the hypothesis that make the vertex • Vertex similar to Track • Replace hit by track • Only one state. • Note that the quality of a track to belong to the vertex is IP or IPS Vertex.h: is an interactor vertex (made with particles) Jose A. Hernando

14. Proposal: ITgParticle ITgParticle • A particle is: • A (collection) TrackState • (position, direction, p) • Associate with a PID • (mu, pi, K, etc) • A TrackState can be created from • a Track (majority) • a Vertex of Tracks • Convening several particles, etc • The properties of the particle are reached via its PID. Class ITgParticle { /// type key: type of ID (rich, muon, tracking) (key) type() const; /// status of the track; key: V2d,V2dSel,Velo,etc (bool) status(key) const; [set_status(key, bool);] /// Returns PID of the particle (PID) pid() const; (double) probability() const; [(double) m() const;] (const TrackState&) state(key) const; (vector_of_tracks)& tracks(key) const; /// Access ITgTrack& track() const; ITgVertex& vertex() const; [vector_of_particles particles() const;] }; But Particle.h [& Vertex.h –phys-] is very good class!! (it has one state) We should use Particle.h! This proposal is more compact & extendable Jose A. Hernando

15. The Montjuïc data fountain • Conclusions: • HEP reconstruction follows a “Montjuïx” fountain of data • The data classes admit an Interface. • Independent of trigger, reconstruction (even LHCb)!! • A good fraction of trigger, reconstruction, and analysis code could be written in these interfaces • It is reusable and valid on other domains and applications • Your reconstruction code maybe requires a particular concrete class that derives from the interface, no problem!. • You still has the freedom of defining your own classes. • Implementing the interfaces in LHCb code if straight forward and the current algorithms will still run! • Proposal: • We should define interfaces for: Hit, Track, Vertex and Particle • They should be minimal and with const getting access methods • We should make the Event Data Model classes to fulfill the interfaces: few days of work! • As many as possible algorithms should use only interfaces. • In the trigger decision algorithms: we then can use offline or trigger reconstruction without changing the code. • We can easily switch between (or replace) reconstruction algorithms Jose A. Hernando

16. the Montjuïc data fountain Matching Hits tracks matching (fitted) tracks fitting PID fitting Vertexes geometry Particles Jose A. Hernando