Object Oriented simulation of the Level 1 Trigger system of a CMS muon chamber

CHEP 2000Abstract B 029Claudio Grandi INFN-Bologna

Object Oriented simulation of the Level 1 Trigger system of a

CMS muon chamber

Claudio Grandi

INFN-Bologna


Introduction

• CMS Level 1 Trigger is implemented using custom designed hardware

• Why is L1 Trigger simulation important:– test the hardware design– base to develop the High Level Trigger software– define data analysis strategies– (online monitoring of the hardware performances)

• L1 Trigger simulation code has to be integrated with the CMS simulation and reconstruction programs!


CMS detector at LHC


ORCA and CARF

• Object Reconstruction for CMS Analysis» see talk by D. Stickland

– detector digitization – detector reconstruction– Level 1 trigger simulation– High Level Triggers software (HLT)– physics object reconstruction– analysis tools

• CMS Analysis and Reconstruction Framework» see talk by V.Innocente

– persistent storage of data– reconstruction and analysis framework


SignalZebra fileswith HITS

HEPEVTntuples

CMSIM(GEANT3)

MC

P

rod

.

Pile-up

ORCADigitization

(merge signaland pile-up)

ObjectivityDatabase

OR

CA

Pro

d.

ORCAooHit

FormatterObjectivityDatabase

Catalog import

Simulation for HLT studies

Level 1 Triggersimulation

HLT Algorithms Reconstructed

ObjectsHLT G

rp

Data

bases

ObjectivityDatabase

Catalog import

ObjectivityDatabaseObjectivityDatabaseytivitcejbOytivitcejbOesabataDesabataD

Mirro

red

Db

’s(U

S,R

ussia

,Italy

...)


L1 Trigger of a muon chamber

The TRACO builds tracks in a chambercorrelating segments found in the R-view quadruplets

The Trigger Server selects the 2 best segments, suppress ghosts and passes the tracks to the Regional Trigger

The BTI finds segments in aquadruplet and assigns thebunch crossing using a mean-timer technique


L1 -trigger packages in ORCAInterface to end userSystem setup

ConfigurationGeometryetc...

Trigger componentssimulation


Class diagramObjects seen by the user

Activate themselves when thetrigger output is asked for

Chambers and trigger units are in1-1 correspondence


Action on demand

• Modules register themselves at creation time and are invoked when required (implicit invocation architecture)

• Use the Dispatcher-Observer pattern– System setup:

L1MuDTTrigSetup is a LazyObserver<Run*>– Event processing:

trigger components are LazyObserver<Event*>

• Optimization of program flow.• User code very simple!


Example of user code// Processing an event...

L1MuDTTrigSetup* setup =

Singleton<L1MuDTTrigSetup>::instance();

L1MuDTTrig* dttrig = setup->DTTrig();

//define chamber (iwh,ist,ise) and BX (is)

int iwh=…;int ist=…;int ise=…;int is=…;

L1MuDTChambPhSegm* first =

dttrig->chPhiSegm1(iwh,ist,ise,is);

L1MuDTChambPhSegm* second =

dttrig->chPhiSegm2(iwh,ist,ise,is);

L1MuDTChambThSegm* theta =

dttrig->chThetaSegm(iwh,ist,ise,is);


BTI simulation

• More than 450 000 BTI chips in CMS, on average 35 are not empty in each event– do not instantiate BTI chips at setup time– instantiate BTI chips event by event if not empty

• The BTI trigger cards (1 per chamber) keep:– map of active BTI chips (L1MuDTBtiChip)– vector of output BTI triggers (L1MuDTBtiTrig)

• Reproduce the BTI behaviour as time flows:– run the BTI algorithm 26 times simulating the chip

registers as they would appear before and after the expected triggering time


BTI interaction diagramWhen output is asked forWhen a new event is read in


TRACO simulation

• More than 120 000 TRACO chips in CMS, on average 10 are not empty in each event– same situation as for the BTI’s

• The TRACO trigger cards keep:– map of active TRACO chips (L1MuDTTracoChip)– vector of output TRACO triggers

(L1MuDTTracoTrig)

• Reproduce the TRACO behaviour as time flows:– run the TRACO algorithm 26 times using as input the

BTI triggers found at the corresponding triggering time


Trigger Server simulation• The Trigger Server chips are instantiated at

setup time (250 for R- view and 250 for R-)• Reproduce the TS behaviour as time flows:

– Algorithm is run 26 times using as input the TRACO triggers found at the corresponding triggering time

• R- view algorithm implies a sorting of triggers:– example of use of bit-wise algebra: use ad hoc

developed BitArray class for bit manipulation– sorting is done using BitArray::operator<

• R- view algorithm is a bit packing of BTI’s output– use again BitArray methods


Persistency

• Persistency for MC information, raw data (including trigger) and reconstructed objects– Most CPU consuming processes are only run once!

• For the Fortran part of the chain use ZEBRA• For the OO part of the chain use Objectivity/DB

» see talk by L. Silvestris

• All Objectivity/DB (and ZEBRA) access is via CARF interfaces

• Use of Objectivity/DB is transparent to the simulation/reconstruction code and to the user program


Persistency

• Simulation is done in transient mode• Transition to persistent mode is done at the end

of the event processing• Make a copy of the cache of the trigger card

objects to its persistent representation• When reading from the DB CARF copies the

objects to the memory • The corresponding C++ pointers are loaded

into the cache of the trigger cards• Analysis is done in transient mode


Summary

• Object technology is well suited to reproduce the behaviour of the different electronic devices– use custom developed class for bit manipulation

• OO code for L1 trigger simulation of a CMS muon chamber is fully integrated in ORCA, the CMS reconstruction and analysis program– uses reconstruction on demand– allows persistency in Objectivity/DB databases

• Code already used in 1999 Monte Carlo production

Date post:	31-Dec-2015
Category:	Documents
Upload:	kylie-adkins
View:	28 times
Download:	1 times

Object Oriented simulation of the Level 1 Trigger system of a CMS muon chamber

Documents