dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 14, 2009 at 10:17:06AM -0500, Robert Kirby wrote:
> 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.

1. Obvious

2. Good for storing default values system-wide and on a per-user basis in
say ~/.dolfin (but less obvious that it will be useful). But maybe most
of all to store the set of parameters used for a particular simulation
and remember those parameters.

3. Good for quickly changing an option without needing to edit any
file (either code or XML).

The first option is already in place. The second would require little
work: XML input/output already working, just need to decide on a
location for the XML files. The third would require some work but not
that much.

Anyone is welcome to have a go at these, but I have limited time right
now myself.

-- 
Anders


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

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

Attachment: signature.asc
Description: Digital signature