CFD中文网

    CFD中文网
    • 登录
    • 搜索
    • 最新

    有关Openfoam在超算并行运算的问题

    OpenFOAM
    5
    18
    3927
    正在加载更多帖子
    • 从旧到新
    • 从新到旧
    • 最多赞同
    回复
    • 在新帖中回复
    登录后回复
    此主题已被删除。只有拥有主题管理权限的用户可以查看。
    • I
      Irisch 最后由 编辑

      各位好。我现在有个关于并行运算的问题想求教一下。
      我现在在用interFoam求解器做一个换热器内部除垢过程的模拟。模拟的模型为一个长80 mm，高5 mm的方形管道，其中间有一块以凡士林作为模拟材料的污垢，高为0.5 mm。除垢物质为水，水流速度为1米每秒和3米每秒。先做的是2D模拟。
      现在我和导师画了一个大概600*400的网格给整个管道，然后用decomposePar对网格进行分割以提高运算效率，最后我们把整个算例提交到学校Taurus超算上去做计算。但是提交上去以后发现运算速度并没有特别的提高。最后需要出一个时间长度为近600秒的算例，但是超算上算0.03秒的时间花了5个小时，用了96个核。试了很多种分割网格的办法，横向x轴24等分的做了，现在做的是x轴6份，y轴4份，速度都没有显著的提高。
      不知道有没有谁有过类似的算例经验，能够指出我这中间哪里做的不对需要修改一下？或者有想法或者建议的！做了快3个月了，还是没有办法，有点着急。
      非常感谢各位的帮助！

      队长别开枪 1 条回复 最后回复 回复 引用
      • 队长别开枪
        队长别开枪 教授 @Irisch 最后由 编辑

        @Irisch 你maxCo和maxAlphaCo设置的多少？网格是不是均匀分布的？最小尺寸是多少？代数方程组选择的哪种求解器？收敛残值设置的多少？影响求解时间的因素太多了，还有，按你说的你分了24个区，为啥用96核？建议你把整个算例和log日志贴出来:shangxue:

        I 2 条回复 最后回复 回复 引用
        • W
          wwzhao 教授 最后由 编辑

          算例的网格数才24万，规模太小了，用多个核心没有加速效果。96核心适合千万网格规模的算例。

          I 1 条回复 最后回复 回复 引用
          • aiweimo
            aiweimo 最后由 编辑

            其实上面的回答已经够好了。我只是想试试我的新头像。我一般并行分网格，一个核大约四五十万网格。你总共24万网格，用96核确实太浪费了。并行中，各分区之间会有数据的交换，每一步会交换一次，如果过度分区，大量时间会浪费在CPU之间（内存）、或者节点之间（网卡）的通讯上，因此计算会变慢。

            I 1 条回复 最后回复 回复 引用
            • I
              Irisch @队长别开枪 最后由 李东岳 编辑

              @队长别开枪 您好！非常感谢您的回复！
              1、我maxCo和maxAlphaCo分别设置的都是1，导师那边要求的以1为界值。其他的边界条件是以$tutorials/multiphase/interFoam/RAS/waterChannel这个算例作为基础设定的。
              2、网格是非均匀网格，blockesh中的网格分割如下。

              hex ()    (150 40 1) simpleGrading (1 1 1)
hex ()   (150 60 1) simpleGrading (1 6 1)
hex () (300 40 1) simpleGrading (1 1 1)
hex () (300 60 1) simpleGrading (1 6 1)
hex() (150 40 1) simpleGrading (1 1 1)
hex () (150 60 1) simpleGrading (1 6 1)

              3、代数方程求解器用的Smooth，湍流模型为kOmegaSSTLowRe,对应的残差值为：

              alpha.water         1e-8
p_rgh                   5e-9
U|k|omega           1e-6

              4、下面是log文件的一段，中间那个时间步长连续性也一直没解决。

              PIMPLE: iteration 1
smoothSolver:  Solving for alpha.water, Initial residual = 0.000122159, Final residual = 6.40432e-11, No Iterations 2
Phase-1 volume fraction = 0.949927  Min(alpha.water) = 0  Max(alpha.water) = 1.00072
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.949927  Min(alpha.water) = -6.32704e-23  Max(alpha.water) = 1.00072
GAMG:  Solving for p_rgh, Initial residual = 0.966053, Final residual = 0.004155, No Iterations 3
time step continuity errors : sum local = 2.21621e-05, global = 3.2579e-08, cumulative = -0.00204445
GAMG:  Solving for p_rgh, Initial residual = 0.967045, Final residual = 2.58939e-07, No Iterations 50
time step continuity errors : sum local = 1.37846e-09, global = 4.13634e-12, cumulative = -0.00204445
smoothSolver:  Solving for omega, Initial residual = 0.000115323, Final residual = 2.6647e-06, No Iterations 1
smoothSolver:  Solving for k, Initial residual = 2.4012e-05, Final residual = 2.34055e-06, No Iterations 6
ExecutionTime = 35841.2 s  ClockTime = 36002 s

surfaceFieldValue inletFlux write:
    sum(inlet) of rhoPhi = -0.0742279

surfaceFieldValue outletFlux write:
    sum(outlet) of rhoPhi = 0.0741348

