bhallalab/moose-core

C++ basecode and python scripting interface

moose-core's Issues

segfault if `moose.Function` is created under `stoich.path`

moose.reinit() causes seg-fault if there is moose.Function under its path. A minimal working snippet is below

import moose
compt = moose.CubeMesh('/compt')
compt.volume = 1e-20

a = moose.Pool('/compt/a')
b = moose.Pool('/compt/b')

a.nInit, b.nInit = 100, 10

atab = moose.Table2('/tableA')
btab = moose.Table2('/tableB')
moose.connect(atab, 'requestOut', a, 'getN')
moose.connect(btab, 'requestOut', b, 'getN')

# Add a function which set conc of a

## NOTE: This cause seg-fault.
func = moose.Function('/compt/a/function')

# This does not.
#func = moose.Function('/func')

func.expr = '100*(1 + sin(0.1*t))'
func.mode = 1
moose.connect(func, 'valueOut', a, 'setN')

reac = moose.Reac('/compt/reac')
moose.connect(reac, 'sub', a, 'reac')
moose.connect(reac, 'prd', b, 'reac')
reac.Kf = 2
reac.Kb = 1

gsolve = moose.Gsolve('/compt/gsolve')
stoich = moose.Stoich('/compt/stoich')
stoich.compartment = compt
stoich.ksolve = gsolve
stoich.path = '/compt/##'

print("Reinit")
moose.reinit()
moose.start(100)
print("Done simulation")

# plots
import pylab
pylab.plot(atab.vector)
pylab.plot(btab.vector)
pylab.show()

moose compilation messages too far down in travis log

Online travis-ci log gets filled with the build/install messages for depedencies and it gives up displaying logs long before moose compilation starts. A way to redirect the non-moose build outputs and keep only the moose build output will be more useful.

Problem finding compartments in SbmlReader.cpp

Following lines in sbml/SbmlReader.cpp return EMPTY vector of ChemCompts since base_.path() is already a compartment and ChemCompts MAY NOT exist as its children.

+            string simpath = base_.path() + "/"+comptName+"/##[]";
+            wildcardFind( comptpath, compts );

Currently I am working without prefixing base_.path() to wildcard expression. One can also pop the very last expression from base_.path() before prefixing.

• Migrated from sourceforge.

Make failed for revision 6765

after svn update to revision 6765, and make clean,

make USE_SBML=1

Failed. It gave the following error:

g++ -O3 -fpermissive -fno-strict-aliasing -fPIC -Wall -Wno-long-long -pedantic -DNDEBUG -DUSE_GENESIS_PARSER -DSVN_REVISION="6765M" -DLINUX -DUSE_GSL -DUSE_SBML -DUSE_NUMPY -DUSE_HDF5 -DH5_NO_DEPRECATED_SYMBOLS -I/usr/local/hdf5/include -I. -I../basecode -I../msg DifShell.cpp -c
DifShell.cpp:13:21: fatal error: numutil.h: No such file or directory
#include "numutil.h"
^
compilation terminated.
make[1]: *** [DifShell.o] Error 1
make[1]: Leaving directory `/data/College/Summer 2015/MOOSE/june1/moose/biophysics'
make: *** [libs] Error 2

Order of assigning paramters in `moose.Reac`; needs warning in documentation

This is the recommended flow for setting reactions:

• Create moose.Reac
• Add substrates, products
• Assign reaction rates

Following is not recommended

• Create moose.Reac
• Assign reaction rates
• Add subtrate and products ( This may cause reaction rates to change ).

The problem with assigning rates before adding reactants is, as Upi mentioned,
unless substrates and products are added to reaction, volume is undefined. The
value of kf/kb depends on volume (numKf/numKb).

However, if a moose.Function is updating rate-constants then any order is
fine.

testHash function fails on 32bit architecture

The build breaks on Launchpad when function testHash is enabled in tests/python/test_pymoose.py file. Currently returning True from function testHash if architecture is 32 bit.

This function should be updated; my guess is that numbers used in this function are irrelevant on 32 bit architecture.

Test failure on Travis with clang

ctest -V fails on Travis with clang. Fortunately on one unit-tests is failing; all pymoose tests are passing.

   No CPU information available. Assuming single core.
   moose.bin: /home/travis/build/BhallaLab/moose-core/biophysics/testBiophysics.cpp:1614: void testNeuronBuildTree(): Assertion `doubleEq( val[i * nuParserNumVal + 8], maxL )' failed.

I could not reproduce the error on virtualbox with same setup. Added allow_failure for clang compiler on Travis to keep the build status of repo to build passing.

function doesn't get clock assigned if the name is not "func"

Migrated from moose . Issue BhallaLab/moose#173.

import moose

moose.Neutral('/model')
compt = moose.CubeMesh('/model/Compart')
compt.volume = 1.6667e-21

s = moose.Pool('/model/Compart/S')
s.concInit = 0.3
p = moose.Pool('/model/Compart/P')
r = moose.Reac('/model/Compart/Reac')
moose.connect(r, 'sub', s, 'reac')

moose.connect(r, 'prd', p, 'reac')

bf = moose.BufPool('/model/Compart/BufPool')
f = moose.Function('/model/Compart/BufPool/function')
moose.connect( f, 'valueOut', bf ,'setN' )

