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. > > 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. >
DOLFIN has a parameter system which is used for tolerances, etc (I think that io of the parameters is on the TODO list). Perhaps we should use it where we currently have enums. Any opinions? Garth > 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] > <mailto:[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]> <mailto:[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]> > <mailto:[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] <mailto:[email protected]> > http://www.fenics.org/mailman/listinfo/dolfin-dev > > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
