On 05/01/11 18:52, Marie E. Rognes wrote:
On 5. jan. 2011, at 19:30, Anders Logg<l...@simula.no> 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.
A linear solver is only one ingredient in a nonlinear solver. There is
also modified Newton, quasi-Newton, path following, Newton-Krylov,
preconditioner re-use, . . . .
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
We could merge a lot of classes that don't share code into one class,
and distinguish cases through the constructor arguments, but that would
be a bad design. If they don't share code, they shouldn't be in the same
class.
I would like to have LinearVariationalProblem and
NonlinearVariationalProblem, and I'm pretty strongly opposed to
artificially forcing both into once class if there is no/minimal code
sharing. A compromise design could be:
class LinearVariationalProblem : GenericVariationalProbem
class NonlinearVariationalProblem : GenericVariationalProbem
and for simple usage cases
class VariationalProblem
{
public:
// constructors
VariationalProblem( .... )
{ variational_problem = new LinearVariationalProblem; }
VariationalProblem( .... )
{ variational_problem = new NonlinearVariationalProblem; }
void solve(Function& u)
{ variational_problem->solve(u); }
private:
GenericVariationalProblem* variational_problem ;
}
Garth
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
