[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

On Sat, Jun 7, 2014 at 4:50 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
> >> And yet the quadrature interface is what occupies that prime namespace.
> >> Other uses of unadorned wording like "Residual" (well, everything else
> >> uses Function, though I would use Residual if starting anew) and
> >> "Jacobian" are in places that do not even assume a PDE or variational
> >> problem, let alone a very specific class of discretizations.
> >
> >
> > I think you exaggerate the danger.
>
> I'd like to hear what some users and other developers think.
>
> >> >> I don't think PETSc should be in the business of creating a
> Framework.
> >> >> To be honest, I would rather see functionality like this provided in
> an
> >> >> external library so that it isn't confused with the more
> general-purpose
> >> >
> >> > I think this argument can be made about anything on top of Vec and
> >> > Mat, like TS. The real criterion we use to decide these things is how
> >> > useful it would be for the majority of PETSc users. I think this is a
> >> > hands-down win there.
> >>
> >> Keep in mind that (a) many PETSc users already use a discretization
> >> package so they couldn't care less about PetscProblem, and (b) many
> >> users that call PETSc directly have rather exotic discretizations or are
> >> not solving PDEs so PetscProblem is of no use for them.
> >>
> >
> > I agree, and many PETSc users want to use their own SNES, or they solve
> > problems which SNES cannot cope with nicely (non-holonomic constraints).
>
> Clearly that is more common than people that use TS _and_ have a spatial
> discretization that fits nicely into your Framework.
>
> >> TS works on a semi-discrete form and assumes nothing about the equation
> >> (such as spatial discretization, if applicable).  The interfaces that
> >> offer something more specific are namespaced accordingly, e.g.,
> >> DMDATSSetIFunctionLocal().  I would have less issue with
> >> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature (which may
> >> or may not be "in scope"), but PetscProblemSetResidual is downright
> >> pretentious.
>
> You didn't respond to this point.  Why are you taking up generic
> namespace with something this specific?
>
> I would argue that your PetscProblem interface is currently applicable
> to a strict subset of the intersection of MOOSE and GRINS.  I don't
>

As far as I know, neither can do FV stuff which this is going to do. 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).


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


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

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