On Sat, Jun 7, 2014 at 8:21 AM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > >> How do we note that these interfaces are not stable and will likely > >> change soon after the release? (At least I think the current > >> arrangement is brittle and either will not last or will not be used > >> much.) > >> > > > > Feel free to note on the list that you think it should be done a > different, > > as yet unspecified > > or coded, way. > > We've discussed these issues many times. I think that in your quest to > make certain simple things easy (or to avoid duplication between > examples), you are building a Framework. Not in the sense of > controlling main, but in being very opinionated about formulation. >
Of course, I disagree. > 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. > ierr = DMGetProblem(dm, &prob);CHKERRQ(ierr); > ierr = PetscProblemSetResidual(prob, 0, f0_u, f1_u);CHKERRQ(ierr); > ierr = PetscProblemSetResidual(prob, 1, f0_p, f1_p);CHKERRQ(ierr); > ierr = PetscProblemSetJacobian(prob, 0, 0, NULL, NULL, NULL, > g3_uu);CHKERRQ(ierr); > ierr = PetscProblemSetJacobian(prob, 0, 1, NULL, NULL, g2_up, > NULL);CHKERRQ(ierr); > ierr = PetscProblemSetJacobian(prob, 1, 0, NULL, g1_pu, NULL, > NULL);CHKERRQ(ierr); > > > 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. Matt > functionality found in the rest of PETSc, and so that it can make more > frequent releases. As an external library, it would also compete as a > peer with other packages offering a similar level of abstraction, rather > than the asymmetric relationship of a high-level opinionated abstraction > masquerading as being part of the middleware upon which its rightful > "peers" depend. > > I think a good way to evaluate scope is to ask whether we would accept > the code if it were submitted by an outsider with no prior history > developing PETSc. If it is quality code that is in scope, there should > be no question. I think this would be considered out of scope, but I'm > just one person. What does everyone else think? > -- 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
