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. > 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. >> 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 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 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.
pgpHWEAwc3rOU.pgp
Description: PGP signature
