Add SciMLBaseExt

[aj-fleming]

Fixes a possible BoundsError when passing an AbstractInterpolation as a parameter to a SciML problem constructor (DifferentialEquations.jl, NonlinearSolve.jl, Optimization.jl, etc..) where the fact that AbstractInterpolation{<:AbstractArray} <: AbstractArray{<:AbstractArray} would cause the parameter type warning check to iterate over the AbstractInterpolation.

Changes:

• Adds an extension for SciMLBase
• Adds test for the parameter type warning

Example Error Details:

Details

ERROR: BoundsError: attempt to access 253-element interpolate((::Vector{Float64},), ::Vector{SVector{2, Float64}}, Gridded(Linear())) with element type SVector{2, Float64} at index [2]
Stacktrace:
  [1] throw_boundserror(A::Interpolations.GriddedInterpolation{SVector{2, Float64}, 1, Vector{SVector{2, Float64}}, Interpolations.Gridded{Interpolations.Linear{Interpolations.Throw{Interpolations.OnGrid}}}, Tuple{Vector{Float64}}}, I::Tuple{Int64})
    @ Base ./essentials.jl:15
  [2] GriddedInterpolation
    @ ~/.julia/packages/Interpolations/rXcvn/src/gridded/indexing.jl:3 [inlined]
  [3] getindex
    @ ~/.julia/packages/Interpolations/rXcvn/src/Interpolations.jl:420 [inlined]
  [4] iterate
    @ ./abstractarray.jl:1235 [inlined]
  [5] _any(f::typeof(SciMLBase.should_warn_paramtype), itr::Interpolations.GriddedInterpolation{SVector{2, Float64}, 1, Vector{SVector{2, Float64}}, Interpolations.Gridded{Interpolations.Linear{Interpolations.Throw{Interpolations.OnGrid}}}, Tuple{Vector{Float64}}}, ::Colon)
    @ Base ./anyall.jl:130
  [6] any
    @ ./reducedim.jl:989 [inlined]
  [7] should_warn_paramtype
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/performance_warnings.jl:5 [inlined]
  [8] _any_tuple
    @ ./anyall.jl:146 [inlined]
  [9] _any_tuple
    @ ./anyall.jl:152 [inlined]
 [10] any
    @ ./anyall.jl:142 [inlined]
 [11] should_warn_paramtype
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/performance_warnings.jl:6 [inlined]
 [12] warn_paramtype (repeats 2 times)
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/performance_warnings.jl:31 [inlined]
 [13] _
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/problems/optimization_problems.jl:121 [inlined]
 [14] OptimizationProblem
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/problems/optimization_problems.jl:110 [inlined]
 [15] #OptimizationProblem#596
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/problems/optimization_problems.jl:137 [inlined]
 [16] OptimizationProblem
    @ ~/.julia/packages/SciMLBase/7YrMQ/src/problems/optimization_problems.jl:133 [inlined]
 [17] w_star(shock::Euler2D.BowShockInterpolation.ShockInterpolation{Float64}, point::SVector{2, Float64})
    @ Euler2D.BowShockInterpolation ~/projects/stce/shockad/Euler2D/src/postprocessing/shock_interpolation.jl:244
 [18] top-level scope
    @ REPL[15]:1

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.84%. Comparing base (457f9d1) to head (d25f4f1).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #652      +/-   ##
==========================================
+ Coverage   87.83%   87.84%   +0.01%     
==========================================
  Files          29       30       +1     
  Lines        1907     1909       +2     
==========================================
+ Hits         1675     1677       +2     
  Misses        232      232              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mkitti]

I'm a little suprised to see this as https://github.com/SciML/DataInterpolations.jl is usually the intepolations package to use with the SciML ecosystem.

I'm a little confused how "not warning" elides an error.

[Copilot]

Pull request overview

Adds a SciMLBase package extension so SciMLBase’s parameter-type warning logic can safely handle Interpolations.AbstractInterpolation{<:AbstractArray} parameters (e.g., in DifferentialEquations/Optimization problem constructors) without triggering BoundsErrors from iterating the interpolation as an AbstractArray.

Changes:

• Add InterpolationsSciMLBaseExt extension to override SciMLBase.should_warn_paramtype for AbstractInterpolation{<:AbstractArray}.
• Add SciMLBase-focused tests and wire them into the test suite.
• Register SciMLBase as a weak dep + extension + test dependency in Project.toml.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 4 comments.

File	Description
ext/InterpolationsSciMLBaseExt.jl	Adds SciMLBase extension method for should_warn_paramtype on interpolations of arrays.
test/scimlbase.jl	Adds tests for SciMLBase should_warn_paramtype behavior with interpolations.
test/runtests.jl	Includes the new SciMLBase test file in the test run.
Project.toml	Adds SciMLBase as a weakdep/extension and includes it in test extras/targets + compat.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aj-fleming]

I'm a little suprised to see this as https://github.com/SciML/DataInterpolations.jl is usually the intepolations package to use with the SciML ecosystem.

DataInterpolations.jl wasn't known to me. I could just switch.

I'm a little confused how "not warning" elides an error.

getindex on an AbstractInterpolation only works inside the knot domain; if eltype(...) of the interpolation is also an AbstractArray, then the default SciML behavior is then to use any, which iterates over each element of the AbstractInterpolation, which doesn't work if the domain of the interpolation is smaller than its range of indices.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

[aj-fleming]

Unless there are any other suggestions from the maintainers (or the robot, on their behalf), I am satisfied with this.

[ChrisRackauckas]

This is reasonable. Though generally the rule is to put the extension where the non-public API lives. IIUC, this is using public API of Interpolations.jl and non-public API of SciMLBase, so the fitting place would likely be SciMLBase. But if you want to maintain it here, that would be fine, it's just not guaranteed to continue to work here.

[aj-fleming]

[...] IIUC, this is using public API of Interpolations.jl and non-public API of SciMLBase, so the fitting place would likely be SciMLBase. [...]

This change uses non-public API of both packages. I guess it could work with knots(...) instead of coefficients(...), in which case, I can submit the same change on the SciML side.

[asinghvi17]

Yeah, looking at what this PR is doing, I would definitely prefer for it to live in SciMLBase