Open ivarne opened 10 years ago
I'm very amused to see this (as well as other convergent discussions), as I've been secretly working on writing IterativeSolvers as iterators and I really like how it's turning out. See this gist for a working implementation of conjugate gradients.
Also observing parallel discussions about APIs makes me think that we should work toward a closer interface for both ODE.jl and IterativeSolvers.jl, especially since many of the latter can be interpreted as Galerkin-type discretizations of the former.
This is a fantastic idea - it solves so many problems at once. Event functions are really a quite hairy solution to a problem that this approach could possibly solve much better.
It would also be entirely possible to wrap the current implementation in an iterative approach:
function ode(F, y0, tspan)
tout = []
yout = []
for t, y in ode_iter(F, y0, 0) # why would we need an end value?
push_back(tout, t)
push_back(yout, y)
if t >= tspan[end]
break
end
end
This has the disadvantage of not giving a solution point exactly at tspan[end]
, but that could be solved e.g. with a keyword argument (gandalf
? ;) to the iterative solver which it shall not pass.
I think the iteration interface is a good thing to explore to see if we have the flexibility we need. It seems to solve some problems, and we can probably extend the start
, done
, next
interface for more advanced control of the iteration.
@tlycken gandalf
will have to work on y
values also, because it would be nice to be able to keep the y
values from overshooting. I have had that problem when the value of y[1]→0
when t→∞
, and negative y
values brought me into imaginary space.
@ivarne Overshooting is an entirely separate problem, to which a keyword argument with a boundary value may or may not be a good solution. (And I'll get back to it shortly.) For now, I was simply referring to the fact that when I call ode(F, y0, [t0, tfinal])
I expect to have a solution point exactly at tfinal
- and without any way of controlling the step length of the iterative solver in each step, we wouldn't be able to use it as our main implementation. Thus, we need a keyword argument which, if it is given, specifies a time tf
(a.k.a. gandalf
) which the iterative solver must not step past; if it wants to step further than tf
, the step size is reduced so that the next solution point (t,y)
which is returned is exactly at tf
.
I was thinking about https://github.com/JuliaLang/ODE.jl/issues/11 and just relaised that an iterator version of the ODE solvers might be a viable solution. As this is a different idea than the event function, I opened a new issue.
This can also be very convenient for plotting partial results and to be able to track the solvers progress.