dolfin team mailing list archive

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

Anders Logg wrote:
> On Thu, Aug 10, 2006 at 10:08:29AM +0200, Garth N. Wells wrote:
> > Anders Logg wrote:
> > > Garth, what is the status of the linear algebra? If you are happy,
> > > I'll take another look and then we can take care of the remaining stuff.
> > It's pretty much done. I still need to fix the selection of the 
> > preconditioner when choosing by name,
> >
> >    PETScKrylovSolver solver(PETScPreconditioner::ilu);
> >
> > You'll see that there is an enum list in PETScPreconditioner and 
> > uBlasPreconditioner. I'd like to change this to just one list so it 
> > won't matter whether PETSc or uBlas is being used, and if the requested 
> > preconditioner is not available, then a default is chosen. Should then 
> > be possible to do
> >
> >    KrylovSolver solver(Preconditioner::ilu);
> >
> > Same story for choosing the Krylov method by name. Any suggestions?
>
> Sounds very good. But one problem may be if we choose to make
> Preconditioner a typedef as we have for the other types. Then we can't
> place an enum inside the class.
>
> On the other hand, if we keep the enums inside PETScPreconditioner and
> uBlasPreconditioner respectively, then making the typedef would solve
> this also so one can do
>
>     KrylovSolver solver(Preconditioner::ilu);
>
> Then we wouldn't need to worry about preconditioners that don't exists
> since Preconditioner would be typedefed to the specific preconditioner
> base class that only contains existing preconditioners. I'd suggest we
> do it this way instead.

The problem with this is that the enum list in PETScPreconditioner and 
uBlasPreconditioner must be identical. For example, if you now do

  uBlasKrylovSolver(uBlasPreconditioner::hypre_amg);

you will get an error. Need to keep both enum lists in mind whenever 
adding a preconditioner.


> > I'm also thinking of moving the individual Krylov methods out of 
> > uBlasKrylovSolver.
>
> Yes why not. Then one would have two entries to both preconditioners
> and Krylov methods (at least for uBlas): either an enum or by choosing
> a specific class, like uBlasGMRES or so.

To keep the interface simple and consistent with the PETSc Krylov 
interface, I was thinking about making the member function (just a 
solver function) of uBlasGMRES, for example, private and making 
uBlasKrylovSolver a friend class. My intention in moving the actual 
solvers out of uBlasKrylovSolver is to limit the size of 
uBlasKrylovSolver.h as Krylov methods are added.

Garth



> For PETSc, only enums would be available since the solvers and
> preconditioners are implemented by PETSc and not by us.
>
> > > Here's a suggested plan:
> > >
> > >        1. Review/cleanup (Garth)
> > >        2. Review/cleanup/class diagram (Anders)
> > >        3. Fix PyDOLFIN linear algebra including typedefs (Johan J)
> > >        3. Finish linear algebra section in manual (Johan H)
> > >        4. Remove PETSc ifdefs from Navier-Stokes module (Johan H)
> > I did this yesterday. Just one PETSc ifdef left for choosing the Hypre 
> > preconditioner.
>
> ok, I just did a grep for HAVE_PETSC.
>
> > >        4. Remove PETSc ifdefs from elasticity module (Johan J)
> > I removed them from elasticity (not elasticity-updates). The module 
> > needs some cleaning up still.
>
> ok, maybe Johan can look at this. If it requires too much work to sort
> out now, then maybe a temporary fix could be added that generates a
> run-time error with an informative message?
>
> > >        4. Unit tests for linear algebra (Anders, Garth)
> > >        4. Demos for linear algebra (Garth)
> > >        4. Benchmarks for linear algebra (Garth)
> > >        4. Review/cleanup of ODE solvers (Anders)
> > >
> > > What more do we want to finish before the next release?
> > Sounds good.
>
> ok.
>
> /Anders
>
>
> > Garth
> >
> > > Hopefully we can make a concentrated effort and make the release
> > > quickly so we can move on to work on the mesh.
> > >
> > > /Anders
> > > _______________________________________________
> > > DOLFIN-dev mailing list
> > > DOLFIN-dev@xxxxxxxxxx
> > > http://www.fenics.org/mailman/listinfo/dolfin-dev
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev