# [petsc-users] Solving Linear Systems with Scalar Real and Complex

Pierpaolo Minelli pierpaolo.minelli at cnr.it
Fri Jul 27 03:26:07 CDT 2018

```Hi,

I tried to follow Matthew's suggestion by dividing the system in the complex field into two systems in the real numbers field. In practice I used three subspaces of Krylov, one for the first system in the real number field and two for the system in the complex number field. Using real numbers, I was able to use the ML and Hypre preconditioners again.
I have performed the following tests using the following default options and using the PETSc version configured with "--with-scalar-type=real (default value)":

(1) -pc_type gamg -pc_gamg_agg_nsmooths 1 -pc_gamg_reuse_interpolation true -pc_gamg_square_graph 1 -pc_gamg_threshold 0. -ksp_rtol 1.e-7
(2) -ksp_type preonly -pc_type lu -pc_factor_mat_solver_type mumps
(3) -ksp_type preonly -pc_type lu -pc_factor_mat_solver_type superlu_dist
4) -pc_type ml -ksp_monitor -ksp_rtol 1.e-7
(5) -pc_type hypre -ksp_rtol 1.e-7

All methods resolve both systems correctly, but iterative methods (1,4,5) are faster. Among iterative methods using Hypre or ML PCs, I get better performance (solve time) than GAMG.

Previously configuring PETSc with --with-scalar-type=complex I had only been able to perform the tests (1,2,3) and in that case the resolution times were roughly the same and comparable to the resolution time of case 1) when using only real numbers.

Finally, I have a question. In my simulation I solve the two systems at each step of the calculation, and it was my habit to use the following option after the first resolution and before solving the system in the second time step:

call KSPSetInitialGuessNonzero(ksp,PETSC_TRUE,ierr)

Since this option was incompatible with the use of MUMPS or SuperLU_Dist, I commented on it and noticed, to my surprise, that iterative methods were not affected by this comment, rather they were slightly faster. Is this normal? Or do I use this command incorrectly?

Thanks

Pierpaolo

> Il giorno 23 lug 2018, alle ore 15:43, Mark Adams <mfadams at lbl.gov> ha scritto:
>
> Note, as Barry said, GAMG works with native complex numbers. You can start with your original complex build and use '-pc_type gamg'.
> Mark
>
> On Mon, Jul 23, 2018 at 6:52 AM Pierpaolo Minelli <pierpaolo.minelli at cnr.it <mailto:pierpaolo.minelli at cnr.it>> wrote:
>
>
> > Il giorno 20 lug 2018, alle ore 19:58, Smith, Barry F. <bsmith at mcs.anl.gov <mailto:bsmith at mcs.anl.gov>> ha scritto:
> >
> >
> >
> >> On Jul 20, 2018, at 7:01 AM, Pierpaolo Minelli <pierpaolo.minelli at cnr.it <mailto:pierpaolo.minelli at cnr.it>> wrote:
> >>
> >> Hi,
> >>
> >> in my code I have to solve both a system in the field of real numbers and in the field of complex numbers.
> >> My approach has been as follows.
> >> First I configured PETSc with the --with-scalar-type=complex option.
> >> Using this option I have unfortunately lost the possibility to use the two preconditioners ML and Hypre.
> >
> >    You should still be able to use the PETSc PCGAMG algebraic multigrid solver. Have you tried that? If there are issues let us know because we would like to continue to improve the performance of PCGAMG to get it to be closer to as good as ML and hypre.
> >
> >   Barry
> >
>
> I will try to convert, as suggested by Matthew, my complex system in a system twice as large in real numbers. When i finish, i will try to use ML, Hypre and GAMG and i let you know if there are any performance differences.
>
> Thanks
>
> Pierpaolo
>
>
> >> I later created two subspaces of Krylov and tried to solve the two systems as I used to when solving the only equation in the real numbers field.
> >> In order to correctly solve the system in the field of real numbers I had to transform the coefficients from real to complex with an imaginary part equal to zero.
> >>
> >> Is there a possibility to use a different and better approach to solve my problem?
> >>
> >> Perhaps an approach where you can continue to use ML and Hypre for system solving in the real numbers field or where you don't need to use complex numbers when real numbers would actually suffice?
> >>