BUG: Changing boundary condition order results in divergence about firedrake HOT 2 OPEN

Handling boundary conditions in a lid-driven cavity (or I guess a shear-driven cavity like you have here) is actually quite delicate. As specified, the boundary data are discontinuous at the corners.

Let's just consider the top-left corner:

x--x--x--
|    
x  
|
x
|

If you provide a list of boundary conditions, Firedrake applies them in turn. If the "top" (zero) bc is last, then the top-left corner dof will be (0, 0). On the other hand, if the "left" (non-zero) bc is last, then the top-left corner dof will be (0, 1).

This introduces a singularity in the numerical scheme that isn't there in the physical system. To handle this, one needs to treat the singularity somehow (Section 3.3 of this paper has a brief overview of techniques). Probably the simplest numerical approach is to pick a regularisation scheme that replaces the discontinuous data with $C^\infty$ data that is $1$ over most of the left edge and then falls to zero quickly at the corners. For a reasonable choice here (and how to change it as $\text{Re}$ is varied) see eq (6) of Lopez et al. (2017) (their problem is in 3D and drives the $z = 1$ lid, but it should be straightforward to modify for 2D).

Placing the zero Dirichlet boundary conditions last has, from the point of view of implementation, the same effect as this kind of mathematical regularisation. The reason being if we have a function that is one everywhere on the left boundary and decays to zero quickly near the corners, then at the dof that is on the midpoint of the edge near the top-left corner, the function will still be one. If we pick regularised boundary data, interpolating it to the finite element space will give use dof values:

0--x---x
|
1
|
1

Which is exactly the effect obtained by applying the top (zero) data last.

from firedrake.

Thanks for the resources and explanation. It was not clear to me exactly how firedrake was handling the corners.

The application of boundary conditions in turn is not immediately apparent in the documentation for solve.

from firedrake.