Results

Building and running

To compile and run the program, we cd into the build directory and type the following command:

$ make distclean && cmake .. && make -j8 && ./step-6 ./../param/param.prm

This command will clean up the previous build and generate the makefiles, compile the program, and run the program with param.prm as the input file.

Output with linear elements (degree 1)

We have the following output from the program in the terminal and the error table at cycle 6:

Cycle 6:
   Number of active cells:       81920
   Number of degrees of freedom: 164354
Iterations required for convergence: 690
Norm of residual at convergence: 0.000452667
output_exact_results function is called with exact.vtu
manufactured components number: 2
L2 error = 0.00250619
H1 error = 0.217938
 
cells  dofs          L2                  H1
   20     50 3.548e+00    -    - 9.770e+00    -    -
   80    178 2.035e+00 1.74 0.80 7.448e+00 1.31 0.39
  320    674 5.759e-01 3.53 1.82 3.571e+00 2.09 1.06
 1280   2626 1.480e-01 3.89 1.96 1.754e+00 2.04 1.03
 5120  10370 3.726e-02 3.97 1.99 8.730e-01 2.01 1.01
20480  41218 9.366e-03 3.98 1.99 4.360e-01 2.00 1.00
81920 164354 2.506e-03 3.74 1.90 2.179e-01 2.00 1.00

At each cycle of refinement we print out

the number of active cells,
the number of degrees of freedom,
the number of iterations that the solver took to converge, and
the norm of the residual at convergence.

Then we print out a line to remind the user that the exact manufactured solution (specified in solution.cc) was written to exact.vtu, and the user can view it via a visualization program such as ParaView. We also print out the number of components of the manufactured solution, which should be 2.

We can see that the number of cells quadruples in each cycle, and the number of degrees of freedom is slightly more than two times the number of cells.

Finally, we have also printed out the error table. In the three columns headed by L2:

the first column is the actual $L^2$ error corresponding to each refinement cycle,
the second column is the $L^2$ error rate, i.e. the ratio of the $L^2$ errors between two consecutive refinement cycles, and
the third column is the $\log_2$ of that error ratio.

Similarly, the next three columns give the $H^1$ errors. Since we are using degree-1 (linear) finite elements, we see that the $L^2$ log error rate is roughly $2$ and the $H^1$ log error rate is roughly $1$, which is what we expect from theory.

Output with quadratic elements (degree 2)

When we change the degree of the finite elements to 2 (using quadratic elements), we would expect to see the $L^2$ log error rate to be roughly $3$ and the $H^1$ log error rate to be roughly $2$. To see this in action, we go to the param.prm file and change the line

set Finite element degree = 1

to

set Finite element degree = 2

Then we do not need to recompile the program, which is the benefit of using a param.prm file. Instead of typing the command

$ make -j4 && ./step-6 ./../param/param.prm

we just need the latter part ./step-6 ./../param/param.prm, and we get the following output:

Cycle 6:
   Number of active cells:       81920
   Number of degrees of freedom: 656386
Iterations required for convergence: 1544
Norm of residual at convergence: 0.000893456
output_exact_results function is called with exact.vtu
manufactured components number: 2
L2 error = 0.00146713
H1 error = 0.00432825
 
cells  dofs           L2                   H1
   20    178 1.305e+00    -     - 3.763e+00    -     -
   80    674 1.769e-01 7.38  2.88 1.007e+00 3.74  1.90
  320   2626 2.028e-02 8.72  3.12 2.401e-01 4.20  2.07
 1280  10370 2.553e-03 7.95  2.99 6.015e-02 3.99  2.00
 5120  41218 4.882e-04 5.23  2.39 1.508e-02 3.99  2.00
20480 164354 7.314e-04 0.67 -0.58 4.293e-03 3.51  1.81
81920 656386 1.467e-03 0.50 -1.00 4.328e-03 0.99 -0.01

This matches our expectation, except at cycles 5 and 6 where the number of cells and the number of degrees of freedom become large, and our Conjugate Gradient solver might not be the best performing solver as the number of cycles increases. We would want to try a different solver such as SolverGMRES, which stands for the Restarted Preconditioned Direct Generalized Minimal Residual Method.

Possibilities for extensions

Different solvers

We notice that as the number of refinement cycles increases, the program takes quite a bit more time to run, at least on a laptop. We could potentially try different preconditioners such as

SparseILU<double> preconditioner;

preconditioner.initialize(system_matrix);

which is a simple incomplete LU decomposition without any thresholding or strengthening of the diagonal. (We need to include deal.II/lac/sparse_ilu.h in the header file for this to work.)

Different right-hand sides

Users are free to specify different manufactured solutions and different right-hand sides to the program, and run to see the output. The solution and mesh in each cycle of refinement is saved as a .vtk file in the same build directory where the program is executed, and those files can be visualized using software such as ParaView.