Module batch 

Batched NLP solving (pounce#126) — N independent NLPs on a rayon pool.

The NLP analog of pounce-convex’s solve_qp_batch / solve_qp_batch_parallel: solve a batch of independent problems (parametric sweeps, multi-start, branch-and-bound node relaxations) and return one result per input, in input order. Each instance runs the full filter-IPM end-to-end via its own IpoptApplication.

Parallelism model: outer-parallel, inner-serial

Same rationale as the QP batch (pounce-convex/src/batch.rs): each NLP solve is fully independent, so the batch is embarrassingly parallel across instances — but the default FERAL factorization backend is itself rayon-parallel within a factor, and running both levels oversubscribes the cores. solve_nlp_batch_parallel therefore builds everything per worker, and the configure hook should install an inner-serial linear-solver backend; install_serial_feral_backend does exactly that (it honors the app’s feral_* options, forcing only parallel = off — a per-backend setting, not global state). Unlike the QP batch, NLP instances converge in wildly different iteration counts; that is fine for thread-per-instance rayon (a converged instance frees its worker — no lockstep), and no cross-instance KKT-structure sharing is attempted because general-NLP sparsity may differ per instance.

Construction happens on the worker

pounce-nlp’s solver plumbing is single-threaded (Rc<RefCell<…>>), so nothing solver-side crosses a thread boundary: each worker receives one owned T: TNLP + Send (e.g. a pounce_nl::nl_reader::NlTnlp, which is Send since its CSE nodes went Arc), constructs its own IpoptApplication inside the worker closure, and only the plain-data NlpBatchResult comes back.

The configure hook

pounce-algorithm cannot depend on pounce-restoration (the dep edge runs the other way), so the per-worker application is handed to a caller-supplied configure closure that should, at minimum, mirror what single-solve drivers do: set options, then install a linear-backend factory and a restoration-factory provider. Without a restoration provider an instance that needs the restoration phase returns RestorationFailure instead of recovering — same as a bare IpoptApplication. See pounce-cli’s solve setup or pounce-py’s Problem::prepare for the full recipe.

Structs

FeralBackendPool

Per-thread pool of serial FERAL backends for identical-sparsity batches (the issue-#126 “optional later optimization”: reuse the symbolic analysis across instances).

NlpBatchResult

Outcome of one instance of a batched solve.

NlpBatchSolution

Final iterate of one batch instance, captured from the finalize_solution callback (owned copies of the borrowed buffers).

NlpWarmStart

Per-instance warm-start iterate for solve_nlp_batch_parallel_warm: primal point plus the three dual vectors the IPM’s warm-start initializer consumes via TNLP::get_starting_point. Build one from a previous batch’s NlpBatchSolution (the From impl) for MPC / sequential-chaining workloads.

Functions

install_pooled_serial_feral_backend

Install a backend factory drawing from pool — the identical-sparsity batch optimization (see FeralBackendPool for the reuse semantics and the determinism caveat). Call from configure instead of install_serial_feral_backend.

install_serial_feral_backend

Install an inner-serial FERAL backend on app, honoring any feral_* options already set (read the options before calling this if configure sets them — i.e. set options first, then call this). The parallel = off toggle is per-backend; concurrent solves on other threads are unaffected.

solve_nlp_batch

Solve a batch of independent NLPs sequentially, returning one result per input in input order. configure is called once per instance (receiving the instance index, so per-instance options are possible) on a fresh IpoptApplication (set options / backend / restoration there — see the module docs). Predictable and contention-free; the right choice when each instance is large enough that the linear-solver backend parallelizes internally.

solve_nlp_batch_parallel

Solve a batch of independent NLPs in parallel across instances on rayon’s global pool, returning one result per input in input order regardless of completion order. Best for many small / medium instances where cross-instance throughput beats parallelizing each factor internally.

solve_nlp_batch_parallel_warm

Warm-started parallel batch: like solve_nlp_batch_parallel but each instance is seeded from the corresponding entry of warms — typically the previous step’s NlpBatchSolutions for a sequence of nearby batches (receding-horizon MPC, sequential parameter continuation, B&B dives). The NLP analog of the QP batch’s solve_qp_batch_parallel_warm.

solve_nlp_batch_warm

Warm-started sequential batch — solve_nlp_batch seeded per instance from warms. See solve_nlp_batch_parallel_warm for the warm-start contract (option forcing, dimension-mismatch fallback).