Expand description
User-facing application object — port of Interfaces/IpIpoptApplication.{hpp,cpp}.
§Crate placement
IpoptApplication lives in pounce-algorithm (rather than
alongside the other Interfaces-side ports in pounce-nlp) because
optimize_tnlp needs to drive the full IPM: it constructs a
TNLPAdapter + OrigIpoptNlp (from pounce-nlp) and hands the
NLP off to an IpoptAlgorithm (this crate). pounce-nlp cannot
depend on pounce-algorithm (the reverse already exists), so
orchestration must live on the algorithm side. Public callers
continue to import via pounce_algorithm::IpoptApplication.
optimize_tnlp routes every problem — constrained or not —
through the same primal-dual IPM, exactly as upstream Ipopt does:
it builds the algorithm via crate::alg_builder::AlgorithmBuilder
(default backend MA57 from pounce-hsl) and runs
IpoptAlgorithm::optimize.
Structs§
Functions§
- default_
backend_ factory - Default symmetric linear-solver factory, parameterized by the
pounce-extension FERAL knobs read off the application’s
OptionsList. - default_
backend_ factory_ with_ sink - Sink-aware variant of
default_backend_factory. Identical dispatch, but the FERAL backend is constructed with aLinearSolverSummarysink soIpoptApplicationcan read out aggregate post-mortem stats (factor counts, fill ratio, extremal pivots, final inertia) after the solve returns. MA57 ignores the sink — the HSL backend doesn’t carry the same instrumentation yet. - feral_
config_ from_ options - Read the
feral_*extension options offoptions, falling back to the env-var defaults baked intopounce_feral::FeralConfig::from_envfor any knob the caller did not set explicitly. The returned config is what every default-factory invocation (main IPM and restoration sub-IPM) consumes.
Type Aliases§
- Converged
Callback - Callback fired by
IpoptApplication::optimize_constrainedonce the IPM has converged (statusSolveSucceededorSolvedToAcceptableLevel) and before the user TNLP’sfinalize_solutionruns. Receives borrowed handles into the algorithm’s converged state. - Restoration
Factory - Factory that constructs a fresh restoration-phase strategy on
demand. The outer algorithm owns at most one restoration object,
so the factory is invoked once per
optimize_tnlpcall. The factory isFnMutto allow callers to capture a builder that internally reuses caches across builds. - Restoration
Factory Provider - Provider that mints fresh
RestorationFactoryinstances on demand. Used by drivers that need to run the inner IPM more than once peroptimize_tnlpcall — notably the Phase-3 ℓ₁-exact penalty-barrier outer loop (pounce#10), which the existingRestorationFactorycannot support because pounce’s defaultmake_default_restoration_factoryis a one-shot. Callers wire this viaIpoptApplication::set_restoration_factory_provider.