GTT Objects Prototype

[NJManganelli]

Rebase of https://github.com/cms-l1-dpg/Phase2-L1Nano/pulls:

This draft PR starts some GTT extensions/additions to the L1Nano format, from some exploration a few months ago and re-basing things now. As of now, this is incomplete, and could use person-power in GTT to extend it more usefully, and decide on what's worth putting in now/later (e.g. see Vertex nTracksIn/Out: can be uncommented now, but we don't fill these in the VertexWord yet)

• hw values for Vertices are added. Most values match current expectations (nTracksIn/Out are not filled, but the lines can be uncommented to add them if these hw values are desirable)
• Vertex hwZ0 interpretation is wrong, would need to be filled to ensure signed-int value works as expected
• Vertex hwSumPt interpretation seems to be the integer cast of the float value stored. Expectation was a factor ~4 difference, to account for the 2 float bits from the ap_fixed<12,10> being accounted for, but it looks like truncation or the float sumPt is getting the wrong value by a factor 4 too large.
• FlatTableProducer for TkJets is added. A few test values are filled, but no validation is done
• Et and Ht sums are added with partial fills. More work would be needed to finish filling what's currently written in the link data (see https://github.com/cms-sw/cmssw/blob/master/L1Trigger/DemonstratorTools/src/codecs_htsums.cc, https://github.com/cms-sw/cmssw/blob/master/L1Trigger/DemonstratorTools/src/codecs_etsums.cc). These are currently in the least-interfaceable state, as much of the logic is in codecs rather than in the Object classes. This is a big(ger) problem to be solved, and would need some person-power and/or cross-talk on approach in correlator
• Whether hwValues are valuable additions to the format depends on use-cases, customizability, size constraints, etc. Storing the entire Word as long unsigned int would only work directly for vertices and sums (64 bits), Jets are encoded as 2 64-bit words (latter currently unfilled according to interface docs). This would also necessitate some interpretation machinery in e.g. a coffea schema or some utility functions (not out of the realm of possibility, but does make it a barrier to easy usage, so not pursued in this initial foray)

A GTTValidation script is added which does a few nigh-trivial tests of Vertices and checks for what branches have been successfully added to the nano format (presumes you create a few-event file with the current master configuration and append the postfix indicated by the 'forig' file open near the top). When things are complete, it could be left as an example or deleted to clean things up.

[artlbv]

Hi @NJManganelli @BenjaminRS could you update me on the status of this? I would prefer if we could switch to nano asap, and now it's mostly the GTT objects that are missing. Given that they are not even included in the final menu for now, it would add some overhead to maintain the old ntupler just for them.

Can we have the tkJets, tkHT and tkMET in already now and add the TPs for your studies later? For the physical quantities I'd suggest we use hardcoded scales for now. I would like to do a menu ntuple vs nano validation in one go rather than incrementally first without and then with GTT.

[artlbv]

I tested this in 14x and it works fine, though I see the physical pt values of the sums are missing. Is there any way to resolve this, even with hardcoded scales e.g. l1tmetemu::kStepMET? I would then propose to merge this PR to help us in the validation.

this is what we did for the menu ntuples https://github.com/artlbv/cmssw/blob/from-CMSSW_12_5_2_patch1/L1Trigger/L1TNtuples/src/L1AnalysisPhaseIIStep1.cc#L617-L632