Introduce L1ScoutingNanoAOD for Run3

[patinkaew]

PR description:

Please also note contributions from @gpetruc, @Mmiglio for initial and important components of L1ScoutingNano as well as L1Scouting team for numerous valuable feedbacks.

This PR introduces L1ScoutingNanoAOD workflow for Run3. For L1Scouting data, each processing event is actually an orbit (in OrbitCollection), different OutputModule is needed to convert orbits to bunch crossings (bx).

Some key features:

• OrbitNanoAODOutputModule is analogous to NanoAODOutputModule and is used to convert orbits to bxs.
• OrbitFlatTable is analogous to nanoaod::FlatTable and contains offsets of each bx in an orbit
• SimpleOrbitFlatTableProducer is analogous to SimpleFlatTableProducer and has all functionalities of SimpleFlatTableProducer.

Two custom NanoAOD flavours are added: @L1Scout for ZeroBias stream and @L1ScoutSelect for Selection stream.

Event content files (html) can be found here on CERNBOX.

PR validation:

Pass all tests from scram b runtests use-ibeos.

Two relval_nano workflows are added for each flavour.
Pass these two workflows from runTheMatrix.py -l 2500.240,2500.241

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

This is not a backport.

[cmsbuild]

cms-bot internal usage

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48163/44934

• There are other open Pull requests which might conflict with changes you have proposed:
  • File Configuration/PyReleaseValidation/python/relval_nano.py modified in PR(s): NanoAODv15-Lite setup for Run2UL and 2022/2023 #48104, Update NANO relval workflows #48152
  • File DataFormats/L1Scouting/interface/OrbitCollection.h modified in PR(s): Calo towers L1 scouting data format update #48093
  • File DataFormats/L1Scouting/src/classes.h modified in PR(s): Calo towers L1 scouting data format update #48093
  • File DataFormats/L1Scouting/src/classes_def.xml modified in PR(s): Calo towers L1 scouting data format update #48093
  • File PhysicsTools/NanoAOD/python/autoNANO.py modified in PR(s): [NGT] Introduce NanoAOD flavour for Phase 2 HLT #48091

[ftorrresd]

enable nano

[ftorrresd]

please test

[cmsbuild]

-1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-43d56f/46799/summary.html
COMMIT: fe95b32
CMSSW: CMSSW_15_1_X_2025-06-16-2300/el8_amd64_gcc12
Additional Tests: NANO
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/48163/46799/install.sh to create a dev area with all the needed externals and cmssw changes.

This pull request cannot be automatically merged, could you please rebase it?
You can see the log for git cms-merge-topic here: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-43d56f/46799/git-merge-result

[patinkaew]

Hi @ftorrresd,

Sorry for a delay. I just fix the merge conflict.

Please note that the workflow numbers for L1ScoutingNano have changed (since BPHNano workflow in 140X was removed in master).

2500.239 L1Scouting2024RAW14.0+l1ScoutingNANO_data14.0 
2500.24 L1ScoutingSelection2024RAW14.0+l1ScoutingSelectionNANO_data14.0

Best,
Patin

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48163/45278

• There are other open Pull requests which might conflict with changes you have proposed:
  • File DataFormats/L1Scouting/interface/OrbitCollection.h modified in PR(s): Calo towers L1 scouting data format update #48093
  • File DataFormats/L1Scouting/src/classes.h modified in PR(s): Calo towers L1 scouting data format update #48093
  • File DataFormats/L1Scouting/src/classes_def.xml modified in PR(s): Calo towers L1 scouting data format update #48093

[ftorrresd]

+1

[Moanwar]

+Upgrade

[emeschi]

+1

[AdrianoDee]

+pdmv

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @mandrenguyen, @rappoccio, @antoniovilela, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2)

[mandrenguyen]

+1

[makortel]

Sorry, I didn't realize this part until it broke compilation against ROOT master (see #48720 for a fix).

I'm curious what is the planned maintenance model wrt. NanoAODOutputModule given that some amount of non-trivial code is currently "shared" by copying it (i.e. any similarity can be thought of accidental). Are there parts that should be really shared, or is the future of these two components completely disjoint?

Also, who will port/migrate this module to RNTuple in the future?

[patinkaew]

Hi Matti,

Sorry for a delayed response. We discussed this a bit during last week L1 Scouting meeting 19.08.2025.

Thank you for the fix and sorry that I didn't catch the deprecated constants earlier. Since OrbitNanoAODOutputModule shares lots of code with NanoAODOutputModule, it would be optimally not to hard-copy to avoid code duplication and if there is a change in NanoAODOutputModule, OrbitNanoAODOutputModule will be changed accordingly (for example, in this case). Hence, the current implementation is not quite optimal and leaves this issue on deprecated constants unchecked. However, I would expect that NanoAODOutputModule will need to be refactored and personally, I wouldn't want to do this during data-taking so I hope the refactor will be done after Run3 finishes.

OrbitNanoAODOutputModule handles translating from orbit-based collection used in L1 scouting to event-based. From my understanding, CMSSW processes event-by-event. In the L1 scouting case, this is orbit-by-orbit. Hence, we use OutputModule to handle changing to event-based when writing to TTree. Do you have any suggestions/ideas on how we can use the standard NanoAODOutputModule?

Regarding porting this module to RNTuple, I'm not very familiar with RNTuple nor RNTupleOutputModule yet and not following the latest development, but I would be happy to implement it if I'm still working with CMS (hopefully). Otherwise, I will compile some documentation for the L1Scouting group so someone will be able to take over as well.

@gpetruc also agrees with this and suggested that we refactor and migrate to RNTuple at the same time. He can also offer to help.

[makortel]

However, I would expect that NanoAODOutputModule will need to be refactored and personally, I wouldn't want to do this during data-taking so I hope the refactor will be done after Run3 finishes.

Ok.

Do you have any suggestions/ideas on how we can use the standard NanoAODOutputModule?

No. I'd look into abstracting the common parts into components that could be shared between this and the NanoAODOutputModule.

Regarding porting this module to RNTuple, I'm not very familiar with RNTuple nor RNTupleOutputModule yet and not following the latest development, but I would be happy to implement it if I'm still working with CMS (hopefully). Otherwise, I will compile some documentation for the L1Scouting group so someone will be able to take over as well.

Ok. The RNTuple-based NanoAOD is still in the works (@ariostas), so it might be useful to either wait for that dust to settle, have this use case included in that work. In any case all this is eventually up to @cms-sw/xpog-l2 (and possibly @cms-sw/daq-l2). I only got concerned of somewhat complicated code being copied around, and if that would have potential to cause maintenance issues in the future.