CFD中文网

zzkluck

说一点我的看法，不一定对，仅供参考：

non-orthogonality

non-orthogonality由snappyHexMeshDict.meshQualityControls.maxNonOrtho直接控制，你的snappyHexMeshDict里这个值是45，这个值一般不需要控制的这么小，65是更常见的配置值。

另外，你的snappyHexMeshDict里，relaxed.maxNonOrtho给的是75，这个值通常是和maxNonOrtho = 65相配合的。如果你真的要把maxNonOrtho设为45，按逻辑来说relaxed.maxNonOrtho也应该相应的减少一点。

网格纵横比

这里截取你的背景网格配置：

vertices
(
    (-340 -302 -3)     // Slightly smaller than the STL model bounds
    (332 -302 -3)
    (332 341 -3)
    (-340 341 -3)
    (-340 -302 95)     // Slightly larger than the STL model bounds
    (332 -302 95)
    (332 341 95)
    (-340 341 95)
);

blocks
(
    hex (0 1 2 3 4 5 6 7) (100 100 100) simpleGrading (1 1 1)  // Adjust mesh density as needed
);

如上面B老师所说，你网格的大纵横比就是这里导致的。如果不是有意要在Z方向上做加密的话没必要这么分块，我口算一下，大概(70 65 10)就可以。

castellate

从上面可以看到，你背景网格的量级是100 * 100 * 100 = 1,000,000；而你SHM的maxGlobalCells给了2,000,000。这看起来不太对，这几乎没给SHM进一步细分的空间，从结果来看也是这样，网格划分的不够细。

另外，截取一段level的配置：

    features
    (
        {
            file "building.eMesh";
            level 3;
        }
        ......
    );

    refinementSurfaces
    {
        building
        {
            level (3 4);
        }
        ......
    }

我理解features的level应该不低于Surface的。

胡乱写了一些个人看法，希望能有所帮助。

zzkluck

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

zzkluck

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

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

zzkluck

@zhou 第四行

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

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

zzkluck

首先你需要确定下你的机器具体有多少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并行也没差多少。

zzkluck

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

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

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

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

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

CFD中文网

zzkluck

帖子

non-orthogonality

网格纵横比

castellate