v2.1.0-beta — dependency upgrade, CTLie integration, test rework

[ocots]

Objective

Bring OptimalControl back onto the current ecosystem. The package has been pinned at CTBase = "=0.18.8" / CTModels = "=0.10.1" while every dependency below it was restructured. This issue tracks the upgrade, the addition of CTLie as a new dependency, and the test rework that goes with them.

Out of scope, deliberately: docs/. A separate documentation PR follows — expect ~24 stale pages after this lands.

Why now

Two independent things happened underneath us.

The whole ecosystem adopted the Handbook modules.md rule — the package top level exports nothing, each submodule owns its API. Names are still reachable through the package root, so most imports don't break, but they are non-compliant and would break silently on the next internal move.

Three families of symbols physically changed package, and those do break:

Was	Is now
CTSolvers.{Options, Strategies, Orchestration}	CTBase.*
CTFlows.{Hamiltonian, HamiltonianVectorField, VectorField}	CTBase.Data.*
CTFlows.{Lift, Poisson, ∂ₜ, @Lie}	CTLie.*
CTDirect.{AbstractDiscretizer, discretize}	CTSolvers.DOCP.*

45 of the ~180 symbols in src/imports/ no longer resolve where we look for them.

What changes for users

Three groups, all going into BREAKING.md:

1. Differential geometry — Lie(X, f) → ad(X, f); X ⋅ f → ad(X, f), removed with no alias; HamiltonianLift → CTLie.LiftedHamiltonianFunction, and it is no longer <: AbstractHamiltonian.
2. Flow calls — the variable is now a mandatory keyword on NonFixed problems (f(t0, x0, p0, tf; variable=λ), no positional slot); augment= → variable_costate=; constrained flows take constraint=/multiplier= keyword pairs instead of three positional functions; constructor keywords gain the is_ prefix.
3. Flow now requires an integrator using — using OrdinaryDiffEq (or OrdinaryDiffEqTsit5) alongside using OptimalControl. This is a deliberate choice, see below.

There is also new API worth exposing that we don't re-export today: the whole CTBase.Data type vocabulary the user writes flows against (OpenLoop, ClosedLoop, DynClosedLoop, PathConstraint, Multiplier, PseudoHamiltonian, …), plus method = :cpu | :gpu on every Flow constructor — so :cpu/:gpu finally means the same thing on the direct and the indirect side.

Two decisions worth surfacing here

Name collisions were resolved upstream, not arbitrated. 49 names are exported by more than one submodule. Rather than picking winners in OptimalControl — which would have been type piracy — the two families that were genuinely one concept were unified in their owning packages: state/control/costate/objective/time_grid and status/successful now extend the CTModels generics. Measured before/after: 23 → 31 shared generics, 26 → 18 distinct. times was deliberately not unified (CTModels' returns a TimesModel component, CTSolvers' a time grid).

Flow needs an integrator using. Keeping SciMLBase, DiffEqBase and OrdinaryDiffEqTsit5 as hard dependencies costs 35 packages, 40 % of the dependency graph, to save the user a single using. Measured, not guessed. Moving them out makes the story uniform with what we already do: you load a solver to solve, Plots to plot, an integrator to integrate.

Upstream — all clear

Both original blockers were released before this work started:

• CTSolvers.jl#187 → 0.4.33-beta
• CTFlows.jl#370 → 0.16.1-beta

A third surfaced mid-migration and is now also resolved:

• CTBase.jl#515 — OpenLoop should be unconditionally non-autonomous → shipped in CTBase 0.28.9-beta. Companion fix for CTFlows' own call sites: CTFlows.jl#378.

Non-blocking and tracked separately: CTFlows.jl#368, CTFlows.jl#369, CTSolvers.jl#189.

Tests

4 files needed substantive rewrites, 13 needed path fixes, and the new work roughly doubles test/problems/:

• indirect and direct problems written both with @def and with the functional API, behind one interface so a single test body runs twice — seeded from the 25 indirect problems with reference solutions in CTFlows.jl/test/suite/integration/;
• 1-D = scalar contract tests per Handbook/philosophy/dimension-and-shape.md, through both paths;
• the flow API surface of the new call convention, control-law kinds, constrained flows and pseudo-Hamiltonians — previously zero coverage;
• CPU/GPU routing assertions (CPU-runnable) plus guarded device runs, gated behind the kkt self-hosted runner.

Full local suite is green: 2167 passed / 2 broken (expected downstream skips) / 0 failed, ~26 min.

Progress

• 0 — upstream unifications released
• 1 — Project.toml: compat, CTLie, extension triggers; .extras pins dropped. Pkg.resolve() clean, direct deps 21 → 17
• 2 — rewrite src/imports/ (+ ctlie.jl, adnlpmodels.jl) and add the extension-arming imports
• 3 — patch src/helpers/ + src/solve/ (~15 sites)
• 4–9 — test rework (paths, reexports, indirect, dual-form problems, flows, shape)
• 10 — BREAKING.md + CHANGELOG.md
• 11 — coverage review

All done. See #826 for the full PR.

---

Full analysis — migration map, API specification, decisions Q1–Q8 with their rationale, and the step-by-step work order — follows in a comment.

[ocots]

OptimalControl v2.1.0-beta — dependency upgrade, CTLie integration, test rework

Date: 2026-07-28, updated 2026-07-30 · Branch: feat/upgrade-v2.1.0-beta ·
PR: #826 (draft)
Status: steps 0–10 done and green (§12); step 11 (coverage review) still open. All design
questions settled — see the Remarks for what surfaced after this plan was written.
Scope: Project.toml compat · src/ (imports + helpers + solve) · test/ · add CTLie
Out of scope (deliberate): docs/ — a separate documentation PR follows.

How to read this. Part I is the state of the world and the decisions — that is the
source for the tracking issue. Part II is the change specification, the reference to keep
open while implementing. Part III is the work order, the source for the implementation plan.

This is a consolidated rewrite. The incremental analysis log that produced it — including
the wrong turns and their corrections, which are worth keeping so they are not re-derived —
is archived at archive/upgrade-v2.1.0-beta-v1-analysis-log.md.

---

Part I — State and decisions

1. Executive summary

OptimalControl sat pinned at CTBase = "=0.18.8" / CTModels = "=0.10.1" while the whole
ecosystem was restructured around the Handbook's modules.md rule — the package top level
exports nothing; each submodule owns its API. On top of that, three families of symbols
physically changed package. This PR closes that gap.

