讨论 Fluent计算效率优于OpenFOAM



  • :zoule: openfoam在网格量大和质量不好时,效率会降低明显

    参考 https://www.cfd-online.com/Forums/openfoam/124745-openfoam-vs-fluent.html

    • I have found that the main deficiency of openfoam is that it is very sensitive to mesh quality. if I divide the mesh quality to very good, good , medium,bad ,very bad then the OF and Fluent have the same performance on the very good meshes. OF performance on the good meshes is lower than FLUENT and it can not handle other meshes. FLUENT can handle medium and bad meshes very well.

    • I have run several test case with OF and Fluent with similar settings. I have found that fluent is more stable , accrue and faster than OF. Also OF is very sensitive to mesh quality but Fluent not.

    • fluent相当于黑匣子,但OpenFOAM可以编自己的求解器: https://www.researchgate.net/post/More_efficient_and_effective_software_between_OpenFOAM_and_Ansys_FLUENT

    替代文字
    替代文字
    替代文字

    @东岳 @wwzhao @程迪 @random_ran @宝丁 @mohui @史浩 @Aeronastro @lhzhu @youmengtian @Calf-Z-DNS @cccrrryyy @CFD中文网 @小火人 :zoule:
    openfoam高雷诺数 大网格量 质量较差的情况,需要怎么处理较好?或者openfoam怎么优化才能在这种情况下,效率追上fluent?


  • OpenFOAM讲师

    @Foamer24 冒昧回复仅供参考,我觉得还是在于fvSchemes中离散格式的选用。对于skew较大等网格质量不好的问题其实就两个思路可供选择,第一重画网格,第二如果的确无法提高网格质量只好退而求其次选择数值耗散更强但是有界性相对较好的的离散格式。其实tutorial中给出的很多示例很难拓展到工程背景下的计算中。对于计算效率的问题往往跟选择的线性矩阵求解方法有关,目前尚未有普适的定论。您给出的结论也并不能涵盖所有的计算情况,您给出的截图也是OpenFOAM更快一些,但是往往需要选择合理的求解方法。根据Fluent的官方手册,它广泛使用的是AMG的求解方法,特别详细的内容我也并不清楚。

    以上,希望没有传递特别离谱的错误信息,如有不当请及时联系,共同学习。



  • Fluent,你把面粉放进去,啥都不用知道你也不需要知道,就能出面包。

    • 优点:省心
    • 缺点:做个面包而已其他啥都不知道

    OpenFOAM放面粉进去,你得自己动手做出面包

    • 缺点:太费事
    • 优点:做个面包之后你能变成全国顶级面点师

    %(#ff0000)[这是严重的差异。]我确实有一些话要说,但现在我有些其他事情要做。改天详细讨论!



  • 本人做凝固模拟研究的,就这么说吧,Fluent算三天的数据,OpenFOAM 2小时搞定了
    然而Fluent前后设置开发,一共花了我2星期,而OpenFOAM求解器开发,我连学习带尝试,花了两个多月的时间(本人有C++面向对象开发经验,也曾经纯自编程写过CFD程序)
    主要速度提升有以下几个方面:

    1. 求解算法的自由调整。Fluent基本上无脑SIMPLE算法,框架改也不能改,基本上都是:求U方程、压力修正、求解湍流方程、求T方程、求C方程、求解自定义方程,判断连续性误差,收敛进入下一时间步,否则重复上述迭代。相比之下,OpenFOAM可以根据自己的需要加入外迭代、压力修正迭代、适时的湍流修正、一些自定义场之间的内迭代等等,这些求能加快收敛速度,减小计算量

    2. 求解器的选择。FLUENT基本无脑AMG算法;OpenFOAM则可以自己修改不同方程的求解器以及求解器参数的设置

    3. 优秀的CFD算法植入。OpenFOAM中一些非常高效的算法植入要比Fluent快很多。以两相流求解器来说,在很多工程计算中,interFoam要比FLUENT中的VOF模型快好多

    4. 高效并行。这个可能和我用的系统以及FLUENT的版有关。Fluent我一直用的是Windoes平台下盗版软件,并行效率感人,基本上超高12核计算速度就基本不动了;而OpenFOAM,几百万网格并行加速效果还是很明显的

    上面是我自己在两个平台下的感觉。基本上做项目,先用Fluent尝试算个结果,这里不得不说一下,Fluent鲁棒性真的好,你瞎搞的算例都能给你算出个东西来。对工艺有了更好的了解之后就转到OpenFOAM开发,根据实际工艺修改求解器、边界条件等参数。

    两个平台都用过,两个平台都很菜,还望各位老师多多批评指正



  • 很难公平对比

    Fluent和OpenFOAM计算效率问题,我个人感觉不能一概而论。举一个非常简单的粒子就是:很多SCI说A模型比B模型好的太多,但还是有很多SCI说A模型远远不如A模型。这种SCI都经常出现不同的观点,因此公说公有理这太常见了

    我个人,用OpenFOAM算了很多奇葩算例,可玩的太多了。OpenFOAM这面需要你去调试算法、网格,并且会大大影响你的计算效率。很多的过程会影响你的计算过程。比如:

    1. 有时候多重网格求解器1秒就收敛,PCG要迭代1000次可能算10s

    2. 有时候时间步长会特别小导致计算的特别慢,这是要从算法上去解决的,比如链接文本中的公式41和42,两种算法直接导致计算时间的不同

    3. 一些奇葩算例动量预测步骤开启会影响你的计算效率,不如关了。一些算例GAMG糙化可以放得大一点,一些算例没必要进行网格修正,甚至你的写文件是binary还是ascii都会影响你的效率。我还可以告诉你一些高IO的算例,硬盘读写能成为卡你脖子

    这些我不知道Fluent里面能不能处理,如果不能处理,就很难做一个公正的对比。因此对于计算效率对比这种事情。Fluent与OpenFOAM应该是完全不同的东西。并且,Fluent那面好像库郎数运行在100也可以?虽然我现在也不知道Fluent那面怎么实现的。

    无脑AMG

    我之前问过几个研究生,他那面用Fluent跑皇冠牛奶的算例一直在发散,我问你的库郎数多少?你的压力求解器用的什么?这个研究生告诉我我也不知道呀,我全都用的默认设置

    :wocao:

    就像 @史浩 说的:

    FLUENT基本无脑AMG算法

    Fluent可能默认全部是AMG求解器?不能换一些别的么?我不太清楚为什么?在网格数量少的时候没必要上奔驰AMG啊。奔驰E系列也行啊:duang: 在这里拓展一下。这个AMG求解器在一些文章里面,并不会表现的特别明显,比如某SCI:

    捕获.JPG

    当然,这只是一种断论,可以选择相信也可以选择不信。就像我之前说的,SCI里面互相抵触的结论太多了。你完全可能在某些SCI里面支持无脑AMG算法


    使用感受不同

    %(#ff0000)[另外跑个题],这是另一个研究生给我发的邮件,当时觉得挺有意思,感觉是要入行CFD了

    捕获.PNG

    再比如这个帖子 http://www.cfd-china.com/topic/2371/

    关于学习fluent,有一些困惑,我自己是从图书馆借了两本fluent入门到精通的书跟着步骤练习,书里只讲每一步设置什么参数,但是我不明白为什么那样设置?我基本上是三周左右把两本书跟着联系完,感觉收获不大。想请教各位应该怎样正确的学习fluent呢?软件操作怎样与相关理论结合呢?

    我玩这么多年OpenFOAM大家应该都知道,在这里说一下我的Fluent经历。我在2012年左右,学OpenFOAM学的要放弃了,学习曲线太陡峭,不出成果,打算换Fluent,于是就装了一下,我记得当时用VOF算了气泡,应该是我没怎么学就算出来了。这里没怎么学,是指我只是下了Fluent,我大体就是参考那个研究生一样,全部采用默认设置没参考任何书。所以我认可市面上大家说的“塞一坨屎进去Fluent,都能给你算出来”。

    但我后期还是硬着头皮学了OpenFOAM,学习的过程中了解不少CFD算法的东西,对后来上手任何的CFD项目帮助很大。虽然Fluent能把塞进去的屎算成面包,但我想知道他怎么算出来的,Fluent并不能告诉我如何变得魔术。我有很多的算法问题在考虑怎么处理,我当然考虑过参考Fluent怎么实现的,但代码是闭源的永远不知道结果。

    But,我还是承认:如果对CFD算法一点都不care,算项目Fluent应该够你的需求。我这面做科研比较多,入坑OpenFOAM。重要的呢,我现在用OpenFOAM完全也可以算Fluent能算的东西

    另外现在干什么都是水涨船高,10年前博士就能留校,现在不是博士后不可能。发文章也一样,以后CFD发文章会越来越难,在这种压力下,植入自己的算法会压力小一些

    国内Fluent盛行的原因跟版权意识有很大关系。这个早晚会改变 不过,没准人家A厂是故意放任小客户用盗版占领市场呢?毕竟还要跟S厂D厂竞争啊,不过也听说过某同行说自己公司有法务部天天打电话。
    具体怎么样,我不确定啊我是瞎说的。现在我说点啥都可能被人要求道歉..

    :xinlei:


  • OpenFOAM副教授

    @Foamer24 效率问题我很感兴趣,写点自己的看法,权当抛砖引玉。我的个人观点是,做CFD最终的目的是要能算东西,所有的算法都是为了能算点什么,但这里有一个先后问题--植入算法的第一步是“能算”,或者说“算对”,第二步才是“怎么算的更快”。

    对于“怎么算的更快”,很有可能Fluent在这方面优于OpenFOAM(不考虑并行的时候)。“怎么算的更快”不仅需要CFD,还需要软件工程、数据结构等等元素。Fluent是商业软件,他们的团队很强大,如果它算的更快我不会特别惊讶,尤其是对于成熟的模块(不需要自己加东西,输入参数就开算的东西)。各位有兴趣可以在LinkedIn上查查Fluent的员工,背景都很强而且多样化。他们有专门的软件工程师,做做什么UI和代码方面的优化是很有可能的。但是这个东西肯定跟case有很大关系,差分格式、线性求解器等等当然就影响更大了。网格方面,Fluent很可能处理较差网格的能力更强。这个就更好理解了,它是商软,它最理想的要garbage in-fairly good results out,很有可能它做过什么处理。这方面我碰到过,同样的网格Fluent能给出比较好看的结果,OpenFOAM就不说了- -但是换一套好的网格,两个差别就没有之前那么大。OpenFOAM是绝对的garbage in-garbage out,而且这里的garbage in不光指网格,还包括边界条件、差分格式等等等等,而Fluent基本上别的都不用管,只要网格凑合就行。

    但是“怎么算的更快”永远都是第二位的。从这点来讲,OpenFOAM的好处就体现出来了。首先它是开源的,因此我输入了什么、怎么算的我很清楚,所以如果哪里算错了我很容易能找到原因(针对已经成型的模块),这其实对学习CFD是一个很好的过程。长期用Fluent的结果我是知道的,就是你猛然问我你这个问题是封闭的吗,我一下子真不一定答的上来。我对这个solver需要求解几个变量、求解了哪几个方程并不是特别清楚。但是用OpenFOAM不会出现这种问题。典型的例子就是RANS,我在OpenFOAM里面用RANS,我能清楚的看到求解了epsilon方程,求解了k方程等等;但在Fluent里面我如果不去看它的Theory Guide(不是那个User Guide)我是不知道这些方程长啥样的。当然了,不同的人有不同的需求,对于搞科研而言当然是什么东西越清楚越好,对于工程应用而言就不一定。

    其次OpenFOAM可以加的东西基本上是没有限制的。这方面其实Fluent最近几年一直在改善,它通过udf可以改的东西越来越多了。但是自己加的东西能满足“算对”就很不错,“算的更快”不那么容易做到,或者说根本没人在乎。

    我自己是从Fluent转到OpenFOAM的,Fluent用了将近五年,OpenFOAM到目前为止将近一年半。Fluent实际上是很好的求解器,上手容易,UI也一直在改进,我很推荐刚入门CFD的人先用一下Fluent,至少先熟悉跑一个复杂的case需要什么步骤。在这个基础之上再转OpenFOAM,一是会平滑的多,二是像探索未知世界一样会发现更多好玩的东西。

    如果不是做科研,OpenFOAM的优势对比Fluent不明显。我用Fluent是读博的时候和当地一家企业合作,他们每周都要汇报进展,要看到彩图,甚至图都没法满足他们,只有动画才可以(我接手项目不到一个月就被要求整个动网格的结果)- -所以他们选择用Fluent。这一点对于企业其实是很重要的,他们很多时候对几何模型修修补补或者微调一个工况,然后想看看对结果有多少影响。如果每个方案都去做实验,太慢而且贵,所以他们才想到做CFD。假设这时候你一个engineer跟老板说我做这个case要花三个月(学OpenFOAM、画高质量网格),老板宁愿花点钱买Fluent(我们买的academic license,印象中一年3600刀),搞不好顺便也把你解雇了:chouchou:

    另外很有意思的一个点,我以前没做过LES,现在转战OpenFOAM做LES,会发现Fluent的LES很多地方值得商榷,相比之下OpenFOAM的LES更清晰。再有就是,做LES就要用到并行计算,这方面我长期围观cfd-online的感觉是OpenFOAM好像更快一点?因为可以采用更合适的线性求解器。Fluent就不行了,无脑AMG。这个不知道正确与否。

    欢迎讨论。



  • @东岳

    我不确定啊我是瞎说的。现在我说点啥都可能被人要求道歉..

    :xinlei:

    这么真实吗?开玩笑的话都被一些人当真了,还要道歉,真是树大招风啊:chigua2:


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

    @东岳 是前几天那篇微信推文吗?凭啥要你道歉啊?读文章都不带眼睛的么,较真的人应该反思一下自己能不能读懂一篇论文,那么多细节表示文章是虚构的,意在提醒国人要发展自己的CAE软件包,别真到时候又抓瞎。



  • 很开心看到大家这么多的观点,下面也说说我最近的%(#ff0000)[个人]看法:laile:

    • 不管fluent还是OpenFOAM都只是工具,更关键的是所关注的问题及其内在的科学规律、机理。资深级CFDer应该会有判断garbage result的能力,会对结果有个大体的预期,对意想不到的结果也有分析判断的能力,甚至有的可以根据流场看出用什么软件/模型求解的。fluent设计目的是提供一个a black box solver that is robust,OpenFOAM则可以自编代码,处于食物链的上一级,更高一级的就是全部自编的in-house代码了。希望以后可以看到fluent的UDF提供更多像OpenFOAM的可操作空间。

    • fluent的非定常计算采用implicit,隐式的求解和时间无关,所以时间步长相比显式要大,不过隐式也存在迭代收敛的问题,这样的问题在OpenFOAM中也会出现,即not converged within 20 iterations。求解方法上用隐式或显式消耗的时间理论上无法比较,工程上一般隐式快一点。在fluent中用隐式进行定常计算,在计算稳定后,设置库郎数100也是可以的,因为定常的最终结果是一定的。但是非定常就不行了,这会牵涉到时间精度的问题。

    • 作为新手,我学习OpenFOAM的过程是先将OpenFOAM用成fluent,然后再准备修改OpenFOAM得到属于自己的fluent。:laile: 不知道这样合不合理,主要是直接看代码,难以短期内有进展,很多情况下要求的是做错了也要有个错的结果。。。

    • 回到标题,在计算三维LES时,相同网格在fluent里面计算的时间步长是10^-6,在OpenFOAM中用了runTimeModifiable 和 adjustTimeStep变为了10^-9~10^-8,不用就报错。不知道是不是就是大家所说的AMG求解器的原因。

    3f33834a-b8a7-4884-ac22-0d49bae68ef5-image.png


  • OpenFOAM教授

    @Foamer24

    OF想赶上商软的鲁棒性和效率恐怕很难。一方面,商软有很多加速的“黑科技”,而这些“黑科技”在用户手册中都不会提及;另一方面,商软中的求解策略都经过优化,对CFD理解不深的人也可以轻松入手使用,而OpenFOAM中的求解参数自由度较大,对于CFD新手来说不当的参数设置显然会导致求解速度的降低。

    至于你的问题,在网格质量不好的情况,首先应当考虑提高网格质量,尽量避免出现歪斜率高的网格和非正交网格。因为这些网格会影响对流项和扩散项的离散精度,从而影响矩阵迭代求解的收敛速度。


  • OpenFOAM教授

    @东岳讨论 Fluent计算效率优于OpenFOAM 中说:

    具体怎么样,我不确定啊我是瞎说的。现在我说点啥都可能被人要求道歉..

    :xinlei:

    树大招风啊,李博顶住~



  • @东岳 @wwzhao @cccrrryyy 您好!今天看到cfd-online上的链接:https://www.cfd-online.com/Forums/openfoam-solving/123586-simulations-large-time-steps-high-cfl.html 。里面讨论了 simulations with large time steps (high CFL),帖子比较老了,说原因是OPENFOAM中没有像fluent那样Pressure-velocity coupling的coupled solver。粗略的看了下文献《A fully coupled OpenFOAM® solver for transient incompressible turbulent flows in ALE formulation》,里面说Implicit + coupling 效率要高。



  • 试了下同样的算例用Fluent 19计算,真的是黑匣子。。。时间步长0.2s都不发散。要是能借鉴一些方法到OpenFOAM里面就好了 :mihu:


  • OpenFOAM教授

    @Foamer24

    首先,我不认为coupled solver可以允许更大的时间步长。

    其次,从理论上说SIMPLE算法不适用于瞬态问题,Fluent里面使用了Transient SIMPLE算法来计算瞬态问题,时间步长取很大也可以算下去,但是很显然时间项的精度会很低,算出来的东西不可信。


  • OpenFOAM副教授

    @Foamer24 我记得在哪里看到过OpenFOAM的PIMPLE算法原则上是允许大时间步的,它设计这个算法好像就是为了绕过CFL数一定要小于1的情况(印象中是有个最大数字的,好像是<3~5)。回到你前面讲的LES在fluent里面时间步长是10^-6,在OpenFOAM里面就要更小。这一点我有体会,就是感觉OpenFOAM首先是自适应时间步不好用。我现在都用给定的时间步,数值上确实比fluent里面要用的小一点,但不像你在数量级上差这么多,我一般大概用到fluent时间步的八成左右。

    我计算的时候会检测最大和平均CFL数,有时候都跳到1点多了,但感觉好像也没啥问题- -我也是LES,然后速度场都用PBiCGStab加DILU,压力用PCG加DIC,不知道你用的是什么,可以分享一下么?你这个时间步我很好奇啊,这么小感觉算起来要等死人的- -

    学OpenFOAM光看代码真的不行,随便找个例子做一下学起来更快(比如加个标量方程啊之类的)。当然了,最重要的就是你说的对物理问题的理解。我还想加上一点,就是对数值算法的理解。我学什么numerical diffusion, dispersion这种就感觉学的艰难,甚至到现在都不敢说完全懂。



  • @wwzhao @cccrrryyy 您好!我还处于入门阶段,一边用OpenFOAM,一边学OpenFOAMwiki上的3weeks编程查询,我的fvSchemes和fvSolution文件如下,目前调试经验是在fvSchemes中设置fluxScheme Tadmor;算得比设置Kurganov;要快。我后面再试下各位的设置,再过来交流。:laile:

    /*--------------------------------*- C++ -*----------------------------------*\
      =========                 |
      \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
       \\    /   O peration     | Website:  https://openfoam.org
        \\  /    A nd           | Version:  6
         \\/     M anipulation  |
    \*---------------------------------------------------------------------------*/
    FoamFile
    {
        version     2.0;
        format      ascii;
        class       dictionary;
        location    "system";
        object      fvSchemes;
    }
    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
    
    fluxScheme          Tadmor;// Kurganov;
    
    ddtSchemes
    {
        default         Euler;
    }
    
    gradSchemes
    {
        grad(U)         cellLimited Gauss linear 1;
        grad(nuTilda)   cellLimited Gauss linear 1;
        grad(e)   cellLimited Gauss linear 1;
    }
    
    divSchemes
    {
        default         none;
        div(tauMC)      Gauss linear;
        div(phi,nuTilda) Gauss linearUpwind limited;
    }
    
    
    
    laplacianSchemes
    {
        default         Gauss linear corrected;
    }
    
    interpolationSchemes
    {
        default         linear;
    }
    
    snGradSchemes
    {
        default         corrected;
    }
    
    wallDist
    {
        method meshWave;
    }
    
    
    // ************************************************************************* //
    
    
    /*--------------------------------*- C++ -*----------------------------------*\
      =========                 |
      \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
       \\    /   O peration     | Website:  https://openfoam.org
        \\  /    A nd           | Version:  6
         \\/     M anipulation  |
    \*---------------------------------------------------------------------------*/
    FoamFile
    {
        version     2.0;
        format      ascii;
        class       dictionary;
        location    "system";
        object      fvSolution;
    }
    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
    
    solvers
    {
        p
        {
            solver          GAMG;
            tolerance       1e-7;
            relTol          0.01;
            smoother        GaussSeidel;
            cacheAgglomeration off;
            nCellsInCoarsestLevel 20;
            agglomerator    faceAreaPair;
            mergeLevels     1;
        }
    
        Phi
        {
            $p;
        }
    
    
        pFinal
        {
            $p;
            tolerance       1e-06;
            relTol          0;
        }
    
        "(k|omega|epsilon|nuTilda|U|R|v2|f|kt|kl|e)"    
        {
            solver          smoothSolver;
            smoother        GaussSeidel;
            nSweeps         1;
            tolerance       1e-20;
            relTol          0.01;
        }
    
    
      "(rho|rhoU|rhoE)"
        {
            solver          diagonal;
        }
    
    
    }
    
    // ************************************************************************* //
    
    


  • @cccrrryyy 您好!请问你的时间步长具体值一般是多少?还有就是网格边界层高度是多高?我的分别是10e-8s和0.0001m。:zoule: 算的确实慢,难以接受



  • @cccrrryyy 算例远场速度是72m/s,调节网格后时间步长提高到了3×10^-8,使用pointwise监测最窄边的长度为2.8×10^-5,使用这些值计算的库朗数是0.077,用rhoCentralFoam计算过程中显示的最大库朗数确是0.53,有点不理解,不知道这个最大库朗数点的位置在哪。:chouchou:

    Mean and max Courant Numbers = 0.001871585 0.5321452
    

  • OpenFOAM教授

    @Foamer24

    远场速度不是最大速度,所以一般实际库朗数比计算得到的要大。



  • @wwzhao :ok: 谢谢,库郎数中的速度指的是特征速度,就用了远场速度,不过用您说的最大速度来预估更合理。还看到东岳老师分享的链接,介绍三维非结构网格的库郎数计算,这个公式中的最小体积可以用画网格软件得到,但不知道通量该如何取值。


  • OpenFOAM教授

    @Foamer24

    一方面,非结构网格的库朗数是通过网格体积和通量(与速度有关)计算的,而一般我们计算库朗数的公式是最简单的一维情况,这两种情况本身就有区别,参考这个链接

    另一方面,有些网格的当地局部速度比特征速度大得多,所以这些网格的库朗数比用远场速度估算得到的库朗数要大。



  • @Foamer24讨论 Fluent计算效率优于OpenFOAM 中说:

    Mean and max Courant Numbers = 0.001871585 0.5321452

    你努力的方向不应该去找库郎数,你的算例只是发散了,库郎数只是表现,不是根本。建议找找发散的原因去去根 :ok2:


  • OpenFOAM副教授

    @Foamer24 感谢分享!我没用过fluxScheme,所以这里什么比较好不太清楚。时间步我一般刚开始都是1e-06,之后根据最大CFL数再去调。我个人的感觉是如果需要调到5e-07以下我就会比较注意了,这种量级感觉算的相当慢了。我的网格有内流和外流两部分,内流的话边界层在0.1mm上下,和你差不多。这个就用雷诺数估算了一下。外流(射流)的话就没care边界层了。

    我觉得时间步的绝对大小参考意义比较小,毕竟也看你的硬件好坏。可能单个时间步需要的时间(我的大概在一分多钟)和总时间步数(我的大概50,000左右)比较有比较价值。另外,我的ddtScheme一般用backward,因为是二阶的。对流项我也一般不用迎风格式,迎风格式对LES好像不太好。线性求解器里面我的压力方程一直是用PCG在解,没用GAMG。这个点其实我很关心,就是PCG和GAMG到底孰优孰劣,希望有经验的来探讨下!

    你这个同样的网格用Fluent只需要1e-06这种量级的时间步吗?这个感觉不科学啊,同样的网格怎么会差这么多呢。



  • @cccrrryyy fluent的网格边界层更密,为1微米,满足y+小于1。:wanan:


  • OpenFOAM副教授

    @Foamer24 意思是Fluent的网格更密然后还能用更大的时间步?



  • @cccrrryyy 是的:zoule:



  • 你需要深挖一下

    给你举个例子,下面是运算的一个log文件,时间步长非常小,2e-5,算2天之后,结果完全可以是正确的,但我觉得有问题

    捕获.JPG

    在自适应调节时间步长的情况下,时间步长会自动跳转满足CFL标准。其实对于我这个,如果在代码里加上几行,输出Ur的话,会发现下图中全场计算域中,就这么一个地方Ur的值特别大,导致局部库郎数过大

    捕获2.JPG

    我建议你看看你的算例是不是也是这样,我怀疑跟我差不多



  • @东岳讨论 Fluent计算效率优于OpenFOAM 中说:

    Ur

    您好!之前测试的时候,壁面附近网格越密,网格高度变低、长宽比也变大,要求的时间步长deltaT就越小。不知道您说的Ur是什么定义?不知道在壁面附近有没有特殊处理,增加它的时间步长。:laile:



  • @Foamer24 我那个只是举个粒子,你可以看看你的U,不一定看Ur :xinxin3:



  • @东岳讨论 Fluent计算效率优于OpenFOAM 中说:

    你需要深挖一下

    给你举个例子,下面是运算的一个log文件,时间步长非常小,2e-5,算2天之后,结果完全可以是正确的,但我觉得有问题

    捕获.JPG

    在自适应调节时间步长的情况下,时间步长会自动跳转满足CFL标准。其实对于我这个,如果在代码里加上几行,输出Ur的话,会发现下图中全场计算域中,就这么一个地方Ur的值特别大,导致局部库郎数过大

    捕获2.JPG

    我建议你看看你的算例是不是也是这样,我怀疑跟我差不多

    想请教一下遇到这种情况应该怎么办呢?特别算vof的时候,界面某些点出经常出现很大的速度,导致时间步长小的无法接受。


Log in to reply
 

CFD中文网 2016 - 2020 | 京ICP备15017992号-2