Convergence failure in penalty method implementation

[sabyasachi chatterjee]

Hello,

I am trying to solve a nonlinear contact problem using penalty method. The tangent stiffness matrix is of the form  K_e + c * K_p, where K_e and K_p are the elastic and penalty contributions and c is the penalty parameter, which is a large number (in the order of 10^2 to 10^3 in our case). The part of the problem that carries out the linear solve for the incremental displacement  using Newton Raphson method is below:

****************************************************************************************

PETScWrappers::MPI::Vector distributed_incremental_solution(
      locally_owned_dofs, mpi_communicator);
    distributed_incremental_solution = incremental_solution;

    SolverControl solver_control(20000, 1e-5);
    PETScWrappers::SolverCG solver(solver_control, mpi_communicator);
    PETScWrappers::PreconditionBlockJacobi preconditioner(system_matrix);

    solver.solve(system_matrix,
             distributed_incremental_solution,
             system_rhs,preconditioner);

    incremental_solution = distributed_incremental_solution;

    hanging_node_constraints.distribute(incremental_solution);
    solution.add(1.0,incremental_solution);

****************************************************************************************

I receive the following error upon running the code:

------

Iterative method reported convergence failure in step 33. The residual
    in the last step was 0.000778898.

    This error message can indicate that you have simply not allowed a
    sufficiently large number of iterations for your iterative solver to
    converge. This often happens when you increase the size of your
    problem. In such cases, the last residual will likely still be very
    small, and you can make the error go away by increasing the allowed
    number of iterations when setting up the SolverControl object that
    determines the maximal number of iterations you allow.

    The other situation where this error may occur is when your matrix is
    not invertible (e.g., your matrix has a null-space), or if you try to
    apply the wrong solver to a matrix (e.g., using CG for a matrix that
    is not symmetric or not positive definite). In these cases, the
    residual in the last iteration is likely going to be large.

-------

For my problem, I don't require a relative error of the order of say 10^(-12) as is often used in the tutorials and a relative error of 10^(-4) probably should also work. I increased the relative error to 10^(-4) and still got a similar error with the final residual a little more than 10^(-4). I further increased the relative error to 10^(-3), but the accuracy of the results got compromised. Let me know if there is any way to go around this issue.

Also please suggest if there is a way to NOT make the code stop if such a situation arises and instead accept the result as it is and move ahead? 

Finally, do you recommend any other solver in this case .

Thanks,

Sabyasachi

[sabyasachi chatterjee]

I just wanted to correct one small thing. What I mean by relative error before is the residual norm, which is a relative number.

[sabyasachi chatterjee]

Hello,

I have come up with a solution, although there may be other ones using iterative solvers. I changed the solver to SparseDirectMUMPS (from tutorial 62). It seems to have stopped generating the error.  Note that my stiffness matrix is not symmetric ( system_matrix.is_symmetric()  is returning 0 ). The modified lines are below:

--

SolverControl solver_control(100, 1e-3*system_rhs.l2_norm());
PETScWrappers::SparseDirectMUMPS solver(solver_control, mpi_communicator);

solver.solve(system_matrix, distributed_incremental_solution, system_rhs);

--

Best,

Sabyasachi

[Wolfgang Bangerth]

On 7/18/23 00:44, sabyasachi chatterjee wrote:
> Note that my stiffness matrix is not symmetric ( system_matrix.is_symmetric()
> is returning 0 ).

Then there is your mistake. You can only use the CG solver for symmetric and
positive definite matrices. You will want to use GMRES for other matrices.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[blais...@gmail.com]

In addition to Wolfgang's answer. Here are some suggestions.

1. You system is not symmetric. Consequently, it is not a viable idea to use the CG linear solver (see https://en.wikipedia.org/wiki/Conjugate_gradient_method). As suggested, using something like GMRES would be a better idea for your case.

2. Be careful about the preconditioner  you use. Something like ILU, which is pretty blackbox, could do a good job for your problem (most likely). Increasing the fill level will increase the robustness, but make the solver more demanding.

3. If you wish to be able to continue your simulation when such a bug occur, you can catch the exception thrown by the linear solver. An example of this is done here: https://github.com/lethe-cfd/lethe/blob/master/source/solvers/gls_navier_stokes.cc#L1325

In essence, what we do is catch the exception and increase the fill level. The code to achieve this would look something like this:

try
        {
          TrilinosWrappers::SolverGMRES solver(solver_control,
                                               solver_parameters);

            solver.solve(system_matrix, solution, rhs, preconditioner;
        }
      catch (std::exception &e)
        {
            Do something if convergence has failed. 
        }

Best

Bruno

[sabyasachi chatterjee]

Thanks Prof. Bangerth and Bruno for your valuable suggestions. It is much more clear to me now.