You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thus, the value of tr_o2 that is being put into the postsynaptic spiking history buffer (via set_spiketime()), and which is here read out again by start->get_tr_o2_...(), is ostensibly incorrect.
This issue could actually be related to getting the trace value just-before, versus just-after the update due to the arriving spike.
Notice how in general, the NESTML trace values (in blue) are tracking the reference trace values (in orange) quite well.
Perhaps if we get the value always just-after the spike update, especially in the nearest-neighbour case, we are always setting tr_o1 and tr_o2 to 1, just before writing them back to the history. So we are only writing 1s to the history in that case.
See the following lines of generated code in set_spiketime():
There is a regression in the STDP triplet synapse model, as is visible in the tutorial notebook on the current master branch.
The regression bug should be fixed, and assertions have to be added to the notebook to prevent this issue from happening again.
Everything seems to work fine if the following line:
is replaced by
Thus, the value of tr_o2 that is being put into the postsynaptic spiking history buffer (via
set_spiketime()
), and which is here read out again bystart->get_tr_o2_...()
, is ostensibly incorrect.This issue could actually be related to getting the trace value just-before, versus just-after the update due to the arriving spike.
I added some debug plots to the notebook, please see https://github.com/clinssen/nestml/blob/triplet_stdp_fix_wip/doc/tutorials/triplet_stdp_synapse/triplet_stdp_synapse.ipynb
Notice how in general, the NESTML trace values (in blue) are tracking the reference trace values (in orange) quite well.
Perhaps if we get the value always just-after the spike update, especially in the nearest-neighbour case, we are always setting tr_o1 and tr_o2 to 1, just before writing them back to the history. So we are only writing 1s to the history in that case.
See the following lines of generated code in set_spiketime():
The text was updated successfully, but these errors were encountered: