[petsc-dev] getting ready for PETSc release

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:
>> How do we note that these interfaces are not stable and will likely
>> change soon after the release?  (At least I think the current
>> arrangement is brittle and either will not last or will not be used
>> much.)
>>
>
> Feel free to note on the list that you think it should be done a different,
> as yet unspecified
> or coded, way.

We've discussed these issues many times.  I think that in your quest to
make certain simple things easy (or to avoid duplication between
examples), you are building a Framework.  Not in the sense of
controlling main, but in being very opinionated about formulation.

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.

  ierr = DMGetProblem(dm, &prob);CHKERRQ(ierr);
  ierr = PetscProblemSetResidual(prob, 0, f0_u, f1_u);CHKERRQ(ierr);
  ierr = PetscProblemSetResidual(prob, 1, f0_p, f1_p);CHKERRQ(ierr);
  ierr = PetscProblemSetJacobian(prob, 0, 0, NULL, NULL,  NULL,  g3_uu);CHKERRQ(ierr);
  ierr = PetscProblemSetJacobian(prob, 0, 1, NULL, NULL,  g2_up, NULL);CHKERRQ(ierr);
  ierr = PetscProblemSetJacobian(prob, 1, 0, NULL, g1_pu, NULL,  NULL);CHKERRQ(ierr);


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
functionality found in the rest of PETSc, and so that it can make more
frequent releases.  As an external library, it would also compete as a
peer with other packages offering a similar level of abstraction, rather
than the asymmetric relationship of a high-level opinionated abstraction
masquerading as being part of the middleware upon which its rightful
"peers" depend.

I think a good way to evaluate scope is to ask whether we would accept
the code if it were submitted by an outsider with no prior history
developing PETSc.  If it is quality code that is in scope, there should
be no question.  I think this would be considered out of scope, but I'm
just one person.  What does everyone else think?
-------------- 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/e5ff4c4d/attachment.sig>