search

cms-l1-dpg / Phase2-L1Nano

NanoAOD ntupler for Phase-2 L1 Objects
Apache License 2.0
1 stars 5 forks source link

GTT additions #6

Closed NJManganelli closed 9 months ago

NJManganelli commented 9 months ago

This draft PR starts some GTT extensions/additions to the L1Nano format, from some exploration a few weeks ago and re-testing 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)

  1. 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)
  2. Vertex hwZ0 interpretation is wrong, would need to be filled to ensure signed-int value works as expected
  3. 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.
  4. FlatTableProducer for TkJets is added. A few test values are filled, but no validation is done
  5. 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
  6. 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 commented 9 months ago

Thanks for this Nick! Just one (two) things I would like to add to what I said on mm:

  1. We plan on moving to be cmsDriver compatible, thus allowing to modify the process via the customisation: #5
  2. I would like to propose to split the "low-level"/TP inputs and the main GT-level objects to different files. E.g. one cff for "final L1 /menu objects", one for GT objects, one for GTT low level etc . Not a showstopper, but maybe this could be taken into account already here?
artlbv commented 9 months ago

Note here the refactoring of the cff files: https://github.com/cms-l1-dpg/Phase2-L1Nano/pull/8

NJManganelli commented 9 months ago

Thanks, Artur. I will see about the refactor sometime in the next couple weeks. We still need to identify whom in GTT can work on further development beyond that point.

what are your thoughts on GTT vertices collection in GTT vs what to add for GT?

artlbv commented 9 months ago

what are your thoughts on GTT vertices collection in GTT vs what to add for GT?

What exactly do you mean here?

NJManganelli commented 9 months ago

Closed in favor of PR#9 which rebases things. We still need to find person-power in GTT