OpenFOAM并行测试



  • 不同处理器的性能测试

    测试方法:

    1. 打开simpleFoam的motorBike算例,修改decomposeParDict文件中的method simplemethod scotch跑6核

    2. ./Allrun直接运行,运行后看运行时间

    测试过程中执行时间和钟表时间基本没区别,因此只显示clockTime。计算机网格数量不是特别多,默认内存、固态硬盘不存在瓶颈。我用的是OpenFOAM6,simpleFoam已经很稳健了版本更新不会有太大变化

    simpleFoam的运行时间对比:

    计算时间
    AMD EPYC 7452 88
    志强金牌5120 124
    志强E5 2678 v3 130
    志强金牌6142 149
    AMD2990w 161
    AMD3900X 164
    i7-9750H 229
    i7-5820K 295
    i7-6700 300

    snappyHexMesh的运行时间对比:

    6核 计算时间
    AMD3900X 59.8
    志强6142 68
    志强金牌5120 72
    i7-9750H 72.5
    i7-5820K 160

    买CPU关注使用核心数还是线程数?

    处理器:志强5120金牌14核心*2

    内存:96G

    求解器:OpenFOAM-5.x

    网格数量:210万六面体

    模型:单相流N-S方程管道quasi-DNS模拟

    0_1540885054546_捕获.JPG

    悲剧,上面这个图没有贴40线程和56线程计算的图,总之就是更慢..

    对本帖总结一下:

    1. 买CPU的时候计算只看核心数就好!!! 不用关心线程数。比如6核12线程,那你计算时候只能用6核!24核48线程,那就是24核!

    2. AMD那面测试几个处理器跑求解器要比intel的慢,画网格要快,目前原因不详,有人知道请分享

    3. 谁有新的处理器能够测试的,欢迎提供数据


  • 自由表面模型副教授 OpenFOAM教授

    @东岳 56是把所有的逻辑核都用了吗?我听我师兄说CFD并行线程数不要超过物理核数,性能会下降。



  • 楼上的说法我可以提供一点佐证。处理器是至强E5-2679v4,40核心80线程,32G内存。网格数记不清了,大概160到180万多面体-六面体混合网格。VOF,k-omega SST, Sliding Mesh。纵轴是时间,单位是秒,横轴是线程数,图是随手画的,领会精神就好:
    0_1540565217472_4fb1f746-9056-41a4-9a02-6793697a188e-image.png



  • 楼上说的很对,验证了。CFD这面并行数量不能超过物理核心数。否则速度大大降低。

    同时,经过测试,超线程关闭与否对计算结果基本没影响。我这几个测试开启超线程与否计算时间区别在20s之内



  • 并行数量不能超过物理核心数,是不是要预留一定的核心给系统进程?



  • @战气凌霄 这方面还没测试,寒假有空试试,不过个人感觉相差基本不大。如果有类似的经验感谢分享



  • @东岳 学校的cluster,志强 6142。用的slurm,但是我不会直接提交Allrun,所以就只测试了6核(在本地运行太多怕被网管揍)
    snappyHexMesh, 67.79s
    simpleFoam, 149s
    不过说明上说这个机器不适合MPI运行,最开始的时候出了个warning

    
    [[51384,1],0]: A high-performance Open MPI point-to-point messaging module
    was unable to find any relevant network interfaces:
    
    Module: OpenFabrics (openib)
      Host: dragon2-ctrl0
    
    Another transport will be used instead, although this may result in
    lower performance.
    
    NOTE: You can disable this warning by setting the MCA parameter
    btl_base_warn_component_unused to 0.
    
    


  • @hurricane007 你的openfoam什么版本?6?



  • @东岳 1812



  • @东岳 另外一个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,,上面那个说错了 :xinlei:



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



  • @hurricane007OpenFOAM并行测试 中说:

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

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



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



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



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



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



  • 今天终于想起把鸽了这么久的事情干了一下了,今天测试的是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, 基本符合预期



  • 再做了一个笔记本的测试,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?



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



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



  • 但是我5120才100多秒



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



  • 然后我又测试了另外一个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

    c125196c-b89d-4f3d-a7c1-7fe675283b3e-image.png



  • @hurricane007OpenFOAM并行测试 中说:

    今天终于想起把鸽了这么久的事情干了一下了,今天测试的是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,难道新版本有加成?



  • @东岳 我在想会不会是如果开了睿频的U会快一些,但是有的cluster 为了稳定性把超线程和睿频都关了,所以就会更慢一些。不知道你测的5120是开了睿频还是关了的



  • 我这个没有开,你那个5118是服务器?是不是计算时候跑大于CPU数量了,我这个5120就我自己用



  • @东岳 对,我那个5118是学校的计算集群,我记得我在哪儿看到过说这堆集群都是把超线程关了的,所以不可能使用的线程数量超过物理核心数量;然后睿频的话,应该是说如果你不关他,他默认是开的,但学校集群可能是关了的,你的如果是自己用应该是开着的,就是说如果睿频开着的,CPU温度和功率不超过他的限值的时候他可以运行在更高的频率上。比如你的5120 是14cores 28 threads 2.2G, 但是如果散热比较好功耗不超过某个限制的时候,他是可以整体跑在更高的频率上,这就能更快。
    话说我觉得最惊奇的是我的9750H跑6线程居然比服务器CPU慢这么多,理论上说不过去啊,因为我看到跑的时候主频都跑到4G了,服务器才2.3G。得研究一下构架了


Log in to reply