<div class="gmail_extra">On Sat, Nov 10, 2012 at 11:57 AM, Blaise A Bourdin <span dir="ltr"><<a href="mailto:bourdin@lsu.edu" target="_blank">bourdin@lsu.edu</a>></span> wrote:<br><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">
<div>Yes, but because of the structure of my problem, the application context also contains a link to the original DM.</div>
<div>Think solving F(u,v) = 0 where and v don't have the same layout, or the same dimensionality, without field split.</div>
<div>My iterate is </div>
<div><span style="white-space:pre-wrap"></span>u_{n+1} = argmin_w F(w,v_n)</div>
<div>  <span style="white-space:pre-wrap"> </span>v_{n+1} = argmin_w F(u_{n+1},w)</div>
<div>The DM associated with u is DMu and the one with v is DMv</div>
<div>For the application context, I can either a create AppCtx with components (pointer to u, pointer to v, pointed to DMu, pointer to DMu), or</div>
<div>AppCtxu with components (pointer to v, pointer to DMv) and AppCtxv with components (pointer to u, pointer to DMu)</div>
<div>In this setting, is calling SNESSolve with Vec u and Application Context AppCtx legal, or do I have to use AppCtxu / AppCtxv? </div></blockquote><div><br></div><div>Either is okay (and neither is okay for FAS).</div>
<div> </div><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"><div><div class="im"><div>
</div>
</div><div>Can you point me to an example? Are interfaces C only because nobody has ever needed fortran versions, or is there a technical reason.</div></div></blockquote><div><br></div><div>SNES ex48 does this, also look at any use of DMCoarsenHookAdd(). There is no fundamental issue, it just requires custom function pointer juggling which is messy and really needs to be tested. </div>
<div> </div><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"><div><div> </div></div></blockquote><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">
<div><div class="im"><div>
</div>
</div><div>I had not thought about it, but it is quite feasible. I store all coefficients that are constant per block of cells or Dof in PetscBags, and everything that has variation at the scale of the finite element space in Vecs.  How would the creation of the
 coarse DMs be handled, though? The geometry part is trivial to propagate using DMClone, but you may need to user feedback for the data layout part, unless you have a scheme that describes it (i.e. for this IS of cells, n dof at the vertices, p at the faces
 etc)</div></div></blockquote><div><br></div><div>You get to implement these two callbacks to create and update data for the coarse grid problem:</div><div><br></div><div><a href="http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMCoarsenHookAdd.html">http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMCoarsenHookAdd.html</a><br>
</div><div> </div><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"><div><div class="im"><div></div></div></div>

<div>Do we mean the same by partially interpolated mesh? What I mean is a mesh the only faces that are explicitly stored are the one we are interested in (typically the boundary mesh). For P1 elements, we need only to know of [cells, some faces, vertices].</div>
</blockquote><div><br></div><div>Yup, same thing.</div><div> </div><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">
<div> I
 tried to manually build partially interpolated sieves with only some of the faces, and distribution would fail. That's how I ended up with a mix of cells of co-dimension 0 and 1. If one wants access to ALL faces / edges or none of them, there is no problem
 in the current implementation.</div></blockquote></div><br></div><div class="gmail_extra">Right, I think of this as having a bunch of codim 0 and a few codim 1. As a user, we call Closure, not Cone, so we go directly to the points from either. But we would get the points to loop over by requesting codim 0 and codim 1 separately. I'd expect that in principle, you likely have multiple groups of codim 1 things that get treated differently. Of course you can lump them all in one bigger index set and have an if statement, though it's not as vectorization-friendly so Matt doesn't like that. I would not mind having an interface for requesting points of multiple dimensions at once (codim in {0,1}).</div>