dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 21 June 2011 10:37, Anders Logg <logg@xxxxxxxxx> wrote:
> On Tue, Jun 21, 2011 at 10:19:22AM +0200, Marie E. Rognes wrote:
>>
>>
>> On 21. juni 2011, at 09:58, Anders Logg <logg@xxxxxxxxx> wrote:
>>
>> > Thanks for looking into this. So it looks like this will work out
>> > fine. So are there any objections to changing the VariationalProblem
>> > (which depends on the order of arguments) to the more explicit
>> >
>> >  LinearVariationalSolver
>> >  NonlinearVariationalSolver
>> >
>> > *solver* classes (instead of problem classes so that it's consistent
>> > with the way we treat la), and adding on top of this the free function
>> > solve() as a shortcut:
>> >
>> >  solve(a == L, ...)
>> >  solve(F == 0, ...)
>> >
>> > If not, I can get started on implementing this.
>> >
>>
>> Very much in favor :)
>>
>> Where does u enter in the free functions?
>
> Don't know yet. Suggestions are welcome. My suggestion would be to
> follow what Mathematica and swiginac and always include it as the argument
> following the equation. We would then have this:
>
>  solve(a == L, u, bc)
>  solve(F == 0, u, bc, J=J)

Looks good to me.

In Python we should check if u is among the coefficients of F,
otherwise raise an error. That will cover the bug case of defining
F with u1 and providing u2 to solve.

In NonlinearVS, I think u should be part of the
constructor arguments, so it's not needed by solve:
  NonlinearVariationalSolver solver(F, u, bcs, ...);
  NonlinearVariationalSolver solver(F, u, J, bcs, ...);
  solver.solve();

Martin

> The drawback is we can't do
>
>  u = solve(a == L)
>
> but that's similar to how we handle linear systems where we do
>
>  solve(A, x, b)
>
> instead of
>
>  x = solve(A, b)
>
> --
> Anders
>