dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Nov 11, 2005 at 12:22:07PM +0100, Garth N. Wells wrote:

> Are there any plans to move the setting of parameters in the class GMRES to a
> another class or parameter system? I need to set the same types of parameters for
> for the linear solve step in the class NonlinearSolver, as well as parameters
> relating to the Newton iterations. There are so many they will swamp the functions
> that do the real work.

Yes, for two reasons. In addition to the reason you give, more than
one object want to share the same parameters, I think we should avoid
creating classes with a lot of .setFoo() member functions.

I would like to have a system where we have a hierarchy of
parameters. There should be a global parameter database (like we have
now) and each object should be able to override the global choice.

Something like the following:

    dolfin_set("tolerance", 1e-10);
    GMRES gmres1; // automatically picks tolerance 1e-10 from global value
    GMRES gmres2; // automatically picks tolerance 1e-10 from global value
    gmres1.set("tolerance",  1e-16); // overrides global value

This requires something more sofisticated than what we have now, which
is just the global database. I imagine something like a base class Parametrized
that we can subclass for the classes that need to keep parameters.

There should also be some functionality for reading parameters from
user preferences, system preferences and from the command line, with
some order of priority.

I've been discussing this with some people from Simula (most notably
Hans Petter Langtangen) so we might end up creating a new FEniCS
component for a common parameter system.

In the meantime, just throw any parameters you like into the global
database (src/kernel/settings/dolfin/Settings.h) and call dolfin_get()
in the constructor of GMRES to get the values, and keep the current
member function setAtol() etc so they can be overridden locally.

> Also, would it be an idea to change the name of the class GMRES to KrylovSolver,
> and provide functions to allow the user to set the exact method and
> preconditioner. The default would be to use the PETSc default (GMRES + some
> preconditioner) as we do now in the class GMRES.

Yes, that's probably better. Let's make a class KrylovSolver to
replace the current GMRES. And let's also create a new class GMRES
that specifically does GMRES, but where solve() is static:

    GMRES::solve(A, x, b);

This function would just create a KrylovSolver object and call it.

/Anders