[datTommyGuy]

Hello,
I'm meshing a more-or-less cylindrical geometry (screenshot attached below, flow through a duct) with sHM. I used a simple (2 2 2) decomposition in decomposeParDict ((2 2 1) for 4 threads). I'm running the case in this order:


blockMesh
surfaceFeatures

decomposePar
mpirun -np 8 snappyHexMesh -overwrite -parallel


However, the more cores I use, the slower snappyHexMesh runs. Just adding new boundary patches takes too long to let it finish the job.



I'm using Ubuntu 16.04 LTS on Windows 10. The processor is a 4-core (8 threads) i7-7700HQ. When using 8 threads, the CPU usage jumps to 100%, while with 4 it stays at about 60%, so the decomposition itself seems to be working.


What may be the cause of such behaviour? I'll gladly provide more details as needed.

[HPE]

how many cells per processor?

[mzzmrt]

This is perfectly normal because your processor has 4 real cores so your max parallelization limit is 4!

[datTommyGuy]

Originally Posted by HPE

how many cells per processor?

~3000 after blockMesh, limit in sHM set to 0.8*10^6.

Originally Posted by mzzmrt

This is perfectly normal because your processor has 4 real cores so your max parallelization limit is 4!

I weren't sure about that, so I tried going over 4 - there are 8 separate CPUs listed in the resource monitor and the total CPU usage approaches 100% only when the case is decomposed for 8 processors.
However, any decomposition seems to be much slower than using just a single core. I've tried using every number of processors between 2 and 8, yet the performance always dropped.