Test external modules with 5G

[heplesser]

All modules listed at https://github.com/nest/nest-simulator/wiki/NEST-Modules must be tested with 5G.

[hakonsbm]

SpikeDetectorFuse

• Compiles without any problems.
• Raises the following error when the included example is run:
  error: void nest::Node::set_local_device_id(nest::index): Assertion 'false && "set_local_device_id() called on a non-device node of type"' failed.

spore-nest-module

• Problems when installing with master
  • CMake doesn't pick up specified compiler from NEST installation.
  • Problem in help_generator/writers.py, where write() wants a unicode argument, but gets a string (at least in Python 2).
  • One test fails (test_music_integration.py), but this is related to errors when running examples.
  • All examples fail with the following error message:
    File "./zmq_proxy_node.py", line 55, in _setup
self._serializer = SERIALIZERS[music_zmq_proxy_config['communication']['format']]
KeyError: 'ujson'
• When trying to install with 5g, the module won't compile because it's using the following classes and functions that are removed or changed in 5g:
  • pack_pointer
  • validate_pointer
  • HetConnector
  • vector_like
  • has_primary
  • has_secondary
  • ConnectorBase::homogeneous_model
  • DiligentConnectorModel

nest-module-STDPStructplast

• Model has to be updated from using t_lastspike as a function argument, to having it as a private class variable.
• After attempting to update the model, the module compiles, but unittests fail because of wrong results.

nest-stdpmodule

• Compilation fails in both master and 5g with the following error message:
  libtool: error: libtool library 'stdpmodule.la' must begin with 'lib'

[hakonsbm]

Update after looking more into the problems with two of the modules:

SpikeDetectorFuse

• Tried updating the model for 5g, and the test now passes.

spore-nest-module

• The module itself is apparently in a subdirectory. Therefore one gets the issue with redefinition of compiler.
  • Can work around this by running CMake with the subdirectory directly.
• The problem in help_generator/writers.py happens only in master (and presumably only with Python 2). The problem comes from the fact that there is no documentation to be read from the module sources. Normally the documentation would be read as unicode, formatted, then written as unicode. But if there is no documentation (the list hlp_list is empty), the return value of '\n'.join(hlp_list) is a basic string, not unicode. Trying to write that empty string to a file as unicode raises the error.
• The ujson problem was fixed by installing the UltraJSON Python package.
• With workarounds for the mentioned problems, tests pass and examples work in master.

[kappeld]

regarding spore-nest-module: Thanks for picking this issue up. We also realized this problem recently. Since SPORE installs its own ConnectorModel, which was re-factored quite a bit in 5G, this will involve some work...

I looked into this a little bit. I think there are two major changes that need to be made:

1. SPORE implemented its own version for removing synapses, since structural plasticity was so far only useful for homeostatic processes, where synapses can not decide on their own that they prefer to be removed. We implemented a workaround, where synapses could mark themselves to become disconnected and then they get picked up by a "garbage-collector" that is triggered in regular intervals. I think pretty much the same functionality was now introduced into NEST with 5G. So we should remove that part from SPORE and use the native version in the synapse model. That should be quite easy if I am not missing something.

2. The second change is a bit trickier. SPORE has developed its own ConnectorModel that behaves a bit different from the native NEST implementation. So, SPORE synapse models are registered with a custom ConnectorModel. The biggest Problem seems to be that new connectors are not keeping the t_last_spike information any longer, which we used internally to keep synapses up to date. One option would be to just derive a new class from ConnectorBase that behaves like the old model, and use this instead of ConnectorBase in all SPORE-related nodes. This should still work with the new kernel and would be backward-compatible to SPORE. I have to investigate if this causes some additional issues though.

[kappeld]

Since fixing this will most likely not effect the development of NEST, I suggest that we continue the discussion here: IGITUGraz/spore-nest-module#26

[heplesser]

@hakonsbm Thanks for testing! The problems with SPORE seem solvable and since the other modules do not work out-of-the box with master, I suggest to close this issue and consider external modules reasonably under control wrt 5g.