Skip to content

Latest commit

 

History

History
92 lines (72 loc) · 4.58 KB

oppgavetekst.org

File metadata and controls

92 lines (72 loc) · 4.58 KB

PS2 Part 2, programming exercise

THIS ASSIGNMENT MUST BE DONE INDIVIDUALLY. IT IS BOTH MANDATORY AND GRADED, COUNTING 10% OF YOUR FINAL GRADE. COLLABORATION AND/OR PLAGIARISATION IS NOT TOLERATED!

Description

In this exercise you will implement a “rock paper scissors” cellular automata (CA). Cellular Automata models processes where each point at some timestep N+1 is a function of the point and its immediate neighborhood at timestep N. The most known cellular automata is conways game of life, capable of creating fascinating patterns with a very simple ruleset. https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

The rock paper scissors CA is best described with a video: https://youtu.be/vqnpl5G17Ws

The rule for our rock paper scissor CA is as follows: A cell has two values: Its color and its strength. For each iteration a cell selects a neighbor at random. If it beats its neighbor its strength increases by 1. If it loses, its strength decraeses by one. When a cell reaches strength 0 it turns white. If a white cell selects a non-white cell, it turns into a new cell of that type with strength 1. Strength is capped at 6

Exercise

You’re asked to parallelize an existing serial implementation with openMPI. You may reuse as much code from the serial version as you see fit, but keep in mind that the serial program produces a video, while you are only required to produce an image of the petri dish after a set amount of iterations.

The exercise is broken into the following parts:

Initialize

Implement the initialize function, setting up process local buffers for petri-dishes, and figuring out where your process fits in.

Exchange borders

This procedure should exchange borders between adjecent petridishes inbetween each step. While each petri shares a single pixel with its diagonal neighbour, exchanging these is not mandatory since it’s hardly worth the extra effort. If you choose to implement this, please note so in your handin.

iterate_CA

Iterate the local petri dish one timestep. In your program, the petri is iterated ITERATIONS times, this value can be changed in RPS_MPI.h, but for your handin it should be set to 10000

gather petri

Gather the local petridishes into one large petridish, and output it as an image.

memory safety

We should always strive to keep memory leaks to a minimum. Ensure that you have no leaks by using valgrind! http://valgrind.org/

Hand-in

You should hand in your code as a zip file named $(your_username)_ps2 Your handed in code should contain a makefile where the first target should compile the parallel program and output a binary named “RPSparallel”

When run, your binary should produce a single output image named “MPI_petri.bmp”

We spend a lot of time grading, please ease the burden by conforming to these guidelines. If nothing else it’s a lot more likely that we overlook a small flaw if we don’t have to hassle to get it to run ;)

Tips

You should set yourself a list of subgoals rather than trying to get everything right in your first attempt! For instance, a good start would be to ensure that you can get the border exchange algorithm right before you start worrying about iterating the petri. Then you can add functionality, for instance exchanging borders for 10 timesteps and see if it still does what you want it to. This makes things easier for you, and it makes it easier for us to help you!

You can run the serial version and see a video of how the petri evolves. Keep in mind that it stores a lot of data on your computer that you need to delete after running.

Grading

The exercise will be graded as following:

Initialize: 0.5 points

Correct buffer sizes are calculated and initialized, processes perform correct process specific initializations

Border exchange: 5 points

The processes are able to correctly exchange borders between iterations

Gathering and outputting the final image: 1 point

The program does as specified in the hand-in part and outputs an image

Memory check: 2 points

Your program does not leak memory. Check this with valgrind!

Code readability: 1 point

I’m able to clearly understand your code. Some focus areas:

Correctly separate concerns (A procedure should have one purpose)

Code comments when necessary (and comment the correct things, less is more!)

Good variable and function names

Don’t try to apply clever tricks unless you can argue that it’s worth the extra mental burden of parsing