gdalle
commented
1 month ago Further investigation: when I run the tests with
julia --check-bounds=yesI get a different error:
julia> sol1 = solve(bvp1, solver; dt=dt)
ERROR: BoundsError: attempt to access 4-element UnitRange{Int64} at index [5]
Stacktrace:
[1] throw_boundserror(A::UnitRange{Int64}, I::Int64)
@ Base ./abstractarray.jl:737
[2] getindex
@ ./range.jl:930 [inlined]
[3] _colorediteration!
@ ~/.julia/packages/FiniteDiff/wm6iC/src/iteration_utils.jl:4 [inlined]
[4] forwarddiff_color_jacobian!(J::SubArray{…}, f::BoundaryValueDiffEq.__Fix3{…}, x::Vector{…}, jac_cache::ForwardColorJacCache{…})
@ SparseDiffTools ~/.julia/packages/SparseDiffTools/RGOJw/src/differentiation/compute_jacobian_ad.jl:392
[5] sparse_jacobian!
@ ~/.julia/packages/SparseDiffTools/RGOJw/src/highlevel/forward_mode.jl:63 [inlined]
[6] __mirk_mpoint_jacobian!(J::Matrix{…}, ::BandedMatrices.BandedMatrix{…}, x::Vector{…}, bc_diffmode::AutoForwardDiff{…}, nonbc_diffmode::AutoSparse{…}, bc_diffcache::SparseDiffTools.ForwardDiffJacobianCache{…}, nonbc_diffcache::SparseDiffTools.ForwardDiffJacobianCache{…}, loss_bc::BoundaryValueDiffEq.__Fix3{…}, loss_collocation::BoundaryValueDiffEq.__Fix3{…}, resid_bc::Vector{…}, resid_collocation::Vector{…}, L::Int64)
@ BoundaryValueDiffEq ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/solve/mirk.jl:390
[7] #268
@ ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/solve/mirk.jl:371 [inlined]
[8] JacobianCache
@ ~/.julia/dev/NonlinearSolve/src/internal/jacobian.jl:149 [inlined]
[9] JacobianCache
@ ~/.julia/dev/NonlinearSolve/src/internal/jacobian.jl:120 [inlined]
[10] __step!(cache::NonlinearSolve.GeneralizedFirstOrderAlgorithmCache{…}; recompute_jacobian::Nothing, kwargs::@Kwargs{})
@ NonlinearSolve ~/.julia/dev/NonlinearSolve/src/core/generalized_first_order.jl:230
[11] __step!
@ ~/.julia/dev/NonlinearSolve/src/core/generalized_first_order.jl:226 [inlined]
[12] #step!#131
@ ~/.julia/dev/NonlinearSolve/src/core/generic.jl:50 [inlined]
[13] step!
@ ~/.julia/dev/NonlinearSolve/src/core/generic.jl:45 [inlined]
[14] solve!(cache::NonlinearSolve.GeneralizedFirstOrderAlgorithmCache{…})
@ NonlinearSolve ~/.julia/dev/NonlinearSolve/src/core/generic.jl:13
[15] #__solve#130
@ ~/.julia/dev/NonlinearSolve/src/core/generic.jl:4 [inlined]
[16] __solve
@ ~/.julia/dev/NonlinearSolve/src/core/generic.jl:1 [inlined]
[17] macro expansion
@ ~/.julia/dev/NonlinearSolve/src/default.jl:282 [inlined]
[18] __solve(::NonlinearProblem{…}, ::NonlinearSolvePolyAlgorithm{…}; stats::SciMLBase.NLStats, alias_u0::Bool, verbose::Bool, kwargs::@Kwargs{…})
@ NonlinearSolve ~/.julia/dev/NonlinearSolve/src/default.jl:255
[19] __perform_mirk_iteration(cache::BoundaryValueDiffEq.MIRKCache{…}, abstol::Float64, adaptive::Bool; nlsolve_kwargs::@NamedTuple{}, kwargs::@Kwargs{…})
@ BoundaryValueDiffEq ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/solve/mirk.jl:175
[20] __perform_mirk_iteration
@ ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/solve/mirk.jl:171 [inlined]
[21] solve!(cache::BoundaryValueDiffEq.MIRKCache{…})
@ BoundaryValueDiffEq ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/solve/mirk.jl:152
[22] #__solve#296
@ ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/BoundaryValueDiffEq.jl:51 [inlined]
[23] __solve
@ ~/.julia/packages/BoundaryValueDiffEq/YN0of/src/BoundaryValueDiffEq.jl:49 [inlined]
[24] #solve_call#44
@ ~/.julia/packages/DiffEqBase/vscDj/src/solve.jl:612 [inlined]
[25] solve_call
@ ~/.julia/packages/DiffEqBase/vscDj/src/solve.jl:569 [inlined]
[26] solve_up(prob::BVProblem{…}, sensealg::Nothing, u0::Vector{…}, p::Tuple{…}, args::MIRK4{…}; kwargs::@Kwargs{…})
@ DiffEqBase ~/.julia/packages/DiffEqBase/vscDj/src/solve.jl:1084
[27] solve_up
@ ~/.julia/packages/DiffEqBase/vscDj/src/solve.jl:1070 [inlined]
[28] solve(prob::BVProblem{…}, args::MIRK4{…}; sensealg::Nothing, u0::Nothing, p::Nothing, wrap::Val{…}, kwargs::@Kwargs{…})
@ DiffEqBase ~/.julia/packages/DiffEqBase/vscDj/src/solve.jl:1007
[29] top-level scope
@ ~/Work/GitHub/Julia/Sandbox/test.jl:47
Some type information was truncated. Use `show(err)` to see complete types.So the one I was observing before might have been due to incorrect use of @inbounds in FiniteDiff:
ChrisRackauckas
avik-pal
Describe the bug 🐞
The new NonlinearSolve v3.15 (with DI in it) causes a BoundaryValueDiffEq solve to error or segfault.
Expected behavior
The solve should run without errors, as it does with NonlinearSolve 3.14.
Minimal Reproducible Example 👇
Error & Stacktrace ⚠️
Environment (please complete the following information):
using Pkg; Pkg.status()using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)versioninfo()Additional context
The bug is probably not deterministic. Sometimes it doesn't even happen, and sometimes it downright causes a segfault.
By
pkg> dev-ing NonlinearSolve and adding some logging before linesrc/internal/linear_solve.jl:231, I obtained some more information about the matriceslincache.Aandnew_A:In other words, the
copyto!fails even though both matrices have the samesize, because the one fromlincachedoesn't have the rightlength. Note thatlength(lincache.A)is not always 1.