dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 14, 2009 at 11:30:58AM +0800, Garth N. Wells wrote:
> 
> 
> 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

The problem might be that the parameters may be needed at the time of
construction. Consider this:

  KrylovSolver solver;
  solver.set("preconditioner", "ilu");

This would only work if the information about the preconditioner is
not used at the time of construction (which is actually the case at
least for PETScKrylovSolver).

But when possible, it would be good to make better use of the
parameter system (and cleaning up the list of options).

The parameter system already supports XML input/output. Perhaps we
should store the default parameters in a system wide XML file instead
of hard-coded into DefaultParameters.h?

We could also look for parameter files in a user's home directory and
the current working directory.

-- 
Anders


> 
> > 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 <gnw20@xxxxxxxxx 
> > <mailto:gnw20@xxxxxxxxx>> 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 <hake@xxxxxxxxx
> >         <mailto:hake@xxxxxxxxx> <mailto:hake@xxxxxxxxx
> >         <mailto:hake@xxxxxxxxx>>> 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
> >         <hake@xxxxxxxxx <mailto:hake@xxxxxxxxx>
> >            <mailto:hake@xxxxxxxxx <mailto:hake@xxxxxxxxx>>> 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
> >         DOLFIN-dev@xxxxxxxxxx <mailto:DOLFIN-dev@xxxxxxxxxx>
> >         http://www.fenics.org/mailman/listinfo/dolfin-dev
> > 
> > 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature