# Similar error for different test cases- "Inadequate World Size" **URL:** \ **Category:** Issues\ **Created:** [March 4, 2024, 8:42pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199 "2024-03-04T20:42:41Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![AlirezaZarei](https://avatars.discourse-cdn.com/v4/letter/a/b5ac83/32.png) [@AlirezaZarei](https://gpusph.discourse.group/u/AlirezaZarei)\ **Post date:** [March 4, 2024, 8:42pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/1 "2024-03-04T20:42:41Z")
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 ![Screenshot 2024-03-04 at 12.32.09 PM](https://global.discourse-cdn.com/free1/uploads/gpusph/original/1X/fda8d8a4391dda6b8abf33605f21ab64d108f799.png) ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [March 4, 2024, 9:31pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/2 "2024-03-04T21:31:38Z")
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) ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [March 5, 2024, 9:44pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/3 "2024-03-05T21:44:45Z")
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](https://github.com/GPUSPH/gpusph/issues/81). Removing the explicit assignment to `m_size` and `m_origin` should fix the issue. ---
**Author:** ![AlirezaZarei](https://avatars.discourse-cdn.com/v4/letter/a/b5ac83/32.png) [@AlirezaZarei](https://gpusph.discourse.group/u/AlirezaZarei)\ **Post date:** [March 6, 2024, 2:02am UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/4 "2024-03-06T02:02:54Z")
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 ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [March 6, 2024, 7:39am UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/5 "2024-03-06T07:39:56Z")
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. ---
**Author:** ![AlirezaZarei](https://avatars.discourse-cdn.com/v4/letter/a/b5ac83/32.png) [@AlirezaZarei](https://gpusph.discourse.group/u/AlirezaZarei)\ **Post date:** [March 6, 2024, 7:59am UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/6 "2024-03-06T07:59:53Z")
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! ---
**Author:** ![giuseppe.bilotta](https://yyz2.discourse-cdn.com/free1/user_avatar/gpusph.discourse.group/giuseppe.bilotta/32/72_2.png) [@giuseppe.bilotta](https://gpusph.discourse.group/u/giuseppe.bilotta)\ **Post date:** [March 6, 2024, 3:10pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/7 "2024-03-06T15:10:49Z")
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](https://gpusph.discourse.group/t/inquire-about-recommendations-to-improve-the-interface-for-dem-topography/198). 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: ```auto m_size.y = some_width; m_origin.y = -some_width/2; ``` would only override the `y` direction and leave `x`, `z` to be autocomputed. ---
**Author:** ![AlirezaZarei](https://avatars.discourse-cdn.com/v4/letter/a/b5ac83/32.png) [@AlirezaZarei](https://gpusph.discourse.group/u/AlirezaZarei)\ **Post date:** [March 7, 2024, 5:43am UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/8 "2024-03-07T05:43:14Z")
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. ---
**Author:** ![AlirezaZarei](https://avatars.discourse-cdn.com/v4/letter/a/b5ac83/32.png) [@AlirezaZarei](https://gpusph.discourse.group/u/AlirezaZarei)\ **Post date:** [March 12, 2024, 3:50pm UTC](https://gpusph.discourse.group/t/similar-error-for-different-test-cases-inadequate-world-size/199/9 "2024-03-12T15:50:41Z")
Hi Giuseppe, Could you tell me the path to pull my new branch?