numVariables = f.numVars
f.numVars+=1
expr = ""
expr = (f.expr+'+'+'x'+str(numVariables))
expr = expr.lstrip("0 +")
expr = expr.replace(" ","")
f.expr = expr
moose.connect( s, 'nOut', f.x[numVariables], 'input' )

bf1 = moose.BufPool('/model/Compart/BufPool1')
f1 = moose.Function('/model/Compart/BufPool1/func')
moose.connect( f1, 'valueOut', bf1 ,'setN' )
numVariables = f1.numVars
expr = ""
expr = (f1.expr+'+'+'x'+str(numVariables))
expr = expr.lstrip("0 +")
expr = expr.replace(" ","")
f1.expr = expr
moose.connect( s, 'nOut', f1.x[numVariables], 'input' )

compts = moose.wildcardFind('/model/##[ISA=ChemCompt]')

print " f name= ",f.name, f.tick
print " f1 name= ",f1.name, f1.tick
for compt in compts:
ksolve = moose.Ksolve( compt.path+'/ksolve' )
stoich = moose.Stoich( compt.path+'/stoich' )
stoich.compartment = compt
stoich.ksolve = ksolve
stoich.path = compt.path+"/##"

print "After solver is set"
print " f name= ",f.name,f.tick
print " f1 name= ", f1.name, f1.tick

One can see for f1.tick is -2 as compared to f.tick is 12

Assertion error while adding a new object in multi-compartment model

multiCompt_newobjectadded.txt
Since github doesn't support uploading py renamed the file to txt.
In the file I have load PSD model multiCompartment model and tried to created a pool under compartment_2 and connected to reaction <moose.vec: class=Reac, id=511, path=/acc52[0]/compartment_2[0]/Ca_reac>, <moose.vec: class=Reac, id=499, path=/acc52[0]/compartment_2[0]/psd_activate_CaN>
Assuming if the problem persist because of dangling pool (but which is not true)
trying to set the solver we get Assertion Error.

