[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

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

> Matthew Knepley <knepley at gmail.com> writes:
> >> This is awfully prime real estate in the namespace to be placing
> >> functions that run at quadrature points, do not have context arguments,
> >> cannot share results of a material model, is somewhat specific to finite
> >> elements, does not support Riemann solvers, characteristic
> >> reconstruction, general boundary conditions, etc.
> >>
> >
> > I gave my reasons for excluding context argument from the bottom level
> > functions. The context appears at the next level up, so that can be
> > replaced if you do not like the quadrature-level interface.
>
> 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 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).

  Matt


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



-- 
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/6451c3e7/attachment.html>