3a8c4142

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

record the GL638 fixed-count confirmation and retained maxima

Archive all 15 fresh build7 runs, fixed pre-results selection and lineage,
15 complete checkpoints, final pooled/seed diagnostics and maximum replays.
The composed joint method remains primary but does not confirm a uniform
variance gain over cuts: real variance increases 10.8%, imaginary decreases
35.1%. Report the graph estimate with empirical error and unresolved tails.

Validation: 135 independent statistics checks; 551 native maximum checks
reproduced with 415 independent checks, 60 bit-exact signed extrema, 48
complete Samples, six Arb controls, and unchanged pilot/state hashes.
No partial pooling, candidate reselection, global boundedness or calibrated
convergence claim. The actual joint imaginary maximum remains Double-only
until the separately authorized precise control/trace completes.

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).

)

Latest follow-up (root-provided task summary, not a verbatim quote): finish
current investigation and soft checks, then replace the standalone Cut1
channel with its joint variant; subsequently research adaptive precision and
current SymJIT O2/compression with 1/20-core separated timings. Defer summed
versus MC-channel comparison until those optimizations are assessed.

Latest user request (verbatim):
Continue and finalize your current investigation (and also notice that it may not be best to have two integration channels active for one of the cuts here; it may be interesting to see what happens when you enable just the joint map for it); also verify that the soft gluon behaviours are fine, even without the explicit lmb channel (with these gluons part of the lmb).

Also consider comparing sampling of all channels at once (i.e. explicitly summed) vs mc'ing over them (with importance sampling). Often, the first mode leads to less bias. (but only do that last part after the optimisation round below)

Then, now that we have some evidence of things working well, we should aim at improving a bit the runtime, before doing more long expensive runs.

To this end:

a) The following is too inefficient:

"""
1. very generated point and its complete sampling weight are prepared at **1000-bit precision**, even for ordinary LMB channels.
2. Joint-map support checks use **2048-bit interval arithmetic**.
"""

Find a way to safely avoid *always* going to higher-arithmetic precision (launch an agent on doing research on how avoid this safely).

b) Let's compile the integrand now with SymJIT o2, and make sure we're using the latest symjit version (patch it in Cargo.toml if need be, but it's a dependency of Symbolica at this point), and use the compression mode. Measure how the timings compare w.r.t current eager mode for double-precision evaluation, but not just monocore but also in production with 20 concurrence cores (it make a difference because of L3 cache saturation potentially).

Report what's your best measure runtime (separating integrand overhead, time spent in evaluators and time spent in advanced sampling) in this best setup you landed on.