dolfin team mailing list archive

["Marie E. Rognes" <meg@xxxxxxxxx>]

On 5. jan. 2011, at 19:30, Anders Logg <logg@xxxxxxxxx> wrote:

> On Wed, Jan 05, 2011 at 05:21:07PM +0000, Garth N. Wells wrote:
>> 
>> 
>> On 05/01/11 15:12, Anders Logg wrote:
>>> On Wed, Jan 05, 2011 at 03:51:32PM +0100, Marie E. Rognes wrote:
>>>> On 01/05/2011 03:32 PM, Garth N. Wells wrote:
>>>> 
>>>>    I wonder if the distinction now between linear and nonlinear problems is
>>>>    too subtle? Another way would be to have classes
>>>> 
>>>>      LinearVariationalProblem
>>>> 
>>>>    and
>>>> 
>>>>      NonlinearVariationalProblem
>>>> 
>>>> 
>>>> 
>>>> 
>>>> I agree that the distinction in the interface can be called subtle (or
>>>> alternatively, "almost seamless"). But, I think I prefer keeping the input
>>>> minimal and rather giving more verbose feedback ("starting linear/nonlinear
>>>> solve", throwing errors if input is inconsistent etc) than increasing the
>>>> verbosity of the required input.
>>>> 
>>>> Also cf. thread "VariationalProblem interface(s)" from Oct 20th for more
>>>> motivation behind this change.
>>> 
>>> I tend to prefer overloading and like the shorter "VariationalProblem"
>>> for both linear and nonlinear problems.
>>> 
>>> The rationale is that the most important argument is placed first:
>>> 
>>>  F, F'
>>>  a, L
>>> 
>> 
>> My first issue is that it's not easy to read. Scanning through a
>> function, it's not immediately obvious that a problem is linear or
>> nonlinear.
>> 
>> Another reason to separate linear and nonlinear clases is that there
>> is almost no shared code (none?) in VariationalProblem.cpp, so it
>> doesn't make much sense to roll linear and nonlinear cases into one
>> class. The other point is that they will share few parameters - I
>> would like eventually to have more options for how a nonlinear
>> problem is solved.


Good point -- there are a lot of linear vs nonlinear checks in the current VP.cpp...


>> 
>> Garth
> 
> We have a blueprint on this. The solvers should be split into
> FooSolver classes anyway so the sharing of code is not much of an
> issue.
> 


This way of solving the above issue makes very much sense to me.


> The solvers can go in
> 
>  static LinearVariationalSolver::solve() const
>  static NonlinearVariationalSolver::solve() const
> 
> Then it's a matter of taste whether we have VariationalProblem or
> two separate classes. I prefer one class since
> 
> 1. I like overloading in general
> 
> 2. It's a shorter name
> 
> 3. It's (mostly) backwards compatible
> 


I second these. (And I use VariationalProblem a lot... if that counts for anything ;) )

--
Marie


> --
> Anders
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp