Fluent多相流仿真：模型选择、UDF编程与工程实践

简介：这份代码包面向使用Fluent开展多相流模拟的工程师与科研人员，系统整理VOF、Eulerian-Eulerian、Eulerian-Lagrangian三大模型的原理、适用场景与设置要点。VOF模型适合油水分离、波浪模拟等自由表面流动；Eulerian-Eulerian模型适用于流化床、混合器中的气固/液固两相流；Eulerian-Lagrangian模型则用于喷雾干燥、气力输送中颗粒或液滴追踪。包体共3个文件，以HTML页面为主体呈现完整解析内容，另附inscode配置与.gitignore文件，整体仅6KB，轻量易用。已有243人学习参考。从中可快速建立起多相流模型选型的判断框架，理解不同模型对相间动量交换、界面追踪和计算资源的差异要求；同时，内容还整理了模型选择依据，强调需结合流动特性、物理模型与计算资源综合判断，涵盖网格划分、边界条件与求解器参数设置等关键环节说明，适合初学者入门，也方便有经验者当作速查手册使用。

1. 多相流模型怎么选：三个主模型的底层逻辑

我最早接触Fluent多相流，是从一个气液两相流项目开始的。当时手头有个鼓泡塔，气泡直径、气含率、流场分布都要预测，软件里Model列表一排就是VOF、Mixture、Eulerian三项，新手很容易随便选一个就开算。但后面我吃了不少亏才发现，模型选错，后面做再多都是白费，甚至算出来看起来合理，实际上物理图景完全不对。

多相流这个名称本身容易让人误解。Fluent里这三个模型并不是“精度高低”的关系，而是“适用尺度”和“相界面处理方式”的差异。用大白话说：VOF是画界面的，Mixture是算混合场的，Eulerian是算每一种流体各自的场。

1.1 VOF模型：哪些场景必须用它

VOF模型的核心思路是，在同一个计算网格里，用相体积分数来确定每个网格里装了多少水、多少空气。体积分数是0就是纯空气，是1就是纯水，在0到1之间说明这里就是相界面。它最大的特点是把自由界面当作一个可以追踪的几何对象来处理。

所以做水坝溃决、船体兴波、液滴碰撞、射流破碎这类问题，VOF是标配选择。因为这类问题里界面形态本身就是最重要的结果，你需要看到界面怎么变形、怎么破碎、怎么合并。如果这时候用Mixture或Eulerian，你就只能得到两相各自的速度和体积分数，界面会糊成一片渐变带，根本谈不上“捕捉”。

但VOF也有它的局限。它默认所有相共享同一个速度场和压力场，也就是说，它假设每个网格内的流体虽然可能是不同相，但它们运动速度相同。这在大尺度界面问题中基本成立，可一旦遇到相间滑移明显、比如气泡在水中快速上升，同一个网格里液相上升速度是0.1m/s、气相是2m/s，VOF就表达不了这种速度差。另外VOF对网格分辨率极其敏感，界面区域的网格如果不够密，界面会严重破碎，气液之间变成一团混杂。

还有一个被很多人忽略的点：VOF虽然只有一套动量方程，但这不代表它省事。它表面张力项的曲率计算依赖界面附近二阶导数的精度，网格质量稍微差一点，就会出现寄生电流，界面会莫名抖动。我第一次做微流控液滴时，界面被拉出了很多小尖角，排查了很久才发现是网格在界面区偏斜太厉害。

1.2 Mixture模型：轻量级的“半宏观”方案

Mixture模型在工程界用得极多，因为它的计算成本比Eulerian低一个量级。它的物理假设是：各相在局部尺寸上达到平衡，相与相之间存在很小的滑移速度，可以把这个滑移用代数关系式来表达，而不是求解第二套动量方程。

做过沉淀池模拟的朋友应该比较熟悉：泥水两相用Mixture算，泥相体积分数、沉降速度、浓度分布都能出来，而且收敛速度快，不容易发散。鼓泡塔初始筛选阶段也可以用Mixture，算出来的气含率分布、流型趋势往往和实验对得上，能快速给方案定一个大方向。

但这里要特别提醒：Mixture虽然叫“多相流”，但它是一个“混合场”框架，它求解的是混合物的动量方程，再通过相对速度来反推各相分布。如果相间相对速度本身很大，那么代数滑移公式的误差就会膨胀。算旋风分离器内的颗粒，颗粒粒径到了微米级还行，如果是毫米级颗粒，Mixture模型算出来的颗粒轨迹和真实情况偏差就会相当大。

