Replacement for TupleToolRecoStats (nTracks, etc)

Need functor replacement for TupleToolRecoStats which uses LHCb::RecSummary object to tuple nTracks, etc. (cc @erodrigu and @pkoppenb ).

It was pointed, after discussions with @sstahl, @nskidmor and @dfazzini , that the containers are not persisted after Turbo or Sprucing, so

• RecSummary needs to be created and persisted. A packer that writes RecSummary to a rawbank might be needed.
• The RecSummaryAlg needs to be modernised for Run3.

Is this in the domain of RTA WP1? (@jonrob and @dcampora )

[In Run2, Hlt2 created RecSummary and persisted in MDF (it was ran here using the SelReport mechanism perhaps due to historical reasons as there were no packers available)]

added RTA RTA WP1 To Do labels

I think in practical terms this is something that cannot be neatly classified as one group or another's responsibility. There are aspects related to RTA WP1, but also RTA WP2 as the alg in question has to 'know' how to determine the various quantities from the reco. Its also not obvious to me, that the old Run2 model of a single algorithm to do this is the best approach, given the work ongoing for persistency in run3 ? @graven ?

It is also the case that this is not going to be high priority for RTA right now, as its not needed (I guess?) to run HLT(1,2) (@mvesteri @poluekt I guess the selections in HLT2 do not need this ?) which is the only primary concern right now, getting dd4hep versions of these ready for data taking. So if DPA considers this critical, it also I think falls partly under DPA responsibility, and it might well need someone from that world to step in to work on it, if you need it 'soon'.

FYI @gligorov

@jonrob or someone else, could you point to an example to have a starting point to write a packer for this use case? In this case the packer is probably relatively easy, it just takes an object consisting of some ints and floats and writes out a rawbank.

[Adding link to https://gitlab.cern.ch/lhcb-dpa/project/-/issues/61 that contains the most comprehensive set of functors needed.]

@jonrob, RTA's or DPA's responsibility is often a fuzzy concept for things across the board. I would not care about that here since both projs have been cross-working nicely on various fronts - I don't think I need to mention recent examples to the crowd here.

What is important is that information that is not saved out of the trigger cannot ever be used by analysts, and the information discussed by Abhijit here is likely even more important for early measurements and "physics commissioning" than for standard analysis in 2024+. Consequently, though DD4hep is clearly a top priority at this point, I would not relegate reco stats to 3rd order, meaning it might then not become available for early-data analysts and even performance group people. That would be bad. The fact that selections in HLT2 do not need the info does not imply analysts do not need it to understand their data. My 2 cents.

I agree it's not very productive to classify whose responsibility this is. Ultimately as noted by others the reconstruction should clearly save a set of summary counters to some raw bank. I would suggest to discuss in an upcoming WP2 meeting, define which counters should be saved, and then figure out who has some time to do the work. cc @decianm @cmarinbe

Let's not divert too much into responsibilities, just see my comment above. We need an example how to write a packer for this case. I can then help with the configuration. Once the skeleton is there we can discuss which variables are need.

Discussing the packer is premature, IMHO, before we have discussed the transient format of the data. How to then make this data persistent comes second. As I said before its not obvious to me a monolithic RecSummary object in the same form as in Run2 is still the right approach here, but then I am less involved with the practical details of the persistency now than I was in Run2, so would value @graven's input here.

agreed with @gligorov from the reconstruction side we would need a list of information that you want to store. Then we can point you to where it is computed right now, or add it if needed be. @amathad we can have a dedicated discussion at the RTA-WP2 meeting next week if that can help

cc @sesen

@sstahl You can write the packed representation similar to any other object:

https://gitlab.cern.ch/lhcb/LHCb/-/blob/master/Event/EventPacker/include/Event/PackedTrack.h

https://gitlab.cern.ch/lhcb/LHCb/-/blob/master/Event/EventPacker/src/lib/PackedTrack.cpp

Packers/Unpackers are nicely templated so if you can keep same structure and naming convention, we can just add it to the list. https://gitlab.cern.ch/lhcb/LHCb/-/blob/master/Event/EventPacker/src/component/Packers.cpp

Thanks, will have a look.

mentioned in merge request LHCb!3671 (merged)

mentioned in merge request !3007 (merged)

mentioned in merge request Moore!1649 (merged)

Some very first version of writing the RecSummary in HLT2 can be found LHCb!3671 (merged) and !3007 (merged) and Moore!1649 (merged)

I added some description to the MRs. Feel free to comment.

Thanks @sstahl good to see this merged. Is there a proposal for what information beyond this initial skeleton to populate in RecSummary? Note that the Hlt1 SelReports now also fill some of this kind of information see Allen!837 (merged) which opens up the possibility of some interesting persistency based tests for HLT1 and HLT2 consistency at the level of the decoding or VELO reconstruction for example.

mentioned in merge request !3033 (merged)

mentioned in merge request DaVinci!729 (merged)

added DPA-WP3 label

added Tuples label

closed with merge request !3033 (merged)

mentioned in commit 6c9ed460

mentioned in commit DaVinci@0d47ab7f

Just a note. The algorithm currently only writes a subset of the information we had in Run 2. The full set still needs to be defined.

Added this to the description of https://gitlab.cern.ch/lhcb-dpa/project/-/issues/61