[inconsistent behaviour] DynamicSS saving all times about steadystatediffeq.jl HOT 9 CLOSED

Also for me the test in line 44 fails because the return code is Terminated not Success

Yes, looks like that never got updated.

Can it be that save_first=false does not take effect (also I do not find it in the documentation)?

Sorry, save_start=false.

On another note can you tell me whether there is a way to run the tests directly from my local copy of the repo, because the way I do it now (adding the repo in a julia REPL and then running the test) seems unnecessarily complicated.

]dev SteadyStateDiffEq and now you edit in your .julia folder, and then ]test SteadyStateDiffEq.

from steadystatediffeq.jl.

Yes, it probably makes sense to handle the output more nicely here, with save_everystep=false and save_first=false defaults (which can then be overridden to see the trajectory for debugging).

from steadystatediffeq.jl.

I can create a PR if you want me to (and you think it is worth it only to change two keyword arguments)

from steadystatediffeq.jl.

I think it's worth it. Thanks!

from steadystatediffeq.jl.

Can it be that save_first=false does not take effect (also I do not find it in the documentation)?
Or did you mean that I should implement this as a keyword argument there and if it is false we just return sol.u[end]?

Also for me the test in line 44 fails because the return code is Terminated not Success, which is also what I would expect because the callback terminates the integration before reaching the final time.

On another note can you tell me whether there is a way to run the tests directly from my local copy of the repo, because the way I do it now (adding the repo in a julia REPL and then running the test) seems unnecessarily complicated.

from steadystatediffeq.jl.

Maybe it would also make sense to change the terminated retcode to success such that whether one uses the rootfinding or dynamical approach success states that the steady state was found.

from steadystatediffeq.jl.

Yes. Just use the utility function DiffEqBase.solution_new_retcode

from steadystatediffeq.jl.

Do you think testing whether the derivative is roughly 0 is necessary or is it fine to assume the user does not use another Callback that terminates the integration while using this problem type?

from steadystatediffeq.jl.

Oh yes, checking the derivative before calling it a success is probably a good idea

from steadystatediffeq.jl.