python: ZombiePoolInterface.cpp:301: void ZombiePoolInterface::setupCrossSolverReacVols(const std::vectorstd::vector&, const std::vectorstd::vector&): Assertion `subCompts.size() == numOffSolverReacs' failed.

moose.connect on `y0`, `y1`, etc. is ordered dependant

Currently, if y1 field is connected before y0 field of a moose.Function, the output of function is not correct. To get the correct output, one has to make sure that all ys are connected in increasing order.

Let me know if a MWE is needed. Probably related to BhallaLab/moose#163

nsdf output: source dimension scale empty for uniform dataset

The NSDF file generated in moose fills the source DS for uniform data with empty string.

Segfault when accessing `e1` and `e2` field of Msg

Following snippet loads a kinekit model and prints sources and destinations of each message:

import pylab
import moose
import numpy as np

# Import all helper functions.
modelFile = './stargazin_synapse.g'
modelPathInMoose = 'model'
method = 'old_gssa'
modelId = moose.loadModel(modelFile, modelPathInMoose, method)
msgs =  moose.wildcardFind('/##[TYPE=OneToAllMsg]')

for m in msgs:
    try: print m.e1
    except: pass
    try: print m.e2
    except: pass

# This does not
for m in msgs:
    print m.e1, m.e2

Function Msg::getE1 in Msg.cpp cause seg-fault because data-member e1_ is a garbage value (sometimes NULL).

Probably Eref::data() is returning NULL

Breakpoint 1, GetOpFunc<Msg, Id>::returnOp (this=0xa9f2c0, e=...)
    at /public/dilawars/moose3.0.1/basecode/OpFunc.h:146
146             return ( reinterpret_cast< T* >( e.data() )->*func_)();
4: e = (const Eref &) @0x7fffffffd100: {
  e_ = 0xba55f0, 
  i_ = 17, 
  f_ = 0
}
3: e.data() = 0x14cc8d0 "\260?\242\365\377\177"
(gdb) 
Continuing.
<moose.vec: class=CubeMesh, id=414, path=/model[0]/kinetics>

Breakpoint 1, GetOpFunc<Msg, Id>::returnOp (this=0xa9f2c0, e=...)
    at /public/dilawars/moose3.0.1/basecode/OpFunc.h:146
146             return ( reinterpret_cast< T* >( e.data() )->*func_)();
4: e = (const Eref &) @0x7fffffffd100: {
  e_ = 0xba57f0, 
  i_ = 0, 
  f_ = 0
}
3: e.data() = 0x0
(gdb) print e
$4 = (const Eref &) @0x7fffffffd100: {
  e_ = 0xba57f0, 
  i_ = 0, 
  f_ = 0
}

NOTE: migrated from sourceforge.

SBML debian package does not work at run-time with sbml support enabled MOOSE

Installing SBML debian package does not enable SBML support in MOOSE. The package seems to have all required header and libraries. The problem may be with CMake which fails to look-up the sbml header in non-standard place.

Build failure with c++ --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.6.0 Thread model: posix

Cmake config output.

+++ CMAKE_INSTALL_PREFIX : /usr/local
-- The compiler /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ has no C++11 support.
-- Performing Test COMPILER_SUPPORTS_CXX11
-- Performing Test COMPILER_SUPPORTS_CXX11 - Success
-- Performing Test COMPILER_SUPPORTS_CXX0X
-- Performing Test COMPILER_SUPPORTS_CXX0X - Success
++ Moose will be quiet
++ Build for Relase/ No unit tests.
-- 
-- Could NOT find LIBSBML (missing:  LIBSBML_LIBRARY LIBSBML_INCLUDE_DIR) 
++ LIBSBML NOT FOUND.  Disabling SBML support.
++ DEBUG: GSL_CONFIG_PREFER_PATH: /bin
DBG GSL_CONFIG /usr/local/bin/gsl-config
-- Using GSL from /usr/local/Cellar/gsl/1.16
-- Found HDF5: HDF5HL_LIBRARY-NOTFOUNDHDF5_LIBRARY-NOTFOUND
-- Found HDF5-headers: HDF5_INCLUDE_DIR-NOTFOUND
++ HDF5 not found. Disabling support
-- Found Curses: /usr/lib/libcurses.dylib  
-- Found Readline: /usr/include  
++ Building native python extension of MOOSE
Python_ADDITIONAL_VERSIONS 2.6 2.7
-- Found PythonInterp: /usr/bin/python (found version "2.7.2") 
-- Found NumPy: version "1.6.1" /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/numpy/core/include
-- Found PythonDev: /usr/bin/python-config  
-- NOT building MOOGLI
-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   _moose

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/dilawar/Work/moose_core_dilawar/_build

Build log.

[ 49%] Building CXX object builtins/CMakeFiles/moose_builtins.dir/Function.cpp.o
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:87:15: error: use of undeclared identifier 'Function'
const Cinfo * Function::initCinfo()
              ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:305:38: error: use of undeclared identifier 'Function'
static const Cinfo * functionCinfo = Function::initCinfo();
                                     ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:307:1: error: use of undeclared identifier 'Function'
Function::Function(): _t(0.0), _valid(false), _numVar(0), _lastValue(0.0),
^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:307:11: error: C++ requires a type specifier for all declarations
Function::Function(): _t(0.0), _valid(false), _numVar(0), _lastValue(0.0),
~~~~~~~~  ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:307:21: error: only constructors take base initializers
Function::Function(): _t(0.0), _valid(false), _numVar(0), _lastValue(0.0),
                    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:311:5: error: use of undeclared identifier '_parser'
    _parser.SetVarFactory(_functionAddVar, this);
    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:311:27: error: use of undeclared identifier '_functionAddVar'
    _parser.SetVarFactory(_functionAddVar, this);
                          ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:313:5: error: use of undeclared identifier '_parser'
    _parser.DefineConst(_T("pi"), (mu::value_type)M_PI);
    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:313:25: error: use of undeclared identifier '_T'
    _parser.DefineConst(_T("pi"), (mu::value_type)M_PI);
                        ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:314:5: error: use of undeclared identifier '_parser'
    _parser.DefineConst(_T("e"), (mu::value_type)M_E);
    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:314:25: error: use of undeclared identifier '_T'
    _parser.DefineConst(_T("e"), (mu::value_type)M_E);
                        ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:315:5: error: use of undeclared identifier '_independent'
    _independent = "x0";
    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:318:9: error: use of undeclared identifier '_parser'
        _parser.SetExpr("0");
        ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:319:14: error: use of undeclared identifier 'mu'
    } catch (mu::Parser::exception_type &e) {
             ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:321:9: error: use of undeclared identifier '_clearBuffer'
        _clearBuffer();
        ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:322:9: error: non-void function 'Function' should return a value [-Wreturn-type]
        return;
        ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:324:5: error: use of undeclared identifier '_valid'
    _valid = true;
    ^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:327:1: error: expected a class or namespace
Function::Function(const Function& rhs): _numVar(rhs._numVar),
^
/Users/dilawar/Work/moose_core_dilawar/builtins/Function.cpp:327:26: error: unknown type name 'Function'
Function::Function(const Function& rhs): _numVar(rhs._numVar),
                         ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [builtins/CMakeFiles/moose_builtins.dir/Function.cpp.o] Error 1
make[1]: *** [builtins/CMakeFiles/moose_builtins.dir/all] Error 2
make: *** [all] Error 2

loading acc42 (CDK2-CyclinA_activation_pathway), acc52(EGFR_Signaling_pathway) causes segmentation fault

moose.loadModel('~/acc42.g','/a42','gsl')
segmentation fault (core dumped)

Loading any of these model (multipcompartment) with gsl, gssa cause moose to crash with
segmentation fault.

I think something to do with ZombiePool calculation in case of multi-Compartment with new solver

core dumped: with 'gssa' solver on moose.Function while reinit()

python: Stoich.cpp:570: const FuncTerm* Stoich::funcs(unsigned int) const: Assertion `funcs_[i]' failed.
7849 abort (core dumped)

import moose
n = moose.Neutral('/model')
compt = moose.CubeMesh('/model/kinetics')
p1 = moose.BufPool('/model/kinetics/Ca')
function = moose.Function('/model/kinetics/Ca/func')
gsolve = moose.Gsolve( compt.path+'/gsolve' )
stoich = moose.Stoich( compt.path+'/stoich' )
stoich.compartment = compt
stoich.ksolve = gsolve
stoich.path = compt.path+"/##"

print "pool ",p1, "pool tick ",p1.tick
print " function ",function, "function tick ",function.tick
moose.reinit()

pool <moose.ZombieBufPool: id=461, dataIndex=0, path=/model[0]/kinetics[0]/Ca[0]> pool tick -2
func <moose.Function: id=462, dataIndex=0, path=/model[0]/kinetics[0]/Ca[0]/func[0]> fun tick 12

Function object is not converted to ZombieFunction after solver is set and tick is 12 ( for both gsl and gssa) as compared to pool

"import moose" error post make

After successfully building the source, I tried to import moose from python terminal. This gave me following error.

teja@teja:~/Desktop/MOOSE/moose/python$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import moose
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "moose/__init__.py", line 29, in <module>
    from .moose import *
  File "moose/moose.py", line 43, in <module>
    from . import _moose
ImportError: moose/_moose.so: undefined symbol: BZ2_bzlibVersion

I have installed corresponding packages in ubuntu

sudo apt-get install zlib1g zlib1g-dev

Can some one point out what might be the problem.
Is there a wiki page containing list of ubuntu packages and python packages that needs to installed?

Better mechanism for handling VERSION

Currently there are two place where moose version is hard-coded: cmake file, and python setup.py file. This may cause some error some day. Move the version information to one place.

MOOGLI extension does not build with gcc-4.7.2 on Debian-7

MOOGLI fails to build on debian-7.0. Compiler gcc-4.7.2 emits an internal error. Most likely a gcc bug. Testing if this passes after some modification, else report bug on GCC.

from /home/dilawar/moose-full/moose-core/python/moogli/src/core/Compartment.cpp:1:
/usr/include/c++/4.7/bits/stl_pair.h: In instantiation of 'constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = osg::Vec3f&; _U2 = float&; <template-parameter-2-3> = void; _T1 = const osg::Vec3d&; _T2 = double]':
/home/dilawar/moose-full/moose-core/python/moogli/src/core/Compartment.cpp:24:62:   required from here
/usr/include/c++/4.7/bits/stl_pair.h:137:68: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccMTv4K9.out file, please attach this to your bugreport.

Disabling USE_CUDA gives build errors.

There are some variables and functions which are useful only when code uses CUDA for execution. Undefining USE_CUDA is not taking care of removing cuda specific code.

Remove __moose_nml.log__ when neuroml is not loaded

The log file moose_nml.log should not be created unless user/developer run the neuroml loader in debug mode. Disable it by default.

During simulation 'CTRL+C' should kill the simulation

When simulation is running, one can not kill pymoose by sending appropriate signal e.g. 'CTRL+C' in terminal. Command such as pkill python is required to kill the python process in which moose is running.

It would be a good feature if MOOSE owns the python process which it can kill as user's whim and exit.

nsdf model tree should link to map datasets.

According to NSDF specs, each dataset under /map should be linked to by the model tree node common ancestor of the mapped sources. This needs to be implemented.

Assertion error in Ksolve on Fedora-20

On Fedora-20/RHEL-7/CentOS-7 (compiled with debug support), execution of script fails with following assertion error:

[dinesh@punehpcdl02 MoosE_CorE]$ python test_ksolve.py
python: /home1/dinesh/MoosE_CorE/moose-core/ksolve/Stoich.cpp:760: void Stoich::allocateObjMap(const std::vector&): Assertion `objMap_.size() >= temp.size()' failed.
Aborted (core dumped)

type_traverse error on python2.6/CentOS-6

dilawar@nargis ~ $
python2.6
Python 2.6.6 (r266:84292, Sep 11 2012, 08:34:23) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import moose
python2.6: Objects/typeobject.c:2673: type_traverse: Assertion `type->tp_flags & (1L<<9)' failed.
Aborted

However, with python2.7, its working fine. export PYTHONPATH=/usr/lib/python2.6/site-packages

Reaction is still ZombieReac even after deletion of solver, provided its cross-compartment reaction

If a cross compartment reaction exists (i.e sub/product is from different compartment) then reaction doesn't get un-zombify after deletion of solver.
But single reaction is fine.
Small Snippet:
import moose
n = moose.Neutral('/model')

Creating two compartments

c1 = moose.CubeMesh('/model/c1')
c1.volume = 1e-21
c2 = moose.CubeMesh('/model/c2')
c2.volume = 1e-18

pools are created

sub_compt1 = moose.Pool('/model/c1/s1')
prd_compt1 = moose.Pool('/model/c1/p1')
prd_compt2 = moose.Pool('/model/c2/p2')

reaction are created, "react_S1P2" is cross compartment Reaction

react_S1P2 = moose.Reac('/model/c1/R_S1P2')
moose.connect(react_S1P2, 'sub', sub_compt1, 'reac')
moose.connect(react_S1P2, 'prd', prd_compt2, 'reac')

where as "react_S1P1", sub/prd from a simple compartment

react_S1P1 = moose.Reac('/model/c1/R_S1P1')
moose.connect(react_S1P1, 'sub', sub_compt1, 'reac')
moose.connect(react_S1P1, 'prd', prd_compt1, 'reac')

