[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

On Sun, Jun 8, 2014 at 3:41 AM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > On Sat, Jun 7, 2014 at 6:01 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> >> Matthew Knepley <knepley at gmail.com> writes:
> >>
> >> > On Sat, Jun 7, 2014 at 5:11 PM, Jed Brown <jed at jedbrown.org> wrote:
> >> >
> >> >> Matthew Knepley <knepley at gmail.com> writes:
> >> >>
> >> >> > As far as I know, neither can do FV stuff which this is going to
> >> >> > do.
> >> >>
> >> >> Where are your Riemann solve, characteristic reconstruction, and
> >> >> boundary conditions interfaces?  You already used the generic
> namespace
> >> >> for a volumetric term that doesn't even exist in FV formulations.
> >> >
> >> >
> >> > Its in PetscFV. PetscProblem is supposed to hold both types. I can
> only
> >> work
> >> > so fast, and I am doing the FEM example first.
> >>
> >> So it's not supported by the PetscProblem interface?
> >
> >
> > I have not had time to code the implementation. The interface is
> > (hopefully) fine.
>
> Where is your Riemann solver interface?  I see
> DMPlexTSSetRHSFunctionLocal which has nothing in its name indicating
> that it is a Riemann solver, has no support for non-conservative systems
> (for which the Riemann solver returns a wave decomposition because
> "flux" is not defined), and cannot support a transverse solve (to double
> or triple the stable time step).  Note that this interface has a
> context, unlike your FE quadrature functions.  (Interface inconsistency
> is evil.)  Also, ex11 does not offer characteristic reconstruction.
>
> I meant for ex11 to be a demonstration of one way to solve these
> problems, but certainly not THE CANONICAL WAY.  I do not agree with
> moving it into PETSc, especially not using a name like PetscProblem.
> I'd rather it be in a separate project (that was the idea with the
> parmod repository, but I don't think you ever used that).


Fine, but what in the FV interface is inappropriate for this. Also, I
distrust the argument
here because some of what you describe is incredibly special-purpose,
namely it will
only work on Cartesian grids, and thus should not determine large parts of
the top
level interface.


> >> >> > Maybe MOOSE does. However, neither of those has good integration
> with
> >> >> > the solver (I have discussed this personally with Roy and Derek and
> >> >> > they agree).
> >> >>
> >> >> You have to be able to formulate a similar scope of problems before
> you
> >> >> get to argue fine points of supporting geometric multigrid and the
> like.
> >> >> FWIW, it does not support the solve structure we use in pTatin so
> gives
> >> >> up significant performance relative to existing packages that use
> solver
> >> >> algorithms you want.
> >> >>
> >> >
> >> > I asked you to help with this.
> >>
> >> I pointed out that your interface can't do that algorithm and I showed
> >> you code that can.  I'm not sure what you want me to do.  Change your
> >> interface to be able to do that method fast, implying other data
> >> structure changes and possible loss of functionality that you want?
> >
> >
> > Of course, there is nothing else to do but point out shortcomings. That
> > makes things easy.
>
> Some problems are not appropriate for a given level of abstraction.  I
> believe you are creating a specialized high-level PDE interface, which I
> consider to be out of scope for PETSc.  Imagine if KSP was only capable
> of solving scalar SPD problems.  "It's so easy to point out
> shortcomings" and yet those shortcomings define a scope that is
> incompatible with the name and not in the spirit of the software
> package.


KSP is of course only for Krylov solvers, and we dump everything else in PC.
There is nothing wrong with limiting the scope of an abstraction to a useful
subset. This is the essence of design, and a small-minded committment to
absorbing everything will dilute the interface to nothing.


> >> >> >> think this belongs in PETSc, definitely not in such prominent
> >> namespace.
> >> >> >>
> >> >> >
> >> >> > I don't know why you think this is so bad. I picked a name because
> I
> >> >> needed
> >> >> > a name. Its not DM, its a collection of DMs.
> >> >>
> >> >> It's a very framework-style name with generic connotations used for
> >> >> something extremely specific.
> >> >
> >> >
> >> > I do not think its for something that specific. It is to hold a
> >> > collection of pointwise evaluation routines + discretizations. What is
> >> > better than "problem"?
> >>
> >> H^1 semi-discrete-in-time quadrature-based method of weighted residuals
> >> without material models or boundary conditions.  "Problem" is way too
> >> generic to be used for something so specific in PETSc.
> >>
> >
> > I do not agree.
> >
> >
> >>
> >> >> >> I also cannot imagine that this interface is stable, so even if
> this
> >> >> >> sort of thing goes into PETSc, there's no use having it in the
> >> release.
> >> >> >>
> >> >> >
> >> >> > We have a bunch of stuff that is not completely stable. I am not
> sure
> >> >> > what this kind of conservatism buys us.
> >> >>
> >> >> Exploratory programming in a release using a prominent namespace will
> >> >>
> >> >
> >> > I think "prominent" here is misguided.
> >>
> >> How else would you describe it?  I suggested
> >> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature().
> >
> >
> > Its not a DM.
>
> You access it via DMGetProblem() and your interfaces are analogous to
> the DM-specific interfaces we have used in the past.
>
> You might recall that we had a discussion a couple years ago about
> whether DM should be a "function space" or should hold the problem
> definition (via callbacks).  I argued for separation and still think
> that unadorned function spaces are useful, but others (especially Barry)
> wanted to limit the number of objects.  And in fact, the physics
> influences things like coarse-space homogenization and grid transfer
> within solver algorithms, so now I mixed opinions about it.  But in any
> case, we made a decision and built code around the DM owning that stuff.
> If you want to fundamentally change that model, it needs to be a
> project-wide decision, implemented consistently across projects.
>
> From the two examples that use PetscProblem, I think the issue is that
> you want it to work with DMDA and DMPlex because the formulation does
> not depend on grid topology, but the naming convention for
> implementation-specific functions uses different namespaces.  But we can
> have DM functions that are implemented by multiple implementations.  So
> maybe this maps to
> DMTSSetIFunctionMattsCoolDiscretizationVolumetricQuadrature().


1) Volumetric here is inappropriate because it supports boundary integrals

2) It is supposed to support both FEM and FVM

3) It is a sub-object, just like PetscLayout, meant to operate is service
of a DM.
     Its never used apart from it, just like PetscLayout and Vec/Mat.
Layout is
     also a generic name, but Layout only supports the simples kind of
partition,
     and thus cannot do more complex things, but we did not have a huge
     discussion about it. I still fail to see how this is a big deal.

    Matt


> >> >> encourage people to try using it, then have a bad experience when it
> (a)
> >> >> does not work for their problem and (b) is changed soon after the
> >> >> release.  I would rather that exploration happen in a different
> package
> >> >> that users can opt into.
> >> >>
> >> >> I like developing library code in PETSc, and often look for ways to
> >> >> formulate a new idea to make it appropriate for PETSc.  But some
> things
> >> >> just make more sense in a separate package.  If there is a technical
> >> >> problem with distributing such a package, we should solve that
> problem.
> >> >>
> >> >
> >> > Its not a lot of code, its very useful for exactly the people that use
> >> > our package,
> >>
> >> s/exactly the people/a subset of the people using H^1
> >> semi-discrete-in-time quadrature-based method of weighted residuals
> >> without material models or boundary conditions/
> >
> >
> > Here you are just arguing to argue. There are many people who would
> benefit.
> > Should we have a survey?
>
> Yes, let's find out what fraction of users would use this.
>



-- 
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/20140608/77921479/attachment.html>