abstract model class PyNN_model

[rgutzen]

No description provided.

[rgerkin]

We started something like this here but did not get very far. In particular we implemented this as a backend (like a simulator) but I think this was the wrong strategy and we should have made it a model class like we did for LEMSModel here. In any case, I think both @russelljjarvis and I would be interested in following along with this issue.

[russelljjarvis]

@rgutzen if I create an abstract model pyNN backend for NetworkUnit, I wonder if there are some NetworkUnit scripts I can run it with to demonstrate the integration is good?

[russelljjarvis]

This file represents the extent of the work. Note I don't remember if that file actually works, but it was more of a guess at what the design of a network NU test class for pyNN would look like.

I am not sure how valuable it is to write generic classes for things like Network models. It might be okay to have a naive PyNN network model, and to bind methods to this network model that NU needs to use to evaluate model fitness.

[rgerkin]

I think it is probably less about whether there should be generic network models, and more about whether it is useful to have PyNN bindings in a SciUnit model. I have found having the LEMSModel class very useful for all things NeuroML-related, and so a PyNNModel could follow the same logic, where the core idea is that the constructor takes a PyNN model, and then the various sciunit.Model methods and capabilities are implemented by calls to that PyNN model's methods.

[rgutzen]

The idea behind such a model class was that it is generally not practical or desirable to require users and developers to reimplement each network model into the sciunit structure in order to validate it. So, there two approaches of how to make the integration of new network models easier and lower the threshold for actual use cases: a) create an intuitive interface to link to external scripts that build and run models on their own (#11 ). b) make the model definition within a model class as simple as possible, hence PyNN.
So, as @rgerkin mentioned, it would rather be about enabling a model class to use PyNN bindings and having either backends or the base class to understand and execute the model simulation (using any PyNN related simulator).

[rgerkin]

I think a) and b) are compatible. With my implementation of #11 in sciunit, one can do sciunit run from the command line and, based on the content of a config file (which makes no assumptions and only points to the locations of python files), runs collections of models and tests expressed in python files. Such a file could, for example, consist of:

from networkunit.pyNN import PyNNModel
paths = ['/path/to/pyNN_model_1.py', '/path/to/pyNN_model_2.py']
models = [PyNNModel(path) for path in paths]

where the paths in the list are for files that create pyNN models, and then the PyNNModel class wraps them in sciunit.Model, with other feautures of course. sciunit run knows to look for a list of sciunit models in the models variable (or another location can be specified in configuration), so this (along with tests) is sufficient for programmatic testing.

@rgutzen Maybe you can conceive of the minimal form of the PyNNModel class, i.e. what the constructor would look like (paths to python files that create pyNN models? actual instances of pyNN models?) and what generate_prediction would need to call to run those models and get the relevant outputs.