On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
> 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. > ;-) Everything is an IS. I suspect that this means that the Set/GetCone, > I think these just return a range or (offset,size). > Set/GetClosure operations > 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. > 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 > I think these are DMCompletVecGet/SetClosure. > > Setting Values is good, but getting values is needed too! > > 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? > I think you would get an index set for those points on the feature you wanted to do something special for. > 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. > 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/d04a3fd5/attachment.html>
