dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

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

--
Anders