[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

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

> Matthew Knepley <knepley at gmail.com> writes:
>
> > As far as I know, neither can do FV stuff which this is going to
> > do.
>
> Where are your Riemann solve, characteristic reconstruction, and
> boundary conditions interfaces?  You already used the generic namespace
> for a volumetric term that doesn't even exist in FV formulations.


Its in PetscFV. PetscProblem is supposed to hold both types. I can only work
so fast, and I am doing the FEM example first.


> > 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).
>
> You have to be able to formulate a similar scope of problems before you
> get to argue fine points of supporting geometric multigrid and the like.
> FWIW, it does not support the solve structure we use in pTatin so gives
> up significant performance relative to existing packages that use solver
> algorithms you want.
>

I asked you to help with this.


>
> >> 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.
>
> It's a very framework-style name with generic connotations used for
> something extremely specific.


I do not think its for something that specific. It is to hold a collection
of pointwise
evaluation routines + discretizations. What is better than "problem"?


> >> 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.
>
> Exploratory programming in a release using a prominent namespace will
>

I think "prominent" here is misguided.


> encourage people to try using it, then have a bad experience when it (a)
> does not work for their problem and (b) is changed soon after the
> release.  I would rather that exploration happen in a different package
> that users can opt into.
>
> I like developing library code in PETSc, and often look for ways to
> formulate a new idea to make it appropriate for PETSc.  But some things
> just make more sense in a separate package.  If there is a technical
> problem with distributing such a package, we should solve that problem.
>

Its not a lot of code, its very useful for exactly the people that use our
package,
it disrupts none of the existing workflow, and its got a fair number of
test compared
to other stuff we have released.

   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/295169e8/attachment.html>