As discussed in the XPOG meeting on Apr-01 (2026), the implementation of the NanoAOD flavours for L1-Scouting is currently organised as follows in CMSSW.
DataFormats/NanoAOD (xpog).
- Contains the
l1ScoutingRun3::OrbitFlatTable data format (which inherits from nanoaod::FlatTable).
PhysicsTools/NanoAOD (xpog).
- Definition of the 2 NanoAOD flavours (python sequence, and customisations), incl. the L1-Scouting NanoAOD EventContents.
L1TriggerScouting/Utilities (daq).
- C++ implementation of the plugins (and related classes) specific to L1-Scouting NanoAOD, most notably
OrbitNanoAODOutputModule.
Based on the discussion in that meeting, I understood that
- it would be good to have most of the implementation under a package which is reviewed by both XPOG and DAQ (incl. L1-Scouting experts), and
- having NanoAOD-related software under the generic
L1TriggerScouting/Utilities is arguably unintuitive.
This would suggest the following re-arrangement.
- (unchanged)
DataFormats/NanoAOD (xpog).
- Contains the
l1ScoutingRun3::OrbitFlatTable data format (which inherits from nanoaod::FlatTable).
- (new package)
L1TriggerScouting/NanoAOD (xpog, daq).
- Will contain all the python and C++ code related to L1-Scouting NanoAOD (which is currently in
PhysicsTools/NanoAOD and L1TriggerScouting/Utilities).
The "double ownership" of L1TriggerScouting/NanoAOD follows what is done for packages like DPGAnalysis/*NanoAOD* (which are under XPOG, plus the relevant DPG).
As far as I can see, the only disadvantage is the creation of a new CMSSW subpackage; not sure if this is okay.
Note: in this draft proposal, OrbitNanoAODOutputModule would be moved to L1TriggerScouting/NanoAOD for now. It might make sense to move it to PhysicsTools/NanoAOD eventually, depending on what will come out of #50635.
Any objections, or suggestions ?
Attn: @cms-sw/xpog-l2 @cms-sw/daq-l2
As discussed in the XPOG meeting on Apr-01 (2026), the implementation of the NanoAOD flavours for L1-Scouting is currently organised as follows in CMSSW.
DataFormats/NanoAOD(xpog).l1ScoutingRun3::OrbitFlatTabledata format (which inherits fromnanoaod::FlatTable).PhysicsTools/NanoAOD(xpog).L1TriggerScouting/Utilities(daq).OrbitNanoAODOutputModule.Based on the discussion in that meeting, I understood that
L1TriggerScouting/Utilitiesis arguably unintuitive.This would suggest the following re-arrangement.
DataFormats/NanoAOD(xpog).l1ScoutingRun3::OrbitFlatTabledata format (which inherits fromnanoaod::FlatTable).L1TriggerScouting/NanoAOD(xpog, daq).PhysicsTools/NanoAODandL1TriggerScouting/Utilities).The "double ownership" of
L1TriggerScouting/NanoAODfollows what is done for packages likeDPGAnalysis/*NanoAOD*(which are under XPOG, plus the relevant DPG).As far as I can see, the only disadvantage is the creation of a new CMSSW subpackage; not sure if this is okay.
Note: in this draft proposal,
OrbitNanoAODOutputModulewould be moved toL1TriggerScouting/NanoAODfor now. It might make sense to move it toPhysicsTools/NanoAODeventually, depending on what will come out of #50635.Any objections, or suggestions ?
Attn: @cms-sw/xpog-l2 @cms-sw/daq-l2