Where to report a bug in OrdinaryDiffEqBDF

General Usage
, ,
1

KiteModels.jl precompiles successfully now with max_order: 5, but not with max_order: 4. This is just a workaround for the bug in OrdinaryDiffEqBDF v1.17.0. You should still report the Val(5) hardcoding bug upstream so max_order: 4 (and 3) works correctly too.

This bug appeared after upgrading OrdinaryDiffEqCore to 3.5.

  1. Your code creates a DFBDF solver with max_order=4
    In KiteModels.jl:569, when solver==“DFBDF”:

solver = DFBDF(autodiff=AutoFiniteDiff(), max_order=Val{4}())
The DFBDF algorithm struct stores max_order as a type parameter MO=4.

  1. The cache is constructed with mismatched sizes
    In dae_caches.jl, function alg_cache for DFBDF{MO} where MO=4:

dense = [zero(u) for _ in 1:(2 * (max_order + 1))] # max_order=MO=4 → 10 elements
But then the constructor call hardcodes Val(5) instead of using Val(MO):

return DFBDFCache( fsalfirst, nlsolver, ts, ts_tmp, t_old, u_history, order, prev_order, u_corrector, u₀, bdf_coeffs, Val(5), # ← BUG: should be Val(MO) or Val(max_order) nconsteps, consfailcnt, tmp, atmp, … dense # ← has only 10 elements (for max_order=4))
This means DFBDFCache{max_order=5, …} — the type says max_order is 5, but the data (dense) was sized for max_order=4.

  1. initialize! trusts the type parameter
    In dae_perform_step.jl:436:

function initialize!(integrator, cache::DFBDFCache{max_order}) where {max_order} integrator.kshortsize = 2 * (max_order + 1) # max_order=5 (from type) → 12 resize!(integrator.k, integrator.kshortsize) # integrator.k has 12 slots for i in 1:(2 * (max_order + 1)) # loops i = 1:12 integrator.k[i] = cache.dense[i] # cache.dense has only 10 elements end # → BoundsError at i=11end
Summary
What Expected (MO=4) Actual (hardcoded Val(5))
cache.dense length 10 10 (sized from MO=4)
Type parameter max_order 4 5 (from Val(5))
Loop range in initialize! 1:10 1:12
The type parameter and the data are out of sync. The dense vector is sized correctly from the runtime MO=4, but Val(5) bakes 5 into the type, so initialize! loops to 12 and overruns the 10-element vector.

Setting max_order: 5 works around it because then dense is sized to 2*(5+1)=12, matching the hardcoded Val(5).

The proper upstream fix is one character: change Val(5) to Val(MO) on line ~299 of dae_caches.jl. (The same file’s alg_cache for FBDFCache has the identical bug with Val(5) on line ~757.)

Claude Opus 4.6 • 3x

2

I don’t see any open issues on that on github, so you might try there.

1 Like