Replace Cactus complex number implementation with C/C++ standard implementation

Issue #624 closed
Erik Schnetter created an issue

Cactus offers CCTK_COMPLEX. This maps to the standard datatype in Fortran, but not in C or C++. It should map to the standard datatypes in C and C++ as well, so that the growing body of code written in C and C++ can reasonably make use of complex numbers.

Keyword:

Comments (5)

  1. Erik Schnetter reporter
    • changed status to open
    • removed comment

    The enclosed patch changes the definition of CCTK_COMPLEX to use C99 or C++ complex datatypes, respectively. The Cactus complex number functions CCTK_Cmplx* are retained for compatibility, and only wrap the C99 functions.

    In most places the changes are trivial.

    File cctk_Complex.h contained optimisations allowing inlining; since we are using different implementations in C and C++, this is not easily possible any more, and is now disable. (The inlining, that is.)

    In many places, real and imaginary parts were accessed as structure members. This is not possible any more, and has been replaced by calls to CCTK_Cmplx{Real|Imag}. This probably also teaches a lesson about the values of information hiding.

    In many places, complex numbers were explicitly treated as two-vector of real numbers. This is now not necessary any more, simplifying the code.

    Thorn LocalReduce is not amenable to modifications. I disabled it in this patch. A better solution is probably to remove support from complex numbers from it, since this support has serious errors anyway. In the long term, LocalReduce should be rewritten in C++, probably reducing code size by a factor of 100.

  2. Roland Haas
    • removed comment

    Causal reading of the patch made me find nothing terribly suspicious. Two questions: (a) won't disabling LocalReduce break all tests that use it (ie all PUGH based tests doing reduction) (b) since we make assumptions about the layout in memory of structure members (essentially that struct {double ; double} has the same layout as double[2]), do we know what happens if CCTK_REAL is float (instead of double), one selects aggressive structure member alignment options (eg in the intel compiler) and is on eg. a 64bit machine where doubles and pointers need to be aligned on 64bit boundaries?

  3. Erik Schnetter reporter
    • removed comment

    (a) Disabling LocalReduce won't fly; we will have to e.g. remove complex number support from it instead. (b) This won't be a problem. double;double; always has the same layout as double[2]. float will not be aligned to 64 bits, even on 64 bit systems.

  4. Log in to comment