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 ./{}/0snappyHexMesh
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？
-
@东岳 对的，感觉时间好长。。。
-
@东岳 估计是吃亏在主频比较低
-
@东岳 对，我看了下你测试的，感觉这个差这么多不正常啊。我改天再试一下看。
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
-
@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 ./{}/0snappyHexMesh
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是开了睿频还是关了的
