Hi Giuseppe,
I hope all is well with you.
I get the attached error after a few time steps when compiling test cases with a flap. For example, when I run the “WaveTank” example with all the default values, I get this error. Moreover, when I use DEM to have an arbitrary bathymetry and try to make some regular waves with a flap, I get this error either. Sometimes, changing delta_p helps and leads to running the case for more time steps, but eventually, I get this error again. Do you have any suggestions?
“ERROR: cell 406 [grid position (12, 0, 11), global position (1.62677, 0.075, 1.58125)] on device 0 has too many particles (2390 > 2047)
Possible reasons:
inadequate world size (23418 particles were marked as out-of-bounds during init)
fluid column collapse
Command CHECK_NEIBSNUM threw ‘overfull cell’ at iteration 13550
Elapsed time of simulation cycle: 159.3s [sim time: 0.9824, ratio 162.2]
dt range [3.999999899e-05, 7.250418275e-05], max neibs ranges [80, 87]+[0,0]
Peak particle speed was ~0.720344 m/s at 0.600302 s → can set maximum vel 0.7924 for this problem
Simulation end, cleaning up…
Deallocating…”
Regards,
Alireza
Hello @AlirezaZarei,
as the error message says, this is caused by too many particles ending up in the same cell (in the grid used for the neighbors list construction, uniform precision and multi-device). This can happen either due an issue during problem initialization, or when there are moving objects.
In your case, the error is reporting that the world size was not set correctly during initialization (you should have gotten a warning, but it’s easy to miss it; it can be turned into an error by running with the option --debug validate-init-positions.
Some examples of how moving objects can cause this issue:
-
during their motion, the moving object ends up overlapping existing geometries (e.g. if the flap intersects the DEM in some place);
-
if the objects are moving at high speed and this isn’t taken into account in the sound speed computation.
In your case, I think the first thing to do is to understand why some particles are being placed out of bounds. Can you try switching some of the geometries on and off to determine which one is causing the issue? Running with --debug validate-init-positions --maxiter 1 is an easy way to determine under which circumstances you get the error, without running a full simulation.
Since you are using the DEM, keep in mind I’ve recently made several fixes to its filling. Make sure you’re up to date (git branch --contains 2ad1559d5d88ded0f943b84e20f7c5e9ab24db44 should include the branch you’re working on)
Hello again @AlirezaZarei, one more thing about the test case: if your test case is built as a modification of the WaveTank test case that ships with GPUSPH, please be aware that during the cleanup that was done for the version 5 release we left in by mistake an explicit setting of the world size and origin (see also issue #81 on GitHub. Removing the explicit assignment to m_size and m_origin should fix the issue.
Thanks, Giuseppe!
I used --debug validate-init-positions, and it really helped me to understand which particles were out of the domain. Then, I modified the global size (m_size), and now, my model works perfectly.
Actually, my model is a combination of DEM and a flap for making regular waves. It’s not based on the “WaveTank” example. I just tested the WaveTank to see whether I got the same error for that or not.
To wrap up, what you said about initialization and possible cases that this error might happen was totally right.
regards,
Alireza
Hello @AlirezaZarei, good to know that you managed to fix it.
Note that as a general rule it’s not necessary to set m_size or m_origin manually in the problem file. It may be necessary in some exceptional cases, but if I remember correctly this is not why it’s in WaveTank —we just forgot to remove it during the latest cleanup.
You are right. It’s not necessary to set m_size or m_origin, and I didn’t use it for my previous cases, but my new case is exceptional because I want to remove the 3 layers of boundary particles and use periodic boundary in the Y direction. So, I have to set m_size to imply the periodic boundary in the right place.
Moreover, my case is not based on the WaveTank example, I just wanted to run the WaveTank example to see the movement of the paddle which I was not successful!
Thanks again!
Ah, interesting. The Problem API 1 tries to take into account periodicity in establishing the world size and origin, although to be fair I don’t think this has ever been tried in combination with a DEM because we generally assume the DEM is enclosed. I assume you’re cutting off the DEM box walls in the periodic direction and have to adjust the size and origin because of this? Would it be possible to share what you are doing to see if the API can be improved to make things easier/possible without having to set things manually? If you have specific recommendations on how to improve the DEM interface you can also comment in this thread.
By the way, if you need to override the size and/or origin in only one direction you can limit yourself to that direction, leaving the other directions to be undefined/auto-computed, for example:
m_size.y = some_width;
m_origin.y = -some_width/2;
would only override the y direction and leave x, z to be autocomputed.
Yes, you guessed right. I’m cutting off the DEM box walls in the periodic direction and have to adjust the size and origin because of that. I’ve created a new branch and will share it with you ASAP. Actually, I’m cleaning the branch and adding some comments to it.
Hi Giuseppe,
Could you tell me the path to pull my new branch?
