Anders Logg wrote:
> On Thu, Jul 02, 2009 at 02:31:32PM +0200, DOLFIN wrote:
> 
>> changeset:   6398:9a984c7459ed594858b34aac700338a1ea2e6b67
>> parent:      6396:ea89145d8ec9846d689122b1b2cea5c964c09f00
>> user:        Anders Logg <l...@simula.no>
>> 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/SubS
ystemsManager.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.
> 
> 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.
> 

A common problem for a number of demos is that

     dolfin_set("output destination", "silent");

no longer works. I get the error

    terminate called after throwing an instance of 'std::runtime_error'
   what():  *** Error: Unknown parameter "output destination".

How should the output destination now be controlled?

Garth

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

Reply via email to