New-Geometry-Case-1.mfx (14.6 KB)
NEW-GEOMETRY-CASE-1.msh (22.4 MB)
Hello,
I am trying to do DEM simulation of 1 mm diameter particles.
Seems like it is taking very long time.
I am attaching the screenshots as well as the files.
I am running MFiX-DEM on a Windows machine with 88 processors.
How can I make sure that MFiX takes all the 88 processors and run.
It is showing the time remaining as 2.5 days.
Kindly have a look at the files and settings and let me know if everything has been done correctly.
I look forward to hearing from you.
Thanks and Regards,
Debashis
Kindly provide me some suggestion how to speed up the simulations.
It is going very slow. Also, the particles are very slow to move down.
I look forward to hearing from you.
Thanks and Regards,
Debashis
SMP performance is never as good as DMP, and the multithreading support on Windows is not great. If it’s possible to install Linux on this machine and run the case with DMP you may get better results.
Hello Dr. Waldman
Thanks a lot.
I will explore whether I can install WSL in this Machine.
Also let me put 88 under Threads since we have 88 processors.
I will keep you posted.
Is the MFiX GUI available on Linux ?
What is needed to make the MFiX GUI work on Linux ?
Please let me know.
Thanks and Regards,
Debashis
Linux is the preferred environment for running MFIX. Everything is supported on Linux including the GUI, and you can run DMP simulations as well, which tend to offer better speedup than SMP. Installing MFIX on Linux is exactly the same as installing on Windows (Conda package).
I’m not sure if WSL will give as good results as native Linux but you can try it!
Dr. Waldman,
Thank you.
As you can see from the attached figure, it is using 88 processors but the load balancing is not good.
I will see if it works in Ubuntu 22.04.
I will keep you posted.
Thanks and Regards,
Debashis
Sadly, throwing more CPUs at a problem doesn’t always help.
You did not include the particle_input.csv file. If you need further assistance, please attach all project files. Go to the main menu, select submit bug report. This will generate a zip file, attach it to the post. The figure you show looks like you are using particles larger than 1mm since the domain width is 1mm.
BOTTOM_INVENTORY.csv (50.9 KB)
MASS_FLOW_RATE_MID_PLANE.csv (51.0 KB)
particle_input.csv (1.8 MB)
TOP_INVENTORY.csv (50.9 KB)
Dr. Dietikar,
I am attaching the files.
It is running with 1 mm particles. Particles number is 35361.
Kindly let me know if it looks ok.
It is taking a lot of time for the particles to descend down.
Thanks and Regards,
Debashis
You still did not attach the zip file I was asking for. You can try to lower the spring stiffness say to 1000 N/m to see if it helps (it will run faster but may generate large particle overlap).
new-geometry-case-1_2025-05-07T114021.569935.zip (804 Bytes)
new-geometry-case-1_2025-05-14T145230.705231.zip (804 Bytes)
Dr. Dietiker,
Attached are the Zip files.
I am also attaching the simulation status.
The time step is very low. 0.6e-06 seconds.
Anyway to increase that ?
Kindly let me know.
Thanks and Regards,
Debashis
I only see the mfixversioninfo.txt in the zip files. We need all input files (mfx, particle_input.csv, stl files) to give you better support. You can try to decrease the spring stiffness to kn=1000 N/m, set the des search grid to 40x60x40 to see if it helps.
You could expect more even cpu load distribution if your geometry also was very uniform. Yours is not. I believe the load is distributed solely done by chopping the mesh up evenly, and if nothing happens in one of these chunks, then cpu will not be used either.
Did you try to enable the array reindexing?
Hello,
Thank you.
No I have not tried array indexing.
I will try that one and let you know.
Best Regards,
Debashis