These exist but need to be sped up heavily. I'll collect some notes on how to do this in edits of this comment.
The current logic for detecting the end of a trace during return map generation involves a ContinuousCallback with the following condition:
function condition(u, t, integrator)
# Get two nearest points on the Ca nullcline to the x line (u[1]).
# If the x line crosses the Ca nullcline, terminate the solver.
# Find the last point on the Ca nullcline that is less than u[5].
Ca_null_index = findlast(Ca_null .< u[5])
# Linearly interpolate the Ca nullcline to find the x value at u[5].
Ca_null_x = xinf(p, V_range[Ca_null_index]) + (u[5] - Ca_null[Ca_null_index])/(Ca_null[Ca_null_index + 1] - Ca_null[Ca_null_index])*(xinf(p, V_range[Ca_null_index + 1]) - xinf(p, V_range[Ca_null_index]))
# Return the distance between u and the Ca nullcline in x if to the right of the equilibrium.
return Ca_null_x - u[1]
end
I suspect the findlast call is what's making the solves take so long -- they are currently taking 46 seconds with just 100 trajectories going a single revolution about the equilibrium (39 seconds if the length of the saveat range is chopped to 2 instead of 1500, but then the spike-count colors cannot be determined).
This edited line led to a drastic speed-up -- reducing the size of the V_range for storing the calcium nullcline by a factor of 10 preserves the quality of the return maps, the illustration of each nullcline in the phase portrait, and achieves a speedup from a 46 second solve to 20 seconds. Further reductions to the size of V_range did not give substantial solve speed improvements.
I suspect it may be ideal to only use the direction of the calcium nullcline coming out of the equilibrium in forming the return map -- the nullcline is very nearly linear along the attractor, and dynamics local to the nullcline do not seem to involve any chaotic mixing. It's worth a shot to see if the return map structure is preserved with a cheap analogue like this for computation.
These exist but need to be sped up heavily. I'll collect some notes on how to do this in edits of this comment.
The current logic for detecting the end of a trace during return map generation involves a
ContinuousCallback
with the following condition:I suspect the
findlast
call is what's making the solves take so long -- they are currently taking 46 seconds with just 100 trajectories going a single revolution about the equilibrium (39 seconds if the length of thesaveat
range is chopped to2
instead of1500
, but then the spike-count colors cannot be determined).This edited line led to a drastic speed-up -- reducing the size of the
V_range
for storing the calcium nullcline by a factor of 10 preserves the quality of the return maps, the illustration of each nullcline in the phase portrait, and achieves a speedup from a 46 second solve to 20 seconds. Further reductions to the size ofV_range
did not give substantial solve speed improvements.I suspect it may be ideal to only use the direction of the calcium nullcline coming out of the equilibrium in forming the return map -- the nullcline is very nearly linear along the attractor, and dynamics local to the nullcline do not seem to involve any chaotic mixing. It's worth a shot to see if the return map structure is preserved with a cheap analogue like this for computation.