Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only refactor matrices when necessary #565

Open
JHopeCollins opened this issue Oct 23, 2024 · 0 comments · May be fixed by #569
Open

Only refactor matrices when necessary #565

JHopeCollins opened this issue Oct 23, 2024 · 0 comments · May be fixed by #569
Assignees
Labels
optimisation Involves optimising performance of code

Comments

@JHopeCollins
Copy link
Member

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:

'snes_lag_jacobian': -2,
'snes_lag_jacobian_persists': None,
'snes_lag_preconditioner': -2,
'snes_lag_preconditioner_persists': None
@JHopeCollins JHopeCollins self-assigned this Oct 23, 2024
@tommbendall tommbendall added the optimisation Involves optimising performance of code label Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimisation Involves optimising performance of code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants