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