Error in complex GMRES

[yy.wayne]

I'm trying to apply a Krylov solver for complex-valued problem. Basiclly I have modified step-16 into a complex-valued problem (do not seperate real and imaginary parts) and solve with direct solver successfully. However it failed on GMRES solver. Does deal.II built-in GMRES solver only supprts double type?

[Wolfgang Bangerth]

Yes. You probably want to take a look at step-58 as well, along with the
discussion in the results section there.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[yy.wayne]

Thank you Wolfgang.

As I changing built-in solver to PETScWrappers, I failed to converse a "PETSc::Wrappers:Vector" variable to a "Vector<std::complex<double>>" one, as shown in line 464 of my code. I tried 

        "Vector<std::complex<double>> a = b; (where b is a PETSc Vector)"

or

        "Vector<std::complex<double>> a(b)"

but both failed. In step-17 however, both is good. Is it because the complex type or other mistake inmy code?

Best

Wayne

[Wolfgang Bangerth]

On 9/27/22 00:25, 'yy.wayne' via deal.II User Group wrote:
> As I changing built-in solver to PETScWrappers, I failed to converse a
> "PETSc::Wrappers:Vector" variable to a "Vector<std::complex<double>>" one, as
> shown in line 464 of my code. I tried
>         "Vector<std::complex<double>> a = b; (where b is a PETSc Vector)"
> or
>         "Vector<std::complex<double>> a(b)"
> but both failed. In step-17 however, both is good. Is it because the complex
> type or other mistake inmy code?
>

I don't know. You may want to show the compiler's error message.

Did you compile PETSc with the flag necessary to support complex arithmetic?

[yy.wayne]

Thank you.

I'm using the Oracle VirtualBox environment by default, so I guess it's not complied with PETSc complex arithmetic.

By the way, is using complex coding approved or separate to real and imaginary parts? I read another discussion in gouglegroup said complex coding might lead to error for <u,v> <v,u> integral. But separate a problem into real and imaginary doubles the matirx size and DoFs, isn't it?

[Wolfgang Bangerth]

On 9/27/22 20:52, 'yy.wayne' via deal.II User Group wrote:
> I'm using the Oracle VirtualBox environment by default, so I guess it's not
> complied with PETSc complex arithmetic.

Yes, that's probably true. You will have to install things from scratch on
your system if you want PETSc with complex arithmetic. It is a pity that PETSc
doesn't make that easy :-(

> By the way, is using complex coding approved or separate to real and imaginary
> parts? I read another discussion in gouglegroup said complex coding might lead
> to error for <u,v> <v,u> integral. But separate a problem into real and
> imaginary doubles the matirx size and DoFs, isn't it?

Well yes, but then you do need to store real and imaginary parts somewhere
anyway. So this isn't likely going to be a big bottleneck.

The post you refer to simply points out that it is easy to make mistakes if
you work in complex, rather than separate real/imaginary, arithmetic. But it
can be done correctly, as shown in step-58.

[yy.wayne]

Thank you sir.

Just one last question. So if I have the same problem coded in real+imaginary or complex and solve with SparseDirect solver or Krylov subspace methods. Will there be difference in time consumption (due to larger matirx / or harder to solve complex arithmetic embedded in those solver)?

[Wolfgang Bangerth]

On 9/27/22 21:02, 'yy.wayne' via deal.II User Group wrote:
>
> Just one last question. So if I have the same problem coded in real+imaginary
> or complex and solve with SparseDirect solver or Krylov subspace methods. Will
> there be difference in time consumption (due to larger matirx / or harder to
> solve complex arithmetic embedded in those solver)?

For Krylov subspace methods, everything depends on the preconditioner and it
is not possible to make general predictions without knowing what you want to
use for the preconditioner.

For SparseDirectUMFPACK, I suspect that using complex arithmetic is faster
than using separate real/imaginary components. By how much is something I have
never measured -- you probably need to measure this yourself. It would not
greatly surprise me if it was faster by a factor of 4 or 6, but I don't think
it should be a factor of 20 for example.

Best
Wolfgang

[yy.wayne]

Yeah I think it make sense. Thank you again.