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

@刘雄国 哈哈哈好没事，反正看得懂的。嗯应该是进程。
MPI或者OpenMP并不影响这个问题，反正都是两边交流信息，所以其实影响这个问题的是第二个。如果离散相分数很低，考虑单向耦合，或者二向耦合（连续相->离散相，离散相->离散相），那么可以把离散相和连续相分开，因为只需要把所有的连续相的流动汇总，并加给离散相就好了。
如果是四向耦合，是不是大概这样：

1. 如果在每个时间步骤，用一个进程把所有的流场信息都集中起来供其他颗粒跟踪的进程去访问，并且还需要把所有的离散相信息汇总给连续相，那么通信量太大了。
2. 即使把每个进程跟踪的颗粒都加上label，只定点访问某些进程的信息，似乎通信量也还挺大问题。
3. 如果把流场的作为主进程，跟踪颗粒的作为slave进程，如果这个master/slave比是定的，那么也是之前的那个效率问题。

现在E-L方法中，在多线程计算的情况下，同一个线程需要计算连续相和离散相，但是在颗粒分布极度不均匀的时候就会产生每个线程所需要的计算时间完全不同的情况。既然连续相和离散相也是依次计算，那么有没有一种办法把两个东西分开呢？打个比方说，某个求解器，计算区域分为4块，4个线程来计算，然后用16个线程进行颗粒跟踪，每个线程分配的颗粒数量大致相当，两边再耦合。
如果有这种求解器的话，求指点一下，如果不能的话，求讨论一下为啥不能

@李梦瑶 Goldschimidt 算例里面, constant/kinematicCloudPositions，里面你能看一行一行的括号，里面有三个数字，就是每个颗粒的坐标，把这堆东西都删掉，换成你自己需要的就可以了。当然，40万颗粒的话，找个别的语言, Julia/Python/Matlab等来写个小代码生成、输出一个颗粒的位置信息的文本比较好。

@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是指实际颗粒？

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