Open QiaoLei-88 opened 3 years ago
The purpose of GridTools::collect_periodic_faces
is to identify faces you want to join and not so much to prescribe how constraints are realized; that's what DoFTools::make_periodicity_constraints
is for.
It's correct that DoFTools::make_periodicity_constraints
only applies homogeneous constraints and thus no value jumps. Depending on the use case, it might be pretty straightforward to modify the constraints created by that function accordingly without introducing more functionality to deal.II.
That being said, you're welcome to contribute a new function that can deal with value jumps. I think the output of GridTools::collect_periodic_faces
can also be used for that.
The purpose of
GridTools::collect_periodic_faces
is to identify faces you want to join and not so much to prescribe how constraints are realized;
I agree. But the boundaries of periodic pair are not necessarily geometrically identical to each other. The boundary geometry might be nonlinearly stretched.
It's correct that
DoFTools::make_periodicity_constraints
only applies homogeneous constraints and thus no value jumps. Depending on the use case, it might be pretty straightforward to modify the constraints created by that function accordingly without introducing more functionality to deal.II.
Good idea. I think this is enough for my problem at hand.
On 5/12/21 6:13 AM, Lei Qiao wrote:
I agree. But the boundaries of periodic pair are not necessarily geometrically identical to each other. The boundary geometry might be nonlinearly stretched.
In that case you need a different approach than trying to match DoFs as these functions do. If you have boundaries where faces don't match, you probably want to enforce something like Proj(u_1 - u_2) = 0 with some projection operator as a constraint, but that's a non-local constraint in general. A typical way to do that would be to add a penalty term like when you impose boundary conditions weakly. That is, in the same spirit as one imposes Dirichlet boundary conditions for DG schemes.
In that case you need a different approach than trying to match DoFs as these functions do. If you have boundaries where faces don't match,
In the supposed condition, the faces don't match in Euclidian space but match in topology space, i.e., the face sequence is preserved between two boundary but face sizes vary.
So DoFs on each side of the periodic boundary are also 1-1 matched, if they have the same kind of FE.
For this case, the current code has get almost everything done (match faces, extract matched dofs and setup constrains), only except 1) match faces with Euclidian coordinates (I am not sure since I have not check the implementation of collect_periodic_faces
yet. ) 2) the projection operator(i.e., values of the entries in the result constraint matrix) is limited.
I think this framework is a good start point to make the function more flexible.
A typical way to do that would be to add a penalty term like when you impose boundary conditions weakly. That is, in the same spirit as one imposes Dirichlet boundary conditions for DG schemes.
I understand, this is the most general case, even valid for boundaries with different number of faces and DoFs. In this case, it is not easy to setup a dof-to-dof constraint, but have find out relevant dofs with more general space search method such as kd-tree or rtree. This case goes beyond the topic of "periodic" boundary, I think.
Now I am dealing with a problem that need to set a value jump across a pair of periodic boundaries.
However, according to my understanding, the
DoFTools::make_periodicity_constraints()
function could provide constraints with value scale but cannot specify value jump.If I am right, I would like to implement this interface.
Moreover, I think the most general way is to accept a user defined function (not necessarily linear) that mapping vector(dofs_per_face) to vector(dofs_per_face). From this point of view, the affine mapping interface provided by
GridTools::collect_periodic_faces()
is still not general enough.