Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add predefined timestep() function #1100

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

clinssen
Copy link
Contributor

@clinssen clinssen commented Sep 20, 2024

Add a timestep() function so models can be formulated in more generic terms than using the resolution() function. The latter assumes a fixed simulation timestep; the former is compatible with timesteps of arbitrary size (with subsequent steps potentially being of different size).

Existing time-based functions (resolution() and steps()) will remain, in order to be able to formulate models optimised for fixed-timestep simulators. This is also necessary to get a numerically identical result with NEST for at least one of the tests (stdp triplet synapse test). A warning will be emitted during model validation with a recommendation to use timestep() where possible.

New refractoriness mechanisms are implemented based on a countdown ODE (thanks to Tom Tetzlaff and Markus Diesmann!) This means that neither resolution() nor timestep() needs to be used any longer in the neuron models for the refractoriness mechanism. (See discussion in #988).

TODO

  • Change neuron models in the Jupyter notebooks
  • Change neuron models in the integration tests

@clinssen clinssen marked this pull request as draft September 20, 2024 18:26
@clinssen clinssen changed the title Add predefined timestep() function. Add predefined timestep() function Sep 21, 2024

onCondition(V_m >= V_peak):
onCondition(V_m >= V_peak and refr_t <= 0 ms):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and in all other neuron models with a similar construct, I'd swap the order of conditions:
onCondition(refr_t <= 0 ms and V_m >= V_peak)

neuron like dynamics interacting by point events is described in
[1]_. A flow chart can be found in [2]_.

This model differs from ``iaf_psc_delta_fixed_timestep`` in that it
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is certainly a typo and should read:
This model differs from ``iaf_psc_delta`` ...

spike

update:
if is_refractory:
Copy link
Collaborator

@tomtetzlaff tomtetzlaff Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be simplified by removing the boolean state variable is_refractory, and replacing

onCondition(not is_refractory)

by

onCondition(refr_t <= 0 ms)

(and similarly for all other refractoriness conditions). With this change, this version of the model becomes more similar to the version using an ODE for the refractoriness counter. In fact, only the way refr_t is updated needs to be changed. To expose the differences between the two versions, I'd keep everything else identical.


emit_spike()

onCondition(is_refractory and refr_t <= resolution() / 2):
Copy link
Collaborator

@tomtetzlaff tomtetzlaff Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this block really necessary?

@@ -260,13 +260,13 @@ In order to model an absolute refractory state, in which the neuron cannot fire
update:
if is_refractory:
# neuron is absolute refractory, do not evolve V_m
refr_t -= resolution()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the entire section "Implementing refractoriness" be updated to explain the new way of handling refractoriness?

Copy link
Collaborator

@tomtetzlaff tomtetzlaff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reviewed the part concerned with the ODE-based refractoriness implementation. Apart from few minor things (see detailed comments), this looks very good. Thanks for implementing this idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants