Closed russelljjarvis closed 4 years ago
Can you gradually change ReducedModel into VeryReducedModel to identify which step of the change causes it to fail during DEAP optimization? Maybe you can start by having VeryReducedModel actually subclass ReducedModel, but then just start overloading its various methods and emptying them out to see which one turns out to be important.
Yes, I think that too. Subclass Reduced model and override the constructor.
This is done, as a temporary measure.
I now have VeryReducedModel.
It's desirable to have a model class that does not force unused variables like LEMS path.
Efforts to define one such as below cause a bad interaction between DEAP and sciunit. I think it has something to do with the code used to remove NEURON C objects from models to make them pickable.
What doesn't work: Both of the classes below (1 and 2) work superficially and would run with code for obtaining Rheobase etc. These objects only fail when entering +1 generations of DEAP optimisation, and then it seems like it is because of DEAPs backend and sciunit backend competing to try to do some kind of object attribute manipulation.
1 Inheriting from External model
2 Inhering from Runnable
https://github.com/russelljjarvis/neuronunit/blob/barcelona/models/very_reduced.py
Using the regular ReducedModel still works.
Stack trace.