On Wed, Jan 05, 2011 at 08:06:58PM +0000, Garth N. Wells wrote:
>
>
> On 05/01/11 20:04, Anders Logg wrote:
> >On Wed, Jan 05, 2011 at 07:50:33PM +0000, Garth N. Wells wrote:
> >>
> >>
> >>On 05/01/11 19:37, Anders Logg wrote:
> >>>On Wed, Jan 05, 2011 at 07:16:45PM +0000, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>>On 05/01/11 18:52, Marie E. Rognes wrote:
> >>>>>
> >>>>>
> >>>>>On 5. jan. 2011, at 19:30, Anders Logg<l...@simula.no> wrote:
> >>>>>
> >>>>>>On Wed, Jan 05, 2011 at 05:21:07PM +0000, Garth N. Wells wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>On 05/01/11 15:12, Anders Logg wrote:
> >>>>>>>>On Wed, Jan 05, 2011 at 03:51:32PM +0100, Marie E. Rognes wrote:
> >>>>>>>>>On 01/05/2011 03:32 PM, Garth N. Wells wrote:
> >>>>>>>>>
> >>>>>>>>> I wonder if the distinction now between linear and nonlinear
> >>>>>>>>> problems is
> >>>>>>>>> too subtle? Another way would be to have classes
> >>>>>>>>>
> >>>>>>>>> LinearVariationalProblem
> >>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>>
> >>>>>>>>> NonlinearVariationalProblem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>I agree that the distinction in the interface can be called subtle
> >>>>>>>>>(or
> >>>>>>>>>alternatively, "almost seamless"). But, I think I prefer keeping the
> >>>>>>>>>input
> >>>>>>>>>minimal and rather giving more verbose feedback ("starting
> >>>>>>>>>linear/nonlinear
> >>>>>>>>>solve", throwing errors if input is inconsistent etc) than
> >>>>>>>>>increasing the
> >>>>>>>>>verbosity of the required input.
> >>>>>>>>>
> >>>>>>>>>Also cf. thread "VariationalProblem interface(s)" from Oct 20th for
> >>>>>>>>>more
> >>>>>>>>>motivation behind this change.
> >>>>>>>>
> >>>>>>>>I tend to prefer overloading and like the shorter "VariationalProblem"
> >>>>>>>>for both linear and nonlinear problems.
> >>>>>>>>
> >>>>>>>>The rationale is that the most important argument is placed first:
> >>>>>>>>
> >>>>>>>> F, F'
> >>>>>>>> a, L
> >>>>>>>>
> >>>>>>>
> >>>>>>>My first issue is that it's not easy to read. Scanning through a
> >>>>>>>function, it's not immediately obvious that a problem is linear or
> >>>>>>>nonlinear.
> >>>>>>>
> >>>>>>>Another reason to separate linear and nonlinear clases is that there
> >>>>>>>is almost no shared code (none?) in VariationalProblem.cpp, so it
> >>>>>>>doesn't make much sense to roll linear and nonlinear cases into one
> >>>>>>>class. The other point is that they will share few parameters - I
> >>>>>>>would like eventually to have more options for how a nonlinear
> >>>>>>>problem is solved.
> >>>>>
> >>>>>
> >>>>>Good point -- there are a lot of linear vs nonlinear checks in the
> >>>>>current VP.cpp...
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>Garth
> >>>>>>
> >>>>>>We have a blueprint on this. The solvers should be split into
> >>>>>>FooSolver classes anyway so the sharing of code is not much of an
> >>>>>>issue.
> >>>>
> >>>>A linear solver is only one ingredient in a nonlinear solver. There
> >>>>is also modified Newton, quasi-Newton, path following,
> >>>>Newton-Krylov, preconditioner re-use, . . . .
> >>>
> >>>I don't understand this point. That would all be part of
> >>>NonlinearVariationalSolver.
> >>>
> >>
> >>I'm not sure that we would want a NonlinearVariationalSolver class.
> >>It should be more abstract and just be a NonlinearSolver.
> >
> >Where would be then implement the algorithm for solving a nonlinear
> >variational problem? It should not be in NonlinearVariationalProblem
> >as that goes against the design for all other algorithms in DOLFIN
> >(which are implemented in separate classes).
> >
> >Perhaps there's also use for an abstract NonlinearSolver, but we also
> >need a concrete implementation of a solver for nonlinear variational
> >problems and then it would be natural to call it NonlinearVariationalSolver.
> >
> >>>>>This way of solving the above issue makes very much sense to me.
> >>>>>
> >>>>>
> >>>>>>The solvers can go in
> >>>>>>
> >>>>>> static LinearVariationalSolver::solve() const
> >>>>>> static NonlinearVariationalSolver::solve() const
> >>>>>>
> >>>>>>Then it's a matter of taste whether we have VariationalProblem or
> >>>>>>two separate classes. I prefer one class since
> >>>>>>
> >>>>>>1. I like overloading in general
> >>>>>>
> >>>>>>2. It's a shorter name
> >>>>>>
> >>>>>>3. It's (mostly) backwards compatible
> >>>>>>
> >>>>>
> >>>>
> >>>>We could merge a lot of classes that don't share code into one
> >>>>class, and distinguish cases through the constructor arguments, but
> >>>>that would be a bad design. If they don't share code, they shouldn't
> >>>>be in the same class.
> >>>
> >>>They would essentially be in two different classes (the two different
> >>>solver classes). The VariationalProblem class would just be a simple
> >>>data structure for packing up the data defining a variational problem.
> >>>
> >>>Note that the design for solving variational problems is different
> >>>from what we use in other places like linear systems. There we only
> >>>have solver classes and the input is a Matrix and a Vector.
> >>>
> >>>We could do the same thing for variational problems:
> >>>
> >>> u = solver.solve(F, bcs)
> >>> u = solve(F, bcs)
> >>>
> >>>>I would like to have LinearVariationalProblem and
> >>>>NonlinearVariationalProblem, and I'm pretty strongly opposed to
> >>>>artificially forcing both into once class if there is no/minimal
> >>>>code sharing. A compromise design could be:
> >>>>
> >>>> class LinearVariationalProblem : GenericVariationalProbem
> >>>> class NonlinearVariationalProblem : GenericVariationalProbem
> >>>>
> >>>>and for simple usage cases
> >>>>
> >>>> class VariationalProblem
> >>>> {
> >>>> public:
> >>>>
> >>>> // constructors
> >>>> VariationalProblem( .... )
> >>>> { variational_problem = new LinearVariationalProblem; }
> >>>>
> >>>> VariationalProblem( .... )
> >>>> { variational_problem = new NonlinearVariationalProblem; }
> >>>>
> >>>> void solve(Function& u)
> >>>> { variational_problem->solve(u); }
> >>>>
> >>>> private:
> >>>>
> >>>> GenericVariationalProblem* variational_problem ;
> >>>>
> >>>> }
> >>>
> >>>The essential bits should go into *solver* classes (which should be
> >>>separate), like we do for everything else.
> >>>
> >>>Then VariationalProblem is just a collection of ca 3 objects (two
> >>>forms, a list of bcs + maybe something else). At that point, it's just
> >>>a matter of taste whether we should have two such classes (with long
> >>>names) or if we can reuse one very simple container for both cases.
> >>>
> >>
> >>OK. If VariationalProblem is just a light-weight collection (unlike
> >>what it is now), then my design objections fall away. I'm still
> >>concerned that the distinction between linear and nonlinear problems
> >>is too subtle and thus error prone (I would have no difficulty on
> >>the Python side using named arguments, e.g. pde =
> >>VariationalProblem(F=..., J=...,...)).
> >
> >I think the J will be optional, at least on the Python side so we will
> >have
> >
> > VariationalProblem(a, L, bcs) --> linear
> > VariationalProblem(F, bcs) --> nonlinear, J computed automatically
> >
> >Then it would be very clear which is linear and which is nonlinear.
> >
>
> The Jacobian cannot always be computed automatically, e.g.
> plasticity problems. It is also desirable in some case to not use
> the exact J.
Yes, but in those cases one can use the optional argument J=something.
--
Anders
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
