[Developers] Problems compiling defaul einstein-toolkit thorns with Intel icc compiler greater version 11

Erik Schnetter schnetter at cct.lsu.edu
Thu Oct 27 07:48:20 CDT 2011


On Thu, Oct 27, 2011 at 5:43 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> On 27 Oct 2011, at 10:12, alibeck wrote:
>
> Hi Folks,
>
> Trying to compile the Thornlist given by einsteintoolkit.th causes
> problems with an Intel icc compiler using a version greater then 11.
>
> To avoid an error in KrancNumericalTools/GenericFD/src/GenericFD.c
>
> [snip]
>
> /home/hlrb2/pr32pi/lu32vak/Cactus-Simfact2-NewRepos/Cactus/arrangements/KrancNumericalTools/GenericFD/src/GenericFD.c(490):
> error: expected an expression
>    for (int d=0; d<3; ++d) {
> [snip]
>
> it is necessary to set -std=c99 as compiler flag.
>
> Yes, many thorns require C99 - if you recall there was a similar issue in
> August:
> http://cactuscode.org/pipermail/developers/2011-August/006225.html
> There is an enhancement request by Erik for the capability to detect whether
> C99 is enabled in the compiler so that thorns can give a sensible error
> message if they need it:
> https://trac.einsteintoolkit.org/ticket/535
> Maybe someone could look at implementing this?
>
> However, setting this flag, M_PI is not defined any more in the C99
> standard, so I am running into this error.
>
> Right - I think this is the real problem.  It looks like the Intel compiler
> became more strict between versions 11 and 12.
>
> U have searched a little bit for solutions in the Internet, and all what
> I have found was the suggestion to add the following definition to the code:
>
> [snip]
>
> #ifndef M_PI
> #define M_PI 3.1415926535897932385
> #endif
>
> [snip]
>
> M_PI is used in the following programs:
>
> [snip]
> ./Kranc/Auxiliary/Cactus/KrancNumericalTools/GenericFD/src/MathematicaCompat.h:#define
> Pi              M_PI
> ./carpet/Carpet/LoopControl/src/wavetoy-loopcontrol.c:  double const kx =
> M_PI/(NI-1);
> ./carpet/Carpet/LoopControl/src/wavetoy-loopcontrol.c:  double const ky =
> M_PI/(NJ-1);
> ./carpet/Carpet/LoopControl/src/wavetoy-loopcontrol.c:  double const kz =
> M_PI/(NK-1);
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                    if (theta
>> M_PI/2.0) {
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                      theta =
> M_PI - theta;
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                  assert
> (theta <= M_PI);
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                    fmod
> (atan2 (dy, dx) + CCTK_REAL (2 * M_PI),
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:
>                          CCTK_REAL (2 * M_PI));
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                      if (phi
>> M_PI / 2.0) {
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                        phi =
> M_PI - phi;
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                      if (phi
>> M_PI) {
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                        phi =
> 2 * M_PI - phi;
> ./carpet/Carpet/CarpetMask/src/mask_surface.cc:                  assert (phi
> < 2 * M_PI);
> ./carpet/Carpet/CarpetRegrid/src/moving.cc:      CCTK_REAL const argument =
> 2*M_PI * moving_circle_frequency * cctk_time;
>
> ./EinsteinAnalysis/AHFinderDirect/src/jtutil/util.hh:#ifdef M_PI        /*
> test for <math.h> */
> ./EinsteinAnalysis/AHFinderDirect/src/include/stdc.h:#ifdef M_PI
>                /* usually defined in <math.h> */
> ./EinsteinAnalysis/AHFinderDirect/src/include/stdc.h:  #define PI       M_PI
> ./EinsteinInitialData/Meudon_Mag_NS/src/.svn/text-base/Mag_NS.cc.svn-base:
>  CCTK_REAL const mu0     = 4*M_PI * 1.0e-7; // vacuum permeability [N/A^2]
> ./EinsteinInitialData/Meudon_Mag_NS/src/.svn/text-base/Mag_NS.cc.svn-base:
>    sqrt(4*M_PI) / cactusL / sqrt(4*M_PI * eps0 * G_grav / pow(c_light,2));
> ./EinsteinInitialData/Meudon_Mag_NS/src/Mag_NS.cc:  CCTK_REAL const mu0
>     = 4*M_PI * 1.0e-7; // vacuum permeability [N/A^2]
> ./EinsteinInitialData/Meudon_Mag_NS/src/Mag_NS.cc:    sqrt(4*M_PI) / cactusL
> / sqrt(4*M_PI * eps0 * G_grav / pow(c_light,2));
>
>
> [snip]
>
> At least find posted my this...
>
> Any other ideas, e.g. by special compiler flags?
>
> If the C99 standard is clear on this point, then it would be good to follow
> the standard.  If the recommended way to get constants such as pi is to
> define it ourselves, then we should.  From a bit of googling, it seems that
> the reason that M_PI was not included in the C99 standard is that it is not
> clear what precision it should be available in.  For Cactus this is quite
> important, as you are supposed to be able to change CCTK_REAL to a higher
> precision than "double", and if the numerical constants such as M_PI are
> fixed to double precision, you will lose accuracy.  Of course, the other
> numerical constants like 2.0 etc might also cause this problem.  The
> definition you gave above has only enough digits for double precision - if
> we wanted to run in quad-precision, it would be imprecise.  You can get the
> value of Pi by acos(-1.0), but then it would have to be a runtime variable
> rather than a compile-time constant, which might be slower.  I'm also not
> familiar with how the math library functions work with higher than double
> precision.
> In any case, whatever definition we choose, it sounds like it would be good
> for Cactus itself to define a Pi variable or macro, to avoid the need for
> all thorns to do this.

The C standard isn't the only standard we need. We need also e.g.
POSIX for operating system calls (handling directories, files). M_PI
is defined in POSIX.

When one requests strict ANSI compliance, then POSIX is disabled.
Maybe there is a better way to enable C99 semantics than requiring
string ANSI compliance, or maybe there is a better way to re-enable
POSIX than the -U flag. In any way, M_PI is part of a standard that we
need anyway, so we don't need to define it ourselves.

It is important to choose the right compiler flags corresponding to
the source code, and it is sad that the default flags are stuck in
1989, but we'll have to live with this. One cannot expect a
non-trivial code to compile simply with "cc", so either Cactus
autoconf is to blame, or one needs good Simfactory options.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/


More information about the Developers mailing list