Plans for integration in HLT

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 MooAlgs • MooAlgs contains the standard sequence of Algorithms: MooMakePhiSegments MooMakeRZSegments MooMakeRoads MooMakeTracks • MooLVL2Algs contain a possible seeding approach MooMakePhiSegmentLVL2 MooMakeRZSegmentLVL2 MooStatistics MooAlgs_n MooEvent Events for reconstruction

Moore Algorithms TDS MooAlgs RPC/TGC digits • MooAlgs • “Seeding” in the first two algoritmhs • Last two for pattern recognition and track fitting MooMakePhiSegments PhiSegments MooMakeRZSegments MDT digits MooMakeRoads CrudeRZSegments MooRoads MooMakeiPatTracks MooiPatTracks MooStatistics MooMakeNtuples Ntuples

First need: • If we want to have the seeded Moore in the HLT environment we need: • MooAlgs in HLT First step: • 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.

MooHLTAlgo- First Approach class 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

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 algos are executed The trigger element is active

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 The HLT interface will be released soon in cvs offline/Trigger/TrigAlgorithms/TrigMOORE

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.

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

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 • Gets RPC (and TGC) DigitCollections from TDS • Loop over digits inside collections • Puts digits inside an histogram to select active phi-roads • Creates a PhiSegmentContainer:: public DataVector<PhiSegment> • 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…

MooAlgs MooMakeRoads MooMakeTracks … MooLVL2Algs MooStatistics MooCode PhiSegmentsFinder MooHisto RZSegmentMaker … MooEvent TrigMoore MooHLTAlg New Moore Structure TriggerAlgorithms Moore

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

TrigMoore package • HLT interface – MooHLTAlgo • Inherits from HLTAlgo • Has pointers to Moore algos • Will use(h, f)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

THE END Moore documentation in: http://people.na.infn.it/~bigliett/moore/MooreDoc/MooreDoc/

Plans for integration in HLT