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 suggestions.
Best Regards, --Allen
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://nest-simulator.readthedocs.io/en/latest/models/izhikevich.html? 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/48c599f4e377627e75e5602d62cd4817...), 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:
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 suggestions.
Best Regards, --Allen _______________________________________________ NEST Users mailing list -- users@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
*Attachments:*
- Iz_Potential_Response.py
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@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/48c599f4e377627e75e5602d62cd4817... 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:
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@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
*Attachments:*
- Iz_Potential_Response.py
NEST Users mailing list -- users@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
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@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/48c599f4e377627e75e5602d62cd4817... 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:
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@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
*Attachments:*
- Iz_Potential_Response.py
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
*Attachments:*
- NEST_IZ_COMPARE.py
Charl,
Wow, you're absolutely correct. How could I overlooked such a trivial bit! I greatly appreciate the time you took to review this and am now fully confident in my NEST results to continue.
Best Regards, --Allen
On Wed, Oct 14, 2020 at 9:21 AM Charl Linssen nest-users@turingbirds.com wrote:
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 -65Let 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@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/48c599f4e377627e75e5602d62cd4817... 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:
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@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
*Attachments:*
- Iz_Potential_Response.py
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
*Attachments:*
- NEST_IZ_COMPARE.py
NEST Users mailing list -- users@nest-simulator.org To unsubscribe send an email to users-leave@nest-simulator.org
-
Allen Rabayda -
Allen Rabayda -
Charl Linssen