dolfin team mailing list archive

[Robert Kirby <robert.c.kirby@xxxxxxxxx>]

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 <hake@xxxxxxxxx> 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 <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>> 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>> 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
> > >> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>
>