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 <mfad...@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.mine...@cnr.it > <mailto:pierpaolo.mine...@cnr.it>> wrote: > > > > Il giorno 20 lug 2018, alle ore 19:58, Smith, Barry F. <bsm...@mcs.anl.gov > > <mailto:bsm...@mcs.anl.gov>> ha scritto: > > > > > > > >> On Jul 20, 2018, at 7:01 AM, Pierpaolo Minelli <pierpaolo.mine...@cnr.it > >> <mailto:pierpaolo.mine...@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? > >> > >> Thanks in advance > >> > >> Pierpaolo > >> > > >
