dolfin team mailing list archive

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

In most Trilinos packages, you also have the opportunity to set these
parameters in code (though I think it's a case-by-case procedure rather than
having a common Parametrized class).  So there could be three methods for
setting parameters:1.) Directly in code
2.) a parameter list via XML
3.) command line

I'm not sure if there are any advantages to having both 2 & 3 in place, but
am happy to be persuaded.

On Tue, Apr 14, 2009 at 10:07 AM, Anders Logg <logg@xxxxxxxxx> wrote:

> 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknkpssACgkQTuwUCDsYZdH77wCdGl4Z6l45y3ojaXigTTwHj1jr
> puQAn0+ki6ea8p+mtBJH0HLssmIYFLFZ
> =rz5t
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>