7818ffcb

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

certify the alternate endpoint of an exhausted radial bracket

Preserve existing accepted solves, then test the other represented endpoint
with the same residual allowance and fresh candidate-specific consistency
checks. Retain the original error/history when that candidate is rejected.
The actual GL638 regression pins the prior strict failure and original-equation
bounds, including an inconsistent-derivative negative case.

Validation: 35 broader tests plus the final strengthened overlapping fixture;
format/check/clippy pass with no changed-line warnings. Optimized build7 passes.
The exact previously failing complete Sample now returns stable Double and Arb
results with six cuts and identical canonical point/J/partition; all 25 native
accuracy checks pass. Preserve the tiny cut-2 component underflow diagnostic,
original interrupted confirmation and deliberately interrupted build6 evidence.
No proposal/tolerance change, further performance optimization, partial pooling
or completed-confirmation estimate is claimed.

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 1m59s 4s 4s 2m04s 1m59s
Eval 2m05s 1m04s 1m04s 3m10s 1s
Build 3m03s 2h32m01s - - 27m39s
Test 35m41s 23m32s - - 0s
Deploy - - - - 0s
Suite 1m59s 2h56m43s - - 29m40s

Timeline

Config Eval Build Test Failed Retried Compressed gap
0s2m3m31m32m33m34m35m36m37m38m39m40m41m42m43m44m45m46m47m48m49m50m51m52m53m54m55m56m57m58m59m1h0m1h1m1h2m1h3m1h4m1h5m1h6m1h7m1h8m1h9m1h10m1h11m1h12m1h13m1h14m1h15m1h16m1h17m1h18m1h19m1h20m1h21m1h22m