GSoC Project Idea 10.1: Model fitting

GSoC
,
1

Fitting models of neurons to experimental data is a common task in computational neuroscience. In 2010, a modelfitting toolbox (https://doi.org/10.3389/neuro.11.002.2010) has been developed that allows to describe and simulate models with the version 1 of the Brian simulator and then to use optimization algorithms to fit such models to data obtained in experiments. This toolbox is no longer compatible with the current version of the Brian simulator. However, it already made heavy use of the code generation technique which has become a core approach of the Brian simulator itself since then. The aim of this project is therefore to:

  • Investigate the existing modelfitting toolbox in order to determine how much of its code has been made obsolete by features in the latest version of Brian
  • Get an overview over existing Python packages for modelfitting and decide whether it makes sense to integrate/re-use them
  • Rewrite/adapt the toolbox to work with Brian 2

Skills: Python programming, basic experience with neural modeling; experience with C++ and Cython helpful
Mentors: Marcel Stimberg, Dan Goodman

1 Like
2

Hello! My name is Pablo and I am a master student in the University of Sao Paulo, Brazil. I got interested on this project and I do have the skills needed to carry it out. Right now, I have some questions:

I also started reading the paper cited in the description, but can anyone give me a clue about what would be a next step?

Thank you for your attention!

3

Hi Pablo, thanks for the interest in the project!
The link for the modelfitting toolbox is the correct one. Whether it should use playdoh is one of the questions that we have to answer in the initial phase of the project. The playdoh library is no longer maintained, so we’d have to first estimate how much work is necessary to get it to work for our use case and whether it is worth the effort to essentially take over its maintenance. It might make sense to rather use a general library that helps with distribution over CPUs (e.g. joblib), or use an optimization library that builds on top of that (such as scikit-optimize). Alternatively, we might even want to build on top of an existing high-level library such as BluePyOpt. We’ll have to figure out how compatible all this is with our approach to code generation, though.

Apart from getting an idea of what the above mentioned tools (and other existing tools) do, I think the most important things to look at currently would be to 1) try to get an in-depth understanding of the existing modelfitting toolbox based on the article and by running its code, and 2) to get an idea of how code generation works in Brian 2, by looking at our paper and running some code.

It is still quite early with respect to the application deadline, so no worries if the project is still a bit vague.

4

I understand. Thanks for the help! I will do it and come back when I have new questions.

5

Hi, I am having some trouble running modelfitting.py. Playdoh throws an exception when trying to run line 208 in synchandler.py:

result = getattr(task, m)(*a, **k)

The exception apparently happens three times, when getattr tries to call the methods start, initialize and get_result from class Optimization. The error messages are, respectively:

Traceback (most recent call last):
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/synchandler.py”, line 208, in execute
result = getattr(task, m)(*a, **k)
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/optimization.py”, line 268, in initialize
self.initialize_algorithm()
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/optimization.py”, line 288, in initialize_algorithm
self.engine.initialize()
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/cma_es.py”, line 103, in initialize
self.fitness_gbest = inf * ones((self.groups,self.mu))
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/numpy/core/numeric.py”, line 192, in ones
a = empty(shape, dtype, order)
TypeError: ‘numpy.float64’ object cannot be interpreted as an index

Traceback (most recent call last):
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/synchandler.py”, line 208, in execute
result = getattr(task, m)(*a, **k)
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/optimization.py”, line 353, in start
fitness = self.get_fitness()
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/optimization.py”, line 315, in get_fitness
param_values = self.parameters.get_param_values(self.X)
AttributeError: ‘Optimization’ object has no attribute ‘X’

An exception occurred in sub-process #0
Traceback (most recent call last):
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/synchandler.py”, line 208, in execute
result = getattr(task, m)(*a, **k)
File “/home/pablo/.conda/envs/brian1/lib/python2.7/site-packages/playdoh/optimization/optimization.py”, line 410, in get_result
group_best_X = self.best_X[group]
AttributeError: ‘Optimization’ object has no attribute ‘best_X’

I am not using any gpu and set the simulation to run with only 1 cpu. Is this an issue?

6

Hi. Yes, problems like this are not surprising given that playdoh is no longer maintained and has not been updated for years… Your problem seems to be relatively easy to fix, though (I did not try it out): earlier numpy versions were fine to accept “round” float values instead of integers in several places, e.g. you were allowed to write np.ones((3.0, 4)) instead of np.ones((3, 4)) to get a 3 x 4 matrix of ones. In recent numpy versions, this will raise an error. In the code that raises an error for you, I think the culprit is self.mu which gets calculated and ends up being a floating point value instead of an integer. You should be able to fix this by replacing self.mu by int(self.mu) (l. 103 in cma_es.py) – presumably there are many more things to fix like this. This is partly what I meant by “The playdoh library is no longer maintained, so we’d have to first estimate how much work is necessary to get it to work for our use case” in my earlier reply.

For playing around with playdoh without spending too much time fixing it, an alternative should be to simply downgrade your numpy version. I guess the latest version of numpy that was still tested with playdoh is something like 1.7…

7

Thanks! Casting self.mu to int indeed fixed the problem. For now I will keep using the most recent version of numpy just to get an idea of how compatible it is with playdoh, but if more errors appear I will definitely downgrade.