Suppress warning "The linear system solution has not converged" if no linear solver iterations are needed

[michelebucelli]

Problem

It sometimes happen that the linear solver does not need to run any iteration, because the residual for the initial guess is already below the tolerance. This is checked by an if statement in gmres_s and gmres_v. If this early termination condition is verified, the flag ls.suc is not set to true, so that the caller interprets this behavior as a linear solver failure, and a warning is printed.

The warning is a bit annoying, but more importantly it might be misleading, since the linear solver actually did reach convergence (or better, it was already at convergence for the provided initial guess).

Solution

I propose setting ls.suc = true in the early termination branch of gmres_s and gmres_v, to suppress the unnecessary/incorrect warning.

Additional context

• This behavior appeared for me due to inconsistent setting of non-linear and linear solver tolerances. The linear solver tolerance was accidentally higher than the non-linear one, so that the linear solver would run no iterations and the non-linear solver would stagnate. I found the warning slightly misleading in this context, as I thought something was wrong with the linear system while in fact I had just set the tolerances incorrectly.
• I have encountered this behavior for the GMRES solver, but I haven't checked if the same might happen for other solvers.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[ktbolt]

@michelebucelli This is a welcome fix; sure to confuse users!

But perhaps lets rename ls.suc to ls.success while we are in the code; always interpret this as ls.sucks on a bad day or ls.sucre on a good day ...

[michelebucelli]

@ktbolt I agree, happy to fix that as well!

[ktbolt]

@michelebucelli I'd like to take a closer look at what is going on in gmres. Please send me a link to your simulation files.

[michelebucelli]

The issue became apparent when running a coupled electromechanics simulation for work on #519, which is implemented in this branch. If you want to check that out I can send you the test case that I have, but if you prefer I can try to reproduce the issue on the main branch (it will probably be a more contrived example).

[ktbolt]

@michelebucelli Send me the test case you used in your branch.

[michelebucelli]

Here's a case that triggers the warning (before the changes to the GMRES). On timestep 1, with one core, the EP model is solved twice, at the second Newton iteration there's no linear iterations to be done, the solver does none, and the warning is printed.

electromechanics-slab.zip

The warning can be suppressed by fiddling with the tolerances, e.g. by setting a very small absolute tolerance on the electrophysiology linear solver (say, $10^{-16}$), so that the initial guess at the second iteration is no longer good enough.

[ktbolt]

I ran your simulation with your branch and see the warnings.

Not setting ls.suc to true for early termination of gmres_s and gmres_v if the residual is smaller than absTol is from the original Fortran code. In that code if ls.suc is not true then a ! (surprise !) is added to the lsIt result in the histor.dat file, for example

 EP     3-3  9.2669  [-215 1.6E-11 4.6E-11 1.00000]  !   0    0   0!

We added a more useful warning message after the !. I'm guessing that the original Fortran code just wanted to flag the linear solve as sort of unexpected wrt to have the residual < absTol set for the problem.

So the question is should we add a message explaining what !0 0 0! means for the linear solve; probably remove the ! as well

 EP     3-3  9.2669  [-215 1.6E-11 4.6E-11 1.00000]  [0    0   0] INFO: No linear solve performed: residual < Absolute_tolerance

[michelebucelli]

So the question is should we add a message explaining what !0 0 0! means for the linear solve; probably remove the ! as well

Tl;dr: I think it makes sense to remove the message.

More verbosely: I think that the answer depends on whether convergence in zero iterations can happen in "legitimate" cases (i.e. in cases where the user has configured tolerances and other parameters correctly). One such case is a system evolving slowly relative to the time step size.

For example, in an electrophysiology simulation, after repolarization has ended, the system just sits there waiting for the next stimulus. During this phase, it would be pretty normal and expected for the linear solver to do very few, and sometimes zero, iterations (maybe one iteration every few time steps), because the solution is changing very slowly and the diffusion step might have nothing to update. I think a message here might incorrectly suggest to the user that something is going wrong, even if phrased as "INFO", instead of "WARNING".

It might be a good idea, however, to have some error or warning during startup if the user sets incompatible tolerances for non-linear and linear solvers, which is what alerted me to this in the first place. The most trivial check would be to assert that the absolute tolerance of the linear solver is strictly less than that of the non-linear one.

Relative tolerances are more complicated to check (and maybe impossible) because the two solvers normalize with respect to different references (I think).