What it involves, in order of size:

1. src/imports/ is the epicentre. 45 of the ~180 imported symbols no longer resolve at
   the path OptimalControl uses. Two files (ctflows.jl, ctsolvers.jl) are rewrites;
   ctdirect.jl needs two lines re-pointed; ctbase.jl, ctmodels.jl, ctparser.jl still
   work but violate the Handbook. A new ctlie.jl and a new adnlpmodels.jl are added.
2. CTLie is a new hard dependency. Lift, Poisson, ∂ₜ, @Lie moved out of CTFlows;
   Lie was renamed ad and ⋅ was removed outright — a documented breaking change.
3. The Flow API changed shape, not just address. The variable is a mandatory keyword
   on NonFixed problems, augment= became variable_costate=, constrained flows take
   constraint=/multiplier= keyword pairs, and a whole type vocabulary the user writes
   against (OpenLoop, ClosedLoop, DynClosedLoop, PathConstraint, Multiplier,
   PseudoHamiltonian, …) now lives in CTBase.Data and is not re-exported at all today.
   Plus a new method=:cpu|:gpu on every constructor.
4. A namespace question, resolved upstream rather than arbitrated. 49 names are exported
   by more than one submodule. Rather than picking winners, the two families that were really
   one concept were unified in CTFlows and CTSolvers — both now released.
5. A hard dependency arms no extension. New in this version: ADNLPModels and ExaModels are
   now extension-gated in CTSolvers. Declaring them in [deps] is not enough; src/imports/
   must import them explicitly or the capability ships dead (§10).
6. Tests: 4 files need substantive rewrites, 13 need path fixes, and the new work — indirect
   and direct problems in both @def and functional form, 1-D = scalar compliance, the flow
   API surface, CPU/GPU routing — roughly doubles test/problems/.

Verified end to end: the whole indirect workflow — @def, functional PreModel/build,
Flow(ocp, u) point call, trajectory call returning a CTModels.Solution, and 1-D-as-scalar —
already works on the target stack. This is a migration, not a redesign.

2. Target dependency set

All target versions are registered in ~/.julia/registries/ct-registry; no Pkg.develop
needed.

Package	Was	Now	Jump
CTBase	=0.18.8	0.28.7-beta	10 minors
CTModels	=0.10.1	0.15.3-beta	5 minors
CTFlows	0.8	0.16.1-beta	8 minors
CTDirect	1	1.1.0-beta	—
CTSolvers	0.4	0.4.33-beta	—
CTParser	0.8	0.8.17-beta	—
CTLie	—	0.1.5-beta	new

The house compat rule

Pin granularity follows the leading number: X == 0 → pin to the minor ("0.28");
X ≥ 1 → pin the major alone ("1"). Multi-range strings apply it per range
("0.10, 1", "5, 6"). The one exception is julia = "1.10", which states a minimum
supported version, not a bound — julia = "1" would falsely claim 1.0–1.9 support.

This rule is not written down in the Handbook. Four violations were found and fixed in this
file, two of them pre-existing (SolverCore = "0.3.9", Documenter = "1.17.0").

Final [compat] — applied

# control-toolbox
CTBase = "0.28"
CTDirect = "1"
CTFlows = "0.16"
CTLie = "0.1"
CTModels = "0.15"
CTParser = "0.8"
CTSolvers = "0.4"

# modelers / NLP plumbing
ADNLPModels = "0.8"
ExaModels = "0.11"          # was "0.9" — CTSolvers and CTDirect both require 0.11
NLPModels = "0.21"
SolverCore = "0.3"          # was "0.3.9" — rule fix

# AD — promoted to [deps]; the differential-geometry API is core
DifferentiationInterface = "0.7"
ForwardDiff = "0.10, 1"     # was "0.10, 1.0" — rule fix

# SciML trio — [extras]; the user loads an integrator (Q7)
DiffEqBase = "6, 7"
OrdinaryDiffEqTsit5 = "2"
SciMLBase = "3"

# unchanged hard deps
CommonSolve = "0.2"
DocStringExtensions = "0.9"
LinearAlgebra = "1"
RecipesBase = "1"
Reexport = "1"

# test-only, widened to match CTSolvers' own compat
CUDA = "5, 6"               # was "5"
CUDSS = "0.6, 0.7, 0.8"     # new — Q5
MadNLP = "0.9, 0.10"        # was "0.9"
MadNLPGPU = "0.8, 0.10"     # was "0.8" — Q5
MadNCL = "0.2"
NLPModelsIpopt = "0.11"
NonlinearSolve = "4"
OrdinaryDiffEq = "6, 7"     # was "6" — 7.2.0 is what resolves
UnoSolver = "0.3"
BenchmarkTools = "1"
Printf = "1"
SplitApplyCombine = "1"
Test = "1"

# dropped entirely — docs/Project.toml already owns both
# Documenter, Literate

julia = "1.10"              # exception: minimum supported version, not a bound

The equality pins were the thing freezing the whole tree. The same two pins existed in
.extras/Project.toml and have been dropped there too; that environment's Manifest.toml is
now stale in the other direction and needs a Pkg.resolve() on next use — not done here,
.extras is outside this PR's path.

Resulting direct dependencies — 17

ADNLPModels · CTBase · CTDirect · CTFlows · CTLie · CTModels · CTParser · CTSolvers
CommonSolve · DifferentiationInterface · DocStringExtensions · ExaModels · ForwardDiff
LinearAlgebra · NLPModels · RecipesBase · Reexport · SolverCore

3. Decisions

#	Question	Decision
Q1	Name collisions	Unify upstream where it is one concept; do not arbitrate. state/control/costate/objective/time_grid: CTFlows.Trajectories extends CTModels.Components' generics. status/successful: CTSolvers.Integrators extends CTModels.Solutions'. times: not unified — CTModels' returns a TimesModel component, CTSolvers' a grid. Doing this in OptimalControl instead would have been type piracy.
Q2	Hard deps for extensions	Promote two, not five. DifferentiationInterface + ForwardDiff → [deps]: small (0.9 + 2.2 Mo) and the geometry API is core vocabulary. Narrowed by Q7.
Q3	Lie and ⋅	Remove, no compatibility aliases. Propagated as a documented breaking change; BREAKING.md + CHANGELOG.md entries are part of this PR.
Q4	CTSolvers version	0.4.33-beta — includes the #187 unification.
Q5	MadNLPGPU / CUDSS	Widen. MadNLPGPU = "0.8, 0.10" + CUDSS = "0.6, 0.7, 0.8", CUDSS in [extras] and the test target. ⚠️ Test files need using CUDA and using CUDSS — CUDSS alone leaves MadNLPGPU.CUDSSSolver === nothing (§10.2).
Q6	Release ordering	Upstream first. Both blockers are now released; see §4.
Q7	SciML trio: [deps] or [extras]?	[extras]. SciMLBase, DiffEqBase, OrdinaryDiffEqTsit5 are 35 packages — 40 % of the graph — and the user recovers Flow with one using OrdinaryDiffEq, which arms every SciML extension. Uniform with solve (load a solver) and plotting (load Plots): load what you want to do. Reverses the SciML half of Q2. BREAKING.md gains an entry: Flow now requires an integrator using.
Q8	Arming extensions from [deps]	Whoever declares the dependency owns the load. A [deps] entry arms nothing — src/imports/ must explicitly import ADNLPModels, ExaModels, DifferentiationInterface, ForwardDiff. Never rely on transitive loading. Pinned by a contract test.

Nothing remains open.

Why the SciML trio moved out (Q7), in one table

Marginal cost over the hard-dep base, measured not estimated:

	pkgs	size	Flow on bare using OptimalControl
all three in [deps]	89	41.7 Mo	✅ works
all three in [extras]	54	35.8 Mo	❌ needs one using
difference	−35 pkgs	−5.9 Mo

5.9 Mo is not the argument; 35 packages is — first-load precompilation and resolution
surface. Moving OrdinaryDiffEqTsit5 alone was never an option worth having: its marginal
cost is 0.5 Mo and 3 packages, because DiffEqBase and SciMLBase carry the graph. It would
have broken Flow while saving nothing.

4. Upstream status — all clear

Repo	Issue	Scope	Status
CTSolvers.jl	#187	status, successful → CTModels.Solutions. Not times	✅ #188 merged, 0.4.33-beta registered
CTFlows.jl	#370	11 methods across 5 generics → CTModels.Components	✅ #371 merged, 0.16.1-beta registered
CTFlows.jl	#369	Configs.dynamics_trait shadows CTBase.Traits	open — non-blocking, neither side re-exported
CTFlows.jl	#368	*_gradient verb (compute) vs noun (accessor)	open — non-blocking, same reason
CTSolvers.jl	#189	GPU test-environment contract	in progress — non-blocking, see §10.3

Both unifications were non-breaking: every call site and method kept working, only
parentmodule changed, and importing both paths into one module now succeeds instead of
erroring. Patch betas sufficed, and CTSolvers = "0.4" / CTFlows = "0.16" already admit them.

---

Part II — Change specification

5. The architectural shift

Every dependency now follows Handbook/philosophy/modules.md:

CTBase    → Core · Exceptions · Options · Strategies · Orchestration · Traits · Data
            Differentiation · Unicode · Descriptions · DevTools · Interpolation · Plotting
CTModels  → Components · Models · Building · Solutions · Display · Serialization · Init
CTFlows   → Display · Configs · Systems · Integrators · Trajectories · Flows · MultiPhase
CTSolvers → Optimization · Modelers · DOCP · Solvers · Integrators
CTLie     → (flat, exports its API)
CTDirect  → (flat)
CTParser  → (flat)

A subtlety that saves work: because each package manifest does using .Sub, names remain
reachable through the package root (CTBase.CTException, CTModels.state both resolve).
So ctbase.jl, ctmodels.jl and ctparser.jl will not break. They are nonetheless
non-compliant and should be re-pointed at the owning submodule in this PR, because a future
move within a package would silently break them again.

Four real relocations, which do break:

Was	Is now
CTSolvers.{Options, Strategies, Orchestration}	CTBase.{Options, Strategies, Orchestration}
CTFlows.{Hamiltonian, HamiltonianVectorField, VectorField}	CTBase.Data.*
CTFlows.{Lift, Poisson, ∂ₜ, @Lie}	CTLie.*
CTDirect.{AbstractDiscretizer, discretize}	CTSolvers.DOCP.*

6. Import-layer migration map

