推荐参考这篇帖子《WSL调用Windows下的ParaView对OpenFOAM进行后处理》。
Paraview
装在Windows里,在wsl里调windows的Paraview
。能避免不少配环境带来的问题,而且这样Paraview
直接装在真实的系统里,图形性能会好很多。
推荐参考这篇帖子《WSL调用Windows下的ParaView对OpenFOAM进行后处理》。
Paraview
装在Windows里,在wsl里调windows的Paraview
。能避免不少配环境带来的问题,而且这样Paraview
直接装在真实的系统里,图形性能会好很多。
首先你需要确定下你的机器具体有多少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
这步应该是从几何表面出发,向外挤出来一块空间把边界层塞进去。怎么在楼主的这个例子中反而是向内把几何都挤变形了