-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Spikey developers and users,
I just tried the Spikey-system that was lent to Bielefeld University
at the HBP-Summit, and I thought it would be nice to share my
experiences and problems with you.
First off, the SDK installation as described in the HBP-Guidebook
[3] worked without any significant problem on my Fedora 22 notebook;
there was a small issue with code not compiling with GCC 5.1 due to
missing <iostream> includes, but this was easily fixed, I already
filed a pull-request for the component in question and Eric already
took care of that. (Kudos to Eric).
For enabling access to the USB-device as non-root, I did not follow
the guidebook, but simply added the following udev-rule to my system
(as /etc/udev/rules.d/spikey.rules):
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04b4",
ATTRS{idProduct}=="1003", MODE:="0666"
This is my usual approach for libusb-based software and it seems to
work without any problem.
The examples included in the SDK seem to run fine and I've added
support for Spikey and PyNN 0.6 to my PyNN-wrapper "PyNNLess" [1].
So, now for the problem, which took me a few hours to hunt down: I
tried to run an instance of the network I'm currently working on in
Spikey, however, it did not work as expected. I narrowed the problem
down to the neuron-ids in the spike arrays being global instead of
population-local.
I built a simple use-case that shows this bug: A single spike source
projects onto three neuron populations with one neuron each (note
that the second neuron seems to be consistently silent on my device,
but this is not a problem per-se):
Pop 1:
[[ 0. 104.40000153]
[ 0. 203.3999939 ]
[ 0. 303.54998779]]
Pop 2:
[]
Pop 3:
[[ 2. 104.05000305]
[ 2. 203.30000305]
[ 2. 303.45001221]]
Note that population 3 returns spikes for a neuron "2" that does not
exist in this population. If I increase the population size of
population 1 to two, I get the following result:
Pop 1:
[[ 0. 104.30000305]
[ 0. 203.5562439 ]
[ 0. 303.55938721]]
Pop 2:
[[ 2. 103.95937347]
[ 2. 203.40937805]
[ 2. 303.4125061 ]]
Pop 3:
[[ 3. 103.12187195]
[ 3. 202.8218689 ]
[ 3. 302.7718811 ]]
So my conclusion is that the returned neuron indices are global,
instead of population-local. This neither makes any sense (as it
induces an order onto the populations that is potentially unknown to
the user), nor does any other PyNN interface known to me (and I've
crunched through quite a few by now) exhibit this behaviour.
However, this behaviour seems to be actively used in the Spikey
examples, so I begin to fear this bug might be a "feature" after all.
I've provided the minimal code example for the results above here:
https://gist.github.com/astoeckel/9448859c6af9b7b1bd2b
I also added a workaround for this bug to PyNNLess [2] assuming that
the neurons are numbered in the way I expect them to be numbered
(which may be wrong) -- this basically seems to work.
Unfortunately I can't find a bug-tracker associated to the
Spikey-PyNN code so I'll both leave reporting and fixing the bug to
you ;-)
Thanks for your support!
Best regards,
Andreas
PS: The fan of the device is really annoyingly loud ;-)
[1] https://github.com/hbp-sanncs/pynnless
[2]
https://github.com/hbp-sanncs/pynnless/commit/73b154a6c89dcd17ac0f0913
fa67e08c437aace1
[3]
http://electronicvisions.github.io/hbp-sp9-guidebook/appendix.html#lab
el-spikeysoftware
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWHZ/AAAoJEGiL9AshMiPduRAIAL1Qpa/Ieb2v6N1Lw821Ff2k
npyRtSimX3NVCAznegoBGO13zK2tvDg/s3urPnV9PKTuOW/PujJVczVL79rOp51l
zi5Dgu8orvYRWmwKGUNnoEgG3a0W17N0PY8HeSB05UHAu6xChhagAt5qEdWkiwDO
mD+MKIDPBwJxjgHTtukmlgabg+zpzgE3bOZFYD9o33tPNscGrIT3Wx9PT3jC5XH3
96F74SPuGy6G+Tlx6vg+gDj4D/4gpY+5DMAYiwcCcOFnXEllu4sRtt0LJCe2ow4J
lbXaBwcs47mLPu97ZiH8qgaZyIoEAkNYqVAIQIPfkTd+ImZsRuPq7Fg8ozuHACo=
=3IkR
-----END PGP SIGNATURE-----
########################################################################
To unsubscribe from the KIP-SPIKEY-USERS list, click the following link:
https://listserv.uni-heidelberg.de/cgi-bin/wa?SUBED1=KIP-SPIKEY-USERS
|
