Boundary conditions

AMReX-Hydro uses underlying AMReX functionality in implementing boundary conditions (see AMReX’s documentation section Boundary Conditions). Physical boundary conditions, such as inflow, outflow, slip/no-slip walls, etc. are ultimately linked to mathematical Dirichlet or Neumann conditions. See amrex/Src/Base/AMReX_BC_TYPES.H for common physical and mathematical types.

Mixed Boundary Conditions

Note

This has only been tested in geometries where the Neumann and Dirichlet areas are separated by an embedded boundary, and is not guaranteed to work for other cases.

In addition to the bc types listed in AMReX, mixed boundary conditions can be implemented. To this end, the (EB)Godunov advection routines support position-dependent boundary conditions. The routines accept a boundary condition MultiFab (BC MF), or Array4. The BC MF is a cell-centered (integer) iMultiFab that carries an amrex::BCType in the first ghost cell and must fully specify the BC on all faces. If position-dependent BCs are passed in, they take precedence and the single BC per face BCRecs are ignored. Within Godunov this holds for both the PLM and the PPM face predictions, so use_ppm does not change which boundary condition is applied.

Position-dependent BCs are only read by the (EB)Godunov routines. The MOL, EBMOL and BDS routines use the single BC per face BCRecs only, so HydroUtils::ExtrapVelToFaces and HydroUtils::ComputeFluxesOnBoxFromState abort if a BC MF (or Array4) is passed with advection_type set to "MOL" or "BDS", rather than silently dropping it.

The MacProjector supports mixed boundary conditions by making use of the underlying linear solver’s Robin BC (Boundary Conditions) option. Robin boundary conditions are formulated as \(a\phi + b\frac{\partial\phi}{\partial n} = f\). \(a\), \(b\), and \(f\) are each a cell-centered (real) MultiFab that carries the relevant values in the first ghost cell. All three must be specified on each level with a call to setLevelBC (see Boundary Conditions for usage).

The NodalProjector can support mixed boundary conditions through the use of an overset mask (see Boundary Conditions). The overset mask specifies a Dirichlet BC with 0 (meaning no solve is needed since the solution is known) or Neumann with 1 (meaning do the solve). Note this is an integer (not bool) MultiFab, so the values must be only either 0 or 1.

Advective BC details

Domain boundary conditions affect the pre-MAC extrapolated velocities in three ways.

  1. Potential impact to the slope computation in cells adjacent to the domain boundary (see Slopes section).

  2. Direct enforcement of the boundary condition: If the face is on a domain boundary and the boundary condition type is

    • External Dirichlet (extdir): on the low side, we set \(u_L\) to the boundary value, and then for the normal component of the velocity only, we set \(u_R = u_L\) (on the high side, \(u_R\) is set to the boundary value and, for the normal component only, \(u_L = u_R\)). This is done because for turbulent inflow, there can be times when the inflow face actually has outflowing velocity. In this case, we want to use the normal component as specified by the BC, but then allow that outflowing velocity to transport values that come from the interior.

    • Direction-dependent (direction_dependent): if the face velocity is inflowing, this bc is identical to extdir; if the face velocity is outflowing, this is equivalent to foextrap.

    • First-order extrapolation (foextrap), higher order extrapolation (hoextrap), or even reflection about the boundary (reflecteven):

      • on the low side of the domain, we set \(u_L = u_R.\)

      • on the high side, we set \(u_R = u_L.\)

    • Odd reflection about the boundary (reflectodd) , we set \(u_L = u_R = 0.\)

  3. To prohibit back flow into the domain at an outflow face (foextrap or hoextrap mathematical BCs):

    • on the low side, we set \(u_L = u_R = \min (u_R, 0).\)

    • on the high side, we set \(u_L = u_R = \max (u_L, 0).\)

For the post-MAC edge state,

  1. Same as pre-MAC

  2. Same as pre-MAC, except that at a direction_dependent face where \(u^{MAC}\) is inflowing, both \(s_L\) and \(s_R\) are set to the boundary value for all quantities, not only for the normal component of the velocity.

  3. Here, we do not impose the no-inflow-at-outflow condition quite as described above; instead we enforce that if \(u^{MAC}\) on an outflow face is inflowing, the normal velocity component must be outflowing or zero. We do this by imposing

    • on the low side, if \(u^{MAC}\ge 0\) (i.e the flow is coming in at an outflow face) and \(s\) is the x-velocity, then \(s_L = s_R = \min(s_R,0).\)

    • on the high side, if \(u^{MAC} \le 0\) on the domain face, then \(s_L = s_R = \max(s_L,0).\)

Note

Boundary conditions are imposed before the upwinding described in the Advection schemes section.

Note

The allow_inflow_on_outflow flag switches off the no-inflow-at-outflow clamp in both of the lists above, so that a MAC velocity that is inflowing at a foextrap or hoextrap face is carried through. It is honoured by Godunov, EBGodunov, MOL, EBMOL and BDS, both pre-MAC and post-MAC.

API documentation can be found in the Doxygen Technical Reference, functions SetExtrapVelBCsLo, SetExtrapVelBCsHi, SetEdgeBCsLo, and SetEdgeBCsHi.