On 06/13/2011 11:16 PM, Anders Logg wrote:
> 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()
For the eigensolvers, all arguments go in the call to solve.
2. simple option
u = solve(a, L, bc)
Just for linears?
3. very tempting option (simple to implement in both C++ and Python)
u = solve(a == L, bc) # linear
u = solve(F == 0, J, bc) # nonlinear
Oo, pretty.
I would prefer this to the other route (LinearProblem|NonlinearProblem).
--
Marie
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
