Le 30 janv. 2014 à 11:08, Garth N. Wells <[email protected]> a écrit :
> 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. > Sorry. In my head NonlinearProblem was not discrete but I was wrong (I unwisely relied on my bad memory instead of reading the code). Then the naming NonlinearVariationalSolver::NonlinearDiscreteProblem for the instance of NonlinearProblem does not make a lot of sense (ok, it is a private object, but it does not help understanding the code and the design). > >> 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. > Ok. I can survive with it, that's few line of code. What Patrick and me where pointing out is that in most cases the user want to control how the system is solved (accessing the low-level solver) without necessary see how it is assembled (a part how to impose the boundary conditions). For example NonlinearProblem could optionally get as input a NonlinearVariationalProblem and give a default implementation (basically moving the code of NonlinearVariationalSolver::NonlinearDiscreteProblem in NonlinearProblem(NonlinearVariationalProblem)). Again, the naming NonlinearProblem is misleading, since NonlinearVariationalProblem seems to be a special NonlinearProblem, while in practice it is more the opposite: having a NonlinearVariationalProblem one creates a Nonlinear(Discrete)Problem. However, on my side every tyrannic design choice that reduces the number of alternatives and simplify the interface is welcome! Even if I would personally start removing the magic solve(F==0). (Non)linearVariationalProblem/(Non)linearVariationalSolver is much saner for novices and students. Corrado > > > Garth > >> Corrado >> Le 30 janv. 2014 à 09:54, Patrick Farrell >> <[email protected]> a écrit : >>> On 29/01/14 21:45, Garth N. Wells wrote: >>>> I'd say that it's pointless >>> Wouldn't the correct behaviour be to apply the BCs symmetrically? >>>> and terribly misleading. >>> I agree with you there. >>> Patrick >>> _______________________________________________ >>> fenics mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
