[petsc-users] one compilation error in PETSc-dev with enabling GPU and complex number

[Barry Smith]

   Jack,

    PetscScalar is defined in petscmath.h to be one of several things:

typedef std::complex<float> PetscScalar;
typedef std::complex<double> PetscScalar;
typedef float complex PetscScalar;
typedef double complex PetscScalar;
typedef float PetscScalar;
typedef double PetscScalar;
typedef __float128 PetscScalar;

Matt's point is that WE (the guys hacking on PETSc everyday) are not going to add other possibilities for cusp and complex at this point in time. We simply don't have the time/reason to add all this functionality now.  If recursader wants that functionality he is free to hack the code and add it; if he does it in a clean way that he can provide patches then we will put the patches into petsc-dev.  We simply don't have the resources to add all stuff to PETSc that anyone wants anytime and we have to focus on adding functionality that is commonly needed and will be widely used (especially within DOE). 

   Barry



On Feb 7, 2012, at 12:10 PM, Jack Poulson wrote:

> On Tue, Feb 7, 2012 at 11:29 AM, Matthew Knepley <knepley at gmail.com> wrote:
> On Tue, Feb 7, 2012 at 11:20 AM, recrusader <recrusader at gmail.com> wrote:
> Whether is it possible to find an efficient mechanism to do the conversion between std::complex and cusp::complex when the conversion is necessary.
> 
> That does not matter. This is a compile error. We are not going to change this right now, and it seems like you are not going
> make the necessary changes, so I would say that complex numbers are not supported with our GPU code right now. The
> change would involve using cusp::complex for PetscScalar, and I am not sure how much work that would entail.
> 
>    Matt
> 
> Matt, 
> 
> You might be interested to hear that the C++03 standard states that "The effect of instantiating the template complex for any type other than float, double or long double is unspecified". Thus, complex quad precision with it is probably a bad idea and, if I'm not mistaken, the standard does not state that the class must store data in the form
> 
> double real, imag;
> 
> so this could potentially break interfaces (e.g., to BLAS or LAPACK). Maybe it would be worthwhile to avoid usage of std::complex and simultaneously fix the compatibility issue with cusp::complex. I recently ripped std::complex out of Elemental for the above reasons.
> 
> Jack