Mesh deformation boundary conditions are unclear in some cases

[gassmoeller]

One more issue about mesh deformation, discovered in #6850.

The boundary conditions for the mesh deformation laplace equation are clearly set for boundaries that:

• are in the list of Mesh deformation boundary indicators (in this case we use Dirichlet boundary conditions for the mesh displacement variable)
• are in the list of Additional tangential mesh velocity boundary indicators (in which case we use no flux / tangential boundary conditions)

However, boundaries that are not in these two lists are automatically assigned boundary conditions and not always in an intuitive way. For these boundaries (i) If they are at periodic boundaries they are assigned tangential mesh deformation boundary conditions, or (ii) if they have tangential Stokes velocity boundary conditions they are also assigned tangential mesh velocity boundary conditions. If they are neither, (iii) they are assigned Dirichlet boundary conditions with zero deformation.

(ii) makes sense if you think of box models with tangential velocity boundary conditions at the sides and a free surface. However, (ii) leads to weird results for the bottom of models, where you often have tangential Stokes velocities, but it would be unusual in almost all cases to let the mesh deform laterally. This can in particular also happen for global spherical shell models, with a free surface and tangential bottom boundary. In these models @tiannh7 and I have observed problems in the mesh displacement gmg solver, where the solver gets stuck with very large iteration numbers or requires a lot of time, similar to encountering a null space. Technically there shouldnt be a nullspace for the mesh displacement equation, because the top is constrained, but fixing the bottom with dirichlet boundary conditions fixes the issue for me, and it is the more natural choice anyway.

My suggestion would be to align the boundary conditions for mesh deformation with the boundary conditions for velocity, namely to explicitly force the user to provide boundary conditions at all boundaries, instead of guessing the correct mesh deformation BCs based on the Stokes BCs. Then for every boundary we would prescribe inhomogeneous Dirichlet (=prescribed motion), no-flux Neumann (=tangential motion), homogeneous Dirichlet (=no motion).

Would that be something useful to pursue?

Here is the test case that creates problems with the current boundary conditions and GMG solver (starting from timestep 5):

geoid_freesurface.prm.txt

[tjhei]

My suggestion would be to align the boundary conditions for mesh deformation with the boundary conditions for velocity, namely to explicitly force the user to provide boundary conditions at all boundaries, instead of guessing the correct mesh deformation BCs based on the Stokes BCs.

I think this makes sense.