Running the OpenMP Run-Time Error Detection Test Suite

1) Download and untar and gunzip as necessary.

2) In each of the directories C, C++ and FORTRAN,
   copy the appropriate CONFIGURATION.* file to
   CONFIGURATION.  If none is appropriate copy
   one that is close, and modify as needed.

3) Modify CONFIGURATION file in the case that you have 
   additional tools (See TOOL variable). 
   Also, the TMP variable allow you to specify a temporary
   space which may be faster than a subdirectory of the current
   working directory.  The directory specified by TMP must
   be shared among all nodes involved. (I.e. on network shared
   filesystem e.g. AFS, NFS, GFS, or a SAN)
   ** CAUTION **
      If you change the value of TMP, do not change it to 
   RESULT or to any directory which you want to keep, as
   this directory is destroyed prior to running each test.

4) In any of the 3 directories C, C++ and FORTRAN, issue
   ./run_tests_all

   As an alternative, we supply a file pbs.batch which is
   a PBS/torque batch script that can be submitted via 
   qsub pbs.batch
   if you are running PBS. This will run all 3 languages in 
   succession, putting the screen output into BATCH_OUTPUT 
   and errors that would come to the screen into BATCH_ERRORS. 
   This batch script has run successfully on a cluster at ISU.

   This will run all the tests for that language, printing a section 
   by section summary.
   There are over 2500 tests, so this test suite will take some time
   to run.
     E.g. on a machine with two dual core Opetrons, the entire suite 
   takes about 2.5 hours.

5) After running, you can cd into any section, and see which tests
   passed/failed in the files test_results_E, test_results_D, test_results_C, 
   test_results_B, test_results_A.  The criteria for passing at the E level 
   is the least strict and the A level is the most strict.

6) In each section, you may type ../chk test_name   
   where test_name is one of the tests in any of the test_results files.
   An example is at the end of the Readme.


7) After running, you can issue  ./cleanup_all
   to get rid of the result files.

8) Note: Some tests may fail to compile/link due to:
   *) Incomplete OpenMP implementation. 

    In this case, a message will be printed giving the testname for which this
   happened and a list of files containing the compiler messages.
   Tests that fail to compile are simply not counted in the score, 
   since they did not run.

     The C, C++ and FORTRAN program source has the .c, .ccp and .f90 extensions respectively,
  and the FORTRAN source is in free format source form.

Appendix A:

../chk example:

> ../chk F_C_4_2_c_M1
 
test_results_A:F_C_4_2_c_M1 FAIL
test_results_B:F_C_4_2_c_M1 FAIL
test_results_C:F_C_4_2_c_M1 FAIL
test_results_D:F_C_4_2_c_M1 FAIL
test_results_E:F_C_4_2_c_M1 PASS
 
 Actual error message for test F_C_4_2_c_M1 :
-------------------------------------------
 
[cli_2]: aborting job:
Fatal error in MPI_Recv: Message truncated, error stack:
MPI_Recv(179).....................: MPI_Recv(buf=80c95a0, count=5, MPI_INTEGER, src=1, tag=1, MPI_COMM_WORLD, status=80c95e0) failed
MPIDI_CH3U_Post_data_receive(1377): Message from rank 1 and tag 1 truncated; 24 bytes received but buffer size is 20
 
 Ideal error message for test F_C_4_2_c_M1 :
-------------------------------------------
 
ERROR: count mismatch
The send buffer 'arrayA' passed to 'MPI_SEND' with count value 6 does not
match the count of the receive buffer 'arrayB' passed to 'MPI_RECV' with
receiving count value 5.
Send function 'MPI_SEND' is called at line 79 in file 'F_C_4_2_c_M1.f90' on
process 1 and the corresponding receive function 'MPI_RECV' is called at line
84 in file 'F_C_4_2_c_M1.f90' on process 2.


Appendix B:

For greater flexibility:
9)  To run just one or two sections for a given language, you may type
     ./run_tests_all  section1 section2 ...

    This does destroy any existing test_results files, and any
    files in the RESULTS subdirectory.

10)  If you are in a section subdirectory, you may run just a few 
    of the tests for that section by issuing
    ../tools/run_tests test1 test2 ...
    Again, this destroys any existing test_results and RESULTS/
    files.

    Once this is done, ../chk works only for the smaller set of tests
    you've just run.