[petsc-dev] getting ready for PETSc release

[Jed Brown]

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
think this belongs in PETSc, definitely not in such prominent namespace.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140607/e3233049/attachment.sig>