@MrZZQi 感谢分享 ！:xiexie: 前几天刚跟海东说完更新一下这个内容，顺便参考一下你的内容

哦，明白了，谢谢。

如图所示，该计算的本意是让进口产生大小为408m/s，方向为63°的气流，因为这是为内流计算做准备，所以规定了出口静压以及进口总压总温和速度方向，并未给出速度的大小，具体可参考设置文件。其计算的原文件如下：325_3.zip
计算的几何为一个0.050.1的长方形，网格量为2080.

84802716afac01f16b6c42a03124b30.png

计算是可以收敛的，但是残差非常非常的高，这里给出了最后一段计算时间步的残差情况。压力项的残差是1e-2这个量级，观察计算文件发现，进口的k和ω的值异常的高，根据湍动能计算脉动速度发现脉动速度甚至超过了主流速度。这是什么情况引起的呢？

residuals.png
k.png

http://dyfluid.com/icofoam.html 更新了一下，你理解下试试?

如果你用的传统的有限体积法，网格顶点的速度压力等信息你是不需要的老铁 :papa:

哦，知道了，谢谢。

链接文本
链接文本
和数据结构有关，这两篇有介绍。

openfoam手册中写到mergeMeshes可以将两套网格合并，那么具体是怎么操作的呢？controlDict中需要添加什么信息？

@东岳 好的，多谢东岳老师

我觉得最简单的方法是适当的延长一段出口增加空气域，很多SCI都这样做防止出口的影响

@东岳 谢谢东岳老师，我正在修改弹性模量，让变形小一点。

这样的话，管流的速度不知道为何会持续增涨，然后在入口处变成一个非常大的值后计算崩溃。我之后改成了入口为totalPressure，才能实现稳定的速度，计算也能保持稳定。请问这两个边界条件分别在什么情况下使用呀？

谢谢。

@范准 非常好，感谢分享 :xiexie:

@东岳 @宝丁 哪里哪里，举手之劳而已

参考 http://www.cfd-china.com/topic/933/swak4foam-和-openfoam4-1/2

@郑澄远 你的0文件夹下的U文件有问题。应该是初始场的个数与网格单元数不一致。

@dzw05
k：

dimensions [0 2 -2 0 0 0 0]; internalField uniform 0.081; boundaryField { inlet { type zeroGradient; } outlet { type zeroGradient; } frontAndBack { type symmetry; } inter2 { type cyclicAMI; } inter1 { type cyclicAMI; } blades { type kqRWallFunction; value $internalField; } }

nut

dimensions [0 2 -1 0 0 0 0]; internalField uniform 0; boundaryField { inlet { type fixedValue; value $internalField; } outlet { type calculated; value uniform 0; } frontAndBack { type symmetry; } inter2 { type cyclicAMI; } inter1 { type cyclicAMI; } blades { type nutkWallFunction; value uniform 0; } }

omega

dimensions [0 0 -1 0 0 0 0]; internalField uniform 0.095; boundaryField { outlet { type zeroGradient; } blades { type omegaWallFunction; value $internalField; } inlet { type zeroGradient; } frontAndBack { type symmetry; } inter2 { type cyclicAMI; } inter1 { type cyclicAMI; } }

p

dimensions [0 2 -2 0 0 0 0]; internalField uniform 0; boundaryField { inlet { type zeroGradient; } outlet { type fixedValue; value uniform 0; } frontAndBack { type symmetry; } inter2 { type cyclicAMI; } inter1 { type cyclicAMI; } blades { type zeroGradient; } }

u

dimensions [0 1 -1 0 0 0 0]; internalField uniform (14 0 0); boundaryField { inlet { type fixedValue; value uniform (14 0 0); } outlet { type zeroGradient; } frontAndBack { type symmetry; } inter2 { type cyclicAMI; } inter1 { type cyclicAMI; } blades { type rotatingWallVelocity; origin (0 0 0); axis (0 0 1); omega 0; } }

boundary

inlet { type patch; nFaces 400; startFace 6377766; } outlet { type patch; nFaces 400; startFace 6378166; } frontAndBack { type symmetry; inGroups 1(symmetry); nFaces 4800; startFace 6378566; } blades { type wall; inGroups 1(wall); nFaces 80334; startFace 6383366; } inter1 { type cyclicAMI; inGroups 1(cyclicAMI); nFaces 13994; startFace 6463700; matchTolerance 0.0001; transform noOrdering; neighbourPatch inter2; } inter2 { type cyclicAMI; inGroups 1(cyclicAMI); nFaces 11572; startFace 6477694; matchTolerance 0.0001; transform noOrdering; neighbourPatch inter1; }

fvSchemes

ddtSchemes { default Euler; } gradSchemes { default Gauss linear; grad(p) Gauss linear; grad(U) Gauss linear; } divSchemes { default none; div(phi,U) Gauss linearUpwind grad(U); div(phi,k) Gauss limitedLinear 1; div(phi,omega) Gauss limitedLinear 1; div((nuEff*dev2(T(grad(U))))) Gauss linear; } laplacianSchemes { default Gauss linear limited corrected 0.5; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } wallDist { method meshWave; }

fvSolution

solvers { "pcorr.*" { solver GAMG; tolerance 0.02; relTol 0; smoother GaussSeidel; } p { $pcorr; tolerance 1e-7; relTol 0.01; } pFinal { $p; tolerance 1e-7; relTol 0; } "(U|k|omega)" { solver smoothSolver; smoother symGaussSeidel; tolerance 1e-06; relTol 0.1; } "(U|k|omega)Final" { $U; tolerance 1e-06; relTol 0; } cellDisplacement { solver GAMG; tolerance 1e-5; relTol 0; smoother GaussSeidel; } } PIMPLE { correctPhi yes; nOuterCorrectors 2; nCorrectors 2; nNonOrthogonalCorrectors 5; pRefCell 0; pRefPoint 0; pRefValue 0; } relaxationFactors { fields { p 0.2; } equations { "(U|k|omega)" 0.7; "(U|k|omega)Final" 0.7; } } cache { grad(U); }

站在2019年，这个问题就会很有意思了。

首先，从软件的层面，虽然我还咩有机会仔细比对fluent和openfoam的区别，但是从业界的反应来看，开源和商用上纯理论层面没太大区别。只是界面和用户习惯上的问题，这个会是放在企业抉择面前的最大问题，也是目前商业帝国的基础。

企业主要就看性价比。就目前的情势而言，企业在不考虑正版化的情况下，会优先选择fluent。比较好用又不要钱。企业的选择：

使用环境：windows，linux，好像前者简单 人才成本：薪酬、培训费，目前fluent人比较好招 版权费：不存在的。
所以综合下来fluent不赢都难。

但是随着最近正版化越收越紧，微软win10的价格其实非常公道。所以很多企业都会考虑尽可能上正版win10. 而对于of来说，win10是他们的朋友，因为ubuntu内嵌，最近连linux格式都支持了。那安装oe的成本其实很低。所以就平台而言，oe和fluent已经站到了同一起跑线上。

下面的问题就是工程师喜欢哪个了，如果oe的生态链（应用、可视化、培训）整体也上来了，企业的选择就会变成：

使用环境：都是win10，没差 人才成本：薪酬、培训费，fluent大概略低，但差不了多少 版权费：fluent肯定贵

所以，oe的机会就在于怎么把应用做得更好用，类似“傻瓜都能收敛” + 增加用户基数。

which，也就是东岳目前正在做的。

@LiuZhuang http://xiaopingqiu.github.io我基本上看的都是这个人写的总结