Remove deprecated SparseDiffTools.jl as dependency

[mx-p9a]

SparseDiffTools.jl is deprecated, it should be removed as a dependency.

This is specifically a problem if you're trying to use GXBeam.jl with OrdinaryDiffEq (which require SciMLOperators 1+).

[Cardoza2]

Thanks for bringing that up. We currently use SparseDiffTools for a lot of things and from what I've come to understand that the replacement for SparseDiffTools isn't quite as fast yet. Have you seen anything different? If not, maybe in the mean time I can restrict the upper bound of DifferentialEquations tighter.

[mx-p9a]

Thanks for the quick reply!

I haven't seen any actual benchmarks for that speed difference to tell if it matters in real-world terms or whether it is an academic curiosity.

I have existing libraries that are used the latests version of the SciML ecosystem and I can't revert those, so the upper bound on DifferentialEquations doesn't help my particular case, unfortunately.

If you're looking for advice, I would try the new package and see what is the actual performance delta and whether that is worth it to let this (awesome) package be stuck with older libraries. It very well might be, but would be good to put a number on that?

[Cardoza2]

Yeah, so nothing official, but back in July 2025 for an unsteady aero-structural optimization I was doing I was getting a derivative call time of ~374 seconds with SparseDiffTools and ForwardDiff and a derivative call time of ~512 seconds with DifferentiationInterface. When I was using Julia 1.8, SparseDiffTools and mixed mode AD I had a call time of 127 seconds.

That being said, I'm probably using the new interface incorrectly. gdalle quickly found some large speed ups in other parts of my code. I'll be taking a look at how I can speed things up here in the next while, so I should be able to figure out something faster. Definitely something to keep an eye on. I'll post an update on speeds when I have it.

[gdalle]

Hi @Cardoza2 and @mx-p9a!
Anyone who finds a slowdown going from SparseDiffTools to the DifferentiationInterface stack is more than welcome to open an issue with an MWE. I am very happy to lend a hand but I have limited time, so if there is no obvious and measurable need, things will not get done.

[gdalle]

The reason Chris's complain has gone unanswered is because I've been asking for an MWE for months and he didn't give any ;)

[mx-p9a]

@Cardoza2 took the liberty of having Claude update the code. Not seeing much if any performance degradation on simple benchmarks, but you'd obviously know much better.

[Cardoza2]

@mx-p9a Thanks for checking that. Those results look promising. I'll take a double check over them.

[gdalle]

I'd be very skeptical of benchmarks that are so very similar between both packages

[Cardoza2]

@Cardoza2 took the liberty of having Claude update the code. Not seeing much if any performance degradation on simple benchmarks, but you'd obviously know much better.

@mx-p9a I just also wanted to note that I took over maintaining this repo as part of my PhD work in the FLOW Lab cause my research uses GXBeam, so I'm really grateful for any help I can get on this.

I'm curious, did you use the Claude coding app to have it update the code? I tried the same thing using Copilot (using a Anthropic model) and it failed.

[mx-p9a]

Yes, I used Claude Code with Opus 4.6, it required a bit of nudging, particularly around dependency management, but got there in the end.

[mx-p9a]

@gdalle could you share what you were expecting to happen?

[gdalle]

If you take a look at the benchmarks in #137 (comment), they are identical to a worrying degree. But you changed the sparsity detection method, which should have a big impact on allocations (especially since DI's preparation is not amortized across multiple Jacobians yet). That's what leads me to question whether Claude actually ran the benchmarks

[Cardoza2]

@mx-p9a Do you have the benchmark file still? I've been looking at this in my spare time. I'm curious what Claude actually was trying to do.

Benchmark Results

Benchmark script at benchmark/benchmark.jl using BenchmarkTools.jl (10 samples each):