Skip to content

Releases: SciML/Sundials.jl

v5.1.0

08 Oct 09:30
1cff2a4

Choose a tag to compare

v5.0.0

17 Sep 15:04
d77ca0f

Choose a tag to compare

Sundials v5.0.0

Diff since v4.28.0

Breaking Changes

Upgrade to Sundials v7

This release updates the underlying Sundials C library from v5 to v7, which introduces significant API changes. This is a breaking change for users directly using the low-level Sundials API.

Key Changes:

  1. SUNContext requirement: All Sundials objects now require a SUNContext object for creation. This context manages the Sundials environment and must be created before any solver objects.

  2. Memory management: The new context-based approach improves thread safety and resource management.

Migration Guide for Low-Level API Users:

If you're using the low-level Sundials API directly (not through the DiffEq interface):

# Old code (v4.x) - No context needed
mem_ptr = CVodeCreate(CV_BDF)
mem = Handle(mem_ptr)
# New code (v5.0) - Context required
ctx_ptr = Ref{SUNContext}(C_NULL)
SUNContext_Create(C_NULL, Base.unsafe_convert(Ptr{SUNContext}, ctx_ptr))
ctx = ctx_ptr[]
mem_ptr = CVodeCreate(CV_BDF, ctx)  # Context passed as argument
mem = Handle(mem_ptr)
# ... use solver ...
SUNContext_Free(ctx)  # Clean up context when done

Automatic handling in high-level interface:

If you're using the standard DiffEq interface (solve(prob, CVODE_BDF())), no changes are needed. The context is automatically managed internally:

# This continues to work without changes
sol = solve(prob, CVODE_BDF())

Functions affected by context requirement:

  • All solver creation functions (CVodeCreate, ARKStepCreate, IDACreate, KINCreate)
  • All vector creation functions (N_VNew_Serial, etc.)
  • All matrix creation functions (SUNDenseMatrix, SUNBandMatrix, etc.)
  • All linear solver creation functions (SUNLinSol_Dense, etc.)

The context is automatically freed when the integrator is garbage collected through the ContextHandle mechanism.

DAE Initialization Algorithm Changes

The default initialization behavior for DAE problems has changed significantly. This is a breaking change that may affect existing code using IDA.

Previous behavior:

  • IDA would automatically attempt to compute consistent initial conditions by default
  • This automatic initialization could sometimes produce incorrect results without warning

New behavior:

  • The default is now validation-only mode that checks if provided initial conditions are consistent
  • If initial conditions are inconsistent, an error is raised with a clear message
  • Automatic initialization must be explicitly requested

Migration Guide:

If you have existing code that relies on automatic DAE initialization:

# Old code (v4.x) - automatic initialization was implicit
prob = DAEProblem(f, du0, u0, tspan, differential_vars = differential_vars)
sol = solve(prob, IDA())

You now have several options:

  1. Use automatic initialization explicitly (recommended for most users):
using DiffEqBase: BrownFullBasicInit
prob = DAEProblem(f, du0, u0, tspan, differential_vars = differential_vars)
sol = solve(prob, IDA(), initializealg = BrownFullBasicInit())
  1. Provide consistent initial conditions:
# Ensure du0 and u0 satisfy f(du0, u0, p, t0) = 0
prob = DAEProblem(f, du0, u0, tspan, differential_vars = differential_vars)
sol = solve(prob, IDA())  # Will validate and proceed if consistent
  1. For problems without differential_vars information:
using DiffEqBase: ShampineCollocationInit
prob = DAEProblem(f, du0, u0, tspan)  # No differential_vars
sol = solve(prob, IDA(), initializealg = ShampineCollocationInit())

Available initialization algorithms:

  • DefaultInit() - Intelligently chooses initialization based on problem type (new default)
  • BrownFullBasicInit() - Brown's algorithm for index-1 DAEs (requires differential_vars)
  • ShampineCollocationInit() - Shampine's collocation method (works without differential_vars)
  • CheckInit() - Only validates initial conditions without modification

Why this change was made:

  • Safety: Silent automatic initialization could produce incorrect results
  • Clarity: Users now explicitly choose their initialization strategy
  • Debugging: Clearer error messages when initial conditions are inconsistent
  • Performance: Avoid unnecessary initialization computations when not needed

