Expanding HLT1 persistency
Starting with some quotes from the discussion
Mhh, unfortunate that Hlt1 and Hlt2 persistence is so disjoint (we don't use this at all in HLT2) I'm a bit wary to entangle such different objects as calo clusters and jets (with this definition), such things might cause problems in the future. But I see that general hlt1 persistency is a bit beyond the scope of this MR.
But it would be good to know how this fits in the general strategy for hlt1 persistency (also for in the future). I haven't been involved with this, only hlt2. What I do know is that cutting corners here can be a massive pain later. As it is information you have to be able to read and its functionality you have to keep around, unlike a typical reco algorithm or so.
General thoughts
- Can we make Hlt1 and Hlt2 persistence less disjoint in the future? Can a DstData bank be used?
- Also on the more shorter term, what should be done in case of expending needs in Hlt1, like the case with jets proposed to be persisted as fake calorimeter objects?
The following discussion from !1372 should be addressed:
-
@mveghel started a discussion: (+11 comments) You're not setting anything for the seed id? Shouldn't your seed track have an actual calorimeter cluster associated to it? That should also be relevant information, no? This way if would be far more appropriate, as it actually would be a calorimeter cluster.
For past discussions, see also (thanks @sstahl): https://gitlab.cern.ch/lhcb-rta/direction/-/blob/master/wp1/persistency.md?ref_type=heads#considerations-for-run-3 and https://cds.cern.ch/record/2310579/files/LHCb-PUB-2018-005.pdf