PHAS0100ASSIGNMENT1

Purpose

This project serves as a starting point for the PHAS0100 2021/22 Assignment 1 Game of Life Simulation coursework. It has a reasonable folder structure for CMake based projects,
that use CTest to run unit tests via Catch.

Further information on the specific project is left as an exercise for the student.

Credits

This project is maintained by Dr. Jim Dobson. It is based on CMakeCatch2 that was originally developed as a teaching aid for UCL's "Research Computing with C++"
course developed by Dr. James Hetherington
and Dr. Matt Clarkson.

Build Instructions

Contents

Introduction

How to build

How to use golSimulator

How to use golStillLifes

How to run tests

Introduction

Welcome to the C++-based Conway's "Game of Life".

• In this project, to specifically investigate the way Conway's "Game of Life" evolves, we have provided the command line application golSimulator to implement two input methods (file input mesh, random initialisation mesh) and thus Create a grid of your choice. Based on this grid, you can specify the number of iterations and print out the results of each iteration according to Conway's "Game of Life" rules. The result is printed out.

• In this project, a command line application golStillLife is provided in order to explore the way still life (i.e. a mesh that has not changed anything between iterations and is not completely empty) evolves. This application generates a number of random meshes based on the parameters you enter, and performs a process based on Conway's Game of Life rules and eventually prints out a grid that matches the definition of a still life.

• In addition, we provide a unit testing application golGameGridTest based on CTest and Catch for unit testing the game grid class.

Next, the parameter rules and how to use them are described in the next three chapters.

How to build

First, go to the root directory of the file with the help of the IDE's terminal.

mkdir build
cd build

The project is compiled based on Cmake. Therefore, if you are using it for the first time, simply enter the following command line in the newly created build directory.

cmake ..
make

Normally the program takes close to a minute to compile. When the compilation is complete, you will see the following output.

[ 28%] Built target PHAS0100ASSIGNMENT1
[ 38%] Built target golStillLife
[ 47%] Built target golSimulator
[ 57%] Built target golMyFirstApp
Scanning dependencies of target golGameGridTest
[ 61%] Building CXX object Testing/CMakeFiles/golGameGridTest.dir/golGameGridTest.cpp.o
[ 66%] Linking CXX executable ../bin/golGameGridTest
[ 71%] Built target golGameGridTest
[ 85%] Built target golCommandLineArgsTest
[100%] Built target golBasicTest

How to use golSimulator

After compiling, follow the rules below to use the command line application golSimulator.

The application golSimulator provides the user with two ways to build a grid.

1. text input

You can specify an input file and thus build a grid of your choice. Based on this mesh, you need to specify the number of iterations.

The input command has two parameters, the file path and the number of iterations to be attempted. Example.

./bin/golSimulator ./Testing/Data/glider.txt 3 

The above command represents our determination that the input file is . /Testing/Data/glider.txt. Based on this file, the mesh we build will go through 3 iterations.

Normally, you would see output like this!

----------
--o-------
o-o-------
-oo-------
----------
----------
----------
----------
----------
----------
 
<----------Inter-iteration-separator---------------->
----------
-o--------
--oo------
-oo-------
----------
----------
----------
----------
----------
----------
 
<----------Inter-iteration-separator---------------->
----------
--o-------
---o------
-ooo------
----------
----------
----------
----------
----------
----------
 
<----------Inter-iteration-separator---------------->

2. Random initial grid

You can customise the size of the specified grid and the total number of initial live cells to be placed, thus creating a randomised generated grid. Based on this grid, you need to specify the number of iterations and the grid will loop as many times as you specify and print out the current grid.

The input command has 4 parameters, rows, columns, the number of live cells and the number of iterations for each grid. Example.

./bin/golSimulator 20 12 30 3

This means we will generate an initialised grid with 30 surviving cells with a width of 20 and a height of 12, and follow the rules for 3 iterations.

Normally, you would see similar output!

--o----o------o--o--
----o-o-------o----o
----o-o-------------
------o-------------
---------o-----o----
--- oo-------o-------
------------------o-
--------o-------o--
--- oo-----o------o--o-
oo---------o--------
-------------------o
---------o-------oo-
 
<----------Inter-iteration-separator---------------->
--------------------
---o--oo ------------
------oo------------
-----o--------------
--------------------
--------------------
--------------------
-----------------o--
oo------------------
oo------------------
------------------o-
------------------o-
 
<----------Inter-iteration-separator---------------->
--------------------
------oo------------
-----o-o------------
------o-------------
--------------------
--------------------
--------------------
--------------------
oo------------------
oo------------------
--------------------
--------------------
 
<----------Inter-iteration-separator---------------->

How to use golStillLifes

You can customize the size of the specified grid and the total number of initial live cells to be placed, thus creating a number (maximum 10) of randomized generated grids. For each grid, you need to specify the number of iterations. During these times, the program will check if the mesh meets the still life criteria and print all still life.

The input command has 4 parameters, rows, columns, the number of surviving cells and the number of iterations for each grid. Example.

./bin/golStillLifes 4 4 6 10

This means that we will generate an initialized grid with 6 survival cells with a width of 4 and a height of 4 and follow the rules for 10 iterations.

Normally, you would see output like this!

--o-
-o-o
-o-o
--o-
 
<----------Inter-iteration-separator---------------->
----
----
oo--
oo--
 
<----------Inter-iteration-separator---------------->
--oo
-o-o
--o-
----
 
<----------Inter-iteration-separator---------------->
----
-oo-
o--o
-oo-
 
<----------Inter-iteration-separator---------------->
--oo
-o-o
--o-
----
 
<----------Inter-iteration-separator---------------->
----
----
oo--
oo--
 
<----------Inter-iteration-separator---------------->
-o--
o-o--
o-o-
-o--
 
<----------Inter-iteration-separator---------------->
--oo
-o-o
--o-
----
 
<----------Inter-iteration-separator---------------->

As you can see, out of the 10 random initialization grids, we found 8 still lifes.

How to run tests

In addition, we also provide the unit testing application golGameGridTest for unit testing the game grid class.

You can use it with the following command!

./bin/golGameGridTest

PHAS0100Assignment2

Purpose

This project serves as a starting point for the PHAS0100 Assignment 2 Gravitational N-body Simulation coursework. It has a reasonable folder structure for CMake based projects,
that use CTest to run unit tests via Catch.

Further information on the specific project is left as an exercise for the student.

Credits

This project is maintained by Dr. Jim Dobson. It is based on CMakeCatch2 that was originally developed as a teaching aid for UCL's "Research Computing with C++"
course developed by Dr. James Hetherington
and Dr. Matt Clarkson.

Build Instructions

Contents

Introduction

How to build

How to use solarSystemSimulator

How to use openMpSystemSimulator

How to run tests

Energy comparison based on solarSystemSimulator

Benchmark results based on solarSystemSimulator

Benchmark results based on openMpSystemSimulator

Introduction

Welcome to N-body gravity simulation built in C++.

• This project realizes the simulation of particle motion in the presence of N-body gravitation, and extends it to the motion of various celestial bodies. In this project, we designed the command line program solarSystemSimulator. Furthermore, we designed the command line program openMpSystemSimulator. Based on the above design, we also conduct benchmarking and accuracy verification.

• Specifically, first of all, we designed the Particle class and MassiveParticle class to simulate the motion principle of particles. After that, in order to generate particle clusters of different modes, we also designed Generator class, SolarSystemGenerator class and RandomParticleClusterGenerator class to generate different kinds of particle clusters. After that, we developed the command-line program solarSystemSimulator to simulate the motion of various celestial bodies in the solar system. After that, we developed the command-line program openMpSystemSimulator to implement N-body motion simulation of random particle clusters optimized by OpenMp parallelization.

• In addition, we provide a unit testing application nbsimSystemSimulatorTest based on CTest and Catch for unit testing the Particle class and the MassiveParticle class.

The last three chapters will be used to present the benchmark results and accuracy test results of the program.

How to build

First, go to the root directory of the file with the help of the IDE's terminal.

mkdir build
cd build

The project is compiled based on Cmake. Therefore, if you are using it for the first time, simply enter the following command line in the newly created build directory.

cmake..
make

Normally the program takes close to a minute to compile. When the compilation is complete, you will see the following output.

Scanning dependencies of target phas0100assignment2
[ 7%] Building CXX object Code/Lib/CMakeFiles/phas0100assignment2.dir/nbsimParticle.cpp.o
[ 14%] Building CXX object Code/Lib/CMakeFiles/phas0100assignment2.dir/nbsimMassiveParticle.cpp.o
[ 21%] Building CXX object Code/Lib/CMakeFiles/phas0100assignment2.dir/nbsimParticleGenerator.cpp.o
[ 28%] Linking CXX static library ../../bin/libphas0100assignment2.a
[ 50%] Built target phas0100assignment2
[ 57%] Linking CXX executable ../../bin/openMpSystemSimulator
[ 64%] Built target openMpSystemSimulator
[ 71%] Linking CXX executable ../../bin/solarSystemSimulator
[ 78%] Built target solarSystemSimulator
[ 85%] Linking CXX executable ../bin/nbsimSystemSimulatorTest
[100%] Built target nbsimSystemSimulatorTest

How to use solarSystemSimulator

After compiling, follow the rules below to use the command line application solarSystemSimulator.

The command line application solarSystemSimulator provides us with a way to simulate the motion of various celestial bodies in the solar system before and after the specified motion time. The data of each celestial body at the beginning comes from the solar system started on the epoch of 2021-01-0T00:00:00Z. You can enter parameters to control the timing and step size of its motion, and observe the energy, position results, and elapsed time of the solar system before and after the simulated motion.

The input command has two parameters, which are the number of iterations and the iteration step size. Example.

./bin/solarSystemSimulator 3650 0.000274

Among them, the input of 3650 and 0.000274 means that you want the solar system to perform 3650 iterations of simulation calculations with an iterative step size of 0.000274 years (about 0.1 days), that is, to simulate the solar system after about 1.0001 year movement.

Normally, you would see output like this!

Before the simulation starts, 
The kinetic energy of the system objects is 0.187358
The potential energy of the system objects is -0.356872
The total energy of the solar system objects is -0.169514
Below are the initial positions of the solar system bodies before the simulation started.

The initial position of Sun is at:
-0.00670894
  0.0060565
 0.00010651
 
The initial position of Mercury is at:
  0.230275
 -0.351957
-0.0508834
 
The initial position of Venus is at:
-0.453178
-0.563815
0.0180571
 
The initial position of Earth is at:
  -0.185741
   0.972886
4.83111e-05
 
The initial position of Mars is at:
 0.614263
  1.38167
0.0136846
 
The initial position of Jupiter is at:
   3.0346
 -4.08225
-0.050909
 
The initial position of Saturn is at:
    5.4834
  -8.33624
-0.0732546
 
The initial position of Uranus is at:
  15.3436
  12.4673
-0.152634
 
The initial position of Neptune is at:
  29.4537
 -5.22631
-0.571104
 
<------------------------------------------------------ > 
After the simulation ends,
The kinetic energy of the system objects is 0.222977
The potential energy of the system objects is -0.392047
The total energy of the solar system objects is -0.169071
After a simulation with a time step of 0.000274 years and a simulation time of 1.0001 years, the following are the final positions of the celestial bodies in the solar system after the simulated motion.The final position of Sun is at:
-0.00850808
 0.00286806
0.000173415
 
The final position of Mercury is at:
 -0.133503
  -1.03322
-0.0742189
 
The final position of Venus is at:
  0.171486
  0.753935
7.4371e-05
 
The final position of Earth is at:
-0.0882755
   1.00545
4.6332e-05
 
The final position of Mars is at:
 -2.52465
  1.26141
0.0881059
 
The final position of Jupiter is at:
   4.32898
  -1.39267
-0.0910706
 
The final position of Saturn is at:
  6.83314
 -6.88108
-0.152436
 
The final position of Uranus is at:
  14.2433
  13.3617
-0.135071
 
The final position of Neptune is at:
  29.5955
 -4.08302
-0.597839
 
CPU time used: 3.898518 s
Wall clock time passed: 3.898581 s

Among them, before starting the simulation, the kinetic energy of the system is 0.187358, the potential energy is -0.356872, the total energy of the solar system objects is -0.169514. After the simulated motion, their values ​​are 0.222977, -0.392047, -0.169071, which basically follow the conservation of energy. In addition, the initial position of each celestial body is also printed, for example, before the motion simulation starts, the initial position of the earth is (-0.185741 0.972886 4.83111e-05), and after about 1 year of simulated motion, its position It is (-0.0882755 1.00545 4.6332e-05), which remains basically unchanged, which means that the planet has completed one revolution in a year and roughly returned to its previous position.

In addition, you can also enter the -h or --help identifier to see more help information.

./bin/solarSystemSimulator -h

./bin/solarSystemSimulator --help

How to use openMpSystemSimulator

Similarly, we provide the command line application openMpSystemSimulator for simulating 2000 random particles

After compiling, follow the rules below to use the command line application solarSystemSimulator.

The command line application solarSystemSimulator provides us with a way to simulate the motion of various celestial bodies in the solar system before and after the specified motion time. You can enter parameters to control the time and step size of its motion, and observe the energy and position results of the solar system before and after the simulated motion.

The input command has two parameters, which are the number of iterations and the iteration step size. Example.

./bin/openMpSystemSimulator 3650 0.000274

Among them, the input of 3650 and 0.000274 means that you want the cluster to perform 3650 iterative simulation calculations with an iterative step size of 0.000274 years (about 0.1 days), that is, to simulate the cluster after Movement for about 1.0001 years.

Normally, you would see output like this!

Before the simulation starts,
The kinetic energy of the system objects is 0.0186525
The potential energy of the system objects is -1.51196
The total energy of the solar system objects is -1.49331
<------------------------------------------>
After the simulation ends,
The kinetic energy of the system objects is 0.0186525
The potential energy of the system objects is -1.51196
The total energy of the solar system objects is -1.49331
CPU time used: 55.242669 s
Wall clock time passed: 55.246126 s

How to run tests

In addition, we also provide the unit testing application nbsimSystemSimulatorTest for unit testing the Particle class and MassiveParticle class.

You can use it with the following command!

./bin/nbsimSystemSimulatorTest

Energy comparison based on solarSystemSimulator

Before the simulation, we knew the initial energy of the solar system as shown in the table below.

In order to reflect the influence of the step size selection on the energy before and after the simulation of the motion of the solar system, we selected 10 different step sizes to simulate 100 years of time, and counted the kinetic energy, potential energy, and total energy of the solar system after the simulation, as shown in the following table Show.

As shown in the above table, with the gradual reduction of the iteration step size, the energy of the system gradually converges to the initial energy before the simulation. This means that the selection of the iterative step size controls the accuracy of the iterative simulation calculation. The smaller the step size, the higher the accuracy of the simulation.

Benchmark results based on solarSystemSimulator

Similarly, we picked 10 different sets of step sizes for benchmarking the simulation run times. The statistical results are shown in the table below.

As shown in the table above, as the iteration step size is gradually reduced, the CPU time and Wall Clock Time spent are higher. This means that the smaller the step size, the longer the computation time required for the simulation.

Based on the above considerations, we choose a time step value of 0.000274 that provides a good balance between simulation runtime and accuracy.

Benchmark results based on openMpSystemSimulator

Next, we used OpenMp for parallelized simulation optimization, and counted the benchmark results before and after optimization. Among them, we selected several groups of different iteration times and iteration steps, and recorded the CPU time and Wall Clock Time under different threads of the simulation calculation of 2000 random particle clusters based on this.

Below are the results of the CPU time.

Below are the results for Wall Clock Time.

It is not difficult to see that the two usages show opposite results. When not parallelized and when the number of threads is 1, the two times are basically the same. When parallelization and multi-threading are enabled, the CPU time increases as the number of threads increases, while the Wall Clock Time decreases as the number of threads increases.