Roadmap 2025-26

[ocots]

Here is the control-toolbox roadmap for 2025-2026.

@jbcaillau @joseph-gergaud @PierreMartinon

[ocots]

Note for next meeting.

• Call for minisymposia at JuliaCon Global 2026
• Modern documentation: DocumenterVitepress, example
• Continuous benchmark (GitHub action)

[ocots]

Development Priorities & Feature List

Bug Fixes

• Fix max objective issue for exa

Workflows

• test Claude GitHub agent (we need an API key):
  • usage.md
  • solutions.md
• add spell check

Core Features

• Allow dimension zero control
• Add parameters to OCP definition? (shall we?)
• Improve outputs (multipliers, costate, etc.)
• Real-time plot of solver iterations
• ⭐ Adaptive time-stepping
• Improve initial guess specification
• ⭐ Add constraints at intermediate times, multi-phase problems (à la Dmitruk)
• ⭐ Non-uniform grid for exa

Solvers & Optimization

• ⭐ Add UNO solver
• Add direct shooting
• ⭐ BVP methods with adaptive time-stepping
• Support MINLP (Mixed-Integer Nonlinear Programming)
• Support NMPC (Nonlinear Model Predictive Control)
• ⭐ Implement homotopy methods

CTFlows Enhancements

• Refactor codebase
• Integrate SimpleDiffEq
• ⭐ Improve performance of AD on flows
• Add GPU support
• Support open and closed loop control
• Add implicit control support

DSL & Language Features

• Add DSL transformations
• ⭐ Penalisation à la Malisani and implicit control
• Natural language to DSL OC converter
• Integrate ModelingToolKit: to use symbolic reduction... Present use cases.
• Add use cases of AI: Latex to OC, OC to MTK, MTK to OC...

Documentation & Tutorials

• Add internal explanations for CTDirect (discretization methods)
• Create tutorial on AD backend options
• Add tutorials: turnpike, AD, free times, state constraints, impulsional cases, abnormal cases, good initial guess, ML and OC

⭐ Benchmarking

• Benchmark NLP solvers
• Benchmark modelers
• Benchmark linear solvers
• Benchmark AD backends
• Write comprehensive benchmarking article
• Compare to CasADi, InfinitOpt, JuMP, Grape

Visualization

• Add Makie support
• Add Plotly support

Publications & Examples

• ⭐ Submit JOSS papers (OC and OCP.jl)
• Add more problems to OCP.jl
• Add application examples: Kepler, MRI, Geometry, Zermelo...

Quality & Testing

• Improve code coverage

[ocots]

DSL & Language Features Discussion

This discussion focuses on the Domain-Specific Language (DSL) used in the OptimalControl.jl / CTParser.jl ecosystem, and on potential extensions and research directions beyond the current long project. We highlight formal transformations, symbolic manipulations, and AI-assisted workflows.

---

1. DSL Transformations and Symbolic Extensions

The DSL can be extended with formal transformations to handle more complex optimal control (OC) problems:

• Multi-phase and free final time problems
  Transformations at the DSL level can encode complex structures like multi-phase problems, free final time, or interior point constraints.
  Relevant discussions: CTParser Issue #139

• Symbolic reduction with ModelingToolkit.jl
  Integrate symbolic simplifications or reductions directly in the DSL workflow. See: OptimalControl Issue #658 for concrete use cases.

• Loss control and constraint penalization
  Introduce formal DSL transformations for penalization and loss control. Related discussions: OptimalControl Issue #620, OptimalControl Issue #525

• Regularization techniques (Malisani style)
  Apply symbolic or numerical regularization for OC problems. References:

  • BVP-DAE repository
  • BVP-DAE Issue #1
  • Malisani et al., HAL 2020

• DSL syntax enhancements
  Examples include handling new keywords, state declarations, and multi-phase notation. See:

  • CTParser Issue #26
  • CTParser Issue #32

---

2. Formal Verification of DSL Transformations

• For critical transformations, consider formal verification of the generated DSL code.
  Tools like Coq or Lean can check correctness automatically.
• LLMs can assist in verifying the structure of the generated code or proposing candidate transformations.
• Example discussion / inspiration: Claude.ai snippet

---

3. AI / LLM Integration

• Transformations can be symbolic or AI-assisted:
  • Natural language → DSL conversion
  • LaTeX / Math → DSL
  • DSL → ModelingToolkit.jl → OC solver
  • Bidirectional DSL ↔ MTK transformations
