algorithms and tools for digitisation

LHCb Simulation TutorialCERN, 21st-22nd February 2012

0110100111011010100010101010110100B00le

Input and output Coding suggestions Raw Event constraints

Algorithms and Toolsfor digitisation

2Algorithms and Tools for digitisation

Purpose of the digitisationFrom the hits produced by Gauss, generate:

The digitisations in the raw buffer, as they would come from the online readout systemThe MC history, allowing to associate a given digit to the MC particle that generated the digit.

Handle spill-overEvents produced 25 ns earlier can still produce signal in the detectors

Add noise if relevantElectronic noise, long-term radiation background

22 February 2012


InputGauss is producing MCHit objects

Position at entrance and exit of the sensitive volumeEnergy released in the sensitive volumeTime of the depositMomentum of the particleMC particle depositing energy.

This is a bit different for the calorimeters (MCCaloHit)Too many MC particlesCollect all the energy released in one cell by a given particleGroup by time slots (25 ns) and produce a deposit for each non empty time slot

Also somewhat different for RICHThis is the impact point in the HPD plane

22 February 2012


Typical processing sequenceAn algorithm that do the whole job

You can have also a sequence of algorithm to separate the various stepsBut this implies that you store intermediate results on the Transient Event Store (TES)

Need to define a class for your intermediate results Not clear what you gain…

Input the Gauss hits of your detector

LHCb::MCHits* myHits = get<LHCb::MCHits>( LHCb::MCHitLocation::MyDet );

No need to check: If not existent, an exception is thrown.Need to define the name of your container, as it should be produced by Gauss with that name…

22 February 2012


Loop on all the hitsFrom the position, define which channels are fired

This is where the DetectorElement will help!Note that there is a ‘SensDetId’ in the MCHit, that can be set in Gauss, to help finding where your hit is, i.e. to which sensitive volume it belongs

As the deposit is not limited to a single channel, you have to handle the sharing of the deposit on to various channels

Project the segment (entry-exit) to your measuring plane, and share the energy accordinglyMore refined handling of the deposit is welcome

Propagation in silicon with charge diffusion Fibres in SciFi and their boundary / connection to a SIPM cell …

Keep track of the truthWhich MC particle has deposited what in this channel

22 February 2012


Time informationThe time of the hit is measured as ‘age’ of the particle

0 is the time at the PVWhen reaching your detector, the minimum time is the time of flight!

You need to handle the time offset, as it will be done for the real detector. Compute the minimal time of flight per piece of hardware that can be time

aligned Store this offset in the detector element Use it…

Spill-over hitsThey are obtained by

LHCb::MCHits* myHits = get<LHCb::MCHits>( “Prev/” +

LHCb::MCHitLocation::MyDet );

This means the location is prefixed with the ‘BX’ name PrevPrev (-50ns), Prev (-25ms), Next (+25) and NextNext(+50).

The time of the hits in these containers is NOT offset by the BX offset, i.e. you have to subtract 50, 25 or add 25, 50 ns to the time.

22 February 2012


Channel numbering : LHCbIDEvery channel in LHCb has a unique ID

The upper 4 bits define the detector (1-8 already used…)The other 28 bits are detector dependentClass LHCb::LHCbID that you will need to modify

Add your detector name in the list Implement the methods to identify if this is your detector Extraction of the 28 lower bits to your own detector channel ID

Create your own detector channel IDHave a look at existing ones

VeloChannelID, STChannelID, …

The various fields in the ID code the hierarchy of our detector Plane, module, chip, channel…

It has to fit in 28 bits, and convert to / from an int

22 February 2012


Defining the Channel numbering scheme from the beginning

is absolutely essential

• Unique numbering scheme in your detector• Count from zero, not from one!• Used in the DetectorElement for geometry• Used in the truth association• Used everywhere in fact

22 February 2012


Using ToolsTools are simple workers

No concept of eventIn principle no memory of previous actions

A tool execute an action on some input, and returns values.

Inside a tool you have the same methods to access TES, print at various levels, … than in algorithms

A tool is defined by its interfaceSeveral tools with the same interface can existIt is easy to change which tool is used at ‘run time’

Compare different versions, more or less details, slow or fast,…

22 February 2012


Use a tool in your algorithm (or in another tool in fact)In the header, create a variable to hold the pointer to the tool (you need to include the interface definition)

#include “Interface/IMyOwnInterface.h” IMyOwnInterface* m_myTool;

In ‘initialize’, retrieve the tool m_myTool = tool<IMyOwnInterface>( myType, myName [,this] ); m_myTool = tool<IMyOwnInterface>( myType,[,this] );

