Comments (8)
I think we do an optional argument on all of them for now. Then in the future make it a keyword argument on perform_step!
. However, we shouldn't do that now because keyword args are very slow in Julia right now, but will be fixed soon with the NamedTuples update. When that happens, we can migrate that over to keyword args with most perform_step!
just splatting kwargs and we'll be in a good spot.
from delaydiffeq.jl.
Good, then I'll add it to all of them and try to apply the proposed changes in the SDIRK and Rosenbrock methods.
from delaydiffeq.jl.
We should make a move on this because it should be pretty easy and would greatly speed up solving stiff DDEs.
perform_step!(integrator,cache::ImplicitEulerConstantCache,f=integrator.f)
The f=integrator.f
is a relic of the past before the nested integrators approach to DelayDiffEq.jl when I instead thought to just pass the closure f
to make it the ODE method (that had many many failures haha which is why it no longer exists). @devmotion have you seen anywhere that still makes use of it? If not, we could instead do:
perform_step!(integrator,cache::ImplicitEulerConstantCache,repeat_step=false)
for if it's a repeat step. Then in the SDIRK methods, we can skip the Jacobian re-calculations by doing
if !repeat_step && cache.newton_iters == 1 && cache.ηold < 1e-3
and skip the W
recalculation using
if !repeat_step && (integrator.iter < 1 || new_jac || abs(dt - (t-integrator.tprev)) > 100eps())
Similarly, in the Rosenbrock methods we'd do
if has_tgrad(f) && !repeat_step
and we'd have to change this block
to pull out the linear solver part to be right after, and flag the whole thing with if !repeat_step
.
So this will all work if we can make use of that optional argument spot. So let me know @devmotion if you've seen it in use anywhere and if not that's the go-ahead for this to get finished and finalize the stiff DDE solvers.
from delaydiffeq.jl.
No, I haven't seen the optional argument in the perform_step!
in use anywhere. I guess we then just remove the optional argument from any perform_step!
except of the SDIRK and Rosenbrock methods (which get this different optional argument), since these other methods behave the same regardless whether it's a repeated step or not? Of course, then we have to filter the type of integrators inside the fixed point iterations which is a bit ugly... Maybe we could introduce an abstract type of integrators that act differently if the step is repeated and just make those SDIRK and Rosenbrock methods are subtype of this abstract type?
from delaydiffeq.jl.
Oh I just discovered that initialize!
has the same optional argument. Do you know if it is needed anywhere or can we get rid of it? It is used in https://github.com/JuliaDiffEq/DelayDiffEq.jl/blob/master/src/integrator_interface.jl#L166 but we can just remove it there.
from delaydiffeq.jl.
We can get rid of it there.
from delaydiffeq.jl.
Can this be closed?
from delaydiffeq.jl.
Yup.
from delaydiffeq.jl.
Related Issues (20)
- Cache tests fail on master HOT 1
- behavior of step! with tstop HOT 6
- Discontinuity tracking can miss discontinuity at 0
- TagBot trigger issue HOT 58
- DDE too stiff? radau method required? HOT 6
- SavingCallback does not seem to save the right values HOT 1
- In DDEs constant_lags break PresetTimeCallback
- Performance regressions since Julia v1.4 HOT 1
- More efficient evaluation of the history function for multiple time points
- Significant allocations in DDE interpolation for multiple time points HOT 3
- Call to HistoryFunction gets replaced by call to ODEFunction HOT 5
- initial conditions not decaying according to dynamics function HOT 1
- missing cache.alg causing runtime dispatch in LinearSolve HOT 7
- Incorrect jacobian with Zygote + ReverseDiffAdjoint HOT 4
- Precompilation issue (DelayDiffEq v5.40.6) HOT 2
- `Dopri5` solver doesn't work for DDEs
- JuliaCon Proceedings Review: Example fails HOT 3
- DDE does not provide any solution (example from docs) HOT 6
- constant_lags contains 0.0 HOT 3
- Cannot resize DDE problem using resize! HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from delaydiffeq.jl.