Diboson process split (ggZZ/qqZZ) and add missing Run 3 datasets

[neeraj-1729]

PR Description: Diboson Process Split + Missing Samples

Summary of Changes

1. ZZ Diboson Process Split (processes/ewk.py):

   • Restructured flat zz process tree into explicit zz_qqbar ($q\bar{q}\to ZZ$) and zz_gg ($gg\to ZZ$) sub-processes.
   • All existing leaf process names (zz_zll_zll, zz_zee_zee, etc.) are preserved for backwards compatibility.
   • Updated theory inclusive cross sections:
     • 13 TeV: $16.518 \pm 1.84%$ pb (NNLO+NNLL, PhysRevD 10.1103/2rr7-5xv3, Table 1)
     • 13.6 TeV: $17.627 \pm 1.93%$ pb (NNLO+NNLL, PhysRevD 10.1103/2rr7-5xv3, Table 1)
   • Updated per-decay-mode cross sections:
     • zz_qqbar: NLO $\times k=1.15$ ($14.6625$ pb inclusive; per-decay-mode values from XSDB)
     • zz_gg: LO $\times k=1.7$ ($47.43$ fb inclusive; values symmetric by lepton universality from Torben's slides)
   • Updated zz_qqbar 13 TeV inclusive: XSDB LO $\times k=1.51$ (LO$\to$NNLO) $= 12.14 \times 1.51 = 18.3314$ pb

2. WW Diboson Process Split (processes/ewk.py):

   • Restructured flat ww process tree into explicit ww_qqbar ($q\bar{q}\to WW$, id=8370) and ww_gg ($gg\to WW$, id=8380) sub-processes, same pattern as ZZ.
   • All existing leaf process names preserved for backwards compatibility.
   • Updated WW inclusive 13.6 TeV: LO Pythia $80.22$ pb $\times k \approx 1.75$ (LO$\to$NNLO) $= 140.4$ pb
   • ww_qqbar decay modes with explicit 13.6 TeV cross sections using XSDB Powheg NLO $\times k=1.14$ (NLO$\to$NNLO, arXiv:1605.02716):
     • ww_dl (WWto2L2Nu): $11.79 \times 1.14 = 13.44$ pb
     • ww_sl (WWtoLNu2Q): $48.94 \times 1.14 = 55.79$ pb
     • ww_fh (WWto4Q): $50.79 \times 1.14 = 57.90$ pb
   • ww_gg dilepton decay modes with explicit 13.6 TeV cross sections using MCFM LO (in fb, not pb) $\times k=1.41$ (LO$\to$NLO, arXiv:1511.08617):
     • Same-flavor (ee, $\mu\mu$, $\tau\tau$): $49.63$ fb $\times 1.41 = 69.98$ fb each
     • Different-flavor (e$\mu$, e$\tau$, $\mu\tau$): $2 \times 49.63$ fb $\times 1.41 = 139.96$ fb each (factor 2 from combining ordering samples)
     • Total gg$\to$WW$\to 2\ell 2\nu$ = $629.8$ fb

3. WZ Decay-Mode Cross Sections (processes/ewk.py):

   • All WZ decay-mode processes now have explicit 13.6 TeV cross sections using XSDB NLO values $\times k=1.08$ (NLO POWHEG $\to$ NNLO QCD $\times$ NLO EW from MATRIX):
     • wz_wlnu_zll (WZto3LNu): $4.924 \times 1.08 = 5.318$ pb (WZ Run3 paper)
     • wz_wqq_zll (WZto2L2Q): $7.568 \times 1.08 = 8.173$ pb (verified from CMS AN-2023/179)
     • wz_wlnu_zqq (WZtoLNu2Q): $15.87 \times 1.08 = 17.14$ pb (GenXSecAnalyzer verified)
     • wz_wqq_zqq (WZto4Q): $24.97 \times 1.08 = 26.97$ pb (GenXSecAnalyzer verified; XSDB mislabels this as "LO" but amcatnloFXFX is NLO — confirmed by 21% negative weight fraction)
   • 13 TeV wz_wlnu_zll: $4.430 \times 1.19 = 5.271$ pb (WZ Run2 paper)
   • 13 TeV values for other WZ decay modes still derived from inclusive via branching ratios
   • $k$-factor is between NNLO QCD $\times$ NLO EW (MATRIX) and NLO POWHEG (not NLO MATRIX) — both papers must be cited

4. New Process Definitions (processes/ewk.py):

   • wg_lnug: $W\gamma \to \ell\nu\gamma$ ($671.5 \pm 0.75$ pb at NLO from XSDB)
   • wpwp_jj: $W^\pm W^\pm jj$ same-sign WW ($0.0587 \pm 1.5\times 10^{-5}$ pb at LO from XSDB)

5. New Dataset Entries (Run 3 2024 Summer24 NanoAOD v15):

   • top.py: tttt_amcatnlo, ttg_amcatnlo, ttg_pt100to200_amcatnlo, ttg_pt200toinf_amcatnlo
   • higgs.py: thq_ctcvcp_madgraph, thw_ctcvcp_madgraph
   • ewk.py: wpwp_jj_ewkqcd_madgraph, wg_lnug_amcatnlo

Cross-Section References

Reference	Used for
PhysRevD 10.1103/2rr7-5xv3	ZZ inclusive NNLO+NNLL
MATRIX (arXiv:1912.00068)	WZ NNLO QCD $\times$ NLO EW
WZ Run3 (arXiv:2412.02477)	WZ $k=1.08$ (13.6 TeV)
WZ Run2 (arXiv:2110.11231)	WZ $k=1.19$ (13 TeV)
Torben's slides	ggZZ values
arXiv:1511.08617 (Caola et al.)	ggWW $k=1.41$ (LO$\to$NLO)
arXiv:1605.02716 (Grazzini et al., JHEP08(2016)140)	qqWW $k=1.14$ (NLO$\to$NNLO), WW Pythia $k\approx 1.75$ (LO$\to$NNLO)
CMS AN-2023/179	gg$\to$WW MCFM values, WZto2L2Q verification

[tolange]

@mafrahm @riga I think we are ready for review :)

