CFD中文网

@李梦瑶 最简单的办法就是在计算过程中输出，写出的theta可以直接用paraView读。后处理的话，@浪迹天大 有套流程。https://github.com/ZhangYanTJU/functionObjects

parcels.theta()().write();
后处理通过theta场和网格体积求parcel的体积。
总质量不就是书橱文件中的mass introduced么

@红豆沙 同样的code，用128个核并行计算，在因特尔的服务器上算的好好的，放在AMD搭建的cluster上就发散……简直是玄学，也不知道是因为mpi库的问题还是因特尔和AMD的区别。AMD稳定性真是差太多了

@Samuel-Tu 是的，new一维数组，通过指针对数组操作，不需要的时候还要delete释放内存 ：）

@yfclark 当然可以啦，什么网格都能算的。你是卡在了Added 1 new parcels这么？

@爱学习的LDH
湍流粘性能的英文是什么？我只听过turbulence kinetic energy，好奇

@wg0632 感觉你对大涡中的平均值有误解。
model的k也是平均值，只不过是平均值的瞬时值，就是大涡中所谓reolve出的物理量。
residuals是滤掉的需要模型才能得到的量。无论是resolved还是residuals，都分别有瞬时值和平均值。将modeled TKE取平均，得到的是平均值的平均值，就是没有波动的平均值。但即使是未取平均的TKE。也一样是一个平均值。
下面这张图就非常好

@yfclark 是不是你的网格太密了？欧拉-拉格朗日法的基本假设就是粒子的质量远小于网格中欧拉相的质量。网格太密，物理意义上就不成立了。
可以通过intermediate/clouds/Templates/KinematicCloud中的theta()函数查看液相和气相的体积比，只在屏幕上输出最大值就好。如果值大于1，那就可能有问题了。处在交界面上会自动判断归属于哪个网格或是直接删除，除非几乎所有parcel都很小并且处在交界面上，才会出问题，基本不可能——就算是这种情况，提示的也是除0的错误。所以，大概率是网格过密。是不是用了渐变网格？喷嘴附近的网格是不是比粒子初始直径还小？建议从这个角度入手解决。
另一个思路是，调整parcelsPerSecond

@Samuel-Tu 可以new一个空间，不会影响并行。但是不建议用链表或者二维数组，很影响效率和内存。有时候，索引链表花的时间甚至比解输运方程还多！我觉得最好不要用List。无论是链表还是多维数组，都是编译器帮你完成的寻址工作，最后从占用内存上讲都是一个一维数组。栈上还稍好，存储在堆上就疯了。自己计算元素的index，全部储存在一个一维数组中是最高效的方案

@东岳 Thanks again for your help! 谢谢

@东岳 The expression in the paper (Fig. 2 in paper "Extended CFD–DEM for free-surface flow with multi-size granules", which is given as alphaf) is alphac = 1-alpha.particle which is different from what you provided (alphac = 1 - alpha.air - alpha.particle). I just wanted to clarify which one is in the code?

Thank you again!

@东岳 Thanks for your help!

In the paper given above, the definition of alphac (=alpha.air + alpha.water) is different. I want to confirm exactly what it is. Is it not following the paper?

comment on 3rd point: I have already done that.

东岳老师，我的印度同事也经常逛CFD中文网，平时都是用谷歌翻译阅读。他也发现了这个问题（气泡不会让交界面的位置升高），想问您下面的问题：
When particles are injected, the liquid level is not changing. What could be the reason? Is it the ddt(alphac)=zero the reason?
多谢您了！

dynSmagorinsky.zip
这是我用过的。
动态参数的可以参照homogeneousDynOneEqEddy中Ck的求法，二者很像

是的，就是为了给用户自定义的文件更好分类。
我的方法是生成FOAM_USER_SRC_A，FOAM_USER_SRC_B，FOAM_USER_SRC_C，可以在每一个文件夹下各自存放自定义库和求解器，这样就避免了重命名或者版本管理。每一个SRC下的文件单独拖出来，都可以直接在cluster上编译运行

这个可以在后处理中做么？模拟已经结束了，切应力在模拟过程中是一直在变化的，需要对每个时间步内的值进行积分。你储存的结果，时间步长足够小么？

@zhe 不太明白你的问题。如果你指的是“粒子是怎么移动的”，和运动相关的都要去src/lagrangian/intermediate/clouds/Templates/KinematicCloud中找。solve(TrackData& td)函数中，从preEvolve()到postEvovle()的过程，就是粒子运动轨迹被求解的过程。每当粒子穿过一个网格时，粒子的所属网格信息都会被更新。如果你指的是如何判断处在cell face上的粒子属于哪个网格，可以参照这篇博士论文：
Kärrholm, Fabian Peng. Numerical modelling of diesel spray injection, turbulence interaction and combustion. Gothenburg, Sweden: Chalmers University of Technology, 2008.
OpenFOAM的粒子追踪算法就是这个人提出的

@悬浮的猪 alphaEff = alpha + alphat，层流热扩散系数在thermodynamic库更新，alphat去找你用的湍流模型。.c文件中有，一般是mut/prt，prt是constant中设置的常数

这个是代码有问题，可以通过Info定位出错的位置

众所周知，OpenFOAM只允许用户把编译好的库（lib）和求解器（solver）放在 $FOAM_USER_APPBIN 或 $FOAM_APPBIN 文件夹中。

科研时间久了，某一个库经过太多次的修改，会有很多个不同版本的代码。如果需要使用其中的一个版本，就要重新编译。如果想同时保留两个版本的求解器，就只能在修改代码的过程中，精心安排每一个编译好的库的名字，比如把 Make/files 文件中的 libcombustionModels 命名为 libcombustionModelsNew libcombustionModelsNewNew…… 只有这样，才能保留不同求解器各自需要的库（.so）文件。改的库多了，工作量就会几何增长！（比如turbulenceModels 建立在thermophysicalModels的基础上，lagrangian 又基于湍流模型，每一个库里都有大量的lib，每一个修改过的lib都需要重新命名，牵一发动全身！如果改了fluidThermo，那简直是欲哭无泪）

网上好像还没有人讨论过这个问题。经过研究，终于找到了一个打破僵局的办法。实现一个新的算法，只需要把新代码放在一个文件夹下，所有库的名字都不用修改。新生成的库，都会以旧代码的库名字保存在新的文件夹下，只要solver中指定需要哪个文件夹下的库就好了。

首先打开terminal，进入到OpenFOAM的文件夹下

$cd $WM_PROJECT_DIR/etc/

在bashrc文件中添加一行代码（在terminal中输入以下代码）：

$sed -i '/WM_PROJECT_USER_DIR_DEV/iexport WM_PROJECT_USER_DIR_DEV=$HOME/$WM_PROJECT/$USER-$WM_PROJECT_VERSION-dev' bashrc

其中，WM_PROJECT_USER_DIR_DEV 是自己取的名字，$USER-$WM_PROJECT_VERSION-dev 是想要储存新代码和库的文件夹路径，这里是创建user-版本号-dev,和$FOAM_USER_APPBIN文件夹同级。

之后，

$cd $WM_PROJECT_DIR/etc/config
$sed -i '/FOAM_USER_LIBBIN/iexport WM_PROJECT_USER_DIR_DEV=$WM_PROJECT_USER_DIR_DEV/platforms/$WM_OPTIONS/lib' settings.sh
$sed -i -e 's=_foamAddLib  $FOAM_USER_LIBBIN\:=_foamAddLib  $FOAM_USER_LIBBIN_DEV:$FOAM_USER_LIBBIN=' settings.sh 

完成在$FOAM_USER_LIBBIN这一行添加新的路径$FOAM_USER_LIBBIN_DEV，其位置在新代码所在的文件夹中。

之后，只要参照下面的命令批量替换新代码中Make/options和Make/files中OpenFOAM寻找库的路径，并保证求解器调用新路径下的库就好了！

sed -i "s/$(FOAM_USER_LIBBIN/$(FOAM_USER_LIBBIN_DEV/g" `grep "lib<自己命名的库>" -rl ~/OpenFOAM/user-版本号-dev/src`