Nonlinear solver generalizations by lindsayad · Pull Request #4537 · libMesh/libmesh

lindsayad · 2026-09-01T21:55:23Z

I want to use MATSHELL for the Jacobian and possibly MATAIJ for the preconditioning matrix so need to develop some additional support for that use case

Importantly this both sets the wrapper as initialized and instructs the wrapper not to destroy the PETSc matrix on exit Co-Authored-By: Claude <noreply@anthropic.com>

Co-Authored-By: Claude <noreply@anthropic.com>

moosebuild · 2026-09-02T01:38:23Z

Job Coverage, step Generate coverage on 01c924a wanted to post the following:

Coverage

	54e0d5	#4537 01c924
	Total	Total	+/-	New
Rate	65.99%	65.98%	-0.01%	100.00%
Hits	79562	79578	+16	60
Misses	40996	41025	+29	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

Co-Authored-By: Claude <noreply@anthropic.com>

…package Co-Authored-By: Claude <noreply@anthropic.com>

lindsayad · 2026-09-02T20:29:04Z

Still waiting on that MOOSE master merge to get those solid mechanics test fixes!

roystgnr · 2026-09-08T00:52:14Z


  explicit PetscMFFDMatrix(const Parallel::Communicator & comm_in);

-  PetscMFFDMatrix & operator=(Mat m);


Let's keep this around for backwards compatibility? Pretty specialized so you can deprecate it if you want, but it's been around for two years and was never marked libmesh_experimental().

Should the backwards compatibility include its undesirable behavior like _destroy_on_exit = true? 😢

Did you want to deprecate this like @roystgnr suggested? Also, any reason that it became inlined when it wasn't before?

I'll remove the inlining which will decrease the PR diff. I don't think I'll deprecate at this point because I think the new operator= behavior (through assign) is what we want

roystgnr · 2026-09-08T00:54:44Z

