Posts made by cccrrryyy

@bestucan 风场计算，没到气象那个级别，网格量在千万上下，多的能到五千万的样子。我研究下您说的swap这个思路。

@李东岳 CFD我理解应该确实不怎么消耗内存的。我这个是流场中有几百个点位需要提取流线，命令就是正常的mpirun -np xxx postProcess -fields xxx -parallel这样，应该不会涉及到内存没释放的问题吧？

@李东岳 不敢当不敢当。机器内存已经很大了，512，跑后处理耗掉了400多，然后节点上还有其他作业在跑，于是爆掉了。

我是没想到跑个后处理能耗这么多内存的，震惊了。

我需要提取一些监测点处的结果，但发现点过多的时候（上几百个）或者网格量很大的时候（普通工况是百万级别，但有时候会到几千万），postProcess在运行一段时间后报了个signal9，发现是内存耗光了。

有大佬碰到这种情况么，怎么解决呀？

@allanzhong 看这个意思，应该和你说的差不多，理论上肯定为，但实际上从理论转换为数值算法的时候总会有些偏差，算法在具体实现的时候又会有一些偏差。如果是这样，这些偏差我认为是可以接受的。

@allanzhong 这个问题问的很深刻，感觉理论上肯定是需要为零的。

openfoam有一些开源的入口条件，openfoam.com上也有DF-SEM入口条件（https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-inlet-velocity-dfsem.html），感觉可以找代码来仔细看看。

商软的话，fluent里面有vortex method，但看不到植入的细节，只有理论手册可以参考。

@leo_chou 大批量的工业算例（本身可能不复杂，但就是工况多），LBM是不是也需要大规模网格和较长时间？工业应用CFD对时间的要求基本上是小时级别的。

另外好奇问下，复杂几何下的LBM如何，需要湍流的LBM呢？我觉得大部分案例，复杂几何+湍流模型是标配，没有湍流的话可能有多相或者化学反应啥的，这些LBM是不是会更强一些？

@星星星星晴 感觉还是不太对，网格需要再细一些。

@星星星星晴 哦哦这个意思。确实是这样的，jet这种情况，喷出来5D左右甚至以内就应该能看到开始发展的涡了，不然LES就有问题。

@hitsc30 方便的话可以把收敛曲线贴出来看下，你这个其实首要条件是保证结果是收敛的。

@hitsc30 这个没有很离谱，只要是收敛的结果而且结果吻合的很好，那说明没啥大问题。

@星星星星晴 这些图能看出来啥

@wying 理论上，显示求解控制在1以下，如果是LES最好控制在0.3-0.5以下，隐式求解CFL没有太明确的限制，有些领域会在5左右，有些领域会在10左右，这个就没有统一的说法了。

但是，所有的这些都是理论上。实际计算以结果为准，而且你所使用的求解器（比如pisoFoam，如前面帖子说的，不是完全显式求解）可能已经没有这么明确的显示、隐式的区分了。

@星星星星晴 首先，那个视频是LES么？如果是的话，那很明显你的网格太粗了。按道理来说jet出来的地方，由于速度和周边环境的速度不一致，外缘在离出口很近的地方就应该开始有涡出来。你的网格量，RANS和LES都是一样的？

其次，Ck，Ce这些系数，是可以调的，而且LES里面这些系数只要不是太离谱，可能差异不会特别大。所以重点仍然是，找个类似的文献用人家用的就行，总比完全没有依据好。

最后，你提到的sgs下的耗散率，我个人是没见过这么定义的。这一项光看ksgs的输运方程，是表征ksgs的耗散率，但能不能和RANS里面的k-e模型的e对应起来，感觉需要严格的公式推导才可以。

@星星星星晴 网格尺寸理论上是有一堆公式可以估算的，但大都针对基础的案例，平板流动啊啥的，对实操没啥用。最好的方式就是找类似的文献，别人用多少你就用多少

直接用k-e的网格感觉太粗了些，壁面不壁面的看你模拟的东西了。你这个没有传热，而且兴趣区域在中间不在外面，感觉壁面可能没啥影响。

