| Thread Previous • Date Previous • Date Next • Thread Next |
On 05/01/11 18:52, Marie E. Rognes wrote:
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, LMy 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...GarthWe 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@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
