Skip to content

Document MATLAB solver API and enable strict QA - #94

Merged
ChrisRackauckas merged 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:agent/matlabdiffeq-narrow-v24-20260808
Aug 8, 2026
Merged

ChrisRackauckas merged 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:agent/matlabdiffeq-narrow-v24-20260808

Conversation

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member

Summary

  • adopt SciMLTesting 2.4 defaults with plain run_qa(MATLABDiffEq)
  • remove the blanket DiffEqBase reexport and import required APIs from their declaring packages
  • document the package-owned MATLAB algorithm API at each definition site and render it through Documenter
  • add focused tests for the public algorithm hierarchy, documentation, and SciMLBase solver interface

API ownership

This uses the declaring packages directly:

  • SciMLBase 3.28.4+ for the documented public solver interface
  • Symbolics 7.34+ for the documented public MATLABTarget
  • ModelingToolkitBase for ModelingToolkit system accessors

The removed blanket reexports were undocumented dependency-owned bindings, so this PR does not describe that cleanup as a breaking change.

Local validation

  • julia +release --project=. -e 'using Pkg; Pkg.test(test_args=["Core"])': passed; interface 46/46, JET 34/34
  • julia +1.10 --project=. -e 'using Pkg; Pkg.test(test_args=["Core"])': passed; interface 44/44, JET 34/34
  • strict QA on Julia release: 20/20 passed
  • strict QA on Julia 1.10: 18/18 passed
  • docs and doctests on Julia release: passed
  • docs and doctests on Julia 1.10: passed
  • Runic 1.7.0 check on Julia release: passed
  • git diff --check: passed

The machine has no MATLAB installation or license, so MATLAB-engine solver executions could not run locally. The full package suite passed using MATLAB.jl's documented CI=true build mode; the repository's existing runtime guard consequently reported no engine-dependent test cases.

Ignore this PR until it has been reviewed by @ChrisRackauckas.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
@ChrisRackauckas
ChrisRackauckas marked this pull request as ready for review August 8, 2026 18:39
@ChrisRackauckas
ChrisRackauckas merged commit 4fdd039 into SciML:master Aug 8, 2026
9 checks passed
ChrisRackauckas added a commit that referenced this pull request Aug 23, 2026
`Document MATLAB solver API and enable strict QA` (4fdd039, #94) dropped
`@reexport using DiffEqBase` from src/MATLABDiffEq.jl. That reexport was the only
thing putting `ODEProblem`, `solve`, `ReturnCode` and the rest of the common
interface into scope, so the README's documented workflow

    using MATLABDiffEq, ParameterizedFunctions
    prob = ODEProblem(f, u0, tspan)
    sol = solve(prob, MATLABDiffEq.ode45())

stopped working with `UndefVarError`. The same commit is its own best evidence:
it had to rewrite both README examples to
`using MATLAB, MATLABDiffEq, ParameterizedFunctions, SciMLBase` and to write the
new docs/src/index.md example as `using MATLABDiffEq, SciMLBase`. Papering over
the documentation is not the same as keeping the interface.

Rather than restore the blanket reexport (420 names, most of them for equation
classes MATLAB's ODE suite cannot solve), export exactly the interface a user
works with:

  * the problem, function and solution types for ODEs, the only class `__solve`
    accepts here: `ODEProblem`, `ODEFunction`, `ODESolution`, plus `DEStats` and
    `NullParameters`;
  * `solve` and `remake`;
  * `ReturnCode` and `successful_retcode`;
  * the ensemble types, which drive `solve` generically.

Deliberately left out: DAE/SDE/DDE and every other non-ODE problem type, the
callbacks (`__solve` errors with "Callbacks are not supported in
MATLABDiffEq.jl"), and the integrator interface (MATLABDiffEq implements
`__solve` only). Those names error identically before and after. The MATLAB
algorithms themselves stay `@public` but unexported, so they are still written
qualified as `MATLABDiffEq.ode45()`.

Restore both README examples to `using MATLABDiffEq, ParameterizedFunctions` and
the docs/src/index.md example to a bare `using MATLABDiffEq`.

Document the reexported surface on a new rendered API page, docs/src/api.md,
grouped by role with SciMLBase named and linked as the owner of every name, a
closing boundary line, and the reasoning for each deliberate omission. Wire the
page into docs/make.jl.

The list is declared through `reexports_allow` in test/qa/qa.jl and covered by a
test that every approved name is in `names(MATLABDiffEq)` and actually in scope
from `using MATLABDiffEq`, so the docs list, the `export` block and the
allow-list cannot drift apart.

Adding back names that used to be exported is not breaking.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rmh6B9eoW3N8oCbuuVPVxJ
ChrisRackauckas added a commit that referenced this pull request Aug 23, 2026
`Document MATLAB solver API and enable strict QA` (4fdd039, #94) dropped
`@reexport using DiffEqBase` from src/MATLABDiffEq.jl. That reexport was the only
thing putting `ODEProblem`, `solve`, `ReturnCode` and the rest of the common
interface into scope, so the README's documented workflow

    using MATLABDiffEq, ParameterizedFunctions
    prob = ODEProblem(f, u0, tspan)
    sol = solve(prob, MATLABDiffEq.ode45())

stopped working with `UndefVarError`. The same commit is its own best evidence:
it had to rewrite both README examples to
`using MATLAB, MATLABDiffEq, ParameterizedFunctions, SciMLBase` and to write the
new docs/src/index.md example as `using MATLABDiffEq, SciMLBase`. Papering over
the documentation is not the same as keeping the interface.

Rather than restore the blanket reexport (420 names, most of them for equation
classes MATLAB's ODE suite cannot solve), export exactly the interface a user
works with:

  * the problem, function and solution types for ODEs, the only class `__solve`
    accepts here: `ODEProblem`, `ODEFunction`, `ODESolution`, plus `DEStats` and
    `NullParameters`;
  * `solve` and `remake`;
  * `ReturnCode` and `successful_retcode`;
  * the ensemble types, which drive `solve` generically.

Deliberately left out: DAE/SDE/DDE and every other non-ODE problem type, the
callbacks (`__solve` errors with "Callbacks are not supported in
MATLABDiffEq.jl"), and the integrator interface (MATLABDiffEq implements
`__solve` only). Those names error identically before and after. The MATLAB
algorithms themselves stay `@public` but unexported, so they are still written
qualified as `MATLABDiffEq.ode45()`.

Restore both README examples to `using MATLABDiffEq, ParameterizedFunctions` and
the docs/src/index.md example to a bare `using MATLABDiffEq`.

Document the reexported surface on a new rendered API page, docs/src/api.md,
grouped by role with SciMLBase named and linked as the owner of every name, a
closing boundary line, and the reasoning for each deliberate omission. Wire the
page into docs/make.jl.

The list is declared through `reexports_allow` in test/qa/qa.jl and covered by a
test that every approved name is in `names(MATLABDiffEq)` and actually in scope
from `using MATLABDiffEq`, so the docs list, the `export` block and the
allow-list cannot drift apart.

Adding back names that used to be exported is not breaking.



Claude-Session: https://claude.ai/code/session_01Rmh6B9eoW3N8oCbuuVPVxJ

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants