TriggerJobOpts: Clean up transient ByteStream configuration

Changes:

• Split the one big function in TriggerTransBSConfig.py into individual functions per system.
• Still provide a combined function merging all systems in case it's needed.
• Include only the Calo transient BS configuration and drop all the others in the standard Trigger top-level job options. AFAIK Calo is the only client of this, so running all the other conversions is just a waste of resources.

Validation:
Checked that HLT Calo actually relies on this - removing transient BS cuts all calo-based chain counts even though no errors are printed and the job runs through just fine.
Compared RDOtoRDOTrigger config, logs and output RDO_TRIG before and after the changes in this MR - no unexpected differences, RDO_TRIG comes out identical.

FYI @wiedenma, @damazio, @jmasik, @tbold

Jenkins please retry a build

This merge request affects 1 package:

• Trigger/TriggerCommon/TriggerJobOpts

This merge request affects 3 files:

• Trigger/TriggerCommon/TriggerJobOpts/python/TriggerTransBSConfig.py
• Trigger/TriggerCommon/TriggerJobOpts/share/runHLT_standalone.py
• Trigger/TriggerCommon/TriggerJobOpts/share/runHLT_standalone_newJO.py

added Trigger master labels

CI Result SUCCESS (hash 284ab8d9)

	Athena	AthSimulation	AthGeneration	AnalysisBase	AthAnalysis	DetCommon
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
AthAnalysis: number of compilation errors 0, warnings 0
DetCommon: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 35553]

marked this merge request as ready

changed the description

added review-pending-level-1 label

added review-approved label and removed review-pending-level-1 label

Hello Rafal,

two things. I thought that L1Calo also depends on this. Doesn't it?! For the future Super-Cell based, in particular, with respect to the future HLTCalo-Super-Cellbased algorithms to be developed starting now, I was planing on also using transient BS. We could, of course, not rely on this, by just making a direct version (by passing the BS encoding-decoding step), but I really feel this would be a waste of resource (to work on this) and would reduce the very important validation of the issues that we can presently do, thanks to having this feature. Cheers, Denis

I don't think either Run-2 or Run-3 L1Calo simulation depends on any ByteStream in MC production. Perhaps you're remembering Run 1 (which I don't know much about)?

Note I didn't remove any code here. All I did was to just stop producing transient ByteStream for LVL1, ID and Muon objects in the main HLT job options, because there are no clients of this. The configuration functions are all still there if needed, but currently not used anywhere.

With this MR, the only things converted to transient ByteStream in the standard HLT job options for MC will be LArRawChannelContainer and TileRawChannelContainer.

Ok. I thought that the RawChannels for the L1Calo, I mean, LArTTL1EM, LArTTL1HAD, TileTTL1Cnt, were still needed. Maybe the code produces a transient copy somewhere and that is what is used.

They are produced in digitisation and are in the input RDO file

merged

mentioned in commit 1a52ad69

added sweep:ignore label

resolved all threads