@Prometheus10
我看了一下那个帖子,可能因为实现方法的差异,两种边界会有细微的差别,但应该不会这么大。
你的其他边界是怎么设置的?symmetry不用特别设置,每一个变量都是sym就行。但是,slip你是具体怎么设置的?速度肯定是slip,其他边界是什么?如果搭配不合适的话,和sym不一致是很正常的事情。
再一个,是不是因为雷诺数特别小,以致实现方法带来的微小区别被放大了?或者说,在低雷诺数下,实现方法带来的差异特别大?建议可以加点流速试试,看一下高流速下是不是还差这么多?
@Prometheus10
我看了一下那个帖子,可能因为实现方法的差异,两种边界会有细微的差别,但应该不会这么大。
你的其他边界是怎么设置的?symmetry不用特别设置,每一个变量都是sym就行。但是,slip你是具体怎么设置的?速度肯定是slip,其他边界是什么?如果搭配不合适的话,和sym不一致是很正常的事情。
再一个,是不是因为雷诺数特别小,以致实现方法带来的微小区别被放大了?或者说,在低雷诺数下,实现方法带来的差异特别大?建议可以加点流速试试,看一下高流速下是不是还差这么多?
那我理解的话,就是矢量是slip,标量是零梯,然后你要设置的值是fixedValue,然后constant/polyMesh/boundary里可以设成wall?
2206是可以用的,是不是constant下边没有g?或者g文件里缺什么东西?
请搜索turbinesFoam,我没用过,但是我师弟用过,结果还可以
可以,请查找mapFields命令
@funky番 没有解决,至少在基金会的框架下到of10都没解决,即使of10宣称可以搞纯波浪,照样没戏。
替代方案是用ESI的版本,我现在做纯波浪的算例,比如说越浪,就用of2112,挺好用。但也有问题,就是越浪之后入口平均水位会倾向保持不变,也就是说没有水的出口的话,计算域内的水会越来越多。在海工上问题不大,但重现实验如果水槽不大越浪很强可能会有问题。
如果要在纯波浪和波流耦合之间切换的话,我现在是用基金会版本加载olaflow的库取代掉controlDict里的libwaves,然后用边界不用求解器,现在看上去还行。
我可能知道是哪里的问题了,在interfaceHeight中会有一个插值的操作:
autoPtr<interpolation<scalar>>
interpolator
(
interpolation<scalar>::New(interpolationScheme_, alpha)
);
(OpenFOAM 10 interfaceHeight 的完整代码参见这里,其他版本的也都有这个过程)
这好像是一个对全局进行插值的操作,也就是说,每次需要对一个点的水位(或者浪高)进行计算的时候都会进行一次全局alpha的插值。而且,同一个function下的不同点也是要分别进行插值而不是共用一个插值结果,然后就会特别慢。
比较快的解决方法是用sample代替interfaceHeight,输出一条或若干条与重力方向平行的线上的alpha的值,然后计算完成后编程处理得到水位随时间的变化。推荐使用这一个现成的python代码,计算中输出基本不占时间,后处理也很快,和interfaceHeight得到的数据几乎完全一致,至少画成折线图看不出区别,完全重合了。
这个代码可能是ESI推荐的方法,因为不同于基金会版本的波浪模拟中使用interfaceHeight,ESI波浪模拟中使用的就是sample。但是需要注意的是,可能是因为版本变化或function的具体设置问题,这个代码在处理.xy文件时在分割列时会出错(报错是在49行,报错原因时列数越界),需要把第46行delimiter="\t"修改成delimiter="\s+"。
使用OpenFOAM进行波浪相关的模拟时,可以在controlDict中加入interfaceHeight函数用于监测指定点的水位。但是,我在实际操作的时候,发现这个函数执行的很慢,执行这个函数的所需要的时间超过甚至远远超过计算本身的时间,如下:
Courant Number mean: 0.0145703 max: 0.124671
Interface Courant Number mean: 0.000203796 max: 0.0781427
Time = 0.008s
smoothSolver: Solving for alpha.water, Initial residual = 0.000118531, Final residual = 7.40804e-08, No Iterations 2
Phase-1 volume fraction = 0.374025 Min(alpha.water) = -8.12552e-19 Max(alpha.water) = 1.00006
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.374025 Min(alpha.water) = -8.12552e-19 Max(alpha.water) = 1.00006
GAMGPCG: Solving for p_rgh, Initial residual = 0.00868385, Final residual = 2.67972e-08, No Iterations 4
time step continuity errors : sum local = 4.14175e-08, global = 2.02918e-10, cumulative = -1.12194e-10
GAMGPCG: Solving for p_rgh, Initial residual = 1.29705e-06, Final residual = 2.96176e-08, No Iterations 2
time step continuity errors : sum local = 4.57363e-08, global = -1.53322e-10, cumulative = -2.65516e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.67786e-08, Final residual = 6.96381e-09, No Iterations 1
time step continuity errors : sum local = 1.07541e-08, global = -5.90717e-12, cumulative = -2.71423e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.86536e-09, Final residual = 6.86536e-09, No Iterations 0
time step continuity errors : sum local = 1.06021e-08, global = -3.32298e-12, cumulative = -2.74746e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.89503e-09, Final residual = 6.89503e-09, No Iterations 0
time step continuity errors : sum local = 1.06479e-08, global = -3.29207e-12, cumulative = -2.78038e-10
smoothSolver: Solving for omega, Initial residual = 7.42141e-05, Final residual = 6.82499e-14, No Iterations 2
smoothSolver: Solving for k, Initial residual = 0.0516569, Final residual = 7.73297e-11, No Iterations 2
ExecutionTime = 6.89933 s ClockTime = 7 s
Courant Number mean: 0.0143844 max: 0.161192
Interface Courant Number mean: 0.000206902 max: 0.0959385
Time = 0.01s
smoothSolver: Solving for alpha.water, Initial residual = 0.000116747, Final residual = 7.13809e-08, No Iterations 2
Phase-1 volume fraction = 0.374029 Min(alpha.water) = -7.96187e-19 Max(alpha.water) = 1.00006
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.374029 Min(alpha.water) = -7.96187e-19 Max(alpha.water) = 1.00005
GAMGPCG: Solving for p_rgh, Initial residual = 0.00847643, Final residual = 2.22443e-08, No Iterations 4
time step continuity errors : sum local = 3.41315e-08, global = 7.51256e-11, cumulative = -2.02913e-10
GAMGPCG: Solving for p_rgh, Initial residual = 1.13271e-06, Final residual = 2.23769e-08, No Iterations 2
time step continuity errors : sum local = 3.42998e-08, global = -1.07007e-10, cumulative = -3.0992e-10
GAMGPCG: Solving for p_rgh, Initial residual = 5.84797e-08, Final residual = 6.46225e-09, No Iterations 1
time step continuity errors : sum local = 9.90576e-09, global = -7.74622e-12, cumulative = -3.17666e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.54525e-09, Final residual = 6.54525e-09, No Iterations 0
time step continuity errors : sum local = 1.0033e-08, global = -5.40963e-12, cumulative = -3.23076e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.63002e-09, Final residual = 6.63002e-09, No Iterations 0
time step continuity errors : sum local = 1.01629e-08, global = -5.3822e-12, cumulative = -3.28458e-10
smoothSolver: Solving for omega, Initial residual = 7.40885e-05, Final residual = 6.80869e-14, No Iterations 2
smoothSolver: Solving for k, Initial residual = 0.0380602, Final residual = 5.72495e-11, No Iterations 2
ExecutionTime = 7.1329 s ClockTime = 7 s
Courant Number mean: 0.0142562 max: 0.195744
Interface Courant Number mean: 0.000209995 max: 0.11138
Time = 0.012s
smoothSolver: Solving for alpha.water, Initial residual = 0.000115473, Final residual = 6.95493e-08, No Iterations 2
Phase-1 volume fraction = 0.374034 Min(alpha.water) = -7.82009e-19 Max(alpha.water) = 1.00005
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.374034 Min(alpha.water) = -7.82009e-19 Max(alpha.water) = 1.00005
GAMGPCG: Solving for p_rgh, Initial residual = 0.00833594, Final residual = 2.20133e-08, No Iterations 4
time step continuity errors : sum local = 3.35881e-08, global = 6.65894e-11, cumulative = -2.61868e-10
GAMGPCG: Solving for p_rgh, Initial residual = 1.03929e-06, Final residual = 1.72629e-08, No Iterations 2
time step continuity errors : sum local = 2.63105e-08, global = -8.49734e-11, cumulative = -3.46842e-10
GAMGPCG: Solving for p_rgh, Initial residual = 5.45841e-08, Final residual = 6.2677e-09, No Iterations 1
time step continuity errors : sum local = 9.55294e-09, global = -8.59065e-12, cumulative = -3.55433e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.57944e-09, Final residual = 6.57944e-09, No Iterations 0
time step continuity errors : sum local = 1.00281e-08, global = -6.37149e-12, cumulative = -3.61804e-10
GAMGPCG: Solving for p_rgh, Initial residual = 6.73188e-09, Final residual = 6.73188e-09, No Iterations 0
time step continuity errors : sum local = 1.02604e-08, global = -6.34536e-12, cumulative = -3.68149e-10
smoothSolver: Solving for omega, Initial residual = 7.39683e-05, Final residual = 6.82984e-14, No Iterations 2
smoothSolver: Solving for k, Initial residual = 0.0301565, Final residual = 4.5122e-11, No Iterations 2
ExecutionTime = 12.7735 s ClockTime = 13 s
0.008秒计算结束后没有写出,0.01秒后有interfaceHeight的写出,然后可以看到ClockTime的差值有明显区别,输出12个点的波高的时间远超计算一步的时间。
目前OpenFOAM 6/8/10和OpenFOAM v2106、2112都有这个现象,修改interfaceHeight的插值方法基本没有影响,同样的修改分块方式也没有。结构网格和非结构网格的输出速度有不显著的差异,结构网格好像会快一点,但没快到哪里去。
有大佬知道是为什么吗?或者如果想加快速度有什么办法或者替代的函数吗?
CPU型号:AMD EPYC 7R32 * 2
系统:linux系统(Linux Mint 19.3)
OpenFOAM版本:OpenFOAM-4.1
96 51.88
64 46.01
48 49.18
32 50.66
24 71.13
16 100.18
8 132.13
4 246.73
2 512.69
1 1086.38
7R32是48核96线程,开超线程可以到192,但跑的时候会报错,所以只到96核,反正按照经验超线程在这里没什么用处。
4.1版本需要把源项fvOptions改一下才能用。
@leilei 加水深等于加波长,还是降低波陡。问题在于要和实验对照,参数是定死的。
@卡洛 这个我看到过,OpenFOAM v2106和之后的版本已经转正为内置模型了,但是效果也没有那么明显,至少在这个问题上没这么明显。
@leilei 也确实有这种可能性,但那样的话基本上就是VOF模型和interFoam本身的问题了。
另一个问题是,来的“早”的这个“早”,是指哪个指标呢?因为相同或更大的波高/波陡/波高水深比我都试过,在比较长的周期,比如1.8或者2.0上就没有问题。
@leilei 可以确认不是破碎,波陡和波高水深比都到不了破碎的地步,开paraFoam看波面也是一个逐渐衰减的过程,没有破碎。关键是,实验可以做到最小周期比这还要小,也可以造出来。
我目前正在做波浪模拟相关的模拟,在模拟中我发现OpenFOAM v2106在使用interFoam模拟波浪时,短周期波浪的波高衰减非常严重,在离造波边界约5倍波长的位置波高衰减了至少一半,有人遇到过这种情况吗?
模拟的波浪为StokesI,也就是线性波,但是会有变形;水深在0.68 m和0.8 m之间,波高为0.08 m到0.16 m;严重衰减的波浪周期在1.0 s到1.5 s之间。湍流模型为k-Omega SST(包括可变密度的版本),关闭动量预测,时间格式为Crank-Nicolson (value = 0.9)。造波方法为速度边界造波,对应U的边界为waveVelocity,alpha.water的边界为waveAlpha,在另一侧边界设置消波。时间步长控制在1/1000周期一下,小范围波动不影响结果;x方向网格控制在1/100波长以下,y方向静水位附近网格控制在1/16波高以下。
现在的问题是,造波边界造出来的波形基本上对的上,但是短周期的波衰减过快。当波周期增大时,这种衰减就会相对减少,在2 s左右就和实验对的差不多了。我知道OpenFOAM不太能处理波陡0.05以上的波浪,但通过降低波高减小波陡后并没有很显著的改善。我也看到过文献说OpenFOAM自带的湍流模型没有考虑交界面附近的密度变化导致湍流被高估,但OpenFOAM v2106已经植入了文献作者提供的变密度湍流模型,也没有明显改善。同时,加密网格、降低时间步长、更换离散格式和增加nCorrectors的数量都不适用。
有没有大神遇到过这种情况?如果有,是怎么解决的?
@yu_tian 我去翻了一下代码,CofG是指重力中心,不是很明白这个参数的意义,如果这个值不能代指旋转中心,也就是6里的origin的话,那就是旋转轴必须通过原点。需要你再确认一下。
@yu_tian CofG是指旋转中心吗?如果是的话,下边那个radialVelocity指的转速需要给定绕三个轴旋转的速度,(0 0 360)就是指绕x轴转速为0,绕y轴转速为0,绕z轴转速为360,归一化之后旋转方向就是(0 0 1),就是。如果你要改旋转轴,就要同时改旋转中心和转速,转速归一化之后就是旋转方向,加上旋转中心就是旋转轴。
@李东岳 不只是从4.1到8,5和6我也试过,感觉就是alpha的上界越界越来越严重,但也不是所有类似算例都跑不了。和波浪没关系,测试的时候是没有波浪的。现在我倒是找到办法了,就是继续降低pcorr的tolerance,从-7降到-10或者-11,然后nCorrector继续加,总是能收敛的。只要是收敛了,结果差的就很有限。只是计算资源消耗更厉害。
目前我主要是用4.1来模拟潮流能水轮机,考虑自由表面,总体上稳定性还行,不太需要专门考虑收敛性的问题。少数情况下有问题的话,调一下pcorr的收敛条件就行,还不行的话加一下nCorrectors,或者略微改一下网格,重新生成一下就行。
但是最近要考虑波浪,于是换成了8,但是在4.1上可以收敛的算例放在8上就收敛不了,而且不能通过过去在4.1上有效的手段改善。然后我又试了一下5和6,发现在一些情况下可以收敛,但是需要调整,比如使用更小的时间步。
我查了一下OpenFOAM.org上的更新说明,发现了几乎每个版本更新都有对MULES的修正或者改进。然后我就试了一下调一下MULES的设置,发现计算过程中确实有差别,但是最终还是会发散。
另外还有两个很奇怪的问题,或者也可能是一个问题的两种反映。一个是基本无论怎么调参数,发散的时间都差不多,基本上是转子转完一圈就开始出现明显不正常的交界面库朗数上升,或者alpha的下界向负数快速增大。另一个问题是,我把4.1中算了一定时间的数据用mapFields导进8的算例里作为初始值,在降低时间步长之后是可以稳定计算的,而且alpha下界越界不大,上界基本不会越界。
我很好奇的是,OpenFOAM中多相流求解器的稳定性是随版本更新逐渐降低的吗,或者至少是在存在逆压梯度和分离流的情况下是否是逐渐降低的?
@oitocfd 不是有小问题,而是我没有试,一般我要解决的问题用SST就行了,不用考虑其他的
@oitocfd 可以直接上SST算
@李东岳 应该不是,关闭所有CFD中文网网页后在重新打开,此时没有手动操作但显示在线(也就是上次勾选了保持登录状态),试图发帖,无论试几次,无论第几次,都会显示这个Forbidden。
发帖的时候右下角会出现Forbidden,然后发不了,可通过重新登陆解决,希望改进一下。
这个帖子其实包括两个问题,首先是OpenFOAM自带的的波浪边界是否支持纯波浪。目前我基本没有头绪,可以确定的是波可以造出来,但波形完全不对,Airy波,二阶和五阶Stokes都不行。
然后是波浪衰减,我已经基本搞明白了改哪些参数有用了。第一个是fvSchemes里的ddt,一般默认是Euler,波浪这里最好改成Crank-Nicolson,也就是算例waves里的设置。这样的话时间步长在1/250波浪周期就有不错的结果(看趋势或许更长也可以,但我没试),如果用Euler可能要1/1000以下才行。我上边贴了一篇论文,里边有详细的比较。Value的话0.9就行,再高提升有限而且不稳定。
第二个是我波浪参数有问题,要么是波高太大,要么是波陡太大,总之增大波长或者降低波高(交界处网格尺寸不变)都能有效改善衰减,可能是因为这个波浪参数非线性太强。同时,将Airy波(一阶波)改成Stokes波也会有明显改善,但二阶波和五阶波差别不大。
现在的话,水深和波长不变,波高降到2.4,改用Stokes二阶波和Crank-Nicolson,连波流耦合导致的波浪变形一起算上,波高衰减不超过3%,已经能用了。
而且,如果用outletPhaseMeanVelocity做出口边界,用不用消波好像没区别。
@oitocfd 非常感谢,这个问题我已经解决了波高衰减的那一部分,但是纯波浪那部分还没头绪。
放个阶段性不完全的解决方案,参考这里,我从头到尾就没想到ddt在波浪模拟上会有这么大的影响。
@卡洛 在 OpenFOAM 8中的波浪边界是否支持纯波浪? 中说:
我没用过of8波流耦合,我用过1912自带的造波,waves2Foam,olaFlow都测试过上面说的湍流模型没问题
非常感谢,我试了以下,发现这个模型不是很稳定。原来用kOmega SST可以算的,改用kOmegaSSTbuoyang后很快就发散了。我在paraFoam里看了一下,主要是波峰前方的波面上出现了过高的k。你碰到过这种情况吗?
OpenFOAM 8 自带波浪边界是waveVelocity,支持波流耦合,我现在模拟的波浪波长54 m,波高3 m,水深30 m,周期约5 s,流速2 m/s。模拟的时候发现波高衰减比较严重,所以想试试纯波浪,排除一下流的影响看看波高衰减情况。但是在模拟的时候,流速设为0之后边界附近的波形就很奇怪,明显和设定不符。所以我想问一下,OpenFOAM 8的波浪边界是否支持纯波浪?或者是我设置有问题?又或者纯波浪的时候设置与波流耦合时有区别?
还有一个问题是,波流耦合的时候,计算域内水位会出现异常上升,自带的wave算例也存在这个现象,想问一下除了把出口流速设大一点,还有什么处理方法吗?
用paraview也可以做:
首先是读取数据,只读那个面上的数据,或者说在mesh parts里只选那个面。可能用提取面也能做,我没试过。
然后用slice,把你要的那一圈切出来。
接着用plotonsortedline在paraview里生成曲线图。
最后用file里的save data把数据保存,一般来说包括你要的压力或者其他数据,和对应点的xyz坐标。
我用这个方法做水轮机叶片的压力分布是没问题。
手头算例都太大,放一个简单的导流罩内壁的压力分布,道理是一样的。
@李东岳 这个forces是写在controlDict/functions里的,在求解过程中每个(或每若干个)时间步输出一次。这个压力和转矩是随时间变化的,不是根据结果文件用postProcessor -func那一套程序得到的。所以修改结果文件的文件名应该没什么用处?
一般情况下forces是输出基于p的压力,也就是说在二相流里考虑了浮力或者说水的重力的影响,现在我想得到不包含浮力的结果,又不想使用其他间接的方法,请问forces能否输出基于p_rgh的压力和转矩?
凹凸不平的表面要做出流线可以参考这里,是关于机翼表面的流线的。如果想要流线更漂亮一点,可能需要结合surfaceLIC使用。
但这是对于平动的表面,对于旋转的表面可能更复杂一些。不过如果只要方向的话,可以省略掉calculator那一步,这样的话就没有太大区别了。
而且实际上这里的流线反映的是剪切应力的方向和大小,虽然对于刚体的表面,剪切应力的方向和相对流速的方向应该是一致的。但问题在于,我不确定在表面边界条件一致的情况下,剪切应力的大小是否和相对速度成正比,特别是在曲面上。
@Joann 我先抛个砖,你的第一个问题应该是因为在fvSchemes里定义ddt的时候使用了localEular,而不是平常用的Eular。我理解的localEular就是在不同的区域根据网格尺寸使用不同的时间步长,所以不会有全局的库朗数输出,但会有最大最小时间步长输出。
@bestucan 我决定直接放图上去了,不用GCI了,主要是因为GCI到底应该限制在多少以下没有定论,同时GCI也需要求解结果满足单调性,偏偏我这个满足不了……
关于第二张图的画法,关键是使用calculator把叶片对应截面的速度加进去。加进去的速度与叶片对应截面速度大小相同,方向相反。然后就是SurfaceVector+StreamTracer。
比较麻烦的是,因为叶片吸力面后方出现了分离(如果没有分离也没必要画这个),所以需要多个Line Source才能把吸力面后缘附近的流线画出来。因此需要多个StreamTracer,就会造成叶片附近一部分流线过密,调起来比较烦,不过也能看。
下图是画图时候的pipeline browser:
StreamTracer1+StreamTracer2-5是一种画法,Line Source是相互平行的,如下图,下图中白色实线是StreamTracer1的Line Source:
StreamTracer1+StreamTracer6是另一种画法,Line Source是接近垂直的,如下图,白色实线是StreamTracer6的Line Source:
严格意义上Slice截面应该与叶片轴线垂直,但这里差的不多,也不准备拿来发论文,所以直接按垂直z轴算的,会有一些误差。
@cresendo 能详细说一下吗?第二张图那种流线我已经搞明白怎么画了,但第一张还是毫无头绪。
对于旋转的叶片,如下图所示的叶片表面流线是否可以使用paraFoam生成?
对于旋转的叶片,下图这种考虑旋转速度的2D流线是否可以使用paraFoam生成?
我可以做到对2D面生成流线,但如果不考虑旋转,生成出来的流线如下图,基本看不出多少有意义的信息。
除最后一张,以上图片均取自岳一轩. 叶片翼刀对水平轴风力机气动性能的影响[D]. 兰州: 兰州理工大学, 2020.
时间步长会显著影响计算的精度,但是不知道是我看论文不仔细,我发现很多做潮流能的数值模拟的文章,包括期刊和学位论文,都没有对时间步长对模拟的影响进行说明。
对于网格的独立性,有GCI这个参数可以进行描述,我想知道的是对于时间步长是否有类似的参数可以描述其独立性或者收敛性。
同时,GCI在哪个范围内可以认为达成网格无关?我看的论文中基本都只给了计算出的GCI,然后说满足独立性、无关性或者收敛性,但没说大致在那个范围才算满足要求?
确实有很大改善,可能上方空气部分需要设置一个比较大的高度
@东岳 用interDyMFoam算潮流能水轮机,没有仔细看,计算速度大概有不到10%的提高
这个情况有点眼熟,我在模拟水轮机的时候出现过推力系数和功率系数剧烈波动但时均值差的不多的情况,用的是interDyMFoam,可能有一定的相通性,你可以拿来参考一下。
我使用的解决方法有两个半:
1.修改fvSolution中pimple下的nCorrector,默认好像都是2,改成3会好不少。
2.修改fvSolution中solvers下的p_rghFinal从GAMG改成下边这个:
p_rghFinal
{
solver PCG;
preconditioner
{
preconditioner GAMG;
tolerance 1e-8;
relTol 0;
nVcycles 2;
smoother DICGaussSeidel;
nPreSweeps 2;
}
tolerance 1e-8;
relTol 0;
maxIter 20;
}
情况有很大改善。
剩下的半个是提高并行线程数,从32提高到64会有明显改善,我也不知道为什么。
其他的比如提高网格质量,减小时间步你估计都试过,就不说了,也不一定有用。
祝好运
目前我正在模拟一个水槽,用于为下一步模拟提供初始流场。但我现在碰到一个问题,就是大气边界如何设置。我目前的设置如下:
二相流的体积分数如下:
没什么问题。
但是速度就比较奇怪:
水面以上空气部分的速度分布很奇怪,呈现一种周期性的变化。
而且湍流动能也有问题:
空气的进入在水面附近引起了强烈的湍流,而且逐渐向底部扩散。
我想问的是,一般大家在模拟水槽或者其他明渠流动的时候,大气边界怎么设置?是否也会出现上图这种情况?或者说,我的边界设置没有问题,但空气区域太小了?
@bestucan 头文件里说的是如果非保守通量( non-conservative fluxes,应该是翻译成非保守通量吧?)对算法的预测部分有影响的话是需要correctPhi的,但是什么情况下会影响,我完全没有概念。至于后半说多相流的部分,4.1多相流里不开correctPhi的还是有几个的。所以我完全没提取出什么有效信息。
@桎梏 我主要是担心在不同工况下correctPhi对模拟结果的影响不同。 虽然都是水轮机,但是具体结构和尺寸的不同可能对correctPhi有不同的要求。而且,alpha.water的有界性在我模拟不加水轮机的背景流场好像受correctPhi影响比较大,但是之前的算例被不小心覆盖掉了,记不太清了,回头我再试试看。
correctPhi是fvSolution中用于修正通量的一个选项,根据一些资料,在多相流和动网格求解中是比较有意义的,建议开启。但是我查了一下OpenFOAM4.1自带的算例,interFoam/ras下的6个算例都没有开这个选项(如果默认是关闭/false/no的话),interDyMFoam和pimpleDyMFoam下有开启的也有关闭的。
关闭correctPhi的算例的共同点是没有进出口,和外界没有质量的交换,不清楚这是不是决定correctPhi是否开启的关键。
我用自己的算例试了一下,关闭correctPhi模拟了一个潮流能水轮机,结果显示功率系数和推力系数的时均值变化不大(38.74%vs38.51%,34.75%vs94.24%)。但这个变化比修改pcorr/p_rgh求解器、renumberMesh和提高网格质量带来的变化都大,不太好说适不适合直接忽略掉。
有资料说correctPhi有助于体积分数的有界,根据我自己的模拟结果来看确实有影响。在开启的时候,alpha.water最小值大概是-1e-6到-1e-14的样子,最大值是1。关闭之后,最小值变化不明显,最大值可以到1.009的样子,看上去确实可以确保有界,但意义有限。
我想知道的是,在什么样的工况下,correctPhi是必须开启的,或者推荐开启的。毕竟计算pcorr也费时间,去掉的话,每个时间步(需要7~8秒)可以省下1秒时间,计算效率提高显著。
根据我现在测试的结果,上文中提到的两种无厚度面在checkMesh中出现的warning均不影响计算进行,很可能不影响计算的收敛性,几乎不影响计算结果的可靠性/准确性。
因为我是在用一个如果使用Fluent转换自ICEM非结构网格的多面体网格计算会在一段时间后无法收敛的算例做测试,所以结论中使用了“很可能”和“几乎”。本算例可以收敛,除pcorr迭代步数大了一点外其他各项与 相似算例(使用六面体-三棱柱混合网格)没有显著区别。结算结果与相似算例和BEM计算比较可以认为相差很小。
我现在正在使用Fluent Meshing为OpenFOAM生成多面体网格,外观如下
内部如下,中间那个绿色的薄片状的是一个无厚度面,用于辅助提高边界层在尖锐角上的质量。没有这个面的话,尖锐角两侧边界层会合并到一起,质量非常差。
现在我在Fluent Meshing生成了网格,生成后把中间的无厚度面设置成interior,检测完没有问题,skewness大概不到0.5。
然后用fluent3DMeshtoFoam命令导入OpenFOAM,中间有一个warning说有一个面未识别,如下,这种情况我碰到过,只要checkMesh没问题就可以用。
CellGroup: 244 start: 0 end: 143971 type: 1
Zone: 244 name: try5 type: fluid. Reading zone data...done.
Zone: 243 name: interior-243 type: interior. Reading zone data...done.
Zone: 3 name: structure type: wall. Reading zone data...done.
Zone: 4 name: interior type: interior. Reading zone data...done.
Zone: 2 name: wall type: wall. Reading zone data...done.
--> FOAM Warning : Found unknown block of type: "73"
on line 1692342
然后checkMesh提示如下
Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
<<Found 65 neighbouring cells with multiple inbetween faces.
Upper triangular ordering OK.
<<Writing 130 unordered faces to set upperTriangularFace
Face vertices OK.
Number of regions: 1 (OK).
这个问题大概是在如下图绿色部分位置,也就是原无厚度面的边缘
我认为问题是如下图,从侧面看出现了类似悬挂节点的网格
不过奇怪的是,如果不把中间的无厚度面设成interior,而是保持默认wall的话,checkMesh的checking topology是正常的,但Checking patch topology for multiply connected surfaces出现了warning如下
Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
wall 22556 43847 ok (non-closed singly connected)
interior 920 922 multiply connected (shared edge)
structure 2894 5725 ok (non-closed singly connected)
<<Writing 918 conflicting points to set nonManifoldPoints
我想知道的是,出现neighbouring cells with multiple inbetween faces会不会影响计算收敛性和计算效率?我选用的求解器大致如下
system.zip
同时,有没有办法避免这种网格出现?或者出现后有没有办法在OpenFOAM中修正?renumberMesh没用,combinePatchFaces倒是有用,但是会制造出更多的问题。
@Hungryandfool 您说的我也想过,但我主要是应付不可预测的爆发性计算需求,超算中心这种流程繁琐,而且灵活性不足。
@东岳 您说的应该是远算云格物那个吧?但是好像不支持本地上传网格和设置文件,用起来限制太大而且不方便。
最近试了一下EasyCAE,感觉还不错,主要是用来应付短时间内爆发性的难以预测的计算需求,长时间的计算需求我自己的工作站就可以满足。但是EasyCAE有的时候会抽风,任务提交死活成功不了。同时不同节点之间性能有明显的差异,同样的算例花的钱也不一样。
阿里云试过,用起来不是太方便,关键是费用还是贵,即使是用东岳老师推荐的那个石家庄的节点,仍然比EasyCAE贵得多。
所以想问一下,有没有人用过类似EasyCAE这种的开放的计算平台,想要试一下,国内或国际上类似的应该不止一家吧?
simpleFoam是稳态求解器,你这个问题是不是用瞬态比较好?如果你模拟的流场达不到稳态可能会这样。建议用pimpleFoam试试。
而且,k-omega SST稳定性很好,对初值没有k-omega模型这么敏感吧。