Wanted: a more flexible mechanism for specifying boundary conditions

[jeff-cohere]

We are now in a position where we need to specify different boundary conditions on different surfaces within a domain. Here's a proposal for allowing this using command-line options (with easily-imagined extensions to the library).

TDycore should accept one or more -bc arguments, each of which sets a boundary condition on a single surface. The format of the proposed argument is:

-bc BOUNDARY:BC_NAME[:BC_ARG]

where BOUNDARY refers to a named sideset/DMLabel found within a mesh, BC_NAME is the symbolic name for one of our boundary conditions, and BC_ARG is an argument (if needed) that specifies the boundary condition.

The boundary conditions we support are named the following way:

• noflow: this specifies that the flow velocity is zero on the given boundary. No argument is needed.
• seepage: this specifies a seepage boundary condition on the given boundary. No argument is needed, since the seepage condition uses data from the cells on either side of the specified boundary.
• pressure: this specifies a Dirichlet boundary condition on the pressure field. It accepts one argument, which is either the numeric value of the pressure [Pa], or the name of a function that supplies the pressure as a function of the spatial position (and possibly other context-dependent information).
• temperature: this specifies a Dirichlet boundary condition on the temperature field for non-isothermal flows. It works the same way as the pressure field, with numeric values specified in K.

If no boundary condition is set on a surface identified within the mesh, a noflow boundary condition is assumed.

Unless I'm missing something, this syntax allows us to completely specify boundary conditions for a domain with surfaces specified in its mesh file. This means we can get rid of the existing boundary-condition-related arguments, which assumed a single boundary condition for each of the flow velocity, pressure, and temperature fields.

[jedbrown]

An alternative that we do in Ratel: https://ratel.micromorph.org/doc/using/#command-line-options

So you'd write something like -bc_noflow 1 -bc_pressure 2,3 -bc_pressure_2_value 1.01 -bc_pressure_2_function my_pressure_func

[jeff-cohere]

Sure, that works too. I'm not married to any particular syntax. @bishtgautam, do you have a preference? And should anyone else weigh in?

[bishtgautam]

We can borrow Ratel's approach rather than inventing our own. But, I guess we will need an additional command-line argument to identify the region for the boundary condition:

-bc_noflow 1 \
-bc_noflow_1_region <region_name> \
-bc_pressure 2,3 \
-bc_pressure_2_value 1.01 \
-bc_pressure_2_region <region_name> \
-bc_pressure_3_function my_pressure_func \
-bc_pressure_3_region <region_name>

[jeff-cohere]

If I understand this correctly, the "regions" (or surfaces/interfaces, really) are identified by the numbers, so we'd need something like

-bc_region_1 <region_name> \
-bc_region_2 <region_name> \
-bc_region_3 <region_name> \
-bc_noflow 1 \
-bc_pressure 2,3 \
-bc_pressure_2_value 1.01 \
-bc_pressure_3_function my_pressure_func

[jedbrown]

Oh, the regions above are the numbers 1, 2, which are values on the Face Sets label. There's an issue to have names for those values. https://gitlab.com/petsc/petsc/-/issues/689

[jedbrown]

If you want an alias for a group of numbered face sets, you could do it without the above issue as

-bc_sets coast,divide
-bc_coast 1,3,4,7
-bc_divide 2,5,6
-bc_pressure divide,coast
-bc_pressure_divide_value ...

[bishtgautam]

We can go with the labels of face sets instead of the names of the regions.

[jeff-cohere]

Just a reminder to myself that face sets are made available in a DMLabel named "Face Sets", and that the indices of the face sets can be retrieved using DMGetLabelIdIS.

[jeff-cohere]

I started working on this a while back in this branch and then a whole lot of changes came in from other directions. That said, I think the approach I was following will probably still work. We do need to add a time parameter to the boundary condition function signature and to the corresponding EnforceXBC functions.

[jeff-cohere]

I've restarted this work in the jeff-cohere/better-bcs-2 branch.

[jeff-cohere]

Just some notes here to myself:

• Multiple boundary conditions on multiple face sets are only supported for the two-point flux approximation for now
• For other methods, a single boundary condition is enforced on faces belonging to the "boundary" label automatically created by DMPlexMarkBoundaryFaces.