Currently spike events are hard coded to occur when:
Somatic voltage potential exceeds 10mV.
If the compartment is refractory, a spike occurs only if the membrane potential was below threshold on the previous time step. For continuous spike events, this is implicit since the affect is definied for positive-going threshold events.
Both of the above are placeholders. We should ultimately support changing the spike threshold and/or defining arbitrary conditions to be met for a spike event. We should also support setting refractory periods based on elapsed time or other state-based conditions.
Changing the raw threshold for spikes is easy--we can extend the existing spike detection methods with an extra optional argument. At minimum, a time-based refractory period requires caching the time stamp of the last spike. You would then define an event as (pseudocode) V > Vthold && Vprev < Vthold && t - t_lastspike > refractory
Support for arbitrary state conditions could be achieved if a user defines their own functors for spike detection. At minimum, we can enable this by defining abstract supertypes for users to overload. However, this approach is burdensome for the user since it requires working on a lower level, using the vanilla DiffEq callbacks API, instead of the ModelingToolkit.jl symbolic callback interface. I will need to think about this last component some more and likely address it as a separate issue.
Currently spike events are hard coded to occur when:
Both of the above are placeholders. We should ultimately support changing the spike threshold and/or defining arbitrary conditions to be met for a spike event. We should also support setting refractory periods based on elapsed time or other state-based conditions.
Changing the raw threshold for spikes is easy--we can extend the existing spike detection methods with an extra optional argument. At minimum, a time-based refractory period requires caching the time stamp of the last spike. You would then define an event as (pseudocode)
V > Vthold && Vprev < Vthold && t - t_lastspike > refractorySupport for arbitrary state conditions could be achieved if a user defines their own functors for spike detection. At minimum, we can enable this by defining abstract supertypes for users to overload. However, this approach is burdensome for the user since it requires working on a lower level, using the vanilla DiffEq callbacks API, instead of the ModelingToolkit.jl symbolic callback interface. I will need to think about this last component some more and likely address it as a separate issue.