dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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 <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
> 
> 
> 
> 

> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature