On 14/06/11 08:03, Marie E. Rognes wrote: > 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() >>
I favour this option, but I think that the name 'LinearVariationalSolver' is misleading since it's not a 'variational solver', but solves variational problems, nor should it be confused with a LinearSolver that solves Ax = f. LinearVariationalProblem is a better name. For total control, we could have a LinearVariationalProblem constructor that accepts a GenericLinearSolver as an argument (as the NewtonSolver does). > > For the eigensolvers, all arguments go in the call to solve. > >> 2. simple option >> >> u = solve(a, L, bc) >> > I think that saving one line of code and making the code less explicit isn't worthwhile. I can foresee users trying to solve nonlinear problems with this. > 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 >> > I don't like this on the same grounds that I don't like the present design. Also, I don't follow the above syntax. Garth > 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
