Algorithm for LAr ByteStream reading

For @damazio and @pavol attention: A possible implementation of Re-entrant algorithm reading LArRawChannels for ByteStream.

Notes/Comments:

• So far reading the entire RawEvent and using the eformat::helper::create_toc to filter out LAr-fragments. Do we have somewhere a list of all LAr ROB-ids?
• I did not implement all the checks for data corruption we have in the old converter
• In this simple version, the cxx is less than 150 lines long with only ~30 lines of boilerplate code that could be shared with conversion-algorithms of LAr(Calib)Digits or LArFEBHeader.

Comments are welcome!

added 3 commits

• 84b8b5ba - remove useless/commentd code lines
• 60c3fc99 - LArRawChannelBSReadAlg: add checksum verification, refine handling of data corruption
• 65c247ae - rename LArRawChannelBSReadAlg into LArRawDataReadingAlg in preparation of generalizing it

Compare with previous version

added 2 commits

• 1d394bd8 - LArRawDataReadingAlg: Add reading of LArDigitContainer
• 91bda00f - LArRawDataReadingAlg: Add reading of LArFebHeader

Compare with previous version

As discussed with @pavol yesterday, extended this prototype to read also Digits and the data from the headers. They are stored in the same ROD-Fragment, so it makes sense to decode them at the same time. The implementation is still less than 300 lines and I believe it's well structured. That compares to >1000 lines in the reading part of old converter that we wrote in 2003 (and extended since then).

The actual decoding of the bits & bytes written by the readout electronics is done by the same RodBlockStructure classes that are used by the old converter I did not dare to touch them.

@damazio : If you stick to the service-approach for data-reading in the HLT, I think the RodBlockStructure classes are the only piece of code worth being shared between HLT and offline. The boilerplate code around is only some 10 lines.

Hello Walter,

I think I will need a bit more time to check all this. That said, I think we should not decode the digits with the energies. This can slow down things. Can we keep the LArRodDecoder instead?! I will try to read everything in the next two or three days. Please, remember that I also have to deal with the Tile, which has a similar interface (fillCollectionsHLT) which I would prefer to keep (see that I DID NOT read yet the code..) Thanks, Denis

Hi @damazio,

the decoding of RawChannels / Digits / FebHeaders is optional. One can turn each of them off by jobO.

For the trigger code, do you actually need the LArRawChannel object? I thought you are bypassing this step. I am pretty sure you'll need only a handful of code-lines from the LArRodDecoder (which is an overloaded and clumsy class)

• Walter

We don't need the LArRawChannel object. That is why we have fillCollectionHLT with LArCellCollection.. Denis

added 3 commits

• 27a569f5 - cosmetic changes (comments, messages, etc.)
• 91671855 - jobOption changes so that RecExCommon reads LAr raw data via...
• 15a48a93 - Update LArRawChannelBuilderAlgConfig to use LArRawDataReadingAlg (instead of converter)

Compare with previous version

With the changes above, the q431 test shows:

• No reference to LAr-data any more in ByteStreamAddressProviderSvc.TypeNames
• The LArRodDecoder public AlgTool is still in the job, probably because of TrigDataAccess service.
• The resulting ESD is identical

Up-wip'ing now.

• Walter

unmarked as a Work In Progress

Can you wait until tomorrow morning before merging? I’d like really to be able to look and understand it.. Thanks Denis

This merge request affects 5 packages:

• Calorimeter/CaloRec
• Event/ByteStreamCnvSvc
• LArCalorimeter/LArCnv/LArByteStream
• LArCalorimeter/LArROD
• Reconstruction/RecExample/RecExCommon

Adding @pavol as watcher

added Calorimeter EDM JetEtmiss LAr Reconstruction master review-pending-level-1 labels

added 1 commit

• 89dfb6ed - LArRawDataReadingAlg: Reseve vectors before filling

Compare with previous version

This merge request affects 5 packages:

• Calorimeter/CaloRec
• Event/ByteStreamCnvSvc
• LArCalorimeter/LArCnv/LArByteStream
• LArCalorimeter/LArROD
• Reconstruction/RecExample/RecExCommon

Adding @pavol as watcher

Hi @damazio,

I havn't touched any trigger code and havn't touched the old converter code.

• Walter

CI Result FAILURE

	Athena	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available at NICOS MR-25404-2019-08-07-17-56
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 1896]

CI Result FAILURE

	Athena	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available at NICOS MR-25404-2019-08-07-18-10
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 1900]

About the failing test Trigger_athena_MC_v7: It works locally if I feeed it with only one input file. With two input files the meta-reader fails. No idea how this could be triggered by my MR.

• Walter

Prb another instance of https://its.cern.ch/jira/browse/ATR-20147 today

I assume !25436 (merged) fixes the issue. Jenkins, please retry a build