On Feb 24, 2012, at 3:13 PM, Matthew Knepley wrote: > On Fri, Feb 24, 2012 at 3:05 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Feb 24, 2012, at 2:41 PM, Matthew Knepley wrote: > > > On Fri, Feb 24, 2012 at 2:39 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > On Feb 24, 2012, at 2:23 PM, Jed Brown wrote: > > > > > We need a richer field interface. Some way for a client of DM to discover > > > vector and tensor structure. > > > > No idea what a tensor is, but DMGetSubDMS(dm,PetscInt *cnt,IS *ises,DM > > *dms); and DMPushSubDMType(DM,"name of a type of splitting like u,v,p or > > velocity,p"); DMPopSubDMType(); and DMGetAvailableSubDMTypes(DM,char **); > > > > Do you need more than that? > > > > Yuck Yuck Yuck. Why are we persisting in shoving all of the index stuff > > into the DM interface. I think this is so > > unwieldy and complicated. PetscSection is small, powerful, and does > > everything suggested and more. I see > > no argument in support of stuff like the above. > > I have no idea what a PetscSection is and > > PetscSection - This is a mapping from DMMESH points to sets of values, which > is > our presentation of a fibre bundle. > > doesn't help explain it. PetscSection is small? It has more methods than > DM, that is not small. > > Don't make me return the count. It has fewer, and definitely fewer concepts. > Most of those are > simple get/set. > > PetscSectionGetFieldComponents() seems to be intuitive, cool. By why does it > return an array of integers? The universal way in PETSc would have it > returning an IS. Wait a minute, it returns one int, the number of components? > Then why is called GetFieldComponents and not GetNumFieldComponents() > > It could be changed to GetNumFieldComponents. > > And what is all this constraint stuff? PetscSectionGetConstraintDof() Huh? It > looks inside the "section" and gets an array of ints from a section inside > the section? > > Yes. It keeps track of constrained dofs. People, who through laziness or > willful blindness, refuse to acknowledge that some > problems make more sense when constrained dofs ar eliminated. > > Here's my guess: a PetscSection is way of "chopping up" a canonical vector > into a bunch of fields. Fine, but then why does it have a bunch of other > stuff in it (like constraints, what the hell are constraints)? And why isn't > a PetscSection just an array of IS that define the fields? > > Constraints are just that. IS is designed to be immutable. Building on it > internally is not a good idea for this reason. > > The reason to shove all the index stuff into the DM interface is because > generally one doesn't just want to know the entries of a field but one also > wants to create vectors for those field variables only, create matrices, know > something about the mesh for that field so one can generate interpolations > and coarsen for multigrid. One cannot do any of those things with > PetscSection. > > Yes you can.
Hmm, I guess I haven't pulled recently. I don't see a PetscSectionGetInterpolation() a PetscSectionCoarsen() a PetscSectionGetGlobalVector() etc etc. > > Please explain in freshman linear algebra what a PetscSection is. > > Exactly what it says in the help. It is a mapping from mesh points (vertices, > edges, faces, cells) to dofs. How can this be easier? Say I want an IS that represents all the cell center dofs, how do I obtain that from a PetscSection? I don't see the functionality for that but it seems the most basic kind of thing needed. Barry > > Matt > > > Barry > > > > > > > > > > Matt > > > > Barry > > > > Note that current DMDA's default subdms served up would be a DM for each > > field consisting of one of the degrees of freedom per node and it could > > also serve up DMs that represent any collections of those for example dof > > 0 and 1 per node, then dof 2 per node. We'll need to come up with some > > naming convention for these. > > > > > > > Possibly also (eventually) a way to solve equations of state so that we > > > can formulate reduced problems in non-conservative variables. > > > > > > On Feb 24, 2012 2:19 PM, "Matthew Knepley" <knepley at gmail.com> wrote: > > > On Fri, Feb 24, 2012 at 1:58 PM, Jed Brown <jedbrown at mcs.anl.gov> > > > wrote: > > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/518ff70e8a0a > > > > > > Matt, I want to get rid of these conditionals, not add more. We should > > > have a DM base interface for getting fields on which to split, that > > > common interface should _replace_ the DMComposite specialization. > > > > > > I agree. However, I won't put anything in until I do it by hand once. > > > > > > Also, I was tempted to just promote DMGetGlobalISes(), but its not quite > > > right. I am planning > > > to put the IS method in PetscSection. I am hoping eventually DMDA uses > > > PetscSection for > > > layout. > > > > > > Matt > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > > > > -- > 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
