Dear users,
I’m having trouble finding a PC/KSP pair that works for my problem in parallel.
I’m solving linearized Navier-Stokes PDE’s discretized with a finite difference
method in 2D or 3D in a logically rectangular grid, in complex arithmetic.
It obviously works fine with a direct solver but also with GMRES + ILU(3) in
sequential.
I tried different combinations such as
-ksp_type gmres -pc_type asm -sub_pc_type ilu
-ksp_type gmres -pc_type bjacobi -sub_pc_type ilu
but cannot get the relative residuals below 10^(-2), after 2,000 iterations -
even with increasing the number of ILU fill-in levels (up to 5), the number of
GMRES restarts (300 to 1000), options such as -ksp_initial_guess_nonzero or
-ksp_gmres_cgs_refinement_type refine_always. -ksp_monitor_true_residual does
not seem to give more information?
Maybe there’s room for more experimentation but if you could suggest a way to
have a better diagnostic?
With the different equation sets I’m working with, the condition numbers
estimated with the petsc faq method vary between 10^3 and 10^7.
On top of that I have ridiculous fill-in and have to set -pc_factor_fill to 14,
up to 35 (!) sometimes.
For our application we need a lot of discretization points in one spatial
direction and I read somewhere that condition number scales with the square of
discretization steps for FD methods. But is there a way to reduce it in my case?
I’m also aware that fill-in should be inevitably expected when you have a
sparse matrix with a banded structure arising from a FDM. But I was wondering
if there’s something more I can do on the numerical side to, on reduce fill-in
and/or help the iterative solver to converge faster?
I know my discretized PDE’s + boundary conditions are scaled consistently with
regards to matrix entries.
I’m using natural ordering (if my unknowns are a_ij, b_ij the unknown vector
starts with a_00 b_00 a_10 b_10 a_20 b_20 and ends with a_nxny b_nxny…) but I
do not think this has any impact?
Thanks for your support,
Thibaut
