<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 26, 2013, at 9:17 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Thu, Sep 26, 2013 at 1:15 PM, Mark F. Adams <span dir="ltr"><<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">><br>
> We have ghost cells in TS ex11, and I think we do them the correct way :) We have a function you register that fills them up, and we<br>
> loop over them explicitly.<br>
><br>
<br>
Well damn Matt, this looks like the right way to do FV in PETSc, regardless of the nice BC abstraction, but am I going to get be seduced and crash into this island and turn into stone? i.e., can stupid people deal with your Sections and Plexes and crap (Barry?).<br>
</blockquote><div><br></div><div>So the important thing here is the organization of the boundary functions. You call</div><div><br></div><div> ModelBoundaryRegister(bdFunc, bdMarker)</div><div><br></div></div></div></div></blockquote><div><br></div><div>OK, I guess I see this as sugar. Don't get me wrong I like sugar. But I will at least keep the infrastructure for Neumann BCs.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>where the function is</div>
<div><br></div><div> PhysicsBoundary_Advect_Inflow(Model mod, PetscReal time, const PetscReal *centroid, const PetscReal *normal, const PetscScalar *xInterior, PetscScalar *xGhost, void *ctx)</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes, I'm comfortable to this point, I just wonder if I'm getting sucked into a morass of topology or something that I did not even think about taking in grad school.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Then we loop over all the mesh pieces marked with each boundary marker, and call the function on those faces. You get the interior</div>
<div>value, and make the ghost accordingly. </div></div></div></div></blockquote><div><br></div><div>I think you are doing the same basic thing that I am used to, where you set the ghost values to satisfy the BCs for the current state, apply an operator of some sort, rinse and repeat ….</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think you would do exactly the same thing in your simple example below. The only optimization</div><div>would be in handling the topology, which you do not see anyway (unless you are a masochist).</div>
<div><br></div></div></div></div></blockquote></div><div><br></div><div>Me a masochist? au contraire :)</div><div><br></div><div>This looks good. I will work on simplifying this example to make a well designed (a la ex11), albeit simple, FV test problem for my current favorite FMG test with an exact solution, and make a converge test out of it. I really need something simple for SR and this is a coarse grid solver. I will ask about SR support when I get there.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><br></div><div><div><br></div><div><br></div><div><br></div></div></body></html>