On Mon, Jan 17, 2022 at 10:49 AM Jed Brown <[email protected]> wrote:
> Thibault Bridel-Bertomeu <[email protected]> writes: > > > Sorry I wasn't clear I think. > > I was thinking that for finite volume codes, you have two options: either > > you use ghost cells that you fill up with the appropriate primitive state > > for the boundary condition, or you directly enforce the boundary > condition > > at the face. > > In the PetscFV examples, the DM_BC_NATURAL_RIEMANN type of boundary > > condition with ghost cells is always used, but what about _not_ > generating > > the ghost cells and using a DM_BC_ESSENTIAL to enforce the boundary > > condition directly at the face (or at the quadrature points on the face > if > > you will) ? > > Essential boundary conditions change the function space in which you seek > a solution. There is no dof at the face in an FV method, so how would you > propose modifying the function space. > > Also, FV methods with higher than first order require a reconstruction > (generally nonlinear) using neighbor cells to create a richer (usually > piecewise linear) representation inside cells. > What you suggest (flux boundary conditions) would require short-circuiting the Riemann solver loop to stick in the flux. It is doable, but we opted against it in the initial design because it seemed more complex than ghost cells and did not seem to have any advantages. For multi-domain things, wouldn't you require that the cell average of the adjacent cell be used as the ghost value for consistency? We would need a new interface to mark existing cells as ghosts, but that is quite simple compared to a flux BC addition. Thanks, Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
