# Particle lost without warning/error or being killed, stalling the run **URL:** \ **Category:** User Support\ **Created:** [June 14, 2023, 4:12pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098 "2023-06-14T16:12:31Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![MIB101](https://avatars.discourse-cdn.com/v4/letter/m/a9adbd/32.png) [@MIB101](https://openmc.discourse.group/u/MIB101)\ **Post date:** [June 14, 2023, 4:12pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/1 "2023-06-14T16:12:31Z")
Hi All, I was running a bioshield calculation when I noticed that my run was stalling on a single particle. I’ve reduced the problem to a minimal working example where the issue is still present (python script attached). The MWE is a large void filled box with reflective boundary conditions at x=0 and y=0 (I had a symmetrical geometry), a 2.45 MeV monoenergetic isotropic neutron source and a single mesh tally element. The MWE stalls on particle 23228 – when printing the trace of that particle it enters the cell but then gets stuck without performing any interactions, crossing any surfaces, or dying. I can’t print the particle track while the simulation is running to see where it is disappearing to (I can only view particle tracks when the simulation is finished, which doesn’t help when it has stalled) so I have no idea where or why the stall is occurring. Does anyone have any ideas/suggestions on what’s causing this bug/how to fix it? Kind Regards Matt My OpenMC version specs are: OpenMC version 0.13.3 Git SHA1: 50e39a4e20dc9e0f3d7ccf07333f6a5e6c797c8c Copyright (c) 2011-2023 MIT, UChicago Argonne LLC, and contributors MIT/X license at [https://docs.openmc.org/en/latest/license.html](https://docs.openmc.org/en/latest/license.html) Build type: Release Compiler ID: GNU 11.3.0 MPI enabled: no Parallel HDF5 enabled: no PNG support: yes DAGMC support: yes libMesh support: no MCPL support: no NCrystal support: no Coverage testing: no Profiling flags: no [Bioshield.py](https://openmc.discourse.group/uploads/short-url/ysVmSnLJvNzZ54rWShTjKq5Z8KG.py) (1.9 KB) ---
**Author:** ![pshriwise](https://yyz2.discourse-cdn.com/free1/user_avatar/openmc.discourse.group/pshriwise/32/3863_2.png) [@pshriwise](https://openmc.discourse.group/u/pshriwise)\ **Post date:** [June 21, 2023, 7:39pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/2 "2023-06-21T19:39:55Z")
Hi Matt, I think you’ve found a problem with our regular mesh tally routine for tracklength tallies. I say this because if I either a) change the mesh dimensions slightly or b) change the tally estimator from “tracklength” (default) to “collision”, then the simulation runs successfully. This is a great minimal working example of the bug and I’ll take a look at a fix very soon, but in the meantime maybe this is enough information to proceed with your work. I’ll make sure to link the fix here once it’s been incorporated into OpenMC. -Patrick ---
**Author:** ![MIB101](https://avatars.discourse-cdn.com/v4/letter/m/a9adbd/32.png) [@MIB101](https://openmc.discourse.group/u/MIB101)\ **Post date:** [June 22, 2023, 8:40am UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/3 "2023-06-22T08:40:57Z")
Hi Patrick Thanks for having a look at this. I think it might also have something to do with an odd interaction with the reflective boundary conditions. I’ve implemented a (less than ideal) workaround of simulating my entire geometry without reflective boundaries and this seems to work reliably. It’d be great to have a patch though 🙂 Cheers, Matt ---
**Author:** ![openMC\_guy](https://avatars.discourse-cdn.com/v4/letter/o/bcef8e/32.png) [@openMC\_guy](https://openmc.discourse.group/u/openMC_guy)\ **Post date:** [May 27, 2024, 10:45am UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/4 "2024-05-27T10:45:21Z")
Hi Patrick, I’m facing the same problem described by @MIB101. However changing the estimator or the dimensions of the mesh didn’t help. The simultation still “freezes”. Is there any more insights about this bug? Thanks ---
**Author:** ![emilio.castro](https://avatars.discourse-cdn.com/v4/letter/e/b38774/32.png) [@emilio.castro](https://openmc.discourse.group/u/emilio.castro)\ **Post date:** [December 3, 2024, 3:36pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/5 "2024-12-03T15:36:12Z")
Hello I am trying to track this problem down with openmc-0.15.0 In file mesh.cpp:669 there is the follwing loop: ```auto // For all directions outside the mesh, find the distance that we need to // travel to reach the next surface. Use the largest distance, as only // this will cross all outer surfaces. int k_max {0}; for (int k = 0; k < n; ++k) { if ((ijk[k] < 1 || ijk[k] > shape_[k]) && (distances[k].distance > traveled_distance)) { traveled_distance = distances[k].distance; k_max = k; } } ``` For particle 23228, `traveled_distance` is always equal to 0, so the particle will never advance in the subsequent code, causing the problem to hang because of an upstream infinite loop. For particle 23228 the involved variables in this loop have the following values: - ijk = {-7, 1, 1} - shape\_ = {1, 1, 1} - distances = {next\_index = -6, max\_surface = true, distance = 0}, {next\_index = 2, max\_surface = true, distance = 1614.1689884883433}, {next\_index = 0, max\_surface = false, distance = 4916.5287060087403} So, in the case of particle 23228 the `traveled_distance` will be only updated when `k==1`, but the distance in this case is 0, so it won’t go into the `if` clause. I am not sure if the problem is in `ijk` or in the `distances` variables. `distance` is calculated in mesh.cpp:1050 as: ```auto d.distance = (positive_grid_boundary(ijk, i) - r0[i]) / u[i]; ``` where: - `positive_grid_boundary(ijk, i)` == 100 - `r0[i]` == 100 giving as a result a distance of 0. ---
**Author:** ![mcampos](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@mcampos](https://openmc.discourse.group/u/mcampos)\ **Post date:** [March 13, 2025, 8:49am UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/6 "2025-03-13T08:49:02Z")
Hi Patrick, I am experiencing the same problem as the one described by @MIB101, in my case using OpenMC 0.15.0. Is there any issue already opened on github for this? Thanks! Marta ---
**Author:** ![cjwiguna](https://yyz2.discourse-cdn.com/free1/user_avatar/openmc.discourse.group/cjwiguna/32/3728_2.png) [@cjwiguna](https://openmc.discourse.group/u/cjwiguna)\ **Post date:** [March 13, 2025, 2:08pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/7 "2025-03-13T14:08:53Z")
Greetings everybody. I took some liberty to modify the case a little bit. Instead of only have one void box, I enclosed the MWE box inside a comically large void box with vacuum boundary conditions on all sides (I don’t like those missing particles warning). If the `settings.seed` is changed into other numbers than 1 (e.g `settings.seed=2`) the whole calculation works without forever loop… … except i also tried `settings.seed=42`, and now in that case particle number #24402 is the one that stucks in a forever loop. So the bug might have anything to do with the pseudonumber generator, i think? [main.py](https://openmc.discourse.group/uploads/short-url/AdggXn4dbXv229Lte9dV74KyI5P.py) (2.6 KB) ps: For those who are wondering, `settings.seed=69` runs smoothly. ---
**Author:** ![emilio.castro](https://avatars.discourse-cdn.com/v4/letter/e/b38774/32.png) [@emilio.castro](https://openmc.discourse.group/u/emilio.castro)\ **Post date:** [June 17, 2025, 1:32pm UTC](https://openmc.discourse.group/t/particle-lost-without-warning-error-or-being-killed-stalling-the-run/3098/8 "2025-06-17T13:32:27Z")
Hello. This has been fixed in [Fix raytrace infinite loop. by GuySten · Pull Request #3423 · openmc-dev/openmc · GitHub](https://github.com/openmc-dev/openmc/pull/3423) I just tested it. Thank you.