The neuro software gap

Our foray into Julia was mostly motivated by a desire to have a programming language as fast as C but as easy to program as Matlab. In particular, we need really fast looping speed, which is necessary to simulate dynamical systems. Our particular project involves fitting a conductance-based model (i.e. Hodgkin-Huxley-like equations) to some data using MCMC. We’re not trying to fit the precise spike shapes per se but the firing rates of synaptically coupled pools of neurons in response to various inputs. We thus need to run simulations for some time, compare the averaged rates to previous runs, and iterate. For good fits, we may need to do this a million times. Hence, we need speed and we can’t really parallelize because we need information from one iteration before going to the next.

Now, one would think that simulating neural networks is a long solved problem and I thought that too. Hence, I instructed my fellow Wally Xie to look into all the available neural simulators and see what fits the bill. We first tried Neuron but couldn’t get all of it to work on our Linux machine running CentOS (which is what NIH forces us to use).  That was the end of Neuron for us. We next tried Nest but found it difficult to specify the neuron model. We finally settled on Brian, which is adaptable, written in Python, and supported by very nice people, but is turning out to be too slow. Native Python is also too slow. Stan would be great but it does not yet support differential equations. Wally is now implementing the code in Julia, which is turning out to be very fast but has a possible bug that is preventing long runs. The developers are extremely helpful though so we believe this will be worked out soon. However, it is hard to get plotting to work on Julia and as pointed out by many, Julia is not nearly as complete as Python or Matlab. (Yes, Matlab is too slow). We could use C and will go to it next if Julia does not work out. Thus, even though people have been developing neural simulators for decades, there is still an unmet need for something adaptable, fast, easy to use, and runs out of the box. A neuro-Stan would be great.

13 thoughts on “The neuro software gap

  1. I’m still confused why you don’t think PyDSTool could fill this here gap. It has user-definable classes on top of neuron component template classes a bit like Neuron, and it “compiles” down to C code, has DS tools associated with it natively, and yet retains the top-level flexibility of Python. I know our documentation could be better but I’d love to know what needs to be done to make it attractive to you to solve such a problem, because that’s basically what it is designed for!


  2. @robclewley We are running OSX 10.8 and later and our Python installation is going through Homebrew so we’re not sure if we can run PyDSTool.


  3. At this point, with a stable scipy/python stack for 10.8, it should be possible to install that with homebrew. I haven’t personally set up PyDST with Homebrew but I know others who have done that with 10.7. I’ll be happy to help tweak anything for access to gcc/gfortran – and you’ll probably have to install SWIG through homebrew. You should probably make sure to try testing with the current Master branch of PyDST on github, which is already a lot more friendly to recent OS and library versions:


  4. It shouldn’t matter and it’s pretty simple to try if you already have the scipy stack installed and if you can get gfortran, gcc, and SWIG installed. Just let me know if you have any problems, and be sure to follow the instructions for Macs on the Getting Started page as closely as possible.


  5. @robclewley gcc is no longer supported in 10.9. It’s clang now and there are differences. Using gcc breaks everything as we found out the hard way.


  6. No worries, the latest github master HEAD should be compatible with clang without adjustment. We were just working on that recently. Any adjustments that might be needed are simple, but I’d have to first check with the developer who made it clang compatible if it doesn’t work out of the box. Send me any error messages by email!


  7. For plotting in Julia, this works for me:

    julia> using PyCall
    julia> @pyimport matplotlib.pyplot as plt

    Now you can use matplotlib.pyplot just as you would in Python. For example,

    julia>x=randn(1000,1); y=.7*x+.7*randn(1000,1); plt.plot(x,y,”.”);


  8. Hi- what about Apple’s new Swift programming language? It is suppose to be fast. See


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s