+void
+PetscMatrixShellMatrix<T>::zero()
+{
+  libmesh_error();


Could we libmesh_error_msg("Called a method that is unimplemented for arbitrary shell matrices") or something, here and elsewhere in the new overloads?

roystgnr · 2026-09-08T00:58:35Z

+
+  /**
+   * An optional matrix to use as the actual Jacobian operator (Amat), distinct from \p matrix
+   * (used as the preconditioning matrix, Pmat). See set_operator_matrix().


This seems like the opposite of what I would have expected. implicit_system.h refers to its matrix as the "system matrix" in solves of "Ax=b" at one point, and as the Jacobian matrix at another. Shouldn't that stay "A", and "P" be the new matrix?

For a nonlinear solver, it is very common to unseat the A matrix and replace it with matrix-free approximations of the Jacobian action via finite differencing of residual evaluations, whereas it is much less common to unseat the preconditioning matrix because you generally need an explicit matrix representation in order to form a preconditioner. Put another way, if we were to assert that the libmesh system matrix is the A matrix, that assertion would fail for perhaps more than 50% of MOOSE simulations because of use of PJFNK and -snes_mf_operator whereas if you were to assert that the libmesh system matrix is the P matrix then I'm not aware of any places where that assertion would fail. But I'm sure you could point me to a libmesh example that would fail 😄

I want to do something similar as PETSc matrix-free finite-differencing, but use MATSHELL instead of MATMFFD where the shell matrix is owned by libMesh/MOOSE, not created and held by PETSc as the latter is done. Our shell matrix will define operations like MatGetDiagonal and MatMult

It might be good if some of this discussion/clarification made it into a comment in the code regarding the colloquial naming conventions surrounding "Jacobian", "system", "Pmat" and "Amat".

Ok I've added discussion in 01c924a but I'm not 100% sure this is the right place nor whether it helps reduce confusion

Co-Authored-By: Claude <noreply@anthropic.com>

Refs failures on libMesh/libmesh#4537

roystgnr

I think you've convinced me on this, but it's a big enough design decision that I'd like to give @jwpeterson some time to look too

jwpeterson

If I understand correctly, this is about adding better MATSHELL support for the nonlinear solver, which sounds useful. I also like that you added several tests.

jwpeterson · 2026-09-17T13:15:21Z


  explicit PetscMFFDMatrix(const Parallel::Communicator & comm_in);

-  PetscMFFDMatrix & operator=(Mat m);


Did you want to deprecate this like @roystgnr suggested? Also, any reason that it became inlined when it wasn't before?

jwpeterson · 2026-09-17T13:22:59Z

+
+  /**
+   * An optional matrix to use as the actual Jacobian operator (Amat), distinct from \p matrix
+   * (used as the preconditioning matrix, Pmat). See set_operator_matrix().


It might be good if some of this discussion/clarification made it into a comment in the code regarding the colloquial naming conventions surrounding "Jacobian", "system", "Pmat" and "Amat".

Co-Authored-By: Claude <noreply@anthropic.com>

lindsayad and others added 3 commits September 1, 2026 14:54

Make PetscMatrixShellMatrix instantiable

3dffbf5

Fix PetscMFFDMatrix Mat assignment

50994df

Importantly this both sets the wrapper as initialized and instructs the wrapper not to destroy the PETSc matrix on exit Co-Authored-By: Claude <noreply@anthropic.com>

Add two-matrix arg solve overload to NonlinearSolver

bb24853

Co-Authored-By: Claude <noreply@anthropic.com>

lindsayad and others added 3 commits September 2, 2026 09:20

Add unit tests

e1fa43f

Co-Authored-By: Claude <noreply@anthropic.com>

Run bootstrap

b3a1a3c

Use libmesh petsc shims

8fe8480

Co-Authored-By: Claude <noreply@anthropic.com>

lindsayad mentioned this pull request Sep 2, 2026

libmesh/Kokkos-based p-multigrid idaholab/moose#33645

Draft

Guard nonlinear implicit system test with necessary nonlinear solver …

d8ad017

…package Co-Authored-By: Claude <noreply@anthropic.com>

lindsayad marked this pull request as ready for review September 2, 2026 20:28

roystgnr requested changes Sep 8, 2026

View reviewed changes

lindsayad and others added 2 commits September 8, 2026 09:21

Explicitly allow calling zero() on shells

762f528

Co-Authored-By: Claude <noreply@anthropic.com>

More informative error message in PetscMatrixShellMatrix methods

740f68b

lindsayad mentioned this pull request Sep 8, 2026

Bump abs_zero for more interaction_integral tests idaholab/moose#33693

Merged

lindsayad added a commit to idaholab/moose that referenced this pull request Sep 8, 2026

Bump abs_zero for more interaction_integral tests

e03072a

Refs failures on libMesh/libmesh#4537

lindsayad requested a review from roystgnr September 8, 2026 21:07

roystgnr approved these changes Sep 8, 2026

View reviewed changes

Add back PetscMFFDMatrix::operator=

a8efa5f

lindsayad mentioned this pull request Sep 8, 2026

osx-arm64 Perl build 8 is missing the RPATH for libperl.dylib conda-forge/perl-feedstock#78

Open

1 task

jwpeterson approved these changes Sep 17, 2026

View reviewed changes

lindsayad and others added 3 commits September 17, 2026 09:21

Make sure to clear in assign if we already own a mat

80e1f72

Co-Authored-By: Claude <noreply@anthropic.com>

Keep operator= definition outside of the class definition

b61f1a7

See about adding the discussion blurb John requested

01c924a


		explicit PetscMFFDMatrix(const Parallel::Communicator & comm_in);

		PetscMFFDMatrix & operator=(Mat m);

Conversation

lindsayad commented Sep 1, 2026

Uh oh!

moosebuild commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage

Uh oh!

lindsayad commented Sep 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lindsayad Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lindsayad Sep 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roystgnr left a comment

Choose a reason for hiding this comment

Uh oh!

jwpeterson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

moosebuild commented Sep 2, 2026 •

edited

Loading

lindsayad Sep 8, 2026 •

edited

Loading

lindsayad Sep 8, 2026 •

edited

Loading