<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 8, 2014 at 12:20 PM, 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 Sun, Jun 8, 2014 at 3:41 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
</div><div class="">>> 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).<br>
><br>
><br>
> Fine, but what in the FV interface is inappropriate for this. Also, I<br>
> distrust the argument here because some of what you describe is<br>
> incredibly special-purpose, namely it will only work on Cartesian<br>
> grids, and thus should not determine large parts of the top level<br>
> interface.<br>
<br>
</div>What only works on Cartesian grids? Wave decomposition and such works<br></blockquote><div><br></div><div>My understanding was that the Clawpack algorithms worked only on Cartesian</div><div>grids. Are these "mode decomposed"?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
on unstructured grids. PetscProblem is the special-purpose thing that<br>
excludes large classes of good methods. I think it is inappropriate to<br>
use the PetscProblem namespace for a specific class of methods.</blockquote><div><br></div><div>I think you have an idiosyncratic and expansive understanding of the word "Problem".</div><div>It can also mean a "difficulty", "unwelcome or harmful situation", or "complication". If</div>
<div>its really down to the word, I could see changing it to reduce the number of ultimately</div><div>unhelpful emails.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
>> >> >> > Maybe MOOSE does. However, neither of those has good integration<br>
>> 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<br>
>> you<br>
>> >> >> get to argue fine points of supporting geometric multigrid and the<br>
>> like.<br>
>> >> >> FWIW, it does not support the solve structure we use in pTatin so<br>
>> gives<br>
>> >> >> up significant performance relative to existing packages that use<br>
>> 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>
>> 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.<br>
><br>
><br>
> KSP is of course only for Krylov solvers, and we dump everything else in PC.<br>
> There is nothing wrong with limiting the scope of an abstraction to a useful<br>
> subset. This is the essence of design, and a small-minded committment to<br>
> absorbing everything will dilute the interface to nothing.<br>
<br>
</div></div>PetscProblem is a name that claims to be far more than it is. You can't<br></blockquote><div><br></div><div>Again, there are no claims in a name. Decades of linguistic research attest to</div><div>the malleability of names.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
compose these things because the scope is so limited and can't even<br>
commit to using them because you'll end up spending lots of time<br>
extending the interface (which is not currently user-extensible and<br>
perhaps not useful to become user-extensible).<br>
<br>
Why can't you develop this in a separate package?</blockquote><div><br></div><div>Too much overhead for too little benefit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> >> How else would you describe it? I suggested<br>
>> >> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature().<br>
>> ><br>
>> ><br>
>> > Its not a DM.<br>
>><br>
>> 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().<br>
><br>
><br>
> 1) Volumetric here is inappropriate because it supports boundary integrals<br>
<br>
</div>Through a different function, PetscProblemSetBdResidual(). (I will also<br>
complain that this does not support different boundary types.)</blockquote><div><br></div><div>Criticize away. I did not want to give you the idea that criticism is unwelcome.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> 2) It is supposed to support both FEM and FVM<br>
<br>
</div>But you need new functions for FV because PetscProblemSetResidual<br>
definitely does not support it.</blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> 3) It is a sub-object, just like PetscLayout, meant to operate is service<br>
> of a DM.<br>
> Its never used apart from it, just like PetscLayout and Vec/Mat.<br>
> Layout is<br>
> also a generic name, but Layout only supports the simples kind of<br>
> partition,<br>
> and thus cannot do more complex things, but we did not have a huge<br>
> discussion about it. I still fail to see how this is a big deal.<br>
<br>
</div>PetscLayout contains nontrivial data size and can be shared between<br>
multiple objects (and we should do a better job of that sharing because<br>
PetscLayout storage is not trivial with a million MPI ranks if each<br>
object has its own).<br></blockquote><div><br></div><div>PetscProblem can be shared between multiple objects, and has non-trivial sizes.</div><div>There is no point to the above paragraph and it dodges the main issue of the</div>
<div>question.</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">
We added the DMTS, DMSNES, etc., to hold functions of this sort. Those<br>
are shared between nested solvers via a DM. Now you're adding a new<br>
interface that does not explicitly name a problem level (TS, SNES, etc.)<br>
or a class of discretizations. (I'm using "discretization" here in a<br>
general sense, independent of mesh topology.) This interface<br>
fragmentation is inconsistent and forces the user to deal with yet<br>
another object.<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>