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