dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Oct 09, 2011 at 01:42:00PM -0700, Johan Hake wrote:
> 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?

Yes, but it should probably not return anything.

Other options are

  info_  (natural since we have info for printing)
  print_

> > >   has_linear_algebra_backend
> > >
> > > instead of
> > >
> > >   has_la_backend
> >
> > Sounds good.
>
> Ok, will add this.

ok.

--
Anders


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