Follow-up to #48163 (comment). As discussed in the XPOG meeting on Apr-01 (2026), the current implementation of OrbitNanoAODOutputModule is independent of that of NanoAODOutputModule, but it duplicates much of the source code in the latter (also, it ignored the RNTuple variant of NanoAODOutputModule, i.e. NanoAODRNTupleOutputModule).
- One should at least abstract the common parts (as already suggested by Core-Sw), removing the existing duplications in the source code.
- One could also try and extend
NanoAODOutputModule such that that plugin could handle FlatTables and OrbitTables alike "automatically" based on the content of the input file (and in that case, OrbitNanoAODOutputModule could be removed).
- I don't know if this makes sense, and I also don't know that there is a significant advantage in handling everything with
NanoAODOutputModule, since at config/python level the OutputModule for L1-Scouting data will anyway have to be different from the one for standard NanoAOD (because of the different EventContent).
Goals of this issue.
- Collect feedback on possible implementations, e.g. (vaguely speaking)
- make
OrbitNanoAODOutputModule inherit from NanoAODOutputModule (and make OrbitNanoAODOutputModule override only certain methods), or
- abstract the common (or the non-common) parts in some new utility class (and use that, instead of duplicating code across the two plugins), or
- extend
NanoAODOutputModule and remove OrbitNanoAODOutputModule, or
- ..some other approach ?
- Decide a timeline for an improved implementation.
- What release cycle is this targeting ?
- Clarify how the RNTuple variant of this OutputModule plays into this discussion.
- Is it sufficient to implement these improvements only for the RNTuple version, or not ?
The questions above are for @cms-sw/xpog-l2 (and other sw experts).
- I guess that providing the implementation is homework for the L1-Scouting group, since
OrbitNanoAODOutputModule is only used in the NanoAOD flavours for L1-Scouting data.
- At the same time, these changes would indirectly touch core XPOG software, so feedback/guidance/help from XPOG experts would help.
Follow-up to #48163 (comment). As discussed in the XPOG meeting on Apr-01 (2026), the current implementation of
OrbitNanoAODOutputModuleis independent of that ofNanoAODOutputModule, but it duplicates much of the source code in the latter (also, it ignored the RNTuple variant ofNanoAODOutputModule, i.e.NanoAODRNTupleOutputModule).NanoAODOutputModulesuch that that plugin could handleFlatTables andOrbitTables alike "automatically" based on the content of the input file (and in that case,OrbitNanoAODOutputModulecould be removed).NanoAODOutputModule, since at config/python level the OutputModule for L1-Scouting data will anyway have to be different from the one for standard NanoAOD (because of the different EventContent).Goals of this issue.
OrbitNanoAODOutputModuleinherit fromNanoAODOutputModule(and makeOrbitNanoAODOutputModuleoverride only certain methods), orNanoAODOutputModuleand removeOrbitNanoAODOutputModule, orThe questions above are for @cms-sw/xpog-l2 (and other sw experts).
OrbitNanoAODOutputModuleis only used in the NanoAOD flavours for L1-Scouting data.