ChrisRackauckas
commented
3 years ago This has nothing to do with SparseDiffTools.jl so this issue is going to get closed. SparseDiffTools.jl assumes you know the sparsity pattern. The other packages, aren't this package and are in a different org so I can't even transfer the issue hence the close.
SparsityDetection.jl was deprecated because when Symbolics.jl gets a tracer it will be powerful enough to capture any function that this analysis can work on. It's built on Cassette.jl which is getting replaced with new tools, so keeping it alive is something that's a bit of work with a time limit. Instead, SymbolicTracing.jl will get functional in the meantime and will be a an easy way to build a full replacement.
I see that ModelingToolkit.jl does sparsity detection, but I would prefer to make my simple examples work without introducing an entire modeling framework.
You don't need to use a modeling framework to use it, so this comment doesn't make much sense. Why not just apply it to Julia code, just like SparsityDetection.jl?
I have done variants of the "hello world" Poisson-FDM type example and that works fine with excellent performance. I run into errors when I have a custom function where the access pattern is determined by the entries of an Array instead of hard coded in the function body. I know that the sparsity pattern would change if the Array changes, but it would be not change for a given sparsity context. The array is wrapped in a closure, so I did what I could to tell the compiler that the pattern doesn't change based on the inputs exposed to jacobian_sparsity. The code runs through regular (dense) ForwardDiff without issue.
This is something that needs runtime information to be transported to compile time information, which is what symbolic tracers like ModelingToolkit/Symbolics.jl can handle which a purely Cassette-based tool cannot.
function testEq!(eq::Vector, p::Vector, N::Vector, useIndex::Bool)
# Function that accesses two elements for each entry
for i = 1:2
r = N[2];
l = N[1];
eq[i] = IfElse.ifelse(useIndex,p[r] - p[l],p[2] - p[1])
end
endshould be perfectly fine for Symbolics.jl with both bool choices, with if statements being able to be used directly after the symbolic tracer is completed.
Hopefully that makes more sense.
moyner
shashi
Hi,
I'm currently testing some of the Julia AD features on some very large sparse problems and I wanted to try the sparsity detection/coloring. I'm not entirely sure if this issue should go into SciML/SparsityDetection.jl instead, but that module is deprecated according to the README. This module depends on the deprecated module, but seems to be active? I see that ModelingToolkit.jl does sparsity detection, but I would prefer to make my simple examples work without introducing an entire modeling framework.
I have done variants of the "hello world" Poisson-FDM type example and that works fine with excellent performance. I run into errors when I have a custom function where the access pattern is determined by the entries of an Array instead of hard coded in the function body. I know that the sparsity pattern would change if the Array changes, but it would be not change for a given sparsity context. The array is wrapped in a closure, so I did what I could to tell the compiler that the pattern doesn't change based on the inputs exposed to
jacobian_sparsity. The code runs through regular (dense) ForwardDiff without issue.Here is a short MWE that demonstrates the issue:
I have attached the full output + stack trace on a fresh Julia 1.6 install on Windows 10, run in a fresh REPL instance under VSCode. The error is a Casette error so it is pretty long. The key bit is inlined here:
The two identical specializations of the functions only differ in the way the indices 1 and 2 are computed. I can manually enter the sparsity pattern and do coloring etc which works perfectly, but any tips to get this working would be greatly appreciated. Is there some overview of what works and doesn't work for the sparsity detection?
stacktrace.txt