说一下自己的看法吧。fvm其本身限制了发展基于它的高阶格式，如果真的追求高阶的话可能使用fvm并不是一个好的选择。另外现在间断问题都需要对高精度格式进行限制，其实本质上应该可以看做降阶处理。

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

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

我来尝试说说我的思路：原则上可能还真的很难。fluent这一类软件由于追求通用性，使用非结构网格，基于此很难构建高阶格式。这就涉及一个问题：离散格式数值粘性过大。比较悲哀的情形就会出现，很多细节结构都被磨平了，不论是空间上还是时间上。实际中DNS是纯粹非稳态的，时空上的叠加会导致计算结果面目全非。所以，DNS可能还真的不是计算量就能解决的问题，可能以非结构为基础的fvm或者fvm本身就不太适合做DNS。可能比较合适的一个是fdm或者galerkin方法。

$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/ 目录。