Hello,
Very small issue here, but I thought I’d let you know :
When activating the background gas collisions (in 2.9.24) with relatively small mean-free paths, I can observe some non-physical leaks. My guess is that when a particle hits a wall, the distance to the next collision is calculated as 0, and the particle is immediately bounced out of the simulation by a background gas collision rather than bouncing back inside the geometry. Below an example with a simplistic box with desorption and no pump:
Many thanks for letting us know,
Could you maybe upload this box geometry here (as the box/mfp ratio is driving the simulation in the end). It would save me some time to debug.
Cheers, Marton
I looked into your geometry. In fact, setting an outgassing but not a sticking is not a physical scenario (inifinite pressure). Because of this, the leak rate (9/21) is apparently large, but it’s because the initial particles stay in the system until they leak.
If I look at the leak/hit ratio (actual ray tracing error), I get a leak rate of
9/13.52E9=0.000000066%
I ran the simulation for 10 minutes, reaching a billion hits, and there was no leak. Because of this, debugging the series of events would be extremely time-consuming (wait very long before an event could be caught). Please note that you used 12 threads, and in debugging only one is available to keep the order of events.
Please accept this 6.6E-10 error rate as that of the ray tracing engine, debugging it would take very very long time and the benefit would be minimal. (In actual geometries with a sticking, the hit/des ratio is usually in the thousands, not billions.)
Oh, I know it’s not big at all (I first saw it in another much more complex simulation where there actually was a small pump and particles made about 100 million hits before getting pumped, and even then it was only 5% leaks). It’s just something that can happen that I thought you should know, and that might be a sign that the mean free path module can give a zero distance between two deflections.
Anyway, it was not something that bothered me too much in the first place, so you do you. Thanks for taking some time for it anyway.
For your info, I’ve spent a few hours debugging the problem.
The leak happens when two conditions are true at the same time:
a) The particle is at the edge of the geometry (just collided with the wall)
b) The flight path until the next scattering is 0.
The two conditions together happen very rarely (1 in 1.5 billion on average), but luckily b) happens more often, so I could set breakpoints to see what the root cause is.
When a particle is generated OR a scattering event happens, an “expected scatter distance” is generated based on the mean free path. For example let it be 5cm.
If it’s a new particle (just outgassed), the expected scattering “travelled path” is 5cm. If it’s a particle that already did events (bounces, scatters), it’s “already travelled path” (from desorption) is incremented. So if it already travelled 100cm, the next expected scattering will take place at 105cm.
After every wall hit, there’s a check if we missed a volume event (radioactive decay or scattering). With the numbers above, if the next wall hit is in 20cm, then 120cm > 105cm, so we move the particle to the 105cm location and perform the scattering.
Now the bug is due to the following:
Adding 100cm and 5cm is precise, we get 105cm on every compiler
However, the exponential distribution can generate very small numbers (with tiny probability), for example an expected scatter path of 10^-15cm
And in your geometry, the flight paths are huge, going towards infinite, since there is no sticking
Adding a huge number and a small number will result in no addition. Concretely:
The distanceTraveled is 43.6km and the path until the scattering is 0.5pm (atomic scale). Adding these two numbers returns 43.6km, so the particle immediately turns back.
The solution could be a redesign so that only the additional path (0.5pm) is compared to the ray tracing, but this would slow down the simulation as a new expected scatter length would be generated at each bounce.
Summary:
The root cause is that adding a very large and a very small number results in the original value due to limited numerical rpecision
This is because the particles don’t stick and cumulate very long flight paths. MolFlow wasn’t designed for this, a sticking is always assumed
As the flight path accumulates, these leaks will become more frequent because we’re adding the same small numbers to larger and larger flight paths - so this bug will happen more often as the simulation progresses
This bug doesn’t happen in a “normal” geometry, as the flight path is in fact not 0, just very small, but still comparable to the particle flight paths (few meters maximum)
