In most Trilinos packages, you also have the opportunity to set these parameters in code (though I think it's a case-by-case procedure rather than having a common Parametrized class). So there could be three methods for setting parameters:1.) Directly in code 2.) a parameter list via XML 3.) command line
I'm not sure if there are any advantages to having both 2 & 3 in place, but am happy to be persuaded. On Tue, Apr 14, 2009 at 10:07 AM, Anders Logg <[email protected]> wrote: > On Tue, Apr 14, 2009 at 09:48:51AM -0500, Robert Kirby wrote: > > 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. > > It would be unproblematic to have both: a utility for parsing > command-line arguments which override parameters stored in XML files. > > I suspect there's something in Boost we could use for the parsing. > > -- > Anders > > > > > > 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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknkpssACgkQTuwUCDsYZdH77wCdGl4Z6l45y3ojaXigTTwHj1jr > puQAn0+ki6ea8p+mtBJH0HLssmIYFLFZ > =rz5t > -----END PGP SIGNATURE----- > > _______________________________________________ > 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
