<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><br></div></div></div></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 17 janv. 2022 à 17:19, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jan 17, 2022 at 10:49 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thibault Bridel-Bertomeu <<a href="mailto:thibault.bridelbertomeu@gmail.com" target="_blank">thibault.bridelbertomeu@gmail.com</a>> writes:<br>
<br>
> Sorry I wasn't clear I think.<br>
> I was thinking that for finite volume codes, you have two options: either<br>
> you use ghost cells that you fill up with the appropriate primitive state<br>
> for the boundary condition, or you directly enforce the boundary condition<br>
> at the face.<br>
> In the PetscFV examples, the DM_BC_NATURAL_RIEMANN type of boundary<br>
> condition with ghost cells is always used, but what about _not_ generating<br>
> the ghost cells and using a DM_BC_ESSENTIAL to enforce the boundary<br>
> condition directly at the face (or at the quadrature points on the face if<br>
> you will) ?<br>
<br>
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.<br></blockquote></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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. </blockquote></div></div></blockquote><div><br></div><div>That also can be worked around by upwinding the reconstruction schemes - it's unpleasant work, but it can be done :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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</div><div>design because it seemed more complex than ghost cells and did not seem to have any advantages. </div></div></blockquote><div><br></div><div>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 !</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>For multi-domain things, wouldn't you require that the cell average of</div><div>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</div><div>addition.</div></div></blockquote><div><br></div><div>Well I think you read my mind. </div><div>My question is indeed still in the context of the thread I started last week about multi-physics stuff.</div><div>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 ...</div><div>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.</div><div>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.<br></div><div>(By the way Matt the MR 4717 you asked me to check works well, thanks !)</div><div><br></div><div>Thanks for your feedback, </div><div>Thibault</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div></div>