Open bgroenks96 opened 3 years ago
Looking at the code, it seems that we just need to add a version of get_log
that allows for the global log to be already active. activate!
and deactivate!
should be fine as-is. I can take a crack at it.
Yeah, you can totally activate!
or deactivate!
a log manually. The only thing is it's going to log every time your function was called. That includes time points where the solver throws away the solution. And maybe even Jacobian calls too, if your solver is doing that. Maybe you could make use of that, but it might get pretty tough to figure out which were the "real" timesteps it took.
Ah. Well, at least with a simple forward integration scheme it should work. Do you think maybe SavingCallback
is more appropriate for this case, in general?
I think really only Euler's method will work this way (and you definitely don't want that). Most other methods will make multiple function calls per time increment. SavingCallback
I think will run into the same problem because it is only called after all of the function calls per update, not every one.
I think really only Euler's method will work this way
I actually often have to use Euler's method.... phase change sucks :(
It's surprisingly often faster in my application domain than most other solvers!
I think will run into the same problem because it is only called after all of the function calls per update, not every one.
Isn't that usually what we want?
I think it would be useful to allow the user to choose to manually activate the global log before calling
solve
in order to collect the logged values at every solver time step.Of course this adds the performance overhead of logging, but for debugging purposes, that's totally fine.
It would also provide a workaround for use cases (like one of mine) when the model slightly violates temporal continuity by implicitly relying on "logged" values from the previous time step.