[petsc-users] fieldsplit preconditioner for indefinite matrix

Matthew Knepley knepley at gmail.com
Sat Apr 16 18:15:08 CDT 2016


On Sat, Apr 16, 2016 at 6:54 PM, Hoang Giang Bui <hgbk2008 at gmail.com> wrote:

> Hello
>
> I'm solving an indefinite problem arising from mesh tying/contact using
> Lagrange multiplier, the matrix has the form
>
> K = [A P^T
>        P   0]
>
> I used the FIELDSPLIT preconditioner with one field is the main variable
> (displacement) and the other field for dual variable (Lagrange multiplier).
> The block size for each field is 3. According to the manual, I first chose
> the preconditioner based on Schur complement to treat this problem.
>

For any solver question, please send us the output of

  -ksp_view -ksp_monitor_true_residual -ksp_converged_reason

However, I will comment below


> The parameters used for the solve is
> -ksp_type gmres
>

You need 'fgmres' here with the options you have below.


> -ksp_max_it 300
> -ksp_gmres_restart 300
> -ksp_gmres_modifiedgramschmidt
> -pc_fieldsplit_type schur
> -pc_fieldsplit_schur_fact_type diag
> -pc_fieldsplit_schur_precondition selfp
>

It could be taking time in the MatMatMult() here if that matrix is dense.
Is there any reason to
believe that is a good preconditioner for your problem?


> -pc_fieldsplit_detect_saddle_point
> -fieldsplit_u_pc_type hypre
>

I would just use MUMPS here to start, especially if it works on the whole
problem. Same with the one below.

   Matt


> -fieldsplit_u_pc_hypre_type boomeramg
> -fieldsplit_u_pc_hypre_boomeramg_coarsen_type PMIS
> -fieldsplit_lu_pc_type hypre
> -fieldsplit_lu_pc_hypre_type boomeramg
> -fieldsplit_lu_pc_hypre_boomeramg_coarsen_type PMIS
>
> For the test case, a small problem is solved on 2 processes. Due to the
> decomposition, the contact only happens in 1 proc, so the size of Lagrange
> multiplier dofs on proc 0 is 0.
>
> 0: mIndexU.size(): 80490
> 0: mIndexLU.size(): 0
> 1: mIndexU.size(): 103836
> 1: mIndexLU.size(): 2583
>
> However, with this setup the solver takes very long at KSPSolve before
> going to iteration, and the first iteration seems forever so I have to stop
> the calculation. I guessed that the solver takes time to compute the Schur
> complement, but according to the manual only the diagonal of A is used to
> approximate the Schur complement, so it should not take long to compute
> this.
>
> Note that I ran the same problem with direct solver (MUMPS) and it's able
> to produce the valid results. The parameter for the solve is pretty standard
> -ksp_type preonly
> -pc_type lu
> -pc_factor_mat_solver_package mumps
>
> Hence the matrix/rhs must not have any problem here. Do you have any idea
> or suggestion for this case?
>
>
> Giang
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160416/141d2ecc/attachment.html>


More information about the petsc-users mailing list