RANS改到LES，需要考虑的有边界条件（特别是入口，可能需要添加认为的扰动）、时间格式、数值格式（迎风就不太好，中心差分会好一些）、网格等等。所以比较建议先找个标准的算例试一下。

另外说一点，RANS你用的k-e，这里的k是所有的湍动能。LES里面的k是ksgs，是亚格子湍动能，不一样。Smagorinsky的话其实没有直接求解这个ksgs，直接用代数方法给出来的，但也有直接求解ksgs的（叫kEqn还是啥的，就是ksgs有一个自己的输运方程）。

@星星星星晴 LES和RANS的区别是全方位的，不要带着任何RANS里面的习惯来做LES。从最基本的开始，先跑个管内流经典算例再来做你自己的case比较好。

@yupeng 不存在搭配的问题，openfoam支持读入多种第三方软件生成的网格。所以的确是，哪个好用用哪个，哪个方便用哪个。

如果你完全没用过任何前处理软件，那建议先找一款身边人用的最多的，这样上手快。同时尝试把它生成的网格转成openfoam格式做计算，这样一整套就没问题了。

如果你已经用过了一些前处理软件，想知道哪个和openfoam更合适。那建议把这些网格先转成openfoam格式，检查下网格质量啥的，看看哪个最符合你的要求。

另外好奇问下，你提到的将来绘制复杂几何结构，复杂到什么程度？

@chien 什么设置？

@hitsc30 你这个涉及的东西有点多，排查起来会比较复杂。首先建议抛开fluent里的设置，因为大涡模拟这块openfoam和fluent差的还有点多。

首先是网格，snappy如果不好生成的话，试试cfmesh，这个比snappy好用，比fluentmeshing我感觉也就是边界层生成差一些。考虑到你这个几何相对应该比较规整，cfmesh应该可以的。

其次是入口条件。openfoam大涡模拟的入口条件这块是不如fluent的vortex method的，fluent的很好用，不怎么发散，生成的湍流也很强。我看你用的是timeVaryingMappedFixedValue，这是用的实验数据或者测试数据吗？你fluent是怎么用的？

然后是nut的边界条件，我之前也是发现nutUSpaldingWallFunction很好用，但我不确定它应该和WALE一起。WALE一般是传热领域用的多，原因是这个模型是不需要壁面函数的，而传热主要就是要解析壁面，不能模化。WALE感觉和你加的nut边界条件可能会冲突？

再然后是数值格式，一个是pisoFoam，openfoam里面的pisoFoam外迭代只有一步，可能收敛不太好。试试pimpleFoam加上外迭代吧，这个其实你在fluent里面应该也设置过。或者把你目前计算的残差曲线贴出来看看。

最后，为了排查这些问题，建议先跑个非稳态的RANS试试，不然理不出头绪来。其实最好先跑个稳态RANS，没问题了再非稳态RANS，再没问题了再上LES。

@shouan VOF吗？对网格要求很高，建议加密网格再试试，反正也要做无关性分析的。

@星星星星晴 网上人的言论别去管，键盘侠多了去了。真正关心你的人是不会有这种想法的，疫情最凶险的时候我不少朋友从国外回来，都是希望他们好好儿的，从来不认为空投。

@星星星星晴 就是类似于属于州府的这个大学管，但实际上离很远，人也不多是么？这种好像越来越多了，不容易啊，好处是可能环境挺好的？ 适合看paper写paper，加油加油

@星星星星晴 teaching assisstant，我当时就是这样的。不知道你是在研究机构还是高校，高校里面找系主任或者导师啥的争取个TA当应该不算特别难，我们系当时是有专门的名额的。所有就有工资啦。

@星星星星晴 找博后最好是请导师帮忙，这样比较顺利。另外国外毕业时间也好商量的，慢慢找吧。实在不行到明年春季毕业喽，先做做TA啥的。

学术上，印象中生物流体这块可能对多相流有比较大的需求，其他的就是燃烧（流体+化学反应）呀，流化床呀。不知道现在还是不是这样。国外其实也很讲关系的，平常多跟老外交流。