‘myType’ is the name of an implementation of the interface. ‘myName’ is the name you want to use for this tool. Not too useful This type should be a property of the algorithm, i.e. it can be changed by options,

this means python configuration. Use the ‘this’ argument if you want your own private copy of the tool. Normally, only type, and it belongs to the tool service

In the execute method, use it type value = m_myTool->someAction( myArgs );

Simple and easy to useA clean interface is very important

Every variant of the tool must implement the complete interface

22 February 2012


Creating an algorithm or a ToolUse the LHCb customized emacs !

It knows how to create a tool and an algorithmBoth for header (.h) and implementation (.cpp) filesProper magic incantations are done for you.

cp $EMACSDIR/.emacs ~

(worse) Cut and paste an existing oneBut it may have an obsolete-but-still-working series of magic incantationsIt contains the original author and creation date…The most important: After cut and paste, EDIT !

22 February 2012


Coding in an algorithm/toolFollow the LHCb coding conventions !

Described in a note LHCb 2001-054 An update is probably necessary after more than 10 years ! Feed-back to the computing group if you want!

A lot of conventions and good practices are defined herehttp://lhcb-comp.web.cern.ch/lhcb-comp/Support/Conventions/default.htm

An update is also probably necessary Python configuration not too much described…

Following conventions allow other people to contribute and to eventually take over

Else the code is rewritten by each new person: Unreadable, ugly,…

22 February 2012

http://cdsweb.cern.ch/record/684691?ln=en

http://lhcb-comp.web.cern.ch/lhcb-comp/Support/Conventions/default.htm




Printing informationSometimes very useful to follow what an algorithm is doing

But not when processing billions of events

Easy printing with debug()or verbose()methodsNice formatting obtained with the instructions

format( “c format string with a %7.3d float”, variable)

For performance reasons, test the print level before formatting or before complex printout

If ( msgLevel( MSG::DEBUG ) { debug() << format( …) << endmsg;}

22 February 2012


Standard output: the Raw EventIt should mimic what the detector will provide

Each TELL40 will produce a block of data, called a bankThe event is a collection of banks.Each bank starts with a standard header, hidden from the user

It contains the id, serial number, version, length, and a magic pattern.

You need to do the grouping of information per TELL40One bank per TELL40The DetectorElement should tell you in which TELL40 is each channel.

Understand (clarify…) the data format proposed by your detector group

Minimize the size, but keep the decoding fast and efficient

22 February 2012


Standard offline method to create a bankCreate the data block for each TELL40

This is a vector of unsigned intGet the raw eventLHCb::RawEvent* rawEvt = get<LHCb::RawEvent>(LHCb::RawEventLocation::Default);

Add your bankrawEvt->addBank( source, type, version, data );

• Source = TELL40 number• Type = type of data, defined in the RawBank header• Version = defines how the data is coded. Start at 0, increase when the

coding changes. The decoding should check the version…

22 February 2012


Truth outputThis describes the relation between a channel and the MCParticles that have contributed to the signal

This is implemented by a Linker object See LHCb 2006-008 for details

Typical use case: Link a channelID to a MCParticle#include “Linker/LinkerWithKey.h”LinkerWithKey<MCParticle> myLink( evtSvc(), msgSvc(),

LHCb::MyDigitsLocation::Default );

for (…) { myLink.link( myId, aMCParticle*, weight );}

• The location is a string, the same should be used when retrieving the information

• myId is a channel ID (int)• Weight (optional) is a double.

22 February 2012

https://cdsweb.cern.ch/record/936887?ln=en


This truth output is importantThis is how one can understand the processing in Brunel

Reconstruction efficiency, ghost rate, …

This is up to you to build it during digitisationBut don’t hesitate to clean up

No truth for zero suppressed channels ! No truth for deposits due to spill-over hits

– They have no MCParticle associated in fact.

The weight makes sense only for analogue detectors And up to a certain point: something giving 1% of the signal can certainly be

ignored in the truth information

22 February 2012


Do we need a Digit class ?Originally, the output of the digitisation was a dedicated container of objects, each of them being a digit.

This is a lot of object, and is expensive in data volume / speed.

These objects are NOT written to the outputOnly the raw event

You could create such a class for your work in BooleOr use a vector of small dedicated objects, like pair <channel, content> to store temporarily the information

Brunel will probably not use the same objectReconstruction is something different

22 February 2012


SummaryThe technical part of the digitisation is not too difficult

Get the inputProduce banksProduce MC truth

The Detector Element is important. Work needed herePosition -> channel numberChannel -> TELL40 number

A channelID should be defined by your detectorMain identification of the data, and interface to Detector Element

The physics process in the detector are more complexAnd this is where you will have to do most of the work !

22 February 2012

algorithms and tools for digitisation

Documents