[olivier-lacroix]

Closes #768. Interested in having rolling horizon patterns in linopy.

• I used the original proposition in terms of method naming. This can be changed to whatever people prefer.
• My first attempt at this sliced each container individually. This allowed to work on the windowed model as on a normal model, but required a lot of code, and was kind of slowish.

Note

The following content was generated by AI.

What

Model.restrict returns a WindowModel backed by a slice of the parent's
flattened A, b, c, lb and ub. A window is a row slice plus a column
range; terms whose variables fall outside the window are folded into the RHS at
their actual matrix coefficient. No container is rebuilt.

window = model.restrict(snapshot=sns[:24], fix={"soc": initial})
window.solve(solver_name="highs")

for start in range(24, len(sns), 24):
    window.advance(snapshot=sns[start : start + 24], fix={"soc": initial})
    window.solve(solver_name="highs")

• window.matrices exposes the window arrays, with the parent labels of its rows and columns.
• window.solution and window.dual are Datasets, materialised per container on access, with column, row and objective scaling undone.
• window.solve builds the native model from the window and updates it in place through ModelDiff.from_windows and each backend's existing _apply_* hooks. A backend without in-place updates rebuilds, and logs a warning; pass disallow_rebuild=True to raise instead.
• window.advance re-slices the parent; a shape change rebuilds the solver.

Semantics

• Folding uses the real matrix coefficient, as specified in Design: Model.restrict / advance — slice a model along a coordinate and condition on boundary values (rolling horizon) #768.
• A window that cuts a coupling without fix raises RestrictionError, naming the constraints. A NaN at a dangling label counts as missing.
• Rows that lose every term are checked for feasibility and dropped when satisfied.

Limits

• One selected dimension; several raise.
• Every carrier of the selected dimension must contain the selected labels.
• Indicators and quadratic objectives raise; native SOS raises; piecewise works; reformulated SOS still fails on its horizon-wide cardinality row.
• A window is not a Model: it cannot take new constraints.

Benchmark

Build plus solver assembly, optimisation excluded. 35040 steps, a 1460-step
window, 24 chunks, three variables and three constraints.
hyperfine --warmup 1 --runs 5:

route	wall	peak RSS
full horizon	514.7 ms ± 7.4	202.6 MiB
chunked rebuild	1236.3 ms ± 11.1	170.2 MiB
restrict + advance	532.3 ms ± 4.6	190.7 MiB

Windowing costs 3.4% over one full build and avoids 24 rebuilds. In-process,
excluding import overhead: 0.170, 0.938 and 0.171 s.

Benchmark script

import sys
import time

import numpy as np
import pandas as pd

import linopy
from linopy.solvers import Solver

N, W = 35040, 1460
route = sys.argv[1] if len(sys.argv) > 1 else "full"


def build(index, prices):
    model = linopy.Model()
    x = model.add_variables(lower=0, coords=[index], name="x")
    y = model.add_variables(lower=0, upper=100, coords=[index], name="y")
    z = model.add_variables(lower=0, coords=[index], name="z")
    model.add_constraints(y - 0.99 * y.shift(time=1) - x + z == 0, name="balance")
    model.add_constraints(x + z <= 50, name="cap")
    model.add_constraints(z - 0.5 * x >= 0, name="mix")
    model.add_objective((prices * x + 0.1 * z).sum())
    return model


def assemble(model):
    Solver.from_name("highs", model=model, io_api="direct")


index = pd.RangeIndex(N, name="time")
prices = pd.Series(np.sin(np.arange(N) / 50), index=index)
fix = {"y": pd.Series(np.zeros(N), index=index)}

start = time.perf_counter()
if route == "full":
    assemble(build(index, prices))
elif route == "chunked":
    for offset in range(0, N, W):
        chunk = index[offset : offset + W]
        assemble(build(chunk, prices.loc[chunk]))
else:
    window = build(index, prices).restrict(time=index[:W], fix=fix)
    for offset in range(W, N, W):
        window.advance(time=index[offset : offset + W], fix=fix)
    assemble(window.as_model_view())

print(f"{route}: {time.perf_counter() - start:.3f}s")

Solver support

Only HiGHS has been exercised by hand. test_window_solve_across_solvers runs
the same recipe on highs, gurobi, cplex, scip, xpress and mosek, skipping
solvers that are absent, file-only, or installed without a license.

solve_window requires io_api="direct". A file-based backend would have to
write the window to disk on every solve, and has no in-place update.

Tests

test_restrict_matrix.py and test_windowing_integration.py, including a solver-parametrized run of the window recipe. linopy/restrict is at 100% statement and branch coverage.

AI assistance

Drafted with Claude Code: the implementation, tests and benchmark. Reviewed by hand before opening.

[codspeed]

Merging this PR will not alter performance

✅ 181 untouched benchmarks
⏩ 181 skipped benchmarks¹

---

_{Comparing olivier-lacroix:feat/restrict-matrix-windows (9a2af9d) with master (ae80bc8)}

Footnotes

1. 181 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[olivier-lacroix]

I'll resolve typing issues

Edit: done

[FabianHofmann]

@olivier-lacroix thanks for the PR! I now start to have more time to look into other things in linopy. there were some major features which kept me buisy. will take a look at this soon

[olivier-lacroix]

@FabianHofmann no worries! I can see the big cleanup happening 😄

[olivier-lacroix]

Rebased onto master at 8736b35 (2026-10-29).

Benchmark rerun on the rebased branch, 5 runs, median:

route	wall	peak RSS
full horizon	22.1 ms	200.1 MiB
chunked rebuild	209.7 ms	168.5 MiB
restrict + advance	32.4 ms	185.5 MiB

Windowed assembly now costs 47% over one full build (for that small bench). Restrict still costs 6.5x less than 24 rebuilds.

[codspeed]

Unable to generate the performance report

Your organization has exceeded its Macro Runners budget. Because this run uses tokenless mode, CodSpeed needs to wait for the GitHub Actions workflow to complete to validate the upload. Since the walltime jobs will never run, the workflow stays pending and we are unable to process this run.

To run these benchmarks again, update your plan or increase your Macro Runners budget.

If you need help, please contact us at support@codspeed.io or on Discord.

[FabianHofmann]

@olivier-lacroix I would push here if you don't mind?

[FabianHofmann]

still have a major refactor outstanding

[olivier-lacroix]

Yes of course @FabianHofmann, go for it.