Fwd: Regarding GSoc'14 Boost.odeint idea
Sir/Mam, I, Rishav Agarwal, am a sophomore studing at the Indian Institute of Technology, Kanpur, India. I am interested in the working on implementing implicit routine for solving ODEs. I have done a semeser long on Numerical Methods in my third semester and am quite familiar with the algorithms used. Although I do not have much experience working with the Boost library, I am well aquaited with C++ and Python and can pick up the libraries easily. I would appreciate if the probable mentor could guide me through the application process and tell me about any pre-requisite/tests that I need to clear which could strengthen my proposal. A list of my previous projects can be found here http://github.com/rra94. Sincerely, Rishav Raj Agarwal I.I.T.Kanpur
Hi Rishav, On 10.03.2014 13:19, Rishav Agrawal wrote:
Sir/Mam,
I, Rishav Agarwal, am a sophomore studing at the Indian Institute of Technology, Kanpur, India. I am interested in the working on implementing implicit routine for solving ODEs. I have done a semeser long on Numerical Methods in my third semester and am quite familiar with the algorithms used. Although I do not have much experience working with the Boost library, I am well aquaited with C++ and Python and can pick up the libraries easily.
I would appreciate if the probable mentor could guide me through the application process and tell me about any pre-requisite/tests that I need to clear which could strengthen my proposal.
Last year we had a small test about the coding skills and the odeint library. We will use this test this year again. I will sent it with a separate private mail. Implicit routines require to solve linear systems. I think, the main difficulty is to integrate these linear solvers into odeint such that they are exchangeable like the existing algebras and operations. This would be a good foundation to implement implicit routines and I would be happy if the BDF method could be implemented. Of course there are some other easier methods (implicit Euler) which could be implemented first. Prerequisites are a solid knowledge of the C++ template systems and a basic knowledge of the implicit algorithms.
A list of my previous projects can be found here http://github.com/rra94.
Sincerely, Rishav Raj Agarwal I.I.T.Kanpur
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Karsten, BDF implicit routine is of prime importance when it comes to stiff systems, but are we expected to test its flexibility on other systems as well? Or is it that other implicit methods shall be implemented for other system. Eg. Implicit Euler method or maybe the Adams-Moulton method ? -- Cheers, Pulkit Mendiratta
BDF implicit routine is of prime importance when it comes to stiff systems, but are we expected to test its flexibility on other systems as well? Or is it that other implicit methods shall be implemented for other system. Eg. Implicit Euler method or maybe the Adams-Moulton method ?
One main use case for implicit methods in general are stiff systems. Therefore, I think one should focus on stiff systems. Of course, it is easy to test it with non-stiff ODEs. An implicit Euler method already exist. But it is limited to Boost.ublas for the state and matrix type at the moment. One goals is to allow for arbitrary state types and the Implicit Euler is surely the most simple method to test if the state type can simply be exchanged.
On Mon, Mar 10, 2014 at 3:40 PM, Karsten Ahnert
Implicit routines require to solve linear systems. I think, the main difficulty is to integrate these linear solvers into odeint such that they are exchangeable like the existing algebras and operations. This would be a good foundation to implement implicit routines and I would be happy if the BDF method could be implemented.
To briefly hijack a thread, SDIRK might be a good use case for API design. - Rhys
I think they could also be generalized to generic SDIRK implementation, parametrized only by its coefficients.
One challenging thing would be getting the caching correct to permit reuse of operator factorizations across substeps. If SDIRK drives the API design, a BDF-ready API should fall out but not necessarily vice versa. -Rhys
On 10.03.2014 22:18, Rhys Ulerich wrote:
I think they could also be generalized to generic SDIRK implementation, parametrized only by its coefficients.
One challenging thing would be getting the caching correct to permit reuse of operator factorizations across substeps. If SDIRK drives the API design, a BDF-ready API should fall out but not necessarily vice versa.
We already have a generic implementation of arbitrary RK schemes, based on template meta programming. Maybe similar techniques from this implemetation can be apply for SDIRK. Sounds really interesting to me.
participants (4)
-
Karsten Ahnert -
Pulkit Mendiratta -
Rhys Ulerich -
Rishav Agrawal