应该就是这个问题，虽然我还不确定问题是怎么发生的，但我已经解决了。
Linux Mint 18 软件源自带的OpenMPI是1.10.2，好像整个OpenMPI 1.10版本包括1.10.2和1.10.7都有这个问题，然后换成2.0.4就好了。

确实有很大改善，可能上方空气部分需要设置一个比较大的高度

@东岳 用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 您说的我也想过，但我主要是应付不可预测的爆发性计算需求，超算中心这种流程繁琐，而且灵活性不足。