7 Feb
2024
7 Feb
'24
3:41 p.m.
Hi!
I am trying to implement weight normalization (as you show in your documentation). It
works well (see below code) when executed "normally" (or when using" mpirun
-np 1"), but it hangs (it just do not respond) when executed using mpirun. It hangs
when I try to execute nest.Simulate() after weigth assignment. If I remove the
"conn.weight = w_nparray" instruction in the following code, it works without
hang.
I use NEST 3.6 and python3, compiled with python, mpi, sionlib and music.
Thanks a lot in advance!
import nest
import numpy as np
pos = nest.spatial.grid(shape = [30,30] )
input = nest.Create('iaf_psc_alpha', positions=pos)
layer_0 = nest.Create('iaf_psc_alpha', positions=pos)
layer_1 = nest.Create('iaf_psc_alpha', positions=pos)
conn_neur = {'rule':'pairwise_bernoulli', 'use_on_source': True,
'mask': {'grid':{'shape':[9,9]}} }
nest.CopyModel('static_synapse', 'syn_1_model')
syn_0 = {'synapse_model': 'static_synapse'}
syn_1 = {'synapse_model': 'syn_1_model'}
nest.Connect(input, layer_0, conn_neur, syn_0)
nest.Connect(input, layer_1, conn_neur, syn_0)
nest.DumpLayerConnections(input, layer_0, 'static_synapse', 'conn.txt')
nest.DumpLayerConnections(input, layer_1, 'syn_1_model', 'conn.txt')
nest.Simulate(100)
for neuron in layer_0:
conn = nest.GetConnections(source=input, target=neuron,
synapse_model='static_synapse')
w = np.array(conn.weight)
if (w.size>1):
w_normed = w / sum(abs(w)) # L1-norm
w_nparray = 2. * w_normed
conn.weight = w_nparray
nest.Simulate(100)
7 Feb
7 Feb
4:18 p.m.
Hi Xavier,
I think I can reproduce your problem and have an idea what it may cause it. How many MPI
processes did you use?
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Wednesday, 7 February 2024 at 15:41
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Weights assignment error with mpirun
[Some people who received this message don't often get email from xotazu(a)cvc.uab.cat.
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi!
I am trying to implement weight normalization (as you show in your documentation). It
works well (see below code) when executed "normally" (or when using" mpirun
-np 1"), but it hangs (it just do not respond) when executed using mpirun. It hangs
when I try to execute nest.Simulate() after weigth assignment. If I remove the
"conn.weight = w_nparray" instruction in the following code, it works without
hang.
I use NEST 3.6 and python3, compiled with python, mpi, sionlib and music.
Thanks a lot in advance!
import nest
import numpy as np
pos = nest.spatial.grid(shape = [30,30] )
input = nest.Create('iaf_psc_alpha', positions=pos)
layer_0 = nest.Create('iaf_psc_alpha', positions=pos)
layer_1 = nest.Create('iaf_psc_alpha', positions=pos)
conn_neur = {'rule':'pairwise_bernoulli', 'use_on_source': True,
'mask': {'grid':{'shape':[9,9]}} }
nest.CopyModel('static_synapse', 'syn_1_model')
syn_0 = {'synapse_model': 'static_synapse'}
syn_1 = {'synapse_model': 'syn_1_model'}
nest.Connect(input, layer_0, conn_neur, syn_0)
nest.Connect(input, layer_1, conn_neur, syn_0)
nest.DumpLayerConnections(input, layer_0, 'static_synapse', 'conn.txt')
nest.DumpLayerConnections(input, layer_1, 'syn_1_model', 'conn.txt')
nest.Simulate(100)
for neuron in layer_0:
conn = nest.GetConnections(source=input, target=neuron,
synapse_model='static_synapse')
w = np.array(conn.weight)
if (w.size>1):
w_normed = w / sum(abs(w)) # L1-norm
w_nparray = 2. * w_normed
conn.weight = w_nparray
nest.Simulate(100)
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
4:36 p.m.
Hi!
I used 2 and 64 number of processes.
An update ... the problem disappears when using
"nest.SetStatus(conn,'weight',w_nparray)" instead of the direct
assignment "conn.weight=w_nparray". In addition, it also hangs when using
"conn.set()"
Xavier
8 Feb
8 Feb
3:04 p.m.
Hi Xavier,
I have now created an issue for this on Github:
https://github.com/nest/nest-simulator/issues/3099
But there is another problem with your approach: Even if the code worked with MPI, you
would only collect the weights of the connections local to each MPI rank on that rank
(i.e., connections with targets on that rank). If normalization per target neuron is what
you want, this is fine, if you wanted to normalize all outgoing synapses of a neuron, this
would be pretty much impossible when using MPI.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Wednesday, 7 February 2024 at 16:36
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi!
I used 2 and 64 number of processes.
An update ... the problem disappears when using
"nest.SetStatus(conn,'weight',w_nparray)" instead of the direct
assignment "conn.weight=w_nparray". In addition, it also hangs when using
"conn.set()"
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
7:46 p.m.
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May I
safely suppose that after every Simulate() new weights of my connections (they are changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
9:14 p.m.
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But note
that NEST only updates synaptic weights when a spike actually passes through the synapse,
so you will get for each synapse the weight as it was at the end of the plasticity update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so cumbersome in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May I
safely suppose that after every Simulate() new weights of my connections (they are changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
9:42 p.m.
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
9 Feb
9 Feb
8:03 a.m.
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook() on
all network nodes to allow them to precompute internal variables. So if you changed neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the actual
time-evolution equations for your weights become when taking normalization into account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
11:40 a.m.
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the actual
time-evolution equations for your weights become when taking normalization into account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
1:29 p.m.
Hi Xavier,
If you know the time course of you poisson process rates beforehand, you can use the
inhomogeneous_poisson_generator, which changes to new rates at given time points.
The rate calculation of the poisson generator is precisely on of the cases where SetStatus
inside a RM context causes problems. This will not change, because one of the key points
about the RM context is to avoid time overhead for neuron configuration.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 11:44
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the actual
time-evolution equations for your weights become when taking normalization into account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections() for
every loop iteration, may I get the connections calling GetConnections() just once? May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
1:59 p.m.
Hans,
Inhomogeneous spike generator is a very nice solution ... Thanks for the tip! I didn't
thought about it :-) I will try it (although at this moment my main time consuming process
is the normalization step, not the Simulate() preparation time :-/ )
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
If you know the time course of you poisson process rates beforehand, you can use the
inhomogeneous_poisson_generator, which changes to new rates at given time points.
The rate calculation of the poisson generator is precisely on of the cases where
SetStatus
inside a RM context causes problems. This will not change, because one of the key points
about the RM context is to avoid time overhead for neuron configuration.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 11:44
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many
models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hans,
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the
actual
time-evolution equations for your weights become when taking normalization into
account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so
cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections()
for
every loop iteration, may I get the connections calling GetConnections() just once?
May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An
example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________ NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
11 Feb
11 Feb
4:46 p.m.
Hi Xavier,
I think I understand your MPI-hang problems now (see comment in the issue) and can suggest
a work-around
if (w.size>1):
w_normed = w / sum(abs(w)) # L1-norm
w_nparray = 2. * w_normed
conn.weight = w_nparray
else:
conn.weight = []
The important thing is that the SynapseCollection.set() method, which is called by the
assignment, is executed by all MPI ranks, even if their conn is empty. Assigning to an
empty conn just does nothing, except MPI communicate with the other ranks.
The other work around is to call SetStatus(), which avoids the MPI calls altogether and
thus is most likely more efficient.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 14:00
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hans,
Inhomogeneous spike generator is a very nice solution ... Thanks for the tip! I didn't
thought about it :-) I will try it (although at this moment my main time consuming process
is the normalization step, not the Simulate() preparation time :-/ )
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
If you know the time course of you poisson process rates beforehand, you can use the
inhomogeneous_poisson_generator, which changes to new rates at given time points.
The rate calculation of the poisson generator is precisely on of the cases where
SetStatus
inside a RM context causes problems. This will not change, because one of the key points
about the RM context is to avoid time overhead for neuron configuration.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 11:44
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many
models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hans,
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the
actual
time-evolution equations for your weights become when taking normalization into
account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so
cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections()
for
every loop iteration, may I get the connections calling GetConnections() just once?
May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An
example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________ NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
7:21 p.m.
Hi Xavier,
I have now created a PR that should fix the problem with hanging simulations. You can find
it at
https://github.com/nest/nest-simulator/pull/3101
I’d much appreciate it if you could check that it solves your problem.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Hans Ekkehard Plesser <hans.ekkehard.plesser(a)nmbu.no>
Date: Sunday, 11 February 2024 at 16:46
To: NEST User Mailing List <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
Hi Xavier,
I think I understand your MPI-hang problems now (see comment in the issue) and can suggest
a work-around
if (w.size>1):
w_normed = w / sum(abs(w)) # L1-norm
w_nparray = 2. * w_normed
conn.weight = w_nparray
else:
conn.weight = []
The important thing is that the SynapseCollection.set() method, which is called by the
assignment, is executed by all MPI ranks, even if their conn is empty. Assigning to an
empty conn just does nothing, except MPI communicate with the other ranks.
The other work around is to call SetStatus(), which avoids the MPI calls altogether and
thus is most likely more efficient.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 14:00
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hans,
Inhomogeneous spike generator is a very nice solution ... Thanks for the tip! I didn't
thought about it :-) I will try it (although at this moment my main time consuming process
is the normalization step, not the Simulate() preparation time :-/ )
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
If you know the time course of you poisson process rates beforehand, you can use the
inhomogeneous_poisson_generator, which changes to new rates at given time points.
The rate calculation of the poisson generator is precisely on of the cases where
SetStatus
inside a RM context causes problems. This will not change, because one of the key points
about the RM context is to avoid time overhead for neuron configuration.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 11:44
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many
models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hans,
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the
actual
time-evolution equations for your weights become when taking normalization into
account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so
cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections()
for
every loop iteration, may I get the connections calling GetConnections() just once?
May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An
example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________ NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________
NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
12 Feb
12 Feb
11:24 a.m.
Hi Hans,
This "else" workaround doesn't work. It also hangs.
I have not tried yet the PR (I have to download it and recompile and reinstall NEST). Will
tell you later (today).
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
I think I understand your MPI-hang problems now (see comment in the issue) and can
suggest
a work-around
if (w.size>1):
w_normed = w / sum(abs(w)) # L1-norm
w_nparray = 2. * w_normed
conn.weight = w_nparray
else:
conn.weight = []
The important thing is that the SynapseCollection.set() method, which is called by the
assignment, is executed by all MPI ranks, even if their conn is empty. Assigning to an
empty conn just does nothing, except MPI communicate with the other ranks.
The other work around is to call SetStatus(), which avoids the MPI calls altogether and
thus is most likely more efficient.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 14:00
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig på
https://aka.ms/LearnAboutSenderIdentification ]
Hans,
Inhomogeneous spike generator is a very nice solution ... Thanks for the tip! I
didn't
thought about it :-) I will try it (although at this moment my main time consuming
process
is the normalization step, not the Simulate() preparation time :-/ )
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
If you know the time course of you poisson process rates beforehand, you can use the
inhomogeneous_poisson_generator, which changes to new rates at given time points.
The rate calculation of the poisson generator is precisely on of the cases where
SetStatus
inside a RM context causes problems. This will not change, because one of the key
points
about the RM context is to avoid time overhead for neuron configuration.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Friday, 9 February 2024 at 11:44
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Inside an RM context, I am not only changing synaptic weights, but also Poisson spike
generators rates. At every loop iteration I change the "input image", and I
simulate it using a spike generator. I tried an RM context some time ago (previous NEST
versions) and I realized that rate didn't change (I guess because the non-updated
internal variables). Is this behaviour changed on 3.6 version?
Related to the neuroscientific question I understand you ask me about the temporal
evolution of weights when externally modifying them. When I just used STDP, my weights
grow indefinitely (a well known problem) or just saturates to W_max. Since in many
models
input weights are normalized, I applied normalization to avoid this growing problem (in
addition, there are some biophyisical studies showing that this kind of normalization
exists in biological systems). Another question is the "continuity" (first
derivative) of temporal evolution of weights ... the answer is "I do not
know"
:-/
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
Actually, in your case the Prepare-Run-Cleanup approach should work, since you use
SetStatus only on synaptic weights. The reason we warn about unpredictable behaviour
in
case of SetStatus inside a RunManager context is that Prepare() calls a pre_run_hook()
on
all network nodes to allow them to precompute internal variables. So if you changed
neuron
parameters inside an RM context, the nodes would update with an inconsistent set of
externally set parameter values and internally not-updated variables. Synapses do not
have
such a pre-run-hook, so there you should be way safe. Note that you cannot
Connect/Disconnect in a RM context, since the connection infrastructure needs to be
updated by Prepare().
Finally, one could wonder about how the external manipulation of the synaptic weights
interacts with the internal evolution of the weights through STDP, i.e., what the
actual
time-evolution equations for your weights become when taking normalization into
account.
But that is a neuroscientific question, not a NEST-technical one.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 21:42
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
på
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Great news to be able to call GetConnections() just once ... it speedsA LOT my
runnings
(from 230-ish seconds to 90-ish) :-)
I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have to use
SetStatus() to update normalized weights between Prepare() and Cleanup(), I cannot use
it
:-(
Best,
Xavier
Hans Ekkehard Plesser wrote:
Hi Xavier,
The result of `GetConnections()` remains valid as long as no new synapses are added
or
synapses deleted, so in your case, you only need to call it once.
When you then do a `conn.weight`, you will get the weights at that point in time. But
note
that NEST only updates synaptic weights when a spike actually passes through the
synapse,
so you will get for each synapse the weight as it was at the end of the plasticity
update
when the most recent spike passed through that synapse.
Instead of calling Simulate() repeatedly, you can also use a RunManager context for
higher
efficiency, see
https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
In case you should be wondering why global instantaneous normalization is so
cumbersome
in
NEST: We have focused on support for biologically plausible networks so far and
instantaneous global normalization is just not biologically plausible (nor physically
feasible with a view to causality).
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Thursday, 8 February 2024 at 19:46
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er viktig
p?
https://aka.ms/LearnAboutSenderIdentification ]
Hi Hans,
Thanks for your information. Fortunately, I do not normalize output connections (only
input), hence, this code works for me.
Another question. Take that I call nest.Simulate() inside a for loop and I want to
normalize weights after every iteration. In order to avoid calling GetConnections()
for
every loop iteration, may I get the connections calling GetConnections() just once?
May
I
safely suppose that after every Simulate() new weights of my connections (they are
changed
because I use STDP) will be available (for reading) using the same variable? An
example
code would be something like:
my_conn = GetConnections(...)
for iter in range(...)
nest.Simulate(...)
normalize_connections(my_conn) # function that normalizes weights and calls
nest.SetStatus(my_conn, ...)
Many thanks in advance!
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________ NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
_______________________________________________ NEST Users mailing list --
users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org Hans,
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
3:10 p.m.
Hans,
The PR works. There is no hang! I downloaded the master from the git and applied your
patch. In comparison with my previous version, now I compiled NEST without MUSIC support.
In addition, the execution is MUCH faster. The time to perform the normalization
(including the weight assignment) is around 30-40 times faster!!! May be it is because I
use 64 mpi processes (mpirun -np 64)?
Best,
Xavier
Xavier Otazu wrote:
Hi Hans,
This "else" workaround doesn't work. It also hangs.
I have not tried yet the PR (I have to download it and recompile and reinstall NEST).
Will
tell you later (today).
Xavier
Hans Ekkehard Plesser wrote:
> Hi Xavier,
>
> I think I understand your MPI-hang problems now (see comment in the issue) and can
> suggest
> a work-around
>
> if (w.size>1):
> w_normed = w / sum(abs(w)) # L1-norm
> w_nparray = 2. * w_normed
> conn.weight = w_nparray
> else:
> conn.weight = []
>
> The important thing is that the SynapseCollection.set() method, which is called by
the
> assignment, is executed by all MPI ranks, even if their conn is empty. Assigning to
an
> empty conn just does nothing, except MPI communicate with the other ranks.
>
> The other work around is to call SetStatus(), which avoids the MPI calls altogether
and
> thus is most likely more efficient.
>
> Best,
> Hans Ekkehard
>
> --
>
> Prof. Dr. Hans Ekkehard Plesser
>
> Department of Data Science
> Faculty of Science and Technology
> Norwegian University of Life Sciences
> PO Box 5003, 1432 Aas, Norway
>
> Phone +47 6723 1560
> Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
> Home http://arken.nmbu.no/~plesser
>
>
>
> From: Xavier Otazu <xotazu(a)cvc.uab.cat>
> Date: Friday, 9 February 2024 at 14:00
> To: users(a)nest-simulator.org <users(a)nest-simulator.org>
> Subject: [NEST Users] Re: Weights assignment error with mpirun
> [Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er
viktig på
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hans,
>
> Inhomogeneous spike generator is a very nice solution ... Thanks for the tip! I
> didn't
> thought about it :-) I will try it (although at this moment my main time consuming
> process
> is the normalization step, not the Simulate() preparation time :-/ )
>
> Xavier
>
> Hans Ekkehard Plesser wrote:
> Hi Xavier,
>
> If you know the time course of you poisson process rates beforehand, you can use
the
> inhomogeneous_poisson_generator, which changes to new rates at given time points.
>
> The rate calculation of the poisson generator is precisely on of the cases where
> SetStatus
> inside a RM context causes problems. This will not change, because one of the key
> points
> about the RM context is to avoid time overhead for neuron configuration.
>
> Best,
> Hans Ekkehard
>
> --
>
> Prof. Dr. Hans Ekkehard Plesser
>
> Department of Data Science
> Faculty of Science and Technology
> Norwegian University of Life Sciences
> PO Box 5003, 1432 Aas, Norway
>
> Phone +47 6723 1560
> Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
> Home http://arken.nmbu.no/~plesser
>
>
>
> From: Xavier Otazu <xotazu(a)cvc.uab.cat>
> Date: Friday, 9 February 2024 at 11:44
> To: users(a)nest-simulator.org <users(a)nest-simulator.org>
> Subject: [NEST Users] Re: Weights assignment error with mpirun
> [Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er
viktig
> på
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Hans,
>
> Inside an RM context, I am not only changing synaptic weights, but also Poisson
spike
> generators rates. At every loop iteration I change the "input image",
and I
> simulate it using a spike generator. I tried an RM context some time ago (previous
NEST
> versions) and I realized that rate didn't change (I guess because the
non-updated
> internal variables). Is this behaviour changed on 3.6 version?
>
> Related to the neuroscientific question I understand you ask me about the
temporal
> evolution of weights when externally modifying them. When I just used STDP, my
weights
> grow indefinitely (a well known problem) or just saturates to W_max. Since in
many
> models
> input weights are normalized, I applied normalization to avoid this growing
problem (in
> addition, there are some biophyisical studies showing that this kind of
normalization
> exists in biological systems). Another question is the "continuity"
(first
> derivative) of temporal evolution of weights ... the answer is "I do not
> know"
> :-/
>
> Best,
> Xavier
>
> Hans Ekkehard Plesser wrote:
> Hi Xavier,
>
> Actually, in your case the Prepare-Run-Cleanup approach should work, since you
use
> SetStatus only on synaptic weights. The reason we warn about unpredictable
behaviour
> in
> case of SetStatus inside a RunManager context is that Prepare() calls a
pre_run_hook()
> on
> all network nodes to allow them to precompute internal variables. So if you
changed
> neuron
> parameters inside an RM context, the nodes would update with an inconsistent set
of
> externally set parameter values and internally not-updated variables. Synapses do
not
> have
> such a pre-run-hook, so there you should be way safe. Note that you cannot
> Connect/Disconnect in a RM context, since the connection infrastructure needs to
be
> updated by Prepare().
>
> Finally, one could wonder about how the external manipulation of the synaptic
weights
> interacts with the internal evolution of the weights through STDP, i.e., what
the
> actual
> time-evolution equations for your weights become when taking normalization into
> account.
> But that is a neuroscientific question, not a NEST-technical one.
>
> Best,
> Hans Ekkehard
>
> --
>
> Prof. Dr. Hans Ekkehard Plesser
>
> Department of Data Science
> Faculty of Science and Technology
> Norwegian University of Life Sciences
> PO Box 5003, 1432 Aas, Norway
>
> Phone +47 6723 1560
> Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
> Home http://arken.nmbu.no/~plesser
>
>
>
> From: Xavier Otazu <xotazu(a)cvc.uab.cat>
> Date: Thursday, 8 February 2024 at 21:42
> To: users(a)nest-simulator.org <users(a)nest-simulator.org>
> Subject: [NEST Users] Re: Weights assignment error with mpirun
> [Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er
viktig
> på
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Hans,
>
> Great news to be able to call GetConnections() just once ... it speedsA LOT my
> runnings
> (from 230-ish seconds to 90-ish) :-)
>
> I tried the Prepare/Run/Cleanup some time ago (nice solution), but since I have
to use
> SetStatus() to update normalized weights between Prepare() and Cleanup(), I
cannot use
> it
> :-(
>
> Best,
> Xavier
>
> Hans Ekkehard Plesser wrote:
> Hi Xavier,
>
> The result of `GetConnections()` remains valid as long as no new synapses are
added
> or
> synapses deleted, so in your case, you only need to call it once.
> When you then do a `conn.weight`, you will get the weights at that point in
time. But
> note
> that NEST only updates synaptic weights when a spike actually passes through
the
> synapse,
> so you will get for each synapse the weight as it was at the end of the
plasticity
> update
> when the most recent spike passed through that synapse.
>
> Instead of calling Simulate() repeatedly, you can also use a RunManager context
for
> higher
> efficiency, see
> https://nest-simulator.readthedocs.io/en/stable/nest_behavior/running_simul….
>
> In case you should be wondering why global instantaneous normalization is so
> cumbersome
> in
> NEST: We have focused on support for biologically plausible networks so far and
> instantaneous global normalization is just not biologically plausible (nor
physically
> feasible with a view to causality).
>
> Best,
> Hans Ekkehard
>
> --
>
> Prof. Dr. Hans Ekkehard Plesser
>
> Department of Data Science
> Faculty of Science and Technology
> Norwegian University of Life Sciences
> PO Box 5003, 1432 Aas, Norway
>
> Phone +47 6723 1560
> Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
> Home http://arken.nmbu.no/~plesser
>
>
>
> From: Xavier Otazu <xotazu(a)cvc.uab.cat>
> Date: Thursday, 8 February 2024 at 19:46
> To: users(a)nest-simulator.org <users(a)nest-simulator.org>
> Subject: [NEST Users] Re: Weights assignment error with mpirun
> [Du mottar ikke ofte e-post fra xotazu(a)cvc.uab.cat. Finn ut hvorfor dette er
viktig
> p?
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Hans,
>
> Thanks for your information. Fortunately, I do not normalize output connections
(only
> input), hence, this code works for me.
>
> Another question. Take that I call nest.Simulate() inside a for loop and I want
to
> normalize weights after every iteration. In order to avoid calling
GetConnections()
> for
> every loop iteration, may I get the connections calling GetConnections() just
once?
> May
> I
> safely suppose that after every Simulate() new weights of my connections (they
are
> changed
> because I use STDP) will be available (for reading) using the same variable? An
> example
> code would be something like:
>
> my_conn = GetConnections(...)
>
> for iter in range(...)
> nest.Simulate(...)
> normalize_connections(my_conn) # function that normalizes weights and calls
> nest.SetStatus(my_conn, ...)
>
>
> Many thanks in advance!
>
> Xavier
> _______________________________________________
> NEST Users mailing list -- users(a)nest-simulator.org
> To unsubscribe send an email to users-leave(a)nest-simulator.org
> _______________________________________________ NEST Users mailing list --
> users(a)nest-simulator.org
> To unsubscribe send an email to users-leave(a)nest-simulator.org
> _______________________________________________ NEST Users mailing list --
> users(a)nest-simulator.org
> To unsubscribe send an email to users-leave(a)nest-simulator.org Hans,
> _______________________________________________
> NEST Users mailing list -- users(a)nest-simulator.org
> To unsubscribe send an email to users-leave(a)nest-simulator.org
3:12 p.m.
A small clarification ... I always used 64 mpi processes to run my code (hence, the 30-40
speedup performace is because of your new code).
Xavier
6:26 p.m.
Dear Xavier,
30–40 times faster is indeed a very pleasant result 😊. The reason is that the PyNEST
interface induced MPI communication for each of the weight updates, and if 64 ranks need
to sync all the time, the going gets slow.
Best,
Hans Ekkehard
--
Prof. Dr. Hans Ekkehard Plesser
Department of Data Science
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser@nmbu.no<mailto:hans.ekkehard.plesser@nmbu.no>
Home http://arken.nmbu.no/~plesser
From: Xavier Otazu <xotazu(a)cvc.uab.cat>
Date: Monday, 12 February 2024 at 15:12
To: users(a)nest-simulator.org <users(a)nest-simulator.org>
Subject: [NEST Users] Re: Weights assignment error with mpirun
[Some people who received this message don't often get email from xotazu(a)cvc.uab.cat.
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
A small clarification ... I always used 64 mpi processes to run my code (hence, the 30-40
speedup performace is because of your new code).
Xavier
_______________________________________________
NEST Users mailing list -- users(a)nest-simulator.org
To unsubscribe send an email to users-leave(a)nest-simulator.org
76
days inactive
81
days old
16 comments
2 participants
participants (2)
-
Hans Ekkehard Plesser -
Xavier Otazu