@星星星星晴 提个建议哈，最好最好，不要换方向，或者说主要的方向不要换。

比如你做欧拉拉格朗日，至少再在这个方向持续发力一段时间。一方面，你搞这个搞了很久，出成果相对容易；另一方面，你在这个方向上的知识储备特别是对领域的历史啊前沿啊之类的更了解，申请项目（比如各种博士后基金啥的）起来也会更加得心应手。博士后期间你当然可以尝试一些多相流领域别的套路，拓宽自己的面嘛，但自己的主方向别丢了，得不偿失。

另外问一下，你说找职位的时候发现这个方向很少是指学术的还是企业的？企业的话你可以试试医疗设备方面，喷雾这种多相流还是挺吃香的，然后就是军工确实不少。

@shrine 听起来太诡异了，还没碰到过这种情况。你是有什么特定的模块要用么，可以尝试把它放到2112里面编译看看行不行，印象中如果不涉及特别底层的东西编译起来也不是很麻烦。

@qing 是这样的，openfoam完全可以这样任意折腾。它是基于文件的，只要能读取、识别到相应的文件就可以进行计算。

@qing 组分场按你说的来就可以，一般不会有问题的。这么小的时间步是做LES么，如果是的话先算个RANS试试看？

@shrine 版本不应该吧？不知道你说的“输出多很多”具体是指什么，按道理IO不会影响速度到你说的这种程度。

同一个物理机虚拟出两个节点，然后用这两个节点跑并行，大概率会很慢很慢。如果是一台物理机一个节点，别的也都没问题，那只能是网络原因了，但就算千兆网也不至于慢到你说的程度。有运维让运维好好儿查查吧，网络的硬软件啥的。

@shrine 那你分到的两个节点至少不能在一台物理机上，这个估计运维管理人员应该能做到吧？不然还不如独占一台物理机，不要跨节点了。

@李东岳 找第三方测试的时候偶然发现的，我自己也不会搞，但发现居然有这种神奇的操作

@shrine 为什么要虚拟成2个节点，这样肯定严重影响速度的，直接并行跑不跨节点就不会这样了。

@ruibin_tongji
Green-Gauss Cell Based

Least Squares Cell Based

Green-Gauss Cell Based是最粗暴最直接的，但也许恰好适用于结构网格？我看这个Theory Guide里面是这么说的

有没有测试过对流项的格式？

@ruibin_tongji 这种需要知道详细的设置才能排查了。其实同样的网格你可以算个不一样的案例或者工况，或者湍流模型？单纯看看结果是否对称，这样能进一步缩小排查的范围。

@shrine 同一台服务器虚拟成2个节点？

@五好青年 所以他们真的是套OpenFOAM吗？有接触过么。纯好奇

@shrine 是不是装了别的版本的openfoam？xshell登录进去运行算例是怎么运行的？

@李东岳 我这个还是之前测并行效率的案例，1000多万网格。我测试了10 20 50 100 1000 10000，奇怪是设成20的时候计算时间最短，是其他时间的75%左右，其他几个计算时间都差不多。比较担心的是这个东西可能是case-dependent，所以想寻求下理论上有没有什么指导。

最近在测试线性求解器的精度、效率，发现GAMG和PCG类的求解器资料很丰富，不管是文献、商软还是网上的讨论啥的，但smoothSolver相对很少。好奇的是OpenFOAM的tutorials里很多案例都在速度场上用了smoothSolver，虽然tutorials并不表示就一定要按照它的设置来，但我觉得还是有一定指导意义的。

另外GAMG里面有一个参数nCellsInCoarestLevel，我测试下来发现它对计算速度影响比较显著。它的最优值有大佬有经验么？能搜到的一个经验性的数值是网格数量的平方根，所以默认值10太小了，可以往大了给。

@hxy970122 之前做燃烧的时候感觉重力影响很明显，重力向上的时候火焰长度明显比重力向下的长。有没有试过直接调重力加速度度的值？直接调成1000倍试试看，如果还是不明显或者根本没作用，说明是模型物理设置方面的问题，大概率不是数值方面（稳态瞬态、数值格式等等）。