Courant Number mean: 0.00867972 max: 1.07575
Interface Courant Number mean: 0.000872321 max: 1.07575
deltaT = 6.62197e-08
Time = 0.0324693

              5、核心的话是这样的，Taurus使用batch系统，可以指定需要的node，task，cpu数，内存量以及每个任务task分配的cpu数，task对应分割区域的的数量，每个区域可以分配你需要的cpu数上去算。我分了24份，每一份用4个核算，就是96个核。

              队长别开枪 1 条回复 最后回复 回复 引用
              • I
                Irisch @wwzhao 最后由 编辑

                @wwzhao 您好，非常感谢您的回复！
                那我这里有个问题，那如果在不产生发散的情况下，把网格继续细化，然后用多核计算，这个时间的消耗和用粗网格少核计算对比，会不会有明显差异？

                W 1 条回复 最后回复 回复 引用
                • I
                  Irisch @aiweimo 最后由 编辑

                  @aiweimo 您好！非常感谢您的回复！
                  是的，并行运算核之间的交互问题也想到了，就是一直找不到一个合适的分割数量，可能我这里对并行运算和分割有点误区，需要再补足一下。

                  1 条回复 最后回复 回复 引用
                  • I
                    Irisch @队长别开枪 最后由 编辑

                    @队长别开枪 对了，那个最小尺寸的话，算下来应该是0.13 mm*0.0125 mm的这个量级。我之前希望把这个量级改一下，导师说不行，他们做实验的就是这个尺寸，所以要在其他参数上想办法。

                    1 条回复 最后回复 回复 引用
                    • 队长别开枪
                      队长别开枪 教授 @Irisch 最后由 编辑

                      @Irisch 在 有关Openfoam在超算并行运算的问题 中说：

                      我分了24份，每一份用4个核算，就是96个核

                      这部分没看明白，不懂一个网格分区是怎么用四个核(线程)进行计算的。看日志时间步长到了1e-8量级了，网格尺寸可能在垂直于速度矢量的方向上过小了。你可以试着用粗网格算一下看看结果怎么样，你导师说换网格尺寸不行又不影响你自己使用粗网格验证一下，你要有自己的想法。

                      I 2 条回复 最后回复 回复 引用
                      • I
                        Irisch @队长别开枪 最后由 编辑

                        @队长别开枪
                        可能是我没表达好。我先是分了24个区域在decomposePar文件里面，然后在超算上预定运算资源的时候，预定了4个nodes，每个nodes上有24个cpu，然后制定每个nodes运算6个task，一个task对应一个区域分区，最后指定每个task（区域）使用4个cpu来进行计算。这样的话就是4nodes6tasks/nodes4cpus/task（区域）=96cpus，是这么得出来的。
                        我自己已经完成了一个cm级别的非常粗网格的计算，大概只有5000个网格的算例，结果确实是我们想要的，这个已经做出来了，计算速度很快，用自己电脑单核跑一下大概5个小时就出结果了。结果的效果很好，所以现在就需要做准确的精细计算了。

                        队长别开枪 1 条回复 最后回复 回复 引用
                        • I
                          Irisch @队长别开枪 最后由 编辑

                          @队长别开枪
                          4(nodes) X 6(tasks/node) X 4(cpus/task（区域）)=96cpus

                          1 条回复 最后回复 回复 引用
                          • W
                            wwzhao 教授 @Irisch 最后由 编辑

                            @Irisch 网格细化后采用多核求解和粗网格少核求解的时间单个时间步的求解时间可能差别不大，但细网格对应的时间步长需要减少，总共的迭代时间步数会增加

                            I 1 条回复 最后回复 回复 引用
                            • I
                              Irisch @wwzhao 最后由 编辑

                              @wwzhao 恩恩是的，非常感谢！

                              W 1 条回复 最后回复 回复 引用
                              • W
                                wwzhao 教授 @Irisch 最后由 编辑

                                @Irisch 没明白task是什么，一般只有node或CPU core的概念。你用的这个HPC应该是一个node有24个CPU core，24万网格我估计顶多用两个CPU core就可以跑，再多的CPU core也提升不了多少求解速度。。。

                                I 1 条回复 最后回复 回复 引用
                                • I
                                  Irisch @wwzhao 最后由 编辑

                                  @wwzhao
                                  task就是对应的一个分割的区域，就是总的task数目对应分割的数量24个，只不过你要给超算要告诉他你有几个task要做，这个是在超算上设置的。
                                  如果我把参差稍微放大到10的-4或者-3的量级，对结果会产生很大的影响么？

                                  1 条回复 最后回复 回复 引用
                                  • 队长别开枪
                                    队长别开枪 教授 @Irisch 最后由 编辑

                                    @Irisch 建议做下网格尺寸无关性，一味的追求超精细网格是没有意义的，网格细化到一定程度后再细化可能对结果影响很小，但是会增加计算时间，一是会降低时间步长，二来也增加了代数求解器的迭代次数和时间。工程应用中的CFD需要平衡求解精度和计算所需时间，找到一个精度和计算时间都可以接受的网格尺寸。

                                    I 1 条回复 最后回复 回复 引用
                                    • I
                                      Irisch @队长别开枪 最后由 编辑

                                      @队长别开枪 在 有关Openfoam在超算并行运算的问题 中说：

                                      网格尺寸无关性

                                      好的！非常感谢！

                                      1 条回复 最后回复 回复 引用
                                      • C
                                        cccrrryyy 教授 最后由 编辑

                                        你运行完decomposePar后的显示是什么？手动分块容易造成有的核分了很多网格，有的分了很少，分的多的跑的很慢，所以其他核还是要等它算完了才能继续。我一般用scotch，不用输入任何参数，openfoam自动会把分区做成1、每个分区cell数目接近；2、分区之间的processor面尽量的小，从而减小数据传输的需求。

                                        batch系统调度感觉你需要再细看一下？node是结点数，你24个分块，如果比如超算上一个结点就有24个核（4个6核cpu），那你node数量只需要1吧？这个超算是什么样的，每个结点有几个cpu，每个cpu几核呀？

                                        I don't want to survive, I want to thrive.

                                        1 条回复 最后回复 回复 引用
                                        • First post
                                          Last post