This Assignment consists of two parts. In Part A you will implement the two dimensional data decomposition with periodic boundary conditions. Part B will be the performance analysis.
(1) Modify the program you write in Assignment #3 to use a two dimensional domain decomposition. The decomposition will use a 2D geometry Px × Py, for example, P=4 : 2x2, P=8 : 2x4, P=12 : 3x4.
Specify the geometry using two command line arguments -px and -py.(2) Implement periodic boundary conditions. Periodic boundary conditions are conveniently handled with ghost cells, which can be used to connect opposite edges that logically touch one another. Watch out for the corners: they wrap around along two axes. Recall that in Assignment #3 we used a one dimensional decomposition. Under these conditions, the two "end" processors communicate data in only one direction. With periodic boundary conditions all processors communicate ghost cells in both directions, resulting in a logical ring processor configuration. For the two-dimensional case Px =Py we obtain a Px × Py-ary 2-cube with end-around connections. (3) Modify your parallel display routine to accept data from all P processors. Try to interleave communication and display for an efficient implementation. Your application will run on P+1 processors. Run with a small problem size of 50x50 for 1000 iterations and plot every 50 iterations:
padv -nx 50 -ny 50 -vx 1 -nt 1000If you have previously set up a ~/.ssh/config file, to ensure correct X11 forwarding (for the plots to appear on your terminal), gnuplot must be instantiated on the correct compute node. This can be done in two steps. First, make sure that the compute node listed as the first entry in the machine-file matches the compute node listed on the first line in the config file. This ensures that this compute node is the one which will be assigned rank=0. Second, in your code, let the process with rank = 0 be the one that runs gnuplot and does the plotting.
Test your implementation on a small mesh (-nx 8 -ny 8) and P = 4. Use the Parallel Print Facility discussed in section (see below). You may want to print out your values (using the Parallel Print Facility routines discussed in Section (and refer to handout) to print out these matrices) for debugging.
Part B
Collect performance data to observe
Turn OFF the display. Now examine fixed speedups for P=4,8 and 12. Choose problem sizes (N2) that maintain the of 4:8:12 in computational load (and hence a fixed computational load per processor) Choose the number of iterations so that the total running time for each run is around 10 seconds. Then, divide the total running time by the number of iterations to get the 'running time per iteration'. Plot this running time per iteration and comment on any trends. How should the plot look ideally?
Turn ON the display. Display data every 50 iterations. Use MPI_Barrier() after every display function call. Your timings should now include the time taken for display. Run with P=1, 2(=1×2) and 4(=2×2) . Plot the speedups observed. Explain your results using Amdahl's law.
The problem size is defined as the number of mesh points updated at each iteration : nx × ny
To get accurate timings, you may need repeat your runs a few times to make sure that you get similar timings for every run. If they vary a lot, then take the average of at least 3 different runs. Prior to collecting timings, you should 'warm up' the machine. To do this, you should run your program a few times in succession and discard the timings obtained from the first run.
Please make sure that you begin taking your timings as soon as possible. As the assignment deadline approaches, many of you will be simultaneously trying to run your program and obtain accurate timings. Job interference will adversely affect terms of the accuracy of your timings, and hence the time needed to obtain good timings. smooth this out a bit is to generate and use a random list of compute nodes in your machine-file list.
Document your work in a well-written report which discusses your findings carefully. Your report should present a clear evaluation of the design of your code, including bottlenecks of the implementation, and describe any special coding or tuned parameters. Further, it should present your timing and speedup observations, with an analysis that describes your understanding of how the speedups (or any other effect you observe) were obtained. Provide code listings for files you wrote, or that you modified based on versions we gave to you (there is no need to provide listings of code we provided, that you did not modify).
Your report should cite any written works or software as appropriate in the text of the report. Citations should include any software you used that was written by someone else, or that was written by you for purposes other than this class.
Provide a hard copy in class. Also transmit the report electronically along with your code. We will run the code on Valkyrie. Transmit a single file as described next.Please tar your writeup, plots, and source code and email them to cs160x1@valkyrie.ucsd.edu. The name of your tar file should be your Login ID.tar. Your archive file should create a directory with the name of your login ID. Be sure and delete all .o files and executables before creating the tar file.
The directory should contain two subdirectories (If you want to provide us additional information about the turnin, you may include a README file):
"src" : All source code
"report" : Your report including any separate plot files or output
If you like, you may put an html file called index.html at the top level. From there you can then link to the README file to the src and report directories. .
Copyright © 2004 Scott B. Baden. Last modified: 04/07/04 04:03 PM