RAM usage gets extremely large after long time running

MFiX Bug report
#1

Hi
I am running a PIC case with reaction. The number of inert particles is just about 6300 and number of biomass particles entering is just about tens per sec. This should not be a very costly simulation but it turns out to take up extremely large portion of RAM after running about 24 hours.

At the beginning, everything is normal and the text terminal flashes with residual infomation as usual. However, with the simulation going on, the RAM usage will go up and up, and now it takes up 30G.
image

image

The simulation was running on a VMware virtual machine with Ubantu20. 16 processors were used for DMP.

A obvious phenomenon is the system is now very slow. The time elapsed counting on dashboard refreshes off and on.

Another phenomenon is the text terminal is in nearly stagnation: No residual and other info comes out any more. See following picture.
image

I guess it may be a bug of GUI.

Here is my case

dempic_2020-05-28T230816.346945.zip (9.1 MB)

#2

Something doesn’t seem right, near the end, the fluid solver is taking 151s! Probably because you are swaping 2 GB! What compiler are you using?

Timestep walltime, fluid solver: 151.479 s
PIC NITs: 1 Total PIP: 6421
Timestep walltime, PIC solver: 0.036 s

#3

Hi Chunlei. Are you still seeing this 30GB RAM usage? If so can you share the project file that causes this? Thanks!

#4

It is still problematic.
Here is my deck files
dempic_2020-06-29T221408.758559.zip (23.3 MB)

#5

Thank you for replying
I need to simulate reactions so I compiled the solver as the user guide told.

#6

Thanks for your help.
Now I guess it is not the fault of GUI because the batch solver also occurs the same issue.

However, I started to wondering if it is related to the DMP (16 threads are used)

#7

Closing the GUI window or even closing the terminal wouldn’t solve the problem, there is still high RAM usage(although half of RAM will be freed if closing the window). The only thing I can do is to reboot the computer and restart the simulation.

Another weird phenomenon is even after I closed the GUI and start in a new terminal, the simulation is still stuck and only showing the elapsed time. So I have to reboot every time this issue occurs

#8

Another weird phenomenon is even after I closed the GUI and start in a new terminal, the simulation is still stuck and only showing the elapsed time.

This does not seem that weird - the GUI allows you to close it while a simulation is running, and will attempt to reconnect to a running job when it starts up again. You have shown that the memory issue is on the solver side, not within the GUI.

However, I started to wondering if it is related to the DMP (16 threads are used)

This is highly likely. Whenever you have problems running a job in DMP mode, it’s good to try running it serially to see if the problem goes away.

#9

Instead of rebooting you should be able to find and kill the “stuck” solver job - using “ps” on Linux, or Task Manager on Windows.