General wall boundary condition

[dreamer2368]

• WallBC have an option for general wall condition.
  • Thermal conditions for heavy species and electron should be specified in the input file. An example is:

    [boundaryConditions/wall1] patch = 1 type = viscous_general heavy_thermal_condition = adiabatic electron_thermal_condition = sheath

    [boundaryConditions/wall2] patch = 3 type = viscous_general heavy_thermal_condition = isothermal electron_thermal_condition = sheath temperature = 3.0e-1

  • heavy_thermal_condition only takes isothermal and adiabatic. If isothermal, temperature also must be specified.
  • electron_thermal_condition takes isothermal, adiabatic, and sheath.
  • If single-temperature plasma, electron_thermal_condition is only effective for sheath, prescribing diffusion fluxes. Other conditions will be ignored and zero diffusion fluxes will be set.
• WallBC::computeGeneralWallFlux prescribes the boundary condition according to the data-types BoundaryPrimitiveData and BoundaryViscousFluxData.
  • BoundaryPrimitiveData has a Vector prim, which has the same structure as primitive variable. Array<bool> primIdxs specifies which components are prescribed and replaced in boundary flux computation.
  • BoundaryViscousFluxData has a similar structure to BoundaryPrimitiveData, having Vector primFlux and Array<bool> primFluxIdxs. Just as the state variable, boundary condition for viscous flux is also specified with primitives, such as diffusion velocity, stress and heat fluxes. Vector primFlux has the following structure:
  • First numSpecies components: species diffusion velocities
  • Next nvel components: viscous stress
  • Next 1 component: heavy-species heat flux
  • Last 1 component, if two-temperature: electron heat flux
  • GasMixture::modifyStateFromPrimitive and Fluxes::ComputeBdrViscousFluxes replace state or viscous flux with the prescribed boundary conditions. In principle, these can be used for all boundary conditions; however, currently the use of GasMixture::modifyStateFromPrimitive is limited to WallBC::computeGeneralWallFlux to avoid any inadvertent changes in the existing simulations.
  • As multiple species are added and diffusion flux contributes to heat flux, it is not possible any more to prescribe viscous boundary flux only by changing gradUp or the resultant viscous flux. Therefore, Fluxes::ComputeBdrViscousFluxes replaced viscous flux handling of all wall boundary conditions. This did not affect any of the existing DryAir CI tests.
• mms.general_wall.test checks:
  • the consistency of Fluxes::ComputeBdrViscousFluxes compared to Fluxes::ComputeViscousFluxes in any random normal direction
  • the right-hand side errors of the manufactured solutions ternary_2d_ambipolar_wall and ternary_2d_sheath.
  • As the time-integrations of these manufactured solutions significantly increase the test time (mainly due to automatic differentiation), the test instead checks the error of the right-hand side using utils/compute_rhs.
  • Currently utils/compute_rhs shows different convergence behaviors depending on mesh geometry type or basis. It is not clear whether this issue only belongs to utils/compute_rhs or the entire code. Also, it is independent of boundary condition. While this issue will be further pursued in the separate branch compute_rhs, the test uses a verified basis and geometry type (Legendre / quadrilateral element).

[koomie]

@dreamer2368, just a head's up that I have landed some modifications to the CI setup on this branch. In particular, the supporting docker container environment derived from docker/test/Dockerfile will be built automatically when the file is changed and then subsequently used in later tests. The image is hosted by a new account and is available as pecosut/tps_env:latest. I had to refactor things and merge two of our previous workflows so you should only see one top-level CI event kicked off.

It looks to be working ok now and pulls in your updated MASA version. When you are happy with the remaining PR, we can merge.

[dreamer2368]

@koomie , it looks good to me. A question is, when a PR updates the container (presumably as pecosut/tps_env:latest), is this updated container reflected to the main CI test before the merge, or only after the PR is merged? Another way to put it is, do these two branches use the same tag of the container or separate tags specified for each branch?

Regardless of the answer, i think the current PR is sufficient to merge to main.

[koomie]

@koomie , it looks good to me. A question is, when a PR updates the container (presumably as pecosut/tps_env:latest), is this updated container reflected to the main CI test before the merge, or only after the PR is merged? Another way to put it is, do these two branches use the same tag of the container or separate tags specified for each branch?

Regardless of the answer, i think the current PR is sufficient to merge to main.

Once this is landed, the main branch will also use the same container. In the current config, the container is updated by the PR and will should be rebuilt again when it lands on main. In general, it will be the exact same container, so we waste a few minutes doing it again, but this allows you to update the container and test the PR.