• LLMs can help generate or verify DSL code from natural language or mathematical descriptions.
• Relevant issues highlighting AI-assisted workflows:
  • CTParser Issue #31
  • CTParser Issue #29
  • CTParser Issue #30

---

4. Use Cases and Examples

• Integrating ModelingToolkit.jl for symbolic simplification and reduction: see OptimalControl Issue #658
• Regularization, loss control, multi-phase OC problems: see OptimalControl Issue #525
• AI-assisted DSL generation from LaTeX / natural language: inspired by Claude.ai example

---

5. Next Steps / Research Directions

1. Formal DSL transformations for multi-phase, free final time, and interior constraints.
2. Symbolic integration with ModelingToolkit.jl for automatic reduction and simplification.
3. LLM-assisted workflows to convert natural language or LaTeX into DSL code and to verify transformations.
4. Formal verification pipeline using Coq / Lean for critical transformation checks.
5. Documented examples linking symbolic, AI-assisted, and solver-ready workflows.

---

References & Issues

• OptimalControl Issue #658 – Integrate ModelingToolkit.jl
• OptimalControl Issue #620 – Loss control transformations
• OptimalControl Issue #525 – Multi-phase / advanced DSL transformations
• CTParser Issue #139 – DSL transformation discussion
• CTParser Issue #31 – LLM-assisted DSL
• CTParser Issue #29 – DSL syntax extensions
• CTParser Issue #30 – DSL code verification
• CTParser Issue #26 – DSL keywords & multi-phase
• CTParser Issue #32 – DSL transformations
• BVP-DAE repository
• BVP-DAE Issue #1
• Malisani et al., HAL 2020
• Claude.ai example

[ocots]

Explore AI and control-toolbox

Explore the possibilities offered by artificial intelligence to interact with the software.
In particular, use natural language and standard LLM tools to provide models or analyze solutions.

• Perform transformations on models:

  • Free final time → fixed final time.
  • Lagrange → Mayer.
  • Multi-phase → single-phase.
  • Non-regular → regular (using various regularizations such as logarithmic barriers, interior-point methods, etc.).
  • Add a homotopy parameter.

• Analyze solutions:

  • Identify the optimal structure and switching times.
  • Provide a report on the quality of the solution based on the logs.

• Build shooting functions:

  • Propose a set of examples and provide guidelines for constructing the shooting function.
  • From there, and using the optimal structure, build the corresponding shooting function.

• Build an initialization for the shooting function with a robustification system.

[ocots]

Issues to write or improve as a priority for @ocots

🧾 Publication and presentation

• Finish the JOSS paper: https://github.com/control-toolbox/joss/issues/1
• Prepare a Wikipedia page, first as an issue draft: [Doc] Create a page on wikipedia OptimalControl.jl#672
• Once it is rich enough, prepare a JOSS paper for OptimalControlProblems.jl (independently of OptimalControl.jl)

---

⚙️ Solvers and model handling

• Check that the solver no longer appears in direct_transcription and close the issue: [Dev] Remove the solver from direct_transcription description CTDirect.jl#493
• Review of the handling of the modeller in direct_transcription and related modules:
  • Description CTDirect.jl#521
  • Description and problems OptimalControlProblems.jl#174
  • then handle this consistently within CTBenchmarks.jl
• Review how to specify which solver we actually want (not just by using); use an explicit variable, add tests, and update the documentation.
• Add MadNCL and UNO to the benchmarks: https://github.com/control-toolbox/CTDirect.jl/issues/514, https://github.com/control-toolbox/CTDirect.jl/issues/304
• Review how a solution is constructed to make it more unified: [General] Build an OCP solution CTDirect.jl#483
• Investigate whether it’s possible to give stronger constraints to solvers to prevent them from leaving the feasible set: [General] Definition of the variables inside an interval OptimalControl.jl#664
• Add tests in OptimalControl.jl to verify that different solvers can be used successfully: [Dev] Add ExaModels unit tests OptimalControl.jl#575

---

🧮 Modeling and optimization problems

• Use a single model for problems with OptimalControl.jl and always express them in minimization form:
  [Doc] _s problems OptimalControlProblems.jl#157,
  [General] Objective value CTDirect.jl#474
  Also improve how problems are retrieved: [Dev] Exa and problems OptimalControlProblems.jl#136
• Optimization with a control of dimension 0: [Dev] Allow dim zero control OptimalControl.jl#656
• Add the notion of parameters: [Dev] Add parameters OptimalControl.jl#655
• Clarify how multipliers, costates, etc. are handled:
  [General] Costate OptimalControlProblems.jl#170,
  Dual variable of the path constraints CTDirect.jl#405
• Constraints and dual variables management: [Dev] Dual variables CTModels.jl#105
• Improve dimension handling in visualizations and the way piecewise-constant controls are displayed: [General] Control logic CTModels.jl#207
• Explain how the initial guess is handled in OptimalControlProblems.jl: [Doc] Intial guess OptimalControlProblems.jl#151
• In the manual section on the initial guess, discuss projection onto constraints: [Doc] Projection of the initial iterate OptimalControl.jl#600
• Add model comparisons and check for ducted_fan: [General] Test comparaison NLP model OptimalControlProblems.jl#166
• Create efficient tests and update import/export functions: [General] Improve import and export CTModels.jl#217

---

📚 Documentation, tutorials, and internal consistency

• Display the documentation of problems in OptimalControlProblems.jl: [Doc] Examples are not displayed correctly in the REPL OptimalControlProblems.jl#173
• Make the documentation of problems clearer: [Doc] Typo in the docstrings OptimalControlProblems.jl#172
  Explain that the correct using statement and backend must be specified. Consider replacing backend types with symbols.
• Export additional functions and update documentation: [General] Export some other functions OptimalControl.jl#618
  Maintain naming consistency. See also [Dev] Naming and consistency CTModels.jl#169
• Review the tutorial on NLP manipulation: [General] Build solution from DOCP Tutorials.jl#38
  Clearly explain how to call different solvers, on CPU/GPU, with Mumps, etc.
• Add an ID for the LQR tutorial: [General] Tutorial LQR Tutorials.jl#24
• Provide a solution for this problem and update the LQR tutorial: [Bug] Error matrix formulation OptimalControl.jl#546
• Finalize the tutorial on logarithmic barrier regularization: [Dev] Tutorial on regularization Tutorials.jl#22
• Finalize the tutorial on intermediate-time constraints: [Dev] Tutorial for constraints at intermediate times Tutorials.jl#18
• Finalize the Kepler application: [Dev] Kepler add examples Kepler.jl#28
• Remove unnecessary stars or improve the table of contents: https://control-toolbox.org/CTBenchmarks.jl/stable/dev.html
• Check that all documentation is up to date: [Doc] Relecture de la documentation OptimalControl.jl#562

---

🧠 Benchmarks and workflows

• Merge in CTBenchmarks: branch 82-doc-add-new-instances-benchmark into 71-doc-plot-benchmarks-results.
• Replace moonshot by mothra or occidata: Add moonshot CPU CTBenchmarks.jl#87
• Typo for MadNLP: [Doc] Typo for MadNLP CTBenchmarks.jl#88
• Remove moonshot from simple CPU runs and replace it with mothra and occidata: [General] Add moonshot CPU CTBenchmarks.jl#86
  Also improve label management for triggering benchmarks.
• Add a comment here to update progress: [Doc] Add new instances benchmark CTBenchmarks.jl#82
  Then merge, explain this to students, and update Generate plots from benchmarks results CTBenchmarks.jl#77 so they can continue their plots.
