Computational basis for BCPNN learning rule

[zenke]

Hi,
The comparisons look indeed very good. Fingers crossed it will scale well!

Delays: Individual delays are something that is still a bit underdeveloped in Auryn because I never played with this in my simulations. Out of the box Auryn supports "axonal" delays on a per SpikingGroup/NeuronGroup basis (can be set in SpikingGroup https://fzenke.net/auryn/doxygen/curren ... f84e08f079) - not on a per Connection basis.

However, per Connection delays should be easy enough to implement by dint of SpikeDelay https://fzenke.net/auryn/doxygen/curren ... Delay.html. This is possible as long as it is fine to make the delays larger than the axonal delay (that's because we use the axonal delay as MINDELAY for parallel simulations). If adding more delay is fine, it can be added to a connection object as a "dendritic" delay.

To do this you will have to modify the propagate function in your Connection class. To test whether this works I just added and pushed a new class DelayConnection to the develop branch which illustrates the basic principle https://github.com/fzenke/auryn/blob/de ... ection.cpp

Code: Select all

void DelayConnection::propagate()
{
    // pop buffer from delay and push spikes from src to back
    src_dly->get_spikes_immediate()->clear();
    src_dly->push_back(src->get_spikes());


    // do normal forward propagation as in SparseConnection
    for (SpikeContainer::const_iterator spike = src_dly->get_spikes()->begin() ;
            spike != src_dly->get_spikes()->end() ;
            ++spike ) {
        for ( AurynLong c = w->get_row_begin_index(*spike) ;
                c < w->get_row_end_index(*spike) ;
                ++c ) {
            transmit( w->get_colind(c) , w->get_value(c) );
        }
    }
}

The first two lines make sure that the added SpikeDelay is reset and spikes from src are added to the delay. The second part is the same as propagate in SparseConnection, but using the delayed spikes from src_dly.

I do not have the time to test this extensively right now, but https://github.com/fzenke/auryn/blob/de ... ection.cpp illustrate a basic use and it seems to be doing the right thing on first coarse inspection:

epsc_w_delayed_ipsc.png (27.12 KiB) Viewed 18880 times

Finally, if you need per-synapse delays it should be relatively simple to extend the above code to add a complex synaptic state storing the per-synapse delay and then inserting the spikes from src sensibly in the ring buffer of src_dly such that they end up having the right delay. SpikeDelay has functions to insert spikes at arbitrary locations into the ringbuffer if I remember correctly. However, these functions should be tested thoroughly before relying on them.

[ala]

Hi Friedemann,
thanks for input on conduction delays. But for our networks we need to have pairwise delays between minicolumns and I think this cannot be achieved by means of these mechanisms you mention, or ...?

Most work for me the past week has been to fix the multicore simulation and monitoring of the bcpnn parts. But now my tests work and they produce outputs of bcpnn variables and scaling as seen in these two figures. I now plan to go on to test some more interesting networks.

The scaling plot shows that STDP is very light-weight computationally and bcpnn is much heavier. But also that scaling of bcpnn is very good up to 512 cores and for stdp or no plasticity it is useless with many cores for this network. But I am not sure my bcpnn implementation is done the best way - I had to resort to 3-state connections with wij, pij, pi states. And there is likely room for some optimization as well, which I did not attempt.

Regarding the comparison of python-bcpnn and auryn-bcpnn it looks quite good. The difference in pij proibably is because I don't delay spikes in my python code. Btw the spiking of the pre- and post neuron is on the last row in the spike raster on top. This connection is between poisson neuron 179 and TIFneuron 78 in a feedforward network with 200 and 100 units in input and output layer respectively.

I have pushed my code to my forked Github repository. I will soon issue pull request from there. It would be very helpful if you had some little time to look at it and try perhaps.I have marked the changes in auryn .h and.cpp files with "ALa added" "ALa changed" so you can easily see. I guess that is not the best way to review changes ...

Best!/Anders La

[zenke]

But for our networks we need to have pairwise delays between minicolumns and I think this cannot be achieved by means of these mechanisms you mention, or ...?

If I understand you correctly, then you want to be able to set a different delay for each synapse? You are right, this is currently not possible with the, but it would not be hard to implement it as an extension of DelayConnection. I think that somebody in Nicola Brunel's lab has done that. What are the typical delay ranges you are after?

Most work for me the past week has been to fix the multicore simulation and monitoring of the bcpnn parts. But now my tests work and they produce outputs of bcpnn variables and scaling as seen in these two figures. I now plan to go on to test some more interesting networks.

Very nice. It seems that it might be a good idea to start putting your simulation code in a separate repository once the underlying connection class is a little stabilized. I would suggest we that we merge your BcpnnConnection and one nice example into the Auryn distribution to keep it lean. What do you think?

The scaling plot shows that STDP is very light-weight computationally and bcpnn is much heavier. But also that scaling of bcpnn is very good up to 512 cores and for stdp or no plasticity it is useless with many cores for this network. But I am not sure my bcpnn implementation is done the best way - I had to resort to 3-state connections with wij, pij, pi states. And there is likely room for some optimization as well, which I did not attempt.

I will certainly have a look at it and see whether I can suggest some additional optimizations. Once thing that I immediately thought of when seeing your results is that you could try reducing the parameter "#define DEFAULT_MINDISTRIBUTEDSIZE 16" in auryn_definitions.h -- it achieves that NeuronGroups are not split smaller than 16 per default. This makes sense for simulations with light-weight STDP simulations, but since in your case most of the computational load resides with the synapses it could make sense to actually have smaller group sizes. If you are lucky this will improve the scaling by a bit. Currently the ratio 8000neurons/500cores=16 could be a coincidence, but it might be just that Auryn doesn't use the additional cores because it does not reduce the group sizes further. Other comments will have to wait until I analyzed your code more carefully. I am also still working on improving SyncBuffer to support different send sizes ...

Regarding the comparison of python-bcpnn and auryn-bcpnn it looks quite good. The difference in pij proibably is because I don't delay spikes in my python code. Btw the spiking of the pre- and post neuron is on the last row in the spike raster on top. This connection is between poisson neuron 179 and TIFneuron 78 in a feedforward network with 200 and 100 units in input and output layer respectively.

This looks quite good indeed. The difference could also be due to the fact that there might be some inconsistencies between the update/record order in Auryn and you example code. In that case the traces should fall on top of each other when you multiply/divide by exp(-auryn_timestep/tau_trace). Just a small thing worth checking. Maybe it is actually identically what both sims are computing.

I have pushed my code to my forked Github repository. I will soon issue pull request from there. It would be very helpful if you had some little time to look at it and try perhaps.I have marked the changes in auryn .h and.cpp files with "ALa added" "ALa changed" so you can easily see. I guess that is not the best way to review changes ...

I see. I will look into that. Normally you do not need to mark such changes separately, because git does that for you. For instance "git blame" will show you who wrote each individual line in a file. Since you changed some parts of the Auryn repository quite extensively, I probably won't be able to merge most of of your pull request. As suggested above, I will only pull select changes, BcpnnConnection and maybe one example which uses it. I would then include a url pointer to your repository with the more extensive examples and documentation. That's for instance also what I did with SuperSpike which is housed in a separate repo https://github.com/fzenke/pub2018superspike. It keeps the Auryn library lean an clean by separating it from individual projects.

Btw, did you have time to review my suggested changes in https://github.com/fzenke/auryn/tree/dev-bcpnn ? For instance this implementation gets away without your addition of kinc to the Trace class etc ...

[zenke]

Hi Anders,
I just merged of BcpnnConnection to branch dev-bcpnn with some change suggestions. I used sim_brunel2k_bcpnn to test that my version and yours produce the same output. I did not merge several modifications you did to the Monitor class and other files because I wasn't sure about them. I left some questions and comments in my code review in your pull request on GitHub. Also I moved your pull request target to dev-bcpnn. Maybe we can converge in our efforts there. I know you haven't used GitHub extensively before, but I hope you find the code review helpful.
Cheers,
Friedemann

[zenke]

Just committed a new version to the develop branch which now uses MPI_Allgatherv to sync the different processes with variable sizes. Would be interesting if this version of SyncBuffer works with your code. Not sure it will save us a lot, but potential savings are high if different ranks produce vastly different numbers of spikes at times ... the overhead should be negligible.