Different solution with different software

[Félix Bunel]

Hi guys !

I'm curently working on a project which consist in solving on a circle the Leslie Eriksen problem. I'm facing an issue with the stokes part of the problem :

a, phi_s, phi_lin, X are constant u, v, P, phi are variables.

I'm solving the two different equation (the one with \phi, and the stokes problem) separately. For each time-step I solve phi and inject it in the stokes problem to get a suitable u,v. Then I re-inject u, v in the first equation to get a better \phi. Then I inject it in stokes, and so on... You get the idea. This procedure converges towards a solution.

I have another code (Mathematica) that do exactly the same, but only for the equilibrium state (t->infinite, all time derivative disappear)

I wanted to compare the results of the two codes in this case to check for the viability of my solution. (I used X=4, a=2, phi_s = phi_lin = 5)

Unfortunately the two codes do not output the same results. Although the solutions looks very similar they are still a bit different as you can see below.

To understand better where the problem is coming from, I'm comparing only the first iteration :

- I solve Phi in the first equation with u,v=0, which gives me a solution (it can be calculated analytically in this case, the solution is \phi = \phi_lin*(1-x^2 -y^2)

- I solve u, v, P in the stokes problem using this phi

Then I compare the results of both codes.

Here are the results :

1 - The first equation in phi is very well solved and both codes gives the same results. They both gives a solution that corresponds to the one calculated analytically.

2 - The two codes do not give the same results for the stokes problem. The two solutions looks almost exactly the same, but the one given by my dealii code give higher values for the velocity field and smaller values for the pressure.

Here, I plot the velocity component u, along the the y axis in both codes :

Mathematica : (maximum is 14.33)

Dealii : (maximum is 18.44)

Here are what the stokes solution looks like :

Here are the idea I thought could be the reason :

1 - Mesh : I tried different mesh refinement in both code and they always gives the same values

2 - Fe-element : I know for the stokes problem that it needs to be at a higher order for u and v than for P. In the dealii code I use : stokes_fe(FE_Q<2>(2), 2, FE_Q<2>(1), 1) and I also enforce this in the mathematica code. I also tried different fe order and it did not change the results

3 - My error : I have re-read my equations in Mathematica again and again. Re-calculated my weak formulation again and again and checked my assembly process in dealii again and again... I did not find a single mistake...

If you want more detail about what i'm doing, I'm joining the pdf where I have written the equations and my weak formulation (from page 3 to page 5).

Thanks in advance

[Daniel Arndt]

Felix,

the usual approach for verifying your code is the method of manufactured solution. Choose functions that are elements of your ansatz space for all solution variables

(possibly chaningyour grid to a cartesian one) and compute the corresponding right-hand side. Check that the error vanishes.

If that works, choose smooth functions not part of your ansatz space and check the rate of convergence when refining your mesh.

You may also want to have a look at https://www.dealii.org/8.5.0/doxygen/deal.II/step_7.html for this.

Best,

Daniel

[Wolfgang Bangerth]

Felix,
in addition to what has been suggested before, think also about the fact that
you don't know which of the two solutions you have is correct. Before you draw
any conclusions, you need to find a way to establish which one is the one that
is correct and which one is not.

Best
W.

On 7/19/19 2:37 AM, Félix Bunel wrote:
> Hi guys !
>
> I'm curently working on a project which consist in solving on a circle the
> Leslie Eriksen problem. I'm facing an issue with the stokes part of the problem :
>

> Dealii : (maximum is 18.44)

>
> Here are what the stokes solution looks like :

> <about:invalid#zClosurez>

>
>
>
>
>
>
>
>
>
>
> Here are the idea I thought could be the reason :
>
> 1 - Mesh : I tried different mesh refinement in both code and they always
> gives the same values
> 2 - Fe-element : I know for the stokes problem that it needs to be at a higher
> order for u and v than for P. In the dealii code I use : stokes_fe(FE_Q<2>(2),
> 2, FE_Q<2>(1), 1) and I also enforce this in the mathematica code. I also
> tried different fe order and it did not change the results
> 3 - My error : I have re-read my equations in Mathematica again and again.
> Re-calculated my weak formulation again and again and checked my assembly
> process in dealii again and again... I did not find a single mistake...
>
>
> If you want more detail about what i'm doing, I'm joining the pdf where I have
> written the equations and my weak formulation (from page 3 to page 5).
>
> Thanks in advance
>

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com
> <mailto:dealii+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/cd5ad853-5fbb-4daa-8a3e-a2f4d626760d%40googlegroups.com
> <https://groups.google.com/d/msgid/dealii/cd5ad853-5fbb-4daa-8a3e-a2f4d626760d%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Félix Bunel]

Hi, Thanks to both of you for your answers.

I have tried a simple testcase for my problem.

I don't know if it's suitable as a testcase but if I use X=0 in my equations above, I know the solution.

The solutions is  u = v = 0, \phi = (1-x^2 -y^2) and the pressure is then P = 8 \phi_lin^2 (1-x²-y²)

It fits with my boundary conditions which are u = v = p = \phi = 0 at the boundaries.

Here are the results for dealii with a = 2  and phi_lin = 4*pi.

Left is the L2 norm of u and v. As you can see it's going to 0 when i jump to a higher refinement cycle.

Last one is cycle 7 and has 81 920 cells, U and V are second order, P is first order, Phi is second order.

Here is what the solution looks like :

I'm a bit at a lose. Why does it work for X = 0 but not when I use a different X ?

Mathematica gave the same solution. I did not do it for different mesh but at the finest mesh it gave the good solution.

> email to dea...@googlegroups.com
> <mailto:dea...@googlegroups.com>.

[Daniel Arndt]

Felix,

I have tried a simple testcase for my problem.

I don't know if it's suitable as a testcase but if I use X=0 in my equations above, I know the solution.

The solutions is  u = v = 0, \phi = (1-x^2 -y^2) and the pressure is then P = 8 \phi_lin^2 (1-x²-y²)

It fits with my boundary conditions which are u = v = p = \phi = 0 at the boundaries.

Here are the results for dealii with a = 2  and phi_lin = 4*pi.

Left is the L2 norm of u and v. As you can see it's going to 0 when i jump to a higher refinement cycle.

Is the rate of convergence as expected?

 

I'm a bit at a lose. Why does it work for X = 0 but not when I use a different X ?

Are you sure that your deal.II solution is wrong in fact? If u = v = 0 in your test case, there might still be a problem with these equations.

I would also try a case where you manufacture a solution and implement a right-hand side term such that this is the solution to your equations.

Since the ansatz space on non-affine mapped geometries is not polynomial anymore, I would also try a cartesian mesh for the case that the solution is contained

in your ansatz space.

Best,

Daniel

[Félix Bunel]

I have tried a simple testcase for my problem.

I don't know if it's suitable as a testcase but if I use X=0 in my equations above, I know the solution.

The solutions is  u = v = 0, \phi = (1-x^2 -y^2) and the pressure is then P = 8 \phi_lin^2 (1-x²-y²)

It fits with my boundary conditions which are u = v = p = \phi = 0 at the boundaries.

Here are the results for dealii with a = 2  and phi_lin = 4*pi.

Left is the L2 norm of u and v. As you can see it's going to 0 when i jump to a higher refinement cycle.

Is the rate of convergence as expected?

I believe so. I did a linear regression of the convergence graphs in logscale and got a value of :

-7.6 for the speed : I believe it corresponds to the -8 from second order finete element in 2D

-3.2 for the pressure : I beliebe it corresponds to the -4 from the first order finite element in 2D

 

 

I'm a bit at a lose. Why does it work for X = 0 but not when I use a different X ?

Are you sure that your deal.II solution is wrong in fact?

I'm not sure at all if this solution is wrong or not. I have to admit this solution looks very good to me and suits the results I was hoping for.

It's just different from the one given from another code (the mathematica one) and I don't understand why. It could be the other code that gives a bad solution.

 

If u = v = 0 in your test case, there might still be a problem with these equations.

I'm not sur to understand what you are saying here. Can you elaborate why you think there is a problem in my equations ?

 

I would also try a case where you manufacture a solution and implement a right-hand side term such that this is the solution to your equations.

I'm trying this at the moment

Since the ansatz space on non-affine mapped geometries is not polynomial anymore, I would also try a cartesian mesh for the case that the solution is contained

in your ansatz space.

I don't really understand what you mean by ansatz space although I have looked it up on google. Do you suggest that I try the X=0 solution on a square mesh ?

Thanks again for your help, this is really helpful to talk about this to someone.

 

Best,

Daniel

[Daniel Arndt]

Felix,

Is the rate of convergence as expected?

I believe so. I did a linear regression of the convergence graphs in logscale and got a value of :

-7.6 for the speed : I believe it corresponds to the -8 from second order finete element in 2D

-3.2 for the pressure : I beliebe it corresponds to the -4 from the first order finite element in 2D

Good!

 

If u = v = 0 in your test case, there might still be a problem with these equations.

I'm not sur to understand what you are saying here. Can you elaborate why you think there is a problem in my equations ?

If the reference solution is 0, you can't see if you are missing a constant factor in your equation even when the rate of convergence looks correct.

 

 

Since the ansatz space on non-affine mapped geometries is not polynomial anymore, I would also try a cartesian mesh for the case that the solution is contained

in your ansatz space.

I don't really understand what you mean by ansatz space although I have looked it up on google. Do you suggest that I try the X=0 solution on a square mesh ?

Yes, but then you also have to be careful with the boundary conditions. If you have an analytical solution with homogeneous Dirichlet boundary conditions for \phi,

I would definitely try that first.

The ansatz space is the space spanned by the basis functions you are using for your solution variables. In case the mapping from the reference cell to the

real cell is affine and you use polynomial base functions (on the reference element), the ansatz space is polynomial as well. Then, it is easier to manufacture

a solution that is contained in the ansatz space.

Best,

Daniel

[Félix Bunel]

If the reference solution is 0, you can't see if you are missing a constant factor in your equation even when the rate of convergence looks correct.

I understand thank you !

 

Yes, but then you also have to be careful with the boundary conditions. If you have an analytical solution with homogeneous Dirichlet boundary conditions for \phi,

I would definitely try that first.

It already has homogeneous Dirichlet boundary conditions. \phi is set to 0 at the boundaries as well as all the other variables (u, v, P).

 

The ansatz space is the space spanned by the basis functions you are using for your solution variables. In case the mapping from the reference cell to the

real cell is affine and you use polynomial base functions (on the reference element), the ansatz space is polynomial as well. Then, it is easier to manufacture

a solution that is contained in the ansatz space.

I'm not sure to understand how to manufacture a solution for my problem. I have read step 7 a few times and I understand but for a coupled system like mine, I don't see how to do it.

Should I choose a solution with u and v that already respect the icompressibility equation ?

Should I keep the same phi or change it for another one ?

Should I keep the same boundary conditions (everything = 0) on the sides ?

From the look of it, the problem comes from the stokes equation. In my simple case described above, the problem in phi is just a poisson equation and I checked that the solution is the correct one (with a good convergence rate).

I also completely erased my assembly of the stokes problem and re-wrote it. It did not change a thing.

By the way, i'm now confident that the problem comes from my dealii code and not from my mathematica code. I have implemented the same code using Fenics, the python library, and it gives the exact same results as the mathematica code. I used the same weak formulation in both the dealii and fenics codes.

Fenics and Mathematica use triangles for a mesh and Dealii use squares. Could this cause a difference in the solution, especially knowing that i'm working on a sphere ? I'm currently comparing the same equations on a square mesh. We will see how it goes.

I'm joining a cpp file with the parts of the code that only correspond to the stokes problem. I pretty much used the same format as in the tutorial so it will look familiar to anyone that read or wrote them.

Will send another e-mail in the afternoon after I studied the problem on a square mesh.

Thanks again to you Daniel for taking the time to help me, and for having developed dealii which is by far the best FE solver for complex problems I have used so far.

[Félix Bunel]

So I did the study on a square mesh. It was faster than I thought. It's so easy to change just the mesh when the library is well coded !

It's the following :

- I solve Phi in the first equation with u,v=0, which gives me a solution. It's just a Poisson equation.

- Then I solve this equation : (with phi_s, a, phi_lin, X are constants) I used my typical values : phi_lin = phi_s = 5, a = 2, X=4

Where I defined :

From this I deduce my weak formulation.

I solved this with Mathematica, Dealii, Fenics.

In Mathematica I enter directly the equation. In dealii and fenics I enter my weak formulation.

All three of them on a square mesh [0,1]x[0,1].

All three of them with Second Order Polynomial FE Element for Phi, U, V and First Order Polynomial FE Element for P.

All three of them with around 1 million DOFS (~500 000 for U V, ~250 000 for Phi, ~60 000 for P)

In the dealii and fenics code, I use the same direct solver umfpack.

Main difference I saw is that dealii use squares and not triangles like mathematica and fenics

To compare the solution, I trace the profile along X and Y in the center of the image and look at the maximum and at the profile itself.

The profiles

are in this order in the figure :

First Figure :Phi(x,0.5) Phi(0.5,y),

Second Figure : all the speeds (u(x,0.5), u(0.5,y), v(x,0.5), v(0.5,y),

Third Figure : P(x,0.5) P(0.5,y).

Dealii

Sur X
Phi 0.2946
U 7.89
V 18.48
P 2349

Sur Y
Phi 0.2946
U 18.48
V 7.89
P 2500

Fenics :

Sur X
Phi 0.2946
U 7.64
V 14.73
P 2368

Sur Y
Phi 0.2946
U 14.72
V 7.64
P 2613

Mathematica

Sur X
Phi 0.29468
U 7.65
V 14.77
P 2364

Sur Y
Phi 0.2946
U 14.78
V 7.65
P 2609

The results from mathematica, fenics and dealii are in agreement for the equation in phi (since it's a simple poisson equation, that was expected !)

The results from mathematica and fenics are in agreement for the stokes equation. And are different from the dealii results.

The solution look very much the same, except they give larger value in the dealii code. It's the same behavior than what I had in the circle mesh.

It's not an exact scaling factor from what i'm seeing.

I don't know what to try next. I will try to do a manufactured solution but I will need some help on the question I have asked in my previous message about this.

[Félix Bunel]

One final remark for today, if I remove the two asymmetrical terms in my equation so it becomes :

Then all three codes gives back the same solution...

So I thought it would come from my assembly of this part of the system but I have checked and checked again... It should not come from my weak formulation since the fenics and dealii have the same one.

Something to do with the matrix no longer being symmetrical ? But I used UMFPack as a solver so it should not be an issue...

Here is my assembly process for the stokes problem in case you see something wrong

void Elfe::stokes_assemble_system ()
{   //Fonction qui assemble le problème de Stokes

    std::cout << BLUE << "Assemblage Stokes            " << RESET
              << std::endl;

    //On réinitialise la matrice et le rhs
    stokes_system_matrix = 0;
    stokes_system_rhs = 0;

    //On charge de quoi extraire les valeurs
    QGauss<2>  quadrature_formula(4);
    const unsigned int   dofs_per_cell = stokes_fe.dofs_per_cell;
    const unsigned int   n_q_points    = quadrature_formula.size();

    std::vector<types::global_dof_index> local_dof_indices (dofs_per_cell);

    FullMatrix<double>   local_matrix (dofs_per_cell, dofs_per_cell);
    Vector<double>       local_rhs (dofs_per_cell);

    //Stokes values
    FEValues<2> stokes_fe_values(stokes_fe, quadrature_formula,
                         update_values | update_gradients | update_JxW_values);

    double u_i, v_i;
    double u_i_x, u_i_y, v_i_x, v_i_y;
    double u_j, v_j;
    double u_j_x, u_j_y, v_j_x, v_j_y;
    double P_i, P_j;

    const FEValuesExtractors::Vector Velocities(0);
    const FEValuesExtractors::Scalar Pressure(2);

    //Phi values
    FEValues<2> phi_fe_values(phi_fe, quadrature_formula,
                         update_values | update_gradients | update_JxW_values);

    double phi, phi_x, phi_y;
    double DX;

    double philin   = 2*pi*n;
    double phiscale = 2*pi*s;

    std::vector<Tensor<1, 2> > phi_solution_gradients(n_q_points);
    std::vector<double>        phi_solution_values(n_q_points);

    //Il nous faut 2 cell iterator, un pour phi, un pour stokes
    typename DoFHandler<2>::active_cell_iterator
    stokes_cell = stokes_dof_handler.begin_active(),
    stokes_endc = stokes_dof_handler.end();

    typename DoFHandler<2>::active_cell_iterator
    phi_cell = phi_dof_handler.begin_active();

    for (; stokes_cell!=stokes_endc; ++stokes_cell, ++phi_cell)
    {   //Pour chaque cell
        stokes_fe_values.reinit(stokes_cell);
        phi_fe_values.reinit (phi_cell);

        local_matrix = 0;
        local_rhs    = 0;

        //On récupère les valeurs pour les angles phis
        phi_fe_values.get_function_values(phi_solution,
                                 phi_solution_values);
        phi_fe_values.get_function_gradients(phi_solution,
                                  phi_solution_gradients);
       
        for (unsigned int q=0; q<n_q_points; ++q)
        {   //Pour chaque point de quadrature
            DX =  stokes_fe_values.JxW(q);

            phi = phi_solution_values[q];
            phi_x = phi_solution_gradients[q][0];
            phi_y = phi_solution_gradients[q][1];

            for (unsigned int i=0; i<dofs_per_cell; ++i)
            {  
                u_i   = stokes_fe_values[Velocities].value   (i, q)[0];
                v_i   = stokes_fe_values[Velocities].value   (i, q)[1];
                u_i_x = stokes_fe_values[Velocities].gradient(i, q)[0][0];
                u_i_y = stokes_fe_values[Velocities].gradient(i, q)[0][1];
                v_i_x = stokes_fe_values[Velocities].gradient(i, q)[1][0];
                v_i_y = stokes_fe_values[Velocities].gradient(i, q)[1][1];
                P_i   = stokes_fe_values[Pressure]  .value   (i, q);

                local_rhs(i) += (
                   
                    u_i*(
                        8*philin*phiscale*X
                        *(cos(2*phiscale*phi)*phi_x + sin(2*phiscale*phi)*phi_y)

                        + 2*phiscale*phiscale*phi_x*(-4*philin/phiscale)
                    )

                  + v_i*(
                        8*philin*phiscale*X
                        *(sin(2*phiscale*phi)*phi_x - cos(2*phiscale*phi)*phi_y)

                        + 2*phiscale*phiscale*phi_y*(-4*philin/phiscale)
                    )
   
                    )*DX;

                for (unsigned int j=0; j<dofs_per_cell; ++j)
                {              
                    u_j   = stokes_fe_values[Velocities].value   (j, q)[0];
                    v_j   = stokes_fe_values[Velocities].value   (j, q)[1];
                    u_j_x = stokes_fe_values[Velocities].gradient(j, q)[0][0];
                    u_j_y = stokes_fe_values[Velocities].gradient(j, q)[0][1];
                    v_j_x = stokes_fe_values[Velocities].gradient(j, q)[1][0];
                    v_j_y = stokes_fe_values[Velocities].gradient(j, q)[1][1];
                    P_j   = stokes_fe_values[Pressure]  .value   (j, q);
                     
                    local_matrix(i, j) += (
                        //Classical Stokes terms
                        - u_i_x*u_j_x - u_i_y*u_j_y - v_i_x*v_j_x - v_i_y*v_j_y
                        + (u_i_x+v_i_y)*P_j
                        + P_i*(u_j_x+v_j_y)

                        //Leslie Asymetrical terms
                        + phiscale/a
                          *(v_i_x-u_i_y)
                          *(u_j*phi_x + v_j*phi_y + 1/2/phiscale*(u_j_y-v_j_x))

                        //Terme provenant du laplacien phi
                        -2*phiscale*phiscale/a
                          *(u_i*phi_x + v_i*phi_y)
                          *(u_j*phi_x + v_j*phi_y + 1/2/phiscale*(u_j_y-v_j_x))

                        )*DX;
                }              
            }
        }

        stokes_cell->get_dof_indices (local_dof_indices);

        //On applique les boundary conditions
        stokes_constraints.distribute_local_to_global(local_matrix,
                                            local_rhs,
                                            local_dof_indices,
                                            stokes_system_matrix,
                                            stokes_system_rhs);
    }

}

[Jean-Paul Pelteret]

Dear Felix,

I don’t claim to have read through your comprehensive documentation of your issue in any detail, but one observation of your code is that you have a couple of suspect terms in your local matrix assembly. In particular, the terms of this form

1/2/phiscale*(u_j_y-v_j_x)

do not compute to what you think they do. The compiler will read this from left to right, and the first operation it sees is an integer divided by an integer. Integer division in C++ will return the value of the quotient rounded down (towards zero, if positive). There’s a more detailed explanation here:

https://stackoverflow.com/a/3602857

So these terms always compute zero! Here’s a short example if you need further proof (looks at the debug output in the central column):

https://godbolt.org/z/XJZ59h

So what you need to do to fix this is to use operator precedence to make sure that you’re always performing division with floating point numbers, or (IMO the preferable solution) explicitly specify the factor 1/2 as a floating point value, either by writing it as 1.0/2.0 or just 0.5.

I’ve got no idea if this is the only source of error in your code, but its certainly not helping you :-) Good luck in sorting this out!

Best,

Jean-Paul

On 25 Jul 2019, at 16:10, Félix Bunel <bunel...@gmail.com> wrote:

One final remark for today, if I remove the two asymmetrical terms in my equation so it becomes :

<Auto Generated Inline Image 1.png>

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/a984ed95-fa81-4758-bc46-1357ec5ce2b5%40googlegroups.com.
<Auto Generated Inline Image 1.png>

[Daniel Arndt]

Felix,

Jean-Paul's answer might already have solved your problem. Anyway:

I'm not sure to understand how to manufacture a solution for my problem. I have read step 7 a few times and I understand but for a coupled system like mine, I don't see how to do it.

Should I choose a solution with u and v that already respect the icompressibility equation ?

Yes.

Should I keep the same phi or change it for another one ?

If you want to see that you represent the solution exactly, you might want to adapt the polynomial degree of your ansatz space to match the one of phi.

 

Should I keep the same boundary conditions (everything = 0) on the sides ?

Yes.

Best,

Daniel

[Félix Bunel]

Okay. When I read you e-mail I sincerely hoped it wasn't the problem. But it was. Now the results match. I feel so so stupid. Such a rookie mistake. I already made this mistake 3 years ago and forgot about it.

Thank you very much for taking the time to look through this part of the code. I own you big time.

Thank you also Daniel for helping me. I will still try a manufactured solution to learn about this process.

Thanks also to everyone that contributed to dealii. Its the perfect library for people that are not as stupid as me.

To unsubscribe from this group and stop receiving emails from it, send an email to dea...@googlegroups.com.

[Jean-Paul Pelteret]

Hi Felix,

Okay. When I read you e-mail I sincerely hoped it wasn't the problem. But it was. Now the results match.

That’s great that this was an easy fix! I’m glad that you can now move along with your problem :-)

I feel so so stupid. Such a rookie mistake. I already made this mistake 3 years ago and forgot about it.

Well now, I bet each one of us has who has been in the C++ game for a while carries around a list of “obvious” mistakes that they first look for when evaluating their own or someone else’s code. Don’t be too upset about this. I’d be embarrassed to admit how many times I’ve been tripped up by (what turn out to be) trivial errors. The important thing is to learn from it and try your hardest not to do it again!

Thank you very much for taking the time to look through this part of the code. I own you big time.

Thank you also Daniel for helping me. I will still try a manufactured solution to learn about this process. 

You’re very welcome. I only had a couple of minutes to help, so its entirely coincidental that my contribution happened to be the one that assisted you the most. I pass the owed favour over to Daniel, who spent a lot more brain power thinking about your problem than I did. And I think that there’s certainly something to be learned about implementing a manufactured solution, so go for  it!

Thanks also to everyone that contributed to dealii.

Its always a delight for us to hear that the users of the library are happy with it. Thank you for your nice compliment! We hope that in the future you’ll also be on the contributors list, with either a little patch or hopefully something more!

Its the perfect library for people that are not as stupid as me.

Seriously, don’t be too hard on yourself. We’ve all made (and will continue to make) these sorts of mistakes from time to time :-)

Best,

Jean-Paul

To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/f887ca46-262f-4805-8b94-ef68341cb455%40googlegroups.com.