[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

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

> Matthew Knepley <knepley at gmail.com> writes:
>
> > 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.
>
> So it's not supported by the PetscProblem interface?


I have not had time to code the implementation. The interface is
(hopefully) fine.


> >> > 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.
>
> I pointed out that your interface can't do that algorithm and I showed
> you code that can.  I'm not sure what you want me to do.  Change your
> interface to be able to do that method fast, implying other data
> structure changes and possible loss of functionality that you want?


Of course, there is nothing else to do but point out shortcomings. That
makes things easy.


> >> >> 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"?
>
> H^1 semi-discrete-in-time quadrature-based method of weighted residuals
> without material models or boundary conditions.  "Problem" is way too
> generic to be used for something so specific in PETSc.
>

I do not agree.


>
> >> >> 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.
>
> How else would you describe it?  I suggested
> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature().


Its not a DM.


> >> 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,
>
> s/exactly the people/a subset of the people using H^1
> semi-discrete-in-time quadrature-based method of weighted residuals
> without material models or boundary conditions/


Here you are just arguing to argue. There are many people who would benefit.
Should we have a survey?


> > it disrupts none of the existing workflow, and its got a fair number
> > of test compared to other stuff we have released.
>
> Deal.II has lots of tests.  Apart from the more restrictive license and
> language choice, why don't we include it in PETSc?  It's currently more
> flexible than your interface.  It can be a separate include so that it
> does not disrupt existing workflow.
>

Yep, I am for including Deal.II. Its now the only logical thing to do. I am
also for
counting all its lines of generated code in our SLOC count. We will win
another
DOE award.

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