dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 14, 2009 at 06:07:39PM +0200, Kent Andre wrote:
> On ti., 2009-04-14 at 17:07 +0200, Anders Logg 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.
> > 
> 
> 
> I suspect there is something in Boost for command-line arguments as
> well.  

That's what I meant. I did not suggest using Boost for storing
parameters.

> Diffpack had very good utilities for this.  It could serve as a model
> for implementation, although it would be nice to not re-invent the
> wheel. In Diffpack the parameters were stored in a dynamic global
> structure. Many classes had a function 'defineParameters()' with a bunch
> of arguments (short commandline argument name, descriptive argument name
> to be used in input-files, the default argument, and a possible prefix
> for multiple instances of the same argument).  Furthermore in 
> Diffpack you would typically do 
> 
> ./demo < inputfile.i 
> 
> After running the simulation you could do 
> 
> generate_readable_inputfile > input_used.i 
> 
> to see all parameters that were set. The input_used.i
> file could then be used in successive simulations. 
> This was very useful in the sense that you did not need to 
> search the source code to find the input parameters. 

All this would be useful to have and it could easily be added to the
parameter system we have.

For example, we already stored whether or not a parameter has been
changed during the execution of a program. It would be easy to also
log which parameters have been accessed.

I'd be very happy if someone with a little programming skill and a
mind for design (and most of all time) would be interested in adding
these features.

-- 
Anders



> Kent
>  
> 
> 
> Kent
> 
> > 
> > 
> > > 
> > > 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
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
>

Attachment: signature.asc
Description: Digital signature