It is not guaranteed, that all the nodes in the following loops are unique: it is possible that node A has node B as its neighbour by more than one direction (for example, (A->get_top() == &B) && (A->get_right() == &B)). In such situation B->temp_trail will be increased twice instead of once.

We need to fix this piece of code, and also look for similar cases and either fix them if they are affected by the same mistake or write a comment explaining why this is not an issue there, to make it clear that the piece of code was not forgotten but is correct.

Current SimulationMap constructor complexity seems to be N^2, where N is the number of nodes being created (because of find_index_of_nearest_node's complexity N). Must be better. Should be fixable with a hash map

Because both faces of Polyhedron and particles at MapNodes are allocated in device memory, it is impossible to access them from host, so the data can't be sent to visualization

Because the distance between two (neighbor) MapNodes is approximately 2 * jones_constants::speed, when a particle makes a move it's guaranteed that if all the neighbor nodes of the "current" node (on which the particle is located) have the same face with the current node, then after the move the particle will stay on the same face, so there is no need to project the move vector. However, it is not checked and we always do project the vector, which is suboptimal:

When running in the debug mode with compilation for GPU, SIGBUS is raised in main.cu inside main while trying to get access to simulation_map->nodes

(This may be a duplicate of #29 or a symptom of #32. This is likely to be a duplicate of #31)

For smaller cubes, which seems to be not affected by #32 (at least, I'm not receiving SIGABRTs for them), another error occurs.

The app compiled for GPU fails to finish constructing a SimulationMap object because of an illegal memory access (attaching a patch I'm using to determine this)
gpu.patch.txt (GitHub doesn't allow uploading .patch files for some reason...)

The app compiled for CPU does finish SimulationMap initialization (at least for me) but fails on the second iteration of the loop:

The fucking_shit.cu and fucking_shit.cuh files were created in order to save time on deciding where to place some functions and which scope they should be located at. I think it's time to fix this. The functions located at fucking_shit.cu/cuh should either be moved to other files, become methods or be removed at all

Current SimulationMap's implementation requires moving MapNodes, but because the Face::node fields are set to pointers to MapNodes during the creation of the grid of nodes, moving them invalidates the pointers set at faces.

The solution is to set Face::node fields only after the whole grid is created, at the end of SimulationMap constructor

When running in the debug mode with compilation for CPU, SIGABRT is raised inside of the SimulationMap constructor. According to git bisect, the problem first appeared at d5411a5

Because it's not possible to allocate an array of MapNodes with the operator new[] when using an array of MapNodes user will face a problem: when trying to replace an element of the array with another MapNode object, the destructor will be called for the old object, which was never constructed (but instead was allocated with malloc or created in any other c-style way) and, therefore, has the particle field invalidated. When the destructor is called, it tries to delete a particle by the particle address, which is invalid. This results in an error.

The workaround is to call the detach_particle() method before replacing an array object, but it looks ugly and should be fixed on the MapNode class side

Implement copy/move constructors and assignment operators for classes, for which this makes sense

Some of the IDE's files (like code style settings) should be indexed by git

I don't like the implementation of find_face_index. I believe it would be better to have a Face method, returning a cached value instead of this function

First vertex of Face::vertices must be repeated in the end, but it's better if the user doesn't have to do that. Face constructor should get vertices and their number without repetition, then allocate memory for Face::vertices of size n_of_vertices + 1. Face::n_of_vertices should be equal n_of_vertices

The normal field is currently a normal of the face the particle is located at. But this is a duplicated information (the normal is stored in the Face object already), neither normal is a property of a particle in any way. So, the field must be removed, the some_particle->map_node->get_face()->get_normal() expression should be used to retrieve a normal given a particle

Reread the whole code and bring both identifiers' names and documentation to a single style. Also, fix typos, language mistakes. It would be perfect to create a Markdown document describing the rules of our documenting style

I think the condition should be just != 200

Check all includes and rewrite them to follow the rule: all files and libraries used in file A has to be included in file A, even if some of them are already included through other files. Also check for other problems such as unused includes. For example:

Incorrect:

//a.cpp
#include <cmath>

//using `cmath` functions

//b.cpp
#include "a.cpp"

//using `cmath` and `a.cpp` functions

Correct:

//a.cpp
#include <cmath>

//using `cmath` functions

//b.cpp
#include <cmath>

#include "a.cpp"

//using `cmath` and `a.cpp` functions

Not only the map_node neighbours but also their neighbours should be checked in this piece of code:

I would really appreciate a comment from @tanya-kta with a pretty detailed explanation of the reason for this (probably with a picture)