Hi, Let me make sure I understand the consensus, since I have a vested interest in the unstructured mesh business:
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, Set/GetClosure operations 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 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? 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. Blaise On Nov 9, 2012, at 9:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > We have a users manual? > > On Nov 9, 2012, at 8:56 PM, Matthew Knepley <knepley at gmail.com> wrote: > >> On Fri, Nov 9, 2012 at 9:46 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>> >>> On Nov 9, 2012, at 8:42 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: >>> >>>> On Fri, Nov 9, 2012 at 8:39 PM, Matthew Knepley <knepley at gmail.com> >>>> wrote: >>>> You are both right :) I don't care where we put them, but I want BCs >>>> and fields. However, this is no problem. >>>> Right now I do BCs and fields as PetscSections held inside the primary >>>> section. If IS can do what PetscSection >>>> can do, I can jsut use another IS for each one. >>>> >>>> Convergence! >>>> >>> >>> Write it up! :-) >> >> In the manual section on Unstructured Grids :) >> >> Matt >> >>>> >>>> I actually like it where it is. Stick with DMComplexVecGetClosure() >>>> with no section argument, and then >>>> the DM holds an IS++. >>>> >>>> Cool, now the "normal" user doesn't even see the ++IS. >>> >> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which >> their experiments lead. >> -- Norbert Wiener > > -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
