Reference no: EM131488930

Introduction

This project will use parallelism, not for speeding data computation, but for programming convenience. You will create a month-by-month simulation in which each agent of the simulation will execute in its own thread where it just has to look at the state of the world around it and react to it.

You will also get to exercise your creativity by adding an additional "agent" to the simulation, one that impacts the state of the other agents and is impacted by them.

Requirements

1. You are creating a month-by-month simulation of a grain-growing operation. The amount the grain grows is affected by the temperature, amount of precipitation, and the number of "graindeer" around to eat it. The number of graindeer depends on the amount of grain available to eat.
2. The "state" of the system consists of the following global variables:
3.
4. int NowYear; // 2017 - 2022
5. int NowMonth; // 0 - 11 6.
7. float NowPrecip; // inches of rain per month
8. float NowTemp; // temperature this month
9. float NowHeight; // grain height in inches
10. int NowNumDeer; // number of deer in the current population
11. Your basic time step will be one month. Interesting parameters that you need are:
12.
13. const float GRAIN_GROWS_PER_MONTH = 8.0;
14. const float ONE_DEER_EATS_PER_MONTH = 0.5; 15.

16. const float AVG_PRECIP_PER_MONTH = 6.0; // average
17. const float AMP_PRECIP_PER_MONTH = 6.0; // plus or minus
18. const float RANDOM_PRECIP = 2.0; // plus or minus
noise 19.
20. const float AVG_TEMP = 50.0; // average
21. const float AMP_TEMP = 20.0; // plus or minus
22. const float RANDOM_TEMP = 10.0; // plus or minus noise
23.
24. const float MIDTEMP = 40.0;
25. const float MIDPRECIP = 10.0;

Units of grain growth are inches.
Units of temperature are degrees Fahrenheit (°F). Units of precipitation are inches.

26. Because you know ahead of time how many threads you will need (3 or 4), start the threads with a parallel sections directive:
27.
28. omp_set_num_threads( 4 ); // same as # of sections
29. #pragma omp parallel sections
30. {
31. #pragma omp section
32. {
33. GrainDeer( );
34. }
35.
36. #pragma omp section
37. {
38. Grain( );
39. }
40.
41. #pragma omp section
42. {
43. Watcher( );
44. }
45.
46. #pragma omp section
47. {
48. MyAgent( ); // your own
49. }
50. } // implied barrier -- all functions must return in order
51. // to allow any of them to get past here
52. The temperature and precipitation are a function of the particular month:
53.
54. float ang = ( 30.*(float)NowMonth + 15. ) * ( M_PI / 180. ); 55.
56. float temp = AVG_TEMP - AMP_TEMP * cos( ang );
57. unsigned int seed = 0;
58. NowTemp = temp + Ranf( &seed, -RANDOM_TEMP, RANDOM_TEMP ); 59.
60. float precip = AVG_PRECIP_PER_MONTH + AMP_PRECIP_PER_MONTH * sin( ang
);
61. NowPrecip = precip + Ranf( &seed, -RANDOM_PRECIP, RANDOM_PRECIP );

62. if( NowPrecip < 0. )
63. NowPrecip = 0.;

To keep this simple, a year consists of 12 months of 30 days each. The first day of winter is considered to be January 1. As you can see, the temperature and precipitation follow cosine and sine wave patterns with some randomness added.

64. Starting values are:
65.
66. // starting date and time:
67. NowMonth = 0;
68. NowYear = 2017; 69.
70. // starting state (feel free to change this if you want):
71. NowNumDeer = 1;
72. NowHeight = 1.; 73.
74. In addition to this, you must add in some other phenomenon that directly or indirectly controls the growth of the grain and/or the graindeer population. Your choice of this is up to you.
75. You are free to tweak the constants to make everything turn out "more interesting".

Structure of the Simulation Functions

Each simulation function will have a structure that looks like this:

while( NowYear < 2023 )
{
// compute a temporary next-value for this quantity
// based on the current state of the simulation:
. . .

// DoneComputing barrier:
#pragma omp barrier
. . .

// DoneAssigning barrier:
#pragma omp barrier
. . .

// DonePrinting barrier:
#pragma omp barrier
. . .
}

Doing the Barriers on Visual Studio

You will probably get this error when doing this type of project in Visual Studio:

'#pragma omp barrier' improperly nested in a work-sharing construct

The OpenMP specifications says: "All threads in a team must execute the barrier region." Presumably this means that placing corresponding barriers in the different functions does not qualify, but somehow gcc/g++ are OK with it.

Here is a work-around. Instead of using the
#pragma omp barrier line, use this: WaitBarrier( );

You must call InitBarrier( n ) as part of your setup process, where n is the number of threads you will be waiting for at this barrier. Presumably this is 3 before you add your own quantity and is 4 after you add your own quantity.

I'm not particularly proud of this code, but it seems to work. To make this happen, first declare the following global variables:

omp_lock_t Lock;
int NumInThreadTeam;
int NumAtBarrier;
int NumGone;

Here are the function prototypes:

void InitBarrier( int ); void WaitBarrier( );

Here is the function code:

// specify how many threads will be in the barrier:
// (also init's the Lock)

void
InitBarrier( int n )
{
NumInThreadTeam = n; NumAtBarrier = 0; omp_init_lock( &Lock );
}

// have the calling thread wait here until all the other threads catch up: void
WaitBarrier( )
{
omp_set_lock( &Lock );
{
NumAtBarrier++;
if( NumAtBarrier == NumInThreadTeam )
{

doing immediately

}
}

NumGone = 0;
NumAtBarrier = 0;
// let all other threads get back to what they were

// before this one unlocks, knowing that they might

// call WaitBarrier( ) again:
while( NumGone != NumInThreadTeam-1 ); omp_unset_lock( &Lock );
return;

omp_unset_lock( &Lock );

while( NumAtBarrier != 0 ); // this waits for the nth thread to
arrive

#pragma omp atomic
NumGone++; // this flags how many threads have returned
}

Random Numbers

How you generate the randomness is up to you. As an example (which you are free to use), Joe Parallel wrote a couple of functions that return a random number between a user-given low value and a high value (note that the name overloading is a C++-ism, not a C-ism):

#include <stdlib.h>

unsigned int seed = 0; // a thread-private variable float x = Ranf( &seed, -1.f, 1.f );

. . .

float
Ranf( unsigned int *seedp, float low, float high )
{
float r = (float) rand_r( seedp ); // 0 - RAND_MAX

return( low + r * ( high - low ) / (float)RAND_MAX );
}

int
Ranf( unsigned int *seedp, int ilow, int ihigh )
{
float low = (float)ilow;
float high = (float)ihigh + 0.9999f;

return (int)( Ranf(seedp, low,high) );
}

Results

Turn in your code and your PDF writeup. Be sure your PDF is a file all by itself, that is, not part of any zip file. Your writeup will consist of:

1. What your own-choice quantity was and how it fits into the simulation.
2. A table showing values for temperature, precipitation, number of graindeer, height of the grain, and your own-choice quantity as a function of month number.
3. A graph showing temperature, precipitation, number of graindeer, height of the grain, and your own-choice quantity as a function of month number. Note: if you change the units to
°C and centimeters, the quantities might fit better on the same set of axes.

cm = inches * 2.54
°C = (5./9.)*(°F-32)

This will make your heights have larger numbers and your temperatures have smaller numbers.

4. A commentary about the patterns in the graph and why they turned out that way. What evidence in the curves proves that your own quantity is actually affecting the simulation?

Attachment:- project assignment.pdf