dolfin team mailing list archive

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

> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp