CFD中文网

我觉得STARCCM+的网格功能挺6的，笛卡尔/多面体等，控制的参数有限，基本上零基础跟着教程做几遍就差不多了，网格生成速度也很快，比较复杂的几何还是很容易解决的；
其他的用point wise多一点，复杂的几何自己划分块有点麻烦，如果不能分层很容易混乱，简单几何还是非常便利的；ICEM复杂几何切起来还是比较舒心的；^_^

基类fvPatchField<Type>的snGrad()定义就是返回face normal gradient... 也就是$\nabla_{\perp}\phi=\nabla\phi\cdot\vec n $

不知道他们几千万的CFD算法研究经费都是怎么构成的 :143:

嗯 模化的$k_{sgs}$部分可以这么求

@同学博 :jingya: 那我还不太知道。不知道这俩是不是一个东西。激光电视目前倒是销量比较差 :qichuang:

@李东岳 谢谢李老师

@wseric 请问怎么设置？:143:

@gemini 谢谢。刚刚试了您的方法，解决了！

@李东岳 @lsprxd @赵一铭 对于标准壁面函数我是这样理解的：在求解流场的时候还是用原来的k方程和epsilon方程来求解，只不过是将在壁面第一层网格（有可能是网格面上的值，有可能是网格中心的值）上的信息用壁面函数求解的结果来修正，而且壁面函数其实只求解壁面第一层网格的信息，第二层网格之后就是输运方程求解的结果了。不知我这样理解是否正确？

@cloud1990 在 VOF求解自由水面问题，求解空气区域吗？ 中说：

Image

Left: Correct jet shape predicted by TruVOF technique used in FLOW-3D. Right: Incorrect jet shape predicted by pseudo-VOF technique used by other CFD codes.

Image
Left: FLOW-3D‘s TruVOF technique predicts jet impingement on wall and some outflow. Right: Pseudo-VOF methods don’t predict realistic jetting of fluid on side walls.

从结果上看，flow3D 所谓的TruVOF是有问题的，air velocity 和　air resistance = 0?　这个可能比较适合粗网格计算，作为一个tricky的存在．但理论上，这个TruVOF是无法解决wind wave的问题．

标准的限制方法是保证插值后网格顶点（vertice）的值不会出现极大值或极小值（比周围网格的最大值大或比周围网格的最小值小）因为梯度插值最容易出现越界值的就是在顶点处，从而用一个标量来scale梯度gradient；另外一种方法是保证网格的面心midponts of cell faces处不出现极大值或极小值即可，就认为满足了插值后不存在越界的问题。我想的是关于第二种方法，面心处插值后不出现最大值或最小值不能代表顶点处不出现最值，对吗

简单的点线面操作撤销是没问题的，检查拓扑或者是操作包含的数量太多ICEM就没办法了，解决这个问题的最好办法就是你在做包含多步操作的问题时候先另存为一下是最保险的，问了一下学长他也是用这个方法的

kOmega模型是高雷诺数湍流模型。如果做了壁面解析，需要保证在1左右，如果使用壁面函数，可以在30以上。

@chenboyao 在 寻求帮忙看看采用重叠网格对平台做自由衰减后自由衰减曲线不符合衰减曲线的原因 中说：

我采用重叠网格对浮式平台做自由衰减，结果自由衰减的数据曲线到最后不符合自由衰减的趋势，而是还向下偏移了，不知道是什么情况造成的，希望有人帮我看看一下，为什么会出现这种情况。
Screenshot from 2024-06-17 09-20-41.png

您好，请问您的自由衰减实验做成功了嘛？我现在也在做浮式平台的自由衰减实验，也遇到过类似的问题，想很您交流一下:chouchou:

@Leon-Zhao 感谢大兄弟

是否为容差 matchTolerance 太大导致的衔接不上~

背景：我要做自己的CFD软件，有生之年，跟商软来一次硬刚！

我这面目前要做的东西是基于OpenFOAM的CFD软件。OpenFOAM是一个国外的开源的CFD求解器，类似linux内核或安卓。我这面就是要基于国外的OpenFOAM内核，做一个中文的界面出来。就类似小米的MIUI手机系统。软件做出来之后就是国产CFD软件。但是内核是基于OpenFOAM。具体为什么要基于OpenFOAM而不是自己写。主要有2个原因：1）自己写出来的CFD代码没人信，2）所需要的时间要三五倍以上。这也就类似目前的C++，C++是国外提出来的，目前大可以放心使用，没必要自己从头开发一个编程语言。

在有了高度开发化的CFD求解器核心之后，在顶层GUI设计的过程中，要充分的做一个新东西出来：1）不能基于老套路。要按照CFD用户最方便的角度去重新设计。2）要把CFD相关的经验融合进去。做智能化，最易用的操作。目前的CFD软件还不够智能，比如商软，她会给你提供一系列的湍流模型可以选择，但是不会给你提供一个最优解。那这个CFD软件在做的时候，要克服相关的缺点。

软件做出来之后，基于我对产品的前沿性的设计。我有充分的信心和十足的把握去推动。软件要按照GPL协议，必然是要提供免费试用版。但同时，可以提供定制版，这部分可以获取利润。目前国内CFD软件的打法，都是直接推收费版软件。我觉得在没有人用的前提下，这些软件是推不出去的。可以赚些小钱，但是不会做成一个国家层面的具有影响力的工业软件。

我对这个产品具有充分的信心把它推出去。到时候只要国人用CFD，那除了商软，开源openfoam，我希望大家能想起这个。这么多年来国家一直在推国产工业软件，我国确实也有，但是没有一个让大家能说得出手。我国有些软件做的不错了，比如金山软件可以抗衡office，中望CAD可以抗衡SolidWorks。但CFD领域却没有人能说我国的xxx能与国外抗衡。我要做的，就是在这个空白的地方做出一个产品。这个软件对标的市场就是西方国家在国内售卖的CFD商业软件。

对合作方要说的：

要充分理解我做CFD软件的目的。我要做出一个最适合国内工业界的普适性CFD软件。希望真正的能让大家用起来。这建立在软件充分的“好用”的基础上。用户占有率在第一位。 也希望能认识到，免费产品未必不可盈利。如微信、抖音、快手、QQ、淘宝等。另一方面。工业软件投入的周期非常长，资本可以做一定程度的催化剂，但底层算法开发以及软件的更新迭代需要长期的坚守。

捐赠

我个人认为这个事情很难做成。主要就是缺少一个前端，普通前端的工资不低，一年30万打底。好一点的一年得更多。咱也没有这个钱一直去投入。目前尚且没有国家基金以及民间资本对这个项目进行支持。于是我决定尝试最后一条路，虽然希望也很渺茫，那就是捐赠。

我个人的想法是在最短的时间内，募集最少40万元，来支付一个前端的工资。当然在法律层面可能需要斟酌（比如一年期聘用关系？）同时，为了保证资金的透明。我这面可以做以下承诺：

2024年9月1日，捐赠达到40万元，我自己将出10万元，凑够50万元，用于第一年的业务支出（40万元用于发工资，10万元用于成立公司组办公室等杂项）。同时继续募集资金用于下一年的支出。

2024年9月1日，不足40万元。项目终止。资金退回给捐赠者。

如果在此期间中彩票拿到天使投，资金退回给捐赠者。

如果在此期间有合作方可以投人，那表明不需要额外资金招聘，资金退回给捐赠者。

捐赠期间，款项进出都将在本帖公示。

捐赠方式

如果是一些个人的捐赠，请参考下方的微信支付二维码。

如果是一些机构的捐赠。可以通过合作的方式来进行。例如，我这面有服务器售价5万元，合作方若愿意捐赠1万元，可走6万元的合同。其中差价1万元则进入本项目捐赠资金。其他的与我这面的其他项目合作都可以，如CFD项目、CFD课程之类。

也希望大家多多宣传。CFD这面我可以弄，最需要的就是一个能做事情的前端。谢谢大家。:xiexie:

资金列表 日期 机构/个人/匿名 金额 备注

这个是当我把水的物性从常数改为多项式后遇到的问题
Courant Number mean: 0.134868655 max: 0.237479859
deltaT = 3.4820232e-06
Time = 0.00378807

PIMPLE: iteration 1
MULES: Solving for alpha.gas
MULES: Solving for alpha.liquid
gas fraction, min, max = 0.00155200072 1e-15 0.0672465558
liquid fraction, min, max = 0.998447999 0.932753444 1
Phase-sum volume fraction, min, max = 1 0.999994574 1.00026614
MULES: Solving for alpha.gas
MULES: Solving for alpha.liquid
gas fraction, min, max = 0.00155951826 1e-15 0.0674835707
liquid fraction, min, max = 0.998440482 0.932516429 1
Phase-sum volume fraction, min, max = 1 0.999994794 1.00025528
MULES: Solving for alpha.gas
MULES: Solving for alpha.liquid
gas fraction, min, max = 0.00156703579 1e-15 0.0677203557
liquid fraction, min, max = 0.998432964 0.932279644 1
Phase-sum volume fraction, min, max = 1 0.999995014 1.00025493
Constructing momentum equations
Tf.gasAndLiquid: min = 350.131001, mean = 456.035361, max = 549.778465
iDmdt.gasAndLiquid: min = -0.959612341, mean = 11.8287784, max = 447.419943, integral = 0.000182163188
wDmdt.gasAndLiquid: min = 0, mean = 138.094307, max = 5727.35791, integral = 0.00212665234
smoothSolver: Solving for e.gas, Initial residual = 0.104953394, Final residual = 1.40390231e-09, No Iterations 2
smoothSolver: Solving for e.liquid, Initial residual = 0.282448508, Final residual = 6.30884149e-18, No Iterations 2
[stack trace]

#1 Foam::sigFpe::sigHandler(int) in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#2 ? in /lib/x86_64-linux-gnu/libpthread.so.0
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#4 void Foam::sqrt<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::sqrt<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#6 Foam::heatTransferModels::RanzMarshall::K(double) const in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libreactingMultiphaseSystem.so
#7 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::BlendedInterfacialModelFoam::heatTransferModel::evaluate<double, Foam::fvPatchField, Foam::volMesh, double>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > (Foam::heatTransferModel::*)(double) const, Foam::word const&, Foam::dimensionSet const&, bool, double) const in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libreactingMultiphaseSystem.so
#8 Foam::BlendedInterfacialModelFoam::heatTransferModel::K(double) const in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libreactingMultiphaseSystem.so
#9 Foam::ThermalPhaseChangePhaseSystem<Foam::PhaseTransferPhaseSystem<Foam::TwoResistanceHeatTransferPhaseSystem<Foam::MomentumTransferPhaseSystemFoam::multiphaseSystem > > >::correctInterfaceThermo() in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/lib/libreactingMultiphaseSystem.so
#10 ? in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/bin/reactingMultiphaseEulerFoam
#11 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#12 ? in /usr/lib/openfoam/openfoam2312/platforms/linux64GccDPInt32Opt/bin/reactingMultiphaseEulerFoam

想先稳态计算获得一个初始流场，可是一直不收敛，以前算其他模型稳态算个几百步就收敛了，这个模型算了4000步还没有收敛的迹象！（kw-SST模型，SIMPLEC算法）

0_1516841984913_捕获.PNG
动图1：河床沙石冲刷运动

河流的流动会改变河床的形状。底部的沙子以及大石头通常会分为两个区：

顶层的bed-load zone（有研究河海的么，这个怎么翻译？），其中的颗粒会随之移动； 底层：沙子以及石头会被困住，但是会缓慢的爬行；

在碎石较多的河床中，较大的沙石倾向于堆积在顶层，这种现象被称之为armoring。个人感觉之所以称之为armoring是因为较大的沙石趋向于在表面，类似一种武装。

实验表明，在这个区域，大沙石有一个净得向上的运动速度，小颗粒具有一个小的向下的移动速度。 目前对于这种现象的原因尚不清楚。不过现存了一些潜在的理论。例如支持程度比较高的巴西果效应（Brazil Nut Effect）。

0_1516841984913_捕获.PNG
动图2：有人晃荡大米里面的密度差不多的小石头

替代文字
动图3：进行的计算模拟

巴西果效应是指如果把两种颗粒的混合物置于容器中，然后施加外加的振荡，体积比较大的颗粒会上升到表层，而较小的颗粒会沉降到底部。关于这种古老的效应的动力学机制至今仍众说纷纭。

DEM模拟：文中作者采用LIGGGHTS对这个现象进行了模拟，下图可以看出，随着时间的推移，大颗粒漂浮出来。

0_1516841984913_捕获.PNG
图4：Nature Communication中的LIGGGHTS模拟

看起来很有意思 :cheeky:

本文来自Nature Communication