The deal.II finite element library has its own mesh generating tools. Perhaps it is easier to use them. However, I have chosen to use Gmsh directly for the following reason. In most of the numerical experiments convergence rates are deduced from convergence tables. To make a convergence table, one needs to solve the boundary value problem on a number of meshes of different degrees of refinement. Let us call them a family of refined meshes. One decent convergence table requires four meshes. The natural way to generate these meshes in deal.II is to use the global refinement option. Refining a mesh three times dramatically increases the amount of degrees of freedom what, in turn, increases the simulation time. This is especially noticeable in three- dimensional problems. For example, if we start with a cube that contains 512 mesh cells and refine it globally three times, the degrees of freedom will increase from 15625 to 7189057 (here the Lagrange finite elements, FE_Q, of the third degree are assumed). It it still possible to simulate this on a desktop computer, but the simulation time is somewhat long. For this reason, I decided to generate meshes by using Gmsh directly. This approach allows to increase the amount of cells at a more moderate rate (when compared to the global refinement) and decrease the simulation time. This direct approach yields 79507 degrees of freedom instead of 7189057 under the same conditions. Both mesh refinement methods yield the same convergence rates if applied to simple domains. The main idea of the direct approach is to gradually increase the amount of nodes on transfinite lines instead of increasing the amount of mesh cells four times in two- dimensional meshes and eight times in three- dimensional meshes with each global refinement. For instance, the mms/gmsh/square.geo file describes a square:

r = 9; //@1
 
a = 1.0;
 
Point(1) = {0, 0, 0};
Point(2) = {a, 0, 0};
Point(3) = {a, a, 0};
Point(4) = {0, a, 0};
 
Line(1) = {1, 2};
Line(2) = {2, 3};
Line(3) = {3, 4};
Line(4) = {4, 1};
 
Line Loop(1) = {1, 2, 3, 4};
Plane Surface(1) = {1};
 
Q1[] = Rotate { {0,0,1}, {0,0,0},  Pi/2} { Duplicata{ Surface{1};} };
Q2[] = Rotate { {0,0,1}, {0,0,0},  Pi} { Duplicata{ Surface{1, Q1[0]};} };
 
Physical Surface(100) = { 1, 2, Q1[0], Q2[0], Q2[1] };
 
Physical Line(1) = {2, 3, 7, 18};
Physical Line(2) = {8, 12, 13, 17};
 
Recombine Surface "*";
 
Transfinite Surface "*";
Transfinite Line "*" = r; 

The mesh generated by Gmsh will be a square with nine (r=9) mesh nodes on each side of the square. By varying the parameter r, i.e., r=9,10,11,12, we can gradually increase the amount of mesh cells. To do this, we need to generate four identical geo files that differ in one line only: the line that contains the parameter r. These four files can be generated automatically by the script root/shared/scripts/clone. It is linked to the gmsh/ directory. The gmsh/build script makes the call:

./clone -d 2 -f square.geo -r 9 1 12

The clone script will generate four geo files in the geo/data directory (square_r9.geo, square_r10.geo, square_r11.geo, and square_r12.geo) and will feed them to the Gmsh, so the corresponding msh files will appear in the data directory as well. If GNU Parallel is installed on the computer, the meshes will be generated in parallel. The simulation program just needs to open the generated mesh files from the gmsh/data directory one-by-one and run the simulation on each of them. The same cloning trick is done to the three- dimensional meshes.

It must be stressed, however, that the frivolous mesh refinement scheme discussed above produces wrong results in certain circumstances. Allow me to explain. The theoretical methods of predicting the convergence rates presuppose that the family of refined meshes is non-degenerate. The last means that the quality of the mesh cells must remain the same as the mesh is refined. The quality of a mesh cell, in turn, is defined with a help of a parameter \(\rho_n\). In a two-dimensional space this parameter is computed as illustrated in the figure below.

It is always possible to enclose a mesh cell with a circle of a diameter \(h\). Likewise, it is always possible to fit a circle of a diameter \(d\) inside a cell. The parameter \(\rho_n\) is computed as a ratio of the two diameters. The parameter \(\rho_n\) of "body-positive" (meaning the opposite to "skinny") cells is relatively high, see the left cell in the figure above. The skinny cells are low on the parameter \(\rho_n\), see the right cell in the figure above. Suppose we can have calculated the parameter \(\rho_n\) for all cells in a mesh and have picked the minimal value, \(\rho_{min}\). Suppose also that we have computed \(\rho_{min}\) for all meshes in the family of refined meshes. Then the family of refined meshes is considered to be non-degenerate if \(\rho_{min}\) has the same value for all meshes in the family. That is, the "body-positiveness" of the cells must remain as the mesh is refined.

If rectangular mesh cells are refined by the global refinement procedure of deal.II, the parameter \(\rho_{min}\) remains the same implying that the family of meshes is not degenerate. This is not always the case if the frivolous mesh refinement scheme discussed above is used. This refinement scheme can in general produce refined meshes with \(\rho_{min}\) higher or lower than that of the coarse mesh. Strictly speaking, this is a crime: the calculated convergence rates will deviate from their true values. However, I prefer to turn a blind eye to this fact as the gain in the simulation time is enormous. Furthermore, if the coarse mesh is done right, the convergence rates will be disturbed just a little bit, so one can draw all relevant conclusions.

If you are after the precise convergence rates, consider resorting to the global refinement procedure of deal.II on rectangular cells.