I installed both numpy/scipy and PyDSTool today via pip on a fresh Ubuntu 16.04 install. When I run one of my older scripts I got the following error (only the PyDSTool related part):
/home/XXX/.local/lib/python2.7/site-packages/PyDSTool/Toolbox/phaseplane.pyc in find_fixedpoints(gen, subdomain, n, maxsearch, eps, t, jac)
1348 return Point(dict(zip(x0_names,a)))
1349 for dummy_ix in range(n**D):
-> 1350 x0 = array([x0_coords[i][d_posns[i]] for i in range(D)])
1351 # TEST
1352 #sol = root(Rhs_wrap, x0, (t,gen.pars), method='hybr',
IndexError: only integers, slices (:), ellipsis (...), numpy.newaxis (None) and integer or boolean arrays are valid indices
So I think it is related that newer versions of numpy strictly forbid floats as array indices. Anyways, I dived into phaseplane.py and found that the 'd_posns' where indeed floats. My fix is the following: I appended a 'dtype = int' to all np.zeros assignments in the 'base_n_counter' class. With this all the d_posms entries are ints and everything runs as expected!
Cheers,
Gregor
PS: Btw I still have the feeling that the new 'Vode_ODEsystem.py' is much slower when it comes to fixed point calculations as compared to older PyDSTool versions. If I have time I will provide more tests.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the note. Looks like you fixed it properly. I'll roll it in to the repo. As for the use of Vode, I found an unpleasant inefficiency recently that was introduced between the two versions. I am not sure what the ultimate solution to this should be, but I do have at least a temp fix. If you replace your
PyDSTool/parseUtils.py with the one attached, you should find significant improvement. My edits are around line 900. It probably still won't be as fast as the old one, and I have some thoughts about that but can't act on them right now. There are some checks and balances that happen by default on the names of params and variables passed around internally that create overhead. I didn't used to have those checks, so in some use cases there could be some nasty bugs. The compromise might be to better optimize how those checks happen.
The quick changes here are not ideal for all possible cases, but should be fine for people not doing really bizarre things with their model objects. For any conventional usage, things should be fine. But
let me know how it works for you.
thx for the quick answer, I am happy you accepted the solution!
And indeed, with your parseUtils.py I got a speedup of around 5 times. I also tried the other Integrators (Dopri and Radau), and they both also got much faster with the fixed point calculations. These actually take much longer than the actual integration of the system.
Cheers,
Greg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I installed both numpy/scipy and PyDSTool today via pip on a fresh Ubuntu 16.04 install. When I run one of my older scripts I got the following error (only the PyDSTool related part):
/home/XXX/.local/lib/python2.7/site-packages/PyDSTool/Toolbox/phaseplane.pyc in find_fixedpoints(gen, subdomain, n, maxsearch, eps, t, jac)
1348 return Point(dict(zip(x0_names,a)))
1349 for dummy_ix in range(n**D):
-> 1350 x0 = array([x0_coords[i][d_posns[i]] for i in range(D)])
1351 # TEST
1352 #sol = root(Rhs_wrap, x0, (t,gen.pars), method='hybr',
IndexError: only integers, slices (
:), ellipsis (...), numpy.newaxis (None) and integer or boolean arrays are valid indicesSo I think it is related that newer versions of numpy strictly forbid floats as array indices. Anyways, I dived into phaseplane.py and found that the 'd_posns' where indeed floats. My fix is the following: I appended a 'dtype = int' to all np.zeros assignments in the 'base_n_counter' class. With this all the d_posms entries are ints and everything runs as expected!
Cheers,
Gregor
PS: Btw I still have the feeling that the new 'Vode_ODEsystem.py' is much slower when it comes to fixed point calculations as compared to older PyDSTool versions. If I have time I will provide more tests.
Thank you for the note. Looks like you fixed it properly. I'll roll it in to the repo. As for the use of Vode, I found an unpleasant inefficiency recently that was introduced between the two versions. I am not sure what the ultimate solution to this should be, but I do have at least a temp fix. If you replace your
PyDSTool/parseUtils.py with the one attached, you should find significant improvement. My edits are around line 900. It probably still won't be as fast as the old one, and I have some thoughts about that but can't act on them right now. There are some checks and balances that happen by default on the names of params and variables passed around internally that create overhead. I didn't used to have those checks, so in some use cases there could be some nasty bugs. The compromise might be to better optimize how those checks happen.
The quick changes here are not ideal for all possible cases, but should be fine for people not doing really bizarre things with their model objects. For any conventional usage, things should be fine. But
let me know how it works for you.
Hi Rob,
thx for the quick answer, I am happy you accepted the solution!
And indeed, with your parseUtils.py I got a speedup of around 5 times. I also tried the other Integrators (Dopri and Radau), and they both also got much faster with the fixed point calculations. These actually take much longer than the actual integration of the system.
Cheers,
Greg