• Create workflow issues for adding new problems in OptimalControlProblems.jl, then one issue per problem to be added
  (transform [Dev] Add examples OptimalControlProblems.jl#92 into a discussion).
  Include interactive figures for benchmarks and formalize the definition of a setup for a performance profile.
• Check if mothra now works: [General] Add bench on KKT CTBenchmarks.jl#63
• For benchmarks, determine whether to compare with manually discretized and modeled problems: Test with ADNLPModels.jl CTBenchmarks.jl#31
• Check the Space Shuttle problem: New instance of Space Shuttle ( Task #4) CTBenchmarks.jl#22

---

🔬 Miscellaneous and code quality

• Introduce JET tests in all packages if possible: [Dev] Reduce type instabilities CTModels.jl#155
• Real-time plot: [Feature] Real time plot of solver iterations OptimalControl.jl#568
• Review this issue: [Dev] Dual variables CTModels.jl#105

[jbcaillau]

@ocots @PierreMartinon refactoring with CTSolvers.jl is now a hot topic

[ocots]

Example of problems for benchmarking: NonlinearOptimizationTestFunctions.jl

[ocots]

Discussion about benchmarking is here: https://github.com/orgs/control-toolbox/discussions/75.

[ocots]

Don't forget:

• Impulsionnal controls (how to model Dirac control)
• Ensemble control
• CTX for homotopy

[ocots]

Roadmap — Personal Priorities (control-toolbox)

Last updated: 09/07/2026

This document is a synthetic pointer to the main resources and work items I am currently pursuing or planning within the control-toolbox ecosystem. Each item links to the relevant discussion or repository and includes a brief status note.

---

Architecture & Core Packages

Plot Engine

• [Roadmap] Plot engine — Phase 3: CTModels migration CTModels.jl#365 | Discussion #363
• Status: In progress. Currently at Phase 3 — CTModels migration (the major part: switching the plotting backend into CTModels). Goal: a single, complete plot engine hosted by CTBase, with thin case layers in CTModels and CTFlows. Key points from the detailed report:
  • Two existing implementations: CTModels (CTModelsPlots, ~1780-line monolith with 5 signal groups, decorations, multi-time grids, phase plots) and CTFlows (PlotEngine ~250 lines + TrajectoryPlots ~260 lines, already split into engine + case layer). Objective: unify into a single engine in CTBase.
  • Layout model — three levels: Level 1 (keyword API: :split, :group — sugar, backward compatible), Level 2 (block combinators: Column, Paired, Stacked, Grid — declarative, what case layers manipulate), Level 3 (weighted tree IR: Leaf, HBox, VBox — what the backend renders). Single render path, multiple entry points.
  • Backend separation: IR (pure data, zero dependencies) lives in CTBase/src/Plotting/; Plots renderer lives in CTBase/ext/CTBasePlots.jl. This makes a future Makie backend possible without touching the IR or case layers.
  • Why the current CTFlows engine is insufficient: lacks weighted block layouts, per-panel x grids, decorations (hline/vline), per-series style, generic (x, y) series for phase plots, and :group grid layout — all needed by CTModels.
  • Case layers reduced to 5 responsibilities: vocabulary/aliases, panel builders (sampling, naming, seriestype), decoration builders (bounds → HLine, t0/tf → VLine), template choice, and Plots plumbing. Estimated ~300–400 lines per case layer (vs ~2000 today for CTModels).
  • Migration phases: Phase 0 (specification & behavior freeze), Phase 1 (CTBase: Plotting module + CTBasePlots renderer), Phase 2 (CTFlows switches to CTBase engine), Phase 3 (CTModels migration — the big one: :split/:group, path/dual, decorations, phase plots, plot! superposition), Phase 4 (consolidation, docstrings, docs), Phase 5 (optional Makie POC).

Constraints & Duals

• [Roadmap] Constraints & duals — multipliers, costates, and dual variables CTFlows.jl#314 | Discussion #312
• Status: Decisions validated (July 8, 2026). Design note covering two blocked items from the CTFlows roadmap v4. Key points from the detailed design note:
  • Part A — Solution with/without duals (§3): EmptyDualModel <: AbstractDualModel sentinel (decision A4), consistent with existing EmptyTimeGridModel / EmptyDefinition pattern. has_duals(sol) is compile-time via the type parameter. dual(sol, model, label) is the sole public query (per-named-constraint lookup); throws on EmptyDualModel. Active set is a solver-side concept, not a Solution concept. Display dispatches on type, not runtime branches. Impact: CTModels (4 small changes), CTDirect untouched.
  • Part B — Constrained flows (§2): separate carriers PathConstraint{F,K} and Multiplier{F} in CTBase.Data (decision B1), following the ControlLaw template. Multipliers are user-supplied inputs (like control laws), not flow outputs. The constrained Hamiltonian is just H + μ'g — no state augmentation, no DAE. Junctions handled by existing MultiPhase concatenation with costate jumps. API: Flow(ocp, u; constraint=g, multiplier=μ) or constraint=:label to fetch from the model.
  • Sequencing: PR1 CTModels (EmptyDualModel), PR2 CTBase (carriers), PR3 CTFlows (:total constrained path), PR4 (:partial with frozen μ), PR5 (control-free constrained case + guide).

CTFlows Roadmap

• [Roadmap] CTFlows — flow derivatives, GPU, AD performance, and control modes CTFlows.jl#315 | Discussion #299
• Status: v4 roadmap. Several items already shipped (control-law wrappers in CTBase.Data, pseudo-Hamiltonian path, :total/:partial action option, "1-D = scalar" refactor, variable_costate free-time semantics). Remaining work items from the detailed roadmap:
  • Implicit control (§1, Applications #46): compute control from ∂H̃/∂u = 0 when no control law is provided. Two strategies: IFT (augmented ODE for (x,p,u)) or DAE. Needs Hessian AD primitives in CTBase.Differentiation. Decision pending: option vs. CTBase.Strategies strategy.
  • Constrained flows (§2): extend Flow(ocp, law) to OCPs with path constraints — blocked on §3 design (now resolved, see Constraints & Duals above).
  • Constraints & multipliers design (§3): design note delivered — see Constraints & Duals above.
  • Flow derivative via dual numbers (§4, #93): Internal Numerical Differentiation (IND) — integrate variational equations when flow is evaluated on ForwardDiff.Dual inputs. Tagged dual dispatch to avoid collision with outer AD.
  • GPU support & testing (§5, #249, #111): flows on GPU arrays (CuArray, AMDGPU/Metal) with GPU-compatible integrators and CI tests.
  • Non-Hamiltonian flow without costate (§6, #230): Flow(ocp) for direct shooting — integrate ẋ = f(t,x,∅,v) as a plain ODE with variables, no adjoint. Direct-shooting use case.
  • Getter naming & vector-field getter (§7, #185): vector_field(flow) accessor — small, unblocks downstream.
  • Variable costate for variable times (§8, #231): confirm remaining cases (free t0, free (t0,tf)).
  • Cache trajectory projections (§9): quality/perf — precompute projections at construction.
  • Internal ODE solver (§10, ✨ Add automated contributors page #81): optional/strategic — standalone RKF 5(4) to reduce OrdinaryDiffEq.jl dependency.
  • Cross-cutting decision: option vs. CTBase.Strategies strategy — three features (§1, §4, §5) face the same architectural choice; decide once and apply consistently.

CTDirect Roadmap

• [Roadmap] Consolidate CTDirect following the Handbook philosophy CTDirect.jl#610 | Discussion #609
• Status: Prospective. Consolidate CTDirect following the control-toolbox Handbook philosophy. The central theme: abstract the founding ingredients of a transcription so that discretization methods become recipes — generic on abstract types (e.g. driven by an arbitrary Butcher tableau), yet overridable with optimized specializations. Key points from the detailed roadmap:
  • Architecture overhaul (§1): move from flat src/*.jl to one submodule per responsibility (Schemes, Layouts, Transcriptions, Sparsity, Grids, Discretizers, Solutions), with a strict dependency DAG.
  • Types, traits, interfaces (§2): replace Symbol dispatch with scheme types, use traits for scheme properties, define accessor interfaces instead of raw field access, and typed extractors for post-processing.
  • Transcription recipe (§3, the heart): reify the ingredients of a direct transcription (unknowns, layout, reconstruction, defects, cost quadrature, constraints, initial guess, work arrays) so that building a DOCP is a generic recipe over abstract types — with two NLP emission backends (ADNLP callables and ExaModels generators) as an explicit axis from day one.
  • Butcher tableau as user input (§4): users can pass any Butcher tableau; named schemes become constructors returning tableaux.
  • Own the ExaModels transcription (§5): move the ExaModels transcription from CTParser into CTDirect, eliminating duplicated logic and enabling the full scheme catalogue on Exa.
  • Sparsity & AD separation (§6): split "pattern provision" from "backend choice" — two orthogonal axes, one knob today.
  • 1-D = scalar (§7): pass scalars for 1-D state/control/variable to user OCP functions, consistent with CTFlows.
  • Initial guess (§8): pluggable and comparable strategies, with problem-informed defaults at the CTModels level and proper NLP-level injection.
  • Solution building & outputs (§9): typed extractors, duals consolidation, costate/multiplier handling.
  • Direct multiple shooting (§10): control/state parametrization decoupled from the ODE scheme.
  • Free node times, grid rebalancing, mesh refinement (§11): free interior nodes as NLP unknowns, outer-loop refinement with warm restart.
  • Impulsive case (§12): state jumps at selected nodes as a recipe extension — a first step toward non-conventional problems.
  • Documentation (§13): Vitepress migration + a "Transcription" guide explaining the exact NLP produced.
  • Test suite restructuring (§14): adopt the Handbook testing template, organize by functionality, add contract tests with fakes.
  • This consolidation will make CTDirect easier to extend for direct shooting, multi-phase problems, grid refinement, and future non-conventional problems (hybrid, impulsional, ensemble).

CTParser Roadmap

• [Roadmap] Consolidate CTParser — separate parsing from semantics via an IR CTParser.jl#289 | Discussion #288
• Status: Prospective. Follow the Handbook philosophy to build a better base for future extensions. Guiding principle: the parser describes the problem; it does not discretize it. Scheme-dependent code belongs to CTDirect. Key points from the detailed roadmap:
  • ExaModels 0.11 migration (§1): compat blocker for the whole ecosystem; bump from pinned 0.9 to 0.11, audit all generated ExaModels call sites.
  • Move the discretization out of the parser (§2, the structural item): the :exa backend stops generating scheme-dependent transcription code. Two routes: (1) function tracing — CTDirect traces CTModels functions into ExaModels generators, CTParser needs no :exa backend at all; (2) expression IR — CTParser stores a neutral expression representation, CTDirect generates the Exa transcription from it. Joint with CTDirect §5.
  • "1-D = scalar" simplification (§3): emitted closures should work when callers pass scalars for 1-D state/control/variable; coordinate with CTDirect §7 and CTModels.
  • Remove prefixes (§4): replace mutable prefix Refs (PREFIX_FUN, PREFIX_EXA) with direct module-qualified code; removes global mutable state.
  • Parsing robustness (§5): bug sweep (#197), stricter parsing with ParsingError for silent mis-parses (#193, #139), finalize slice notation (#260).
  • Syntax extensions (§6): coordinate-derivative aliases (ẋ₁(t) sugar for ∂(x₁)(t), References #71), tensors/matrix-valued state and control (#181), incremental @def! with $-interpolation (New release of OptimalControl v0.5.0 #32).
  • Parsing engine redesign (§7): staged compiler-style pipeline over a typed IR — Stage 0 (surface normalization), Stage 1 (grammar → IR nodes), Stage 2 (semantic validation), Stage 3 (backend emission). Replaces the 1500-line monolithic onepass.jl. The IR is route 2's neutral representation; engine redesign and Exa repatriation converge on the same object.
  • Test suite restructuring (§8): adopt the Handbook testing template, organize by functionality, keep :exa tests as golden oracle for CTDirect's repatriation.
  • Documentation (§9): Vitepress migration + a complete DSL grammar reference page derived from the §7 IR productions.

CTLie.jl (new)

• [Roadmap] CTLie — differential geometry for Hamiltonian optimal control CTLie.jl#11 | Repository
• Scope: Differential geometry for Hamiltonian optimal control — Lie derivatives, Poisson brackets, Hamiltonian lifts, and the @Lie macro. Newly created package.

---

Indirect Methods & Solvers

CTIndirect (new package, not yet created)

• [Roadmap] CTIndirect — system to define shooting equations and indirect solvers CTSolvers.jl#167 | Design document
• Goal: Provide a system to define shooting equations in a simpler way than manually writing them. Current indirect shooting examples that motivate this:
  • Goddard — Indirect shooting
  • Double integrator (energy) — Indirect method
  • Double integrator (time) — Indirect method
  • Control free — Indirect method
  • Control and variable — Indirect
  • Singular control — Indirect shooting
  • State constraint — Indirect method
• Solvers: Newton solver and possibly BVP solvers for the shooting equations. These solvers will live in CTSolvers.jl. A brainstorming is needed to decide what to create and where to place it.

Homotopy & Conjugate Points

• [Roadmap] Homotopy methods & conjugate point detection CTSolvers.jl#168
• Goal: Reproduce the capabilities of hampath (homotopy methods, conjugate point detection). This requires creating a new package and integrating BifurcationKit.jl.
• Related: Notion of parameters in OCP definitions (see [Dev] Add parameters OptimalControl.jl#655).

BVP Solver & Malisani Transformation

• [Roadmap] Malisani transformation — regularization of DAE optimal control problems BVP-DAE#4 | Repository
• Goal: Build a nice system to construct the Paul Malisani transformation (regularization of DAE optimal control problems). References: Malisani et al., HAL 2020.

---

Benchmarking & Testing

Benchmarking

• [Roadmap] Update CTBenchmarks for OptimalControl v2 and benchmarking paper CTBenchmarks.jl#192 | Repository
• [Roadmap] Update OptimalControlProblems for v2 and add new problems OptimalControlProblems.jl#257 | Repository
• Goal: Update for v2 API and add new benchmark problems. Problem sources: ICLOCS, COPS, PSOPT, MINTOC, DYMOS, BOCOP, Betts (2nd ed.). Specific problems to add: MRI, Kepler, swimmer. Supersedes issue #92 (closed). Write a comprehensive benchmarking paper comparing NLP solvers, modelers, linear solvers, AD backends, against CasADi, InfinitOpt, JuMP, Grape.

Regression Testing with Guix

• [Roadmap] Regression testing with GNU Guix CTBase.jl#480
• Goal: Use GNU Guix for reproducible regression testing across the ecosystem.

---

New Problem Types

• [Roadmap] New problem types: hybrid, impulsional, and ensemble control OptimalControl.jl#807
• Scope: Support non-conventional optimal control problems:
  • Hybrid systems (mixed continuous/discrete dynamics, switching, mode transitions)
  • Impulsional control (measure-driven control, state jumps)
  • Ensemble control (control of populations of systems)
• Related work: NOSNOC (numerical optimal control for hybrid/nonsmooth systems, FESD discretization with switch detection, time-freezing reformulations for state jumps), CCOpt.jl (solver for Mathematical Programs with Complementarity Constraints), MPCCbenchmark.jl (benchmarks for MPCCs, including nonsmooth OCP instances from NOSNOC). These are complementary Julia packages that could serve as references or integration targets for non-conventional problem support.

---

Features & UX

Real-Time Plot

• [Feature] Real time plot of solver iterations OptimalControl.jl#568
• Goal: Real-time visualization of solver iterations during optimization.

Makie Support

• [Roadmap] Add Makie.jl plotting backend CTModels.jl#366
• Goal: Add Makie.jl as a plotting backend alongside the existing Plots.jl support.

DSL Extension

• [Roadmap] DSL extension at the abstract/semantic level CTParser.jl#290
• Goal: Extend the DSL at the abstract level — transformations, multi-phase notation, penalization, symbolic reduction. Play at the abstract (semantic) level rather than the parsing level.

---

Publications

JOSS Paper

• [Roadmap] Finalize JOSS paper — response to reviewers OptimalControl.jl#808 | JOSS branch | JOSS review
• Status: Finalize the response to reviewers and get the paper accepted. Related issues and PRs: #805, #803, #802, #799, #795, PR #804, PR #762.

---

Documentation & Tutorials

Tutorials

• [Roadmap] Update and add tutorials (turnpike, AD, free times, state constraints, etc.) Tutorials.jl#80 | Repository
• Goal: Update existing tutorials and add new ones. Improve "tricks and tips" style tutorials. Add tutorials on: turnpike, AD, free times, state constraints, impulsional cases, abnormal cases, good initial guess, ML and OC.

Documentation via Vitepress

• [Roadmap] Migrate documentation to DocumenterVitepress across all packages CTBase.jl#481
• Goal: Migrate all package documentation to DocumenterVitepress. Already started in CTBase and several other packages.
• Handbook — Vitepress doc

[ocots]

CTFlows Roadmap — update (2026-07-25)

Following up on the CTFlows entry above (discussion #299, tracking comment):

• The v4 roadmap is down to 4 remaining items: implicit control via IFT/DAE (Applications #46), flow derivative via dual numbers/IND (#93), ensemble flows (#341), and an optional internal ODE solver (✨ Add automated contributors page #81). GPU support (#249/#111) and the remaining variable-costate case (#231) are now done — the "Constraints & Duals" work described above already covered §2/§3.
• v0.16.0-beta is out: fixes batched/SVector states on Flow(ocp), and extends the "1-D = scalar" convention to Flow(::VectorField)/Flow(::ODEFunction) (breaking output-shape change for those two — see the CHANGELOG).
• The logical next step is bubbling this up into a new OptimalControl.jl beta, but that's blocked on CTDirect.jl#610 point 7 ("1-D = scalar"), which hasn't landed in CTDirect yet — the convention needs to be consistent across the direct (CTDirect) and indirect (CTFlows) legs of the ecosystem before a new OptimalControl release makes sense. Once that item lands, we can target a new OptimalControl.jl beta.
• Continuing to track the rest of the priorities listed above in parallel.