TypeError from vode: Excess work done on this call

[Maurizio De Pitta']

Dear all,
Sometimes in the trajectory computation some other times in the continuation of trajectories the following error message pops up:

 TypeError  Traceback (most recent call last)
 <ipython-input-14-125733ca85f2> in <module>()
 21 DS.gammas_dot = gammas_dot
 22 
 >23 traj = DS.compute('start_pts')
 24 pts  = traj.sample()
 25

 /usr/local/pydstool/PyDSTool/Generator/Vode_ODEsystem.py in compute(self, trajname, dirn, ics)
838             except TypeError:
839                 # e.g. when errcode has been used to return info list
>840                 print("Error information: %d" % errcode)
841                 self.diagnostics.errors.append((E_COMPUTFAIL, (solver.t,
842                                     self.diagnostics._errorcodes[0])))

TypeError: %d format: a number is required, not numpy.ndarray

vode:Excess work done on this call. (Perhaps wrong MF.)

I understand that the issue is within the VODE integrator, but I cannot figure out exactly what conditions on my solution or on my algparams settings it could be caused by. So if you could just clarify my when this error in general comes out I will appreciate it.

Thanks in advance for your time.

Cheers,

M

[Vladimir Zakharov]

Looking at traceback only: string formatting inside 'print' call expects number, but receives numpy.ndarray. As a result we have unhandled TypeError exception on line 840 (inside another TypeError handler), which propagates to user. And this issue should be addressed somehow (change string formatting?)

[Vladimir Zakharov]

After a bit of analysis, added new issue.

[Rob Clewley]

Your parameters are most likely passing through a region where the dynamics are stiff. VODE can be set to "stiff" mode in the algparams settings, which might help. If you're doing this as part of continuation, PyDSTool doesn't know how to automatically adjust any numerical parameters on-the-fly during a series of integrations. Also, using Radau would probably help.

If you really want to understand it, you can try to compute the time scales of the system as a function of parameters that are changing, and observe where they separate most strongly.

[Maurizio De Pitta']

Hi Rob,
thanks for the insight.

Trying to figure out the parametric time scales is going to be quite a daunting task on this system... but indeed there are multiple time scales. Rather it looks like so far I am coping with some issues in my implementation of the ODE.

On a side note, I tried the Radau on the newly installed PyDSTool through

python setup.py develop

on last updated Numpy and Swig and it fails with:

radau5_temp/radau5_<my_model>.py no such file or directory
error: swig exit flag 1

This is a plain python installation on a Fedora 20 machine.

What could that be?

M

[Rob Clewley]

Not sure -- there's a bunch more info we'd need. Could you please start a new thread with an appropriate title about this so that my colleagues can also notice it? You'll have to tell us what your versions for python, PyDSTool, numpy, swig, and whether this is a 64 bit installation. After that, please post the more verbose output from this or a simple radau test in the tests/ dir by listing the contents of the build.log file, which should be inside radau5_temp. Thanks.