dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Saturday October 8 2011 04:33:44 Anders Logg wrote:
> On Fri, Oct 07, 2011 at 05:01:10PM -0700, Johan Hake wrote:
> > 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 ;)).
> 
> It would be very simple to fix, but I think it is useful to return it
> as a list of pairs. For one thing, it can be used in GUI wrappers with
> a drop-down menu that displays the descriptions (second item in each
> pair) and sends the method name (first item in each pair) to DOLFIN.

Ok.

> So we have two functions: a simple version for just printing the
> options (list_krylov_solver_methods) and one more advanced for users
> who actually need to access the strings as part of a program (GUI or
> not). Since there is already a simple function I think we don't need
> to make the "advanced" function simpler by removing information from
> it.

Sounds good.

Johan

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