search

NeuralEnsemble / PyNN

A Python package for simulator-independent specification of neuronal network models.
Other
276 stars 126 forks source link

Check use of GetConnections #672

Closed apdavison closed 3 years ago

apdavison commented 4 years ago

see message from Håkon Mørk on NEST Users mailing list from February 28th 2020:

With NEST 2.16 and onward, connection infrastructure requires connections to be sorted. Sorting is triggered when calling for example Simulate() or GetConnections(). Therefore, if you have stored your connections with GetConnections(), then create more connections, and the connections are sorted again (e.g. calling GetConnections(), then Connect(), then GetConnections() again), the connections you have stored are no longer valid.

Now, with NEST 2.20, a warning is issued when creating more connections after the current connections have been sorted. This has nothing to do with https://github.com/nest/nest-simulator/pull/1251. As Alex Serenko pointed out, GetConnections() should be placed after all your Connect() calls to avoid invalidating stored connections.

There are however a couple problematic cases. The warning is issued when creating more connections on top of already sorted connections. This means that calling other functions that trigger sorting (for example Simulate()) between Connect() calls also triggers the warning, even if you haven't called GetConnections().

A potentially more serious issue is if you are using PyNN. Creating connections in PyNN may automatically store connections in the Projection object, meaning it calls both Connect() and GetConnections(). Creating Projection objects will therefore trigger the warning every time. Furthermore, creating more than one PyNN Projection object may invalidate the connections stored in all but the last Projection created.

apdavison commented 3 years ago

In certain situations PyNN caches the output of GetConnections. This cache is invalidated for a given Projection if new connections are added to the Projection. However, the change to NEST means that all caches need to be invalidated when a new Projection is created.

This problem is unlikely to have affected many PyNN scripts, the only scenario I can think of is if a Projection's attributes were accessed, then new Projections created, then the attributes accessed again.