另一个经常被忽略的是Mixture模型里“液相”是由各相体积分数加权后的属性；如果你要做蒸发冷凝这类涉及传质的工况，Mixture后面挂传质模型也挺麻烦，不如直接用Eulerian或者VOF里的蒸发冷凝模型。所以我的经验是：Mixture适合“趋势型”研究，不适合“机理型”研究。

1.3 Eulerian模型：全双流体框架

Eulerian模型是我个人认为最难调、但上限最高的多相流框架。它为每一相独立求解动量方程、连续性方程，相与相之间通过交换系数（动量交换、热量交换、质量交换）耦合起来。这意味着你的曳力模型、升力模型、湍流分散力等等都要给清楚。

流化床、气力输送、液液萃取、有强相间作用的体系，基本都要上Eulerian。因为只有它能够表达“气固两相各自独立运动且相互影响”这种物理本质。做过流化床的人应该都知道，Eulerian模型调起来有多疼：几何模型容易搭，最难的是曳力模型参数、颗粒温度（granular temperature）、径向分布函数、镜面反射系数……每一个都可能导致床层膨胀高度不对。

我记得第一次做鼓泡塔的Eulerian模拟，算出来的气含率比实验值差了将近一倍。后来一个一个排查，发现问题出在两处：一是初场的体积分数初始化没设置好，二是曳力模型用了默认的Schiller-Naumann适配大粒径其实不合适。换成Grace模型之后，气含率曲线马上就贴近实验值了。这种经验不踩坑真的学不会。

1.4 选型对照表：从物理场景直接定位

综合下来，我平时给团队同事做选型建议时，基本都是按下面这张表的逻辑来判断：

还有一个朴素但重要的经验：如果不能确定用哪个，先做网格无关性验证和模型对比验证，用同一套网格分别算一遍，看关键物理量的差异。算力宽裕就用Eulerian做基准，算力不够就用Mixture做趋势筛选，VOF做界面细节分析。

2. 网格准备与求解设置里的关键细节

很多人以为多相流难在模型选择，模型选完就能一路算到底。实际上，多相流项目里至少一半的精力要花在网格和求解设置的细节上。同样的模型、同样的UDF，网格拓扑换一下，结果可能就天翻地覆。

2.1 网格质量对多相流的影响

Fluent对网格质量的通用标准是偏斜度（Skewness）低于0.85，正交质量高于0.1。但在多相流里，这个标准往往要更苛刻，尤其是VOF模型和Eulerian模型。原因很简单：多相流计算中，界面曲率、体积分数的梯度都依赖网格面上的通量计算，网格一旦畸变，通量插值就会出现非物理振荡。

我自己做自由液面的时候，一般要求界面附近区域的偏斜度低于0.7，体积变化率控制在1.2以内。六面体网格优先，因为它的通量计算是最稳定的；四面体网格虽然自动生成方便，但界面捕捉的精度下降得厉害，界面会变得又粗又抖。

多孔介质和动静区域交界处的网格也是重灾区。大家搜“多孔介质Fluent参数设定”会看到很多帖子，但真正关键的一点是：多孔介质区域网格方向要与流动方向对齐。如果多孔区域的惯性阻力系数设置合理，但网格斜向，反算出来的压降就会偏大很多。我做过一个蜂窝陶瓷载体项目，就是因为网格方向没对齐，压差比实验值高了20%以上。

2.2 表面张力、接触角与相间作用

多相流里还有一个让人头疼的参数：表面张力系数和接触角。Fluent里设置表面张力很简单，拉一个常数就行，但你要是真用常数去算微流控、喷雾、毛细现象，大概率会翻车。实际液滴在运动过程中，表面张力会受温度、表面活性剂浓度影响发生动态变化。

所以在需要精确刻画气液界面的场景里，我倾向于用UDF让表面张力随温度或组分变化。接触角方面，如果是静态接触角可以直接给数值，但动态润湿过程里接触角滞后（Contact Angle Hysteresis）是真实存在的，前进角和后退角往往差十几度。Fluent默认简化处理，不会自动考虑滞后，因此做液滴在斜面上的滚动模拟时，要自己写UDF去控制接触角。

再说到相间作用力。Eulerian模型里，动量交换的曳力系数、升力系数、虚拟质量力都要手动指定或通过UDF定义。对很多工程刚入门的朋友来说，这些力全是生面孔。我用一个生活化类比解释：曳力就像你在水里推一个球，水阻碍球运动的那股力；升力是球在水中运动时因两侧速度差产生的横向推力；虚拟质量力则是球加速时带动周围水一起加速，水产生反作用力带来的“惯性增加”效应。球越小、密度差越大，虚拟质量力的作用越明显。