[riga]

Thanks for all the work!

I did a first pass and added some inline comments to dataset / process names to ensure consistency with current naming schemes throughout cmsdb.

I also browsed through the ewk process changes and before reviewing deeper, could you do the following?

In the comments for the tracking of cross section values, there are a lot of factors common to more than one cross section value (e.g. k-factors). Could you - at the right spots - assign these common values to variables together with comments detailing where the values come from? With that, it's totally ok use in-line computations instead of doing some multiplications manually and pasting the value.

You're actually doing this already in some spots, like

# XSDB NLO: 6.912 pb × k=1.15 = 7.9488 pb
13: Number(6.912) * 1.15,

while in others, you write the computation in a comment like

# sum of ggZZ decay modes: 13 TeV: 3×2.703 + 3×5.423 = 24.378 fb
13: Number(24.378e-03),

The latter can just become

# sum of ggZZ decay modes 3×2.703 + 3×5.423 = 24.378 fb
13: Number(2.703 + 5.423) * const.n_leps * 0.001,

[neeraj-1729]

Thanks for the detailed review, @riga. I've addressed all the feedback in the latest push.

[riga]

Please find more inline suggestions below.

Before continuing, we'd have one comment / question on the new subprocess layer in both the ZZ and WW processes. You added the division into qq and gg-induced production and then re-attached existing processes to this new layer.

Let's use the following example to start the discussion:

zz_zee_zee = zz_gg.add_process(

(note that there are inline comments suggesting to change zz_gg → ggzz)

The fact that zz_zee_zee would now be g-induced only is rather implicit, and is purely driven by the existence of datasets in specific campaigns. The idea of processes behind was always for them to exist without strong ties to datasets or generator aspects .

Do you see any reason by existing subprocesses need to be re-attached to the ones you introduced?

[riga]

Do you have a reference (mcm/fragment link) stating that this sample is indeed only qq-induced?

[neeraj-1729]

I checked for ww_dl_powheg: https://cms-pdmv-prod.web.cern.ch/mcm/public/restapi/requests/get_setup/GEN-RunIII2024Summer24wmLHEGS-00309
the gridpack's flavor list directly, and only quark-antiquark initial states show up at Born level. No gluon-gluon entries anywhere, so this sample is indeed qq-induced only.

[riga]

Do you have a reference (mcm/fragment link) stating that this sample is indeed only gg-induced?

[neeraj-1729]

For ww_wenu_wenu_pythia : https://cms-pdmv-prod.web.cern.ch/mcm/public/restapi/requests/get_setup/HIG-RunIII2024Summer24wmLHEGS-00775
Checked the gridpack's input card directly. It's running MCFM process 127, which is specifically the gluon-loop-induced WW process (no quark-initiated diagrams in it). So yes, this sample is gg-induced only.

[riga]

Suggested change

	name="wpwp_jj_madgraph",
	id=15515111,
	processes=[procs.wpwp_jj],
	name="ww_ss_2j_madgraph",
	id=15515111,
	processes=[procs.ww_ss_2j],

[riga]

Suggested change

	"wpwp_jj",
	"ww_ss_2j",

[riga]

If you are just extracting a cross section at a single value, please use the verbose form

Suggested change

	13: multiply_xsecs(wz, const.br_w.had * const.br_z.clep)[13],
	13: wz.get_xsec(13) * const.br_w.had * const.br_z.clep,

[riga]

In this case, writing "qqbar" behind "ww" is misleading as it can be confused with decay products rather than the production mode.

Suggested change

	ww_qqbar = ww.add_process(
	name="ww_qqbar",
	qqww = ww.add_process(
	name="qqww",

Please also change in all instances below as well as in __all__.

[riga]

Same as above.

Suggested change

	ww_gg = ww.add_process(
	name="ww_gg",
	ggww = ww.add_process(
	name="ggww",

Please also change in all instances below as well as in __all__.

[riga]

Suggested change

	wpwp_jj = Process(
	name="wpwp_jj",
	ww_ss_2j = Process(
	name="ww_ss_2j",

[riga]

In this case, writing "qqbar" behind "zz" is misleading as it can be confused with decay products rather than the production mode.

Suggested change

	zz_qqbar = zz.add_process(
	name="zz_qqbar",
	qqzz = zz.add_process(
	name="qqzz",

Please also change in all instances below as well as in __all__.

[riga]

Same as above.

Suggested change

	zz_gg = zz.add_process(
	name="zz_gg",
	ggzz = zz.add_process(
	name="ggzz",

Please also change in all instances below as well as in __all__.

[neeraj-1729]

Thanks for the feedback, @riga . You're right, there's no strong reason for the existing decay-mode subprocesses to be re-attached under the gg/qq production-mode layer. The production mechanism is a generator-level distinction and shouldn't dictate the process hierarchy. I've moved all decay-mode subprocesses (zz_zll_zll, zz_zee_zee, ww_dl, ww_wenu_wenu, etc.) back to being direct children of zz/ww.

I've also applied all the other suggestions in this round:

Renamed zz_qqbar → qqzz, zz_gg → ggzz, ww_qqbar → qqww, ww_gg → ggww, wpwp_jj → ww_ss_2j
Replaced multiply_xsecs(wz, ...)[13] with the verbose wz.get_xsec(13) * ... form
Updated all and campaign dataset names accordingly