1 / 19

Algorithms and Tools for digitisation

Algorithms and Tools for digitisation. Input and output Coding suggestions Raw Event constraints. From the hits produced by Gauss, generate: The digitisations in the raw buffer, as they would come from the online readout system

lyris
Download Presentation

Algorithms and Tools for digitisation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Algorithms and Toolsfor digitisation Input and output Coding suggestions Raw Event constraints

  2. From the hits produced by Gauss, generate: • The digitisations in the raw buffer, as they would come from the online readout system • The MC history, allowing to associate a given digit to the MC particle that generated the digit. • Handle spill-over • Events produced 25 ns earlier can still produce signal in the detectors • Add noise if relevant • Electronic noise, long-term radiation background Algorithms and Tools for digitisation Purpose of the digitisation

  3. Gauss is producing MCHitobjects • Position at entrance and exit of the sensitive volume • Energy released in the sensitive volume • Time of the deposit • Momentum of the particle • MC particle depositing energy. • This is a bit different for the calorimeters (MCCaloHit) • Too many MC particles • Collect all the energy released in one cell by a given particle • Group by time slots (25 ns) and produce a deposit for each non empty time slot • Also somewhat different for RICH • This is the impact point in the HPD plane Algorithms and Tools for digitisation Input

  4. An algorithm that do the whole job • You can have also a sequence of algorithm to separate the various steps • But 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… Algorithms and Tools for digitisation Typical processing sequence

  5. Loop on all the hits • From 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 accordingly • More 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 truth • Which MC particle has deposited what in this channel Algorithms and Tools for digitisation

  6. The time of the hit is measured as ‘age’ of the particle • 0 is the time at the PV • When 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 hits • They 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. Algorithms and Tools for digitisation Time information

  7. Every channel in LHCb has a unique ID • The upper 4 bits define the detector (1-8 already used…) • The other 28 bits are detector dependent • Class 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 ID • Have 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 Algorithms and Tools for digitisation Channel numbering : LHCbID

  8. Algorithms and Tools for digitisation 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

  9. Tools are simple workers • No concept of event • In 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 interface • Several tools with the same interface can exist • It is easy to change which tool is used at ‘run time’ • Compare different versions, more or less details, slow or fast,… Algorithms and Tools for digitisation Using Tools

  10. 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 use • A clean interface is very important • Every variant of the tool must implement the complete interface Algorithms and Tools for digitisation

  11. Use the LHCb customized emacs ! • It knows how to create a tool and an algorithm • Both for header (.h) and implementation (.cpp) files • Proper magic incantations are done for you. cp $EMACSDIR/.emacs ~ • (worse) Cut and paste an existing one • But it may have an obsolete-but-still-working series of magic incantations • It contains the original author and creation date… • The most important: After cut and paste, EDIT ! Algorithms and Tools for digitisation Creating an algorithm or a Tool

  12. Follow 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 here • http://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,… Algorithms and Tools for digitisation Coding in an algorithm/tool

  13. Sometimes very useful to follow what an algorithm is doing • But not when processing billions of events • Easy printing with debug()or verbose()methods • Nice 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; } Algorithms and Tools for digitisation Printing information

  14. It should mimic what the detector will provide • Each TELL40 will produce a block of data, called a bank • The 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 TELL40 • One bank per TELL40 • The 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 Algorithms and Tools for digitisation Standard output: the Raw Event

  15. Standard offline method to create a bank • Create the data block for each TELL40 • This is a vector of unsigned int • Get the raw event LHCb::RawEvent* rawEvt = get<LHCb::RawEvent>(LHCb::RawEventLocation::Default); • Add your bank rawEvt->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… Algorithms and Tools for digitisation

  16. This describes the relation between a channel and the MCParticles that have contributed to the signal • This is implemented by a Linkerobject • 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. Algorithms and Tools for digitisation Truth output

  17. This truth output is important • This is how one can understand the processing in Brunel • Reconstruction efficiency, ghost rate, … • This is up to you to build it during digitisation • But 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 Algorithms and Tools for digitisation

  18. 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 output • Only the raw event • You could create such a class for your work in Boole • Or use a vector of small dedicated objects, like pair <channel, content> to store temporarily the information • Brunel will probably not use the same object • Reconstruction is something different Algorithms and Tools for digitisation Do we need a Digit class ?

  19. The technical part of the digitisation is not too difficult • Get the input • Produce banks • Produce MC truth • The Detector Element is important. Work needed here • Position -> channel number • Channel -> TELL40 number • A channelID should be defined by your detector • Main identification of the data, and interface to Detector Element • The physics process in the detector are more complex • And this is where you will have to do most of the work ! Algorithms and Tools for digitisation Summary

More Related