On Thu, Jul 02, 2009 at 03:04:34PM +0200, Johan Hake wrote: > 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 <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/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!
Not so nice. I managed to push some changes I didn't intend to push just yet which introduces some new bugs. It should be fixed in a little while. Update: just pushed. > This commit has to result in a Super Nova in the FENICS movie ;) That's my plan. But in general, I try to avoid supernovas since they are potentially hard to merge. :-) > > 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. I began doing this, but I got into difficulties. Consider the following example. A user writes: VariationalProblem problem(a, L, bc); problem.parameters["newton_solver"]("relative_tolerance") = 1e-16; For this to work the nested parameter set for the Newton solver must e created already in the constructor of VariationalProblem. But at this time, the NewtonSolver has not been created. It gets created later when the user calls solve(). I didn't see an easy way around this. -- Anders > 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. > >
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev