physarumadv / minds_crawl Goto Github PK
View Code? Open in Web Editor NEWPhysarum polycephalum growth simulator on polyhedron surfaces written in CUDA C++
License: MIT License
Physarum polycephalum growth simulator on polyhedron surfaces written in CUDA C++
License: MIT License
(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 SIGABRT
s 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:
minds_crawl/src/main_logic/main.cpp
Lines 55 to 68 in 66da82c
Implement copy/move constructors and assignment operators for classes, for which this makes sense
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
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.
minds_crawl/src/main_logic/simulation_motor.cuh
Lines 156 to 165 in 8e132c0
Because both faces of Polyhedron
and particles at MapNode
s are allocated in device memory, it is impossible to access them from host, so the data can't be sent to visualization
minds_crawl/src/simulation_objects/MapNode.cu
Lines 8 to 10 in e150e17
Face *polyhedron_face
, so this face can be not connected with accepted polyhedron
int polyhedron_face_id
Current SimulationMap
's implementation requires moving MapNode
s, but because the Face::node
fields are set to pointers to MapNode
s 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
nodes_directions
to an array of size n_of_faces
. When the first node is created on the face, direction to all top neighbors of all nodes lying on this face must be assigned in this arrayI 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
Because the distance between two (neighbor) MapNode
s 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:
Lines 40 to 41 in a1d483f
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
Some of the IDE's files (like code style settings) should be indexed by git
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 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
I think the condition should be just != 200
Not only the map_node
neighbours but also their neighbours should be checked in this piece of code:
minds_crawl/src/simulation_objects/Particle.cu
Lines 41 to 51 in f4dc1c9
I would really appreciate a comment from @tanya-kta with a pretty detailed explanation of the reason for this (probably with a picture)
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
minds_crawl/src/simulation_objects/Particle.cuh
Lines 150 to 151 in f4dc1c9
Because it's not possible to allocate an array of MapNodes
with the operator new[]
when using an array of MapNode
s 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
detach_particle()
in the above piece of code must be commented. It looks absolutely out of place without a commentCheck 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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.