SpikeGenerator not always producing correct number of spikes

7 views
Skip to first unread message

Anthony Sherbondy

unread,
Dec 22, 2009, 10:06:22 PM12/22/09
to Brian
I have the following simple test code:

for ii in range(0,5):
# Setup a new clock
sim_clk=Clock(dt=0.1*ms)

# Setup up a particular sequence of spikes
spiketimes = [(0,1*ms),(0,5*ms),(0,10*ms),(0,15*ms)]
layer1 = SpikeGeneratorGroup(2,spiketimes,clock=sim_clk)

# Setup output recorder
spikes1=SpikeMonitor(layer1)

run(20*ms)

print 'Counted %d spikes.' % (spikes1.nspikes)
sys.stdout.flush()

As you can see it should spike 4 times each of the 5 times I run the
loop. Unfortunately, the network spikes either the right number of
times or zero times as shown here:

In [307]: execfile('check_spiking.py')
Counted 4 spikes.
Counted 0 spikes.
Counted 4 spikes.
Counted 0 spikes.
Counted 4 spikes.

In [308]: execfile('check_spiking.py')
Counted 4 spikes.
Counted 4 spikes.
Counted 0 spikes.
Counted 0 spikes.
Counted 0 spikes.

Am I doing something silly here? I have Brian1.1.3, Python2.5,
MacOSX. Thank you very much for your help

Dan Goodman

unread,
Dec 23, 2009, 5:13:33 AM12/23/09
to brians...@googlegroups.com
Hi Anthony,

There is a bug here that is to do with multiple clocks. You can fix the
problem below by adding the function clear() at the end of the for loop.
See the docs at:

http://www.briansimulator.org/docs/reference-network.html#brian.clear

The problem is that on the second pass through the for loop, Python
hasn't destroyed the objects from the first run of the for loop, so they
are still forming part of the network that is being run. In other words,
in the first run through it is simulating one group of neurons on one
clock, in the second run it is doing two groups of neurons with two
clocks, on the third three groups with three clocks, etc. That's why you
have multiple clocks even though it seems that you should only ever have
one at a time from looking at your code.

The reason that multiple clocks are interfering with each other and
causing spikes to be missed is a bug in Brian that will be fixed in the
next release. If you are only ever simulating with one clock at a time
though, this shouldn't affect you.

Does that solve your problem? If you have multiple clocks in your actual
code and are concerned that there might still be problems, please let us
know.

Dan

> --
>
> You received this message because you are subscribed to the Google Groups "Brian" group.
> To post to this group, send email to brians...@googlegroups.com.
> To unsubscribe from this group, send email to briansupport...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/briansupport?hl=en.
>
>
>

Anthony Sherbondy

unread,
Dec 23, 2009, 10:51:57 AM12/23/09
to Brian
Thank you for the fast reply. This solves my problem.
Reply all
Reply to author
Forward
0 new messages