Backports for the June 2017 release to compile on the NDS machine

Issue #2080 closed
Steven R. Brandt created an issue

I would like to backport the following files from master to the June 6th release of the ET. The files are

repos/simfactory2: bin/sim mdb/machines/jupyteret.ini mdb/optionlists/generic.cfg mdb/runscripts/generic.run

Also, a small modification to the PAPI thorn:

Index: src/detect.sh
===================================================================
--- src/detect.sh   (revision 42)
+++ src/detect.sh   (working copy)
@@ -27,7 +27,7 @@
         # libraries might have different file extensions
         for libext in a dll dll.a dylib lib so; do
             # libraries can be in lib or lib64 (or libx32?)
-            for libdir in lib64 lib; do
+            for libdir in lib64 lib  lib/x86_64-linux-gnu; do
                 # These files must exist
                 FILES="include/papi.h ${libdir}/libpapi.${libext}"
                 # assume this is the one and check all needed files

With these changes, the ET builds on the NDS machine. Moreover, it should more easily build on machines which have no explicit entry in Simfactory.

Keyword:

Comments (11)

  1. Roland Haas
    • changed status to open
    • removed comment

    Looking at generic.cfg in 5258cc455e06d90584708e1f62a2b3fc87b569bc which seems to be the one you want to backport (technically the change to master would also have required review):

    • maybe better to use gnu++0x rather than c++0x so that _GNU_SOURCE is automatically defined
    • it is possible to compile Cactus (PUGH for example) without the F90 compiler which is why there is no default F90 compiler. So adding the requirement is a bit of a policy decision (should be fine but should be mentioned and not done without comment).
    • "F90_OPENMP_FLAGS = -pg" seems wrong. Do you mean to use either F90_PROFILE_FLAGS or "-fopenmp"?
    • same later on for F90_OPENMP_FLAGS
    • please do not make generic.run into a script that can use MPI code, we already have generic-mpi.run for this

    The proposed change to bin/sim seems like a bugfix to me while the others are enhancements.

  2. Steven R. Brandt reporter
    • removed comment

    Sorry. The F90_OPENMP_FLAGS was, obviously, a copy paste error. I made a similar mistake on the warn files. Here's the corrected version (if you approve).

    diff --git a/mdb/optionlists/generic.cfg b/mdb/optionlists/generic.cfg
    index 489e60d..ea82618 100644
    --- a/mdb/optionlists/generic.cfg
    +++ b/mdb/optionlists/generic.cfg
    @@ -16,7 +16,7 @@ CPPFLAGS =
     FPPFLAGS = -traditional
    
     CFLAGS   = -g -std=gnu99
    -CXXFLAGS = -g -std=c++0x
    +CXXFLAGS = -g -std=gnu++0x
     F77FLAGS = -g -fcray-pointer -ffixed-line-length-none
     F90FLAGS = -g -fcray-pointer -ffixed-line-length-none
    
    @@ -36,15 +36,15 @@ PROFILE           = no
     CPP_PROFILE_FLAGS =
     C_PROFILE_FLAGS   = -pg
     CXX_PROFILE_FLAGS = -pg
    -F77_OPENMP_FLAGS = -pg
    -F90_OPENMP_FLAGS = -pg
    +F77_PROFILE_FLAGS = -pg
    +F90_PROFILE_FLAGS = -pg
    
     WARN           = yes
     CPP_WARN_FLAGS = -Wall
     C_WARN_FLAGS   = -Wall
     CXX_WARN_FLAGS = -Wall
    -F77_OPENMP_FLAGS = -Wall
    -F90_OPENMP_FLAGS = -Wall
    +F77_WARN_FLAGS = -Wall
    +F90_WARN_FLAGS = -Wall
    
     OPENMP           = yes
     CPP_OPENMP_FLAGS = -fopenmp
    

    I thought the policy on cfg files was, generally, not to make a ticket. Since generic.cfg didn't work anyway, it seemed harmless.

    Why should we have two versions of generic, one that can call mpi and one that cannot? Why not have one script that only tries to use mpi if more than one process is called for? If we have two scripts, then we should have simfactory detect whether mpi is present and install the correct one. Is that what you would prefer?

  3. Steven R. Brandt reporter
    • changed status to open
    • removed comment

    Roland, you and I hashed out these issues at the ETEU workshop and everything is committed both to the ET_2017_06 branch and to master. Any objection to marking this closed/fixed?

  4. Roland Haas
    • removed comment

    If it is all committed then I have not problem with this ticket being closed. However it would be good to quickly give an overview about the current state:

    • F90 required?
    • MPI used / required / assumed in the generic.run?
    • removed all "old" optionslists / cfgfiles / runscripts /submitscripts for Linux / OSX / Cygwin that are no longer required?
  5. Steven R. Brandt reporter
    • removed comment

    Overview:

    F90 is and has always been required. My recollection is that if you try to compile the ET without it CCTK_REAL is not defined. Thus, the original generic.cfg was guaranteed not to work anywhere.

    MPI is used by generic.run, but only if you ask for more than 1 proc. It assumes mpirun is in the $PATH.

    The simfactory submit commands work for generic machines now (using nohup), with or without MPI.

    I have not removed the optionlists that are no longer required. If we want this, it is the only action to be taken on this ticket. I suspect doing this will cause some short-term pain for people who have workflows that use them explicitly, and I'm not sure we want to do so this close to a release.

  6. Erik Schnetter
    • removed comment

    Fortran is not required for Cactus, but it is required for the Einstein Toolkit. Cactus detects if there is no usable Fortran compiler, and CCTK_REAL should in this case still work fine. Of course, there are cases where Cactus stumbles across a dysfunctional Fortran compiler, and then all bets are off...

  7. Log in to comment