Improve Fluids boundary condition prescribing options

[jrwrigh]

Stemming from this comment:

At some point, we may want to reflect on making our options orthogonal, and maybe -bc_inflow 1 -bc_inflow_stg 2 to apply fluctuations on one surface, but laminar on the other.

I'd like to move to more generic boundary condition definitions, though it'd be a significant change, so I'd want to get some feedback/thumbs up before really going at it. I've honestly been thinking about changing it for awhile now.

General Idea

Effectively, rather than have dedicated flags for each bc type, (ie. the bc_{inflow,outflow,freestream,wall,slip} flags), group faces into generic BC definition structures. This is more similar to how PHASTA defines it's boundary conditions (though I'm not the most knowledgeable when it comes to the details for how that's done).

The end result is something that's more composable than what we currently have. I've divided my idea into a UI and Backend implementation, which can be implemented independently. The UI might be difficult to implement, as I don't know how flexible PETSc's Options Database is. I think the Backend would be a fairly straight forward and simplify the code a decent bit, particularly when it comes to trying out different BC combinations.

User Interface

So the user interface would be something like:

bcs:
  - faces: 1,2
    type: problem_inflow

  - faces: 3,4
    type: custom
    strong: stg #(or could be constant)
    strong_components: 1, 2, 3
    weak: constant
    weak_components: 4
    weak_temperature: 288

  - faces: 5
    type: custom
    strong: constant
    strong_components: 1, 2, 3, 4
    strong_state: 0, 0, 0, 288 # No-slip wall + specified temperature
    weak: consistency_integral

I'm know this is valid YAML, but I'm not sure how PETSc would interpret the sequence of sets of key-value pairs into it's options database (if it even can do that, as I'm not sure how it'd translate onto command line). At a minimum, it conveys the general idea:

• Have a list of BC definitions
• type can be either a problem defined BC, periodic, or custom
• type: custom can define out specific implementations of strong and weak enforcement

Backend

In the code itself, we'd have enums for the different options and a BCDefinition struct that would contain all the data needed for the boundary condition setup:

// Already implemented in code, here for clarity
typedef struct {
  CeedQFunctionUser    qfunction;
  const char           *qfunction_loc;
  CeedQFunctionContext qfunction_context;
} ProblemQFunctionSpec;

typedef enum {
  CUSTOM,
  PROBLEM_INFLOW, // Problem's default inflow
  PROBLEM_OUTFLOW, // Problem's default outflow
  PERIODIC, // Only allows weak QFs
} BoundaryConditionType;

typedef enum {
  STG_STRONG,
  SLIP,
  STRONG_CONSTANT,
  //etc. .....
} StrongBCs;

typedef enum {
  FREESTREAM_HLL,
  FREESTREAM_HLLC,
  STG_WEAK,
  CONSISTENCY_INTEGRAL,
  WEAK_CONSTANT,
  //etc. .....
} WeakBCs;

typedef struct {
  BoundaryConditionType bc_type;
  StrongBCs             strong_type;
  WeakBCs               weak_type;
  ProblemQFunctionSpec  weak_qf;
  ProblemQFunctionSpec  strong_qf;
  PetscInt              num_strong_comps;
  PetscInt              strong_comps[5];
  CeedScalar            strong_state[5];
  // It'd be nice to make ^^this^^ a State, but that may open a can of worms
  PetscInt              num_weak_comps;
  PetscInt              weak_comps[5];
  CeedScalar            weak_state[5];
  // It'd be nice to make ^^this^^ a State, but that may open a can of worms
  PetscInt              num_faces;
  PetscInt              faces[];
} BCDefinition;

Then instead of having separate code for inflow, outflow, and freestream QF setup (in addition to the other boundary condition setups), we'd just have a loop over each BCDefinition, which would then setup the requirements. We might need to have multiple loops over BCDefintiion (for example, we'd probably want to set up the PETSc strong boundary conditions before setting up the Boundary QFunctions).

[jedbrown]

Thanks for writing this all out. What would you think of doing what Ratel does for multiple materials. It would look like

bc: farfield,viscous_inflow,viscous_outflow,insulated_wall
farfield:
  faces: 1,2
  type: freestream
viscous_inflow:
  faces: 3,4
  type: stg
  stg:
    weak_temperature 288
viscous_outflow:
  faces: 5
[...]

where the arguments like farfield have no intrinsic meaning to the application. I think we shouldn't need an enum, just a PetscFunctionList to register each of the BC types.

[jrwrigh]

That would actually work quite well!

[jrwrigh]

Note: It'll also be nice to have the existence and size of jac_data be dependent on each boundary QFunction. This will alleviate the "store zeros" solution to the issues found in #1420.

Possibly also name the data as "stored" data to be more generic? Probably unnecessary...