<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 8, 2014 at 3:41 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Sat, Jun 7, 2014 at 6:01 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Sat, Jun 7, 2014 at 5:11 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> ><br>
>> >> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> >><br>
>> >> > As far as I know, neither can do FV stuff which this is going to<br>
>> >> > do.<br>
>> >><br>
>> >> Where are your Riemann solve, characteristic reconstruction, and<br>
>> >> boundary conditions interfaces?  You already used the generic namespace<br>
>> >> for a volumetric term that doesn't even exist in FV formulations.<br>
>> ><br>
>> ><br>
>> > Its in PetscFV. PetscProblem is supposed to hold both types. I can only<br>
>> work<br>
>> > so fast, and I am doing the FEM example first.<br>
>><br>
>> So it's not supported by the PetscProblem interface?<br>
><br>
><br>
> I have not had time to code the implementation. The interface is<br>
> (hopefully) fine.<br>
<br>
</div>Where is your Riemann solver interface?  I see<br>
DMPlexTSSetRHSFunctionLocal which has nothing in its name indicating<br>
that it is a Riemann solver, has no support for non-conservative systems<br>
(for which the Riemann solver returns a wave decomposition because<br>
"flux" is not defined), and cannot support a transverse solve (to double<br>
or triple the stable time step).  Note that this interface has a<br>
context, unlike your FE quadrature functions.  (Interface inconsistency<br>
is evil.)  Also, ex11 does not offer characteristic reconstruction.<br>
<br>
I meant for ex11 to be a demonstration of one way to solve these<br>
problems, but certainly not THE CANONICAL WAY.  I do not agree with<br>
moving it into PETSc, especially not using a name like PetscProblem.<br>
I'd rather it be in a separate project (that was the idea with the<br>
parmod repository, but I don't think you ever used that).</blockquote><div><br></div><div>Fine, but what in the FV interface is inappropriate for this. Also, I distrust the argument</div><div>here because some of what you describe is incredibly special-purpose, namely it will</div>
<div>only work on Cartesian grids, and thus should not determine large parts of the top</div><div>level interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> >> > Maybe MOOSE does. However, neither of those has good integration with<br>
>> >> > the solver (I have discussed this personally with Roy and Derek and<br>
>> >> > they agree).<br>
>> >><br>
>> >> You have to be able to formulate a similar scope of problems before you<br>
>> >> get to argue fine points of supporting geometric multigrid and the like.<br>
>> >> FWIW, it does not support the solve structure we use in pTatin so gives<br>
>> >> up significant performance relative to existing packages that use solver<br>
>> >> algorithms you want.<br>
>> >><br>
>> ><br>
>> > I asked you to help with this.<br>
>><br>
>> I pointed out that your interface can't do that algorithm and I showed<br>
>> you code that can.  I'm not sure what you want me to do.  Change your<br>
>> interface to be able to do that method fast, implying other data<br>
>> structure changes and possible loss of functionality that you want?<br>
><br>
><br>
> Of course, there is nothing else to do but point out shortcomings. That<br>
> makes things easy.<br>
<br>
</div>Some problems are not appropriate for a given level of abstraction.  I<br>
believe you are creating a specialized high-level PDE interface, which I<br>
consider to be out of scope for PETSc.  Imagine if KSP was only capable<br>
of solving scalar SPD problems.  "It's so easy to point out<br>
shortcomings" and yet those shortcomings define a scope that is<br>
incompatible with the name and not in the spirit of the software<br>
package.</blockquote><div><br></div><div>KSP is of course only for Krylov solvers, and we dump everything else in PC.</div><div>There is nothing wrong with limiting the scope of an abstraction to a useful</div><div>subset. This is the essence of design, and a small-minded committment to</div>
<div>absorbing everything will dilute the interface to nothing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
>> >> >> think this belongs in PETSc, definitely not in such prominent<br>
>> namespace.<br>
>> >> >><br>
>> >> ><br>
>> >> > I don't know why you think this is so bad. I picked a name because I<br>
>> >> needed<br>
>> >> > a name. Its not DM, its a collection of DMs.<br>
>> >><br>
>> >> It's a very framework-style name with generic connotations used for<br>
>> >> something extremely specific.<br>
>> ><br>
>> ><br>
>> > I do not think its for something that specific. It is to hold a<br>
>> > collection of pointwise evaluation routines + discretizations. What is<br>
>> > better than "problem"?<br>
>><br>
>> H^1 semi-discrete-in-time quadrature-based method of weighted residuals<br>
>> without material models or boundary conditions.  "Problem" is way too<br>
>> generic to be used for something so specific in PETSc.<br>
>><br>
><br>
> I do not agree.<br>
><br>
><br>
>><br>
>> >> >> I also cannot imagine that this interface is stable, so even if this<br>
>> >> >> sort of thing goes into PETSc, there's no use having it in the<br>
>> release.<br>
>> >> >><br>
>> >> ><br>
>> >> > We have a bunch of stuff that is not completely stable. I am not sure<br>
>> >> > what this kind of conservatism buys us.<br>
>> >><br>
>> >> Exploratory programming in a release using a prominent namespace will<br>
>> >><br>
>> ><br>
>> > I think "prominent" here is misguided.<br>
>><br>
>> How else would you describe it?  I suggested<br>
>> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature().<br>
><br>
><br>
> Its not a DM.<br>
<br>
</div>You access it via DMGetProblem() and your interfaces are analogous to<br>
the DM-specific interfaces we have used in the past.<br>
<br>
You might recall that we had a discussion a couple years ago about<br>
whether DM should be a "function space" or should hold the problem<br>
definition (via callbacks).  I argued for separation and still think<br>
that unadorned function spaces are useful, but others (especially Barry)<br>
wanted to limit the number of objects.  And in fact, the physics<br>
influences things like coarse-space homogenization and grid transfer<br>
within solver algorithms, so now I mixed opinions about it.  But in any<br>
case, we made a decision and built code around the DM owning that stuff.<br>
If you want to fundamentally change that model, it needs to be a<br>
project-wide decision, implemented consistently across projects.<br>
<br>
>From the two examples that use PetscProblem, I think the issue is that<br>
you want it to work with DMDA and DMPlex because the formulation does<br>
not depend on grid topology, but the naming convention for<br>
implementation-specific functions uses different namespaces.  But we can<br>
have DM functions that are implemented by multiple implementations.  So<br>
maybe this maps to<br>
DMTSSetIFunctionMattsCoolDiscretizationVolumetricQuadrature().</blockquote><div><br></div><div>1) Volumetric here is inappropriate because it supports boundary integrals</div><div><br></div><div>2) It is supposed to support both FEM and FVM</div>
<div><br></div><div>3) It is a sub-object, just like PetscLayout, meant to operate is service of a DM.</div><div>     Its never used apart from it, just like PetscLayout and Vec/Mat. Layout is</div><div>     also a generic name, but Layout only supports the simples kind of partition,</div>
<div>     and thus cannot do more complex things, but we did not have a huge</div><div>     discussion about it. I still fail to see how this is a big deal.</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> >> encourage people to try using it, then have a bad experience when it (a)<br>
>> >> does not work for their problem and (b) is changed soon after the<br>
>> >> release.  I would rather that exploration happen in a different package<br>
>> >> that users can opt into.<br>
>> >><br>
>> >> I like developing library code in PETSc, and often look for ways to<br>
>> >> formulate a new idea to make it appropriate for PETSc.  But some things<br>
>> >> just make more sense in a separate package.  If there is a technical<br>
>> >> problem with distributing such a package, we should solve that problem.<br>
>> >><br>
>> ><br>
>> > Its not a lot of code, its very useful for exactly the people that use<br>
>> > our package,<br>
>><br>
>> s/exactly the people/a subset of the people using H^1<br>
>> semi-discrete-in-time quadrature-based method of weighted residuals<br>
>> without material models or boundary conditions/<br>
><br>
><br>
> Here you are just arguing to argue. There are many people who would benefit.<br>
> Should we have a survey?<br>
<br>
</div>Yes, let's find out what fraction of users would use this.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>