In MATLAB, the suite of numerical solvers for systems of ordinary differential equations are functions that accept variables, including other functions. Since I learned to program MATLAB for my numerical solutions, I am accustomed to this system of passing a function of equations and variables to the ODE solver function. While there is something gratifying in my mind about the distinct separation and, in theory, plug-and-play ease of this system, I cannot help but think that it’s computationally more efficient to have the ODE solver integrated into the numerical application. When people say that they write their own ODE solvers, I always assumed that they meant an ODE solver that accepted a function file of equations and iterated over them, in much the same way as MATLAB. However, it’s finally becoming clear to me that this is not the case, and by ODE solvers, most mean that they are simply hard-coding a numerical algorithm or scheme for iterating their equations. The difference is subtle and may boil down to a difference in computational versus mathematical approaches. In my current project, I am interested in interacting rhythms in biophysical models of neural systems, which requires me to solve large systems of ODEs numerically.
While I make the transition from MATLAB to GNU Octave/R, I’m learning about what implementations are reasonable to translate and what new things I need to learn. Of course, I am interested in maximizing efficiency in the shift, but I have to be careful not to do so at the expense of lost computational efficiency, which happened in my first attempt at using ‘lsode’ as a drop-in solver replacement for a complicated system of ODEs. Since I have decided to ditch graphics in MATLAB in lieu of another system that has fewer four letter words associated with it, the ODE solver was my last true obstacle in the translation from MATLAB to Octave. Now that I am going to solve that problem by “writing my own” scheme, I am that much closer to being completely free and open source in my science.