solver is set

stoich1 = moose.Stoich( '/model/c1/stoich' )
stoich2 = moose.Stoich( '/model/c2/stoich' )
ksolve1 = moose.Ksolve( '/model/c1/ksolve' )
ksolve2 = moose.Ksolve( '/model/c2/ksolve' )
stoich1.compartment = c1
stoich1.ksolve = ksolve1
stoich1.path = '/model/c1/##'
stoich2.compartment = c2
stoich2.ksolve = ksolve2
stoich2.path = '/model/c2/##'

print " After solver set--> react_S1P2 ", react_S1P2.name, " className ",react_S1P2.className
print "After solver set --> react_S1P1 ", react_S1P1.name, " className ",react_S1P1.className

Solver is deleted here

compts = moose.wildcardFind('/model/##[ISA=ChemCompt]')
for compt in compts:
if moose.exists(compt.path+'/stoich'):
st = moose.element(compt.path+'/stoich')
ks = moose.element(compt.path+'/ksolve')
st_ksolve = st.ksolve
moose.delete(st)
if moose.exists((st_ksolve).path):
moose.delete(st_ksolve)
#moose.delete(compt.path+'/stoich')
#moose.delete(compt.path+'/ksolve')

print "\n After deletion--> react_S1P2 ", react_S1P2.name, " className ",react_S1P2.className
print "After deletion--> react_S1P1 ", react_S1P1.name, " className ",react_S1P1.className

Build failing with new version of gcc on Ubuntu - 15.X

File testNSDF.cpp failing on Wily. Full log here: https://launchpadlibrarian.net/215848338/buildlog_ubuntu-wily-amd64.moose_3.0.2-6~69~ubuntu15.10.1_BUILDING.txt.gz . Relevant part is below.

Passing on Precise and Trusty.

68%] Building CXX object builtins/CMakeFiles/moose_builtins.dir/testNSDF.cpp.o
cd /«PKGBUILDDIR»/_build/_moose-core/builtins && /usr/bin/x86_64-linux-gnu-g++   -DARGS_CHECK -DQUIET_MODE -DRESULT_CHECK -DSANITY_CHECK -DUSE_GENESIS_PARSER -DUSE_GSL -DUSE_SBML -DVALUE_CHECK -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  -O3 -DNDEBUG -I/«PKGBUILDDIR»/_build/_libsbml_static/include -I/«PKGBUILDDIR»/moose-core/msg -I/«PKGBUILDDIR»/moose-core/basecode -I/«PKGBUILDDIR»/moose-core/builtins/../msg -I/«PKGBUILDDIR»/moose-core/builtins/../basecode -I/«PKGBUILDDIR»/moose-core/builtins/../external/muparser    -Wall -Wno-unused-variable -Wno-unused-function -fPIC -UDO_UNIT_TESTS -O3 -o CMakeFiles/moose_builtins.dir/testNSDF.cpp.o -c /«PKGBUILDDIR»/moose-core/builtins/testNSDF.cpp
/«PKGBUILDDIR»/moose-core/builtins/testNSDF.cpp:90:25: error: ISO C++ forbids declaration of 'testCreateStringDataset' with no type [-fpermissive]
 testCreateStringDataset()
                         ^
/«PKGBUILDDIR»/moose-core/builtins/testNSDF.cpp: In function 'int testCreateStringDataset()':
/«PKGBUILDDIR»/moose-core/builtins/testNSDF.cpp:93:1: warning: no return statement in function returning non-void [-Wreturn-type]
 }

Seg fault if ksolve is deleted before stoich

Originally created at BhallaLab/moose-gui#3 which is moved to moose-core as this is moose-core issue.

Seg fault if ksolve is removed before stoich

stoich is removed first and then ksolve, works fine

import moose
moose.loadModel('~/acc27.g','/acc27',"gsl")
compts = moose.wildcardFind('/acc27/##[ISA=ChemCompt]')
for compt in compts:
if moose.exists(compt.path+'/stoich'):
st = moose.element(compt.path+'/stoich')
st_ksolve = st.ksolve
moose.delete(st)
#print st_ksolve.path
if moose.exists((st_ksolve).path):
moose.delete(st_ksolve)

" If ksolve is removed first and then stoich then gives seg fault\n"

moose.loadModel('~/acc27.g','/acc27_1',"gsl")
compts = moose.wildcardFind('/acc27_1/##[ISA=ChemCompt]')
for compt in compts:
if moose.exists(compt.path+'/stoich'):
st = moose.element(compt.path+'/stoich')
#print " stoich ksolve ",st.ksolve.path
if moose.exists((st.ksolve).path):
moose.delete(st.ksolve)
moose.delete(st)

regards

On Ubuntu-12.04, Server Edition, 64 bit, ctest is failing but passes on 14.04.

On Travis-CI which has Ubuntu-12.04 Server Edition, 64 bit. command ctest after cmake -DDEBUG=ON .. and make fails. The log is here.

I could not recreate this situation in virtualbox 12.04. The only difference was that I did not install libSBML on Travis-CI.

`system_error` with CUDA

