On 14/06/11 08:53, Anders Logg wrote: > > 14 jun 2011 kl. 09:18 skrev "Garth N. Wells" <gn...@cam.ac.uk>: > >> >> >> 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. > > With the syntax suggested below it would be easy to check for errors. > > >> >>> 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 > > I'm not surprised you don't like it. But don't understand why. It's > very clear which is linear and which is nonlinear. And it would be > easy to check for errors. And it would just be a thin layer on top of > the very explicit linear/nonlinear solver classes. And it would > follow the exact same design as for la with solver classes plus a > quick access solve function. >
Is not clear to me - possibly because, as I wrote above, I don't understand the syntax. What does the '==' mean? Garth > -- Anders > > >> 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
