MOOSE code still triggering PETSc's unused options warning

[pbehne]

Bug Description

MOOSE is setting PETSc options that are not always used. When this occurs, PETSc emits an annoying unused options warning that the user cannot do anything about.

Steps to Reproduce

So far, I have seen 2 categories of unused options.

The first can be observed by running test/tests/problems/eigen_problem/eigensolvers/ipm.i. This results in the following warning:

WARNING! There are options you set that were not used!
WARNING! could be spelling mistake, etc!
There are 7 unused database options. They are:
Option left: name:-ksp_converged_reason value: ::failed source: code
Option left: name:-mat_mffd_type value: wp source: code
Option left: name:-snes_converged_reason value: ::failed source: code
Option left: name:-snes_mf_operator (no value) source: code
Option left: name:-st_ksp_atol value: 1e-50 source: code
Option left: name:-st_ksp_max_it value: 10000 source: code
Option left: name:-st_ksp_rtol value: 0.01 source: code

The likely solution is not to set these options for Eigen problems.

The second category can be observed by running test/tests/time_integrators/actually_explicit_euler_verification/ee-1d-linear.i This results in the following warning:

WARNING! There are options you set that were not used!
WARNING! could be spelling mistake, etc!
There are 3 unused database options. They are:
Option left: name:-snes_converged_reason value: ::failed source: code
Option left: name:-snes_monitor_cancel (no value) source: code
Option left: name:-snes_type value: ksponly source: code

I have not yet investigated this category. All failures can be viewed here: https://civet.inl.gov/event/184918/

Impact

Users are annoyed with warnings that are not their fault.

[Optional] Diagnostics

No response

[pbehne]

I'll work on this one.

[lindsayad]

For the latter case, we are likely not doing a nonlinear solve at all, which is why you see the unused options for SNES

[pbehne]

I agree. The time integrator used in ee-1d-linear.i is ActuallyExplicitEuler, which only does a linear solve per time step. This will be the case for any integrator derived from ExplicitTimeIntegrator.

Take -snes_converged_reason, for example. It is an option listed in getCommonPetscFlags. All flags returned by this function are turned on by FEProblemSolve.

Aside: FEProvlemSolve is derived from NonlinearSolveObject. Using this in conjunction with problems that do not require nonlinear solves may not make the most sense. However, it may be the easiest implementation?

Anyway, this is how I would proceed: Let petsc options be set the way they currently are. Identify types of simulations that don't use certain groups of petsc options. Turn these options off from the base class of each simulation type.

What do you think?

[lindsayad]

What do you consider the base class of each simulation type?

[pbehne]

I'd consider the base class as the least derived class where the unused warning always occurs.

For the example above, I would turn off all snes options in ExplicitTimeIntegrator. I would create a function (something like PetscSupport::turnOffSNESOptions and call that.

[pbehne]

I just noticed something else about the unused options:

Option left: name:-snes_converged_reason value: ::failed source: code Option left: name:-snes_monitor_cancel (no value) source: code Option left: name:-snes_type value: ksponly source: code

According to petsc documentation here, -snes_type ksponly has the effect that:

Nonlinear solver that performs one Newton step with KSPSolve() and does not compute any norms. Note The main purpose of this solver is to solve linear problems using the SNES interface, without any additional overhead in the form of vector norm operations.

Do we even need things like ExplicitTimeIntegrator in MOOSE if we can just set this flag to do a linear solve while reusing nonlinear solve code?

[lindsayad]

Yes because sometimes we don't even want to do a KSP solve. With an explicit time integrator, if you lump the mass matrix onto the diagonal (or are doing finite volume), then the inverse of the system matrix is just the reciprocal of the diagonal, so you don't need any KSP solve machinery.

[lindsayad]

Anyway, this is how I would proceed: Let petsc options be set the way they currently are. Identify types of simulations that don't use certain groups of petsc options. Turn these options off from the base class of each simulation type.

This sounds good!