|
[Sponsors] |
[snappyHexMesh] Decomposed sHM runs slower than on single thread |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
February 19, 2020, 11:31 |
Decomposed sHM runs slower than on single thread
|
#1 |
New Member
Tom
Join Date: Nov 2019
Posts: 2
Rep Power: 0 |
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. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
pimpleFoam runs slower than rhoPimpleFoam | Kosuke Seto | OpenFOAM Running, Solving & CFD | 3 | May 27, 2023 14:12 |
Parallel UDF Segmentation fault error | KevinZ09 | Fluent UDF and Scheme Programming | 1 | January 9, 2017 05:30 |
my case in CFX runs in single mode but in parallel it does not | gaza | CFX | 1 | September 16, 2014 18:52 |
problem with mpirun (runs fine in single thread mode) | Jonathan | OpenFOAM Running, Solving & CFD | 1 | April 1, 2013 11:56 |
Parallel runs slower with MTU=9000 than MTU=1500 | Javier Larrondo | FLUENT | 0 | October 28, 2007 22:30 |