Repeated solves and parameter updates
Scenario studies, time series and sensitivity experiments all solve related problems, but they do not necessarily share one model. Choose the workflow before trying to reuse solver state. These workflows need JuMP and a suitable optimizer; DiffOpt is needed only when requesting derivatives through DiffOpt.
Choose what is shared
| What changes or couples? | Workflow | Detailed guide |
|---|---|---|
| Network data or independent operating scenarios | Materialize each case/snapshot and build its model. This is the simplest baseline. | Case families, time series. |
| Supported coefficient values in an already parameterized model | Update the registered JuMP parameters and follow the cached-model reset/re-solve workflow. | Updating parameters and resolving, resolve_opf!. |
| Topology, dimensions, device ownership or voltage-domain certificates | Rebuild the model; a coefficient update does not reconstruct these choices. | Staged construction, device replacement. |
| Decisions coupled between time periods | Build multiple contexts into one model, add coupling constraints and solve jointly. | Multi-period and storage construction, coupled-snapshot example. |
Updating the source network dictionary alone does not update an already built JuMP model. For a parameterized path, the coefficient-provider reference defines which quantities remain symbolic. A parameter that currently equals zero is still a parameter; see substitution boundaries.
Reuse needs a fresh solution check
The canonical update workflow documents a measured stale-evaluation failure and the tested resolve_opf! workaround. It owns the code recipe, version-specific evidence, cached/direct-model distinction, and reset behavior; follow it rather than assuming another call to optimize! invalidates all numerical caches.
The reset preserves JuMP handles and algebra but reloads the optimizer. It does not retain numerical factorizations. By default resolve_opf! warm-starts from the previous feasible solution (primal and dual values, plus Ipopt's warm-start options); pass warm_start=false for a cold re-solve from the build's own initialization. A warm start steers the solver toward the previous operating point but does not decide which local solution it reaches. Check the solution against the updated parameters and physical laws. A successful termination status alone is insufficient.
For sensitivity studies, the DiffOpt example compares analytic, forward, reverse and finite-difference derivatives on one selected local solution branch. For experiment logs, use research provenance at appropriate checkpoints. For changes in base policy or initialization, return to Scaling, initialization and diagnostics.