第一种方法：如果水域和空气域分开建模，则ICEM分别划分网格，分别将两个域定义成不同的流动域，交界面用interface面连接，在CFD软件中分别定义各自的属性即可，但好像交界面附近的网格需要加密，以捕捉水面的波动细节；第二种方法：如果知道水深，只建立一个流动域，在CFD软件（如fluent）中进行VOF设置的时候开启明渠造波流动模块，输入水深及水波特征也是可以的。

@桑葚熟了 这个问题是不是可以从源头上想，滑移网格是为了解决什么问题提出来的，提出来之后怎么实施的，这个过程其实包含了你提到的疑惑。
又想不用动网格变形网格，又想实现运动，那就把动的那一部分网格挖出来，不变形、整体运动，不动的保留网格，两个之间滑移运动。这有个前提，这种物体运动不需要网格变形，比如叶轮旋转，而且运动带来的影响基本局限于动的那一部分网格内，这就需要你自己判断究竟动的网格范围有多大。在这个基础上通过坐标变换实现滑移运动网格数据与不动的网格上绝对坐标系保持一致。
其次，是滑移运动这部分网格跟不动的网格交界位置怎么传递数据的问题，这也有相关的算法保证。

@胡同小巷 时间步长和时步数量是针对瞬态计算而言，一个时间步长内需要把控制方程迭代收敛，所以才有最大迭代步数问题，是指在一个瞬态迭代步内，要通过类似稳态的迭代过程把计算迭代收敛，然后整个网格或流动进入下一个瞬态时间步。比如动网格或滑移网格流动问题，一个瞬态时间步内迭代时，网格状态不动，在这个状态下计算最多20步把流动算收敛（你也可以更改这个数字），然后网格变形或旋转等等，进入下一个瞬态时间步状态，在这个状态下重新开始20步迭代计算收敛过程，依次类推。
回到你的设置，你瞬态时间步设置10000步，时间步长设置0.000001s，这都是针对瞬态过程而言，确实总的流动计算物理时长还不到1s，就是你只能看到这个流动不到1s的过程。跟每步的20次关系不大，这个每步迭代20次只是保证每一步的收敛性，总的流动物理时长就是时步数量和时间步长的乘积。
题外话，不太懂你算的这个问题是什么，但感觉流动分布很简单，时间步长这么小没必要。时间步长的确定跟你流动的实际物理复杂程度和网格有关，达到一定分辨率就行了。

@ejector 这也差的太多了，不是界面清晰不清晰的问题，怀疑两相模型用的不对

@kennyadapter 前面的大神们说的对，就是O-block的大小不合适，再就是可以在圆中间横着、竖着各切一刀，多出来的四个顶点沿横轴、纵轴往外稍微移动一下，调到合适的位置能改善一下质量。
如果边界离圆面太近不能调整，那就是计算域选的不合适。

@深蓝 除了对编程有一点要求外，就是受限于fluent本身开放的接口，UDF程序没啥限制的。题外话，发帖时间为什么比北京时间延后这么多？穿越了？还是在日本、澳大利亚，新西兰。。。呀，哈哈

@bestucan 不太懂这个，就是用google浏览器打开网页，之前都没问题，最近突然出现这种打不开的情况。

这几天突然开始出现github和gmail只能随机打开一个的情况，要么github网页加载正常了，gmail打不开了，要么就是突然gmail又能打开了，github加载不出来了。代理出现问题，如图。
关键是，github登录的验证邮箱留的是gmail的号，这俩躲猫猫让我情何以堪？？网上能查到的方法，修改“Hos..”文件，助手，DNS，注册表，驱动，能试的都试了，就是解决不了。莫非是外部原因？？脑壳疼！！

貌似是UDF并行的问题，提示中说mpt_read错误，没有发现这样的文件或者字典，是不是C++安装不完整之类造成的。

感觉这个问题是计算流体力学本身不同方向的割裂造成的，流体力学可以不十分懂算法和底层的方程原理也能把流动算出来，做算法的可以不用管具体流动应用场景，直管把方程解出来。但其实这两者是有桥梁的，粘性流体力学基础之类的相对底层一点的东西才是涵盖算法和工程的，算是个纲领。

小米14 Pro，8G内存，跑100万以内网格勉强吭哧瘪肚能整，再多就呼呼叫了，也就敲敲字刷刷剧可以，干计算还得台式机。