Hello Everyone,
I am running mfix simulations on my windows based system.
I have selected 25 cores but still the PC is not using all cores. (Picture attached)
Please guide me why this is so? is it a problem of PC or mfix settings?
Thanks!
Farid
How do you know that the PC is not using 25 threads?
Hi,
Thank you very much for your response.
When i check the performance bar, this shows on 5% of the CPU utlization while I am simulating a multiphase problem with 3 phases. I assume it must be between 50% to 90% at least!
Please check the attached picture and guide me how to increasr the cores.
Thank you so muhc once again.
Note that not all parts of the MFiX solver are written to take advantage of SMP parallelism. You may get better results with DMP (which, unfortunately, is not supported on Windows - we suggest Linux for high-performance work).
If you attach your project files (Main menu → Submit bug report) I’ll try to take a look and see why you are not getting more than 5% utilization.
Hi,
Many thanks for your reply.
Here is the zip file. please guide further, how I can still solve this problem with windows as switching to Linux would be difficult at this stage of work.
Thank you very much.
base_case_simulation_1to1_2024-12-10T092118.611164.zip (92.5 MB)
I have some answers for you, but they may not the answers you hoped for.
Running on an 8-core Linux machine with 8 SMP threads, I observed 160% CPU usage, which means less than 2 cores were kept busy at a time (if all 8 cores were active the job would report 800%, this is the way top works on Linux)
So throwing more than 2 cores at the simulation won’t really help. Not all parts of MFiX are capable of taking advantage of SMP - looking at the source code, only blocks marked
!$omp parallel do default(none)
are taking advantage of SMP mutithreading. (And sections with more than 1 !, like !!$omp are disabled.)
After running for 5 minutes, the MFiX dashboard says your job will require another 93 days to complete.
For comparison, in a serial run (no SMP or DMP) this number is 109 days, so the SMP speedup is not very significant.
perf top shows what functions the system is spending the most time in. There are no really obvious targets for optimization here.
Now let’s try a DMP run, with 2x4x1 domain decomposition:
This looks better, we are keeping all 8 cores mostly busy (close to 100%). These numbers would probably be higher if I didn’t have other processes running, like the web browser.
Now the remaining time is 67 days, better than 93 but still probably longer than you want to wait…
perf top shows similar information for the DMP run:
To get this job to run faster, you’re going to have to do something other than rely on parallelization.
Note that dt is staying very low, so simulation time proceeds slowly:
The P0 (Air pressure) residual is the dominant one:
You can try various things, like relaxing the tolerances for convergence, or using different linear solvers/preconditioners (see Numerics pane). Or try using a coarser mesh.
I tried changing from 80x200x1 mesh to 40x100x1 but got this error:
Error 1101: Invalid location specified for PS 3.
X: -0.25000E-02, 0.30000E-02 I: 21, 22
Y: -0.18250 ,-0.18050 J: 3, 2
Z: -0.20000E-02, 0.20000E-02 K: 2, 2
It looks like with the coarser grid spacing, the point source is spread just across the center of the cell (in y-direction). That seems to cause a problem with the conversion from coordinate to index.
If you increase the PS top coordinate to ymin+0.004, it seems to run.