2.3 求解模式与库朗数的控制

很多人在多相流计算中遇到发散，第一反应是调低松弛因子。但松弛因子不是万能药，它只是让变量更新变慢，物理本质没有变化。更关键的一步是，瞬态多相流计算中需要控制库朗数（Courant Number）。

库朗数的定义很直观：CFL = 速度 × 时间步长 / 网格尺寸。它表示在一个时间步里，流体穿过多少个网格。VOF模型里，如果CFL大于1，界面区域会产生严重的数值振荡，界面网格上的体积分数会超过1或者变成负数，计算没几步就崩了。

我做VOF的工程经验是，时间步长选取要让CFL保持在0.5以下，最好在0.2-0.4之间。Fluent里用自适应时间步长可以帮忙，把最大库朗数设置为0.5，它会自动调整时间步。Eulerian模型对CFL的需求略宽一些，但超过2也会明显影响稳定性。

还要提一个高级一点的问题：能量方程和多相流耦合时，时间尺度往往是跨数量级的。例如考虑相变的气液两相流，界面运动的时间尺度是毫秒级，而热扩散的时间尺度可能是秒级。这种情况下用全局统一时间步长，效率极低。我的做法是把能量方程和多相流方程分开做算子分裂（Operator Splitting）：先算多相流一个时间步，再冻结流场散热几个外部时间步。这个方法虽然要多写一点控制脚本，但能节省大量机时。

3. 代码实操：从UDF编写到编译调试

标题里带着“代码”两个字，那正文必须要聊透UDF的问题。很多人在搜索框里打“fluent里udf文件在哪里编辑”，这个问题的含义其实有两层：一是编辑器在哪里打开，二是UDF怎么组织。Fluent本身不自带代码编辑器，我一般用Visual Studio Code写C语言代码，再用Fluent的编译环境编译。Visual Studio Code有代码提示和高亮，比Fluent内嵌的简单文本框好用了不止一个级别。

3.1 UDF在Fluent中如何组织

UDF（User Defined Function）是Fluent开放的C语言接口，让你能自定义边界条件、源项、材料物性、相间作用力、初始化场等等。标准UDF文件的基本结构是这样的：

#include "udf.h" DEFINE_PROPERTY(water_viscosity, c, t) { real temp = C_T(c, t); return 2.414e-5 * pow(10.0, 247.8 / (temp - 140.0)); }

很多新手把udf.h当成一个普通头文件，其实它的作用远不止引入函数库。Fluent在编译UDF时，通过你include的udf.h来匹配当前版本的数据结构宏定义，所以不同版本Fluent编译UDF时，这套头文件必须与求解器版本对应。如果你用Fluent 2023 R1的udf.h去编译给Fluent 2023 R2用，大概率报出一堆莫名其妙的类型冲突。

在组织Fluent项目代码时，我习惯把不同功能的UDF拆成不同文件。比如一个文件放物性定义，一个文件放源项，一个文件放初始化宏。这样调试的时候定位问题更快，bin和lib目录也不会乱成一团。再说了，多相流的UDF联动性很强，一个宏出错往往牵一串函数，拆开文件至少能把出错范围缩小。

3.2 曳力系数自定义：一个完整可参考的示例

我觉得最值得写出来的UDF案例，是Eulerian模型里自定义曳力系数的过程。这里我用一个幂律型曳力模型来演示：

#include "udf.h" #define RHO_P 2500.0 /* 颗粒密度，kg/m3 */ #define D_P 0.0003 /* 颗粒直径，m */ #define A 0.44 /* 模型参数A */ #define B 2.65 /* 模型参数B */ DEFINE_EXCHANGE_PROPERTY(custom_drag, c, t, li, tj) { real rho_cont = C_R(c, t); /* 连续相密度 */ real mu_cont = C_MU_L(c, t); /* 连续相动力粘度 */ real slip_x = C_U(c, t) - C_U(c, tj); /* 相间滑移速度x分量 */ real slip_y = C_V(c, t) - C_V(c, tj); /* 相间滑移速度y分量 */ real slip_z = C_W(c, t) - C_W(c, tj); /* 相间滑移速度z分量 */ real slip_mag = sqrt(slip_x * slip_x + slip_y * slip_y + slip_z * slip_z); real re_p = rho_cont * slip_mag * D_P / mu_cont; /* 颗粒雷诺数 */ real cd = 0.0; real drag = 0.0; if (re_p < 1.0e-6) re_p = 1.0e-6; /* 幂律型曳力模型 */ cd = A + B / re_p; drag = 18.0 * mu_cont * cd * re_p / (24.0 * D_P * D_P); return drag; }