GSoC-2015 code for gpu branch is failing with following error with cuda-7.5/cuda-7.0.

$ cd benchmarks/Solvers/HSolve/2000ComptModel && python bigElec.py 
...
terminate called after throwing an instance of 'thrust::system::system_error'
  what():  function_attributes(): after cudaFuncGetAttributes: invalid device function
Aborted

`no module name suds.client` after `pip install suds`

I've install suds using pip yet the moosegui does not launch: (On MacOSX).

File "/opt/local/lib/moose/gui/biomodelsclient.py", line 49, in <module>
    from suds.client import Client
ImportError: No module named suds.client

This is probably related to this http://stackoverflow.com/questions/14973852/suds-install-error-no-module-named-client

Can you confirm if the real dependency should be suds-jurko rather than suds.

KSolve Issue

Need a simple script to

• Test Ksolve
• Profile Ksolve
• Debug Ksolve

Need time variable `t` support in `moose.Function`

Currently x, y and c are supported by moose.Function. It will be nice to have support for variable t e.g. function expression like sin(t) + cos(t) without the need to connect t with any moose.Clock.

missing input message when enz having same parent and substrate

moose.loadModel('~acc85.g','/acc85','gsl')
Stoich::installMMenz: No substrates for: /acc85[0]/kinetics[0]/CELLDIV[0]/CycE[0]/k8_CycE

Enzyme 'k8_CycE' has parent 'CycE' and also 'CycE' is substrate to Enzyme.
readKkit misses this message while reading. (But in genesis file the message connection exist)

enz = moose.element('/acc85[0]/kinetics[0]/CELLDIV[0]/CycE[0]/k8_CycE')
enz.neighbors['enzDest']
<moose.vec: class=ZombiePool, id=905, path=/acc85[0]/kinetics[0]/CELLDIV[0]/CycE>
enz.neighbors['subOut']
empty

segfault: while loading acc94 will gssa / with 'gsl' segfault during moose.start(10)

moose.loadModel('acc94.g','/acc94','gsl')
moose.reinit()
moose.start(1-9) #runs fine

moose.start(10)
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3e8fd4a in FuncTerm::evalPool (this=0x1581da0, S=0x159af30, t=0) at FuncTerm.cpp:140
140 args_[i] = S[reactantIndex_[i]];

But for 'gssa'
moose.loadModel('acc94.g','/acc94','gssa')
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3e8fd4a in FuncTerm::evalPool (this=0x1581da0, S=0x159af30, t=0) at FuncTerm.cpp:140
140 args_[i] = S[reactantIndex_[i]];

`mca_paffinity_linux.so:undefined symbol: mca_base_param_reg_int` with OpenMPI-1.4 on ubuntu-12.04

When OpenMPI is enabled (-DWITH_MPI=ON) in cmake, compilation and linking is fine. C++ using tests passes. Python test scripts fails with following error:

Test project /home/virtualuser/Work/moose-core/_build
    Start 1: moose.bin-raw-run
1/5 Test #1: moose.bin-raw-run ................   Passed    0.13 sec
    Start 2: pymoose-test-synchan
2/5 Test #2: pymoose-test-synchan .............***Failed    0.10 sec
/usr/bin/python: symbol lookup error: /usr/lib/openmpi/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int

    Start 3: pymoose-test-function
3/5 Test #3: pymoose-test-function ............***Failed    0.20 sec
/usr/bin/python: symbol lookup error: /usr/lib/openmpi/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int

    Start 4: pymoose-test-vec
4/5 Test #4: pymoose-test-vec .................***Failed    0.10 sec
/usr/bin/python: symbol lookup error: /usr/lib/openmpi/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int

    Start 5: pymoose-neuroml-reader-test
5/5 Test #5: pymoose-neuroml-reader-test ......***Failed    0.10 sec
/usr/bin/python: symbol lookup error: /usr/lib/openmpi/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int


20% tests passed, 4 tests failed out of 5

Total Test time (real) =   0.64 sec

The following tests FAILED:
      2 - pymoose-test-synchan (Failed)
      3 - pymoose-test-function (Failed)
      4 - pymoose-test-vec (Failed)
      5 - pymoose-neuroml-reader-test (Failed)

segfault in Rdesigneur tutorial

In the latest tunk of moose in running

python compositionTut.py

gives a segfault in
rdes.buildModel( '/model' )

a gdb trace returns

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdaa95f60 in HSolve::localIndex(Id) const () from /data/College/Summer 2015/MOOSE/june1/moose/python/moose/_moose.so

segfault: while loading acc52 with gssa, with gsl its while running

Loaded acc52 model with "gsl" solver, crashes at the time of running, but the same model crashes while loading with gssa solver itself.

moose.loadModel('acc52.g','/rec_gsl',"gsl")
moose.reinit()
moose.start(50)
FuncTerm::evalPool (this=0x15285c0, S=0x1535170, t=0) at FuncTerm.cpp:152
args_[i] = S[reactantIndex_[i]];

moose.loadModel('acc52.g','/rec_gssa',"gssa")
Same error

MOOSE script does not work

By Dinesh.

Following test-script taken from example page does not work anymore.

#!/usr/bin/env python

