Tormod Landet

  1. Solving the Laplace equation with FEniCS

    I have found that explaining something is a good way to learn. As I am currently reading some books on the finite element method to refresh my rusting memories from math courses at university I thought it would be a good idea to write a summary of some of the basics. This post will explain how to use the finite element method and FEniCS for solving partial differential equations. FEniCS is a collection of tools for automated, efficient solution of partial differential equations using the finite element method.


    I will show how to apply FEniCS to a simple partial differential equation. I will also explain the solution method employed in the finite element method to solve the selected equation, the Laplace equation:

    \begin{equation*} \newcommand{\dif}{\mathrm{d}} \newcommand{\pdiff}[2]{\frac{\mathrm\partial#1}{\mathrm\partial#2}} \newcommand{\laplace}[1]{\nabla^2#1} \laplace{\phi} = 0 \end{equation*}

    When a fluid is incompressible, inviscid and the flow can be assumed to be irrotational then the Laplace equation shown above describes the fluid flow. The fluid velocities, \({\bf U} = (U_x, U_y, U_z)\), can be calculated from the velocity potential \(\phi\) as follows:

    \begin{equation*} U_x = \pdiff{\phi}{x} \qquad U_y = \pdiff{\phi}{x} \qquad U_z = \pdiff{\phi}{x} \end{equation*}

    Our domain, \(\Omega\), is a 2D square with \(x \in [0, 2]\) and \(y \in [0, 1]\). For the boundary conditions, let's say that we know the value of \(\phi\) at that the short boundaries and the normal derivative at the long edges is zero. The complete equation system can then be for example:

    \begin{align*} &\laplace{\phi} = 0 \\ \ \\ &\phi = -1.0 \quad &\text{on} \quad x = 0.0 \\ &\phi = +1.0 \quad &\text{on} \quad x = 2.0 \\ &\pdiff{\phi}{\bf n} = 42 \quad &\text{on} \quad \Gamma_L \\ \end{align*}

    where we define \(\Gamma_L\) to be the long edge boundaries \(y=0\) and \(y=1\). The normal vector on the boundary is \(\bf n\) and \(\pdiff{}{\bf n}\) is the normal derivative at the boundary. It is common to use \(\Omega\) to denote the domain and \(\Gamma\) to denote the boundary.


    Now, to solve the equation with boundary conditions we need a discretized domain. This can be created by using the FEniCS Python package dolfin like this:

    import dolfin as df
    start_x, end_x, n_elem_x = 0.0, 2.0, 4
    start_y, end_y, n_elem_y = 0.0, 1.0, 2
    mesh = df.RectangleMesh(start_x, start_y, end_x, end_y, n_elem_x, n_elem_y)

    Running df.plot(mesh) will show the following:

    The mesh

    An example mesh with triangular elements

    We discretize our domain \(\Omega\) into discrete elements and obtain \(\hat \Omega\). I will use the "hat" to denote discretized values. We use linear elements which means we will approximate the unknown function with piecewise linear functions, \(\phi \approx \hat \phi\). They look like this for a 1D domain with two elements and three vertices (nodes):

    Linear shape functions in 1D

    1D domain with three shape functions, \(N_1(x)\), \(N_2(x)\) and \(N_3(x)\)

    We have one shape function \(N_i\) for each vertex in the mesh. The shape functions are equal to 1.0 at the corresponding vertex and 0.0 at all other vertices. In 2D a standard bi-linear shape function looks as follows:

    Linear shape function in 2D

    2D domain with a bi-linear shape function shown for one of the vertices on the boundary

    Marking the boundaries

    We know how to make a mesh of the domain. We also need to tell FEniCS about the different parts of the boundary. We do this by giving the boundaries different unique integer numbers and marking the boundaries with a mesh function:

    # Each part of the mesh gets its own ID
    boundary_parts = df.MeshFunction("size_t", mesh, mesh.topology().dim()-1)
    # Define the boundaries
    GEOM_TOL = 1e-6
    define_boundary(lambda x, on_boundary: on_boundary and x[0] < start_x + GEOM_TOL, boundary_parts, ID_LEFT_SIDE)
    define_boundary(lambda x, on_boundary: on_boundary and x[0] > end_x - GEOM_TOL, boundary_parts, ID_RIGHT_SIDE)
    define_boundary(lambda x, on_boundary: on_boundary and x[1] < start_y + GEOM_TOL, boundary_parts, ID_BOTTOM)
    define_boundary(lambda x, on_boundary: on_boundary and x[1] > end_y - GEOM_TOL, boundary_parts, ID_TOP)

    The define_boundary function is just a small utility I made to make it easier to mark the boundaries. Normally you need to create a class for each boundary and implement a method, inside, on this class. My function accepts a lambda expression which is used instead:

    def define_boundary(defining_func, boundary_parts, boundary_id):
        Define a boundary
        - defining_func is used instead of the normal SubDomain inside method: defining_func(x, on_boundary)
        - boundary_parts is a MeshFunction used to distinguish parts of the boundary from each other
        - boundary_id is the id of the new boundary in the boundary_parts dictionary
        class Boundary(df.SubDomain):
            def inside(self, x, on_boundary):
                return defining_func(x, on_boundary)
        boundary = Boundary()
        boundary.mark(boundary_parts, boundary_id)
        return boundary

    The solution method

    The simplest variant of the finite element method to describe is probably the Galerkin weighted residuals method. The core of the method is described below.

    The unknown function \(\phi\) is written as a sum of \(M\) shape functions and a set of unknown coefficients, \(a_i\). There is one unknown coefficient for each shape function:

    \begin{equation*} \hat \phi(x,y) = \sum_{i=0}^{M} a_i N_i(x,y) \end{equation*}

    Suppose we guess some coefficients \(a_i\). We can then integrate our trial function, \(\hat \phi\) over the domain, but since the discretization is not perfect we get a residual and not zero as the equation was supposed to give:

    \begin{equation*} \int_{\Omega} \laplace{\hat \phi} \ \dif \Omega = R \end{equation*}

    To be able to fix this and find some coefficients \(a_i\) that gives zero residual we need a set of equations. This is done by multiplying the above integral with a set of weighing functions, \(w_i(x,y)\). The number of weighting functions is equal to the number of unknowns, so we get a fully determined set of linear equations. In the Galerkin method the weighting functions are taken equal to the shape functions, \(N_i\) except that we do not include shape functions corresponding to vertices where we know the solution \(\phi(x,y)\) from the Dirichlet boundary conditions.

    We then get a set of \(M\) equations:

    \begin{equation*} \int_{\Omega} \laplace{\hat \phi} w_i \ \dif \Omega = 0 \end{equation*}

    which is the same as:

    \begin{equation*} \int_{\Omega} \laplace{\left(\sum_{j=0}^M a_j N_j\right)} N_i \dif \Omega = 0 \end{equation*}

    Since the integral will only be non-zero for vertices that are close in the mesh, i.e. \(N_i\) and \(N_j\) have some overlap, we end up with a quite sparse equation system. Very efficient solvers exist for the types of equation systems that come out of the Galerkin method.

    Solving the equation system with FEniCS

    In the standard finite element terminology our unknown function \(\phi\) is called the trial function and denoted \(u\) while the weighting function is called the test function and denoted \(v\). We switch to this terminology to be compatible with the FEniCS tutorial. We call this equation the weak form:

    \begin{equation*} \int_{\Omega} \laplace{(u)}\,v \ \dif \Omega = 0 \end{equation*}

    Before we are done we need to modify the equation a bit. As written it makes little sense since the Laplacian of the bi-linear function \(N_j(x,y)\) will always be zero. We modify our weak form by performing integration by parts. The formula for this in higher dimensions is:

    \begin{equation*} \int_\Omega \pdiff{f}{x_i}\,g \ \dif \Omega = \int_\Gamma f\,g\,n_i\ \dif \Gamma - \int_\Omega f \pdiff{g}{x_i} \ \dif \Omega \end{equation*}

    where \(n_i\) is the \(i\)-th component of the outwards normal vector on \(\Gamma\). I do not think I ever learned that at school? Maybe it's just my rusty memory, but thanks to Wikipedia we will not let lacking education and/or failing memory stop us, now will we? We get this when applying integration by parts to our integral:

    \begin{equation*} \int_\Omega \laplace{(u)}\,v \ \dif \Omega = \int_\Gamma \nabla(u)\,v\,n_i\ \dif \Gamma - \int_\Omega \nabla (u)\cdot\nabla(v) \ \dif \Omega \end{equation*}

    I guess now is the time for me to remember to mention that the test function \(v\) is always zero at the Dirichlet boundaries. Dirichlet boundaries are boundaries where we have Dirichlet boundary conditions, which means we know the value of \(\phi\), i.e. the short edges of our mesh in this case. No reason to have a weight function there, right? We now have the final expression for the weak form:

    \begin{align*} \int_{\Omega} \nabla u \cdot \nabla v \ \dif \Omega &= \int_{\Gamma_N} \laplace{(u)}\,v\,n_i\ \dif \Gamma_N \\ &= \int_{\Gamma_N} \pdiff{u}{\bf n}\,v\ \dif \Gamma_N \end{align*}

    The long edges were we prescribe the normal velocity (normal derivative of the velocity potential \(\phi\)) are now denoted \(\Gamma_N\) since this type of boundary condition is called a Neumann boundary condition.

    FEniCS understands equations such as the above and calls them forms. To describe the equations we use UFL, Uniform Form Language which is a Python API for defining forms. When interacting with FEniCS through Python we can use UFL through the dolfin package just like the mesh facilities. UFL can also be directly imported, import ufl.

    # Define a function space of bi-linear elements on our mesh
    V = df.FunctionSpace(mesh, 'Lagrange', 1)
    # The trial and test functions are defined on the bi-linear function space
    u = df.TrialFunction(V)
    v = df.TestFunction(V)
    # Our equation is defined as a=L. We only define what is inside the integrals, and the difference
    # between integrals over the domain and the boundary is whether we use dx or ds:
    #   - the term a contains both the trial (unknown) function u and the test function v
    #   - the term L contains only test function v
    a = df.inner(df.nabla_grad(u), df.nabla_grad(v))*df.dx
    L = df.Constant(42)*v*df.ds(ID_BOTTOM) + df.Constant(42)*v*df.ds(ID_TOP)

    This is basically all there is to solving the Laplace equation in FEniCS. The complete code can be seen below. The parts I have skipped explaining above are well explained in the FEniCS tutorial.

    Complete code

    The complete code can be found on Bitbucket. The resulting plot from running the code with FEniCS 1.3 is shown below:

    Plot of the result

    Plot of the resulting \(\phi\) function

    If you have any questions to the above and how to use FEniCS you can ask here, but I would really recommend the FEniCS QA Forum where you will probably get better and faster answers.

  2. Creating a mesh in FEniCS

    I may end up doing a large project using FEniCS which is a collection of tools for automated, efficient solution of differential equations using the finite element method. While playing with implementing a simple solver for fluid flow in a tank by use of FEniCS to solve the Laplace equation I needed to create my own mesh in code.

    FEniCS is quite well documented, but I had to look at the source code for some of the mesh conversion routines to find out how to build a mesh from scratch. So, for posterity, here is a reimplementation of dolfin.RectangleMesh in a much more cumbersome (and flexible) way:

    import numpy
    import dolfin as df
    def create_mesh(length, height, nx, ny, show=False):
        Make a square mesh manually
        Should give exactly the same results as using the built in dolfin.RectangleMesh() class
        # The number of mesh entities
        nvert = nx*ny
        ncell = 2*(nx-1)*(ny-1)
        # Positions of the vertices
        xpos = numpy.linspace(0, length, nx)
        ypos = numpy.linspace(0, height, ny)
        # Create the mesh and open for editing
        mesh = df.Mesh()
        editor = df.MeshEditor(), 2, 2)
        # Add the vertices (nodes)
        i_vert = 0
        for x in xpos:
            for y in ypos:
                editor.add_vertex(i_vert, x, y)
                i_vert += 1
        # Add the cells (triangular elements)
        # Loop over the vertices and build two cells for each square
        # where the selected vertex is in the lower left corner
        i_cell = 0
        for ix in xrange(nx-1):
            for iy in xrange(ny-1):
                # Upper left triangle in this square
                i_vert0 = ix*ny + iy
                i_vert1 = ix*ny + iy+1
                i_vert2 = (ix+1)*ny + iy + 1
                editor.add_cell(i_cell, i_vert0, i_vert1, i_vert2)
                i_cell += 1
                # Lower right triangle in this square
                i_vert0 = ix*ny + iy
                i_vert1 = (ix+1)*ny + iy+1
                i_vert2 = (ix+1)*ny + iy
                editor.add_cell(i_cell, i_vert0, i_vert1, i_vert2)
                i_cell += 1
        # Close the mesh for editing
        print 'Created mesh with %d vertices and %d cells' % (nvert, ncell)
        if show:
        return mesh

    If anyone finds this by searching the web for how to build a mesh programmatically in FEniCS/dolfin, then I hope the above was understandable. The documentation is quite good when you know that you need to search for the MeshEditor class ...

  3. Sorting images

    Once upon a time, back when I was using Windows at home, I had a useful small program that helped me sort through new pictures from my camera. I have forgotten the name of the program, but basically it allowed me to sort the good pictures from the bad in a fast and efficient manner so that the really bad ones could be deleted and the good ones could be separated, maybe for sharing with others.

    I have just been on a trip where I took quite some pictures. I could have gone over the pictures and manually copied the good ones into a separate folder for sharing with friends. This would have been a bit boring, but it would only have taken about five minutes. As a programmer I of course selected to optimize this task and spent some hours recreating the program I had once used. After a thousand trips or so I will come out ahead in terms of time spent!

    The program looks like this:

    Picster GUI

    I named it Picster, short for Picture Sorter. There is, of course, at least one other programs with that name already, but I cannot be bothered to find something better at the moment, It's just a script, after all. It is meant to be used from the keyboard, but there are also buttons for all possible actions (moving between images, categorizing images, and sorting images on disk based on category information).

    All of the GUI coding I do at work is scientific visualization, mostly using Python 2 and the wx library in some way. To try something slightly different I went with Python 3 and Qt for this program. I cannot really call myself an expert in Qt after only a couple of hours and the Picster code is probably not how a Qt expert would have written it, but it seems to work OK.

    From this brief encounter, Python Qt code seems to be a bit more verbose and tedious compared to wxPython. For example Qt/PySide is missing the nice init arguments, so all properties on an object must be set after creation through method calls. The API is not very pythonic with no use of Python properties as far as I understood. I am also missing docstring help on class and method name completion in Eclipse PyDev :-(

    Also missing as far as I understood is the wxPython ability to bind to any event from anywhere. To listen for keystrokes or window size change for example you must override virtual methods. For now I am happy with using wx at work. The Qt documentation that was rumored to be fabulous seems quite on the same level of the wx documentation as well.

    What I really liked about Qt was the Layouts which work almost exactly like Sizers in wx, except that they come with a sensible default spacing of widgets. This is a sore spot in laying out wx interfaces and always needs manual intervention to look good.

    Enough mostly unqualified statements about Qt vs. wx, here's the code for anyone interested in a picture sorting program. The code requires Python (probably works in versions 2 and 3, tested in 3.2) and PySide for Python bindings to Qt.

  4. En beretning om blindhet - José Saramago

    En beretning om blindhet er en flott fortalt historie om et samfunn som faller fra hverandre. Dette er enda en "hva hvis" fortelling slik som Dødens uteblivelse. Denne gangen er det en epidemi av blindhet som sprer seg og setter verden på hodet for innbyggerne i et uspesifisert land. Ingen unnslipper utenom kona til øyenlegen som undersøker den første smittede blinde. Historien utspiller seg på et asyl for smittede der forholdene gradvis forverrer seg for de som holdes der av myndighetene. Den seende kona gjør så godt hun kan, men barbarismen sprer seg raskt når det blir lenge nok siden forrige varme måltid.

    I motsetning til Dødens uteblivelse er samfunnets og enkeltmenneskenes reaksjoner bedre beskrevet og mer troverdige i denne fortellingen. En del er kanskje satt på spissen, men fortvilelsen, volden, frykten og maktløsheten er til å ta og føle på og jeg blir revet med av enkeltpersonenes skjebner og personligheter.

    Jeg er fremdeles ikke noen stor fan av Saramagos uendelig lange og snirklete setninger. Det er heldigvis mer enn dem som skiller dette fra en ti på dusinet spenningsbok, så jeg ser ikke helt poenget i å tvære ut språket og trekke ned tempoet så mye som Saramago gjør. Boka hadde blitt høyere anbefalt av meg hvis den kunne leses på en fornuftig mengde tid og i litt lengre strekk. Slik den er nå må jeg ha pauser og mister fort litt av interessen. Sett bort fra det tunge språket er En beretning om blindhet en fin fortelling.

    Sertig, Davos

    Sertig, Davos

  5. The Gardens of the Moon - Steven Erikson

    Steven Eriksons bokserie Malazan Book of the Fallen er en av de store milepælene innen moderne episk fantasy såvidt jeg har forstått. Gardens of the Moon er den første boka i serien, som fremdeles ikke er helt ferdig, men som allerede består av ni bøker av ti totalt.

    Det er mye jeg liker med denne boka. Erikson er flink til å lage gode hovedpersoner, det er et intrikat plott og handlingen og motivene er ikke svart/hvit. Dette er alle veldig gode egenskaper ved en episk fantasybok. Likevel vet jeg ikke helt om jeg kommer til å lese mer av denne serien. Hele settingen er veldig mørk. Det foregår en endeløs, stor krig. Det hele virker håpløst og døden er alltid like rundt hjørnet. Jeg er ikke helt sikker på at jeg greier å tro på en slik historie og menneskene som velger å fortsette i samme spor når de har mulighet til å komme seg unna og gjøre noe annet. Det hele blir litt for håpløst for meg til tider.


    Fra Estenstadmarka

« Page 2 / 9 »