# Presentation: 313537

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

- 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

- seed::TProcessEventABC

- SEED – What it does

- TTree::AddFriend

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

## SEED – The Seeds

- 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::TSingleEntryTree::Transfer

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

## 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**

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

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

## 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**

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

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

## 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);}**
**};**

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

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

## 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!