dealii / dealii

The development repository for the deal.II finite element library
https://www.dealii.org
Other
1.37k stars 744 forks source link

Periodic boundary with value jump? #12179

Open QiaoLei-88 opened 3 years ago

QiaoLei-88 commented 3 years ago

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.

masterleinad commented 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.

QiaoLei-88 commented 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;

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.

bangerth commented 3 years ago

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.

QiaoLei-88 commented 3 years ago

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.