NonlinearVariationalSolver does not pass linear solver parameters
NonlinearVariationalSolver has lu_solver and krylov_solver parameter sets in its parameters but it does not pass them to linear solver created by NewtonSolver.
Comments (29)
-
-
- changed milestone to 1.3
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
Fix issue 10: NonlinearVariationalSolver does not pass linear solver parameters
→ <<cset 90af979ece61>>
-
A fix has been implemented in logg/fix-issue-10 but testing is needed.
This involves a change in the NewtonSolver interface whereby the variables
linear_solver
andpreconditioner
are changed into parameters. In addition, thelu_solver
andkrylov_solver
parameters are moved from NonlinearVariationalProblem to NewtonSolver where they belong more naturally.The interface change might break some demos so I'll do some more testing before merging.
-
reporter @logg Take care not to break
PETScSNESSolver
. I think that @cmaurini or @pefarrell made a delivery of these parameters toPETScSNESSolver
working so it would be silly to fix one and break another. -
I see that now. Corrado and Patrick, could you move the linear solver parameters into PETScSNESSolver? That should make things simpler for you as well. You would not need to extract the parameters inside set_linear_solver_parameters and call that from NonlinearVariationalSolver.
PS: Jan, how does one link to a user when posting on Bitbucket?
-
reporter Type at sign
@
and then continue typing some civil name or user name and bitbucket will help you choose. Unfortunately it acts badly on usernames with dot, like Garth's one. -
reporter @logg will be still those parameters accessible somehow when using high-level
NonlinearVariationalSolver
rather thanNewtonSolver
orPETScSNESSolver
? -
Yes @blechta, they will be accessible via the parameters of the Newton solver:
nonlinear_variational_solver.parameters["newton_solver"]["linear_solver"]["..."]
-
Fix issue 10: NonlinearVariationalSolver does not pass linear solver parameters
→ <<cset cc1b2ae50908>>
-
reporter - changed status to open
Maybe there is still something wrong. Check warnings below.
>python demo_hyperelasticity.py Solving nonlinear variational problem. *** Warning: Unable to set parameters for linear solver type "default". Newton iteration 0: r (abs) = 3.681e+00 (tol = 1.000e-10) r (rel) = 1.000e+00 (tol = 1.000e-09) ...
>python demo_nonlinear-poisson.py No Jacobian form specified for nonlinear variational problem. Differentiating residual form F to obtain Jacobian J = F'. Solving nonlinear variational problem. *** Warning: Unable to set parameters for linear solver type "default". Newton iteration 0: r (abs) = 5.745e+00 (tol = 1.000e-10) r (rel) = 1.000e+00 (tol = 1.000e-06) Solving linear system of size 1089 x 1089 using Epetra LU solver (Amesos_Klu). ...
>python ConstrainedFunctionSpace.py Testing constrained (periodic) FunctionSpace ------------------------------------------------ ......Solving linear variational problem. No Jacobian form specified for nonlinear variational problem. Differentiating residual form F to obtain Jacobian J = F'. Solving nonlinear variational problem. *** Warning: Unable to set parameters for linear solver type "default". Newton iteration 0: r (abs) = 5.871e-02 (tol = 1.000e-10) r (rel) = 1.000e+00 (tol = 1.000e-09) Newton iteration 1: r (abs) = 1.547e-16 (tol = 1.000e-10) r (rel) = 2.635e-15 (tol = 1.000e-09) Newton solver finished in 1 iterations and 1 linear solver iterations. .. ---------------------------------------------------------------------- Ran 8 tests in 0.348s OK
And also in
demo_auto-adaptive-navier-stokes.py
andchapter_10.py
test. Common denominator issolve(F == 0, ...)
. -
Yes, this is a problem related to both NewtonSolver and LinearSolver needing to agree on which solver types are supported and what is meant by "default". I'll take a closer look.
-
I've fixed this now (again...). The naming of linear solvers (direct, iterative, krylov, lu, gmres etc) is somewhat of a jungle and the parameter sets (krylov_solver, lu_solver) must match and do not really correspond to the solvers. This should be discussed on the mailing list and cleaned up (after the release of 1.3).
-
reporter Yes, there are plenty of defficienscis, for example:
When DOLFIN is not compiled with CHOLMOD, then
LinearSolver('cholesky')
redirects toCholmodCholeskySolver
which implements a fallback toUmfpackLUSolver
. It should be discussed ifLinearSolver('cholesky')
should call ratherLUSolver
withsymmetric=True
option.In
PETScLUSolver::select_solver
there is missing a logic for picking Cholesky-capable (as indicated byPETScLUSolver::_methods_cholesky
) solver whensymmetric=True
. -
- changed status to resolved
-
I've created issue #167 for this.
-
Is there any parlicular reason _solver is only created when you call solve(...) on NewtonSolver() object and not in the constructor? I think this leads to seg faults.
solver = NewtonSolver() solver.parameters['linear_solver'] = 'lu' ddm_lu = solver.linear_solver().parameters
Any access to ddm_lu parameters will give seg fault.
-
reporter - changed status to open
Probably, an error message should be raised in
NewtonSolver::linear_solver()
when no_solver
has been created yet.Possibly the construction of the linear solver in
NewtonSolver::solve
could be moved toinit
method so that user can use approach linear solver before solve is called. -
- changed milestone to 1.4
-
- changed status to resolved
This seems to have already been fixed. Accessing the linear solver checks for the solver being instantiated:
GenericLinearSolver& NewtonSolver::linear_solver() const { dolfin_assert(_solver); return *_solver; }
Regardless of this, accessing the parameters of linear solver object won't work. The parameters must be set in the nested parameter set for the Newton solver. These are then passed to the linear solver when solve() is called. Changing the parameters for the linear solver object (if it had been instantiated) would have now effect as the parameters would be overwritten:
_solver->update_parameters(parameters(_solver->parameter_type()));
-
reporter dolfin_assert
is only consistency check in DOLFIN library which has no effect for production builds. Proper check when user might be doing wrong thing isif (!_solver) dolfin_error(...)
.Initialization on first use could be better.
-
Then if we want to be consistent, we would need to change a lot of dolfin_asserts throughout the code to if + sensible error messages.
Do we want to go that route? Opinions?
In this case, initialization on first use would trick the user into believing that the returned object can actually be used for setting for example parameters (which it can't even if it were initialized).
-
reporter -
Fix issue
#10(again): change dolfin_assert --> if + error message when accessing linear solver→ <<cset cd575aa494f3>>
-
The dolfin_assert has now been changed to a sensible (I hope) error message.
-
reporter Great!
Does
_solver->update_parameters(parameters(_solver->parameter_type()));
rewrite parameters of solver passed to constructor of Newton solver?
-
Yes, but perhaps they shouldn't. It would be easy to change.
-
- removed milestone
Removing milestone: 1.4 (automated comment)
- Log in to comment
Issue
#95was marked as a duplicate of this issue.