"""excercise.py: This is a simple excercise in moose. We just simulate a soma as
described by Subha on tutorial.

Last modified: Tue Feb 18, 2014  06:20PM

"""

__author__           = "Dilawar Singh"
__copyright__        = "Copyright 2013, NCBS Bangalore"
__credits__          = ["NCBS Bangalore", "Bhalla Lab"]
__license__          = "GPL"
__version__          = "1.0.0"
__maintainer__       = "Dilawar Singh"
__email__            = "[email protected]"
__status__           = "Development"


import moose

model = None
soma = None 
vmtab = None

def buildModel():
    global model 
    global soma
    model = moose.Neutral('/model')
    soma = moose.Compartment('/model/soma')
    return model

def stimulus():
    global soma
    global vmtab
    pulse = moose.PulseGen('/model/pulse')
    pulse.delay[0] = 50e-3
    pulse.width[0] = 100e-3
    pulse.level[0] = 1e-9
    pulse.delay[1] = 1e9
    vmtab = moose.Table('/soma_Vm')
    moose.connect(pulse, 'outputOut', soma, 'injectMsg')
    #moose.connect(vmtab, 'requestData', pulse, 'get_output')
    moose.connect(vmtab, 'requestData', soma , 'get_Vm')

def clocks():
    global soma
    global model
    moose.setClock(0, 0.025e-3)
    moose.setClock(1, 0.25e-3)
    # Don't forget to do this.
    moose.useClock(1, '/model/pulse', 'process')
    moose.useClock(1, '/soma_Vm', 'process')
    moose.useClock(0, soma.path, 'init')
    moose.useClock(0, '/##', 'process')


def main():
    global vmtab
    buildModel()
    stimulus()
    clocks()
    moose.reinit()
    t = 500e-2
    moose.start(t)
    import pylab
    t = pylab.linspace(0, t, len(vmtab.vec))
    pylab.plot(t, vmtab.vec)
    pylab.savefig('../images/soma.png')

if __name__ == '__main__':
    main()

readSBML core dumped

Orginally created by MelanieI Stefan under moose moved to moose-core

I have used moose.readSBML successfully in the past, but now I get the following error message:

*** Error in `python': free(): invalid pointer: 0x00007ffff3b8d9e8 ***
Aborted (core dumped)

Running the latest version of moose and Python 2.7.10 on Ubuntu 15.10

Also I realise that the loadSbml.py snippet has gone from the snippets folder, so maybe this means you are working on this already.

`segfault` when ksolve it used

Following MWE demonstrate the bug.

import moose
import moose.utils as mu

compt = moose.CubeMesh('/compt')
compt.volume = 1e-20

molecules = [ "ca", "S", "S1", "Sp" ]
pools = {}
tables = {}
for m in molecules:
    pools[m] = moose.Pool('/compt/%s' % m)
    t = moose.Table2("/table%s" % m)
    tables[m] = t
    moose.connect(t, 'requestOut', pools[m], 'getConc')

pools['ca'].nInit = 20

r_p0_p1 = moose.Reac('/compt/reacA')
funA = moose.Function('/compt/funA')
funA.expr = "{0}*(y0/{1})^6/(1+(y0/{1})^3)^2".format("1.5", "0.7e-3")
moose.connect(funA, 'requestOut',  pools['ca'], 'getConc')
moose.connect(funA, 'valueOut', pools['S1'], 'setConc')
moose.connect(r_p0_p1, 'sub', pools['S'], 'reac')
moose.connect(r_p0_p1, 'prd', pools['S1'], 'reac')

r_p1_up = moose.Reac('/compt/reacB')
moose.connect(r_p1_up, 'sub', pools['S1'], 'reac')
moose.connect(r_p1_up, 'prd', pools['Sp'], 'reac')

# Disabling solver executes the model accurately.
k = moose.Ksolve('/compt/ksolve')
s = moose.Stoich('/compt/stoich')
s.compartment = compt
s.ksolve = k
s.path = '/compt/##'

moose.reinit()
moose.start(10)

When solver is setup up, I get assertion error (seg-fault in this version of code).

python: /home_local/dilawars/Work/GITHUB/moose-core/ksolve/Stoich.cpp:562: const std::vector<RateTerm*>& Stoich::getRateTerms() const: Assertion `rates_[i]' failed.

I tracked it down to member rates_ which has a NULL pointer at index 0. However at index 1 there is a valid pointer. The number of rate terms in this vector is 1. Somewhere indexing and assignment are causing problem.

nsdf writer should store morphology and connectivity of neuronal models

For NSDF dump to be useful for visualization it must store the morphology (essentially x-y-z for compartments) and connectivity for synapses.

swc reader does not read custom types, loses original information

According to swc format specification (neuromorpho.org standard), structure identifier (column 2) 5 and above represent custom identifier. However, MOOSE swc reader does not read files with such identifiers.
Custom identifiers are useful for neurons which do not conform to the popular pyramidal cell morphology and when one wants to tag specific branches or regions in a reconstructed morphology.
Related to that is the problem of mapping the nodes in the original swc file to the compartment names generated by moose.

Cleaning up `python/moose` directory

There are few modules/files scatters in python/moose which needs to be cleaned-up. Few of them I added long time back. I am removing them from this repository. May be they can be put back in contrib folder or something similar. Right now the focus is to cleanup the tree.

• backend; builds a graph from moose-internal messages. Dilawar, Planned to be deleted. Removed.
• topology; process the graph generated by backend. Dilawar. Planned to be deleted Removed.
• kkit . @subhacom @hrani
• neuroml, In working condition. Often used. May be some documentation is needed.
• print_utils.py, verification_utils.py, and sim_utils.py. Dilawar. I need to document them. They have some useful functions which I often use: e.g. for saving moose.Tables to csv file and plotting them. Need better documentation.
• neuroml2. @subhacom It can still read morphology-only files. Ion channel and concentration needs updating. Waiting for upstream neuroml2 schema to stabilize.
• genesis. @hrani .

In addition to these, in python directory, I worked on libmumbl. Disable its packaging till its ready. Retain it for development.

Missing module `numpydoc` when generating documentation

The script docgen uses doxygen and python-sphinx to generate moose-document. Currently build fails with error that module numpydoc is not found.

This module is not a not part of python-sphinx package on various (perhaps all) distribution. Also rpm packages are not available for this. This causes build failure of moose-doc package on many RPM based distributions; even on Ubuntu.

Currently moose-doc is an empty package till a easier solution to build doc is found.

• Configure doc build in a way that it does not uses numpydoc (and any module which is hard to find as a package on all Linux distros).
• Build doc offline (on development machine) and distribute them along with source i.e. no need to build document when build packages. This will also reduce the dependency list on build time

I prefer the first solution since python-sphinx is available in most of the Linux platform I am building for.

SBML Rules lost

Attached sbml model loads successfully using readSBML, but all Rules and the related variables seem to be lost. These rules do not seem to be in the model tree and are not saved if the model is writen out to an xml file using writeSBML.

addChannelMessage(Id chan) cannot be overloaded

> git clone https://github.com/BhallaLab/moose.git
> cd moose
> mkdir _build
> cd _build
> cmake ..
> make

[ 23%] Building CXX object biophysics/CMakeFiles/biophysics.dir/Neuron.cpp.o
cd /home/teja/Desktop/MOOSE/moose/_build/biophysics && /usr/bin/c++ -DARGS_CHECK -DQUIET_MODE -DRESULT_CHECK -DSANITY_CHECK -DUSE_GENESIS_PARSER -DUSE_GSL -DUSE_SBML -DVALUE_CHECK -std=c++11 -O3 -DNDEBUG -I/usr/local/include -I/home/teja/Desktop/MOOSE/moose/msg -I/home/teja/Desktop/MOOSE/moose/basecode -I/home/teja/Desktop/MOOSE/moose/biophysics/../basecode -I/home/teja/Desktop/MOOSE/moose/biophysics/../synapse -I/home/teja/Desktop/MOOSE/moose/biophysics/../utility -Wall -Wno-unused-variable -Wno-unused-function -fPIC -UDO_UNIT_TESTS -O2 -DCYMOOSE -DCYTHON -o CMakeFiles/biophysics.dir/Neuron.cpp.o -c /home/teja/Desktop/MOOSE/moose/biophysics/Neuron.cpp
In file included from /home/teja/Desktop/MOOSE/moose/biophysics/Neuron.cpp:13:0:
/home/teja/Desktop/MOOSE/moose/biophysics/ReadCell.h:99:8: error: ‘void ReadCell::addChannelMessage(Id)’ cannot be overloaded
void addChannelMessage( Id chan );
^
/home/teja/Desktop/MOOSE/moose/biophysics/ReadCell.h:35:15: error: with ‘static void ReadCell::addChannelMessage(Id)’
static void addChannelMessage( Id chan );
^
make[2]: *** [biophysics/CMakeFiles/biophysics.dir/Neuron.cpp.o] Error 1
make[2]: Leaving directory /home/teja/Desktop/MOOSE/moose/_build' make[1]: *** [biophysics/CMakeFiles/biophysics.dir/all] Error 2 make[1]: Leaving directory/home/teja/Desktop/MOOSE/moose/_build'
make: *** [all] Error 2

Source of the problem is In ReadCell.h same method is declared twice, once as static and normal.

• static void addChannelMessage( Id chan );
• void addChannelMessage( Id chan );

`moose.Function` does/can not update `conc` of `moose.Pool`

Currently, a function can not update conc field of moose.Pool. One has to write expression such that setN produce the correct result.

I understand that setConc is discouraged because it causes volume scaling effects.

Class get functions dont work

example where
model_elec=moose.element(rdes.model.path+"/elec")

In [25]: model_elec.getPathDistanceFromSoma()

TypeError Traceback (most recent call last)
in ()
----> 1 model_elec.getPathDistanceFromSoma()

TypeError: moose.setDestField: Arguments not handled: getPathDistanceFromSoma(PSt6vectorIS_IdSaIdEESaIS1_EE,)

Many such functions are not working.

HDF5 headers are moved to /usr/include/hdf5/serial on Ubuntu-15.10

The location of headers of hdf5 are moved to non-standard location. This will break the cmake build on Ubuntu-15.10 (debian jessie and higher) and higher.

https://packages.debian.org/jessie/amd64/libhdf5-dev/filelist