Produced by resolving every symbol in src/imports/*.jl against the target stack in a live
probe (§14). Only broken entries are listed; everything else resolves.

6.1 ctdirect.jl — 2 broken

import CTDirect: AbstractDiscretizer   # → CTSolvers.DOCP.AbstractDiscretizer
@reexport import CTDirect: discretize  # → CTSolvers.DOCP.discretize

CTDirect.Collocation and CTDirect.DirectShooting are unmoved. AbstractDiscretizer is now
owned by CTSolvers; CTDirect only implements it.

6.2 ctflows.jl — 10 of 11 broken (rewrite)

Old	New
CTFlows.Hamiltonian	CTBase.Data.Hamiltonian
CTFlows.HamiltonianVectorField	CTBase.Data.HamiltonianVectorField
CTFlows.VectorField	CTBase.Data.VectorField
CTFlows.HamiltonianLift	renamed → CTLie.LiftedHamiltonianFunction
CTFlows.Lift	CTLie.Lift
CTFlows.Poisson	CTLie.Poisson
CTFlows.∂ₜ	CTLie.∂ₜ
CTFlows.@Lie	CTLie.@Lie
CTFlows.Lie	renamed → CTLie.ad
CTFlows.⋅	removed — use ad(X, f) or @Lie
CTFlows.*	no longer needs re-export — it is Base.:*, extended by CTFlows.MultiPhase
CTFlows.Flow	CTFlows.Flows.Flow

Two are semantic, not cosmetic:

• HamiltonianLift is no longer a Hamiltonian. CTLie.LiftedHamiltonianFunction <: Function, not <: Data.AbstractHamiltonian. Any isa/<: assertion against the old
  hierarchy is now wrong. Lift is also overloaded on input type: Lift(f::Function) →
  LiftedHamiltonianFunction, but Lift(X::Data.AbstractVectorField) → Data.Hamiltonian.
• ⋅ has no replacement. X ⋅ f was the Lie-derivative operator, dropped in the move.

6.3 ctsolvers.jl — 28 broken (rewrite)

Everything strategy/option-related left CTSolvers for CTBase:

# → CTBase.Strategies
AbstractStrategy, StrategyRegistry, StrategyMetadata, StrategyOptions,
RoutedOption, BypassValue, AbstractStrategyParameter, CPU, GPU,
id, metadata, describe, options, option_names, option_type, option_description,
option_default, option_defaults, option_value, option_source, has_option,
route_to, bypass

# → CTBase.Options
OptionValue, OptionDefinition, is_user, is_default, is_computed

OptionDefinition is exported by both CTBase.Options and CTBase.Strategies — same
object, so either path works; import from Options, the owner.

What stays in CTSolvers, under a submodule:

CTSolvers.Modelers: AbstractNLPModeler, ADNLP, Exa
CTSolvers.Solvers:  AbstractNLPSolver, Ipopt, MadNLP, MadNCL, Knitro, Uno
CTSolvers.DOCP:     DiscretizedModel, AbstractDiscretizer, discretize,
                    ocp_model, nlp_model, ocp_solution

6.4 Files that work but should still be re-pointed

• ctbase.jl — the 7 exceptions are in CTBase.Exceptions.
• ctmodels.jl — 108 symbols over Components (51), Models (21), Solutions (24),
  Building (9), Init (3), Serialization (2). One correction: time is no longer a
  CTModels function, it is Base.time extended by CTModels.Components — drop it.
• ctparser.jl, examodels.jl — fine as is.

6.5 New API worth exporting that we currently don't

The full CTBase.Data vocabulary (§7.5), plus CTLie.dg_ad_backend / dg_ad_backend!
(global AD-backend control), CTFlows.MultiPhase.* (n_phases, get_flow,
get_switching_time, get_jump, …), CTSolvers.Integrators.{SciML, AbstractIntegrator, final_state, evaluate_at} and CTBase.Strategies.{description, parameter, default_parameter, force, create_registry, strategy_ids, type_from_id}.

The Data types are the notable gap: Flow dispatches on them, so a user who wants anything
beyond the Function convenience overloads currently has to reach into CTBase.Data by hand.

7. Renamed, moved and removed API

7.1 Sites inside src/

Site	Old	New
helpers/print.jl:301-303	CTSolvers.Strategies.get_parameter_type(T)	CTBase.Strategies.parameter(T)
helpers/print.jl (×7)	CTSolvers.value	CTBase.Options.value
helpers/descriptive_routing.jl:259,317,322-328	CTSolvers.Orchestration.*	CTBase.Orchestration.*
helpers/registry.jl:49	CTSolvers.create_registry	CTBase.Strategies.create_registry
helpers/component_completion.jl:60	CTSolvers.resolve_method	CTBase.Orchestration.resolve_method
helpers/strategy_builders.jl:289,326,333	CTSolvers.{ResolvedMethod, build_strategy_from_resolved}	CTBase.Orchestration.*

7.2 Constructor keyword spelling (is_ prefix)

# before
VectorField(f; autonomous=false, variable=true)
Hamiltonian(h; autonomous=false, variable=true)

# after
Data.VectorField(f; is_autonomous=false, is_variable=true)
Data.Hamiltonian(h; is_autonomous=false, is_variable=true)

Same for @Lie's options.

7.3 Flow call convention — the biggest user-visible break

Not a rename but a signature change. Verified in CTFlows.jl/src/Flows/calling.jl:

(f::AbstractStateFlow)(t0, x0, tf;      variable=NotProvided, unsafe=false)
(f::AbstractHamiltonianFlow)(t0, x0, p0, tf;
                                         variable=NotProvided,
                                         unsafe=false,
                                         variable_costate=false)
(f::AbstractStateFlow)(tspan, x0;       variable=…, unsafe=…)          # trajectory
(f::AbstractHamiltonianFlow)(tspan, x0, p0; variable=…, unsafe=…, variable_costate=…)

1. No positional slot for the variable any more. f(t0, x0, p0, tf, λ) becomes
   f(t0, x0, p0, tf; variable=λ), and it is mandatory on NonFixed problems — the
   default is CTBase.Core.NotProvided and omitting it raises a PreconditionError whose
   suggestion is literally "Pass variable=v when calling the flow".
2. augment=true → variable_costate=true. It integrates the augmented adjoint
   ṗᵥ = -∂H/∂v and returns (xf, pf, pvf) instead of (xf, pf). Our
   test_ctflows.jl:418 still uses augment=true → MethodError.
3. New unsafe=false — when true, ODE retcodes are not checked and failures do not
   throw. Useful inside a shooting loop where an intermediate failure should surface through
   the residual. Worth exposing and testing.

7.4 Constrained flows: keywords replace positional arguments

Old form (still in test/suite/indirect/test_goddard.jl:76):

fb = Flow(ocp, (x,p,v) -> ub(x), (x,u,v) -> g(x), (x,p,v) -> μ(x,p))   # 3 positional

New form — constraint and multiplier are paired keywords; one without the other is a
PreconditionError:

fb = Flow(ocp, u; constraint=g, multiplier=μ)

constraint accepts three spellings, which is a genuine capability gain: a plain Function
with the OCP's natural arity, a Data.PathConstraint, or a Symbol naming a :path
constraint already declared in the OCP — so a constrained flow can reuse the model's own
constraint instead of restating it. multiplier accepts a Data.Multiplier or a plain
μ(x,p) / μ(t,x,p) / μ(x,p,v) / μ(t,x,p,v).

Guard rails to test: Flow(ocp; constraint=…, multiplier=…) without a control law is rejected
(the pair augments the pseudo-Hamiltonian, which needs a law), and single-method functions
have their arity checked against the OCP's time/variable dependence.

Additional option on Flow(h̃, law) and Flow(ocp, law): hamiltonian_type = :total
(default) or :partial — :total composes a Data.ComposedHamiltonian and differentiates
through the control law; :partial builds a Systems.PseudoHamiltonianSystem and takes
partials of H̃ at the frozen feedback value. They coincide only when the law is stationary
for H̃. Anything else is an IncorrectArgument.

7.5 CTBase.Data — the type vocabulary the user now writes against

Flow dispatches on these, so a user building a flow explicitly needs them in scope. None
are currently re-exported by OptimalControl.

Group	Types
Vector fields	AbstractVectorField, VectorField, ControlledVectorField, ComposedVectorField, AbstractControlledVectorField, controlled_vector_field
Hamiltonians	AbstractHamiltonian, Hamiltonian, ComposedHamiltonian, HamiltonianVectorField, AbstractHamiltonianVectorField
Pseudo-Hamiltonians	AbstractPseudoHamiltonian, PseudoHamiltonian, AbstractPseudoHamiltonianVectorField, PseudoHamiltonianVectorField, pseudo_hamiltonian
Control laws	AbstractControlLaw, ControlLaw, OpenLoop, ClosedLoop, DynClosedLoop, control_law
Path constraints	AbstractPathConstraint, PathConstraint, StateConstraint, ControlConstraint, MixedConstraint
Multipliers	AbstractMultiplier, Multiplier

The three control-law kinds are semantically distinct and select different Flow methods —
OpenLoop u(t), ClosedLoop u(t,x), DynClosedLoop u(t,x,p). The convenience overload
Flow(ocp, u::Function) silently wraps u in a DynClosedLoop; a user wanting open- or
closed-loop must name the type. Flow(h̃, law) rejects OpenLoop/ClosedLoop with a
PreconditionError, since a pseudo-Hamiltonian needs the costate those laws do not carry.

The Flow constructor grid is now 9 methods: Flow(VectorField),
Flow(HamiltonianVectorField), Flow(AbstractHamiltonian), Flow(ocp), Flow(ocp, law),
Flow(ocp, u::Function), Flow(PseudoHamiltonian, law),
Flow(PseudoHamiltonianVectorField, law), Flow(ControlledVectorField, law).

7.6 method = :cpu | :gpu on flow construction

Every Flow(...) constructor accepts a method keyword, popped before option routing
(Flows._pop_method) and resolving both strategy families at once — the :di family (AD
backend → Differentiation.DifferentiationInterface{P}) and the :sciml family (integrator →
Integrators.SciML{P}). :cpu is the default (AutoForwardDiff + SciML{CPU}).

This mirrors the :cpu/:gpu token solve already understands, so after this upgrade the
same word means the same thing on the direct and the indirect side — worth stating in the docs
pass. Upstream reference: CTFlows.jl/docs/src/flows/gpu.md, docs/src/dev/gpu-internals.md,
and the CPU-runnable routing tests in CTFlows.jl/test/suite/flows/test_gpu_routing.jl —
those assert strategy resolution without a functional GPU, the pattern to copy.

8. The namespace, as settled

Measured on the post-unification stack by object identity (objectid) and per-method owner
(parentmodule) — not by name, which is what separates a shared generic two packages extend
from a true homonym.

	before unification	now
names exported by >1 submodule (32 submodules)	49	49
…a single shared generic	23	31
…distinct objects	26	18

All seven targeted names resolve to one object each, and the operation this exercise existed
for now succeeds:

import CTModels.Components: state ; import CTFlows.Trajectories: state
import CTModels.Solutions:  status; import CTSolvers.Integrators: status
# ✅ all four coexist in one module — previously an error

times   # still 2 distinct objects — deliberately, see below

The 18 still-distinct names and what OptimalControl does with each:

Name(s)	Decision
times	Export CTModels.Components.times only. ⚠️ Genuinely different concepts: CTModels' returns the TimesModel component, CTSolvers' returns the integration time grid. The grid already has its own name, time_grid. Merging would conflate a model component with a vector.
pseudo_hamiltonian, control_law	Export the CTFlows.Systems ones only — siblings of hamiltonian(sys). The CTBase.Data versions act on a bare ComposedHamiltonian; not needed.
variable	CTModels only — CTFlows.Systems.variable reads ODEParameters internals.
initial_time, final_time, initial_state, name	CTModels only — the CTFlows counterparts are Configs internals; CTBase.Options.name is option metadata.
AbstractTag	No export at all.
build_model, build_solution, description, value, the four *_gradients, dynamics_trait	No export — internal on both sides.

No new arbitration is needed: this is exactly the set already ruled on. src/imports/ can be
written against a settled namespace.

9. CTLie integration

[deps]
CTLie = "6880e05b-3a7d-4cac-887c-30cb52c5fdde"

[compat]
CTLie = "0.1"

New src/imports/ctlie.jl:

# CTLie reexports

# Generated code (the @Lie macro emits CTLie.* and CTBase.Traits.* prefixes)
@reexport import CTLie: CTLie

# Differential geometry
@reexport import CTLie: ad, Lift, Poisson, ∂ₜ, @Lie

# AD backend control
@reexport import CTLie: dg_ad_backend, dg_ad_backend!

# Types
import CTLie: LiftedHamiltonianFunction

Two caveats:

1. @Lie emits CTBase.Traits.* in its expansion, so CTBase must be in scope at the
   call site. imports/ctbase.jl already does @reexport import CTBase: CTBase — keep it.
2. CTLie's AD is extension-gated — Lift, ad, Poisson, ∂ₜ need CTBase's
   CTBaseDifferentiationInterface extension, which must be armed; see §10.1.

Also note the 0.1.5-beta breaking change: ad_backend= no longer takes a raw
ADTypes.AbstractADType, it takes a CTBase.Differentiation.AbstractADBackend.

10. Extensions: what must actually be loaded

10.1 A hard dependency arms nothing — the load is what counts

New in v2.1.0-beta and easy to get silently wrong. ADNLPModels and ExaModels used to be
plain hard dependencies of CTSolvers with no extension behind them; they are now
extension-gated. Julia fires an extension when its trigger packages are loaded in the
session, not when they appear in Project.toml. Verified:

using CTSolvers                 # ADNLPModels & ExaModels ARE direct deps here
# CTSolversADNLPModels : inactive
# CTSolversExaModels   : inactive
import ADNLPModels: ADNLPModels
import ExaModels: ExaModels
# both : ACTIVE

using CTBase
# CTBaseDifferentiationInterface : inactive
import DifferentiationInterface: DifferentiationInterface
# CTBaseDifferentiationInterface : ACTIVE

The rule (Q8): whoever declares the dependency owns the load. If a package is in
[deps] because a CTx extension needs it, src/imports/ must import it explicitly.
Otherwise we pay the install cost and ship a dead capability.

Capability	Extension	Trigger	Loaded by OptimalControl today?
Exa modeler	CTSolversExaModels	ExaModels	✅ imports/examodels.jl:4
ADNLP modeler	CTSolversADNLPModels	ADNLPModels	❌ nothing imports it
AD for solve	CTSolversForwardDiff	ForwardDiff	⚠️ only transitively
Lie / Poisson / Lift / @Lie	CTBaseDifferentiationInterface	DifferentiationInterface	❌ nothing imports it
Flow over an ODE	CTFlowsSciMLFlows, CTFlowsSciMLIntegrator, CTSolversSciMLIntegrator	SciMLBase, DiffEqBase	user's using — by design (Q7)
default Tsit5	CTSolversOrdinaryDiffEqTsit5	OrdinaryDiffEqTsit5	user's using — by design (Q7)
plotting	CTBasePlots, CTFlowsPlots	Plots	user's using — by design
NLP solvers, GPU	CTSolversIpopt, CTSolversMadNLPGPU, …	solver pkgs, CUDA+CUDSS	user's using — by design

Two of these are bugs waiting to happen once the upgrade lands: the ADNLP modeler — our
default — would not be registered, and the whole differential-geometry API would be
inert, both while their packages sit in [deps] being paid for.

⚠️ CTSolversForwardDiff is armed by accident. Nothing here imports ForwardDiff; it is
available only because ADNLPModels depends on it. That rests on someone else's dependency
graph. ADNLPModels 0.8 has already moved to DifferentiationInterface; the day it drops the
ForwardDiff dep, the extension stops arming — no error, no warning, possibly no failing test.

imports/examodels.jl:5 already applies this reasoning — using LinearAlgebra is there purely
"to trigger ExaModels extension for LinearAlgebra". The practice just needs applying to the
other three.

Corollary worth remembering: seeing ✓ Pkg → PkgExt in a precompile log proves nothing —
extensions precompile whenever triggers are in the manifest, but load only when the triggers
are actually using-ed.

10.2 MadNLPGPU, CUDA and CUDSS

Registry facts, checked against General.tar.gz:

MadNLPGPU	CUDSS	CUDA
0.7–0.8	hard dep, CUDSS = "0.6.4 - 0.6" on 0.7.17 - 0.8	hard dep
0.9+	weak dep, no compat bound at all	gone — replaced by weak CUDACore, cuBLAS, cuSOLVER, cuSPARSE

MadNLPGPU/src/MadNLPGPU.jl:45 declares global CUDSSSolver::Any = nothing; only
MadNLPGPUCUDAExt.__init__ overwrites it, and that extension triggers on five packages.
So:

using MadNLPGPU, CUDSS         # CUDSSSolver === nothing   ← still degraded!
using MadNLPGPU, CUDA, CUDSS   # CUDSSSolver === MadNLPGPUCUDAExt.CUDSSSolver ✅

Both using CUDA and using CUDSS are required. The assertion
Test.@test MadNLPGPU.CUDSSSolver isa Type catches the inert case and is CPU-runnable — it
passes with CUDA.functional() == false, because extension loading depends on packages being
loaded, not on a driver being present. It does not belong behind a GPU gate.

The union CUDSS = "0.6, 0.7, 0.8" matters: "0.7, 0.8" alone makes the MadNLPGPU = "0.8"
branch unsatisfiable and silently collapses the widened pin to a single line.

Footprint, for the record: CUDSS.jl source is 1.1 Mo but CUDSS_jll's binary is 76 Mo
(lazy), CUDSS ≥ 0.7 hard-depends on CUDACore+cuSPARSE (+44 packages), its artifacts are
linux/windows only, and CUDA_Runtime_jll is 1 597 Mo (also lazy). Hence [extras], not
[deps] — it is not even a free choice, since a hard CUDSS drags CUDA behind it.

10.3 Incoming from CTSolvers #189

CTSolvers is widening the trigger:

CTSolversMadNLPGPU = ["MadNLPGPU", "CUDA", "CUDSS"]   # was "MadNLPGPU"

This fixes a real production bug: ext/CTSolversMadNLPGPU.jl:47-51,69-73 dispatches on
Type{MadNLPGPU.CUDSSSolver}, a signature baked at extension-load time. Loading the
extension before CUDA+CUDSS defines both methods against a degenerate Type{nothing}, and
Julia never reloads an extension.

Consequences here:

1. using CUDSS becomes load-bearing. test/suite/solve/test_canonical.jl has
   using MadNLPGPU (l. 21) and using CUDA (l. 24) but no CUDSS. Today: degraded extension.
   After: no extension at all, so MadNLPGPU{GPU} is not registered as a strategy.
2. No [compat] change — CTSolvers adopts exactly CUDSS = "0.6, 0.7, 0.8".
3. Not blocking, unlike OptimalControl.jl upgrade: CTBase.jl v0.10, CTFlows.jl v0.4, CTDirect.jl v0.7, CTProblems.jl v0.7 #187/Fix link to MadNLP #370: CTSolversMadNLPGPU is GPU-only and nothing in the
   direct/indirect workflow touches it. It can land before or after this PR.

11. Test-suite impact

Current suite: 30 files, ~7 500 lines.

11.1 Breakage triage

Severity	Files	Nature
Rewrite	suite/reexport/test_ctflows.jl (490 l)	tests ⋅, Lie, HamiltonianLift, CTFlows.{VectorField,Hamiltonian,AbstractHamiltonian}, autonomous=/variable= — nearly every assertion is stale
Rewrite	suite/reexport/test_ctsolvers.jl (213 l)	28 moved symbols
Rewrite	suite/reexport/test_ctdirect.jl (51 l)	AbstractDiscretizer/discretize moved
Rewrite	suite/indirect/* (3 files)	Lie → ad, and the flow call convention (§7.3–7.4): test_goddard.jl:76 uses the 3-positional constrained form; test_ctflows.jl:418 uses augment=true
Patch	13 files under suite/helpers/, suite/solve/	CTDirect.AbstractDiscretizer, CTSolvers.{Options,Strategies,Orchestration} paths
New	suite/reexport/test_ctlie.jl	doesn't exist yet
Review	suite/reexport/test_ctmodels.jl, test_ctbase.jl	should assert submodule-qualified paths

11.2 New tests

(a) Indirect × two front ends. test/problems/ holds 8 problems, all @def.
../CTFlows.jl/test/suite/integration/ has 25 indirect problems with reference solutions,
all functional-API — the source to mine:

control_and_variable · control_free · double_integrator_{consumption,energy,state,time}
double_integrator_energy_control_constraint · double_integrator_energy_distance
double_integrator_state_first_order · free_initial_time · goddard · goddard_ocp
lqr_ricatti · orbital_transfer_{consumption,energy,time}
simple_exponential_{consumption,energy,time}
simple_integrator_{energy_free_tf,lqr_free_tf,mixed_constraint,nonsmooth_turnpike}
simple_integrator_state_and_control_constraints_nonautonomous · singular_control

Each problem exposes both constructions behind one interface, so a single test body runs twice:

test/problems/
  <problem>.jl        →  <Problem>(:abstract)   # @def
                         <Problem>(:functional) # PreModel / build

with a shared driver asserting equivalent models and equivalent shooting residuals.

The functional form needs one call that is easy to forget — verified, it throws a
PreconditionError otherwise:

CTModels.time_dependence!(pre; autonomous=true)   # required before build

(b) 1-D = scalar contract tests. Per Handbook/philosophy/dimension-and-shape.md, every
1-D quantity is a scalar and the in-place derivative buffer stays a vector. Confirmed on the
target stack. Add, per the Handbook's own recipe, a type-recording fake at module top level:

const SEEN = Ref{Any}(nothing)
rec_dyn_1d!(r, t, x, u, v) = (SEEN[] = (x, u, v); r[1] = -x[1] + u[1]; nothing)
# then: Test.@test SEEN[][1] isa Number   (1-D state → scalar)
#       and for an n-D twin: isa AbstractVector

New test/suite/shape/ group, exercised through both the direct and the indirect path —
exactly the boundary OptimalControl owns.

(c) Direct × two front ends. Same (:abstract, :functional) pattern over the existing
direct problems (beam, goddard, double integrator, quadrotor, transfer, control-free).

(d) Flow API surface — new, currently zero coverage. New test/suite/flows/:

• Call convention: variable= mandatory on NonFixed — assert the PreconditionError
  when omitted and the correct result when given; variable_costate=true returns the 3-tuple
  and false the 2-tuple; unsafe=true suppresses the retcode check (drive it with a
  deliberately failing integration).
• Control-law types: one end-to-end extremal per kind — OpenLoop, ClosedLoop,
  DynClosedLoop — plus the error path that Flow(h̃, law) rejects the first two.
• Constrained flows: the Goddard boundary arc rebuilt with
  Flow(ocp, u; constraint=…, multiplier=…) in all three constraint spellings — plain
  Function, Data.PathConstraint, and the Symbol label form reusing a :path
  constraint declared in the OCP (a genuine capability gain, deserves its own test). Plus the
  pairing guard and the control-free guard.
• Pseudo-Hamiltonian: hamiltonian_type=:total vs :partial — assert they agree where the
  law is stationary for H̃ and differ where it is not. Plus
  Flow(PseudoHamiltonianVectorField, law) (hand-differentiated, no AD).
• 1-D = scalar through these paths too, not only through Flow(ocp, u).

(e) CPU/GPU end-to-end, two levels, following CTFlows:

1. Routing assertions, CPU-runnable — method=:gpu resolves the :di family to
   Differentiation.DifferentiationInterface{GPU} and :sciml to Integrators.SciML{GPU}
   without a functional GPU. Pattern: CTFlows.jl/test/suite/flows/test_gpu_routing.jl.
2. Actual device runs, guarded by is_cuda_on() as runtests.jl already does — an
   indirect method=:gpu flow and a direct (:collocation, :exa, :madnlp, :gpu) solve on the
   same problem, checked against the CPU result.

(f) Extension-arming contract — the §10.1 matrix as assertions, not prose:

# test/suite/extensions/test_extensions_armed.jl
for (mod, ext) in ((CTSolvers, :CTSolversADNLPModels),
                   (CTSolvers, :CTSolversExaModels),
                   (CTSolvers, :CTSolversForwardDiff),
                   (CTBase,    :CTBaseDifferentiationInterface))
    Test.@test Base.get_extension(mod, ext) !== nothing
end
# and, once CTSolvers#189 lands:
Test.@test Base.get_extension(CTSolvers, :CTSolversMadNLPGPU) !== nothing
Test.@test MadNLPGPU.CUDSSSolver isa Type

Cheap, CPU-only, and it fails loudly the day an upstream package reshuffles its deps.

11.3 Handbook compliance

Handbook/philosophy/testing.md mandates: file = module, single test_<name>() entry, outer
redefinition, all imports and call sites qualified, fakes at module top level. The existing
files mostly comply, with one systematic deviation: suite/reexport/test_ctflows.jl uses bare
using OptimalControl then unqualified Lift, Flow, Poisson, @Lie, ∂ₜ. Defensible
there — the file's purpose is to test the flat re-exports exist — but it should be an
explicit commented exception rather than an accident.

---

Part III — Work order

12. Sequencing

Each step ends green before the next starts; the suite is the regression net. Per
Handbook/RULES.md, run through ct-dev-mcp (get_test_command → run with tee →
generate_report), targeted scope first, full suite before closing a step.

#	Step	Gate
0 ✅	Upstream — CTSolvers #187, CTFlows #370	passed — both registered
1 ✅	Project.toml: compat + CTLie + [extras]/targets; drop .extras pins	passed — Pkg.resolve() clean
2	Rewrite src/imports/ (7 files + new ctlie.jl + new adnlpmodels.jl) and add the arming imports (§10.1)	using OptimalControl loads
3	Patch src/helpers/ + src/solve/ (§7.1, ~15 sites)	package precompiles
4	Patch the 13 path-only test files; add using CUDSS to the two GPU files (§10.3)	those groups green
5	Rewrite test_ctflows.jl, test_ctsolvers.jl, test_ctdirect.jl; add test_ctlie.jl	reexport group green
6	Rewrite suite/indirect/* for the new flow call convention (§7.3–7.4)	indirect group green
7	Dual-form problem library (:abstract / :functional), seeded from CTFlows' 25 problems	indirect + direct green
8	New test/suite/flows/ + the extension-arming contract test (§11.2 d, f)	new group green
9	New test/suite/shape/ 1-D-scalar contract tests	full suite green
10	BREAKING.md + CHANGELOG.md for v2.1.0-beta	—
11	Coverage run, cov_report.md review	—

Step 1 outcome (done)

Pkg.resolve() clean; direct deps 21 → 17. The stale root Manifest.toml had to be
regenerated — it pinned CTFlows 0.8.25 and failed with empty intersection between CTFlows@0.8.25 and project compatibility 0.16. It is gitignored (.gitignore:36).

The test target was resolved separately (extras are invisible to a plain Pkg.resolve()):
it co-resolves at MadNLPGPU 0.10.2 + CUDSS 0.7.0 + CUDA 6.2.0, with
CTSolvers → CTSolversMadNLPGPU precompiling.

Precompiling OptimalControl itself now fails at UndefVarError: AbstractDiscretizer not defined in CTDirect — the §5 relocation, and step 2's job.

13. BREAKING.md content for v2.1.0-beta

Three groups, all user-visible:

1. Differential geometry — Lie(X, f) → ad(X, f); X ⋅ f → ad(X, f) (no alias);
   HamiltonianLift → CTLie.LiftedHamiltonianFunction, no longer <: AbstractHamiltonian.
2. Flow calls — variable is a mandatory keyword on NonFixed (f(t0,x0,p0,tf; variable=λ));
   augment= → variable_costate=; constrained flows take constraint=/multiplier= pairs
   instead of three positional functions; constructor keywords gain the is_ prefix.
3. Flow now requires an integrator using (Q7) — using OrdinaryDiffEq or
   using OrdinaryDiffEqTsit5 alongside using OptimalControl.

The docs pass that follows must lead with (3), since it changes every example's preamble.
Expect ~24 stale pages under docs/src/ (manual-differential-geometry.md,
manual-flow-*.md, the example-*.md set).

14. How the facts here were established

A throwaway environment at the target versions, plus targeted probes; nothing in the repository
was modified during analysis. Scripts are in the session scratchpad.

1. Resolution is clean — no compat conflict anywhere in the target set, verified for the
   project and, separately, for the test target.
2. Every symbol in src/imports/*.jl was probed against the new stack; the broken list in
   §6 is exhaustive, and each broken symbol's new home was found by scanning all submodule
   export lists.
3. The 49 multiply-exported names were classified by objectid and per-method
   parentmodule, not by name — re-run after both unifications landed (§8).
4. The indirect workflow was run end to end: @def double integrator (energy),
   Flow(ocp, (x,p) -> p[2]), point call from p₀ = [12, 6] → final state residual 5.1e-15;
   the trajectory call returns a CTModels.Solutions.Solution with objective(sol) = 6.0
   (reference 6.0); the same problem via the functional API gives identical results; a
   1-D problem returns Float64 scalars.
5. Extension arming was tested, not assumed (§10.1, §10.2) — including the negative cases
   that make the difference: hard dep without import, and CUDSS without CUDA.
6. Package footprints were measured as marginal cost over the hard-dep base, since
   standalone totals double-count shared infrastructure and mislead by an order of magnitude.

Remarks

• ✅ CTSolvers#190 (merged) — GPU testing.
  Adopted here: the TestCapabilities module (test/helpers/capabilities.jl), the CPU-runnable
  MadNLPGPU.CUDSSSolver isa Type assertion, using CUDA and using CUDSS, and the
  RUNNER_NAME == "kkt" contract that makes the device tier required on the GPU runner instead
  of skipped. Our own anti-pattern audit is clean — no isdefined(Main, :Pkg) offenders.
  Still open elsewhere: CTFlows.jl has the same class of hole one level up — its GPU suites
  (test/suite/extensions/test_gpu_{flows,ensemble}.jl) gate on a silent early return nothing,
  so 71 device assertions vanish from the summary as a pass rather than as a skip, and nothing
  distinguishes a laptop from a degraded kkt. Filed as
  CTFlows#375.

• ✅ describe on :di/:sciml. get_full_strategy_registry() merges the solve registry
  with CTFlows.Flows.flow_registry(), so describe(:ipopt) and describe(:sciml) work from
  the same entry point (src/helpers/registry.jl, test/suite/helpers/test_describe.jl).
  Uncovered a real upstream bug along the way: describe(:sciml) — and, by contagion,
  describe(:cpu)/describe(:gpu) on any registry containing it — threw FieldError, because
  SciML has 4 type parameters and CTBase's _strategy_base_name only handled up to 2. Filed
  as CTBase#516 (fixed, 0.28.8-beta),
  alongside CTBase#517
  (Base.merge(::StrategyRegistry...), so the merge above no longer reaches into the struct by
  hand) and CTSolvers#191 (the
  missing describe coverage on the Integrators family that let CompatHelper: bump compat for CTParser to 0.3 for package docs, (drop existing compat) #516 through — still open).

• ✅ "parameter is not a rename of get_parameter_type." Confirmed and resolved. The old
  CTSolvers.Strategies.get_parameter_type returned nothing for a strategy without one;
  CTBase.Strategies.parameter throws NotImplemented instead — deliberate, matching id/
  metadata, but it meant _extract_strategy_parameters needed its own try/catch. Filed
  CTBase#518 rather than adding a
  NoParameter sentinel type (rejected: nothing is already the documented, unambiguous answer
  for every non-parameterized strategy in the ecosystem — a new type would rename a working
  convention, not fix anything). Shipped as the non-throwing 2-arg
  parameter(strategy_type, default), now what _strategy_parameter calls
  (src/helpers/print.jl) — it also warns once per strategy type when the fallback is taken,
  rather than staying silent.

• ✅ Shooting functions live in the problem file, tested generically. Each indirect fixture
  (Goddard, the three double-integrator variants) now carries a shoot_builder — closure
  signature (; hamiltonian_type=:total) -> (shoot!, ξ_exact, ξ_guess) — on TestProblem,
  built once next to the problem (test/problems/{goddard,double_integrator}.jl). Quadrotor's
  is nothing: no exploitable extremal structure, and the constructor now enforces the claim.
  One generic suite/indirect/test_shooting_sweep.jl replaced three hand-written files, adding
  the Newton-from-a-perturbed-guess check none of them exercised before. Found along the way:
  the same derivations were also independently re-derived in
  suite/problems/test_hamiltonian_type.jl — now consumes the shared builder too, three copies
  down to one.

• 🔄 OpenLoop always non-autonomous (CTBase#515). The neutral issue asking whether an
  autonomous OpenLoop should take no argument resolved toward: it shouldn't be a choice at
  all — an open-loop control has nothing but time, autonomy is a property of the OCP. CTBase
  0.28.9-beta makes OpenLoop unconditionally NonAutonomous (is_autonomous kept as a
  warn-only misuse detector, not removed outright). Consumed here: test_flow_api.jl's arity
  table loses its OpenLoop autonomous row, replaced by a regression test that the old
  zero-argument spelling now fails loudly (MethodError) rather than constructing silently.
  Sibling fix in CTFlows.jl (six zero-argument OpenLoop sites in its own test suite) on a
  separate branch and PR, not this one.

• In the documentation, explain the integrator is a strategy in the control-toolbox sense, and
  so you can inspect options. Do this also for the other strategies. Still open.