This program was contributed by Daniel Arndt and Matthias Maier.
Introduction
In this example we present how to use periodic boundary conditions in deal.II. Periodic boundary conditions are algebraic constraints that typically occur in computations on representative regions of a larger domain that repeat in one or more directions.
An example is the simulation of the electronic structure of photonic crystals, because they have a lattice-like structure and, thus, it often suffices to do the actual computation on only one box of the lattice. To be able to proceed this way one has to assume that the model can be periodically extended to the other boxes; this requires the solution to have a periodic structure.
Procedure
deal.II provides a number of high level entry points to impose periodic boundary conditions. The general approach to apply periodic boundary conditions consists of three steps (see also the Glossary entry on periodic boundary conditions):
Create a mesh
Identify those pairs of faces on different parts of the boundary across which the solution should be symmetric, using GridTools::collect_periodic_faces()
The second and third step are necessary for parallel meshes using the parallel::distributed::Triangulation class to ensure that cells on opposite sides of the domain but connected by periodic faces are part of the ghost layer if one of them is stored on the local processor. If the Triangulation is not a parallel::distributed::Triangulation, these steps are not necessary.
This call loops over all faces of the container dof_handler on the periodic boundaries with boundary indicator b_id1 and b_id2, respectively. (You can assign these boundary indicators by hand after creating the coarse mesh, see Boundary indicator. Alternatively, you can also let many of the functions in namespace GridGenerator do this for if you specify the "colorize" flag; in that case, these functions will assign different boundary indicators to different parts of the boundary, with the details typically spelled out in the documentation of these functions.)
Concretely, if are the vertices of two faces , then the function call above will match pairs of faces (and dofs) such that the difference between and vanishes in every component apart from direction and stores the resulting pairs with associated data in matched_pairs. (See GridTools::orthogonal_equality() for detailed information about the matching process.)
Consider, for example, the colored unit square with boundary indicator 0 on the left, 1 on the right, 2 on the bottom and 3 on the top faces. (See the documentation of GridGenerator::hyper_cube() for this convention on how boundary indicators are assigned.) Then,
Apart from this high level interface there are also variants of DoFTools::make_periodicity_constraints available that combine those two steps (see the variants of DofTools::make_periodicity_constraints).
There is also a low level interface to DoFTools::make_periodicity_constraints if more flexibility is needed. The low level variant allows to directly specify two faces that shall be constrained:
Here, we need to specify the orientation of the two faces using face_orientation, face_flip and face_orientation. For a closer description have a look at the documentation of DoFTools::make_periodicity_constraints. The remaining parameters are the same as for the high level interface apart from the self-explaining component_mask and affine_constraints.
A practical example
In the following, we show how to use the above functions in a more involved example. The task is to enforce rotated periodicity constraints for the velocity component of a Stokes flow.
On a quarter-circle defined by we are going to solve the Stokes problem
where the boundary is defined as . For the remaining parts of the boundary we are going to use periodic boundary conditions, i.e.
The mesh will be generated by GridGenerator::quarter_hyper_shell(), which also documents how it assigns boundary indicators to its various boundaries if its colorize argument is set to true.
The commented program
This example program is a slight modification of step-22 running in parallel using Trilinos to demonstrate the usage of periodic boundary conditions in deal.II. We thus omit to discuss the majority of the source code and only comment on the parts that deal with periodicity constraints. For the rest have a look at step-22 and the full source code at the bottom.
In order to implement periodic boundary conditions only two functions have to be modified:
StokesProblem<dim>::setup_dofs(): To populate an AffineConstraints object with periodicity constraints
StokesProblem<dim>::create_mesh(): To supply a distributed triangulation with periodicity information.
The rest of the program is identical to step-22, so let us skip this part and only show these two functions in the following. (The full program can be found in the "Plain program" section below, though.)
Setting up periodicity constraints on distributed triangulations
void quarter_hyper_shell(Triangulation< dim > &tria, const Point< dim > ¢er, const double inner_radius, const double outer_radius, const unsigned int n_cells=0, const bool colorize=false)
Before we can prescribe periodicity constraints, we need to ensure that cells on opposite sides of the domain but connected by periodic faces are part of the ghost layer if one of them is stored on the local processor. At this point we need to think about how we want to prescribe periodicity. The vertices of a face on the left boundary should be matched to the vertices of a face on the lower boundary given by where the rotation matrix and the offset are given by
The data structure we are saving the resulting information into is here based on the Triangulation.
After we provided the mesh with the necessary information for the periodicity constraints, we are now able to actual create them. For describing the matching we are using the same approach as before, i.e., the of a face on the left boundary should be matched to the vertices of a face on the lower boundary given by where the rotation matrix and the offset are given by
These two objects not only describe how faces should be matched but also in which sense the solution should be transformed from to .
For setting up the constraints, we first store the periodicity information in an auxiliary object of type std::vector<GridTools::PeriodicFacePair<typename DoFHandler<dim>::cell_iterator> . The periodic boundaries have the boundary indicators 2 (x=0) and 3 (y=0). All the other parameters we have set up before. In this case the direction does not matter. Due to this is exactly what we want.
Next, we need to provide information on which vector valued components of the solution should be rotated. Since we choose here to just constraint the velocity and this starts at the first component of the solution vector, we simply insert a 0:
After setting up all the information in periodicity_vector all we have to do is to tell make_periodicity_constraints to create the desired constraints.
The rest of the program is then again identical to step-22. We will omit it here now, but as before, you can find these parts in the "Plain program" section below.
Results
The created output is not very surprising. We simply see that the solution is periodic with respect to the left and lower boundary:
Without the periodicity constraints we would have ended up with the following solution: