| 205 | === 2. Boost.odeint Implicit Routines === |
| 206 | Potential mentors: Karsten Ahnert and Mario Mulansky |
| 207 | |
| 208 | ==== Background ==== |
| 209 | Boost.odeint http://www.odeint.com is a library devoted to finding numerical solutions of ordinary differential equations (ODEs). It is developed in a generic way using Template Metaprogramming which leads to extraordinary high flexibility at top performance. It is widely used in academic and industrial projects. Boost.odeint has been a Google Summer of Code project in 2011 http://google-melange.appspot.com/gsoc/project/google/gsoc2011/mulansky/14001 and we would like again to see students involved in the development of this numerical library. |
| 210 | |
| 211 | The current focus of odeint is on '''explicit''' routines, namely the Runge-Kutta schemes or the multi-step methods. However, we would like to expand odeint by adding implicit routines in the same flexible manner. Implicit routines are important when dealing with stiff systems, but also ensure stability in some cases of discretized partial differential equations (PDEs). At the moment, odeint provides an implicit Euler and Rosenbrock algorithm, but the implementation is restricted to Boost.uBlas. As one of the main objectives of odeint is to provide highly flexible algorithms, we want to change this implementation to have a greater flexibility and interchangeability similar to that of the explicit routines. This project would not only require pure coding, but first also a considerable amount of design work. |
| 212 | |
| 213 | * [http://en.wikipedia.org/wiki/Numerical_methods_for_ordinary_differential_equations] |
| 214 | * [http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods] |
| 215 | * [http://en.wikipedia.org/wiki/Explicit_and_implicit_methods] |
| 216 | |
| 217 | ==== GSoC project proposal ==== |
| 218 | This project does not only require profound knowledge on C++ and generic programming, but we would also like to see some experience on numerical algorithms and solving ODEs, if possible. |
| 219 | |
| 220 | * Develop a design on how the requirements on implicit routines can be modularized |
| 221 | * Implement a prototype showing the usability of the design |
| 222 | * Change the existing routines to the new design |
| 223 | * Implement other backends (MTL, eigen,...) to demonstrate the flexibility |
| 224 | * Provide examples and documentation |
| 225 | * (Add more implicit routines, if time permits) |
| 226 | |
| 227 | |