这个UDF里，DEFINE_EXCHANGE_PROPERTY是专门用来定义相间交换系数的宏，它和Fluent内置的相间曳力模型是同一层级的接口。函数里几个关键的细节我提一下：

第一，C_MU_L(c, t)在单相流里是层流粘度，在多相流里它取的是连续相的层流粘度，而不是混合粘度。这一点不打开Fluent的User Guide，很多照着扒代码的人是看不出来的。

第二，颗粒雷诺数趋近于零时，公式中B/re_p会爆炸。所以我对re_p做了一个下限裁剪（clip），这个操作在实际工程中非常重要，因为迭代初期的流场往往极不物理，滑移速度接近零的情况很常见。

第三，曳力系数的量纲和单位。DEFINE_EXCHANGE_PROPERTY返回的交换系数在Fluent中被用来乘相间滑移速度、再乘相的体积分数，从而组成动量交换源项。它的单位是kg/(m3·s)。如果量纲给错了，计算机会报units mismatch或者干脆不收敛。我见过不少朋友在这里栽跟头，算出来流化床颗粒全部飘到顶上去，原因就是曳力返回量级差了三个数量级。

3.3 编译运行中的常见坑

UDF编译报错是家常便饭，最典型的几类问题：

环境变量缺失导致编译器无法识别。Windows下Fluent需要识别Visual Studio的C编译器，如果报“Error: Unable to locate compiler”，多半是环境变量没有配置。解决方案是打开Fluent后，File → Solution → Environment里检查，或者直接用Fluent自带的Compile UDF命令，让它自动探测。

宏参数写错。比如DEFINE_PROPERTY和DEFINE_EXCHANGE_PROPERTY的参数列表完全不同，前者是(name, c, t)，后者是(name, c, t, li, tj)。我见过很多代码，第一步就把宏头写错，编译器根本不会提示你宏参数对不对，而是直接爆出一堆typedef类型不匹配的报错。这种报错很具有迷惑性，因为你按报错去找，往往以为是某个结构体定义错了。

还有一个很隐蔽的坑：Fluent的并行计算对UDF代码有特殊要求。如果你的UDF里有全局变量或static变量，在并行分区计算时，这些变量在每个计算节点上都是独立副本，无法跨节点通信。我在做大规模气液两相流时遇到过弱收敛，无论怎么调都差一口气，最后排查发现是UDF里用了static变量累计了质量通量，而并行节点不共享这个变量，残差就永远停在一个小值附近。

4. 从计算发散到结果可信：常见问题排查实录

最好写也最实用的部分，应该是问题排查。我这些年做多相流仿真，九成的时间不是在“算”，而是在“救”那些算不动的模型。下面把几个高频问题整理成表格，按现场排查的思路讲一遍。

4.1 收敛困难：残差、通量与质量守恒

多相流不发散的少，一发散就是大动静。残差曲线冲到1e10，那基本可以判定是某个源项或者交换系数出问题了。

第一排查项不是松弛因子，而是欠松弛因子初始化。很多发散问题在迭代的第三到第五步就开始酝酿了，这时候看云图会发现某个区域的压力出现非物理的负值。负压一般都和初始化场不合理有关：比如Eulerian模型里，第二相体积分数初始值为0，但速度场非零，动量方程里就出现了“除以零”效应。我处理这类问题的办法是，把第二相体积分数初始化成一个极小值，比如1e-6，而不是0，然后打开体积分数方程的Quadratic Upwind插值。

第二排查项是有限体积法里的通量限制。多相流里体积分数必须严格保持在0到1之间，任何数值弥散造成越界，都会连锁产生负密度、负粘度。在Fluent中，直接调Limited格式能让体积分数的越界变少，但代价是界面被抹得更平。如果计算本身对界面精度要求不高，这是一笔划算的买卖。

第三排查项是质量守恒。很多看似“收敛”的计算，实际上全场质量平衡有10%以上的误差。检查方法很简单：Report → Fluxes里看进口和出口的净通量，再看Graphics里某截面的速度分布是否光滑。如果进口出口差了10%以上，说明缺陷在边界条件或者网格质量，残差再低也不能作为收敛依据。

