This is quite a bit how the mechanism in Trilinos works.It has the advantage that all components can (in principle) use it. The DOLFIN parameter mechanism could also dispatch to particular linear algebra back-ends (PETSc, Trilinos). Sundance uses this to control the various preconditioner/solver packages in Trilinos (use Amesos with UMFPACK, no use AztecOO with Ifpack preconditioning, etc). It has a think layer that reads the ParameterList and creates the right objects. This relies heavily on polymorphism, which we already have in place thanks to Generic*
While enums are statically checkable at compile-time, parameter lists can be set and altered at run-time without recompilation. Compile/link is something of a chore, and just to change the solver tolerance or preconditioner, one shouldn't have to recompile. Note, PETSc also has a parameter mechanism that is controllable without recompilation, so there must be something to this. I personally prefer the XML format that Trilinos uses to the command-line structure of PETSc. On Tue, Apr 14, 2009 at 8:34 AM, Johan Hake <[email protected]> wrote: > On Tuesday 14 April 2009 04:38:15 Robert Kirby wrote: > > Trilinos does this via the ParameterList class in Teuchos. They have an > > XML format that can be parsed. > > Sundance uses this feature extensively to define solvers from the various > > Trilinos packages. > > I havn't worked with the ParameterList, but I have worked with a similare > type > in Python, called ParameterDict, which is based on the python dict. The > ParameterList actually works more or less as a dict in PyTrilinos. > > A nice feature with both of these is that you can define nested parameters, > which would be nice to have for the next iteration of DolfinParameters. > > I have also found it instructive to let my solvers, or applications "have" > a > ParameterList instead of "beeing", i.e, by inheritance. All my applications > and/or solvers objects also have a default_params() function, which returns > a > predefined set of parameters. This object knows what parameters it have and > complains if one tries to set parameters which are not predefined. It can > do > all sorts of type and range checking too, the first not so usefull in c++, > but in Python. > > An application often consist of many objects which all defines their own > parameters. With the nested feature mentioned above we can collect all > these > into a nested parameter dict for all of the included objects. > > The built in parameters in dolfin could be defined either as a nested > ParameterList type of object: > > ParameterList ODE_params("fixed time step",false, > "ODE solve dual problem", false,...); > ParameterList Krylov_params(...); > ParameterList Newton_params(...); > > ParameterList dolfin_params("ODE",ODE_params, > "Krylov",Krylov_params, > "Newton",Newton_params); > > then one can: > > dolfin_params["ODE"]["fixed time step"] > > or just: > > ODE_params["fixed time step"] > > This is quite straight forward to do in Python but not _so_ easy to do in > c++. > It is probably not worth the effort of making it possible to state such a > ParameterList in the constructor, especially not from c++, but it is quite > convinient. > > > Johan > > > You do have to do a little work in setting this kind of system up, but it > > can provide a fairly intuitive way to control preconditioners, > tolerances, > > iteration counts, etc. > > > > There is no performance penalty in practice since you spend a little bit > of > > time parsing strings/XML, but the setup is amortized over a very large > > calculation. > > > > On Mon, Apr 13, 2009 at 9:18 PM, Garth N. Wells <[email protected]> wrote: > > > Robert Kirby wrote: > > >> I didn't see it as a sub of cpp. thanks for pointing that out. > no_prec > > >> is a better name > > >> given what "None" means in python. > > > > > > I find the enums is C++ clumsy, so is there a disadvantage in just > using > > > strings for setting solvers, preconditioners, etc? > > > > > > Garth > > > > > >> On Mon, Apr 13, 2009 at 3:00 PM, Johan Hake <[email protected] <mailto: > > >> [email protected]>> wrote: > > >> > > >> On Monday 13 April 2009 21:32:22 Robert Kirby wrote: > > >> > Aha. I forgot about the inheritance issue.This should die on > > >> > > >> forming an > > >> > > >> > ILU since I don't have matrix values. > > >> > > > >> > doflin::none is not exposed to PyDOLFIN, so I can't set the > > >> > > >> preconditioner > > >> > > >> > to do nothing rather than attempt to compute an ILU. > > >> > > >> It is exposed to dolfin.cpp. You can for example do: > > >> > > >> dolfin.uBLASKrylovSolver( dolfin.gmres, dolfin.cpp.none ) > > >> > > >> We can allways expose it to dolfin too but however I am not sure > > >> "none" is a > > >> good name. Maybe "no_prec" is better? > > >> > > >> Johan > > >> > > >> > Thanks, > > >> > Rob > > >> > > > >> > On Mon, Apr 13, 2009 at 2:30 PM, Johan Hake <[email protected] > > >> > > >> <mailto:[email protected]>> wrote: > > >> > > On Wednesday 08 April 2009 23:15:42 Robert Kirby wrote: > > >> > > > Hi all,I've gotten a prototype working where I construct > > >> > > > a uBLASSparseMatrix and get it to compute the same result as > > >> > > > my matrix-free uBLASKrylovMatrix. Both of these are > > >> > > > constructed in PyDOLFIN. However, I can feed the > > >> > > > uBLASSparseMatrix I construct into a > dolfin.uBLASKrylovSolver > > >> > > > solve method, but I get a type error when I try to put my > > >> > > > uBLASKrylovMatrix with mult and dim implemented in Python > > >> > > > into the solver. > > >> > > > > > >> > > > In fact, I get a > > >> > > > > > >> > > > TypeError: in method 'uBLASKrylovSolver_solve', argument 2 > of > > >> > > >> type > > >> > > >> > > > 'dolfin::uBLASKrylovMatrix const &' > > >> > > > > >> > > You need to call: > > >> > > > > >> > > dolfin.uBLASKrylovMatrix.__init__(self) > > >> > > > > >> > > to initialize the super class. > > >> > > > > >> > > When I did this I got a bit further. Now an assertion is > > >> > > >> triggered: > > >> > > *** Assertion (_x.size() == _M.size1()) > > >> > > [at dolfin/la/uBLASILUPreconditioner.cpp:41 in solve()] > > >> > > > > >> > > Johan > > >> > > > > >> > > > Not very revealing. I've attached a horribly ugly source > > >> > > >> code for > > >> > > >> > > > anyone interested in doing a post-mortem on this. > > >> > > > > > >> > > > Thanks, > > >> > > > Rob > > >> > > >> > ------------------------------------------------------------------------ > > >> > > >> _______________________________________________ > > >> DOLFIN-dev mailing list > > >> [email protected] > > >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > >
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
