Small bug in ModelSpec_test using VODE?

Help
Anonymous
2012-01-03
2013-11-04
  • Anonymous - 2012-01-03

    I've just installed PyDSTool on my Windows XP computer and am trying to get the tests to run, but I'm running into a problem with ModelSpec_test.py that seems to be because I just want to use the standard NumPy VODE integrator. The error is:

    ModelSpec and neural computation toolbox tests...
    Error occurred in generating Dopri system...
    <type 'exceptions.SystemExit'> error: command 'swig.exe' failed: No such file or directory
    Problem initializing target Generator 'Dopri_ODEsystem'
    Traceback (most recent call last):
      File "ModelSpec_test.py", line 210, in <module>
        HHmodel_net = modelC_net.getModel()
      File "c:\PyDSTool\ModelConstructor.py", line 1148, in getModel
        = self.createGenerators()
      File "c:\PyDSTool\ModelConstructor.py", line 1033, in createGenerators
        gen = self._genFromMSpec(GDescriptor(**geninfo))
      File "c:\PyDSTool\ModelConstructor.py", line 1139, in _genFromMSpec
        return genCon.getGenerator()
      File "c:\PyDSTool\ModelConstructor.py", line 557, in getGenerator
        return gsh.genClass(a)
      File "c:\PyDSTool\Generator\Dopri_ODEsystem.py", line 422, in __init__
        self.compileLib()
      File "c:\PyDSTool\Generator\Dopri_ODEsystem.py", line 796, in compileLib
        raise RuntimeError
    RuntimeError
    

    Looking at ModelSpec_test.py I find this:

    targetGen = 'Dopri_ODEsystem'
    # -------------------------------------------------------------------------
    if targetGen == 'Vode_ODEsystem':
        targetlang='python'
    else:
        targetlang='c'
    

    Changing the first line of this to targetGen = 'Vode_ODEsystem' fixes the tests for me, but obviously this is not right for anyone who wants to use an external integrator.

     
  • Anonymous - 2012-01-03

    Another problem I think, this time with pest_test3.py. In version 0.88.111221, the name of the current parameter in HH_Model.py is IApp, whereas in version 0.87 it was just I. In pest_test2.py the call to makeHHneuron has been updated to reflect this:

    par_args_HH = {'gna': 100, 'gk': 80, 'gl': 0.1,
                'vna': 50, 'vk': -100, 'vl': -67,
                'Iapp': 1.35, 'C': 1.0}
    # deliberately set Iapp not quite 1.3, as used for IF neuron
    ic_args_HH = {'v':-70.0, 'm': 0, 'h': 1, 'n': 0}
    HH = HH_model.makeHHneuron('goalHH', par_args_HH, ic_args_HH)
    

    This doesn't seem to have been done for pest_test3.py, however:

    par_args_HH_goal = {'gna': 100, 'gk': 80, 'gl': 0.1,
                'vna': 50, 'vk': -100, 'vl': -67,
                'I': 1.3, 'C': 1.0}
    ic_args_HH = {'v':-68, 'm': 0, 'h': 1, 'n': 0}
    HH_goal = HH_model.makeHHneuron('goalHH', par_args_HH_goal, ic_args_HH,
                extra_terms='-0.04*(sin(9.1*t)*cos(2.6*t)+sin(5.1119*t+2))*(v-60)')
    

    It looks like an easy fix to me, but I'm a complete beginner when it comes to NumPy/SciPy/PyDSTool so correct me if there's something more complicated going on!

     
  • Anonymous - 2012-01-03

    For reference, the error I get is:

    Error in specification `v` with token `Iapp` :
    (Iapp-0.04*(sin(9.1*t)*cos(2.6*t)+sin(5.1119*t+2))*(v-60)-ionic(v,m,h,n))/C
    Traceback (most recent call last):
      File "pest_test3.py", line 26, in <module>
        extra_terms='-0.04*(sin(9.1*t)*cos(2.6*t)+sin(5.1119*t+2))*(v-60)')
      File "C:\PyDSTool\tests\HH_model.py", line 52, in makeHHneuron
        return Generator.Vode_ODEsystem(DSargs)
      File "c:\PyDSTool\Generator\Vode_ODEsystem.py", line 41, in __init__
        ODEsystem.__init__(self, kw)
      File "c:\PyDSTool\Generator\ODEsystem.py", line 51, in __init__
        kw))
      File "c:\PyDSTool\FuncSpec.py", line 2221, in __init__
        FuncSpec.__init__(self, kw)
      File "c:\PyDSTool\FuncSpec.py", line 314, in __init__
        self.generateSpec()
      File "c:\PyDSTool\FuncSpec.py", line 472, in generateSpec
        self._genSpecPy()
      File "c:\PyDSTool\FuncSpec.py", line 993, in _genSpecPy
        temp = self._specStrParse(specname_vars, self.varspecs, 'xnew')
      File "c:\PyDSTool\FuncSpec.py", line 1172, in _specStrParse
        doing_inserts)
      File "c:\PyDSTool\FuncSpec.py", line 1218, in __processTokens
        ' spec string `'+specname+'`')
    ValueError: Undeclared or illegal token `Iapp` in spec string `v`
    
     
  • Rob Clewley

    Rob Clewley - 2012-01-03

    Thanks, I don't know how these were missed when finalizing the release. Your fixes are correct, and it's fixed in the BZR repository. Will be fixed in the next release too.

     
  • Anonymous - 2012-01-11

    No problem, glad to be of use. I'm still trying to get all of the tests to pass; this time the problem is with symbolic_diff_test.py. I'm guessing that the problem is my fault because I'm ignoring the advice in the installation manual and using the latest versions of numpy and scipy (1.6.1 and 0.10.0 respectively). The (possibly misguided) hope is that I'll be able to fix any incompatibilities that crop up as I go along.

    This is the error I get:

    Symbolic vector tests
    [q0,q1]
    [(p0+3),(3*Pow(p0,2)*Cos(Pow(p0,3)+q0))]
    [[-3*6*Pow((2*v+1),2)+2,2],[0,-0.5]]
    [[ -8.80000000e+02   2.00000000e+00]
     [  0.00000000e+00  -5.00000000e-01]]
    Traceback (most recent call last):
      File "symbolic_diff_test.py", line 189, in <module>
        assert str(Diff(F,[y0,y1,y2])) == '[[-0.04,10000*y2,10000*y1],[0.040000000000000001,(-10000*y2)-30000000*2*y1,-10000*y1],[0,30000000*2*y1,0]]'
    AssertionError
    

    Debugging indicates that str(Diff(F,)) = "[,,]" (notice the expected 0.040000000000000001 is 0.04). I've noticed that a similar error in Symbolic_Test.py was fixed in a patch by using assert_approx_equal on the numbers, rather than doing a string comparison. Is this also a valid fix here, or is the precision important? Is my attempt get PyDSTool to work with the latest NumPy/SciPy going to turn out to be much more difficult that anticipated?

     
  • Rob Clewley

    Rob Clewley - 2012-01-11

    I can update that test script to use assert_approx_equal too. There is no difference in precision there, it's an inherent representation error and is probably being cleaned up differently by a function preparing the strings.

    I don't foresee many problems in getting it to work with the latest numpy and scipy. Not that many things change from version to version, and we can keep abreast of these little things.

    Thanks.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks