Dev sheet 3 #24
Dev sheet 3 #24
Conversation
…n Simulation.cpp to apply boundary conditions
Dev sheet 3 task 4
Dev sheet 3 task 2
There was a problem hiding this comment.
Note
This is only feedback regarding the code directly. Grade feedback will be on Moodle once we are through with all groups.
Thank you for your submission 💪
Unfortunately, things didn't go as expected with implementing LinkedCells, but it is fine. I hope you can resolve it soon, look at some comments related to it. Small last boundary cell and missing interaction from same cell might be the reason?
Have a look at my other comments too and see if you can implement some changes if they make sense to you. But ofcourse, first focus on the worksheet 4 tasks.
In case, you cannot resolve the existing issues, please reach out to us soon (say by next Wednesday), so we can find another way for you to continue with new worksheet.
I am sure you will do great.
Good luck! 😄
|
|
||
| SimParams parameters{}; | ||
| CommandParser::parse(argc, argsv, parameters); | ||
| LinkedCellContainer particles = Simulation::readFile(parameters); |
There was a problem hiding this comment.
hardcoded for LinkedCells container, the code should work with earlier DirectSum implementation too
edit: I see it is not hardcoded, you handle the choice of container through OPTIONS, but here is a suggestion: instead of LinkedCells inheriting from DirectSum, both should inherit from a common interface in order to be easily extensible to other containers in future. These containers should provide ways to iterate over the particles, and the force class should provide how force is computed between two particles.
| } | ||
| } | ||
|
|
||
| void Force::verlet(LinkedCellContainer &particles, OPTIONS OPTION) { |
There was a problem hiding this comment.
naming the force verlet is confusing, change it to gravitational or something similar
| } | ||
|
|
||
| void Force::lennard_jones(LinkedCellContainer &particles, OPTIONS OPTION) { | ||
| if (OPTION == OPTIONS::NONE) { |
There was a problem hiding this comment.
instead of NONE, use DIRECT_SUM
| x = static_cast<size_t>(domain_size_[0] / r_cutoff) + (extend_x ? 1 : 0); | ||
| y = static_cast<size_t>(domain_size_[1] / r_cutoff) + (extend_y ? 1 : 0); | ||
| z = domain_size.size() == 3 | ||
| ? (static_cast<size_t>((domain_size_[2] / r_cutoff)) + | ||
| (extend_z ? 1 : 0)) | ||
| : 1; |
There was a problem hiding this comment.
If I understand correctly, you are creating an extra small cell at the end of the domain, if the domain size is not exactly divisible by the cutoff. However, I see this as a potential problem for several reasons:
- time step is set in a way that particle doesn't cross an entire cell in one step. So, now with smaller cell, there might be cases when you need small timestep than specified in the worksheet. And depending on how small the cell is, this can be really small and create problems in the simulation. (this is just for you to be aware, but also in general you want to be able to run the simulation with as large a timestep as possible)
- for reflection with ghost particle: if cell is too small then reflection should already happen one cell before as particle is too close to boundary. If you only consider particle in these small boundary cells, they might be too close and create much higher repulsive force and cause simulation to explode?
some other approaches:
- just use a slightly bigger uniformly-sized cells
- just make the last cell a little bigger
| size_t i = static_cast<size_t>((position[0] - left_corner_coordinates[0]) / | ||
| r_cutoff_); | ||
| size_t j = static_cast<size_t>((position[1] - left_corner_coordinates[1]) / | ||
| r_cutoff_); | ||
| size_t k = domain_size_.size() == 3 | ||
| ? static_cast<size_t>( | ||
| (position[2] - left_corner_coordinates[2]) / r_cutoff_) | ||
| : 0; | ||
|
|
||
| int index = i + j * x + k * x * y; | ||
| std::vector<ParticlePointer> neighbours; | ||
|
|
||
| int X = static_cast<int>(x); | ||
| int Y = static_cast<int>(y); | ||
| int Z = static_cast<int>(z); | ||
| // handle 2d case | ||
| // Convert 1D index to 3D coordinates | ||
| i = index / (Y * Z); | ||
| j = (index % (Y * Z)) / Z; | ||
| k = index % Z; |
There was a problem hiding this comment.
this feels a bit weird. why did we start with i,j,k then calculate index and then again calculate i,j,k?
| } | ||
|
|
||
| p.updateX(position[0], position[1], position[2]); | ||
| p.updateV(velocity[0], velocity[1], velocity[2]); |
There was a problem hiding this comment.
while it is fine, I feel like this can be optimized (maybe consider as an optimization in WS4) by minimizing the number of if-else loops as this will be done at every step. You can also leave it as it is if there are other things you would like to do first, it is nothing urgent.
| } | ||
|
|
||
| for (auto &particle : particles) { | ||
| for (auto neighbour : particles.get_neighbours(particle)) { |
There was a problem hiding this comment.
it seems like you have missed considering the interaction from particles in the same cells as the current particle. the get_neighbours() only returns particle in the neighbouring cells and not the same cell.
Summary: