On Sat, Jun 7, 2014 at 5:11 PM, Jed Brown <j...@jedbrown.org> wrote: > Matthew Knepley <knep...@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. > > 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. > > >> 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"? > >> 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. > 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, it disrupts none of the existing workflow, and its got a fair number of test compared to other stuff we have released. 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