dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Oct 08, 2011 at 11:19:09PM -0700, Johan Hake wrote:
> 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

We already have the function named summary(). It can be renamed to
list_timings() if it makes you happier. :-)

>   has_linear_algebra_backend
>
> instead of
>
>   has_la_backend

Sounds good.

> 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.

Sounds good.

--
Anders