You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context
The default behaviour of LinearVariationalSolver is to reassemble the matrix and preconditioner at every solve call. If the matrix type is not mat_free this means recalculating all the entries of the matrix, and if a factorisation method is used for the preconditioner (e.g. lu, ilu) then this will be refactorised.
Problem
If the matrix hasn't actually changed then reassembly is unnecessary. Mass matrix solvers for explicit schemes are the most obvious example of this, but anywhere where a constant reference profile is used will also be doing this.
These operations can be quite expensive. In particular, factorisations do not scale well for large problems or core counts.
Solution LinearVariationalProblem has a constant_jacobian argument to the constructor. If True then the matrix will not be factorised at every step.
For #542, reassembly will only be required when the reference profiles are updated. The constant_jacobian argument can still be set, and the LinearVariationalSolver.invalidate_jacobian() can be called whenever the profiles are updated to tell the solver to reassemble at the next solve call.
Related, sometimes there might be times when a NonlinearVariationalSolver is actually solving a linear system that doesn't need reassembling. If that happens, then these PETSc options will prevent reassembly after the first solve:
Context
The default behaviour of
LinearVariationalSolver
is to reassemble the matrix and preconditioner at everysolve
call. If the matrix type is notmat_free
this means recalculating all the entries of the matrix, and if a factorisation method is used for the preconditioner (e.g.lu
,ilu
) then this will be refactorised.Problem
If the matrix hasn't actually changed then reassembly is unnecessary. Mass matrix solvers for explicit schemes are the most obvious example of this, but anywhere where a constant reference profile is used will also be doing this.
These operations can be quite expensive. In particular, factorisations do not scale well for large problems or core counts.
Solution
LinearVariationalProblem
has aconstant_jacobian
argument to the constructor. IfTrue
then the matrix will not be factorised at every step.For #542, reassembly will only be required when the reference profiles are updated. The
constant_jacobian
argument can still be set, and theLinearVariationalSolver.invalidate_jacobian()
can be called whenever the profiles are updated to tell the solver to reassemble at the nextsolve
call.Related, sometimes there might be times when a
NonlinearVariationalSolver
is actually solving a linear system that doesn't need reassembling. If that happens, then these PETSc options will prevent reassembly after the first solve:The text was updated successfully, but these errors were encountered: