Conversation
|
Cool, thanks for adding. The new integrators are written in Python so they will be slow. After reading a bit about them, I'm not sure that was a great move on SciPy's part. I like the new unified interface, but why choose not to rely on battle hardened numerical codes doesn't make much sense. I think I should rename If you want to install SciPy 1.0 via pip wheels on the server we can, but I'd prefer to try to stick with conda based stuff on defaults or the forge. I like the idea of a check in the setter for |
| - sphinx | ||
| - numpy | ||
| - scipy | ||
| - scipy>=1.0 |
There was a problem hiding this comment.
setup.py also needs this designation
| res = self._array_rhs_eval_func(times, int_res) | ||
|
|
||
| return int_res[:, 0], int_res[:, 1], res[1, :] | ||
| return int_res[0], int_res[1], res[1, :] |
There was a problem hiding this comment.
Interesting. I'm not sure it was a good idea to swith x,t in the input and spit out the transpose wrt to odeint. There is so much code in the wild that uses the other pattern.
| t_eval=times, | ||
| method=integrator, | ||
| vectorized=True, | ||
| **kwargs) |
There was a problem hiding this comment.
I'm not sure I want to switch to just using this new method. I like the idea of having the design able to support any kind of integrators (e.g. sundials, scipy variety, scikit odes, etc). The previous design was setup so you write a single method for any new integrator that you may want to add.
| return sp.integrate.solve_ivp(self._array_rhs_eval_func, | ||
| (times[0], times[-1]), | ||
| initial_conditions, | ||
| t_eval=times, |
There was a problem hiding this comment.
Not sure this was a good API decision either, why do yo uhave to pass in t0, tf, and t (an array)?
Initial working implementation in place. Some notes:
CoulombPendulumSystemif you integrate out beyond the sticking point for much time. The fixed time step Runge-Kutta solver we're using currently is nice there though it has accuracy issues. Could just bring that back I suppose.ValueErrorif you try to set it to something not available.ode_funcis intended to always be vectorized, but I'm guessing some fun traceback will result if it's not. Should probably handle that by passing in dummy values when it's set.Fixes #102