4.2 “孤儿网格”和梯度警告

搜过“fluent孤儿网格”的朋友，大概率都在报错日志里见到过类似的警告：Warning: orphan faces, cells, or nodes were detected。孤儿网格的意思是，网格拓扑中存在一些单元格或节点，和周围网格没有正确的连接关系，导致求解器在处理通量时把它们孤立出来了。

导致孤儿网格的原因主要有三种：一是从其他网格软件导出时格式转换出错，二是Fluent里的网格重排序或重构操作不当，三是TUI命令手工删除了某些网格实体但关联关系没有更新。处理时我会先用Mesh → Check看诊断信息，如果确认有孤儿网格，最稳妥的方法是重新导入原始网格导出文件，或者用Separate和Merge修复部分缝隙。如果网格拓扑破损严重，重新划分比手动修要快得多。

梯度和多相流的组合还有一个很多人不知道的坑：默认的Green-Gauss Node-Based梯度重构在界面附近会出现振荡，因为界面区域的体积分数梯度非常大，而线性重构假设是光滑的。我在VOF计算中，会优先使用Least Squares Cell-Based梯度，它对网格畸变和多相界面更鲁棒。曾经一个算例用Node-Based梯度连发散三次，改成Least Squares后直接平稳收敛到目标残差。

4.3 结果可信度检查

计算收敛之后，不代表结果就可靠。我做项目验证时从来不看残差这一个指标，而是看三件事：物理合理性、网格无关性、和实验或经验公式的对比。

物理合理性是最快的筛子。你把速度矢量图打开，看看有没有局部回流和漩涡遍地方向都不对；把压力云图打开，看看压降趋势是否符合常识。多相流里要特别看体积分数云图，如果相同位置出现“水中有气泡、气泡里有水”这样的穿甲现象，说明界面已经糊了，结果不可用。

网格无关性检验在什么时候做？应该是在你最终确定几何和物理模型之后，而不是在方案还没定的时候就做。至少用三套网格：粗、中、细。如果关键物理量，比如某个截面的平均气含率，在中等网格和细网格之间变化小于5%，那么中等网格就可以接受。如果始终不稳定，很可能不是网格问题，而是物理模型本身选择有误。

实验对比是最硬核的验证方式。没有实验数据时，退而求其次和经验公式对比。气液两相流中用得非常多的漂移通量模型，或者流化床里最小流化速度的经验关联式，都能做参考基准。但要注意经验公式的适用范围往往很窄，比如只适用于某个粒径范围或某个雷诺数范围，不能直接套到所有工况上。

5. 多相流仿真的算力与资源调度心得

写到这里发现UDF和多相流模型还可以结合一个现实问题聊：算力。多相流仿真的计算开销远高于单相流，尤其Eulerian模型，相数越多、网格越密，内存和CPU时间的消耗都是几何级增长。这篇博文主要是技术解析，这部分就当个人经验补充来聊了。

我自己的一个经验准则是：VOF模型用单个工作站算两百万网格的瞬态问题是可以接受的；Mixture模型可以再翻一倍网格量；Eulerian模型则不要轻易超过三百万网格，除非你的机器内存足够大。Eulerian模型里面每增加一相，每个额外相都要多一套动量方程和连续性方程，内存占用会线性增加，而且相间耦合矩阵会让线性方程组的迭代次数剧增，CPU开销增长远超线性。

并行计算的进程数也要斟酌。Fluent的并行对多相流没有单相流那么友好，因为界面区域和相间耦合引入了更多的通信量。我从实践中总结出来的经验是：先跑几十个迭代步记录单步耗时，然后逐渐增加进程数，找到拐点。比如四核性价比最高，八核提升并不明显，那就别浪费核数。

如果项目对周期敏感，我通常建议先做一版Li代模型（比如用Mixture替代Eulerian）跑通整个流程逻辑，拿到近似的流场趋势，再针对重点区域换高保真模型重算。这种方法在方案阶段特别管用，能省下至少一半的试错时间。

最后再分享一个小细节：多相流的自动保存频率一定要高。Eulerian模型调参的时候，经常是算了一百步之后突然发散，如果数据保存间隔太长，发散前的流场全都丢了。我习惯每200步保存一次数据文件，UDF调试阶段每50步就存一次，看起来多占点磁盘，其实换来的是反复迭代调参的安心。这种经验都是踩过坑才有的。

本文还有配套的精品资源，点击获取