Jose A. Hernando

Trigger Gaudies Trigger Gaudies

Trigger Gaudies

Reconstruction Tools & Algorithms

Inspectors

MC & Data Algorithms

Template preserved container

Jose A. Hernando

Jose A. Hernando

Reconstruction (access)Reconstruction (access) The reconstruction algorithms share:

– Access to the geometry (see geometry part)– Access to Hits

We should define an interface (base) class.

Solution:– The Reconstruction Tool/Alg should look for the data classes:

– An algorithm at the initialization of the run that creates Geometry classes (calibration)

– An algorithm that event by event create hits classes

OLRecords HitsHitMaker

event by event

geo cal

geometry geo cal

Ini of run

geo cal Hits

Jose A. Hernando

(status) RecAlg::execute() {

vector<Track*> ntracks;

for seed in tracks new track* ntrack = NULL; if (rectool.reconstruct(seed,track)) ntracks.push_back(track); clone_killing(ntracks)};

Class RecTool: public ToolAlg {

(status) reconstruct(const Track& seed, Track*& track) ;

(status) reconstruct(const (TrackState)& state, Track*& track); };

Reconstruction (Tool & Algorithm)Reconstruction (Tool & Algorithm)

The reconstruction can be partial or complete– Partial: A collection of selected tracks, – Complete: all seed tracks, or with no input

Solution– The reconstruction should be a Tool and an Alg

– The Tool and Alg will require:– – The Tool will take a seed a reconstruct a track

– The Alg will delegate in the tool to reconstruct

– Property of RecAlg: Address of the input container Check for a flagged input ot not

Tracks (3d) Tracks (VTT)VeloTTRecAlg

geo cal Hits

Track VeloTTRecTool Track

Hits geo

VeloTTRecTool VeloTTRecAlg

RecTool

RecAlg

Jose A. Hernando

InspectorsInspectors

The reconstruction algorithms are inspected:

– They accumulate data during the run Histograms, counters, timers

– These run data can be made persistent (or simply printed out)

Solution– The inspector are tools – the algorithms retrieve them and use

them.– Any inspector should have user friendly

methods. To book, fill histogram, ntuples To start, stop timers

– The inspector should contain and manage the run data

The user do not care of the data

Ini of run

IniInspectors

Histos

Ntuples

Timers

Counters

end of run

Summarize

Counters

Jose A. Hernando

Histos

Histogram InspectorHistogram Inspector

Histogram Inspector:– It server histograms between the user

and HistoSvc of Gaudi

– The user book and fill it as old Hbook Book(ID, n, x0, xf); Fill(ID,x);

– The user do not have to keep the histograms pointers in their algorithm

– The “key” of histogram can be (string) name, (int) ID

– Properties of HistoInspector Persistency HBOOT/ROOT/etc Address.

Class IHistoInspector: public ToolAlg {

(status) book(key, n, x0, xf);(status) book(key, nx, x0, xf, ny, x0, xf);(status) fill(key, x, increment = 1);(status) fill(key, x, y, increment = 1);};

(status) VeloTTRecAlg::initialize() {

histoInsp().book(“TTHits”,200,0,50);histoInsp().book(“TTXY”,50,-80,80,50,-80,80);}

(status )VeloTTRecAlg: execute {…histoInsp().fill(“velo hits”, nhits,1.);histoInsp().fill(“xy velo hits”, x, y, 1.);}

VeloTTRecAlgUse in Algorithms:

Inspector header (some user friend methods)

Jose A. Hernando

NTuples

Ntuples InspectorsNtuples Inspectors

NTuples Inspector:– It server ntuples between the user and

NTupSvc of Gaudi

– The user book and fill ntuples similar as old Hbook

Book(ID, name); Fill(ID,name,x); tup[name] = x;

– The user do not have to keep the ntuples entries pointers in their algorithm

– The ntuple will have an ID (int) and every entry an name (string)

(int) NtupleID, (string) name

– Properties of HistoInspector Persistency HBOOT/ROOT/etc Address.

Class NtupleInspector: public ToolAlg {

(status) create(id);(status) define(var_name);(status) fill(var_name, var);(double&) operator() [](varname);};

(status) VeloTTRecAlg::initialize() {

NtupleInsp().create(10);NtupleInsp().define(“TTHits”);}

(status) VeloTTRecAlg: execute {…(int) nhits = tthits.size();NtupleInsp().fill(“TTHits”, nhits);}

VeloTTRecAlgUse in Algorithms:

Inspector header (some user friend methods)

Jose A. Hernando

Timer

Timer InspectorsTimer Inspectors

Timer Inspector:– It store a histogram for user timer

– The user start and stop the timer start(name); stop(name); The elapsed time is the entry of a

1D histogram

– The information is printed or stores as histogram

– Properties of TimerInspector Persistency HBOOT/ROOT/etc Address.

Class NtupleInspector: public ToolAlg {

(status) start(name);(status) stop(name);};

(status) VeloTTRecAlg: execute {TimerInsp().start(“VeloTTRECAlg_exe”);….TimerInsp().sto(“VeloTTRecAlg_exe”);}

VeloTTRecAlgUse in Algorithms:

Inspector header (some user friend methods)

Jose A. Hernando

Counter

Counter InspectorsCounter Inspectors

Counter Inspector:– It store counters

– The user can increment a counter reset(name); increment(name, (int) val);

– The information is printed at the end of the run.

Class NtupleInspector: public ToolAlg {

(status) reset(name);(status) increment(name, (int) val=1);};

(status) L1Decision: execute {CounterInsp().increment(“passingL1”);}

VeloTTRecAlgUse in Algorithms:

Inspector header (some user friend methods)

Jose A. Hernando

MC & Data AlgorithmsMC & Data Algorithms How to check an algorithm with MC without

been intrusive?– The Data Algorithm [DAlg] should not contain any

track of MC– Who to test the code without duplication?

Solution1. A MC Algorithms that takes as input Data and

MCData As other Algorithm but now takes also MCData. It can be use as checker of the output but not during

the execution of the Dalg You add the MCAlg to the sequencer

2. A MC Algorithm inherits from the Data Algorithm The MCAlg overwrites DAlg methods, and add MC

information. Doing the check you replace DAlg by MCAlg in the

sequencer

Tracks <Track,MCPar>

Hits <Hit,MCPar>Counter

CheckRecEff

Class MCAlg : public DAlg, public algorithm {

(status) initialize();(status) execute();(status) finalize();

protected:Associator<Track,MCPar>* m_astor;}

(status) MCAlg : initialize() {DAlg::initialize();HistoInsp().book(“track_mcw”,50,0,1);}

(status) MCAlg::execute() {Create_cheating_mctracks();Set_address_to_cheated_mctracks();DAlg::execute(); // DAlg::matching();Study_efficiency();}

In the header

In the cpp

Jose A. Hernando

MC & Data Algorithms (2)MC & Data Algorithms (2) The Algorithms repeat some common task:

– Go to the DataSvc and get the data (MC)– Go to the ToolSvc and get the tool

Solution– We can write with an script (python):

Input txt file (<xml>): – DataObjs address – Tool address– properties

– It will write in the squeleton of header file1. The member pointer and access to the data

const L13dTracks& l13dtracks();2. The member pointer and access to the tools

HistoInsp& histoInsp();

– It will write the squeleton of the cpp file The “nots” of Gaudi to get the data and the tools The “nots” of Gaudi to make the alg factory.

Tracks <Track,MCPar>

Hits <Hit,MCPar>Histos

CheckRecEff

Class CheckRecEff : public algorithm {

HistoInsp& histoInsp() {return *m_Hinsp;}Const L13dTracks& l13dtracks() const{return *m_l13dtracks;}

protected:HistoInsp* m_HInsp;L13dTracks* m_l13dtracks;};

Static cont AlgFactory<…>Const IAlgFactory& …(status) CheckRecEff : initialize() {Retrieve_run();histoInsp().book(“ntracks”,50,0,50);}(status) CheckRecEff::execute() {Retrieve_event();Int ntracks = l13dtracks().size();histoInsp().fill(“ntracks”,ntracks);}(status) CheckRecEff::retrieve_event() {m_l13dtracks = SmartPtr<L13dtracks> L13dTracks(evtSvc(), m_address_l1trks);}

Jose A. Hernando

Template preserved containerTemplate preserved container How we can avoid to create new objects

and delete them per event?– This is one of the most time consuming task!

Solution:– Create our own template container

Booked_vector<Hits*> hits(50);

– The container (the pointer) should survive an event We can not use the eventSvc We can instanciate a new DataSvc in Gaudi for this

porpose. (I.e. TgDataSvc) We will acces the data from these container from

this DataSvc

– The container has a fixed dimension at creation time

This can be expanded dynamically.

– The container can be reset and return the next empty element.

– The elements should be reset(able)– The container can be smart and have keys or flags

to access selected elements.

Template <class T> class booked_vector {Booked_vector(int n);Reset();(Int) size() const {};T& next() {}(iterator)& begin() {}(iterator)& end() {}protected:Std::vector<T*> m_vector;}

(status) HltXAlg ::execute() {

(booked_vector<HltHit*>) hltHits().reset()HltHit* hit = hltHits().next(); // return firstFill_hit(hit);Int nhits = hltHits().size() ;// size now =1}

In the header

In the cpp

Jose A. Hernando

ConclusionsConclusions

The Gaudies: – It is code to help to create and use the (trigger) small algorithms– It is code to make Gaudi more user friendly– It is code to simplify our coding experience.

Gaudies:– The Reconstruction Algorithm and Tool

The Reconstruction Tool operates in one seed track The Reconstruction Algorithm operates (in a container of tracks) and uses the Tool

– The Inspectors They are tools to store and manage a run-type data They have user friendly tools

– Histos, Ntuples, Timer, Counter Inspectors

– The MC and Data Algorithm A MCAlgorithm can check its DataAlgorithm without disturbing the DataAlg. The general code of accessing data/tools and other “nots” of Gaudi can be create automatically

with an script (python)

– A template preserved container Is is a container of fixed size to be changed dynamically It can be reset(), and ask for the next() empty element The container leaves in a DataSvc of Gaudi different than the eventSvs and survives during the run

The Gaudis should be a package