level 2 trigger software interface

9/12/99 R. Moore 1

Level 2 Trigger Software Interface

R. Moore,Michigan State

University

9/12/99 R. Moore 2

L2 Crate

Administrator

Worker WorkerWorker

Data Input Data Output

Trigger Control Computer

ExternalCommunications

InternalCommunications

9/12/99 R. Moore 3

Software Components

AdministratorMBus

Worker LevelUser code

Tool LevelUser code

L2 Software Framework

Worker

Physics!

Pre-ProcWorker

GlobalTool

GlobalWorker

9/12/99 R. Moore 4

L2 Simulator

PackedData

RawChunk

UnpackData

Chunk

Ev

ent In

terfac

e

WorkerCode

Ev

ent In

terfac

e

Online

Offline

(testing only)

dynamic_cast<>

Online Code

Offline Package

I/Ogen

I/Ogen

9/12/99 R. Moore 5

L2 Simulator

• L2 simulator runs online worker code only– framework code

(administrator) not included because it has no physics impact

• Online L2 framework replaced by offline code:– control hooks replaced by

offline framework package– data interface replaced to

use unpacked data chunks

9/12/99 R. Moore 6

Writing L2 Code

• What you need to know:– L2 coding guidelines

(http://d0lxmsu1.fnal.gov/L2/L2CodingGuidelines.pdf)

• How to use DOC++

– How to use the offline build environment

• CTBuild user guide hopefully appearing soon…?

– Input and output object formats• tell Dylan and he’ll add them to the

L2 I/Ogen configuration file

– Worker algorithm

• What you don’t need to know!– Unpacked data chunks– Whether you are running online

or offline

9/12/99 R. Moore 7

Creating a Worker

• Create a new package for the algorithm code named:– l2<worker abbrev>worker– e.g. l2gblworker, l2cttworker

• Write the main worker class and put it into this package– the same class is used online

AND offline– Class name: <worker>Worker

e.g. GlobalWorker

• Create a new package to interface to trigsim, called:– tsim_l2<worker abbrev>– e.g. tsim_l2gbl, tsim_l2ctt …

9/12/99 R. Moore 8

Writing the Worker Class

• Worker class is ONLINE code– ALL L2 workers need one– Required methods:

• void processEvent(void)• Plus others to be added later

for monitoring, initialization etc.

– MUST obey L2 online coding guidelines: no STL!

• processEvent(void)– processes the current

event– Event I/O handled by

offline or online framework

9/12/99 R. Moore 9

Offline Interface

• Use L2 specific macros to register with framework– e.g. tsim_l2gbl.cpp

#include "framework/Registry.hpp"#include "l2workersim/FrameworkMacros.hpp"#include "l2gblworker/GlobalWorker.hpp"#include "l2gblworker/GlobalEventInput.hpp"#include "l2gblworker/GlobalEventOutput.hpp"#include "l2workersim/WorkerSim.hpp"

using namespace l2gblworker;using namespace l2workersim;

L2FWK_REGISTRY_IMPL(Global,"$Name: $")

#include "framework/Registry.hpp"#include "l2workersim/FrameworkMacros.hpp"

L2FWK_REGISTRY_DECL(Global)

– e.g. Regtsim_l2gbl.cpp

9/12/99 R. Moore 10

Input Format

L2Header

Object

L2Trailer

Object

Object

= InputBuffer<Object>

= ChunkInputBuffer <Object>

• Single MBT (or UDC if offline) channel maps to a template class•Behaves like an array

of the given object type•Inherits from L2Header

to allow access to header data

9/12/99 R. Moore 11

Output Format

L3Header

L3Trailer

Node Header

L2Header

Object

L2Trailer

Object

Object

L2Header

Object

L2Trailer

Object

Object

Channel

Channel

Channel

Channel

Channel

Module

Raw Data Unpacked Data Chunk

9/12/99 R. Moore 12

High Level Format

• Each worker and administrator has three possible output modules– Normal L2 output– Copy of inputs (UBS events)– Special UBS event data

output

Raw Data Unpacked Data Chunk

Crate = System

L3 OutputUBS Inputs = ModuleUBS Output

9/12/99 R. Moore 13

Building the Output

• Output created by ‘ChannelFiller’ templates which each fill one channel

• Template parameters:– Object type stored in channel– ‘Getter’ class

• ‘Getter’ class fetches the data from the worker code:– bool gotData() returns true if

there is more data to get– <Object> &nextObject()

returns the next object– void newEvent() notifies class

of a new event

• Some standard ‘Getters’ provided

9/12/99 R. Moore 14

Event I/O

• Classes to access data created by evigen python script– <worker>EventInput– <worker>EventOutput

• Configuration file similar to Windows .ini files

• Full documentation being worked on…

9/12/99 R. Moore 15

Example.evi

[Worker]package = l2gblworkername = Globalsystem = GBL_L2stdout = GBL_STD_OUTPUTubsout = GBL_UBS_OUTPUTubsin = GBL_UBS_INPUTS

[Input0]name = pTTrackobject = CTTPTTracktype = unpackedlimit = 50system = CTT_L2module = CTT_STD_OUTPUTchannel = GBL_PTTRACKcomment = pT tracks from CTT

9/12/99 R. Moore 16

Example.evi II

[StdOutput0]object = Electrongetter = l2workerbase/FetchTagchannel = GBLOUT_ELECTRONmajorver = 0minorver = 1

[StdOutput4]object = Taugetter = l2workerbase/FetchTagchannel = GBLOUT_TAUmajorver = 0minorver = 1

[UbsOutput0]object = Electrongetter = l2workerbase/FetchAllchannel = GBLOUT_ELECTRONmajorver = 0minorver = 1

9/12/99 R. Moore 17

Accessing the Data

• To access the input data inherit the EventInput class

class ATool : public GlobalEventInput {…void findElectron(void);…};

void ATool::findElectron(void) {if (pTTrack.bunch() != emCluster.bunch()) errlog << “Calling SCL init!”…… dphi=pTTrack[i].phi()-

emCluster[j].phi();…}

9/12/99 R. Moore 18

Writing the Data

• To use provided “Getter” classes output objects inherit from a “Creator”

• This provides a static method “create()” which returns a pointer to a new class instance– you cannot use ‘new’ !

class Electron : public Creator<Electron> {…};

Electron *myelectron = Electron::create();

9/12/99 R. Moore 19

Current Status

• Basic software packages written and docs in progress– Basic interface stable, only

minor changes or additions– Ready for L2PP’s to start

using framework– BUT still a little rough:

• Need to liase with Dylan/me• Not everything will work “out

of the box” just yet

– Toy “GlobalWorker” written by Dylan• Can test single Global tools

9/12/99 R. Moore 20

Still to do…

• Add interface to L2 low level parser– L2parser package written

and documented– Can’t use RCP: online code

• Add hook for monitoring data: collectStatus()

• Add support for ‘non-standard’ data formats:– e.g. CTT has private header– if L2 input not stored in L3

raw data need to write a package to recreate it

– BUT some L1 packages will use L2 UDC standard (L1Cal)

9/12/99 R. Moore 21

Yet more to do…

• Make a L2 release– Currently all packages in CVS

but not in a release

• Understand the build system (CTBuild/SRT/…)– Need to set compiler options

• e.g. “-DOFFLINE”, “-DDEBUG”

– CTBuild docs promised…

9/12/99 R. Moore 22

Conclusion

• The basic L2 framework is complete and ready for use– should remove a lot of the pain

we have had to endure!

• Switching to online is easy… once we have the hardware– Code written 6+ months ago– Needs interfacing with low level

device drivers

• “Bells and whistles” will be added over the next several months as interfaces are agreed upon– monitoring– configuration

9/12/99 R. Moore 23

Data I/O

• All L2 I/O done using I/Ogen classes:– Python script which

generates code to convert between packed memory and C++ class

– handles multiple format versions in offline

– centralizes object formats to ensure compatibility

– interfaces easily to the (new) Unpacked Data Chunks

– creates routines to print data classes in human-readable form

9/12/99 R. Moore 24

I/Ogen in l2io

ConfigurationFile [l2io.iogen]

Python Script

IO Classes Data Classes