Written by Adrien Haxaire
on 

funfem

Time has come for me to introduce funfem. funfem is the functional finite element library. I could say it is a functional finite element library, but there aren’t enough of them to say it is yet another finite element library. To my knowledge, only femlisp exists, and it does not emphasize that much on the functional aspect of it. Funfem is open-source; it follows a BSD3 license.

The ‘fun’ in funfem has at least three meanings:

  1. fun as in functional.
  2. fun as in fun.
  3. fun as in fundamental.

Let’s explain these points in more details.

First, I am learning Haskell, and there’s nothing better than a project to go in the details and have a better understanding of the language. But more than that, I want to show that functional languages are also well-suited for scientific/numerical methods. After all, the finite element method is a set of functions and relations, which are first class citizens in functional languages. I am convinced than once Haskell syntax is understood, which takes less than apprehended, the organization of the program and the method are simpler to grasp than the flood of imperative loops.

Second, believe me or not, it is fun. This is not the first word that comes to mind when thinking of finite elements, but out rooting it from its imperative culture is really a lot of fun. I have been asked why I was not implementing more ‘haskell-ish’ programs, like chess games or sudoku solvers, instead of yet another finite element library, or why I wouldn’t want to write a Haskell wrapper around a C++ ‘fast’ library instead. My answer was that language where it is not expected is fun (after precising that functional languages are far from confined to those cliches). Attacking the FE method with a functional approach is fun. As James Hague put it nicely when explaining why Erlang for games, ‘it seemed so perverse’: that brings its amount of fun in itself. Moreover, I work on this library on my spare time, so if there is no fun, there is no point in it.

The third point is about the nature of this library. Funfem is an experiment. It is not aimed to be used in the industry; there are already plethora of libraries that focus on performance, features, etc. Funfem is a crucible for students, researchers and any curious mind. There won’t be tuning techniques, benchmarks to see if I gained 32ms at the cost of obfuscating the code. I want funfem to be crystal clear, nearly a bit naive, so that students can learn the FE method easily. To show that Haskell is more friendly and less esoteric than the imperative point of view might suggest. Simple enough to invite imperative programmers to look into the code.

Yet it does not mean that I don’t want it to run smoothly. I want to be able to run consequent models in a reasonable time. Not the fastest I could get, but reasonable enough. I intend to parallelize it to gain some performance, to learn then show how easy it is with Haskell. I love Haskell because I spend much of my time thinking about the algorithm instead of implementing it. I hope that in this respect funfem will leverage new approaches on the algorithms used generally in the FE method, or even new algorithms. I am curious about what a plasticity law will look like in funfem. You get the idea: I want funfem to be the tool that allows easy implementation of new ideas, approaches, while not having to fear an off-by-one mistake. This is where I think the functional approach will shine.

Funfem aims to be generic. Users should be able to model physics and couplings between them simply. For example, I am quite curious about the implementation of avalanches and glacier dynamics. This has to be easy to implement in funfem. If not, it will mean that the library is not simple enough. A note on the features. I’d like funfem to have:

… and many more. All written in Haskell of course. That’s a long road, but I am in no hurry.

About the status. You will not be surprised to read that the 0.0.1 version is not even finished. I’ll upload it to Hackage when I have something playable with. That should be soon, still. You can find the code at the darcs repository or browse it on the website. There is also a github mirror.

I’ll be writing extensively about it. Any feedback welcome.

I hope you will enjoy it as much as I already do.