OpenFOAM并行测试

hurricane007

@东岳 1812

hurricane007

@东岳另外一个cluster上更搞笑，处理器是志强 5118@2.3G, OF4.1，也是本地运行，均为6核，不过太慢估计是有别的原因
snappyHexMesh 96.72s
simpleFoam ExecutionTime 250.07s， ClcokTime 661s。感觉前者比较可信，因为这是个登录和编译用的节点，估计用的人比较多，后台线程比较多了。
也是有个warning

--------------------------------------------------------------------------
WARNING: No preset parameters were found for the device that Open MPI
detected:

  Local host:            lm3-m001
  Device name:           i40iw1
  Device vendor ID:      0x8086
  Device vendor part ID: 14290

Default device parameters will be used, which may result in lower
performance.  You can edit any of the files specified by the
btl_openib_device_param_files MCA parameter to set values for your
device.

NOTE: You can turn off this warning by setting the MCA parameter
      btl_openib_warn_no_device_params_found to 0.

红豆沙

表格里面是不是打错了，是213s，，2分多

李东岳

@红豆沙在 OpenFOAM并行测试中说：

里面是不是打错了，是213s，，2分多

可以测试下6核么？方便横向对比，其他几个CPU没有12核

CFD计算用的是核数就行

红豆沙

@东岳 6核下，snappyhexmesh时间：59.8s，simplefoam时间164s，，12核simplefoam时间是153s，，上面那个说错了

李东岳

@红豆沙很有意思，画网格有优势，算simplefoam没优势，AMD那个撕裂者也是，

李东岳

@hurricane007 在 OpenFOAM并行测试中说：

外一个cluster上更搞笑，处理器是志强

志强6142可以补充几个数据么？目前只有6核的simpleFoam，149秒

红豆沙

@东岳所以是不是 AMD架构采用了 ZEN2后，多核通信效率提高了，且浮点啊，整数啊运算能力提高了，，但是至强系列你耐不住INTEL爸爸的指令集，尤其对于至强系列的，更牛批啊，，对于运算更加得心应手咯

李东岳

@红豆沙不确定。我需要更多的数据然后在CFD界推一下让大家关注下。很久很久之前我以为是版本的问题，竟然不是

红豆沙

@东岳哦哦，，是不是好像那个 Intel有MKL数学运算库，，对于方程求解啥的很有用，，，这个影响在openfoam里会不会也是个原因

hurricane007

@东岳我找个时间研究下怎么提交Allrun的script。。。

hurricane007

今天终于想起把鸽了这么久的事情干了一下了，今天测试的是5118 2.3G. OpenFOAM 4.1
因为是服务器，所以先运行了surfaceFeatureExtract，blockMesh, decomposePar 以后，再用slurm 分别提交snappyHexMesh 和simpleFoam，运行完snappyHexMesh 以后把Allrun里面的这两行也运行一下再提交patchSummary, potentialFoam 和simpleFoam。不过是log文件里面是分别计时的，所以应该没影响。

ls -d processor* | xargs -I {} rm -rf ./{}/0
ls -d processor* | xargs -I {} cp -r 0.orig ./{}/0

snappyHexMesh
6C: 99.52 s
12C: 71.93 s
24C: 59.36s
simpleFoam
6C: 237 s
12C: 158 s
24C simpleFoam 时间是86s, 基本符合预期

hurricane007

再做了一个笔记本的测试，CPU i7-9750H + 16G，性能模式， win10 下 WSL Ubuntu 18.04，OpenFOAM 7，6核，
第一遍 snappyHexMesh 74.98s， simpleFoam 251s
第二遍 snappyHexMesh 69.01s， simpleFoam 256s

李东岳

@hurricane007 志强金牌5118六核计算237s？

hurricane007

@东岳对的，感觉时间好长。。。

hurricane007

@东岳估计是吃亏在主频比较低

李东岳

但是我5120才100多秒

hurricane007

@东岳对，我看了下你测试的，感觉这个差这么多不正常啊。我改天再试一下看。
BTW，我一样的办法换到6142上面，simpleFoam 跑了163s，比利时CECI这对电脑怎么回事

hurricane007

然后我又测试了另外一个cluster，CPU 是 6142 2.6G。因为这个机器不是给MPI并行用的，所以nodes 之间的通信不是很好。但是一个node 有两块16C的CPU，应该也不影响，最多也测到了24核，结果如下。12C的snappyHexMesh结果很奇怪，simpleFoam结果还算正常，但是提交到任务序列算都比之前直接在登陆节点算要慢，不知道为什么。
snappyHexMesh:
6C: 80.8s
12C:165.37s (这个数据有问题，不知道怎么回事）
24C:36.24s
simpleFoam
6C: 163s
12C:112s
24C:60s

hurricane007

@hurricane007 在 OpenFOAM并行测试中说：

今天终于想起把鸽了这么久的事情干了一下了，今天测试的是5118 2.3G. OpenFOAM 4.1
因为是服务器，所以先运行了surfaceFeatureExtract，blockMesh, decomposePar 以后，再用slurm 分别提交snappyHexMesh 和simpleFoam，运行完snappyHexMesh 以后把Allrun里面的这两行也运行一下再提交patchSummary, potentialFoam 和simpleFoam。不过是log文件里面是分别计时的，所以应该没影响。
ls -d processor* | xargs -I {} rm -rf ./{}/0
ls -d processor* | xargs -I {} cp -r 0.orig ./{}/0
snappyHexMesh
6C: 99.52 s
12C: 71.93 s
24C: 59.36s
simpleFoam
6C: 237 s
12C: 158 s
24C simpleFoam 时间是86s, 基本符合预期

换了个1812的OF来测了下，5118的U, snappyHexMesh 测出 83s，simpleFoam 测出190s，难道新版本有加成？

CFD中文网

OpenFOAM并行测试