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<logg@xxxxxxxxx> 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.
