dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxxxxxxx>]

Quoting Anders Logg <logg@xxxxxxxxx>:

> On Tue, Dec 06, 2005 at 11:49:55PM +0100, Garth N. Wells wrote:
> 
> > I was thinking about defining PETSc preconditioners and a "userdefined"
> > preconditioner using enum. We could define PETSc preconditioners, a
> "dolfin"
> > preconditioner and a "userdefined" preconditioner.
> 
> With the enum approach, I don't think we need to have a case called
> "userdefined". Either someone does
> 
>     solver.setPreconditioner(Preconditioner::ilu);
> 
> thus choosing one of the built-in preconditioners, which can be
> something from PETSc or something that we have implemented in DOLFIN.
> 
> Or, a user does
> 
>     solver.setPreconditioner(pc);
> 
> where pc is an instance of the class Preconditioner (with member
> function solve() overloaded).

This is how I've done it now. KrylovSolver is looking cleaner, Preconditioner
looks a bit messy. Feel free to rearrange.

> 
> The only thing we would have to do would thus be to put the enums
> in the Preconditioner class and overload setPreconditioner in
> KrylovSolver so it either accepts Preconditioner::type or
> Preconditioner.
> 
> > I'm not sure if it's easier to put these into the class Preconditioner or
> to
> > break them up in separate classes.
> 
> The above is the easiest I think, but perhaps we want to have only one
> KrylovSolver::setPreconditioner() so that in particular one can pass
> Preconditioner objects around in the code (and there would not be two
> kinds of preconditioners: either Preconditioner or the fake
> Preconditioner::Type).
> 
> Then we could declare a number of subclasses of Preconditioner, such
> as
> 
>     class ILU : public Preconditioner { ... }
>     class SOR : public Preconditioner { ... }
> 
> These would not actually implement the preconditioning in question,
> but instead KrylovSolver would check that this is a special type of
> preconditioner (a PETSc built-in) and just set the choice of
> preconditioner in PETSc.
> 
> We could collect all of these in say Preconditioners.h since each
> class will be very small.
> 
> With this approach, a user would do
> 
>     ILU ilu;
>     KrylovSolver solver;
>     solver.setPreconditioner(ilu);
> 

The way to go in the future could involve both methods of setting the precondtioner.

     solver.setPreconditioner(Preconditioner::ilu);

is really simple and will suffice for the majority of problems, while 

     ILU ilu;
     ilu.inPlace(true);
     KrylovSolver solver;
     solver.setPreconditioner(ilu);

would allow details of the PETSc preconditioner to be set by the user. For some
of the preconditioners, such as Hypre, a lot of parameters can be set.

Garth


> Don't know which approach is best, the enums or this one.
> 
> /Anders
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
>