4d192b5b

By: ValentinHirschi <valentin.hirschi@gmail.com>

stabilize phase-space roots with prepared LU routing

Route fixed velocities before radial scaling in the phase-space callback.
Large cancelling master-frame components previously exhausted a narrow
bracket and rejected a foreign cut-channel inverse at full precision.
Keep other evaluators, solver budgets, profiles and density owners unchanged.

Validation: exact GL638 input fixture reproduces the old failure and certifies
the new root against the original equation; 15 regression tests passed.
Formatting, cargo check and Clippy passed with no changed-line diagnostics.
The optimized build and exact GL638 Halton3363 replay pass: all 13 native
forward rows remain identical, all 13 foreign Cut1 inverses now succeed,
and selected/summed reference paths pass with all 35 saved-file hashes
unchanged. Full seven-candidate acceptance remains a separate pending gate.

User requests:
Continue as planned, but after this current round of optimisation completes for the joint advanced sampling, stop optimizing further; we will accept current advanced sampling performance as-is for now. Instead focus on verifying that the physics expectation are met. That is:

i) The integrand weight in the HZ corner are now bounded.

ii) The variance of at least the absolute value of the integrand, but hopefully also of the integrand itself, is improved. (compare the MC error at a) fixed sample counts without advanced sampling, b) with only combinations of channels with simpler non-joint advanced maps, c) with the full optimal combination involving also joint advanced sampling maps)

iii) For a reasonable number of sample gain confidence of the fact that the case c) above leaves a bounded maximum weight, and at least smaller than the one found in b) and c). Also analyze what is the origin and cause of the remaining max weight point in b) and c) setups.

iv) Provide you current best estimate (central value + error) you current have now on GL638 cross-section. You can use up to 30 cores and 300 GB of RAM; but use less if you don't see performance scale linearly with number of cores until 30.

Continue as planned, but did you already do a local instpect/approach of the HZ corner to establish that the new joint map makes the GL638 weight bounded there now?

(
continue as planned, but also consider different combination of channels which you think are optimal,e.g. something like:

| ChannelTarget | |
| --------------- | ----------------------------------------------- |
| Cut 0 | `cut(2,6,12,13)` |
| **Cut 1 + H/Z** | `cut(2,6,10)` combined with joint H/Z focusing |
| Cut 2 | `cut(2,6,7,13,14)` |
| Cut 3 | `cut(2,4,12)` |
| Cut 4 | `cut(2,4,10,13)` |
| Cut 5 | `cut(2,4,7,14)` |
| Soft coverage | One LMB: `[6,12,13,14]`, containing both gluons |

Although the soft channel may not even be necessary.

Experiment with different combinations.

So toggling on/off the join mapping should not be by itself, but rather always in the presence of cut channels.

but of course also compare against the baseline of just the optimized LMBs (which is what we had before).

)
GitHub
Time to Start Worker time Duration Time to finish Idle
Config 1s 3s 3s 5s 1s
Eval 6s 1m39s 1m39s 1m45s 0s
Build 1m42s 2h42m28s - - 14m59s
Test 27m16s 16m39s - - 0s
Deploy - - - - 0s
Suite 1s 3h00m50s - - 15m02s

Timeline

Config Eval Build Test Failed Retried Compressed gap
0s1m4m5m6m7m21m22m23m24m25m26m27m28m29m30m31m32m33m34m35m36m37m38m39m40m41m42m43m44m45m46m47m48m49m50m51m52m53m54m55m56m57m58m59m1h0m