Skip to content

Boundary condition improvements #64

@TimothyEDawson

Description

@TimothyEDawson

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions