S EED – What it does

1. SEED – What it does • SEED transfers data from n-tuples to objects • Provides framework to • read n-tuple (also chained or “friended”), • fill objects = convert n-tuple data into objects, • call analysis after each event, • store objects in new file • read objects back from file • with only 3 classes + your objects TTree::AddFriend seed::TProcessEventABC

2. SEED – Better than ROOT? • ROOT offers TTree::MakeClass, but: • not object oriented: Can’t store data in objects automatically • just reads out n-tuple and puts data into structs • unstructured data • cryptic members • change the n-tuple, redo you code changes • transfer n-tuple into objects: by hand, otherwise: • no access to ROOT’s many predefined methods (lorentz boosts, matrix utilities, PDG interfaces etc) • jet[iJet].Phi() instead of cos(pow(JCCA_JCCAPx,2.)+…) • jet[iJet].Boost(trk[iTrk].Vect()) instead of …

3. SEED – The Seeds • SEED doesn’t know about n-tuple layout nor what classes to store the data in (“data class”) • Need translation units – the seeds: • Fill one type of object with the n-tuple data it needs • Collect seeds and use them when you need them • Turn the seed on or off, depending on the n-tuple you process • Seeds don’t care about the whole n-tuple, but only about the pieces they read out. seed::TSeedABC seed::TEventSample seed::TSingleEntryTree::Transfer

4. SEED – The Seeds • Automatically generate them: • e.g. MakeSeed(“qcd.root”, “Global”, “JCCA”, “TConeJetSeed”, “seed::TCaloJet”) will • create the seed TConeJetSeed that • transfers data from the branch JCCA (or any part of it) • to objects of type seed::TCaloJet. • The n-tuple Global • in qcd.root tells this method what the branch JCCA looks like. seed::TEventSample::MakeSeed

5. SEED – The Library • Independent of D0’s build system, comes with its own (generalized adaptation of ROOT’s makefile) to allow build of custom binaries, linked against ROOT (much faster than macros) • Many problems in the past due to ROOT problems: Excellent response time by ROOT team to SEED team’s suggestions • SEED is going to be part of FNAL’s next ROOT release (approx June): • Library will be pre-built, pre-interfaced with ROOT • Examples and build system part of ROOT: • cp $ROOTSYS/seed/tutorial .; gmake

6. SEED – What’s available, what’s not • Some data classes + seeds available Reco, for L2 triggers, L3 muon segments, muon central matching, generator level (TMCParticle + seed: a good one) – see cvs package seed0 • Take those as templates – the work needs to be done by YOU (no library can get that done for you): • Define data classes (95% of your work), write seeds (the rest). • And this is positive: focus has to be on the design of the objects, not on how to get data into the objects! • SEED will give you all the freedom you need to fill data into your objects – whatever they look like.

7. Common Objects at D0 – To Do • WARNING • My personal opinions & very crude sketches • Take them as they are: Unqualified • I won’t be able to participate in the work, so I can easily talk about how it could be done and what needs to be done…

8. Common Objects at D0 – To Do • Define common, abstract base classes for physics objects to define common interfaces, using ROOT classes where possible to save coding time • class Jet: public TLorentzVector { • Float_t WidthPhi() const; • Float_t WidthEta() const; • Float_t Width() const; • }; • will have Phi, Eta, Boost, etc from TLorentzVector

9. Common Objects at D0 – To Do • Add specializations gradually • L1Jet = Jet • L2Jet = CaloJet: Jet + EMF, N90 • CaloVtxJet: CaloJet + Vertex information • L3Jet = CaloVtxTrackJet: CaloVtxJet + references to tracks in jet cone • This approach gives the highest flexibility when dealing with multiple levels of specializations of objects just to give you an idea…

10. Common Objects at D0 – To Do • Add cross-level methods, let’s take matching / comparison • Goals: • Allow comparisons to be object specific (e.g. an L2Jet can implement its own way of comparing to an L1Jet) • Comparisons should have sensible defaults, maintained as part of the objects – while still being customizable.

11. Common Objects at D0 – To Do • class MatchMaker { • public: • // match two matchables • virtual float match(const Matchable* a, const Matchable* b) const; • }; • class Matchable { • public: • // match this with external MatchMaker • void match_mm(const Matchable* with, const MatchMaker& mm)const{ • mm.match(this, with);} • };

12. Common Objects at D0 – To Do • This generic matching interface would allow: • class Jet: public Matchable { • public: • void match(const Jet* with) const; • }; • So one can call jet1->match(jet2)using the default match offered by Jet, • but also jet1->match_mm(jet2, myMatchMaker) with a user specified matching algorithm

13. Common Objects at D0 – To Do • It obviously also allows specialized cross object comparisons • class L2Jet: public Jet { • public: • void match(const L2Jet*)const; • void match(const L1Jet*)const; • }; • So you could use base classes’ match methods or specialize your own for defined cross matches.

14. SEED – Contact • documentation, download: www-d0/nikhef • cvs packages: seed, seed_framework, seed0 • ups product: setup seedlib • version updates, problems + discussions: seedtalk mailing list (see web) – very fast response times, as distributed over US and Europe, guys with a lot of coding + SEED experience. • No active help in coding from SEED team, but full support for SEED library – at least for the next two years. • GOOD LUCK!