dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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