Support for Warm-Start / Resume From Existing Solution in Strip Packing

[mathurinadvanthink]

@JeroenGar
Follow this conversation JeroenGar/sparrow#124

Currently, StripPackingInstance.solve() always starts the search from scratch with no option to:

provide an initial solution (e.g., a previously found layout),

resume from a partially explored state,

or influence the solver using a known good arrangement as a starting point.

For large item counts (N > 50), this would be extremely useful, because:

most runs converge to similar solutions with the same seed,

improvements become very rare even with long computation times,

a previously found “good but not optimal” solution could guide the solver away from repeatedly exploring the same local minima.

Proposed API Idea (High-Level)

For example:

fn solve_with_initial( &self, initial_solution: &StripPackingSolution, config: &StripPackingConfig, ) -> StripPackingSolution
Or on the Python side (spyrrow):

instance.solve(initial_solution=my_previous_solution, config=cfg)
Alternatively, a resume() function using an exported intermediate state would also work.

It would greatly improve solver diversity and final packing quality.

It would allow iterative refinement loops (reduce strip height → resume → refine).

It would reduce total compute time for users exploring stepwise height decreases.

It aligns with workflows in industrial cutting & nesting applications.

Thank you for your help.

[PaulDL-RS]

Thank you for your interest and sorry for the late reply.

I will go further with it when the implementation in sparrow is ready.

I quite like the idea of an optional keyword argument initial_solution for the solve function.

But an argument could be made that 2 methods is a better idea to minimize the scope of each. I will need to see the underlying implementation of sparrow and i will probably mirror it.

[mathurinadvanthink]

Thanks a lot for your reply, and no worries at all about the delay 🙂

I’m glad the idea of an initial_solution resonates with you. From my perspective, both approaches make sense, but I tend to agree with your point about having two separate methods if it helps keep responsibilities and scope clearly defined at the API and implementation levels.

In the use cases I have in mind (successive iterations, progressive strip-height reduction, run diversification), the key aspect is really the ability to re-inject an existing solution in a clean way, without necessarily exposing too much internal state.
An explicit solve_with_initial(...) or resume(...) API would fit that need very well.

I also understand the rationale for aligning with sparrow’s implementation; keeping consistency between the Rust and Python layers sounds like a very good approach.

Thanks again for being open to the discussion — this would be a high-impact feature 👍

[JeroenGar]

I am working on adding the ability to warm-start sparrow by loading it with a solution file instead of an input file, effectively warm-starting the optimization.

Once it's ready, this should provide sufficient information to add a similar (or more enhanced) version of this feature to spyrrow.

[mathurinadvanthink]

Thank you

[JeroenGar]

I have merged the feature into the main branch of sparrow.

See this PR: JeroenGar/sparrow#125

[mathurinadvanthink]

I confirm, thank you.