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 crossing base bakes the shared optim over G_base U tau(G_base) (crossgroup_helunion.dat); wavefunction recycling is retained.
    • helicity needs a flipping associated to the permutation
    • tau is that flipping applied in place (the crossing's NSF sign flips), and it is the ONLY part of the transform the recycled optim can realise: it bakes its helicity configs into the HELAS calls and receives just (PUSE, IC) -- IC carries the signs, nothing carries the slot permutation.
    • the permuted map (the GHREMAP sigma that matrix<b>_orig.f applies via APPLY_CROSSING_TABLE) is the wrong one here. Baking G_base U sigma(G_base) cost -28.5% on q q~ > q q~; fixed in db46ee2, pinned run-free by TestCrossingRecycledHelicityUnion.
    • AMP2 (multi-channel) and JAMP2 (colour flow) -- not the |M|^2 sum -- are gated on TS(K).NE.0D0 for a crossing base, so each member weights channels and colour over exactly its own good set. A shared optim necessarily holds rows that are dead for whichever member is calling.
      - [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).
• q q~ > q q~ (q=u d s c, apply_flavor_grouping False, group_subprocesses True, MLM ickkw=1/xqcut=20): 5188690 +- 15750 vs the 3.7.2 reference 5184588 +- 2971 -- acceptancetest_flavor::test_flavor_grouping_consistency_mlm green on all four settings (the crossing+recycling one was 3706990 +- 10989, 105.8 sigma). Colour flow held: TestMadeventCrossingBaseColorFlow and TestMadeventRouterColorSelection pass, g g > u u~ crossing-on and --use_crossing=False both 3.023e6 +- 1406 pb.
• 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]

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.