On Thu, Jan 30, 2014 at 11:48:47AM +0100, Jan Blechta wrote: > On Thu, 30 Jan 2014 10:37:59 +0000 > "Garth N. Wells" <[email protected]> wrote: > > > On 2014-01-30 10:25, Jan Blechta wrote: > > > On Thu, 30 Jan 2014 10:08:16 +0000 > > > "Garth N. Wells" <[email protected]> wrote: > > > > > >> On 2014-01-30 09:37, Corrado Maurini wrote: > > >> > Is there a reason for which there is not an option in > > >> > NonlinearVariationalSolver to choose how to impose boundary > > >> > conditions (symmetric or not)? > > >> > > > >> > As a user of PETScSNESSolver I completely agree with Patrick with > > >> > the usefulness of an intermediate class or something similar. > > >> > > > >> > I think that there the current argument naming in > > >> > PETScSNESSolver is misleading. > > >> > In PETScSNESSolver::solve(NonlinearProblem, x), NonlinearProblem > > >> > is actually a NonlinearDiscreteProblem. > > >> > > >> That's not correct. NonlinearDiscreteProblem is a NonlinearProblem. > > >> > > >> > Hence the user must implement its own NonlinearDiscreteProblem to > > >> > use directly PETScSNESSolver. > > >> > > >> No. A user implements a NonlinearProblem. > > >> > > >> > If NonlinearDiscreteProblem was public, or at least accessible by > > >> > PETScSNESSolver, one could easily overload > > >> > PETScSNESSolver::solve to get as input a real NonlinearProblem > > >> > (and not only the Discrete version as now). > > >> > Perhaps it suffices to render PETScSNESSolver and > > >> > NonlinearVariationalSolver friend classes? > > >> > > > >> > > >> This doesn't make sense. The design is simple: a user implements a > > >> NonlinearProblem. > > > > > > Garth, the whole story is pretty simple: > > > why can't user access NonlinearDiscreteProblem to be able to > > > overload some of its methods (F, J) when using > > > NonlinearVariationalProblem/Solver > > > interface (like he can (actually must) do with NonlinearProblem when > > > using NewtonSolver or PETScSNESSolver). > > > > > > > We could provide 100s of ways of doing everything, but we make design > > I get your point but the suggested change is of particular interest as > it allows you to use a custom way of assembling a problem and > simultaneously lets you switching between built-in Newton and SNES just > using a parameter.
I still don't see the point. How can you not accomplish that by creating a subclass of NonlinearProblem directly, instead of via an additional wrapper layer in the form of NonlinearDiscreteProblem? It sounds like what you are asking for is an interface in between NonlinearProblem and NonlinearVariationalProblem, which takes care of assembly, but leaves nonlinear solve to the user. By the same reasoning, we could add yet another interface which takes care of nonlinear solve but leaves assembly to the user... -- Anders _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
