Stalling in MMCLAB based on source position

[Ife E]

Dear Prof. Fang,

We've been running into an interesting issue with MMCLAB v2025.10

We have been running simulations to generate ground truth data for DOT. Our maximum SDS is quite high (approx. 5 cm) so we have been simulating a large number of photons  (1e10). For these larger photon counts we have found MMCLAB is more likely to stall. 

Based on GPU usage (and the sound of my cooling fans!) it seems like the simulations finish or pause but don't pass back control to MATLAB so we need to restart the IDE. 

Initially we found shifting the offending source locations very slightly before resuming the simulation prevented this issue. As we repeat simulations for different optical properties different sources would begin to stall and we haven't found a correlation between them. Now we randomly set the shift direction of all the sources before simulating and have more success but every so often run into this issue.

All our generated meshes are verified with meshcheckrepair and we pass the cfg output from mmclab(cfg,'prep') to the simulation as well just in case. We also have cases to check that the source position does not overlap with any element vertices. Weirdly for our initial simulations at lower photon counts it seemed like this happened less frequently.

Not a critical issue for us at the moment but we thought it was interesting behaviour to highlight, and couldn't find any related problems on the forums.

All the best,

Ife

[Qianqian Fang]

hi Ife,

thanks for reporting this. yes, I have noticed the stalling situations since the early days of MMC. it has some built-in heuristics to prevent stalling, but no matter how small the chance this may happen, MC seems to always have a way (not surprisingly) to bump into it, as long as the photon number is big enough.

ray stalling is a classic graphics ray-tracing problem, known as "self-intersection", see

https://www.kns.org/files/pre_paper/49/23S-249-%EA%B6%8C%EC%84%B1%EC%A4%80.pdf
https://developer.nvidia.com/blog/solving-self-intersection-artifacts-in-directx-raytracing/

the root cause of the issue is the limited precision (floating-point) when performing ray-triangle intersection testing - after advancing a ray to the intersecting surface, you hope that its next intersection will be in a different triangle, but limited precision may result in the ray hitting the same triangle again and again, and get trapped.

almost all mesh-based MC codes have some sort of built-in heuristic to "nudge" the ray/photon beyond the intersecting surface, so that it can move on to the next intersection. most of these heuristic involves adding a small increment (epsilon) sufficiently big to overcome the precision limit. However, such epsilon is not robust and guarantee self-intersection won't happen.

in comparison, mcx also has to handle such self-intersection at all voxel boundaries. it manages to achieve a robust solution by first rounding to the integer (exactly on the voxel boundary), and then take an nextafter operator to ensure that the resulting coordinate passes the boundary in the velocity's direction. however, "nextafter" won't work for mesh data because coordinates are not along integers.

I have been experimenting some new heuristics to more robustly detect such trapped photons and minimize such self-intersection. hopefully in our next release, this could improve.

Qianqian

On 4/22/26 07:21, Ife E wrote:

You don't often get email from ifechiej...@gmail.com. Learn why this is important

--
You received this message because you are subscribed to the Google Groups "mcx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mcx-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mcx-users/9b5f2512-2dc1-44a2-b52d-4fe3e1452276n%40googlegroups.com.

[Ife E]

Hi Qianqian,

This is good to know and interesting behaviour we were completely unaware of, thanks for taking the time to reply! 

Best,

Ife