-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
What version of OR-Tools and what language are you using?
Version: 9.15.6755
Language: Python
Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)?
CP-SAT
What operating system (Linux, Windows, ...) and version?
Linux
What did you do?
We implement a lazy constraint generation loop: solve the model, analyse the solution for constraint violations, add new NewOptionalIntervalVar + AddNoOverlap constraints for the violated paths, then re-solve the same model. The model proto is reused and grows between iterations.
from ortools.sat.python import cp_model
model = cp_model.CpModel()
for iteration in range(6):
solver = cp_model.CpSolver() # fresh solver each iteration
solver.parameters.num_search_workers = 8
status = solver.Solve(model)
if status not in (cp_model.OPTIMAL, cp_model.FEASIBLE):
break
violations = detect_violations(solver, model)
if not violations:
break
# Add new intervals + NoOverlap for violated paths
for path in violations:
intervals = []
for arc in path.arcs:
iv = model.NewOptionalIntervalVar(
start, size, end, presence, f"path_{path.id}_{arc.id}"
)
intervals.append(iv)
model.AddNoOverlap(intervals)
# Warm-start from previous solution
model.ClearHints()
for i, var in enumerate(model.proto.variables):
if var.name:
v = model.get_int_var_from_proto_index(i)
model.AddHint(v, solver.Value(v))What did you expect?
Each re-solve completes successfully, producing a feasible or optimal solution on the incrementally-constrained model.
What happened instead?
The process crashes consistently around iteration 3–4 with:
terminate called after throwing an instance of 'std::out_of_range'
what(): absl::btree_map::at
Pattern observed from production logs:
│ Iteration │ Variables │ Constraints │ New violations │ Result │
│ 0 │ 14,050 │ 30,637 │ 1 │ FEASIBLE │
│ 1 │ 14,204 │ 30,946 │ 3 │ FEASIBLE │
│ 2 │ 15,326 │ 33,193 │ 2 │ FEASIBLE │
│ 3 │ 15,766 │ 34,075 │ — │ CRASH │
The crash is non-deterministic (depends on thread scheduling) but highly reproducible (~80% crash rate on iteration 3 or 4).