你看paraview。上面时间已经是0.005了
帖子
-
设置的U和pareview里面查看的U不一致 -
foam-extend-4.0 移植重叠网格 wmake编译报错@Gunther 已经include?你是说在源代码里写的包含头文件那句代码?
你知道那个文件在哪,但是gcc不知道,所以得在options里写明,头文件的位置,和库文件的位置。
头文件可以让gcc知道有哪些函数可用,头文件一般都是函数声明。库文件定义函数如何运行。所以位置都得指明。
那些个IDE有的设定好了,把这些细节藏起来了。
至于为什么你的options文件没有发挥作用,我看你也没把overset的头文件写进包含里呀,具体怎么写不知道,但大概应该像这个的最后一行,地址不一定对,那你觉得你之前的option文件里,第几行包含了overset的头文件呢?
EXE_INC = \ -I$(LIB_SRC)/finiteVolume/lnInclude \ -I$(LIB_SRC)/meshTools/lnInclude \ -I$(LIB_SRC)/surfMesh/lnInclude \ -I$(LIB_SRC)/sampling/lnInclude \ -I$(LIB_SRC)/lduSolvers/lnInclude \ -I$(LIB_SRC)/overset/lnInclude
-
OpenFoam监测位移,后处理作图求助OpenFOAM的计算结果文件夹里有温度、压力。。。。等等文件。飞射物体所在的位置有什么特殊物理量?
用grep去抓,用数据所在行数判断坐标,写成脚本,把所有时间节点都抓了,然后就有数据画图了 -
foam-extend-4.0 移植重叠网格 wmake编译报错直接把
crMatrix.H
的绝对路径写到EXE_INC
里试试 -
cellMotion边界条件源码阅读求助找pp[i].average的定义
pp是p的patch的引用,p是this的patch的引用。
所以pp是this的patch的patch。
所以pp的子函数average要从this里找。this就是当前这个类:cellMotionFvPatchField
这个类的定义在:
src/fvMotionSolver/fvPatchFields/derived/cellMotion/cellMotionFvPatchField.H
由类定义可知,该类继承自 fixedValueFvPatchField.H (
src/finiteVolume/fields/fvPatchFields/basic/fixedValue/fixedValueFvPatchField.H
)fixedValueFvPatchField 又继承自 fvPatchField (
src/finiteVolume/fields/fvPatchFields/fvPatchField/fvPatchField.H
)
这里352行,有patch函数,返回值是patch_src/finiteVolume/fields/fvPatchFields/fvPatchField/fvPatchField.C
中显示patch_的初始变量是fvPatch类型的(this的patch)src/finiteVolume/fvMesh/fvPatches/fvPatch/fvPatch.H
这里142行,有patch函数,返回值是polyPatch_,它的声明在69行,是polyPatch类型(this的patch的patch)polyPatch里没有average函数,接着往基类上找(
src/OpenFOAM/meshes/polyMesh/polyPatches/polyPatch/polyPatch.H
)继承自两个类:patchIdentifier, primitivePatch
第一个查无所获,第二个:
src/OpenFOAM/meshes/primitiveMesh/primitivePatch/primitivePatch.H
里面有四个头文件,一个个找过去,
第一个:
src/OpenFOAM/meshes/primitiveMesh/PrimitivePatch/PrimitivePatch.H(^处两个字母,大小写和上面不一样) ^ ^
没有average函数
第二个:
src/OpenFOAM/meshes/meshShapes/face/face.H
好了,找到函数原型:148行
//- Calculate average value at centroid of face template<class Type> Type average(const pointField&, const Field<Type>&) const;
代码行数都是OpenFOAM 10版本的
网页搜着慢,可以自己编译个本地的,搜着快,一句命令就可以生成。
can@M320-TC:/home/can/.local/share/OpenFOAM/OpenFOAM-10/doc/Doxygen> ll (git)-[master]- total 140K drwxr-xr-x 2 can can 4.0K Jan 6 2023 Macros/ -rwxr-xr-x 1 can can 2.0K Jan 6 2023 Allwmake* -rw-r--r-- 1 can can 496 Jan 6 2023 CFDFoundation55x55.png -rw-r--r-- 1 can can 948 Jan 6 2023 customdoxygen.css -rw-r--r-- 1 can can 103K Jan 6 2023 Doxyfile -rw-r--r-- 1 can can 716 Jan 6 2023 footer.html -rw-r--r-- 1 can can 2.1K Jan 6 2023 header.html -rw-r--r-- 1 can can 7.5K Jan 6 2023 README.html -rw-r--r-- 1 can can 1.7K Jan 6 2023 README.org can@M320-TC:/home/can/.local/share/OpenFOAM/OpenFOAM-10/doc/Doxygen> ./Allwmake (git)-[master]-
也可以手动找。加载了OpenFOAM环境后,
src
命令直接跳到源代码目录,然后:直接找到类的定义:
find . -name calssWhatIWant.H
直接找函数:
grep -r "functionWhatIWant(" .
加半拉括号是为了减少搜索到的结果。搭配正则表达式用,搜的效率更高。
-
snappyHexMesh生成网格后,结果显示“non-orthogonality > 45 degrees”过多网格设定的问题。网格看起来太薄了,这不是好的网格,放在二维里说,就是大纵横比网格。
这样薄片或者说大纵横比网格,即使正常生成网格没有错误,计算也容易出问题。
这样的网格在优化的过程中也容易出问题,因为稍微挪动,就会出现像穿模一样的效果,负体积之类的。
-
cellMotion边界条件源码阅读求助 -
关于hexRef8 : Dumping cell as obj to ".../cell_813430.obj"的问题 -
前处理,进口面问题icem也有这个功能,只是我没用过,
-
Paraview如何自定义时间间隔 -
前处理,进口面问题虽然我没画过这类网格,但“两个网格边界组合对应一个相邻网格”这种操作应该挺普遍的,因为按区域加密是个挺普遍的需求,比如这个教程里:
-
关于集群计算积累buff/cache缓存过高的处理办法@郑学习 是的
-
paraview显示不了粒子,应该怎么设置呢paraFOAM是编译出来的。安装的paraview不能使用paraFOAM命令。
paraFOAM和paraview差别不大。可以直接用paraview。
就是每次查看计算结果多了个步骤:touch test.foam
因为paraview无法自动生成 .foam文件,所以要手动创建
-
Openfoam 每隔一段时间更新流场你可以先探索一条“手动”实现你想要的功能的方法。
然后用bash脚本替代“手动”过程。
写bash脚本的时候直接用gpt,把你想要实现的功能描述清楚,让他生成,你再调
大概是这么个循环:
计算一小时间
然后setfields
然后修改cotroldic里的计算开始和结束时间要修改的时间可以用循环变量乘以周期时间之类的。
-
关于集群计算积累buff/cache缓存过高的处理办法性能上的设置,只会影响速度,不会影响“炸不炸”。buff/cache 是用来加速的,所以,即使没有,顶多慢,不会炸。
应该是内存炸了,swap太太小了,个人计算机都不会这么小。可以把swap理解为虚拟内存。物理内存不够用,就会暂时使用虚拟内存。虽然虚拟内存慢,总不至于完全无法工作。要是物理内存用完了,虚拟内存也用完了,就会炸。
有一次OpenFOAM的大赛版本升级,导致编译的时候需要十几G的内存,很多人都炸了还找不到原因。
一般 swap 设置为真实内存的一倍就差不多了。古早时候个人计算机内存小,2G、4G的时候,虚拟内存都设置为三倍左右。现在大了,一倍就差不多了。你这个服务器内存也够大了,哪怕0.5倍呢;再大了即使不炸,也会很慢;结果4G。。。。
按说那么大内存,能控制好计算任务范围,不用虚拟内存也行。但是你们那么多人用。调大了,即使不炸也会很慢。swap就是抗一下内存占用尖峰,保证不炸,不能依靠。
另外,很多人用fluent不知道怎么杀干净,留一堆僵尸进程,也会很影响性能。如果有很多cleanup开头的fluent脚本,就是了。正常关闭不会留下这些文件。异常退出就是要用这些文件清理僵尸进程
-
在工作站中测试openfoam并行效率很低,大佬们帮忙看看是什么导致的呢@w352405196 对于单个CPU而言,所有的核都用上,不会是最快的,但是慢多少说不清楚。
因为还要留几个核做些调度工作,(往底层说是芯片上任务分支判断、多任务切换上下文转换、堆栈策略什么的,往系统上说是系统本身有些服务进程一直在后台运行)
32核跨CPU效率高。可以解释为,对于单个CPU而言,满载32个核都用来任务,还得时不时停下任务做些任务调度工作,所以慢些。分到两个CPU。每个CPU。一半核用于调度工作,一半核用于计算任务。快些也合理。
当8核的时候。无论是单个CPU还是两个CPU运行,都会有一部分核空闲用于随时的任务调度工作。所以,分到两个CPU上反而慢一些。因为CPU间通信会耗时一些。两个CPU互相不知道对方的工作状态,不如单个CPU统一调度效率高。这个现象也可以理解。
如果把计算任务理解成打仗。不能让所有人都上战场(所有核用于计算),得留几个人搞后勤支援。否则,就得有些人一会披上铠甲打仗,一边系着围裙搞后勤。后勤保障不上,拖慢整体进度。相比于整体进度拖慢,做后勤的那个核因为做后勤而降低的打仗效率反而不重要了。
而且,核多不一定快。
核越多,核间通信的时间成本越大,核间任务调度算法越麻烦,调度效率也越低(总是难免核间互相等待对方的结果才能继续自己的)。如果横轴表示计算用的CPU核数量,纵轴表示计算用时,那应该是两头高,中间低。
影响的因素很多,得具体分析瓶颈在哪里。
-
在工作站中测试openfoam并行效率很低,大佬们帮忙看看是什么导致的呢@w352405196 两个CPU呀,那要考虑主板总线带宽的影响了。
线程开的越多,CPU交换数据越频繁。总线堵了,速度可不是上不去了。
CPU和内存交换数据也是要通过总线的。所以,程序即使往硬盘读写不频繁。但是计算一定要从内存读指令和数据的。所以,可以查查你的主板型号,看看它的总线对多CPU或者说高性能计算的支持怎么样
-
在工作站中测试openfoam并行效率很低,大佬们帮忙看看是什么导致的呢@w352405196 CPU呀,都顶到100%了。
硬盘读写都为0,说明硬盘没限制速度。
还有不小的上传下载流量。这个计算是跨节点的?
进程gs_test只占用60%左右,cpu都能顶到100%。这是还有些进程因为权限没显示出来。
可能和网络通信有关
-
在工作站中测试openfoam并行效率很低,大佬们帮忙看看是什么导致的呢下载一个gotop二进制文件。github上有。跑代码的时候再开一个终端看gotop的各项指标,哪个满了就是哪个卡脖子🤣🤣🤣
-
openfoam火灾燃烧模拟@李东岳 现在社会语境下的“道友”几乎约等于“同志”