There are several improvements I would like to make to the boundary conditions. The following is a list of items to address:
- Inconsistent/confusing terminology:
- Outflows: The "Inflow" and "DirichletInflow" should function just fine as outflows, so we should probably just rename them accordingly.
- May benefit from special treatment of supersonic flows, e.g. by switching to
Extrapolate.
- Boundary types: For many BCs it's not immediately clear from the class name whether a boundary condition sets the ghost cells, face values, or flux directly, e.g.
Extrapolate could mean either ghost cells or face values.
- Initially the idea was that the base class -
GhostCell, RiemannFlux, or SpecifiedFlux tells you this, but that's not information which is easily accessed when writing or reading the code.
- Perhaps including
Cells, Faces, or Flux in each name would help. E.g. ExtrapolateFaces and PeriodicCells.
- Mapping to strings: Need to make sure we have a consistent way to map the common names used as inputs to
set_boundary_conditions to their corresponding objects, noting that they don't necessarily need to match. Enums might be a good option to use.
- Primitive variable-based ghost layers: Some ghost layer boundary conditions may function better through direct manipulation of the primitive variables in the ghost layers, rather than exclusively through modifying the conservative variables.
- Need to consider how this impacts the naming convention, as well.
PeriodicCellsPrimitive and PeriodicCellsConservative gets really clunky.
- WENO scheme treatment:
- For ghost layer based boundary conditions, the WENO scheme should operate normally everywhere, where previously it switched to first-order near boundaries.
- For other boundary types, it's common to either perform a high-order extrapolation into the ghost layers, or set them to be large values with large variations in order to force the WENO scheme to disregard them during the stencil-choosing step (see NASA/CR-97-206253, section 2.3.3. on page 26). This can be essential to ensure the extrapolated values for the first couple interior faces are valid.
- Primitive variable-based ghost layers would help with this as well.
- Additional common boundary conditions to consider adding:
- Isentropic inflow: Computes the inflow from a user-specified total pressure and temperature.
- Mass flow: Sets the inflow/outflow properties to achieve a specified target mass flow rate or mass flux. For inflows, this often requires the total temperature with isentropic flow relations to close the system. For outflows, it may need to fall back to an
Extrapolate condition if the flow goes supersonic.
- Characteristic boundary conditions (NSCBC): More advanced boundaries which allow fine control over reflections by applying locally one-dimensional inviscid (LODI) relations. This is more involved, but could be worth investigating.
- Unit and integration tests: Extremely important for verifying the BCs are functioning correctly. I know how to set up integration tests such as convecting pressure pulses, but I'm not sure how to create unit tests which don't simply mirror the same logic the BCs are using internally.
I plan to work through some of these in sub-issues, and welcome all ideas, feedback, and volunteers!
There are several improvements I would like to make to the boundary conditions. The following is a list of items to address:
Extrapolate.Extrapolatecould mean either ghost cells or face values.GhostCell,RiemannFlux, orSpecifiedFluxtells you this, but that's not information which is easily accessed when writing or reading the code.Cells,Faces, orFluxin each name would help. E.g.ExtrapolateFacesandPeriodicCells.set_boundary_conditionsto their corresponding objects, noting that they don't necessarily need to match. Enums might be a good option to use.PeriodicCellsPrimitiveandPeriodicCellsConservativegets really clunky.Extrapolatecondition if the flow goes supersonic.I plan to work through some of these in sub-issues, and welcome all ideas, feedback, and volunteers!