14 Oct
2020
14 Oct
'20
3:21 p.m.
Hi Allen,
Please check your initial values for consistency. You are initialising the NEST model with
Vm0 and Um0, but the initial conditions for your Python script solvers are different,
namely:
v7[0] = c + (0.04 * Vm0+5.0) * Vm0 + 140.0 - Um0 + I_e7[0]
u7[0] = Um0 + a * ( 0.2 * Vm0 - Um0 )
(And identically for v8[0], u8[0].) If you set these also to Vm0 and Um0 then the results
are consistent, with the exception that the NEST multimeter does not record time zero, so
its data is shifted by one row:
1st 10ms NEST Model Python (NEST ODE) Python (Paper ODE)
---------- ------------ ------------------- --------------------
0 -63.08 -65 -65
1 -61.3292 -63.08 -63.08
2 -59.4889 -61.3292 -61.3292
3 -57.2741 -59.4889 -59.4889
4 -54.1778 -57.2741 -57.2741
5 -48.943 -54.1778 -54.1778
6 -37.2009 -48.943 -48.943
7 7.22383 -37.2009 -37.2009
8 -65 7.22383 7.22383
9 -73.5611 -65 -65
Let me know if this helps.
Kind regards,
Charl
On Mon, Oct 5, 2020, at 03:47, Allen Rabayda wrote:
Charl,
Thank you for your suggestions as I looked closer at the references you provided then
compared the NEST izhikevich Model, #1, behaviour to a Python implementation of NEST C++
Code, #2, and the Izhikevich Published C++ code, #3:
My comparison has #2 and #3 agreeing exactly, but #1 appears to show a slower rate of
growth of V_m leading to a widening lag in spike timing of NEST compared to #2 and #3.
I've attached my comparison code which produces two plots and tables to show these
findings.
Any suggestions would be appreciated.
Best regards,
--Allen
On Mon, Sep 21, 2020 at 6:21 AM Charl Linssen <nest-users(a)turingbirds.com> wrote:
__
Hi,
Note that the original paper by Izhikevich used an unconventional integration method. The
integration method can be selected by setting the model parameter
"consistent_integration"; see
https://nest-simulator.readthedocs.io/en/latest/models/izhikevich.html
<https://secure-web.cisco.com/16AWua6-b_AgYwy0oWPHBENNE1ghazbgRCzENGdeyQzRaps-dRXM5Kyh-ND_ajflWf9v02aHA7gxQ6bPmfLpz8xAbwRV2X3JXyVXr_RyJvhwGNRI-0bEo2wodNwSzqmKUaE55nllmJznRCBxpB7OwXdSo6nbZNGF7mb2i0o_tM1A82hKeU0d6csq-oOYWqgHTfY2XUVoTaYQic9OPIAzUZUJ5iOEXwJH1zqakg79hULvLv8Uwxg3SAyL52f427655KCHvoqwMpsQ4TlIkSn6x_lB9sPI13Oi8D4WDp4iO43FCKB6SoBDFtIHco9pYEnwI4sOiaGNsdLfyuX7jFb8vpMoOPo1uuFXWp77cOIV9uJy3qg-t8Q8hAj1hR-g1hMkFhru8wlou1q2bOxMalW36cTA7J00rO8eIRjMC_o49s2L4moKqBjBuiSRmDy9seDo4zAoxwtwM6jUYywUiYJt12Q/https%3A%2F%2Fnest-simulator.readthedocs.io%2Fen%2Flatest%2Fmodels%2Fizhikevich.html%3F>
for more information.
Also note that the NEST model behaves differently from the code you supplied when the
threshold is crossed: the NEST model immediately sets the voltage to the reset value (see
https://github.com/nest/nest-simulator/blob/48c599f4e377627e75e5602d62cd481…
<https://secure-web.cisco.com/1hRgbPsfb9noPq831V-Qg2gbgXXs7Ez_sRD7SuUYkFEyLYjp07I01dg9pCrfeMPMaDfrXUniv0bWFQs_fZt0yk47DQ9GBfXbYNpyMzhQ6qtjtHyxRVASEQbGvaMqqZmN4FO2a8w8dMBBmoDmBSds8VktIynlb-R8iDZ83QMFc_L7lMHUZ49F6OPKTtawC13dQvELJ5u-zo3ZUu7ENOLqeREeWDcb7KlvOBf2yKj14h4yTrVsjgxZyrGK7SX5t8dsdC6kLnYyTXwIXKAJnUe3-ylBGHM-_WjrtOnx-LHeia6HhwmPq8hVCofudS-KHDkmuO4_gmpJKxonFIptvdLr-FVSA2FqLFeW009OgqxzCNhp7zdceE_x2BtFg7Yt4KW5oAsTlvAyMCvTxUWPDfhKp_3kn1AlajTOAoY6NJj_6kwXEcVkJWOzEvLmyZ7rVnkYe1EseyB5UDqOGgdRe-uAFkw/https%3A%2F%2Fgithub.com%2Fnest%2Fnest-simulator%2Fblob%2F48c599f4e377627e75e5602d62cd481776ede1e1%2Fmodels%2Fizhikevich.cpp%23L235>),
and this is the value that is logged. So we might see the voltage evolve as follows:
...
at t = 42: V = 25
at t = 43: V = 35
-> threshold crossing detected, set V(t = 43) to -65
...
So your voltage trace will look like [..., 25, -65, ...]. Note that this does not include
the threshold value (30), but only the value just before the timestep in which the
threshold was crossed, and the reset voltage.
Your code instead clamps the above-threshold value of V *at the previous timestep* to the
threshold (in the line ``v2[t]=30``) when a crossing is detected. So the voltage trace
would look like:
...
at t = 42: V = 25
at t = 43: V = 35
at t = 44: threshold crossing detected at t = 43, set V(t = 43) to 30 and V(t = 44) to
-65
...
So your voltage trace will look like [..., 25, 30, -65, ...].
I haven't quite figured out in detail what happens with this extra timestep, perhaps
there is a slight bug in my explanation, but it could also be a discrepancy between the
integration methods.
If the integration methods are the same for your script and the NEST model, the spike
times produced should be precisely the same, even though the voltage traces for the
membrane potential will be different, because of the different ways of handling threshold
crossing.
Hope this helps, otherwise please let us know!
Charl
On Mon, Sep 21, 2020, at 01:44, Allen Rabayda wrote:
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
*Attachments:*
* NEST_IZ_COMPARE.py Dear Nest Community,
When trying to reproduce Izhikevich's Simple Neuron Model with NEST Izhikevich
Neuron Model, it is spiking before reaching my V_th potential threshold setting of 30 mV,
producing results inconsistent with the publication.
Would anybody have insight as to why the neuron is spiking early? Did I perhaps not
include a relevant NEST setting?
I compared it to an explicit implementation of the ODEs, attached, for your reference
of expected neuron response.
Thank you for any further suggestions as I strive to have full explainability and
understanding as my research matures.
Best Regards,
--Allen
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
*Attachments:*
* Iz_Potential_Response.py
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org