Since we are at the end of the Google Summer of Code 2016, It is now the time to write a final post to talk about what I have done during this summer.
But let me re-introduce myself first: I am Michaël Sghaïer, french third-year student in Software Engineering at Polytechnique Montréal, Canada. I am mostly interested in C++ programming, Python and algorithms and this is why I have taken part in this Google Summer of Code 2016 as developer for the DUNE organization where my project was to implement Python bindings for the DUNE grid interface.
What I have done
As described in my proposal and in the first post of this blog, my project was to export to Python the grid interface that DUNE provides. This grid interface is the core of the DUNE project since each grid implementation has to fulfill it to provide a specific discretization of space, in a transparent way for the user who can then solve partial differential equations using the grid of his choice.
To achieve this project, I dived myself in the huge C++11 codebase of DUNE, learnt how to use pybind11, discussed a lot with my mentors, worked with sub-milestones and finally did a lot of debugging. You can find the final result as a DUNE module named
dune-corepy just here: https://gitlab.dune-project.org/michael.sghaier/dune-corepy and see all my activity (commits, issues, merge requests) here: https://gitlab.dune-project.org/u/michael.sghaier (entirely related to this
project). The project is in a useable state and you can test it after a few steps, as explained in the
With the help of my mentors, I implemented bindings for almost all of the concepts listed in my proposal:
- (hierarchical) grid
- grid construction
- parallel computing/communication
- load balancing
As you can see, I did not export any mechanism to use adaptivity (which is the name of the process of refining a grid) in Python. Indeed, my mentors would like to provide a more advanced mechanism that the one provided by default by the grid interface, so they asked me to not care about that.
Regarding the unit tests and the build system I talked about in my proposal, there have been some changes. Indeed, I did not provide unit tests but instead I implemented the finite volume, finite element and parallel finite volume schemes described in the grid-howto.pdf document in Python, using my bindings. It gave me sub-milestones to achieve and that was crucial to know where I was going, in addition to helping me debugging my bindings. As for the build system, I simply used DUNE’s so I did not develop anything new.
Finally, I maintained this blog to give regular feedbacks about my project (see the archive here).
What is left to do
As the end of this GSoC was coming, I did some cleaning and gave a thought about what is left to do (or at least, what is left to think about):
- providing a mechanism to use adaptivity from Python
- fixing the bugs listed in the GitLab
- maybe developing a system for testing grid prototypes
A final word
It have been a real pleasure taking part in this adventure! I learnt a lot: about C++ (11 and 14), about the possible interactions between C++ and Python, about how to manage an open source project and finally about myself. Indeed, after this GSoC, I think I am more interested in computer science itself rather than a scientific field that uses computing capabilities (like computational science in the case of DUNE, for example). So I am not sure I will continue to contribute to DUNE, although
I will maintain
Anyway, It has been definitely a great experience and I warmly thank Google, DUNE and my mentors for having given me this opportunity! :-)
After three months of work, the GSoC is coming to its end. Before writing a final post about my work (as final submission to Google), here is a short post to talk about the past few days.
As I said in my previous post, I focused on documentation and cleaning. Thus, I especially wrote documentation for developers who may want to contribute to
dune-corepy, see https://gitlab.dune-project.org/michael.sghaier/dune-corepy/tree/master/doc/sphinx (you can build the doc with
make doc in the
build-cmake directory of
dune-corepy). I also did some refactoring for the bindings of
https://gitlab.dune-project.org/michael.sghaier/dune-corepy/commit/228a5e0d131f870ea051a53a2ee227ff647d7ae6 and https://gitlab.dune-project.org/michael.sghaier/dune-corepy/commit/2480fef5ba8deff3552cfa97d2272e7a868aa276. Finally, I worked on a merge request to harmonize the shared libraries generated by
dune-corepy, see https://gitlab.dune-project.org/michael.sghaier/dune-corepy/merge_requests/2.
During the following days, I will be improving the documentation, testing
dune-corepy to find bugs/issues and finally writing a final post on this blog.
Last week was dedicated to some cleaning of
dune-fempy. In fact my mentors, who are working on
dune-fempy for a long now, wanted to base
dune-corepy. Since I worked a lot on
dune-corepy, it was the time to take some actions in that direction. In consequences, my mentors cleaned up the codebase of
dune-corepy and moved some stuff from
dune-corepy (especially some features for grid constructions). I finally reviewed and tested their changes and they merged that into the master branche (see the commits in the gitlab).
I also continued to debug my parallel interface when using a
DataHandle class specialized with
pybind11::object (see my previous post) but still without success. Thus, I chose to move on, writing some documentation for the developers who may want to contribute to
dune-corepy. In fact, after having a skype conversation with my mentors, we decided to prepare for the end of this GSoC: documentation, cleaning, tests and bug fixes. Thus, I made some bug fixes after the merge of my mentors
(the iterators were broken) and wrote some documentation with sphinx.
Next week will also be dedicated to documentation, cleaning and bug fixes, I keep you in touch!