In FRI Linear, the LB cost function is not convex.

[MaartenHilferink]

This cannot be correct, as relaxed optimization should ressult in a convex function

[MaartenHilferink]

Two problems mixed into one curve; FRI is being re-swept on the current data

You are right that the LP bound must be convex — the sweep traces the lower convex envelope of a parametric LP, and any point above the chord of its neighbours is not the same LP. That is exactly what happened: the FRI LINEAR curve on p46 is the union of two different problems.

What the chart is made of

build_deck_data.py takes an area's frontier rows from its last full sweep log and, since #52, adds the rows of the refine-only run (the S1/S2 bisection points) at λ values the sweep did not solve. For FRI those two runs are not the same LP:

	full sweep (logs/sweep_FRI_LINEAR.log)	refine (logs/refine_FRI_LINEAR.log, 11 Sep)
run	22 July, scratch/run_fri_protect.ps1	11 Sep, run_resweep_batch.ps1 -RefineOnly
candidate set	6,765 of 17,141 (LOCATION_SELECTION_FACTOR=3, baseline-protected stride)	17,133 (full)
solver, w_max	IPM, 0.5	dual simplex, grid
existing-side OD	327,370 rows, 6,052,430 residents	327,285 rows, 6,048,670 residents
baseline	1,584 cells, 27,489,201	1,583 cells, 26,839,141

So the grey "LB" alternates between the July subsampled frontier (higher travel at a given count, because two thirds of the candidates are missing) and the September full-set frontier — the bumps at sum_y ≈ 1,070–1,650 are the September points sitting below the July chord, and λ is not even monotone along the curve (0.109 → 0.115 → 0.119 → 0.123). Chart-level symptom, data-level cause.

Why FRI in particular

FRI was the one area whose July sweep used the candidate subsample (it was the slow one then, hence IPM + factor 3 + w_max 0.5 in run_fri_protect.ps1). Every other area's full sweep ran on the full candidate set, so their refine points join a frontier of the same problem. And FRI's July log predates the 2 Sep landbody rebuild: the rebuilt FRI OD differs slightly (85 existing-side rows, 8 candidates), which is why the baselines differ too.

Fix

FRI is being fully re-swept on the current arrows with the full candidate set, both cost functions, with the current sweep (S1/S2 pinned inside the sweep, tail stop): task NM_fri54, ~4–6 h. build_deck_data.py will then take its frontier and its S1/S2 from that sweep alone (the refine log is older), and the deck, the README numbers and the #45/#48 files follow.

What this exposed for the other areas — your call

Checking every area the same way: 16 more areas have a July full sweep whose OD differs slightly from the 2 Sep rebuild (Estonia, FRC, FRD, FRE, FRF, FRG, FRH, FRJ, FRK, FRL, FRM, PL2, PL4, PL5, PL6, SE1 — a few dozen to, for SE1, 3,500 OD rows out of 1.6 M). The 2 Sep diff had called them unchanged. Their refine points therefore also come from a marginally different LP; the resulting kinks are ≤ 1.5 % (FRH), invisible in the charts, and their S1/S2 are pinned on the current data. Re-sweeping them fully for a clean frontier is 32 runs, roughly 20 h on four workers with the current sweep. I have not started that; say so and I will.

[MaartenHilferink]

Fixed — FRI re-swept on the full candidate set; the bound is one problem again

FRI was fully re-swept on the current arrows with the full candidate set (17,133), both cost functions, one worker: LINEAR 2.2 h, LOGISTIC 1.9 h. Both scenarios pinned inside the sweep:

	S1 — today's 1,583 cells	S2 — today's travel
LINEAR	w = 0.088289, Σy = 1,582.1	w = 0.12419, travel +0.15 %
LOGISTIC	w = 0.00093708, Σy = 1,581.1	w = 0.0014768, travel −0.12 %

The LINEAR lower bound has no point above the chord of its neighbours any more (22 rows; λ and Σy monotone). build_deck_data.py takes FRI's frontier and its S1/S2 from this sweep alone — the July subsampled rows and the September refine points are out of the curve.

What moved. FRI's S2 (same travel, fewer locations) read −232 locations (−14.7 %) off the mixed curve and reads −364 (−23.0 %) off the clean one: the July subsample, missing two thirds of the candidates, had a frontier too far from the axis, and the interpolated S2 sat on it. S1 is unchanged (−3.8 M min, −14.2 %, λ 8,824); λ at S2 goes 10,268 → 12,369. LOGISTIC is unchanged (−428 locations, −27.0 %). In the S2 column FRI leaves the bottom of the French regions (−14.7 %, beside Île-de-France's −15.1 %) for the pack (the other eleven sit at −19 to −24 %, Corse −30 %). The FRI slide (p41), the tables on p62–63, README and the #45/#48 files are regenerated in 3e6e5b3 (216ac77's zips are superseded by s1s2_open_locations_20260915.zip and issue48_frontier_data_20260915.zip).

