get_K_value() can still return 0 erroneously in edge case

[JanVogelsang]

Describe the bug
The bug was already described in #1034 and partially fixed in #1137, but still appears for some parameter combinations.

Continuing on the description of the issue mentioned above:
Between two communication episodes, lots of post-synaptic spikes might occur, which can lead to the removal of other post-synaptic spikes from the history-queue, which is needed for the synapse to calculate the post-synaptic trace (K-value).
Whether a spike can be removed from the history or not depends on two conditions defined in
set_spiketime of the archiving node class:

1. Its access counter indicates it has been read out by all connected STDP synapses
2. There is another, later spike, that is strictly more than max_delay_ + eps away from the new spike

The second condition is needed for situations when two pre-synaptic spikes arrive at the synapse before there is another postsynaptic spike that can be used as reference for the post-synaptic trace. Max-delay is used to make sure that at least one other spike in the post-synaptic neuron's history is relevant for the weight update of the synapse (i.e. had time to travel to the synapse) before removing the spike.

Spikes are communicated in fixed intervals, and the weights of the STDP synapses are only updated upon spike delivery. This leads to an issue when the history of a post-synaptic neuron gets updated between two communication interval which might not leave the synapse enough time to access the history in time.
The issue is quite easy to reproduce in a minimal scenario. We connect two arbitrary neurons using a STDP synapse with some delay, e.g. a purely dendritic delay of 1.0. The delay between these neurons is now the min- and max-delay for our simulation with a resolution h defined by min-delay = k*h, k>1. Now imagine these spikes:

1. Post 0.2
2. Pre 1.5
3. Post 2.1
4. Pre 3.1 [get_K_value history: 3.4, 2.1]
5. Post 3.4

The first spike will add one entry to the post-synaptic neuron's history. The second spike will read the first spike, which by that time arrived at the synapse. The access counter for that spike is now at the number of all synapses in the simulation (which is 1 in this simple test case). The third spike adds another entry to the history, not removing the first spike yet, as the second condition is not met, as there is no other spike in the history yet. The fourth spike will arrive at the synapse at 3.1 (as there is no axonal delay) in theory, in reality the weight update is not performed at this point in time, but instead when the spike is due for delivery. The spike will be delivered at the next communication episode at 4.0, which is when the synapse performs the STDP weight update. At this time, the fifth spike has occured already, removing the first spike from the history of the post-synaptic neuron, as both conditions are met. The fourth spike will then call get_K_value of the post-synaptic neuron which calls get_history, which will return zero relevant spikes as the third spike (post-spike) has to be at least eps away from the fourth spike (pre-spike). The calculated K-value will therefore be 0, which is not correct.

To Reproduce
NEST-Version: dd5b613
Steps to reproduce the behavior:

1. stdp_synapse test
2. Use the parameters set in the stdp_synapse test, but add "t_ref: 0.5" to neuron_parameters.
3. pytest testsuite/pytests/test_stdp_synapse.py
4. Test fails.

[github-actions]

Issue automatically marked stale!