dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Saturday October 8 2011 04:29:43 Anders Logg wrote:
> On Fri, Oct 07, 2011 at 11:42:51AM -0700, 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.
> 
> Yes, that's why there are two functions. A user who wishes to just
> print the list of available options can call
> 
>   list_krylov_solver_methods()
> 
> and a user who wishes to get the list of options can call
> 
>   KrylovSolver::solver_methods()
> 
> I think it's important that there is an easy way to just print the
> options to screen, and it should be a free function since solve() is a
> free function.
> 
> I think the above works well: a free function
> list_krylov_solver_methods for casual users who rely on the solve()
> function and KrylovSolver::solver_methods() for "advanced" users who
> like to create solver objects.

Sure but AFAIK nowwhere else in the library do we print something to screen 
using a dedicated function. We have info(foo) for that. However, I see that it 
is not that easy to call info on a free function. If we add another list_ 
function I might be more happy! What with list_la_backends (or 
list_linear_algebra_backends). We already have 

  has_la_backend("Foo")

(at least in the Python interface) we can then settle on has_ and list_ as 
convinient functions for la stuff (as already suggested by Garth) :) If so I 
can add that to the C++ interface. Should we use the longer namings

  has_linear_algebra_backend 

instead of

  has_la_backend

It resonate better with the parameters name.

On a side note on the use of info. Would it be usefull to include the 
available solvers and preconditioner when one call info on a solver? That 
would be intuitive and would make sense. This while keeping the 
solver_methods() method.

Johan

> 
> --
> Anders
> 
> > > 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()
> > > 
> > > ?
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp