Crossing symmetry

[oliviermattelaer]

Implementation:

• New default (--no_crossing -> --use_crossing)
• New default value (use_crossing is ON by default
  • @theoheimel we might want to backtrack that if you are not ready for madspace
• encoding choice via larger range for FLAV_IDX
  • FLAV_IDX = cross*nflav + flav where flav is the previous flavor index to use
  • cross = flip1*(nexternal+1)+flip2, where flip1 is the position (1 encoding) of the final state particle that is flip with particle 1, and flip2 is the position of the final state particle flip with particle2 (0 means no flipping)
    • encoding fail to capture all possible crossing (see dedicated post below).
• change NHEL that instead of a lookup table (complicated for crossing) is a radix encoding of the helicity
• change color index such that it also correspond to an encoding
• supported in standalone_fortran
  • check_sa.f does contains a demo code (not active) on how to use such feature
  • f2py compatible getting the index from the PDG requested
  • can be check via the command "check crossing p p > j j j"
  • C symmetry of helicity are now checked
• supported in standalone_cpp
  • check_sa.cc does contains a demo code (not active) on how to use such feature
  • can be check via the command "check crossing p p > j j j --output=standalone_cpp"
  • C symmetry of helicity are now checked
• supported in standalone_mg7
  • can be check via the command "check crossing p p > j j j --output=standalone_mg7 --simd=sse4 --precision=d"
  • check command works for other simd format
  • change SIMD strategy (seed post below)
  • C symmetry of helicity are now checked
• moves the T-channel propagator width treatment into ALOHA.
  • Outside the complex-mass scheme, the ALOHA propagator routine now drops the width i·M·Γ for spacelike (P²<0) momenta at runtime (correct t-channel treatment), replacing the old codegen call-rewrite (which only affected madevent's fk_ widths — standalone/cpp never got it)
  • new mg option: zerowidth_tchannel to control if this need to be activated (old madevent trigger is crashing now!)
• New width treatment zerowidth_external (default True): set the width to zero (internally to the matrix-element) for any particle that appears in the final state)
  • not applied if a particle is marked as offshell (*, syntax supported for standalone)
• Madevent handling:
  • Crossing within the same group:
    • a single matrix.f
    • multiple auto_dsigX.f
    • metadata generated as in the case of grouping
  • crossing-equivalent MEs in different P directories share one compiled ME via symlink;
    • the dependent keeps its own PDF/PS/leshouche/configs and routes its auto_dsig to the base SMATRIX.
    • Per-flavour event maps: flavour route (DSIG_XGROUTE), CONFIGMAP (multichannel diagram pairing), COLMAP,
      helmap.
    • Shared base .o via crossgroup.mk + a single parallel top-level makefile for all P dirs.
    • hadronic p p also uses cross-group sharing; crossing limitation tag extended to cross-group.
  • Helicity recycling: A cross-group base keeps all configs in the shared optim (exact; still recycles wavefunctions).
    • helicity needs a flipping associated to the permutation
      - [x] C symmetry of helicity are now checked compatible with helicity recycling
    • checked that event helicity are correctly written
      - [x] Block beam polarisation + EVA under crossing (clear crash rather than silent wrong results).
      - [x] handled only for the production side in case of decay chain syntax.
• New tests/acceptance_tests/test_standalone_cross_symmetry.py (multi-process crossing checks) and additions to test_standalone_madevent_consistency.py.

Validation:

• p p > j j bit-identical; p p > j j j matches; colour conserved.
• p p > t t~ j j: completes (was crashing), total within MC error, colour 0/10000 unphysical.
• p p > w+ w- j j: 22.74 vs 22.91 pb (<1σ), colour 0/2000 unphysical; QCD=0: 0.7315 vs 0.7326 pb.
• Lepton/photon EP EM > EP EM: now matches reference (0.2675, was ~1.8% low).
• In progress: check the rate in the lhef of
  • check the rate in the lhef of flavor
  • icheck the rate in the lhef of nitial state
  • check the rate in the lhef of color
  • check the rate in the lhef of helicity (CURRENTLY FAILING --under investigation--)
  • check density matrix computation

Known limitations / follow-ups

• IOTest references for the changed ALOHA propagator routines (TestAlohaWriter/*) still need regenerating.
• IOTest for madevent/standalone
• test_standalone_madevent_consistency.py uses group_subprocesses False, which the non-group madevent exporter doesn't support under the default use_crossing=True — needs --use_crossing=False there (or non-group crossing support).
• need a full run of the test suite (some reweighting one fail for example)

merge option

• merge now but set back the default to no_crossing
• implement in madspace before merging

[theoheimel]

Do we need any new functionality for that on the madspace side or will it just affect the generation of the subprocesses.json file and we will have a few more flavors within each subprocess?

[oliviermattelaer]

The things that was needed for madevent were multiple map to correctly connect the information

1. a map over the helicity (madevent use an helicity index which does not map trivially when crossing are happening -- important for the writing of the lhef)
2. a map over the color (also for the writing of the lhef)
3. a map for the sde (when the same matrix-element is used between grouping mode). This one I do not think that you will need (it is already contained in your json file)

So yes only subprocesses.json need to be modified. I forwarded your question to claude:

Short answer: It's not just "a few more flavors within each subprocess" — a crossing changes the initial state, so a crossed process can't live inside an existing subprocess's flavor list. But the extra work on the madspace side is small and localized: for the cross-section it's essentially just "pass the extended flavor id to the shared ME"; the phase-space machinery is untouched. The only genuinely new piece is for event generation (the per-crossing helicity/colour/channel index maps), and that's a design choice about where those tables live.

Why it isn't just more flavors in a subprocess. In subprocesses.json each subprocess has a fixed incoming/outgoing, and its flavors are what the exporter calls all_flavors_same_initial — different PDG assignments that share the same initial-state slots, hence the same kinematics/phase space. A crossing by definition moves a leg between the initial and final state, so a crossed process has a different incoming/outgoing (different PDF legs, generally different masses). It violates the same-initial invariant, so it must be its own subprocess entry, not an extra entry in the base's flavors list.

What actually changes in subprocesses.json. You get additional subprocess entries (the crossed ones), each with its own incoming/outgoing/channels/helicities and its own phase space, but pointing at the same me_path (shared compiled ME) plus one new field: the crossing / extended flavor id (cross*nflav + flav). This mirrors the Fortran madevent design exactly — each crossed process keeps its own phase-space setup and only the matrix-element object is shared.

What madspace needs — split by use case:

Cross-section / integration: essentially nothing new. Each crossed subprocess is an ordinary subprocess with its own incoming/outgoing, so phase space, PDFs, cuts, and channel sampling all work as today. The one requirement is that the ME call forwards the extended flavor id so the ME applies its internal crossing. The madmatrix/cudacpp backend already supports this (supports_crossing=True, extended flavor id) and returns the correct crossed |M|² internally — so no new PS math and no correctness work for the xsec.

Event generation (spin/colour in the event record): here there is something. The ME returns the selected helicity, colour flow, and multichannel channel in the base process's enumeration, but the event for the crossed process needs them in the crossed process's own convention. That's three small per-crossing maps — the direct analogues of the Fortran DSIG_XGHEL (helicity), COLMAP (colour), and CONFIGMAP (channel↔diagram). Decision to make: either emit them into subprocesses.json per crossed subprocess and have madspace apply them after the ME call, or bake them into the C++ ME. (Note CONFIGMAP is only an importance-sampling/variance matter, not correctness.)
Net: more subprocess entries (not more flavors per subprocess), each carrying a crossing id and sharing a me_path; zero new phase-space functionality; a trivial ME-call change to forward the extended flavor id for the xsec; and a small, well-defined set of index maps if/when you want correct spin+colour in the generated events.

Confirmed: the madmatrix/cudacpp ME currently returns the selected helicity, colour, and channel/iconfig in the base process's numbering — only the |M|² is crossed. So the crossed-process index maps (helicity/colour/channel, = Fortran DSIG_XGHEL/COLMAP/CONFIGMAP) are not yet handled by the ME. For cross-sections that's irrelevant; for event generation someone has to apply them — cleanest inside the C++ ME (the colour one especially, since it needs the base ME to publish its per-flow jamp2 and re-select in the dependent's colour basis), otherwise emitted into subprocesses.json and applied by madspace.

[oliviermattelaer]

@Qubitol, I add to take some decision concerning the nice handling of helicity/crossing to be optimised with SIMD, here is the documentation of such strategy. Would be nice if you can comment on this.

Per‑lane helicity: the SIMD strategy for standalone_mg7 crossing

Backend: madmatrix (cudacpp). Commit 4663f1855 on claude/fortran-cross-symmetry-3f13f3.

1. Background — crossing + the good‑helicity filter

Crossing symmetry lets one base matrix element serve all of its crossed
subprocesses. g q → t t̄ q already computes g q̄ → t t̄ q̄, q q̄ → t t̄ g, … —
same diagrams, relabelled legs. In standalone_mg7 this is carried by an
extended flavor id per event:

flavorID = cross * nmaxflavor + flav        // cross ∈ [0, (npar+1)²)

cross = 0 is the identity (base process); the momenta of a crossed event are
permuted into the base slot order per event (_crossing_preamble, deliberately
not vectorised — see §2), and the swapped legs' NSF sign is flipped.

Orthogonally, cudacpp uses a good‑helicity filter: sigmaKin_getGoodHel
samples a few events and keeps only the helicity rows that contribute; sigmaKin
then loops over that reduced set. The tension this note is about is how the
good‑helicity filter interacts with crossing in a SIMD/GPU execution model.

2. Why the original design used a union

cudacpp processes events in SIMD lockstep. sigmaKin loops once over a single
shared list cGoodHel, and for each helicity calculate_jamps computes all
events in the vector:

for (int ighel = 0; ighel < cNGoodHel; ighel++) {
  const int ihel = cGoodHel[ighel];              // ONE scalar helicity, all lanes
  calculate_jamps(ihel, …, iflavorVec, …);       // whole SIMD vector
}

The catch: events in one SIMD page share flav_use but may carry different
crossings. (That is exactly why _crossing_preamble gathers each lane's
permuted momenta in a scalar, per‑event loop.) A per‑crossing good‑helicity
gate therefore cannot be applied at this shared loop level — different lanes
would want different helicity subsets.

The original solution was the union: getGoodHel scans every
ncross * nflav combination and ORs the result, so cGoodHel is the union of
good rows over all crossings. Rows that vanish for a given lane's crossing simply
contribute 0. Correct, and SIMD‑clean — but a superset.

3. The cost of the union

The per‑crossing good sets are permutations of each other (crossing is a
relabelling), so they all have the same size but sit on different rows of
the table. On a chiral/EW process the good set is small yet the crossings scatter
it across the whole table, so the union blows up.

Measured, p p > w+ j, the gQ directory (ncomb = 24):

	helicity rows computed / event
any single crossing (base good set)	6
union over all 25 crossings	24 (all of them)

→ the union computes 4× more helicities per event than any single crossing
needs. (For pure‑QCD processes the base set is already near‑full, so the union
is barely larger and the win is small — the payoff is on EW/chiral matrix
elements.)

4. The strategy: per‑lane helicity

The key observation: helicity only ever enters the external wavefunctions
(ixxxxx / oxxxxx / vxxxxx). Everything after them — internal wavefunctions,
FFV* vertices, colour decomposition (get_amp) — is helicity‑agnostic and
already fully SIMD.

So we do not need a shared helicity across the vector. Instead:

• loop once over the per‑crossing good‑hel count (not the union);
• at iteration ighel, each lane uses its own crossing's ighel‑th good
  helicity — i.e. the helicity becomes a per‑lane quantity;
• the external wavefunction for a leg is built for each of the leg's helicity
  states and mask‑blended lane‑wise (does this lane want state v?);
• get_amp then runs full‑width on the blended wavefunctions — no lane masking
  downstream, no union waste.

This is the SIMD‑native realisation of the same shared‑filter idea the Fortran
and standalone_cpp backends express with a per‑event gate (CROSS_GHIDX /
ghfilt): each event ends up evaluating exactly its own good helicities.

External block, per leg (schematic)

{ static const int _st[NS] = { <helicity states of this leg> };   // e.g. {-1,1} or {-1,0,1}
  for (int _vi = 0; _vi < NS; _vi++) {
    const int _v = _st[_vi];
    ROUTINE(xmom, MASS, _v, +nsf, …, aloha_x[0], s);              // build wf at helicity _v, both NSF
    ROUTINE(xmom, MASS, _v, -nsf, …, aloha_x[1], s);
    const fptype_sv _sp = (icsign[s] + 1)*0.5, _sm = (1 - icsign[s])*0.5;   // per-lane NSF blend
    fptype_sv _hm{};
    for (int _ie = 0; _ie < neppV; _ie++) {                       // per-lane helicity mask
      int _hr = (_ighel < 0) ? ihel
              : cGoodHelOfCross[ iflavorVec[ievt0 + _ie] / nmaxflavor ][_ighel];   // (padded to -1)
      ((fptype*)&_hm)[_ie] = (_hr >= 0 && cHel[_hr][s] == _v) ? 1. : 0.;
    }
    // accumulate the lane-selected wavefunction (get_amp is unchanged after this)
    w_sv[s]    += _hm * (_sp*w_x[0]    + _sm*w_x[1]);
    pvec_sv[s] += _hm * (_sp*pvec_x[0] + _sm*pvec_x[1]);
  } }

Scalars (spin 1) carry no helicity, so their block stays the plain NSF blend.
The per‑leg state list comes from _hel_state_values(spin, mass) (fermion →
{-1,1}, massless vector → {-1,1}, massive vector → {-1,0,1}, spin‑2 too).

Data structures

getGoodHel builds a per‑cross table during its existing scan:

static int cGoodHelOfCross[ncross][ncomb];   // good rows per crossing
static int cNGoodPerCross[ncross];           // count per crossing
static int cNGoodMaxCross;                   // loop bound (= base count)

sigmaKin's summation loop then runs ighel < cNGoodMaxCross.

5. The mixed‑precision subtlety (please look here, reviewers)

calculate_jamps processes nParity pages in a loop, and the external block runs
once per page:

for (int iParity = 0; iParity < nParity; ++iParity) {   // nParity = 2 in mixed precision
  const int ievt0 = ievt00 + iParity * neppV;           // this page's first event
  … external block …
}

So the per‑lane helicity must be derived per page from ievt0. A first
implementation precomputed a _ihlane[neppV] array in sigmaKin for page 0 only;
in mixed precision (nParity = 2) that silently zeroed the second page —
every second neppV‑page of events came out 0 under divergent crossings.

The fix (and the current design): pass the good‑hel index _ighel to
calculate_jamps, and let the external block resolve _hr from
iflavorVec[ievt0 + _ie] per page. _ighel < 0 falls back to the scalar
ihel (used by getGoodHel's scan and by the non‑crossing path).

6. Scope and gating

• C++ path only — scalar‑SIMD and mixed precision. GPU
  (MGONGPUCPP_GPUIMPL) stays on the union; it isn't ported and needs a CUDA
  box to validate. (The CUDA async helicity loop is deliberately left on
  cNGoodHel; note it is textually identical to the C++ loop and is
  distinguished by the following line, fptype* hAllJamps vs cxtype_sv jamp_sv.)
• Fully gated on use_crossing. A non‑crossing build is byte‑identical:
  the OFF fills keep cNGoodHel / cGoodHel[ighel] / the scalar ihel, and the
  _ighel parameter is not even added to calculate_jamps.
• Codegen lives in madmatrix/model_handling.py
  (get_madmatrix_crossing_dict holes + _crossing_external_block) and two
  templates (process_function_definitions.inc, process_sigmaKin_function.inc).

7. Validation

check_sa -f <flavorID> forces one crossing for the whole run, so all lanes
share a crossing — it cannot exercise the very thing this change is about.
A small mixed‑crossing driver was used: patch the host flvVec to cycle
crossings per event (MG_FLVMIX="c0,c1,…"), so neighbouring lanes in a SIMD
vector carry different crossings.

Results on cppsse4 (neppV = 2, via sse2neon on arm64):

• per‑event |M|² is byte‑identical to the union build, in both
  FPTYPE=d (pure double) and FPTYPE=m (mixed precision, nParity=2), with
  divergent crossings inside a SIMD vector;
• check crossing --exporter=standalone_mg7 --simd=sse4: 3/3 (p p > w+ j)
  and 4/4 (p p > t t~ j);
• --use_crossing=False emits zero per‑lane machinery (historical output).

Work per event drops from 24 → 6 helicity iterations on w+ j (~4× on the
dominant get_amp); even the external‑wavefunction call count nets down
(≈ 192 → 108) despite the per‑state blend, because the iteration count falls
faster than the per‑iteration cost rises.

8. Open items

• GPU per‑lane port (needs CUDA to validate).
• The reported per‑event helicity allselhel for crossed events (separate
  commit 1eb6ec73c) is compile‑checked but runtime‑unvalidated — it does not
  affect |M|², only the LHE helicity label; it needs an event‑level cudacpp run
  against the Fortran backend to settle the permute‑vs‑NSF convention.

[oliviermattelaer]

One subtelty to keep in mind (maybe we should change the crossing encoding?):

Why q q~ > t t~ q q~ keeps its own matrix element (and is not routed as a crossing of q q > t t~ q q)

Context. In p p > t t~ j j the group P*_qq_ttxqq contains two compiled
matrix elements, matrix1_orig.f (Q Q > t t~ Q Q) and matrix2_orig.f
(Q Qx > t t~ Q Qx), plus one crossing router (Q~ Q~ > t t~ Q~ Q~). A natural
question is why Q Qx is a second matrix element rather than a crossing of
Q Q, since q q > t t~ q q and q q~ > t t~ q q~ are related by crossing.

Short answer. It is not a filtered/"no-flavour" diagram, and the
processes are genuine crossings. The one flavour that cannot be routed is the
flavour-changing annihilation d d~ > t t~ u u~, and the obstruction is a
limitation of the crossing encoding (it can only swap the two initial legs
with final ones — it has no final↔final permutation), not a physics or
diagram-content difference.

The facts (verified)

Diagram counts match, so no diagram is dropped — these are true crossings:

process	NGRAPHS	crossing of …
u u > t t~ u u	14	—
u u~ > t t~ u u~	14	u u > t t~ u u ✅
d u > t t~ d u	7	—
d d~ > t t~ u u~	7	d u > t t~ d u ✅

Reachability of the crossed signatures (from compute_crossing_pdg_entries):

u u~ > t t~ u u~   reachable from u u > t t~ u u   : True   (both leg orders)
d d~ > t t~ u u~   reachable from d u > t t~ d u   :
      (1,-1,6,-6, -2,  2)  =  d d~ > t t~ ū u      : True
      (1,-1,6,-6,  2, -2)  =  d d~ > t t~ u ū      : False   <-- the order the merged ME uses

Why the merged Q Qx ME still cannot route

Q Qx > t t~ Q Qx bundles (via flavour grouping) three flavour classes. Two of
them do cross to Q Q:

• d d~ > t t~ d d~ (same flavour) → crossing of d d > t t~ d d ✅
• d u~ > t t~ d u~ (mixed) → crossing of d u > t t~ d u ✅

The third is the flavour-changing annihilation d d~ > t t~ u u~ (initial d d̄,
final u ū, via d d̄ → g → t t̄ and g → u ū). It is a crossing of
d u > t t~ d u, but only with the two final same-flavour-group legs in the
order (ū, u):

crossing of d u > t t~ d u delivers :  … , ū(5) , u(6)     -> sig (1,-1,6,-6,-2, 2)
merged Q Qx > t t~ Q Qx lists       :  … ,  u(5) , ū(6)    -> sig (1,-1,6,-6, 2,-2)   (Q at 5, Qx at 6)

Going from (ū, u) to (u, ū) is a swap of the two final legs. The crossing
code encodes a crossing as

CROSS = I*(NEXTERNAL+1) + J        # swap initial-1 with final-I, initial-2 with final-J

i.e. only crossings of the two initial legs with final ones — there is no
final↔final permutation in the encoding. Since u and ū are different
particles, feeding the base's crossing SMATRIX the dependent's momenta in the
wrong order would evaluate the wrong |M|², so partition_crossing_classes
correctly refuses the match. Routing a merged member requires every flavour
to cross to a single base; this one flavour cannot, so the whole Q Qx ME stays
a base and gets its own matrix<i>_orig.f (and its own helicity-recycling run).

Consequences / how it could be enabled

• The current output is correct — Q Qx genuinely needs a matrix element it
  can evaluate; nothing is double counted or lost.
• This is not the cross-group Track-B case: g g > t t~ q q~ ↔ q q~ > t t~ g g
  are reused (symlinked base matrix element), because there the crossing is a
  plain initial↔final swap the encoding can express.
• To share Q Q with Q Qx one would have to generalise the crossing to also
  permute final legs (or have flavour grouping assign, for that flavour, the leg
  order the initial-leg crossing can actually reach). Either is a real extension
  of the crossing machinery, not a bug fix.

One-line summary

q q~ > t t~ q q~ is a genuine crossing of q q > t t~ q q, but the merged
Q Qx matrix element also carries the flavour-changing d d~ > t t~ u u~, whose
crossing needs a final-leg reorder the I*(N+1)+J encoding cannot express —
so the merged ME cannot be routed as a whole and keeps its own matrix element.