[petsc-users] PetscFV without ghost boundary conditions

[Thibault Bridel-Bertomeu]

Le lun. 17 janv. 2022 à 17:19, Matthew Knepley <knepley at gmail.com> a écrit :

> On Mon, Jan 17, 2022 at 10:49 AM Jed Brown <jed at jedbrown.org> wrote:
>
>> Thibault Bridel-Bertomeu <thibault.bridelbertomeu at gmail.com> 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.
>>
>
There can be dof at the faces actually, higher order FV can also be based
on a quadrature representation that involves extra dof in the cells and in
the faces for accurate integration.


>
>> 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.
>
>
That also can be worked around by upwinding the reconstruction schemes -
it's unpleasant work, but it can be done :)


> 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.
>

OK ! I agree it is more complex, ghost cells are quite straightforward to
use and don't require any extra upwinding of the reconstructions etc ... I
actually mostly also opt for ghost cells in the codes I write, so I
understand your decision !


> 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.
>

Well I think you read my mind.
My question is indeed still in the context of the thread I started last
week about multi-physics stuff.
Actually, if we can mark cells that are actually part of the mesh as ghost
to be used by boundary conditions, then it would be perfect ! I was
thinking how I could do that actually ...
If we think about the same example I have been using so far (a rectangle
split into two distinct domains to represent fluid on one hand and solid on
the other hand) then the ghost cells for the fluid at the fluid/solid
interface would actually be cells located in the solid domain, and those
are the ones we could be marking if you think it's possible ! It would be
about handling the special case of creating ghost cells for faces that
already have two cells on each side I believe.
Anyway for my example, I was thinking of working my way from the "Wall"
label, and identifying for each face in the label, the cells on each side
and put those cells that also belong to the "Solid" label in the "ghost"
label - I don't know if that makes sense.
(By the way Matt the MR 4717 you asked me to check works well, thanks !)

Thanks for your feedback,
Thibault


>
>   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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220117/ea8ba5f4/attachment.html>