CFD中文网

$E=mc^2$

@Foamer24 你可以贴一个fvSchemes完整的设置看一下，很有可能是离散格式的问题。

@Foamer24 冒昧回复仅供参考，我觉得还是在于fvSchemes中离散格式的选用。对于skew较大等网格质量不好的问题其实就两个思路可供选择，第一重画网格，第二如果的确无法提高网格质量只好退而求其次选择数值耗散更强但是有界性相对较好的的离散格式。其实tutorial中给出的很多示例很难拓展到工程背景下的计算中。对于计算效率的问题往往跟选择的线性矩阵求解方法有关，目前尚未有普适的定论。您给出的结论也并不能涵盖所有的计算情况，您给出的截图也是OpenFOAM更快一些，但是往往需要选择合理的求解方法。根据Fluent的官方手册，它广泛使用的是AMG的求解方法，特别详细的内容我也并不清楚。

以上，希望没有传递特别离谱的错误信息，如有不当请及时联系，共同学习。

@东岳 老哥具体说一说，让我们也学习一下

@东岳 正好这两天下载安装了一下，icem还在但是基本没变化。感觉ansys这几个版本还是在做整合，大的改变很难搞了。

有的呀，还有的

@random_ran 您说的太客气了，虽然咱们这儿叫CFD中文网但是也没说不让使用英文。你之前的阅读逻辑是没有什么错误的，但是我不知道你怎么读到polyModifyPoint.H这个头文件去，因为我觉得貌似跟这个头文件没有关系。但是我感觉你对错误的基本定位应该是准确的，应该就出现在polyModifyFace.H第190行开辟新的智能指针出错了

polyModifyFace.H      188
virtual autoPtr<topoAction> clone() const
{
    return autoPtr<topoAction>(new polyModifyFace(*this));
}

@yuhx 你想加option的时候加，可以参考/src/OpenFOAM/include中相关内容

@Yongbo 看预计多大的计算量。CFD这东西感觉也没个上限吧，不过个人工作站还是有极限，我觉得貌似个人财力是上限，在这个限制之下买最后的。

@lllwonderliquid 方法可能不止一种，我给你提供一个思路吧，可能需要写一些程序，通过fvOptions实现。具体可以参考limitTemperature。

./system/fvOptions

limitT
{
    type            limitTemperature;
    active          yes;

    selectionMode   all;
    min             200;
    max             500;
    phase           gas; //optional
}

代码实现在 src/fvOptions/corrections/limitTemperature/ 目录。

另，建议改小matchToTolerance。相对于你的网格尺寸，这个值明显偏大。

@random_ran polyModifyFace是一个类，而非函数。另外在polyModifyFace.H同级文件夹下有polyModifyPoint.H 。至于抛出的异常之前未见过，不过看样子应该是在分配内存时出现了异常，非常有可能是你说的问题。但是实际上可能和你演示的例子还是有差别，固定数组能够使用的栈本身大小有限很容易出现这种异常。但是实际中像createPatch之类需要对网格数据进行处理的往往是通过动态数组开辟内存空间的，其上线与计算机内存有直接关系。createPatch在运行中需要额外生成相关patch的数据信息，需要占用相应大小的内存，如果网格过大很有可能超出计算机内存上限抛出错误。

另，过于createPatch具体实现我也没有进行深入的分析，仅提供一个思路，正确与否请谨慎。

@lllwonderliquid 可能你对插值格式的理解有误？？vanLeer01这里的0-1指的是相对值。你想给定k的范围可能是绝对值？那就需要使用bound进行限制。

@random_ran 从check的结果来看，原始生成的网格没有什么问题。您说的周期性边界失败是指？可是尝试使用createPatch这个utility创建cyclic边界实现周期性边界。

可以贴个详细的case来大家都跑一下，这样比较容易定位问题。这样问的话还是比较模糊。

@东岳 vim or emacs

这个我也挺好奇的。看OpenFOAM中的一些说明文档大约是用emacs org模式写的，看样子应该有很多开发者在用emacs。另外vim也是很好的一个选择，ide的话就很多了。我现在用eclipse结合git插件看代码貌似也不错，但是eclipse貌似有点儿太累赘，已经不能算是编辑器的范畴。我觉得，这个因人而异吧，用自己最习惯的就好。

gdb跑一下，这一个错误提示根本看不出来个啥

@李东岳 最近也在做打算。数据越来越多，做一个nas貌似挺有必要的

对，最近也是发现这个改动。不太明白出于什么目的，之前函数重载用着挺舒服的。不知道为什么要改成这样