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)
• change NHEL that instead of a lookup table (complicated for crossing) is a radix encoding of the helicity
• 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"
• 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"
• supported in standalone_mg7
  • can be check via the command "check crossing p p > j j j --output=standalone_mg7 --simd=sse4"
  • check command works for other simd format
• 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!)
• 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] Block beam polarisation + EVA under crossing (clear crash rather than silent wrong results).
• 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 (reserved for the maintainer).
• IOTest for madevent
• 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]

I'm looking to a new way to encode helicity to avoid to have to do a mapping. If it works we can try similar (but more complex?) idea for the color as well.

[oliviermattelaer]

Done with having coding of NHEL representing the value of the helicity (rather than an arbitrary look-up table).
This is obviously slightly slower (need to encode/decode) but at the end much more practical (in particular with crossing but also for density matrix/...
Tell me what you think about such idea, I can think of implementing something similar for the color-flow.
(likely more complicated since this is how particles connect but likely doable)

Documentation on the encoding to interface that with madspace:

Writing event helicities with the canonical helicity encoding (madspace)
This PR changes how a matrix element (ME) labels the helicity it selects for an event. A consumer that writes per-particle helicities (LHE SPINUP, the density matrix, …) must interpret that label with the rules below. Momenta and |M|² are unchanged — only the helicity label.

• The convention: the selected helicity is a self-describing canonical code
  The ME no longer returns an arbitrary row index. It returns one 1-based integer — the canonical mixed-radix code — that fully describes the helicity of every external leg.

Per external leg k (1..nexternal):

NHSTATE[k] = number of physical helicity states (2 for a fermion / massless vector, 3 for a massive vector, 4/5 for spin-3/2, spin-2).
STATES[d][k] = leg k's helicity values, i.e. get_helicity_states(allow_reverse=True) for the Fortran backends (allow_reverse=False for C++/cudacpp — each backend is internally self-consistent, so decode with the same backend's tables).
Last external leg = least-significant digit (matches itertools.product / the old NHEL order):

code = 1 + Σ_k digit[k] · Π_{j>k} NHSTATE[j]

• Decoding a code → per-leg helicities
  w = Π_{j>ipart} NHSTATE[j]
  digit = ((code - 1) // w) mod NHSTATE[ipart]
  helicity[ipart] = STATES[digit + 1][ipart]
  You don't have to reimplement it — every ME exposes it:

Fortran madevent (auto_dsig.f): GET_NHEL(code, ipart) → code>0: the helicity of leg ipart; code=0: NHSTATE[ipart].
Fortran standalone: DECODE_HEL(code, config), GET_NHEL(iden, table), SMATRIXHEL(P, code, flavor_idx, ans).
So the writer is just SPINUP[ipart] = get_nhel(code, ipart) for ipart = 1..nexternal.

• Without crossing
  Nothing special: each subprocess ME returns a code in its own enumeration; decode as in §2.

• With crossing
  A crossed subprocess shares a base ME, called with an extended index FLAV_IDX = cross·nflav + flav.

  • Option 1: Recommended: use the subprocess's own SMATRIX / get_nhel (crossing is transparent). The Fortran madevent relabels internally — the router / auto_dsig permutes the base code's digits by the crossing permutation, so the code handed back is already in this subprocess's enumeration. Decode it with this subprocess's get_nhel. Identical to §3, no crossing code on your side.

  • Option 2: If you call the base ME directly (e.g. today's C++/cudacpp Bridge, §5), the code is in the base leg order. Convert with the permutation:
    CALL GET_CROSS_PERM(FLAV_IDX, PERM, SGN, FLAV_USE) ! PERM[k] = base leg landing in this subprocess's slot k (1-based)
    for ipart in 1..nexternal:
    SPINUP[ipart] = get_nhel_base(code, PERM[ipart]) ! base ME's get_nhel, read at the permuted leg
    Critical: copy the helicity value unchanged — do not multiply by SGN. SGN is the NSF/momentum sign; it belongs to |M|² (nh = nhel·nsf), not the label. Applying it double-counts and silently reverses every crossed leg's helicity — invisible on non-chiral final states, wrong for e.g. w+ w- j j. (dep_states[k] == base_states[PERM[k]], no reversal — the incoming→antiparticle wf flip and the crossing conjugate+swap cancel.)

• Backend status
  Fortran standalone + f2py + madevent — fully in this PR; §4a works out of the box.
  C++/cudacpp (standalone_mg7) — non-crossing already returns the canonical code (the selected ihel is the mixed-radix code). The crossed relabel is not yet wired into the C++ allselhel selection (a scoped follow-up), so for a crossed flavor apply §4b with the generated cross_perm / GET_CROSS_PERM until it lands.

• Regression guard
  test_standalone_cross_symmetry.py::TestMadeventCrossingHelicity.test_w_helicity_asymmetry_ppwj — a small p p > w+ j run must write a physical, chirally-asymmetric W⁺ polarisation; a scrambled relabel breaks it.

Summary:

tl;dr for madspace: the selected helicity is now a self-describing 1-based mixed-radix code; write SPINUP[ipart] = get_nhel(code, ipart). If you go through the per-subprocess SMATRIX/get_nhel, crossing is transparent. If you call the base ME directly (C++ today), read the base code at GET_CROSS_PERM's permuted legs — and never apply SGN to the label.

[theoheimel]

Yes, I think using a smart encoding makes a lot of sense. If the encoding/decoding speed is an issue (I'd be surprised though), we can also consider a less compact but easier to decode representation with a fixed width of 3bits per particle for up to 8 helicity states.

[oliviermattelaer]

Ok we agree, let me try to do the same for the color of the events then.

[oliviermattelaer]

Done for the color encoding:

The matrix element emit a self-describing colour code (the colour analogue of the helicity encoding). The encoder is done on the MG7 side; the runtime that returns and decodes it is the madspace/cudacpp half described below.

What the ME now provides

• subprocesses.json (per subprocess): color_slots = {"color":[...], "acolor":[...]} — colour/anticolour slot leg numbers (1-based), flow-independent; color_codes — code of each flow (informational); color_flows — old ICOLUP tags, kept as fallback
• coloramps.h (per ME) : constexpr int colorflowcode[ncolor] + constexpr bool colorflowcode_valid

The code of the selected flow is colorflowcode[icolC], where icolC is the 0-based flow index the ME already picks in select_col_and_diag (allselcol = icolC + 1). Same integer on all three backends — the fortran colorflow.inc, the JSON color_codes, and the C++ colorflowcode[] agree byte-for-byte (u u~ > g g → {7, 11}).

The encoding

Order colour slots and anticolour slots by leg on the initial-state-flipped flow (every colour connects to an anticolour). Then code = Σᵢ digitᵢ·Nⁱ (N = #anticolour slots), where digitᵢ is the anticolour-slot index that colour slot i connects to.

Two runtime pieces to implement (specified, not yet built):

• api.cpp — return the code. It currently hardcodes color_out = 0 (mg7 colour is a stub today — the same gap as helicity_out = 0). Once the event's colour is selected: (likely fixed in the latest main)

• madspace LHECompleter — decode instead of table-lookup. Colour enters complete_event_data in exactly one place: the per-external-leg (colour, anticolour) list of the selected flow (color_flows[flavor][color_index][perm_index]). Replace that with a decode of the returned code producing the same length-nexternal array in matrix leg order; everything downstream (internal-line reconstruction, cancellation) is unchanged.

for (int i = 0; i < N; ++i) {                 // N = acolslots.size()
    int digit = (code / ipow(N,i)) % N;
    int tag = 501 + i;                        // fresh; only which legs SHARE a tag matters
    int cleg = colslots[i], aleg = acolslots[digit];
    // colour of cleg / anticolour of aleg, but SWAP those positions on initial-state legs
    (cleg <= n_initial ? anticol(cleg) : col(cleg)) = tag;
    (aleg <= n_initial ? col(aleg) : anticol(aleg)) = tag;
}

Three things to know

• The initial-state position swap is the one convention to get exactly right — it undoes the flip that defines the code, and it matches the fortran addmothers decoder.
• Tag numbers are free. Downstream relabels and cancels, so 501+i per event is equivalent to the old color_flows numbering. Events are colour-equivalent, not byte-identical (same as the fortran side).
• Fallback: colorflowcode_valid == false for colour sextets and epsilon structures (color_codes/color_slots null). Keep the color_flows lookup there. No SM tree process hits this.

color_flows — can be removed (but need validation/developement for sextet/epsilon_ijk, so fallback to it in those case)

Redundant for every valid-code subprocess (decode gives the externals; internal lines derive from them), but required as the sextet/epsilon fallback, so it stays in the JSON.

Validation boundary

Encoder validated (JSON + coloramps.h cross-checked against the fortran output; CPPProcess.cc compiles). The api.cpp/madspace pieces above need a cudacpp build + an mg7 event run to validate end-to-end — the same path the helicity encode is deferred behind.