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 : [email protected] > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
