<div class="gmail_extra">On Fri, Nov 9, 2012 at 10:20 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2w7">A DM does double duty by describing the geometry of the mesh, and the data layout associated with the finite element space. I liked the model where the mesh geometry and the data layout on the mesh was split in two objects, but I understand the convenience of having everything in the DM, and DMClone works just fine. Since I may have to handle scalar, vector, 2nd and 4th order tensor on 2 different finite element spaces, in an assembly loop, I may end up dealing with as many as 8 DM. I stick all these DM's in the user context of each DM associated with a unknown (a Vec on which I may have to call SNESSolve or TSSolve), hoping that this is not creating some aliasing problem which as  a fortran programmer I can not possibly understand.<br>
</div></blockquote><div><br></div><div>;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2w7">
Everything is an IS. I suspect that this means that the Set/GetCone,</div></blockquote><div><br></div><div>I think these just return a range or (offset,size).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2w7"> Set/GetClosure operations </div></blockquote><div><br></div><div>Closure needs to do orientation, so it's not direct access from the Vec. Regardless, I don't think the plan would be to create an IS for that granularity.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2w7">would return an IS that could be used in VecSetValuesIS, but may not even be needed if an equivalent of  DMMesh' SectionRealRestrict / RestrictClosure /Update / UpdateCLosure is implemented<br>
</div></blockquote><div><br></div><div>I think these are DMCompletVecGet/SetClosure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2w7">
<br>
Setting Values is good, but getting values is needed too!<br>
<br>
Also, in addition to the Barry's simple pseudo-code, I need to be able to get an IS for the i^th dof of a field at a given point (think of applying a Dirichlet boundary conditions to only one component of a field, for instance). It's always been the messy part. How would that fit within the proposed model?<br>
</div></blockquote><div><br></div><div>I think you would get an index set for those points on the feature you wanted to do something special for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2w7">
Finally, just a comment on stratum vs topological dimension. There is no reason why all elements in a mesh should have the same topological dimension. I actually find it much easier to have a single mesh where some sets of elements have codimension 0 and others codimension 1 and dispatching my assembly depending on the physics associated with each block, and the codimension of the element rather than having to deal with side sets / boundary mesh / whatever you want to call it.</div>
</blockquote></div><br></div><div class="gmail_extra">I don't mind that, but can't you have an index set describing the codim 0 elements (maybe all of them) and another index set for the codim 1 elements on the features you care about? You can take their union (or concatenate) for your assembly loop if you like. Is there something wrong with this approach?</div>