memory issue for large scale problems

[berceanu]

the typical problems i am interested in involve discretization of the spatial part of a PDE and solving for the resulting coupled ODEs. for a fine grid, the solution vector at each time step needs considerable memory. furthermore, i am interested in the steady state solution, after a long evolution time.
is there a way to obtain only aout[end] and discard results for intermediate times?
is this at least considered in the proposed API?

[acroy]

There are two issues here: To get the solution only at the end of the time-evolution you will be able to use the keyword points=:specified and tspan with two elements. This works already on master for ode23s and it will work for the RK family once @mauro3's PR is merged (#68). The other (more severe?) problem is that each call of the function calculating the rhs of your ODE gives rise to (at least) one copy. To fix this we have to allow mutating rhs functions, however there isn't any consensus up to now how to do it (#31 is probably relevant).

[berceanu]

As I already commented on Mauro's PR, I am glad to help with that.

However, even if I get just the solution at the end of the interval, my
memory overflow problem would still be there if copies are made inside
odeXX for each call of the RHS. Reading #31, it is not clear how I can
help with this second issue.

On 05/19/2015 09:45 PM, acroy wrote:

There are two issues here: To get the solution only at the end of the
time-evolution you will be able to use the keyword |points=:specified|
and |tspan| with two elements. This works already on master for
|ode23s| and it will work for the RK family once @mauro3
https://github.com/mauro3's PR is merged (#68
#68). The other (more
severe?) problem is that each call of the function calculating the rhs
of your ODE gives rise to (at least) one copy. To fix this we have to
allow mutating rhs functions, however there isn't any consensus up to
now how to do it (#31 #31
is probably relevant).

—
Reply to this email directly or view it on GitHub
#69 (comment).

[acroy]

I think there was actually a concrete proposal to support in-place rhs in #33 (in particular this comment). That approach should also work with the new solvers.

[mauro3]

It would be fairly trivial to use a mutating fn! in my PR. However, I'm hesitant to make that PR much larger.

Note however, that it is mainly a time-efficiency problem as the arrays produced by old calls to fn can be garbage collected. If you are so memory constraint that you cannot have several state vectors (approximately the number of stages + a few more) then my solvers will not be useful anyway. Then you'd need to look into something like: http://www.davidketcheson.info/assets/papers/2010_LSRK_postprint.pdf

[mauro3]

You could have a look whether the PR #72 is any good. Although those are implicit methods.

[mauro3]

Your last comment was for #71, right?

[berceanu]

Indeed, sorry about that! I just moved it there.