+ All Categories
Home > Documents > Plans for integration in HLT

Plans for integration in HLT

Date post: 02-Feb-2016
Category:
Upload: zoey
View: 62 times
Download: 0 times
Share this document with a friend
Description:
Plans for integration in HLT. M. Biglietti - Univ. “Federico II” – INFN Napoli G. Cataldi - INFN Lecce. Athena algorithms with different features/goals. Moore Packages. Moore is a container. run-time plug in differents algos in order to build the reconstruction chain. MooLVL2Algs. - PowerPoint PPT Presentation
Popular Tags:
14
Plans for integration in HLT M. Biglietti - Univ. “Federico II” – INFN Napoli G. Cataldi - INFN Lecce
Transcript
Page 1: Plans for   integration in HLT

Plans for integration in HLT

M. Biglietti - Univ. “Federico II” – INFN Napoli

G. Cataldi - INFN Lecce

Page 2: Plans for   integration in HLT

Moore PackagesMoore is a containerMoore is a container

MooAlgs

MooEvent

MooAlgs_n

Events for reconstruction

Athena algorithms with different features/goals

MooLVL2Algs

run-time plug in differents algos in order to build the reconstruction chain.

MooStatistics

MooAlgs contains the standard

sequence of Algorithms:

MooMakePhiSegments

MooMakeRZSegments

MooMakeRoads

MooMakeTracks MooLVL2Algs contain a possible

seeding approach

MooMakePhiSegmentLVL2

MooMakeRZSegmentLVL2

Page 3: Plans for   integration in HLT

Moore Algorithms MooAlgs

“Seeding” in the first two algoritmhs

Last two for pattern recognition and track fitting

MooMakePhiSegments

RPC/TGC digits

PhiSegments

MooMakeRZSegmentsMDT digits

MooMakeRoads CrudeRZSegments

MooMakeiPatTracks MooRoads

MooiPatTracks

MooMakeNtuples

NtuplesNtuples

MooAlgsMooAlgs

MooStatisticsMooStatistics

Page 4: Plans for   integration in HLT

First need: If we want to have the seeded Moore in the HLT environment we

need: MooAlgs

in HLT

MooAlgs in HLT assuming that the sequence is always

valid, and accessing to all the event, i.e Standard Moore running.

No use of TriggerElements.

First step:First step:

Page 5: Plans for   integration in HLT

MooHLTAlgo- First Approachclass MooHLTAlg: public HLTAlgo

{

public:

MooTopAlg (const std::string& name, ISvcLocator* pSvcLocator);

~MooTopAlg();

StatusCode initialize();

StatusCode execute();

StatusCode finalize();

StatusCode execHLTAlgorithm(TriggerElement*)

private:

MooMakePhiSegments * m_MooMakePhiSegments;

MooMaCrudeRZSegments * m_MooMakeCrudeRZSegments;

MooMakeRoads * m_MooMakeRoad;

MooMakeTracks * m_MooMakeTracks;

};

Inheriths from the Steerining algo

Pointers to the Moore

algos

Page 6: Plans for   integration in HLT

MooHLTAlg – First Approach II

bool MooHLTAlg::execHLTAlgorithm(TriggerElement* TEout){

executeAlgs(&m_MooMakePhiSegmetsAlgs); executeAlgs(&m_MooMakeCrudeRZSegmentsAlgs); executeAlgs(&m_MooMakeRoadsAlgs); executeAlgs(&m_MooMakeiPatTracksAlgs); executeAlgs(&m_MooSvcAlgs);

//Let's suppose Moore always validates the sequence... log << MSG::INFO << "Trigger Element is active : " << TEout->label() << endreq; TEout->SetActive(true);

return true;

Moore algosare executed

The trigger element is active

Page 7: Plans for   integration in HLT

Result It technically works but we were not able to find a working PESA

release considering the facts that: With 5.2.0/4.0.6 execHLTAlgorithm() is initialized, but not

executed Taking into account that muons are BROKEN from 4.3.0 up to

5.1.0, and that 5.2.0 is just usable (i.e. it runs, but there are several bugs)

What release can we use under:

/afs/cern.ch/atlas/project/trigger/pesa-sw/release

offline/Trigger/TrigAlgorithms/TrigMOORE

The HLT interface will be released soon in cvs

Page 8: Plans for   integration in HLT

From last HLT - Muon meetingsee M.G. minutes. 20/2/03

In the muon vertical slice, the muon ROI is passed from the LVL1 to the LVL2 steering that feeds the ROI into muFAst. The result of muFast is passed as part of the LVL2 result to the EF.

Currently, no provisions exist to translate the LVL2 result of muFAst into a 32-bit word format that can be passed on to the EF via the LVL2-to-EF bytestream.

the EF will receive directly the LVL1 ROI from the LVL1-to-LVL2 bytestream. MOORE can then use directly the eta-phi information of the muROI to request the RPC and MDT RDO collections that are intersected by an eta-phi road around the ROI.

For this MOORE will make use of the RegionSelector that will provide DetectorElement (both RPCs and MDTs) in which are contained the digits.

The LVL2 steering passes the LVL1 muROI to an HLT algo by means of a TriggerElement object that contains a navigable link (uses relationship) to an object of type RecMuonRoI. This class will live in Trigger/TrigT1/TrigT1Interfaces and will contain the eta and phi position of the RoI, the threshold the ROI passed, in GeV an offline identifier that identifies the PAD to which the ROI belongs.

The implementation of RecMuonRoI and code to fill it is supposed to be provided in the next couple of weeks.

Page 9: Plans for   integration in HLT

How to proceed ?

Our understanding is that in one two weeks we can access the Offline Identifiers of RPC selected by LVL1 Trigger.

Keeping in mind that in future we will use LVL2 output, can we access RoI in terms of Offline Identifiers from the LVL1 ? If yes, how?

A possible strategy is presented in the following slides...

Page 10: Plans for   integration in HLT

Strategy – Further Modularization of Moore Isolation of objects from the Athena Algorithms (directly linked with the offilne

framework) In this way is possible to use the same code also for the online framework EXAMPLE: MooMakePhiSegments

1. Gets RPC (and TGC) DigitCollections from TDS 2. Loop over digits inside collections3. Puts digits inside an histogram to select active phi-roads4. Creates a PhiSegmentContainer:: public DataVector<PhiSegment>5. Puts PhiSegmentContainer into TDS

New MooMakePhiSegments 1. Gives the RpcDigitCollections to a MooPhiSegmentsFinder

MooPhiSegmentsFinder puts digits into an histogram to select active phi-roads and creates a PhiSegmentsContainer::public DataVector<PhiSegment>

Gets PhiSegmentContainer from MooPhiSegmentFinder 5.

In this way the HLTAlgo can use directly MooPhiSegmentFinder The same happens with MooMakeCrudeRZSegments…

Page 11: Plans for   integration in HLT

MooAlgs

MooMakeRoadsMooMakeTracks…

MooLVL2Algs

New Moore Structure

MooStatistics

MooCode

PhiSegmentsFinderMooHistoRZSegmentMaker…

MooEvent

TrigMoore

MooHLTAlg

Page 12: Plans for   integration in HLT

MooEvent

• RZSegment is a general class, specialized for CSCs and MDTs•RZSegments have a pointer to the vector of hits

Page 13: Plans for   integration in HLT

TrigMoore package

HLT interface – MooHLTAlgo Inherits from HLTAlgo Has pointers to Moore algos Will use () of the LVL1 muon RoI to infer a search range

for PhiSegments and RZSegments. Soon it will use offline IDs selected via the RegionSelector

Gets the DetectorElements from the offline Ids, or from your search.

Gets the RPC and MDT RODs from the DetectorElements Builds the Phi and RZ Segment and than executes the Moore

Algorithms for the PR and the track fitting Sets the output TriggerElement into TDS according to the

reconstruction result

Page 14: Plans for   integration in HLT

THE ENDTHE ENDMoore documentation in:

http://people.na.infn.it/~bigliett/moore/MooreDoc/MooreDoc/


Recommended