[petsc-dev] DMComplex and PCFieldSplit

[Matthew Knepley]

On Fri, Feb 24, 2012 at 3:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> 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.


DMComplexGetHeight(dm, 0, &cStart, &cEnd); /* Get the range of mesh points
which are cells, height is like co-dimension */
numCellDof = 0;
for(c = cStart; c < cEnd; ++c) {
  PetscSectionGetDof(section, c, &dof);
  numCellDof += dof;
}
PetscMalloc(numCellDof * sizeof(PetscInt), &indices);
numCellDof = 0;
for(c = cStart; c < cEnd; ++c) {
  PetscSectionGetDof(section, c, &dof);
  PetscSectionGetOffset(section, c, &off);
  for(d = 0; d < dof; ++d, ++numCellDof) {
    indices[numCellDof] = off+d;
  }
}

   Matt


>   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
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120224/86e0bdf6/attachment.html>