> But while we are heading in that direction, how about abolishing the
> *Problem class(es) altogether, and just use LinearVariationalSolver
> and NonlinearVariationalSolver/NewtonSolver taking as input (a, L, bc)
> and (F, dF, bcs), respectively.
This will be in line with an old blueprint. We noted some time ago
that problems/solvers are designed differently for linear systems
Ax = b than for variational problems a(u, v) = L(v). For linear
systems, we have solvers while for variational problems we have both
problem and solver classes.
> I mean, the main difference lies in
> how to solve the problems, right?
It looks like the only property a VariationalProblem has in addition
to (forms, bc) + solver parameters is the parameter
symmetric=true/false.
If we go this route, we could mimic the design of the linear algebra
solvers and provide two different options, one that offers more
control, solver = KrylovSolver() + solver.solve(), and one quick
option that just calls solve:
1. complex option
solver = LinearVariationalSolver() # which arguments to constructor?
solver.parameters["foo"] = ...
u = solver.solve()
