You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
using OrdinaryDiffEq
using ComponentArrays
using Parameters
using SciMLNLSolve
using LinearSolve
p = ComponentArray(a=0.04,b=1e4,c=3e7,d=1.0)
u0 = ComponentArray(x1=1.0,x2=0.0,x3=0.0)
function f(resid,du,u,p,t)
@unpack a,b,c,d=p
resid[1] = - a*u[1] + b*u[2]*u[3] - du[1]
resid[2] = + a*u[1] - c*u[2]^2 - b*u[2]*u[3] - du[2]
resid[3] = u[1] + u[2] + u[3] - d
end
du0 = similar(u0)
fill!(du0,0.0)
tspan = (0.0,1e5)
prob = DAEProblem(f,du0,u0,tspan,p,differential_vars=[true,true,false])
This all works fine. Unfortunately, when passed into a solver, sol = solve(prob,DFBDF())
The default linear solver in this case will be KrylovJL_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 SciML/OrdinaryDiffEq.jl#1673
Moving to different choices in nonlinear solvers, we have a different issue: solve(prob,DFBDF(NLSolveJL()))
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 and ComponentArrays.
The text was updated successfully, but these errors were encountered:
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 ComponentArrays, StaticArrays, and similar types of arrays that encode their size (in one way or another) in the type domain. The approach for ComponentArrays and StaticArrays 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 be
KrylovJL_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 SciML/OrdinaryDiffEq.jl#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
.The text was updated successfully, but these errors were encountered: