[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

On Sat, Jun 7, 2014 at 8:21 AM, Jed Brown <jed at jedbrown.org> wrote:

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

Of course, I disagree.


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


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

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.

   Matt


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



-- 
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/296dad95/attachment.html>