In addition to the issues noted below, you can refer to our bug tracker on GitHub.
List of known issues
- Cannot find msvcr90d.dll
- “AttributeError: MSVCCompiler instance has no attribute ‘compiler_cxx’”
- “Missing compiler_cxx fix for MSVCCompiler”
- Problems with numerical integration
- Jupyter notebooks and C++ standalone mode progress reporting
- Parallel Brian simulations with the
weavecode generation target
- Parallel Brian simulations with C++ standalone
- Slow C++ standalone simulations
- Cython fails with compilation error on OS X:
error: use of undeclared identifier 'isinf'
- CMD windows open when running Brian on Windows with the Spyder 3 IDE
If you see this message coming up, find the file
and modify the line
msvcr_dbg_success = build_msvcr_library(debug=True) to read
msvcr_dbg_success = False (you can comment out the existing line and add the new line
This is caused by a bug in some versions of numpy on Windows. The easiest solution is to update to the latest version of numpy.
If that isn’t possible, a hacky solution is to modify the numpy code directly to fix the
problem. The following change may work.
Modify line 388 of
elif not self.compiler_cxx: to
elif not hasattr(self, 'compiler_cxx') or not self.compiler_cxx:. If the line
number is different, it should be nearby. Search for
elif not self.compiler_cxx in
If you keep seeing this message, do not worry. It’s not possible for us to hide it, but doesn’t indicate any problems.
In some cases, the automatic choice of numerical integration method will not be appropriate, because of a choice of parameters that couldn’t be determined in advance. In this case, typically you will get nan (not a number) values in the results, or large oscillations. In this case, Brian will generate a warning to let you know, but will not raise an error.
When you run simulations in C++ standalone mode and enable progress reporting
(e.g. by using
report='text' as a keyword argument), the progress will not
be displayed in the jupyter notebook. If you started the notebook from a
terminal, you will find the output there. Unfortunately, this is a tricky
problem to solve at the moment, due to the details of how the jupyter notebook
When using the
weave code generation target (the default runtime target on
Python 2.x, see Runtime code generation for details), you should avoid running multiple
Brian simulations in parallel. The
weave package caches compiled files,
but this cache is not prepared for multiple concurrent updates. If two Python
scripts (or two processes started from the same Python script, e.g. via the
multiprocessing package) try to store compilation results at the same time,
weave will crash with an error message. The
are not affected by this problem.
Simulations using the C++ standalone device will create code and store results
in a dedicated directory (
output, by default). If you run multiple
simulations in parallel, you have to take care that these simulations do not
use the same directory – otherwise, everything from compilation errors to
incorrect results can happen. Either chose a different directory name for each
simulation and provide it as the
directory argument to the
build call, or use
will use a randomly chosen unique temporary directory (in
Unix-based systems) for each simulation. If you need to know the directory name,
you can access it after the simulation run via
Some versions of the GNU standard library (in particular those used by recent
Ubuntu versions) have a bug that can dramatically slow down simulations in
C++ standalone mode on modern hardware (see #803). As a workaround, Brian will
set an environment variable
LD_BIND_NOW during the execution of standalone
simulations which changes the way the library is linked so that it does not
suffer from this problem. If this environment variable leads to unwanted
behaviour on your machine, change the
Try setting the environment variable
This is due to the interaction with the integrated ipython terminal. Either change the run configuration to “Execute in an external system terminal” or patch the internal Python function used to spawn processes as described in github issue #1140.