[petsc-dev] getting ready for PETSc release

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

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

Where is your Riemann solver interface?  I see
DMPlexTSSetRHSFunctionLocal which has nothing in its name indicating
that it is a Riemann solver, has no support for non-conservative systems
(for which the Riemann solver returns a wave decomposition because
"flux" is not defined), and cannot support a transverse solve (to double
or triple the stable time step).  Note that this interface has a
context, unlike your FE quadrature functions.  (Interface inconsistency
is evil.)  Also, ex11 does not offer characteristic reconstruction.

I meant for ex11 to be a demonstration of one way to solve these
problems, but certainly not THE CANONICAL WAY.  I do not agree with
moving it into PETSc, especially not using a name like PetscProblem.
I'd rather it be in a separate project (that was the idea with the
parmod repository, but I don't think you ever used that).

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

Some problems are not appropriate for a given level of abstraction.  I
believe you are creating a specialized high-level PDE interface, which I
consider to be out of scope for PETSc.  Imagine if KSP was only capable
of solving scalar SPD problems.  "It's so easy to point out
shortcomings" and yet those shortcomings define a scope that is
incompatible with the name and not in the spirit of the software
package.

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

You access it via DMGetProblem() and your interfaces are analogous to
the DM-specific interfaces we have used in the past.

You might recall that we had a discussion a couple years ago about
whether DM should be a "function space" or should hold the problem
definition (via callbacks).  I argued for separation and still think
that unadorned function spaces are useful, but others (especially Barry)
wanted to limit the number of objects.  And in fact, the physics
influences things like coarse-space homogenization and grid transfer
within solver algorithms, so now I mixed opinions about it.  But in any
case, we made a decision and built code around the DM owning that stuff.
If you want to fundamentally change that model, it needs to be a
project-wide decision, implemented consistently across projects.

From the two examples that use PetscProblem, I think the issue is that
you want it to work with DMDA and DMPlex because the formulation does
not depend on grid topology, but the naming convention for
implementation-specific functions uses different namespaces.  But we can
have DM functions that are implemented by multiple implementations.  So
maybe this maps to
DMTSSetIFunctionMattsCoolDiscretizationVolumetricQuadrature().

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

Yes, let's find out what fraction of users would use this.
-------------- 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/20140608/bb487f7b/attachment.sig>