Two things the check turned up

The subsample is history, not just for FRI. The README said "the largest areas are candidate-subsampled". Checked against the candidate arrows: every one of the 88 current sweeps runs on the full candidate set (M = the arrow's count in all of them). The July PL8 subsampled sweep was superseded on 2 Sep, FRI's now. README and the roadmap slide say so; the knob stays as a scale test.

A tail stop can cap the aggregate. FRI LOGISTIC's sweep stopped at w = 0.002: the next grid point, 0.005, did not solve within the hour from the post-bisection basis (925k iterations, still converging). The aggregate frontier is the sum over areas on the w-range every area covers, so FRI capped it at 0.002 — just below the aggregate's own S2 (w ≈ 0.00212), which then did not bracket. A tail-only mode now continues a finished sweep's grid with a longer limit and without touching its S1/S2 (run_resweep_batch.ps1 -TailFrom 0.001 -TailTo 0.005 -TailLimit 14400; rows in logs/tail_<area>_<FUNC>.log, merged by build_deck_data.py). Run for FRI LOGISTIC: 0.001 from cold and 0.002 reproduce the sweep's rows exactly, 0.005 solved in 55 min (Σy 558, relax 883,045). The aggregate LOGISTIC frontier runs to w = 0.005 again and both scenarios bracket: S1 51,372 locations at w = 0.00113, S2 33,530 at 0.00212 (LINEAR: 51,637 / 35,813).

Not in the chart: the rows' mean travel time

While rebuilding the deck data: a sweep row's mean_t counted a stranded client (no open facility in its choice set) at 0 min, the baseline's at the 120-min cutoff — cost_c, which selects S1/S2, always priced both at BIG, so the pinning is untouched, but the "Δ mean t" beside the LOGISTIC S1 column compared two conventions. Fixed in lp_run.jl; for the existing logs doc/recompute_mean_t.jl recomputes every rounded row and S1/S2 from its per-λ traveltime arrow (2,289 rows; 162 whose arrow a later run overwrote keep the logged value). The effect is bounded by the stranded population: at most +0.17 min on an S1/S2 (SE3 LOGISTIC S2), 16 of 176 scenario values move by more than 0.01 min; the LOGISTIC S1 "Δ mean t" for SE2 goes −1.6 → −1.5 min, nothing else in the tables changes at one decimal.

The other 16 areas

Unchanged from the previous comment: Estonia, FRC–FRM (except FRI), PL2/4/5/6 and SE1 have July sweeps on arrows that differ slightly from the 2 Sep rebuild (kinks ≤ 1.5 %, S1/S2 pinned on the current data). A clean re-sweep is 32 runs, ~20 h on four workers. Not started.

[MaartenHilferink]

The other 16 areas are re-swept too — every frontier in the deck is one LP on the current arrows

Estonia, FRC, FRD, FRE, FRF, FRG, FRH, FRJ, FRK, FRL, FRM, PL2, PL4, PL5, PL6 and SE1: 32 full sweeps on the full candidate set, 4 workers, 9.9 h of compute (15–16 Sep, around two machine restarts), 32 OK. Checks on the new logs: no lower bound has a point above the chord of its neighbours (the FRI symptom is gone everywhere), S1 within 0.5 % of today's count (FRM 1.15 % = one cell of 87), S2 within 0.25 % of today's travel; the S1 w's equal the September refine points exactly, the S2 w's are within 1 % of them — so the refine had pinned the right points, only the curves around them were mixed.

What moved: last-decimal changes in 14 areas (S2 within ±2 locations); SE1 LOGISTIC a little more (S1 −14.6 → −15.6 %, S2 −183 → −189 locations, λ at S2 702 → 759 — its July frontier was the roughest). Aggregate over 43 areas: LINEAR S1 51,640 locations / −23.6 % travel, S2 35,992 / −29.9 %; LOGISTIC S1 51,362 / −9.7 %, S2 33,350 / −35.1 % — the same story at one decimal.

Deck, README, deck data and the #45/#48 files regenerated in 660e5c3 (s1s2_open_locations_20260916.zip, issue48_frontier_data_20260916.zip supersede the 15 Sep ones). Nothing further is pending on this issue from my side.