CFD中文网

这其实是个常见问题。按我的理解，不是Courant Number突然变大很多倍导致模拟发散，而是速度求解先崩掉了导致Courant Number跟着增大，然后速度就更崩了，然后恶行循环。从崩溃的时间步往前看日志，应该能观察到Courant Number持续增大。

推荐参考这篇帖子《WSL调用Windows下的ParaView对OpenFOAM进行后处理》。

Paraview装在Windows里，在wsl里调windows的Paraview。能避免不少配环境带来的问题，而且这样Paraview直接装在真实的系统里，图形性能会好很多。

@zhou 第四行

min (#calc "$xmin + 0.3$in_len"  .......

这个0.3和$in_len之间没有运算符，相当可疑。

首先你需要确定下你的机器具体有多少CPU核心，我猜测你CPU实际上是56核112线程——这种制式偶尔也草率地称为112核，或者称为56颗物理核心/112颗逻辑核心。

mpirun的默认slot数是你的物理核心数量而不是逻辑核心数。考虑到我们的物理核心可能只有56颗，在64并行运算时程序报告not enough slots available是非常合理的。

在这种情况下，你问题的答案就在错误报告的最后面写着：

4. If none of a hostfile, the --host command line parameter, or an
     RM is present, Open MPI defaults to the number of processor cores

In all the above cases, if you want Open MPI to default to the number
of hardware threads instead of the number of processor cores, use the
--use-hwthread-cpus option.

Alternatively, you can use the --oversubscribe option to ignore the
number of available slots when deciding the number of processes to
launch

简单翻译一下：

情况4：如果没指定远程计算资源，OpenMPI使用本机的处理器核心数作为slots的默认值；

.....，如果你想要让Open MPI使用硬件线程数（112）代替处理器核心数（56）（作为默认Slot数量），使用--use-hwthread-cpus选项。

或者，如果你想要在决定的启动的进程数这个问题上忽略可用slot数量，使用--oversubsribe选项。

这样来看，如果你的CPU确实是56核112线程的话，加一个--use-hwthread-cpus参数是更合适的选项。不过使用超线程会使得加速比下降，也许56并行和64并行也没差多少。

按照文档里的说法，有时换一下meshShrinker也许会有效果，感觉文档里那个例子和你的也有点像。

addLayersControls
{
    ...
    meshShrinker    displacementMotionSolver;
    solver          displacementLaplacian;
    displacementLaplacianCoeffs
    {
        diffusivity     quadratic inverseDistance 1(wall);
    }
    ...
}

相应的还需要调整下fvSolution和fvScheme，具体文档里都有。

话说新版文档虽然变好看了，但图居然是糊的，可能还需要参考下旧版文档。

另外这里也请教下各位老师，按我的理解snappyHexMesh做完snap之后，在layer这步应该是从几何表面出发，向外挤出来一块空间把边界层塞进去。怎么在楼主的这个例子中反而是向内把几何都挤变形了