dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 02 July 2009 14:45:03 Anders Logg wrote:
> On Thu, Jul 02, 2009 at 02:31:32PM +0200, DOLFIN wrote:
> > changeset:   6398:9a984c7459ed594858b34aac700338a1ea2e6b67
> > parent:      6396:ea89145d8ec9846d689122b1b2cea5c964c09f00
> > user:        Anders Logg <logg@xxxxxxxxx>
> > date:        Thu Jul 02 14:31:14 2009 +0200
> > files:       bench/ode/reaction/bench.log bench/ode/reaction/bench.py
> > demo/ode/collection/cpp/main.cpp demo/ode/courtemanche/cpp/main.cpp
> > demo/ode/harmonic/cpp/main.cpp demo/ode/lorenz/cpp/main.cpp
> > demo/ode/reaction/cpp/main.cpp demo/ode/tentusscher/cpp/main.cpp
> > demo/ode/tentusscher/cpp/tentusscher.h
> > demo/pde/cahn-hilliard/cpp/main.cpp demo/pde/dg/poisson/cpp/main.cpp
> > demo/pde/elasticity/cpp/main.cpp demo/pde/stokes/stabilized/cpp/main.cpp
> > demo/pde/stokes/taylor-hood/cpp/main.cpp dolfin/common/Variable.cpp
> > dolfin/common/Variable.h dolfin/fem/VariationalProblem.cpp
> > dolfin/fem/VariationalProblem.h dolfin/la/GenericLinearSolver.h
> > dolfin/la/KrylovSolver.h dolfin/la/LUSolver.h dolfin/la/LinearSolver.cpp
> > dolfin/la/LinearSolver.h dolfin/la/PETScKrylovSolver.cpp
> > dolfin/la/PETScLUSolver.cpp dolfin/la/PETScLUSolver.h
> > dolfin/la/SingularSolver.cpp dolfin/la/SingularSolver.h
> > dolfin/la/uBLASKrylovSolver.cpp dolfin/la/uBLASKrylovSolver.h
> > dolfin/main/SubSystemsManager.cpp dolfin/main/SubSystemsManager.h
> > dolfin/mesh/MeshFunction.h dolfin/nls/NewtonSolver.cpp
> > dolfin/nls/NewtonSolver.h dolfin/ode/Adaptivity.cpp
> > dolfin/ode/Dependencies.cpp dolfin/ode/Dual.cpp dolfin/ode/GMPObject.h
> > dolfin/ode/MonoAdaptiveFixedPointSolver.cpp
> > dolfin/ode/MonoAdaptiveNewtonSolver.cpp
> > dolfin/ode/MonoAdaptiveTimeSlab.cpp dolfin/ode/MonoAdaptivity.cpp
> > dolfin/ode/MultiAdaptiveFixedPointSolver.cpp
> > dolfin/ode/MultiAdaptiveNewtonSolver.cpp
> > dolfin/ode/MultiAdaptiveTimeSlab.cpp dolfin/ode/MultiAdaptivity.cpp
> > dolfin/ode/ODE.cpp dolfin/ode/ODE.h dolfin/ode/ODESolution.cpp
> > dolfin/ode/ODESolver.cpp dolfin/ode/Partition.cpp dolfin/ode/TimeSlab.cpp
> > dolfin/ode/TimeSlabSolver.cpp dolfin/ode/TimeStepper.cpp
> > dolfin/parameter/DefaultParameters.h dolfin/parameter/NewParameter.cpp
> > dolfin/parameter/NewParameter.h dolfin/parameter/NewParameters.cpp
> > dolfin/parameter/NewParameters.h dolfin/swig/dolfin_shared_ptr_classes.i
> > dolfin/swig/ignores.i description:
> > Work on transition to new parameter system. Used now in most places
> > some work remains. Global parameters still handled by the old system.

Nice work!

This commit has to result in a Super Nova in the FENICS movie ;)

> Some comments on the status of the transition:
>
> 1. All C++ demos and unit tests seem ok and most Python demos, but
> some of them crash (segmentation fault). I haven't tracked this down
> yet. Any suggestions are welcome.
>
> 2. Default values for all parameters are set in functions named
> default_parameters(). For visibility, this function is implemented in
> the header file of each class. Here's an example for the class
> NewtonSolver:
>
>   /// Default parameter values
>   static NewParameters default_parameters()
>   {
>     NewParameters p("newton_solver");
>
>     p.add("maximum_iterations",    50);
>     p.add("relative_tolerance",    1e-9);
>     p.add("absolute_tolerance",    1e-10);
>     p.add("convergence_criterion", "residual");
>     p.add("method",                "full");
>     p.add("report",                true);
>
>     return p;
>   }
>
> The parameter values must be explicitly set in the constructor by a
> call to the function default_parameters(). This function is static
> which means it cannot be placed in the base class Variable and then
> inherited.
>
> 3. Nested parameter sets are handled explicitly from the parent to the
> child. This means that the parent must both add the parameters of the
> child (which makes it possible to set those parameters for the parent
> without an error message about an illegal parameter name) and also
> propagate those values to the child when appropriate. Here's an
> example for the class VariationalProblem:
>
>   /// Default parameter values
>   static NewParameters default_parameters()
>   {
>     NewParameters p("variational_problem");
>
>     p.add("linear_solver", "direct");
>     p.add("symmetric", false);
>
>     p.add(NewtonSolver::default_parameters());
>     p.add(LUSolver::default_parameters());
>     p.add(KrylovSolver::default_parameters());
>
>     return p;
>   }
>
>   LUSolver solver;
>   solver.parameters.update(parameters["lu_solver"]);

I think we should add new parameter set by reference and not by value. Then we 
should be able to populate the childs default parameters with the parameters 
of the parents. Something like this:

  p.add(NewtonSolver::parameters);
  p.add(LUSolver::parameters);
  p.add(KrylovSolver::parameters); 

(Is this the correct syntax?)

The add by reference also makes it possible for a user to collect all 
parameters used in an application into a single parameter set. This set can 
then be used to update all parameters in the application.

Johan

> 4. So in summary, there are more things to think about with the new
> parameter system:
>
>   a. Inherit from Variable (or just declare the parameters variable)
>   b. Implement default_parameters()
>   c. Assign parameters = default_parameters()
>   d. Add parameters for "childs"
>   e. Propagate parameter values to "childs"
>
> It might be possible simplify this. Let's think about it.
>
> 5. The old global prefixes "Krylov", "ODE" have been removed.
>
> 6. It remains to move the few remaining global parameters to a common
> global parameter set.