@散漫守望2016 感谢回复！我找出问题了，这个颗粒直径应该设置成particle diameter，即单个小颗粒的直径，而不是parcel equivalent diameter，即假设的parcel等效直径。这个发散的原因可能是直径设置错误当把nParticle 设置成100时颗粒相体积分数太大了，所以就没法算了。
解释一下供后面的新手参考

@hurricane007 脑残了，之前写错地方了。现在找到了

@zhangxc0223 问下。。。他是写在哪个文件夹里面的啊。。。我怎么用了这个utility 么看到写入的东西

这个真的是大佬了！

@白礼耕 我记得theta() 是欧拉相或者拉格朗日相的分数？如果这个大于1应该就是越界了，理论上说DPM应该不至于超1，但是MPPIC容易超1是真的。还是我记错了这个是两者的比例？

@yfclark 在 拉格朗日粒子追踪死循环 中说：

@白礼耕 感谢回复，网格和粒子直径比确实小，最小比例为5，

然后网格粒子大小比是5应该问题不大的啊

@红豆沙 并没有。。。我们这边很神奇，几个学校的cluster是共享的，有各种CPU，5118，6142，EPYC 7501什么乱七八糟的，还有V100加速卡，然而我自己实验室给的一台破E5450，自己买了台Y540 打游戏。。。

@红豆沙 6核能跑59.8/165 ， 12核是48/153，真是猛，我的9750H 用6核跑出来的是 74/251。看来笔记本U真不是降频这么简单，难道连浮点单元也砍了？？？
不过喂饱的问题，我在服务器上试了下，感觉6核还是喂不满的，12核和24核比6核都有很大提升
snappyHexMesh， 6C: 99.52 s；12C: 71.93 s；24C: 59.36s
simpleFoam，6C: 237 s；12C: 158 s；24C：86s,
然后想了下3900X的构架，12C分别在两个CCX上，应该是1个CCX 6个核心，如果就跑6C估计就正好分配给一个CCX上的单元所以更快，如果12C了，中间靠I/O核心通信，估计这个延迟会大一些？或者是因为超线程没关所以部分还在超线程的上面跑（类似并不是所有物理核心都被利用起来了，这种情况关掉超线程应该能提高）？或者因为AMD刚出来的时候驱动优化还不够？因为我之前看到过说Win10和 AMD两个通信好像有点问题导致某些东西没能运行在最快的核心上，你有没有装新的驱动再试试？
我倒是觉得对这个计算来说，内存通信和IF通信都不应该是瓶颈，毕竟网格数量还是比较少的。。。

@熊咔咔 在 DEM和DPM 中说：

@hurricane007 我大致明白了，parcel是为了简化计算的而设置的，particles是指实际颗粒？

也不是简化计算，应该是说为了加速计算

@熊咔咔 是 parcel track啊

@熊咔咔 我大概回答一下，如果不对期待大家指出
OpenFOAM里面是把particle打包在parcel里面了的，但是如果 1 particle/parcel 就和particle没有本质区别。
parcel是一个打包的概念，把多个性质差不多的颗粒打包成一个来追踪，减少计算量，其直径是等效直径，比如 n particles/parcel， 直径是 (nd)^(1/3)，但是particle force 是 nF。正常来讲最大n particles/ parcel 的这个n应该是小于最小cluster包含颗粒数量。如果原先用1particle/parcel 计算需要的时间是T，用parcel 的 n particles/parcel，假设总颗粒数量是 N，那么追踪的parcel数量减少到N/n，需要的时间可以粗略估计为是 T*(n/N)^0.5

@东岳 对，我那个5118是学校的计算集群，我记得我在哪儿看到过说这堆集群都是把超线程关了的，所以不可能使用的线程数量超过物理核心数量；然后睿频的话，应该是说如果你不关他，他默认是开的，但学校集群可能是关了的，你的如果是自己用应该是开着的，就是说如果睿频开着的，CPU温度和功率不超过他的限值的时候他可以运行在更高的频率上。比如你的5120 是14cores 28 threads 2.2G, 但是如果散热比较好功耗不超过某个限制的时候，他是可以整体跑在更高的频率上，这就能更快。
话说我觉得最惊奇的是我的9750H跑6线程居然比服务器CPU慢这么多，理论上说不过去啊，因为我看到跑的时候主频都跑到4G了，服务器才2.3G。得研究一下构架了