Use DEFAULT_SPECIALIZATION for all SciMLFunction constructors#1298
Merged
ChrisRackauckas merged 1 commit intoMar 29, 2026
Merged
Conversation
Change all SciMLFunction constructors (ODEFunction, NonlinearFunction, DAEFunction, SDEFunction, DDEFunction, DiscreteFunction, RODEFunction, BVPFunction, IntegralFunction, etc.) to use DEFAULT_SPECIALIZATION instead of hardcoded FullSpecialize. DEFAULT_SPECIALIZATION is set via Preferences and defaults to AutoSpecialize. The preference system already existed but constructors were bypassing it. The only places that retain explicit FullSpecialize are: - The struct definition itself - unwrapped_f methods (which construct fully-typed copies) - Documentation/comments Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ChrisRackauckas-Claude
force-pushed
the
nonlinear-autospecialize-default
branch
from
b14675e to
28e884f
Compare
ChrisRackauckas-Claude
changed the title
ChrisRackauckas-Claude
pushed a commit
to ChrisRackauckas-Claude/SciMLBase.jl
that referenced
this pull request
Mar 29, 2026
The change in SciML#1298 exposed multiple breaking issues: - BigFloat tableau coefficients promote t past FunctionWrapper signatures - GradientTracer/sparsity detection types not in wrapper signatures - MatrixOperator jac_prototype causes promote_op → Union{} in promote_f - Hard DAE numerical accuracy regression with wrapped functions Deferring this to v4 where the underlying issues (tableau two-type constructors, promote_f robustness) can be addressed properly. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ChrisRackauckas-Claude
pushed a commit
to ChrisRackauckas-Claude/SciMLBase.jl
that referenced
this pull request
Mar 30, 2026
Only reverts ODEFunction, SplitFunction, and DynamicalODEFunction back to FullSpecialize. Other function types (NonlinearFunction, SDEFunction, DiscreteFunction, etc.) keep DEFAULT_SPECIALIZATION from SciML#1298. The ODEFunction change exposed multiple issues in OrdinaryDiffEq.jl: - BigFloat tableau c promotes t past FunctionWrapper signatures - GradientTracer types not in wrapper signatures (AutoSparse) - MatrixOperator jac_prototype causes promote_op → Union{} - Hard DAE numerical accuracy regression Deferring ODEFunction AutoSpecialize default to v4. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Summary
NonlinearFunctionconstructors to useDEFAULT_SPECIALIZATION(defaults toAutoSpecializevia Preferences) instead of hardcodedFullSpecializeDEFAULT_SPECIALIZATIONalready exists and defaults toAutoSpecialize, but theNonlinearFunctionconstructors were bypassing itMotivation
SciML/NonlinearSolve.jl#838 adds AutoSpecialize/norecompile infrastructure to NonlinearSolve. When
NonlinearFunctionusesAutoSpecialize, NonlinearSolve wraps the function inFunctionWrappersso that solving with different functions doesn't trigger recompilation each time. Benchmarks show ~85% reduction in per-function compilation overhead.Without NonlinearSolve.jl#838 merged,
AutoSpecializeis a no-op — the trait is stored in the type parameter but never read. So this change is backwards compatible.What changes
Users can override via
Preferences.@set_preferences!("SciMLBase", "SpecializationLevel" => "FullSpecialize")if needed.🤖 Generated with Claude Code
Co-Authored-By: Chris Rackauckas accounts@chrisrackauckas.com