Thanks Prof. Bangerth and Bruno for your valuable suggestions. It is much more clear to me now.
On Wednesday, July 19, 2023 at 5:44:09 AM UTC+5:30 [email protected] wrote: > 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 > > > On Tuesday, July 18, 2023 at 2:44:54 a.m. UTC-4 [email protected] wrote: > >> 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 >> On Thursday, July 13, 2023 at 6:33:09 PM UTC+5:30 sabyasachi chatterjee >> wrote: >> >>> I just wanted to correct one small thing. What I mean by relative error >>> before is the residual norm, which is a relative number. >>> >>> On Thursday, July 13, 2023 at 12:57:23 PM UTC+5:30 sabyasachi chatterjee >>> wrote: >>> >>>> 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 >>>> >>>> >>>> -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e027bde4-d363-4dc5-849d-e9dbc33a3f70n%40googlegroups.com.
