Skip to content
  • 最新
  • 版块
  • 东岳流体
  • 随机看[请狂点我]
皮肤
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
CFD中文网

CFD中文网

  1. CFD中文网
  2. OpenFOAM
  3. OpenFOAM并行测试

OpenFOAM并行测试

已定时 已固定 已锁定 已移动 OpenFOAM
31 帖子 6 发布者 33.7k 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    写于 最后由 编辑
    #21

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

    1 条回复 最后回复
  • 李东岳李 离线
    李东岳李 离线
    李东岳 管理员
    在 中回复了 hurricane007 最后由 编辑
    #22

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

    http://dyfluid.com/index.html
    需要帮助debug算例的看这个 https://cfd-china.com/topic/8018

    hurricane007H 2 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 李东岳 最后由 编辑
    #23

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

    1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 李东岳 最后由 编辑
    #24

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

    1 条回复 最后回复
  • 李东岳李 离线
    李东岳李 离线
    李东岳 管理员
    写于 最后由 编辑
    #25

    但是我5120才100多秒

    http://dyfluid.com/index.html
    需要帮助debug算例的看这个 https://cfd-china.com/topic/8018

    hurricane007H 1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 李东岳 最后由 编辑
    #26

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

    1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    写于 最后由 编辑
    #27

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

    1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 hurricane007 最后由 编辑
    #28

    @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,难道新版本有加成?

    1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 李东岳 最后由 编辑
    #29

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

    李东岳李 1 条回复 最后回复
  • 李东岳李 离线
    李东岳李 离线
    李东岳 管理员
    在 中回复了 hurricane007 最后由 编辑
    #30

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

    http://dyfluid.com/index.html
    需要帮助debug算例的看这个 https://cfd-china.com/topic/8018

    hurricane007H 1 条回复 最后回复
  • hurricane007H 离线
    hurricane007H 离线
    hurricane007
    在 中回复了 李东岳 最后由 编辑
    #31

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

    1 条回复 最后回复

  • 登录

  • 登录或注册以进行搜索。
  • 第一个帖子
    最后一个帖子
0
  • 最新
  • 版块
  • 东岳流体
  • 随机看[请狂点我]