Sent from a handheld device.
On Nov 10, 2012, at 12:38 AM, "Jed Brown" <jedbrown at mcs.anl.gov<mailto:jedbrown at mcs.anl.gov>> wrote: On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin <bourdin at lsu.edu<mailto: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/fb0588ca/attachment.html>
