overpimpleDyMFoam +颗粒边界处理
-
@lys 嗯嗯 重叠网格部分我也不是很了解 请问能否讲一下这个部分是怎么处理的?
正常情况下验证过parcel放在pimple之前或者之后应该是不太影响结果的(同事验证过, dilute),但是你这个case改变了mesh,就不好说了。或许你应该放在pimple之前,这样会导致 $n_t$ 的时候用的是$n_{t-1}$的流场, 但是这样仍然无法规避网格变动的情况。
你可以先跑一个无重叠网格的case,判断一下,是否是重叠网格的问题。parcel应该都是在网格内部的,所以如果出现在非网格处的话,能让我想到的只有你的重叠网格引起的问题了,是不是应该在重叠网格处理部分也加入关于parcel的处理。而且我在kinematicCloud.C 中看了一下,preEvolve的地方他会updateCellOccupancy(),所以parcel会在计算的时候重新计算当前cell内的parcel信息。
-
@lys 你可以试试Co小一点,这个也有影响的,判断你的拉格朗日dt. 正常情况下是需要考虑dispersion的,不然particle的RMS是错的(个人经验)。不过of自带的dispersion model 也不咋地,不过你可以试试看。也要看你用什么turbulence。 RANS 还是LES,RANS需要,LES怎么说呢,理论上也是是需要的,但是好多人不用。OF也没有默认的LES的turbulence dispersion。俩模型都$k-\varepsilon$的。你也没说你用的啥turbulence
我做过和你类似的,不过不是圆柱,不是你的重叠网格,是tablet周围被snappyhexmesh加密过,完全没有你说的情况,particle就是碰到壁面就没了,个人认为,是因为你的重叠网格,也不知道这个重叠网格怎么做的,另外如果你particle很小,不是dense的话,有些模型不用考虑,完全是浪费时间。shear-lift?不好意思,有些词我想不起来中文教材怎么叫了。。。
-
@lys 比如ueq里面的 + parcels.SU(U) 这一项,其他的有加么
// Solve the Momentum equation MRF.correctBoundaryVelocity(U); tmp<fvVectorMatrix> tUEqn ( fvm::ddt(rho, U) + fvm::div(phi, U) + MRF.DDt(rho, U) + turbulence->divDevTau(U) == rho()*g + parcels.SU(U) + fvOptions(rho, U) ); fvVectorMatrix& UEqn = tUEqn.ref(); UEqn.relax(); fvOptions.constrain(UEqn); if (pimple.momentumPredictor()) { solve(UEqn == -fvc::grad(p)); fvOptions.correct(U); K = 0.5*magSqr(U); }
-
@lys 嗯,就是确认一下别拉下什么东西没加就难受了。
所以说,那些particle 应该是在$n-1$步时还在网格里,然后网格发生变化,可能就不在网格里了,这部分parcel就没办法算了。
- 把parcel.evolve() 放到 bool changed = mesh.update() 前面,让parcel用上一步的旧网格试试看
- 另外如果你的Euler time step $\Delta t_E$ 足够小,就是你每次更新网格的间隔减小,会不会也一定程度上减少这样的发生呢?
- 调整动网格或者在parcel部分,判断内部是否有parcel,有parcel就挪他们到wall表面。