qmc/sse: default EPSILON to an ergodic value for sign-problematic models

[skilledwolf]

Problem

The sse4 worker reads EPSILON (default 0) and floors it to 1e-6 regardless of the Hamiltonian. The per-bond diagonal constant is c(type) = epsilon + max_diag_me(type), so the vertex carrying the maximum diagonal matrix element is inserted with weight c − me = epsilon ≈ 1e-6.

On a sign-problematic (frustrated / non-bipartite) Hamiltonian this makes the diagonal update effectively non-ergodic: the operator-string sampler freezes, the expansion order ⟨n⟩ is undersampled, and the simulation reports a confidently wrong, seed-dependent energy with small error bars. The constructor already warns about exactly this case ("make sure that EPSILON is ergodic") but proceeds with the non-ergodic floor.

Fix

The SSE energy estimator is invariant to EPSILON (a constant shift of the diagonal vertex weights), so when EPSILON is unset and the model is signed, default it to the largest diagonal matrix element. That gives the maximum-diagonal vertex an O(1) insertion weight and restores ergodicity, auto-scaling with the model.

• Sign-free models keep the previous 1e-6 floor bit-identically (they are ergodic at EPSILON=0, and a larger shift would only inflate the expansion order) — existing unfrustrated results are unchanged.
• An explicit EPSILON still overrides everything, as before.
• The warning is reworded into a note describing the applied default.

How to reproduce

Save as parm (a 3×3 periodic-boundary Heisenberg lattice — "square lattice" in lattices.xml is periodic — at β=1; no EPSILON set):

LATTICE="square lattice"
MODEL="spin"
local_S=1/2
J=1
L=3
W=3
T=1
THERMALIZATION=20000
SWEEPS=200000
SEED=42
{}

parameter2xml parm
dirloop_sse parm.in.xml
# Energy is in parm.task1.out.xml / parm.task1.out.h5
# (simulation/results/Energy and .../Sign)

Exact thermal reference for this lattice at β=1: ⟨H⟩ = −2.6525 (checked with two independent exact diagonalizations).

• on master: ⟨H⟩ = −2.42 ± 0.02 — ~13σ from exact, seed-dependent (and the run prints the existing "make sure that EPSILON is ergodic" warning before proceeding anyway)
• with the fix (still no EPSILON set): ⟨H⟩ = −2.642 ± 0.017 — within 1σ of exact

Chains and open 2-D/3-D (sign-free) lattices produce bit-identical results before/after, since the new default only engages when is_signed().

Provenance

Root-caused in a downstream ALPS modernization fork while chasing wrong SSE energies on periodic 2-D lattices; instrumentation first refuted a bond-counting hypothesis and then identified the frozen diagonal update. Locked there against ED.

[egull]

Assigning @LodePollet with reviewers @Ooolab and @marcusr2ML . This is the SSE4 code. Technically falls under Lode's umbrella; @LodePollet let us know if you're comfortable with that code, I see it's been authored exclusively by Sergei Isakov.

[marcusr2ML]

@egull (AI generated synopsis) Verified locally, independent of the numbers in the PR description.

Built both master (unpatched) and fix/sse-epsilon-ergodicity, ran the exact repro parm from this PR on each:

Master (unpatched):

• 22,714,050 measurements
• ERROR converged="no"
• Autocorrelation ~3e4–5e4
• Energy still drifting (~−2.38), off from exact ED (−2.6525) even after that many samples

Fix (fix/sse-epsilon-ergodicity):

• 300,591 measurements
• ERROR converged="maybe" (±0.015)
• Autocorrelation ~0.3–0.4
• Energy = −2.64621, within ~0.4σ of exact

This confirms the core claim: the old EPSILON floor breaks ergodicity on this frustrated lattice (huge autocorrelation, non-converging chain no matter how long you run it), and the fix restores it — autocorrelation collapses ~5 orders of magnitude and the estimator converges in a fraction of the samples.

LGTM from a correctness/repro standpoint.

[egull]

@marcusr2ML I'd still like @LodePollet to take the lead here. I don't know the sse code well. It all looks good, but we need a human in the loop who's familar with the design decisions that went into this in the first place.

[egull]

merging in master so we can profit from a cmake.verbose fix that makes the builds pass.

[LodePollet]

will look into it.

[Ooolab]

I don't think we could overcome sign problem by simply changing the constant EPSILON value. I would say if the sign problem is severe the effective number of samples from the simulation is still limited. But I will approve this, since at least something is tuned to check the sign average.

[skilledwolf]

Agreed—this does not mitigate the sign problem or increase the effective sample count after sign reweighting. It only prevents the diagonal update from freezing because the maximum-diagonal vertex has an approximately zero insertion weight.