On Sat, Jun 7, 2014 at 6:01 PM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > > > On Sat, Jun 7, 2014 at 5:11 PM, Jed Brown <[email protected]> wrote: > > > >> Matthew Knepley <[email protected]> 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
