Hi Andreas (and all fellow Spikey users),
I can confirm that neuron IDs are global. I was struggling with the same issue a while ago. I ended up wrapping the pyNN calls into my own population-like objects that would handle everything that involves neuron IDs (like providing spike data etc), and map it into a more convenient space.
If I remember correctly, the reason for the neuron IDs being global was that on the hardware they are actually constant, i.e. neuron ID 163 always refers to the same physical neuron on the chip (unless you specify neuronPermutation in setup(), that is). At least this was how it was explained to me ;) Maybe one of the Spikey software developers wants to provide more information?
Cheers,
Michael
> On 14 Oct 2015, at 01:20, Andreas Stoeckel <[log in to unmask]> wrote:
>
> -----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:
> http://listserv.uni-heidelberg.de/cgi-bin/wa?TICKET=NzM1OTE1IG0uc2NobXVrZXJAQklPTUFDSElORUxFQVJOSU5HLk5FVCBLSVAtU1BJS0VZLVVTRVJTIGWEf25WOO4L&c=SIGNOFF
--
Michael Schmuker
University of Sussex
School of Engineering and Informatics
Falmer, Brighton BN1 9QJ
Tel: +44 (0) 1273 876565
http://biomachinelearning.net
########################################################################
To unsubscribe from the KIP-SPIKEY-USERS list, click the following link:
https://listserv.uni-heidelberg.de/cgi-bin/wa?SUBED1=KIP-SPIKEY-USERS
|
