OrdinaryDiffEq.jl
OrdinaryDiffEq.jl copied to clipboard
Verbosity flag not correctly passed to linear solver
Reproducer
using DifferentialEquations, IterativeSolvers, LinearSolve
function lorenz!(du,u,p,t)
du[1] = 10.0*(u[2]-u[1])
du[2] = u[1]*(28.0-u[3]) - u[2]
du[3] = u[1]*u[2] - (8/3)*u[3]
end
u0 = [1.0;0.0;0.0]
T = 100.0
tspan = (0.0,T)
problem = ODEProblem(lorenz!,u0,tspan)
Δt_save = 0.1
timestepper = ImplicitEuler(linsolve = IterativeSolversJL_GMRES(; abstol=1e-8, reltol=1e-6))
integrator = init(
problem, timestepper,
adaptive=true, abstol=1e-3, reltol=1e-3,
progress=true, progress_steps=1,
saveat=Δt_save, verbose=true
);
integrator = TimeChoiceIterator(integrator, 0.0:Δt_save:T)
for (u_uc,t) in integrator
@show u_uc
end
This is an OrdinaryDiffEq issue and not a LinearSolve.jl one. Pretty straightforward to fix though, just needs to be passed in the linear solve init
s in the cache constructors.
Then I will try to grab this.
Since I am back here, let me try to get the discussion rolling.
I think there is some information which we want to have when debugging convergence issues.
For adaptive solvers we want to have some information about the error estimation and reason for rejection/retry of the step. For stiff solvers some information about the nonlinear solver is needed, e.g. current iteration and the convergence measure. Finally there might be issues in the linear solver, for which we to print out, which was the original concern of the issue. I did a prototype for this in the PR liked above, but the problem with just passing down the verbosity flag is that we do not have fine grained control about the outputs, such that we may get drained in noise if we just print out everything.
I think we can approach this by introducing for the subpackages (LinearSolve.jl, NonlinearSolve.jl, OrdinaryDiffEq.jl,...) either A) some structs to pass down what should be printed per solver or B) we pass down monitoring functions to compute or print information manually
xref https://github.com/termi-official/Thunderbolt.jl/issues/12#issuecomment-2112411365 for some possible design
We should make a set of defined structs in SciMLBase which are like, NonlinearProblemLogger, LinearProblemLogger, with a bunch of booleans or log-levels to turns things on and off. These could nest, so an ODEProblemLogger would have a NonlinearProblemLogger which would have a LinearProblemLogger to give full control all of the way down.