Thorn CT_Analytic does not build on Shelob

Create issue
Issue #1834 closed
Erik Schnetter created an issue

The file takes more than 30 minutes to build on Shelob, and the build process is thus aborted by the operating system:

COMPILING arrangements/CTThorns/CT_Analytic/src/

Message from root@shelob1 on <no tty> at 17:25 ...
icpc: error #10106: Fatal error in /usr/local/compilers/Intel/composer_xe_2013.5.192/bin/intel64/mcpcom, terminated by kill signal
compilation aborted for /project/eschnett/shelob/Cvanilla/configs/sim/build/CT_Analytic/ (code 1)

I've looked at the source code. It seems Kranc-generated, with expressions spanning many lines and many calls to pow. Maybe a small change to the Kranc script choosing different options (e.g. enabling CSE, or replacing calls to pow by explicit multiplication) could remedy this.

At the moment I will disable this thorn on Shelob.


Comments (7)

  1. Ian Hinder
    • removed comment

    The Kranc script is in arrangements/CTThorns/m. It looks like there is no newer compiler version on shelob.

    Another option might be to leave some of the operations to be performed numerically, rather than substituting everything into a single expression finally.

  2. Frank Löffler
    • removed comment

    Does that file also need so long on other machines using the Intel compiler? Maybe something could be done using the compiler flags?

  3. Ian Hinder
    • removed comment

    It's fine on Intel 15 on Datura, and GCC on Mac OS. If we could set the compiler flags for that specific source file to disable optimisation, that would work around the problem, but I don't think there is such a mechanism in Cactus. I don't think the routine is performance-sensitive.

  4. Roland Haas
    • removed comment

    You can modify compiler flags on a per-file bases via makefiles. For example (this is for LocalInterp2, but currently not under review). For example in LocalInterp2/src/make.code.deps CXXFLAGS += -fp-model precise
  5. Eloisa Bentivegna
    • removed comment

    I assume that this is due to the fact that many of the coefficients are specified parametrically, via lengthy superpositions. I have just committed a change that reduces the number of terms in one of these superpositions, as this functionality is currently not used anywhere and who needs more parameters can always increase this number and regenerate the thorn.

    The change reduced the corresponding generated code by two thirds. Erik, does this solution alleviate the compile problem on Shelob?

  6. Log in to comment