Matthew Knepley <knep...@gmail.com> writes: >> And yet the quadrature interface is what occupies that prime namespace. >> Other uses of unadorned wording like "Residual" (well, everything else >> uses Function, though I would use Residual if starting anew) and >> "Jacobian" are in places that do not even assume a PDE or variational >> problem, let alone a very specific class of discretizations. > > > I think you exaggerate the danger.
I'd like to hear what some users and other developers think. >> >> I don't think PETSc should be in the business of creating a Framework. >> >> To be honest, I would rather see functionality like this provided in an >> >> external library so that it isn't confused with the more general-purpose >> > >> > I think this argument can be made about anything on top of Vec and >> > Mat, like TS. The real criterion we use to decide these things is how >> > useful it would be for the majority of PETSc users. I think this is a >> > hands-down win there. >> >> Keep in mind that (a) many PETSc users already use a discretization >> package so they couldn't care less about PetscProblem, and (b) many >> users that call PETSc directly have rather exotic discretizations or are >> not solving PDEs so PetscProblem is of no use for them. >> > > I agree, and many PETSc users want to use their own SNES, or they solve > problems which SNES cannot cope with nicely (non-holonomic constraints). Clearly that is more common than people that use TS _and_ have a spatial discretization that fits nicely into your Framework. >> TS works on a semi-discrete form and assumes nothing about the equation >> (such as spatial discretization, if applicable). The interfaces that >> offer something more specific are namespaced accordingly, e.g., >> DMDATSSetIFunctionLocal(). I would have less issue with >> DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature (which may >> or may not be "in scope"), but PetscProblemSetResidual is downright >> pretentious. You didn't respond to this point. Why are you taking up generic namespace with something this specific? I would argue that your PetscProblem interface is currently applicable to a strict subset of the intersection of MOOSE and GRINS. I don't think this belongs in PETSc, definitely not in such prominent namespace. 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.
pgpkGgNneobvk.pgp
Description: PGP signature