[petsc-dev] DMComplex and PCFieldSplit

[Barry Smith]

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