Open aabills opened 2 years ago
Hey Alec. Yeah, I think I need to explicitly add some of the factorizations. A lot of them don’t work because they call a similar
method that is fundamentally type-unstable with ComponentArray
s, StaticArray
s, and similar types of arrays that encode their size (in one way or another) in the type domain. The approach for ComponentArray
s and StaticArray
s is just to fall back to a plain Matrix
in these cases, which tends to break things down the line that expect them to be the same type as what went into the factorization. So I think that’s what’s happening here.
I’ll take a look at it when I get the chance. Unfortunately I’ve kinda got a backlog of issues to fix this week and haven’t had time to commit to them.
Hi! My team and I stumbled upon this package and have found it really useful in our current project. Unfortunately though, we're having trouble getting it to play nicely with much of the DAE ecosystem in DifferentialEquations.jl, and in particular with linear solvers and nonlinear solvers. Here're a few MW examples:
Top of file:
This all works fine. Unfortunately, when passed into a solver,
sol = solve(prob,DFBDF())
The default linear solver in this case will beKrylovJL_GMRES()
and it will error with this stack trace:This error occurs when using any solver from Krylov.jl.
Taking a look at the first line of the stack trace, it looks like Krylov is attempting to create an empty array, by a syntax which is not compatible with
ComponentArrays
.I also wanted to try IterativeSolvers.jl, but unfortunately it doesn't seem to work at all with
DAEProblem
(see https://github.com/SciML/OrdinaryDiffEq.jl/issues/1673Moving to different choices in nonlinear solvers, we have a different issue:
solve(prob,DFBDF(NLSolveJL()))
Results in:
This is true for any NLSolve solver. Some things do work! For example,
solve(prob,DFBDF(linsolve=LUFactorization())
works fine. However, it'd be amazing to have more compatibility of DAE's andComponentArrays
.