compat + SolveStats: admit DirectTrajOpt 0.10 / NT 0.9, wire real iteration counts - #18
Merged
Conversation
DTO 0.10.0 and NT 0.9.3 registered this morning; the 0.9/0.8 floors made DTO's own benchmark/convergence CI suites unsatisfiable the moment 0.10.0 hit General. No API surface used by the benchmarks changed (SolveStats is additive; the Δt-weighting change is DTO-internal behaviour experienced on update regardless).
…ration counts DTO 0.10.0 and NT 0.9.3 registered 2026-08-21; the 0.9/0.8 compat floors made DTO's own benchmark/convergence CI unsatisfiable the moment 0.10.0 hit General (the benchmark envs pin this package by rev). Beyond compat: DTO 0.10's solve! now returns a SolveStats (previously nothing). benchmark_solve! was hard-coding iterations = -1 with a 'solve! returns nothing; sentinel' comment — real solver counts were being discarded. Wire them through: iterations from stats.iterations, solver_status from the MOI termination status (post-solve heuristic kept as the fallback for pre-0.10). Full suite 306/306 against DTO 0.10.
The registry only recently gained DirectTrajOpt 0.10.0 (the original registration PR sat unmerged: AutoMerge requires breaking release notes to say 'breaking'). Guard the SolveStats branch with isdefined so the harness works whether the resolver picks 0.9.8 or 0.10.0 — the isa check alone throws UndefVarError on pre-0.10. Verified both ways: Pkg.test() 306/306 against registry DTO 0.10.0 (SolveStats path live) and the guard keeps 0.9.8 resolvable.
aarontrowbridge
added a commit
to harmoniqs/DirectTrajOpt.jl
that referenced
this pull request
Aug 21, 2026
…Stats) The rev-pinned c38418c pin (compat DirectTrajOpt = 0.9 only) made both benchmark CI suites unsatisfiable the moment DTO 0.10.0 hit General — on this very PR, since its Project.toml declares 0.10. v0.2.1 widens compat to 0.9/0.10 and wires the SolveStats return into benchmark_solve!'s iteration counts (harmoniqs/HarmoniqsBenchmarks.jl#18).
aarontrowbridge
added a commit
to harmoniqs/DirectTrajOpt.jl
that referenced
this pull request
Aug 21, 2026
…tor (#139) * fix(integrators): restore the multi-state BilinearIntegrator constructor The c9fdeb7 integrator refactor dropped the historical xs::AbstractVector{Symbol} constructor, leaving every stacked-state caller — concretely Piccolo's exported VariationalKetIntegrator/VariationalUnitaryIntegrator (Piccolo #300) — with a MethodError on construction. Additive restore following the codebase's existing multi-name convention (get_nonlinear_constraints already dispatches on x_names; Piccolissimo's exponential family carries it): - struct gains x_names::Vector{Symbol}; x_name::Symbol stays as the primary (first) name, so existing field access keeps working - BilinearIntegrator(G, xs, u, traj) constructor; the single-name form delegates via [x] - evaluate!/eval_jacobian/eval_hessian_of_lagrangian gather the stacked state across all names (component ranges hoisted out of the ForwardDiff closures) - get_nonlinear_constraints checks x_names before x_name so an integrator carrying both fields sums the whole stack - test: split-component trajectory vs single-component reference — identical residuals/Jacobians/Hessians on coinciding flat data + branch coverage Fixes #138. Unblocks Piccolo #300 (variational integrator tests ride 2.0.3). * benchmark: pin HarmoniqsBenchmarks to v0.2.1 (DTO 0.10 compat + SolveStats) The rev-pinned c38418c pin (compat DirectTrajOpt = 0.9 only) made both benchmark CI suites unsatisfiable the moment DTO 0.10.0 hit General — on this very PR, since its Project.toml declares 0.10. v0.2.1 widens compat to 0.9/0.10 and wires the SolveStats return into benchmark_solve!'s iteration counts (harmoniqs/HarmoniqsBenchmarks.jl#18).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #19
Why
DTO 0.10.0 and NT 0.9.3 registered this morning; this package's
DirectTrajOpt = "0.9"/NamedTrajectories = "0.8"floors made DTO's own Benchmark and Convergence CI suites unsatisfiable the moment 0.10.0 hit General (both pin this package by rev).What
0.9, 0.10; NT0.8, 0.9. No benchmark-facing API changed.solve!returnsSolveStats(previouslynothing).benchmark_solve!was hard-codingiterations = -1with a'solve! returns nothing; sentinel'comment — the solver's real counts were being discarded. Now:iterationsfromstats.iterations,solver_statusfrom the MOI termination status, with the old post-solve heuristic kept as the pre-0.10 fallback.Verification
Full suite 306/306 against DTO 0.10 (developed in the test env). New assertion:
iterations >= 0(the sentinel path would fail it).After merge
Tag v0.2.1 — DirectTrajOpt's
benchmark/Project.tomlandbenchmark/convergence/Project.tomlpin this repo by rev; I'll bump both pins to the tag on the DTO side (PR harmoniqs/DirectTrajOpt.jl#139 branch).