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!
Merge request reports
Activity
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
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
This merge request affects 5 packages:
- Calorimeter/CaloRec
- Event/ByteStreamCnvSvc
- LArCalorimeter/LArCnv/LArByteStream
- LArCalorimeter/LArROD
- Reconstruction/RecExample/RecExCommon
Adding @pavol as watcher
CI Result FAILUREAthena 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 FAILUREAthena 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]Prb another instance of https://its.cern.ch/jira/browse/ATR-20147 today
Edited by Christos AnastopoulosI assume !25436 (merged) fixes the issue. Jenkins, please retry a build