Rectangular facets stop counting arbitrarily

After some time running a simulation that features a combination of triangular and rectangular facets, some of the rectangular facets stop counting hits or transparent passes. This is particularly troublesome for textured facets, because although the simulation continues to run, the pressure heat map stops updating minutes into a simulation.

What could be causing this? Is it a memory issue? It seems like Molflow+ is using very little memory.
I am on version 2.8.3 and running it from a folder on my desktop. The model consists of 15000+ facets.

Thank you!

Hey Jake,
without more information this can be difficult to analyse.
To me it sounds like your molecules might be stuck, where they don’t reach the facets anymore. Do you have further desorptions? Are there still visible hits (activate [Lines] or [Hits] in the viewer settings)?

Could you also verify, whether the same issue happens with the latest 2.7.x build or not?
If you could share a minimal geometry to recreate the issue, this would help a lot.

Best,
Pascal

Hello Jake:

and thanks for contributing to this forum.
I concur with the preliminary analysis of Pascal… it probably depends on molecules getting stuck between two facets which are very close, sometimes even defined by the same vertices, but oriented against each other. Some STL files extracted by CAD models just do that, I went crazy some time ago with one provided by a colleague… I ended up making the same geometry myself using the editing features of Molflow+.
Anyway, as Pascal said, it would be nice if you could share with us the file, because in that case we could troubleshoot you very quickly. In case you don’t want to share it publicly here you can e-mail us, my e-mail is roberto.kersevan@cern.ch. We’ll keep it confidential, of course, unless you tell us that we can share with other Molflow+ users the solution to your problem.
Cordially,

R.

Pascal,

Thank you for such a quick response.

Certain facets continue to count hits. I can see this live in the facet information table below the simulation parameter pane. I have experienced this with 2.7.11 as well, but not as often or severe, with severity meaning that I would achieve enough simulation time for desirable results before the facets stopped updating.

I usually run simulations with lines and textures visible because I simply like to see the textures update and how a sample of particles propagate. Another issue worth noting that I have had with 2.7.11 and 2.8.3 is that after some time (unrelated to the texture/hit issue) lines stop rendering on each update. With 2.7.11 I was able to start and stop the simulation and toggle line view to temporarily render lines again.

I will try and recreate the issue soon.

I should note that I am running a quadcore intel processor with 8 total virtual cores. For past simulations I have run on 2.7.11 and 2.8.3 I have had 8 processes (default) set to run in the simulation settings.

I noticed after switching to 2.8.3 that my CPU usage was considerably down while running a simulation. IE, 2.7.11 would use 100% CPU and 2.8.3 would use 40% CPU.

Thinking this might signify a CPU and memory utilization issue, I turned off rendering of all lines and textures and left auto updating for the scene on. I then tried a few different numbers of processes in the simulation settings, 1, 4, 8, 16, and 32. What I found is that the simulation would run much longer before experiencing any issues updating facets when I had 32 processes running. I also found that CPU usage was back up to 100%. And finally, the simulation ran faster, meaning more Mhits in a short elapsed time.

Jake

rkerseva,

See my reply to Pascal.

Jake

Dear Jake,

  • Lines stopping rendering after a while: it’s a clear indication that molecules are getting stuck
  • 32 processes run longer than 4 before stop: less computing power per process, meaning it takes longer for all 32 processes to reach a stuck state
  • Less CPU usage 2.8 vs 2.7: this is just apparent, as Windows Task Manager only displays the GUI cpu usage, and in 2.8 calculation was delegated to subprocesses. If you open the Resource Monitor (available as a link at the bottom of the CPU tab on task manager), you will see the molflowSub.exe processes and their usage, the sum will be 100% (or 100% times the number of cores, depending on Windows versions)

To find the root of the problem, when lines disappear, sort facets by number of hits (clikcing on the header of the Hits column), and you will see that only a handful (around 10 or less) facets increase their hit count. Zoom in and you will see very tiny green molecule trajectories corresponding to stuck molecules bouncing forever. That’s where the geometry has to be corrected.

Cheers, Marton

1 Like

[Marking it as solved after 1 month of inactivity.]

You were right, particles were getting stuck. I apologize for taking so long to get back to you. This was very helpful. Thank you!