dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

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.

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