Thanks for the suggestions! For now I have updated the documentation (see https://github.com/nest/nest-simulator/pull/3384/commits/081b23790ceeb9a4098416102fec191d5b907404). I will ask Tom Tetzlaff to review, but please feel welcome to also leave your feedback on GitHub.

Again, much obliged for bringing this issue to our attention!

With kind regards,
Charl

On Wed, Feb 5, 2025, at 13:09, Pavel Haman wrote:
Hello Charl,

the clarification in the documentation would surely be nice!

With the "uninitialised" value for u, there is already this condition (https://github.com/nest/nest-simulator/blob/b907e0dccfb394c322a48be86a3c01897125ff6f/models/tsodyks2_synapse.h#L231):
if ( t_lastspike_ >= 0.0 )
so it might be enough to  set the default value to -1 and add the case when that condition ( t_lastspike_ >= 0.0 ) is false and if u is uninitialised (u==-1) it might be enough to change it to u=U, and in case u is specified by the user leave it as the user wants?

I do not see deeper into NEST code and possibly miss the consequences or design paradigms, but it looks like a place to deal with initialisation.
E.g. I am not sure if set_status would allow the default value to be -1.

All the best,
Pavel



po 20. 1. 2025 v 15:27 odesílatel Charl Linssen <nest-users@turingbirds.com> napsal:

Hi Pavel,

Thank you for the clarification! Do you feel it would be a satisfactory solution if, in addition to the pull request I filed earlier, we add a warning in the documentation of the synapse model, that setting U directly "by hand", in particular before the start of the simulation, always needs to be accompanied by setting u to the same value?

Perhaps we could address the issue in a more rigorous way, by updating the code of set_status(), and using a default "uninitialised" value for u (like setting it to -1) before the start of the simulation, but it might involve more complex logic to check for this special case, which runs the risk of introducing new bugs. Moreover, checking if u equals -1 for each spike that passes through the synapse might be costly in terms of runtime performance.

Thanks for your thoughts!
Charl


On Mon, Jan 13, 2025, at 13:45, Pavel Haman wrote:
Dear Charl,

I am afraid that it is something I do not observe, and what I am concerned about!

Taking again this following script (comparing tsodyks_synapse and tsodyks2_synapse)

comparing a run with following parameters
dep_params = {"U": 0.67, "u": 0.67, "x": 1.0, "tau_rec": 450.0, "tau_fac": 0.0, "weight": 250.0}
and (without "u" being defined)
dep_params = {"U": 0.67, "x": 1.0, "tau_rec": 450.0, "tau_fac": 0.0, "weight": 250.0}

I see different results in the case of tsodyks2_synapse. What I observe in the second case is that the initial value of u is not that of U but rather 0.5 (that reflects the lower peak in the membrane potential for that model).
And as Tom Tezlaff referred to the paper (Maass and Markram, 2002;  doi:10.1016/S0893-6080(01)00144-7) that should be defining the model, the equation (2) there says that for the first spike u_1 should be equal U.

(note: in this test I was using the nest version from your pull request)


I am not sure what would be the best way to deal with the set_status() case, I haven't played with that at all and it would also require a discussion on the meaning of changing U during a simulation.

All the best in the new year,
Pavel

út 7. 1. 2025 v 10:34 odesílatel Charl Linssen <nest-users@turingbirds.com> napsal:

Dear Pavel,

Thanks for your detailed reply, and best wishes for the new year!

I noticed that in the model, the default initial value for u is initialised to that of U. I don't know the model very well; would you say it's meaningful to set the initial value of u to something other than U? Or, as u_1 = U always, should we simply set u to the value of U whenever the latter is changed through set_status()?

With kind regards,
Charl


On Sat, Dec 21, 2024, at 19:30, Pavel Haman wrote:
Hello Tom and Charl,

I have checked Charl's PR - it solves the problem. After a brief silent period the synapse behaves the same way as tsodyks_synapse and as could be expected.

I have found one more issue playing with parameters, which I think is connected to the original issue (https://github.com/nest/nest-simulator/issues/957) regarding the first spike.

When initiating the synapse, changing parameter 'u' (in dep_params dictionary) to anything different than 'U', e.g. raising it to 0.9 or lowering to 0.2 leads to a different first peak (and consequently the following peaks), compared to tsodyks_synapse model. The model obviously determines the first value u_1 (referring to the paper Maass and Markram, 2002;  doi:10.1016/S0893-6080(01)00144-7) as 'u' parameter. Which I believe does not correspond with the paper, where it is set u_1 = U (eg. 2), so for the first spike it should be set as 'U'.



Currently it behaves such that the u_1 value is 'u' and it is ignoring any time passed since the start of the simulation (i.e. the synapse does not relax). This means that for this synapse 'u' does not represent the initial value of the dynamical variable which is in differential equations describing the synaptic behavior, but rather strictly the value of that variable at the time of the first spike.

I am not sure that is the intended behavior, I can just report that it was unexpected behavior for me (it does not depend whether the first spike is at time t=2 ms or t=500 ms).


Note, that the default value of 'u' for tsodyks2_synapse is 0.5 regardless of the value of 'U'.

All the best,
Pavel

út 17. 12. 2024 v 14:14 odesílatel Tom Tetzlaff <t.tetzlaff@fz-juelich.de> napsal:
Hi Pavel,

you are right. Indeed, I assumed that $\Delta{}t_n=t_n-t_{n-1}$, rather
than $\Delta{}t_n=t_{n+1}-t_n$, as used in the paper. Well spotted. This
makes much more sense now. Sorry for the confusion. I agree that the
current NEST implementation is hence wrong, obviously the result of an
earlier "fix", as Charl explained. I had a quick look at Charl's PR and
think this will solve the problem.

Best
Tom



On 17.12.24 12:22, Pavel Haman wrote:
> Hello Tom and Charl,
>
> thank you for your time, explanations and replies. You confirmed what I
> thought was happening.
>
> I quickly checked the paper (Maass and Markram, 2002; 
> doi:10.1016/S0893-6080(01)00144-7) and equations (1-5).
> I think that the model should not update weights with delay of one
> spike, since $\Delta t_n$ in the equations is actually $t_{n+1}-t_{n}$,
> i.e. referring to the new spike (it is explained in the sentence before
> equations), not to older spikes. (I believe here could be the issue,
> since interpreting $\Delta t_n$, as I would naturally do, as
> $t_{n}-t_{n-1}$ leads to this one spike delay of updates)
>
> Effective weight for spike $n+1$, $A_{n+1}$ is given as
> $A_{n+1}= A u_{n+1} R_{n+1}$
> and $u_{n+1}$ depends on the times of the new spike $t_{n+1}$ and
> previous spike $t_{n}$
>
> I will check Charl's PR later this week.
>
> All the best,
> Pavel
>
> po 16. 12. 2024 v 22:19 odesílatel Charl Linssen
>
>     A little follow-up: I made a pull request with a suggested fix for
>
>     Tom, Pavel, would you mind having a look to see if this addresses
>     the issue?
>
>     Again, much obliged!
>     Charl
>
>
>     On Mon, Dec 16, 2024, at 11:14, Charl Linssen wrote:
>      > Hi Tom,
>      >
>      > Thanks for your input on this! I was just looking at the code
>     too. It
>      > seems that the order of updates (first update adaptation variables,
>      > then send spike, versus first send spike, then update adaptation
>      > variables) was changed, in order to prevent the adaptation from
>     kicking
>      > in for the very first spike to ever go through the synapse. See
>      > t_lastspike is initialised to zero, rather than some "special" value
>      > like -1. It is possible that this fix was erroneous, in that it
>     ends up
>      > affecting not just the first-ever spike, but also subsequent
>     spikes. I
>      > am investigating a bit more, but if you are convinced that the
>     current
>      > behaviour is the correct one, then I can stop investigating.
>      >
>      > Much obliged!
>      > Charl
>      >
>      >
>      > On Mon, Dec 16, 2024, at 11:01, Tom Tetzlaff wrote:
>      >> Dear Pavel,
>      >>
>      >> I can confirm you observation, and I share your surprise.
>     Intuitively,
>      >> one would expect that the synaptic state should return to the
>     initial
>      >> state after the long period of silence. However, after
>     consulting the
>      >> source papers (todyks_synapse:
>     doi:10.1523/JNEUROSCI.20-01-j0003.2000,
>      >> tsodyks2_synapse: doi:10.1016/S0893-6080(01)00144-7) and looking
>     at the
>      >> NEST code, I conclude that what the example shows is indeed the
>     intended
>      >> behaviour.
>      >>
>      >> A key difference between tsodyks_synapse and todyks2_synapse is the
>      >> order of update steps: upon arrival of the presynaptic spike,
>      >> tsodyks_synapse first updates the synapse state (x,y,z,u; see lines
>      >> 258-277 in tsodyks_synapse.h), and then reports the new weight
>     (line
>      >> 285
>      >> in tsodyks_synapse.h). In tsodyks2_synapse, this is reversed:
>     first,
>      >> the
>      >> synaptic weight is computed based on the current (i.e., the old)
>      >> synapse
>      >> state (line 236 in tsodyks2_synapse.h), and then the synapse
>     state is
>      >> updated (lines 243,244 in tsodyks2_synapse.h). When the first
>     spike of
>      >> the second burst of presynaptic spikes arrives in the example
>      >>
>      >> the recovery value of tsodyks2_synapse still is where it was at
>     the end
>      >> of the first burst of spikes (before the break). This is exactly
>     how
>      >> the
>      >> model is defined in (Maass and Markram, 2002;
>      >> doi:10.1016/S0893-6080(01)00144-7; see equations (1-5)). It
>     needs one
>      >> more spike to really "recover".
>      >>
>      >> I hope this clarifies things a bit.
>      >>
>      >> Best
>      >> Tom
>      >>
>      >>
>      >>
>      >> On 12.12.24 12:05, Pavel Haman wrote:
>      >>> Hello,
>      >>>
>      >>> I have followed the example script comparing `tsodyks_synapse`
>     and `tsodyks2_synapse` models, which can be found here:
>      >>>
>      >>>
>      >>> Using the parameter set for depression instead of facilitation
>     I found that `tsodyks2_synapse` model leads to weird peaks of
>     synaptic currents (at least I would not expect that for short term
>     depression) - during the second stimulation the weight rescaling
>     seems to be shifted by one spike compared to tsodyks_synapse (as if
>     parameter "u" would be updated after rescaling the weight instead of
>     before).
>      >>>
>      >>> Does anybody know why is there this difference between the two
>     synapse models?
>      >>>
>      >>> Thank you.
>      >>>
>      >>> All the best,
>      >>> PH
>      >>> _______________________________________________
>      >>> NEST Users mailing list -- users@nest-simulator.org
>     <mailto:users@nest-simulator.org>
>      >>> To unsubscribe send an email to users-leave@nest-simulator.org
>      >>
>      >> --
>      >> ---
>      >>
>      >> Dr. Tom Tetzlaff
>      >> Institute for Advanced Simulation (IAS-6)
>      >> Computational and Systems Neuroscience
>      >> Jülich Research Centre
>      >> Jülich, Germany
>      >>
>      >>
>      >>
>      >>
>     -----------------------------------------------------------------------
>      >>
>     -----------------------------------------------------------------------
>      >> Forschungszentrum Jülich GmbH
>      >> 52425 Jülich
>      >> Sitz der Gesellschaft: Jülich
>      >> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
>      >> Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
>      >> Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
>      >> Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens
>      >>
>     -----------------------------------------------------------------------
>      >>
>     -----------------------------------------------------------------------
>      >>
>      >> _______________________________________________
>      >> NEST Users mailing list -- users@nest-simulator.org
>     <mailto:users@nest-simulator.org>
>      >> To unsubscribe send an email to users-leave@nest-simulator.org
>      >>
>      >> Attachments:
>      >> * smime.p7s
>      > _______________________________________________
>      > NEST Users mailing list -- users@nest-simulator.org
>     <mailto:users@nest-simulator.org>
>      > To unsubscribe send an email to users-leave@nest-simulator.org
>     _______________________________________________
>     NEST Users mailing list -- users@nest-simulator.org
>     <mailto:users@nest-simulator.org>
>     To unsubscribe send an email to users-leave@nest-simulator.org
>
>
> _______________________________________________
> NEST Users mailing list -- users@nest-simulator.org
> To unsubscribe send an email to users-leave@nest-simulator.org

--
---

Dr. Tom Tetzlaff
Institute for Advanced Simulation (IAS-6)
Computational and Systems Neuroscience
Jülich Research Centre
Jülich, Germany



-----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens
-----------------------------------------------------------------------
-----------------------------------------------------------------------
_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org
_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org


_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org
_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org


_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org
_______________________________________________
NEST Users mailing list -- users@nest-simulator.org
To unsubscribe send an email to users-leave@nest-simulator.org