[petsc-dev] questions on new include organization

[Matthew Knepley]

On Wed, Feb 13, 2013 at 8:40 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Regardless of exactly how this shakes out I think you both have to agree
> that PetscSection is a bit of an oddball and it should be more "integrated"
> with the "IS stuff" in that we have a single source code location
> (directory) and set of concepts related to indexing things. And don't have
> some in the Vec directory.
>
>    So, for now, I won't change names or functionality but would like
> permission to move source around. Who knows, maybe in the end the is
> directory will get a more suitable name.
>

Yes, I completely agree with the move. There is really only one file right
now.

   Matt


>    Barry
>
> As you know I really really like having names that convey connections left
> to right, KSPGMRES, PC_ILU  etc. I think this helps make the learning and
> understanding curve lower. Now people see IS and PetscSection and they are
> two completely unrelated things to their eyes but in fact they are not
> unrelated and I would like to convey that somehow in the future.
>
> BTW: I consider it a terrible tragedy that in (for example C++ and Java)
> one can define a subclass of a class and just use a completely arbitrary
> ASCII name for the subclass completely unrelated to the class it is derived
> from, talk about losing information.
>
>
> On Feb 13, 2013, at 6:40 AM, Matthew Knepley <knepley at gmail.com> wrote:
>
> > On Wed, Feb 13, 2013 at 12:45 AM, Jed Brown <jedbrown at mcs.anl.gov>
> wrote:
> >
> > On Tue, Feb 12, 2013 at 11:34 PM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >  Is it? Maybe a more general definition of PetscSection would be better
> as map from (int) -> IS   Matt's current usage is very restricted to only
> contiguous blocks of elements in a group. Need that be it? Should that be
> it?
> >
> > There is some hackery to ascribe "field" structure to the output of the
> map, but I'm skeptical of whether it belongs at this level.
> >
> > The granularity is normally very small so we certainly don't want to pay
> the memory or performance overhead of an IS for each output. Although I'm
> sure we can think up scenarios where that flexibility would be useful, I
> think generality in the outputs here would add significant complexity with
> limited practical return.
> >
> > Note that PetscSection is currently accessed using function calls in
> inner loops. This already accounts for a noticeable amount of time for a
> CFD application. So we either need a coarser grained access API or we need
> a non-polymorphic accessor for use in hot access sites. (This is a rare
> case where indirect function call overhead matters.)
> >
> > I think its helpful to look at the one universal use case right now:
> >
> >   You would like to describe a function over a mesh, so
> >   associate functions with each part of the mesh and
> >   store coefficients of these functions.
> >   This happens for:
> >     mesh geometry
> >     PDE solutions and auxiliary fields (like viscosity)
> >     the mesh itself (the adjacency is a field over the points)
> >
> > The inner loops Jed is referring to are structured like this
> >
> > VecGetArray(sol, &solArray);
> > Loop over pieces (like cell, face, etc.)
> >    Get solution on this piece:
> >      PetscSectionGetDof(solSection, piece, &dof),
> PetscSectionGetOffset(solSection, piece, &off)
> >      pieceArray = &solArray[off];
> >      Jed condenses this to DMPlexPointLocalRead(solDM, piece, solArray,
> &pieceArray)
> >
> > Thus this adds structure to the Vec sol by breaking it into irregular
> pieces. The lower level
> > function Dof/Offset() are definitely necessary so you can reason about
> the operations. I think
> > you could get away with only the array offsetting being fast, but I
> don't see how you make that
> > fast and those slow.
> >
> > Barry: > Is it? Maybe a more general definition of PetscSection would be
> better as map from (int) -> IS   Matt's current usage is very restricted to
> only contiguous blocks of elements in a group. Need that be it? Should that
> be it?
> >
> > I think you are missing the point here. I use this all over the place.
> This is PetscSection+IS. You put your
> > non-contiguous indices in the IS and index into it using PetscSection.
> PetscSection is the composable part
> > of this indexing-by-groups. It can be combined with IS or Vec or
> anything. I think it is the right building block.
> >
> >    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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130213/cd00490c/attachment.html>