On Sat, Jun 7, 2014 at 3:30 PM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > >> This is awfully prime real estate in the namespace to be placing > >> functions that run at quadrature points, do not have context arguments, > >> cannot share results of a material model, is somewhat specific to finite > >> elements, does not support Riemann solvers, characteristic > >> reconstruction, general boundary conditions, etc. > >> > > > > I gave my reasons for excluding context argument from the bottom level > > functions. The context appears at the next level up, so that can be > > replaced if you do not like the quadrature-level interface. > > 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 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). Matt > 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. > -- 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