@韬智tz 首先你要确认算四分之一区域是可行的，至少算一个工况下四分之一和360度，确认没问题再往后进行；或者你有一些很确切的方式（理论或者实验观测）知道你要模拟的问题是对称的。

或者你也可以探究下一半区域（180度），能省下来一些计算量就省嘛。

另外你提到的运算效率这块，可以先从初始场、松弛因子这些入手，然后就是迭代求解器（SIMPLE，SIMPLEC这些对比下），再然后就是线性求解器。

@tens 我这边做的一些测试下SIMPLEC比SIMPLE甚至还要慢。这一块东西需要看一下理论，贴一下FLUENT的文档

@exthan 这些量本身就是有的吧，mu_，nu_这样子？

你试过调用但显示未定义这个过程是什么样的？

@exthan 改EddyDiffusivity这一部分，可否直接自己建一个变量，只不过它的计算基于mut，mu这些，然后求解器那块全部使用这个自建的变量。就是说，原有的Prt全部保留，只是增加一个东西，然后求解器用的是新加的这个。

@exthan 因为你的Prt是定值呀，这个文件不止包含边界条件，内部场也是有的，只不过是uniform 0.85。

你用info输出那里是不是应该直接改为Prt_，而不是Prt()。

@exthan 你的目的是把Prt改成所说的和mut，mu，nu，alpha等等有关的那个表达式对吧？你改的eddyDiffusivity文件路径是啥，我瞅一眼看看，好久没搞可压缩啦。

你判断修改Prt是否成功的方法应该没问题，但是没有输出有点奇怪，按道理说即便是报错了应该也会输出的。如果这种间接的方式还不行，我一般会直接在程序里面让它输出，就是 Info<< 这样子，缺点是这样会输出每一步每一个cell上你要的数值，优点是你一下就能看出来有没有问题。可以把网格弄很小，反正只是测试程序嘛。

@李东岳 HPC的节点分配逻辑可以自定义，但确实最通用的就是优先占满某个节点。至少在工业场景下，比如我们是好几个应用都在集群上跑，那OpenFOAM这边我只要保证多节点不比单节点慢就很理想了。比单节点还快是加分项，但不是必须项。

或者可以设置为在集群比较空的情况下，优先采用多节点少核心的方式，但“集群比较空”在实际使用场景中基本不存在，能排上队就不错了。

如果是学术那肯定不一样，确实如李老师所说，光是并行加速这一块好好的研究下就可以发sci了。

@李东岳 李老师，最近跑了下多节点并行的算例，和之前我贴出来的案例是同一个。速度如下

24：1195
24+24：809
24+24+24：500
24+24+24+24：392 （注：也跑过48+48，时间602，再次说明同样核数情况下多节点的效率很高）
24+24+24+24+24：354

能看到从3节点开始效率提升就不再是线性，可能对这个网格量的算例来说3个节点已经到头，再增加节点的话性价比就开始下降，但没有出现您所说的效率反而降低的情况。

这个效率的增加其实有点超出我的预期，本来以为到了3个节点应该开始明显变慢才对。我这边单节点是64核，每个节点用24核应该远没达到机器的性能峰值，所以可能多用节点的时候计算效率提升依然很不错。

@hitsc30 我的经验是这个是并行不并行没有关系，你先试试看。一般挪一下点位之后就能出来结果，但是挪多少不固定，因为这个方法本质上是让点位避开OpenFOAM出bug的那个地方，但bug还是存在的。

@hitsc30 这东西是OpenFOAM底层的一个bug，它在某些情况下会判断点不在任何一个cell里，高版本应该不会再有问题了。

http://bugs.openfoam.org/view.php?id=1544

我尝试过将高版本的相关代码在低版本上进行编译，但是因为底层代码区别有点大，编译失败了。最后换成高版本的OF去计算的。

如果你一定要使用某个版本的OF，那么可以尝试重新划分下网格，或者像你尝试的一样挪一下点位，但这些都不能百分百保证不会报错。