ModelingToolkit Initialization Support

CVODE and ARKODE now support the initializealg parameter for parameter initialization compatibility with ModelingToolkit. This enables proper handling of problems with initialization requirements.

# Now supported for ODE problems with initialization needs
sol = solve(prob, CVODE_BDF()) # , initializealg = SciMLBase.OverrideInit()) done by default

Features

  • Added support for DiffEqBase initialization algorithms across all Sundials solvers
  • Improved callback handling to use callback-specific initialization algorithms
  • Enhanced error messages for DAE initialization failures

Dependency Updates

  • Sundials_jll: Updated from v5.x to v7.4.1 (major version bump)
  • Minimum DiffEqBase version: 6.190.2
  • Added NonlinearSolveBase dependency for improved nonlinear solving
  • Added LinearSolve dependency for initialization support
  • Updated minimum SciMLBase version to 2.119.0

Merged pull requests:

Closed issues:

  • Kinsol is unstable for multiple variable problems (#220)
  • Error with optional flag set on IDA. (#241)
  • Structs for the method choices (#242)
  • Refactoring (#250)
  • Failed ODE does not return the expected retcode (#283)
  • Unify Sundials initialization options with the rest of DiffEq (#285)
  • LabelledArrays Error (#296)
  • CVODE_BDF: Event points are not stored (#309)
  • Question about the Cvode(cvode_mem, tout, y0, &t, CV_NORMAL) command (#354)
  • Memory leak in threaded calls to CVODE (#388)
  • kinsol interface for GMRES missing (#405)
  • Update to Sundials 6.5 (#413)
  • Sundials not hooked up with MTK custom initialization (#469)
  • Test failures on windows (#496)
  • Fix CI issues (#497)
  • Deprecations in the testsuite (#499)

v4.28.0

17 Apr 21:48

Choose a tag to compare

Sundials v4.28.0

Diff since v4.27.0

v4.27.0

20 Mar 16:31
769b890

Choose a tag to compare

Sundials v4.27.0

Diff since v4.26.1

Merged pull requests:

Closed issues:

  • LoadError: InitError: could not load library "/cache/julia-buildkite-plugin/depots/5b300254-1738-4989-ae0a-f4d2d937f953/artifacts/cb7fc2801ca0133a5bdea4bc4585d07c08284cfa/lib/libsundials_sunlinsolklu.so" (#465)

v4.26.1

08 Nov 10:41
cdde5c9

Choose a tag to compare

Sundials v4.26.1

Diff since v4.26.0

Merged pull requests:

  • ci: test with 1, lts and pre versions of julia (#462) (@thazhemadam)
  • Support the expanded change_t_via_interpolation! interface (#463) (@BenChung)

v4.26.0

11 Oct 06:33
d22dbf3

Choose a tag to compare

Sundials v4.26.0

Diff since v4.25.0

Merged pull requests:

Closed issues:

  • saveat includes save_start and save_end for ARKODE() but not for others (#460)

v4.25.0

18 Aug 18:09
d7e83c0

Choose a tag to compare

Sundials v4.25.0

Diff since v4.24.0

Merged pull requests:

Closed issues:

  • Sundials.jl errored during testing. (#450)

v4.24.0

15 Feb 17:53
1ca5ee4

Choose a tag to compare

Sundials v4.24.0

Diff since v4.23.2

Merged pull requests:

Closed issues:

  • ERROR: Package Sundials errored during testing (#391)
  • IDA fails to solve when encountering algebraically inconsistent u after callback (#449)

v4.23.2

27 Jan 13:48
ce4753f

Choose a tag to compare

Sundials v4.23.2

Diff since v4.23.1

Merged pull requests:

Closed issues:

  • v4.19.4 CVODE recoverable warnings now cause failures (#420)
  • Allocations in convert(Ptr{T}, Handle{T}) (#435)
  • Latest Sundials does not work on Julia v1.11+ (#441)
  • Lots of warnings while running tests in 1.11-dev (#442)

v4.23.1

24 Dec 16:42

Choose a tag to compare

Sundials v4.23.1

Diff since v4.23.0

Merged pull requests: