dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Sunday October 9 2011 01:21:46 Anders Logg wrote:
> 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. :-)

Yes! I always have to check old code to figure out what I was supposed to call 
to get the timings. summary isn't intuitive ;) But then is list_ the correcy 
prefix? What with display_ if that is what that function is doing, or are the 
list_ functions also returning stuff?

> >   has_linear_algebra_backend
> > 
> > instead of
> > 
> >   has_la_backend
> 
> Sounds good.

Ok, will add this.

Joha

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