HINTS

The goal is be systematic in figuring out how to parallelize this program. You should start by using the gprof command to figure out what parts of the program take the most time (to use gprof, you will need to compile your program with the -pg switch). From there you should examine the loops in the most important subroutines and figure out how to add OpenMP directives.

The programs will be run on a single compute node of the zaratan machine (zaratan.umd.edu). You already have account information and should know how to login and run jobs on the machine from the MPI project.

WHAT TO TURN IN

You should submit your program and the times to run it on the input file quake.in (for 1, 2, 4, 8, 16, and 32 threads). Since quake runs for a while on this input dataset for small numbers of threads, for your testing another input file that runs for much less time is in quake.in.short. So that you don't have to make copies of the somewhat large input data files, they are available on zaratan in /home/asussman/public/714/OpenMP/data. A copy of the serial quake.c is also available in /home/asussman/public/714/OpenMP/src.

You also must submit a short report about the results (1-2 pages) that explains:

• what directives were used
• what are the performance results, and are they what you expected

You should put the quake OpenMP code and the report in a single directory (named LastName-assign2), compress it to .tar.gz (LastName-assign2.tar.gz) and upload that to ELMS.

Using OpenMP

To compile openMP we will be using gcc version 9.4.0 (the default version on zaratan, which you can get by doing module load gcc on the zaratan login node, but you already have that if you are already loading the openmpi module in your .bashrc), which nicely has openMP support built in. In general, you can compile this assignment with:

gcc -fopenmp -pg -o quake quake.c -lm

The -fopenmp tells the compiler to, you guessed it, recognize OpenMP directives. -lm is required because our program uses the math library. -pg needs to be added to collect profiling data when the program is run; you can remove this option before you do final performance testing.

The environment variable OMP_NUM_THREADS sets the number of threads (and presumably processors) that will run the program. Set the value of this environment variable in the script you submit the job from. It defaults to using all available cores, and on a zaratan node that means 128, so be sure to set the number of cores before running the program in your sbatch script.

RUNNING THE PROGRAM

Quake reads its input file from standard input, and produce its output on standard output. Quake generates an output message periodically (every 30 of its simulation time steps), so you should be able to tell if it is making progress.

You should use diff to check that the output of your program exactly matches the output of the original code.

Also, before submitting please remove any debugging print statements. Alternatively, send debugging output to stderr, so it will not appear along with the expected output of quake (assuming you redirect stdout to a file).

GRADING

Grading

The project will be graded as follows:

Component	Percentage
Correctly runs with 1 thread	10
Correctly runs with 32 threads	30
Performance with 1 thread	10
Speedup of parallel version	30
Writeup	20

NOTE: If your program does not run correctly, you do NOT get any points for performance/speedup.