dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Friday October 7 2011 11:42:51 Johan Hake wrote:
> On Friday October 7 2011 08:56:04 Anders Logg wrote:
> > On Fri, Oct 07, 2011 at 08:44:16AM -0700, Johan Hake wrote:
> > > This is great!
> > > 
> > > I have always thought we need to do something with this. However, I
> > > wonder if list_foo is the best name?
> > > 
> > > What bothers me is the "list". We have by purpose skipped most "get"
> > > from
> > > 
> > > methods, as it is implicit for what you want. What with just:
> > >   lu_methods (also see below), preconditioners
> > > 
> > > Also
> > > 
> > >   [list_]methods, [list_]lu_methods and [list_]krylov_methods
> > > 
> > > might be amigous. What methods are we talking about? What with:
> > >   solver_methods, lu_solver_methods, krylov_solver_methods
> > 
> > Sure, let's drop the list_ prefix for the class methods, but I think
> > we should keep the "list_" prefix for the free functions, since they
> > not only return the list of methods/preconditioners, but also print
> > them to screen.
> 
> I think "list_" is not nessesary for the free methods, in particular I
> think printing by default is not what I would expect. It is usefull to
> know what solver methods are available in an api and there are other ways
> of using that information than printing it to screen.

Also would it be possible to only return a vector of string instead of a 
vector of a map of two string. It makes sense to store it as the latter as one 
can then portray the more verbose version of the solver method in the print to 
screen version of the listing. But it makes no sens to return the verbose 
string to the user (it is also much easier to wrap to Python ;)).

Johan

> > And should it be
> > 
> >   KrylovSolver::krylov_solver_methods()
> > 
> > or
> > 
> >   KrylovSolver::krylov_methods()
> > 
> > or
> > 
> >   KrylovSolver::solver_methods()
> 
> I vote for KrylovSolver::solver_methods()
> 
> Johan
> 
> > or
> > 
> >   KrylovSolver::methods()
> > 
> > ?
> > 
> > --
> > Anders
> > 
> > > They are a bit lengthy but if we skip list they might work fine.
> > > 
> > > Johan
> > > 
> > > On Friday October 7 2011 06:20:46 Anders Logg wrote:
> > > > I set out to fix this bug:
> > > >   https://bugs.launchpad.net/dolfin/+bug/868465
> > > > 
> > > > but things spread out and I ended up touching all the la files.
> > > > I won't push this to trunk until I've done some more testing, but
> > > > here's a summary of the changes:
> > > > 
> > > > 1. Each solver defines a set of available methods and preconditioners
> > > > which can be accessed by
> > > > 
> > > >   FooLUSolver::list_methods()
> > > >   
> > > >   FooKrylovSolver::list_methods()
> > > >   FooKrylovSolver::list_preconditioners()
> > > > 
> > > > 2. New global functions that list available methods and Krylov
> > > > solvers
> > > > 
> > > > for the currently chosen backend:
> > > >   list_lu_methods()
> > > >   
> > > >   list_krylov_methods()
> > > >   list_preconditioners()
> > > >   
> > > >   list_solver_methods() = list_{lu + krylov}_methods
> > > > 
> > > > 3. Changes in all factory classes to handle the above
> > > > 
> > > > 4. Checks added to check whether a certain method is available and
> > > > that the preconditioner is set to "none" when using a Krylov method.
> > > > 
> > > > The following output is printed when calling the above methods using
> > > > the PETSc backend:
> > > > 
> > > > LU method     |  Description
> > > > ---------------------------------------------------------------------
> > > > -- ---- -- default       |  default LU solver
> > > > umfpack       |  UMFPACK (Unsymmetric MultiFrontal sparse LU
> > > > factorization) mumps         |  MUMPS (MUltifrontal Massively
> > > > Parallel Sparse direct Solver) pastix        |  PaStiX (Parallel
> > > > Sparse matriX package) spooles       |  SPOOLES (SParse Object
> > > > Oriented Linear Equations Solver) superlu       |  SuperLU
> > > > superlu_dist  |  Parallel SuperLU
> > > > petsc         |  PETSc builtin LU solver
> > > > 
> > > > Krylov method  |  Description
> > > > --------------------------------------------------------------
> > > > default        |  default Krylov method
> > > > cg             |  Conjugate gradient method
> > > > gmres          |  Generalized minimal residual method
> > > > minres         |  Minimal residual method
> > > > tfqmr          |  Transpose-free quasi-minimal residual method
> > > > richardson     |  Richardson method
> > > > bicgstab       |  Biconjugate gradient stabilized method
> > > > 
> > > > Preconditioner    |  Description
> > > > ---------------------------------------------------------------
> > > > default           |  default preconditioner
> > > > none              |  No preconditioner
> > > > ilu               |  Incomplete LU factorization
> > > > icc               |  Incomplete Cholesky factorization
> > > > jacobi            |  Jacobi iteration
> > > > bjacobi           |  Block Jacobi iteration
> > > > sor               |  Successive over-relaxation
> > > > additive_schwarz  |  Additive Schwarz
> > > > amg               |  Algebraic multigrid
> > > > hypre_amg         |  Hypre algebraic multigrid (BoomerAMG)
> > > > hypre_euclid      |  Hypre parallel incomplete LU factorization
> > > > hypre_parasails   |  Hypre parallel sparse approximate inverse
> > > > ml_amg            |  ML algebraic multigrid
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp