R-tipping functionality #183
Conversation
…l script, created a dev folder, updated src/CriticalTransitions.jl file.
…itions.jl file to be in line with that of the main branch.
…RateSystem example
|
Hey @ryandeeley, I added a file for each function in |
cool, thanks! |
| ## Non-autonomous case | ||
|
|
||
| Now, we want to explore a non-autonomous version of the system. | ||
| We consider a setting where in the past and in the future the system is autnonomous and in between there is a non-autonomous period ``[t_start, t_end]`` with a time-dependent parameter ramping given by the function ``\lambda(rt)``. Choosing different values of the parameter ``r`` allows us to vary the speed of the parameter ramping. |
| r::Float64 | ||
| t_start::Float64 | ||
| t_end::Float64 | ||
| end |
There was a problem hiding this comment.
This struct should be made concrete. Both p_lambda and λ are non concrete types instead one should use Parametric types. Also, RateProtocol should probably not be mutable as this would lead to bad performance. Instead I propose
struct RateProtocol{F, T}
forcing_function::F
p_lambda::Vector{T}
rate::T
time_interval::Tuple{T,T}
end| u, | ||
| p, | ||
| t, | ||
| ds::ContinuousTimeDynamicalSystem, | ||
| λ::Function, | ||
| t_start::Float64, | ||
| t_end::Float64, | ||
| r::Float64; | ||
| kwargs..., | ||
| ) | ||
| if t_start > t_end | ||
| error("Please ensure that t_start ≤ t_end.") | ||
| end | ||
|
|
||
| p̃ = if r*t ≤ t_start | ||
| λ(p, t_start; kwargs...) | ||
| elseif t_start < r*t < t_end | ||
| λ(p, r*t; kwargs...) # the value(s) of λ(rt) | ||
| else | ||
| λ(p, t_end; kwargs...) # the value(s) of λ(rt) | ||
| end; # the value(s) of λ(rt) | ||
| return ds.integ.f(u, p̃, t) | ||
| end; |
There was a problem hiding this comment.
Would it be better for performance to do this with a callback?
| Time-dependent forcing protocol specified by the following fields: | ||
| - `λ::Function`: forcing function of the form `λ(p, t_start; kwargs...)`` | ||
| - `p_lambda::Vector`: parameters of forcing function |
There was a problem hiding this comment.
p_lambda::Vector`: parameters of the forcing function
| fp, eig, stab = [], [], [] | ||
| for t in times | ||
| rate_sys = apply_ramping(ds, rp, t) | ||
| _fp, _eig, _stab = fixedpoints(rate_sys, box) |
There was a problem hiding this comment.
At first this threw me because it looks like you're trying to compute the fixed points of a nonautonomous system, rather than those of the associated frozen-in autonomous system. However, I'm guessing fixed_points is clever and extracts the frozen-in dynamic_rule corresponding to the initial time t passed here.
src/r_tipping/moving_sinks.jl
Outdated
| The term "moving sinks" refers to Wieczorek et al. (2023). | ||
| """ | ||
| function moving_sinks(ds::ContinuousTimeDynamicalSystem, rp::RateProtocol, box; | ||
| times=0:0.1:1) |
There was a problem hiding this comment.
I would propose changing the value of the keyword argument times to rp.t_start/rp.r : (rp.t_end/rp.r - rp.t_start/rp.r)/10 : rp.t_end/rp.r, because then when "sweeping through" times you are going to automatically cover all possible parameter values attained with the rate protocol rp.
…ing it to work on a test example.
4 participants
We wish to create the initial functions useful for analysing rate-dependent dynamical systems that will go into the JOSS paper, in particular the
critical_rateandmoving_sinksfunctions.