dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

14 jun 2011 kl. 09:18 skrev "Garth N. Wells" <gnw20@xxxxxxxxx>:

> 
> 
> 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.

--
Anders


> Garth
> 
>> Oo, pretty.
>> 
>> I would prefer this to the other route (LinearProblem|NonlinearProblem).
>> 
>> -- 
>> Marie
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp