GSOC 2014

[fsaporito]

Hi,

I am Francesco Saporito, and I was intested in applying for the ODE Solver project. I have been poking around the code and reading the Julia manual, and I am getting toghether some ideas for the project.
I wanted to know what the community had in mind regarding the ODE Solver and what the GSOC student it's expected to do to the project. In the project idea it was hinted that a major rewrite of the code was involved, but I wanted to know what you believe that has to be done for the solver.

Thank you for the suggestions.

Saporito Francesco

[acroy]

Glad to hear that you are interested in ODE.jl! As you have probably seen we are currently trying to revise the package to some extent and would be most happy to get some help. I don't know if there is already a definite GSOC ODE project, but I am sure we can come up with something that suits your interests.

I hope that the others will join the discussion with suggestions, but some potential topics that come to my mind would be

• Implementation of an adaptive solver for stiff ODEs. Such methods typically need the Jacobian matrix of the right-hand side and it might be interesting to see if/how one could make use of DualNumbers.jl, which provides a different approach to numerical differentiation than finite differences with some epsilon.
• "ODE solver facility". In WIP: Api changes #7 @tlycken suggested to introduce some kind of "solver object", which allows you to specify the problem independently of the method.
• Test & performance suite for ODE solvers. @tlycken started some work in WIP: Test framework #3, which (I believe) is based on DETEST. In general it would be nice to have a proper test suite for our solvers, which allows it to check correctness, but also gives some performance benchmarks.

But you mentioned that you already have some ideas?

[fsaporito]

Thank you for the reply.
The project is among the ones on the julia's website list (http://julialang.org/gsoc/2014/).
The description says:

"Project: Native Julia solvers for ordinary differential equations

Julia should have a full set of ODE solvers, as they are vital for numeric programming. This project should build on the work of ODE.jl. The best way forward will probably be to implement the solvers in Julia. See #75.

Expected Results: A set of production-quality ODE solvers."

This is what I have thought so far:

I would start by implementing some basic ODE solvers, like implicit and explicit Euler, Crank-Nicolson and Heun. This is actually more useful for myself than to the library, because it's lets me enter in the julia's development frame of mind and can be used to assert that I am suitable for the project. (This will come before the actual project and before the GSOC, let's call it a warm up :) ).

The first thing to do in my opinion is to improve the test suite and the documentation, to allow a much smoother development of the library.

The library should then expand by implementing some other methods, with maybe some redundance in problem solving (different methods can solve the same thing) but with the possibility for the user to chose from a group of solvers.
Maybe we can even create a comparison between the methods for the specific problem posed by the user, so that it's possible to see which method is better for the task (where better can be intended as speed, precision, etc).

For the new methods to be implemented, I don't know much on the subject yet, but I think that maybe finite volume and finite element can be added.

What do you think?

[tomasaschan]

Fun! ODE.jl could really benefit from growing its number of active developers, so it's nice to see that there is interest! =)

As you'll see if you read through the open issues, much of the current discussion is around API design and basic functionality. Many good ideas have been raised, but at least some of them might require a fair amount of work to actually be implemented - however, I don't know if maybe work on many of those things will already be started by the time GSoC starts. A good way for you to familiarize yourself with Julia and with ODE.jl would be to get involved in the discussion ;)

@acroy's suggestions for topics are great - in particular, the library is really in need for some rigorous testing, both for accuracy and performance, so if I got to pick, that would be my first priority for a GSoC project. However, there are some other things we could definitely use as well:

• Even without the dual numbers approach for differentiation, stiff solvers are really a requirement for this package to be "feature-complete". The usual way of handling them is to have the user provide an analytical jacobian of the system as an extra function argument, i.e. instead of ode(f, tspan, y0), one has to call odes(f, tspan, y0, J).
• Some of the current implementations are taken from places where it's a little unclear what licensing requirements are. Therefore, a pure white-paper implementation of e.g. a general RK method (similar to oderkf in its current form) would be a welcome addition. This is perhaps a too small a project for GSoC (I don't know) but it for example be combined with stiff solvers above.
• Documentation is also needed, but since the API is changing a lot right now, maybe we should make all the decisions before we document them ;)
• All Runge-Kutta methods are finite-difference based - it might be nice to add some finite volume or finite element methods as well.
• We currently lack BVP solvers completely.

Edit: now I saw that you've posted another comment. Yes, your ideas sound good - as I said above, a good test suite would really add a lot of value to the package. If you'd like to work on that, that'd be really great! As for warm-up, why don't you start going through the issues and submit pull requests already now? ;)

[jiahao]

If you can show us reasonable implementations of explicit and implicit Euler in your GSoC application, that would go a very long way toward convincing us that we should have you on board.

cc: @StefanKarpinski

[fsaporito]

@tlycken I thought of implementing something related to the project by starting from the basic level, to allow a sort of educational pathway in the project course and to start getting the hang of things. Starting with actual issues, would mean a more step learning curve with the julia language and a more difficult project start in my opinion.

[acroy]

@sapo93 Then @jiahao's suggestion sounds like the perfect starting point!

[fsaporito]

Give me a couple of days to sort out the material and I'll start working with Euler :)

[jiahao]

@sapo93 we look forward to your application.

[stevengj]

I want to second @tlycken's call for testing, and let me expand on that by saying that we really need rigorous testing and comparison of our solvers to competing solvers (in Matlab, Mathematica, Sundials, etcetera).

Without rigorous comparisons (on a variety of test cases exhibiting different characteristics, including both "easy" and "hard" cases), it is difficult to know whether our ODE solvers are any good.

[mauro3]

I just commented over in issue #20 that PETSc has nice ODE/DAE solver setup (EDIT: now the separate issue #30). Both from an API point of view and from what solvers it contains. Also it has a liberal licence, so code could probably be directly based off that.

[fsaporito]

I looked over chapter six of the manual and the General linear methods explanation posted in #30 . It seams to me a worthwhile idea for the GSOC project.
If the community feels that this is the right track for the library, I will apply for implementing this and for adding a test suite (which I usually do as I code, only this time it wouldn't be a use and trash test suite)
.
P.s. In the admission draft, its suggested to list some people that the student feels should be mentoring him for the project. Is there already someone that took interest in mentoring this project? in my post in the mailing list (https://groups.google.com/forum/#!topic/julia-dev/7o4gMdB8PIc) alessandro adrioni (https://github.com/andrioni) wrote that he was able to serve as a mentor for the project, but I never saw him write on the discussions regarding the library. Someone that steps forward?

[jiahao]

I can mentor, but you'd hit the jackpot with @stevengj if he were available.

[acroy]

For GSOC I would concentrate on one specific solver and implement that in a correct and performant way (with support for the features we are discussing in doc/api.md. Personally, I would like to see an implicit solver (like RADAU or RODAS), but there might be other suggestions. That should be enough work for the summer and if there is still time we will certainly find some extra things to do.

Regarding the test suite, I think one should not underestimate that task. We are not talking about the kind of really simple tests we have now. As @stevengj pointed out, we need rigorous testing and comparison of our solvers for a variety of test cases (involving different ODEs, parameters, accuracies). The tricky part is probably to obtain a sensible and useful analysis of the test results. I would consider this a separate project in it's own right.

[edit ivarne: fixed link to api.md]