OF可压流求解器

Aeronastro

OF中可压流求解器主要是以rhoCentralFoam和rhoPimpleFoam为主，而rhoCentralFoam的对流项用的是KNP的通量分裂格式，尽管这个格式我在计算流上面没有找到理论，但既然编成了这种格式应该也有它的用武之地吧，而rhoPimpleFoam是将不可压的PIMPLE算法加以扩展，用在了可压流中，也有人反映这个算法对压力项的修正不是很好。

我不知道为什么不用主流的Roe格式来进行对流项的离散？不知道有人用过Roe自己编写过可压流的求解器没有？和OF自己的KNP方法比较有什么差别？

以上是我的见解，不恰当之处还请批评指正，谢谢~

xuebao1989

@Aeronastro 过段时间我也想改一下可压缩流的求解器，有这个想法，目前思路还不是太清晰:cold_sweat:

李东岳

Hi, @Aeronastro

我个人不怎么做超音速空气动力学，对这个帖子不会有什么特殊贡献。

但有关rhoCentralFoam我层和Henry讨论过，他表示rhoCentralFoam相比较rhoPimpleFoam更加适用于震波捕获。另外，rhoCehtralFoam有文献，昨天重做系统刚把这个我没怎么调研的求解器的文献删除。没想到今天就遇到了。google一下？:anguished:

其他有关KNP，ROE尚不清楚。如果你有兴趣，是否可以简单说一下为什么超音速流有很多特别的对流格式？

lhzhu

@xuebao1989

这里有个网站， compressibleFOAM: http://pavanakumar.github.io/compressibleFoam/index.html，对你实现可压缩求解器可能有帮助。里面的一个 Instructional workshop on OpenFOAM programming LECTURE 系列Lecutures也是很好的资源。

lhzhu

@李东岳在 OF可压流求解器中说：

Hi, @Aeronastro

我个人不怎么做超音速空气动力学，对这个帖子不会有什么特殊贡献。

但有关rhoCentralFoam我层和Henry讨论过，他表示rhoCentralFoam相比较rhoPimpleFoam更加适用于震波捕获。另外，rhoCehtralFoam有文献，昨天重做系统刚把这个我没怎么调研的求解器的文献删除。没想到今天就遇到了。google一下？:anguished:

其他有关KNP，ROE尚不清楚。如果你有兴趣，是否可以简单说一下为什么超音速流有很多特别的对流格式？

只能初略的解释下：
因为在激波层这一极其薄的区域要人为增大粘性（可以通过各种方式），让数值上的激波厚度能跨越几个（1个、2个...，也不能太多）计算网格（远大于实际的激波厚度），不然程序在间断处就不稳定。但是又要保证这个数值粘性在那些比较光滑的地方比较小。这两个要求很难同时满足得比较好，所有就会有对流格式出现了。

wwzhao

@李东岳我也不是做空气动力学的，说说我的理解吧。

超音速空气动力学中的激波（shock wave）是间断问题，需要一些被称为高精度格式（high resolution schemes）的对流格式才能捕捉，在使用高精度格式的时候通常还需要配套使用通量限制器（flux limiter）以保证解的有界性，避免在间断点出现过大振荡导致发散。这类格式通常满足总变差不增（total variation diminishing）。

xuebao1989

@lhzhu 真是太感谢您了，非常有用

Aeronastro

@李东岳嗯嗯，谢谢哈，关于那篇文献我之前研究过。关于对流项的其他离散格式，我从一些文献上找到高阶精度的，WENO等（这些格式之所以要求这么高是因为要用LES湍流模型），我目前还不是很了解这些，我们教研室湍流用的都是RANS，软件一般用的是fluent，里面最常用的就是Roe和ASUM，所以我之前对于OF中的可压流没有提到这些格式有点疑问。

Aeronastro

@wwzhao 嗯嗯，是的，在rhoCentralFoam中用到了VanLeer和VanLeerV的插值格式，也是一种限制器，我也别人说rhoCentralFoam在求解超声速流动时耗散偏大，不知道是不是有这样的一个现象？

Aeronastro

@xuebao1989 您好，那个网站我貌似打不开:upset:
里面都有哪些有用的资料呢？能否共享一下？:tongue_out:
谢谢:happy:

xuebao1989

@Aeronastro 把链接的index.html去掉即可打开

程迪

@李东岳
这个solver作者的原始文献是Implementation of semi-discrete, non-staggered central schemes in a colocated, polyhedral, finite volume framework, for high-speed viscous flows DOI: 10.1002/fld.2069
具体格式是KT和KNP，分别有各自的文献。

李东岳

@程迪
多谢，下来研究研究。

youmengtian

终于看到有做这个方向的朋友了。现在我就是想在这个方向上发展，目前也有一些其他人的前期工作。现在主要参考DensityBasedTurbo和foam-extend-4.0中的fvBlockMatrix等相关内容。

目前梳理一下主要还有几方面工作亟待完成：

完善的通量分裂格式代码，这个之前已经有很多实现了，包括foam-extend中的dbns实现；
低马赫数流动的预处理方法；
基于blockMatrix的隐式时间格式，或者更方便的LU-SGS方法。不幸的是，如果使用预处理方法，求解的矩阵还会是block格式的。

如果以上几个方面OK的话，在OpenFOAM中实现与fluent相似的密度基求解器就可行了。目前最头痛的问题是OpenFOAM的官方版本至今也没有推出blockMatrix求解实现的计划，看现在的情况，只能在foam-extend下实现。

ps：看过foam-extend 中blockLduMatrix的主要实现，基本在基本库foam中，对应官方版本的OpenFOAM基本库。由于这个库很低层，如果想实现移植是一个很大的工程。各版本各有优势，大牛们又各自为战，有时候也忍不住想吐槽一下。

程迪

@youmengtian

通量分裂是不是还分FVS和FDS，还是现在大家都融合到一块儿了？

我刚入手，但是觉得有点问题的地方在于：

OpenFOAM的lduMatrix会不会对求解器开发构成限制？这样隐式项只有neighbour部分的影响，其他全部搞成deferred correction了；
OpenFOAM貌似没有自带的计算数值通量的函数库，连界面两侧的插值获取都要手动实现（类似rhoCentralFoam），感觉不是很方便；
对blockMatrix不太了解，但是感觉在限制器设计上是不是还有很多工作要做？毕竟多维扩展的矢量限制器想想就可怕；
从时间项来看感觉OpenFOAM只有线性单步法的时间推进(time stepping)算法，连线性多步法都没有，还得自己实现；
低Mach数理论上可以用预条件，但是必要性存在问题呀，完全可以用不可压缩的求解器嘛；
除了LU-SGS外还其他的方法会不会更好一些？JFNK/IDR(s)之类的？感觉lduMatrix还是很适合稀疏算法的。

youmengtian

其实不管fvs还是fds，或者有融合二者的AUSM系列，都可以抽象成输入网格面两边格心的原始变量，通过相应变换生成守恒通量。也就是说通量分裂格式在代码实现上可以抽象成一个系统。

另外roe AUSM HLLC等等格式都是一阶精度，通过限制器可以实现二阶精度。也就是在这个基本数值通量上，通过限制器实现插值重构。

另外blockldumatrix基本迭代求解方法可以类比ldumatrix。本质上ldumatrix可以认为是blockldumatrix<scalar>。当然存在一些自己独特的block子矩阵特殊处理方法。目前一些求解器通过先生成fvmatrix然后后期组装成fvblockmatrix。就目前状况，如果不涉及隐式时间项，可以在不涉及blockmatrix的前提下实现。

其实不管是压力基还是密度基，都在努力扩展求解范围。很多实际问题并不会有明显区别，甚至有跨多流态的问题。

以上，自己的一些理解，希望进一步交流

程迪

@youmengtian

我的理解和您不一样，我的理解是限制器只在interpolation阶段有用，（代码显示OF也是只在interpolation阶段有用限制器，玩的似乎是flux limiter的路数而不是gradient limiter，但是感觉很奇怪），守恒通量是用Riemann求解器搞出来的，Roe/AUSM/HLLC都算是Riemann求解器，大概意思是从两侧的通量整出个新通量出来。整出的新通量还要用限制器限制么？我觉得应该不用了吧，限制器需要一个比较范围，新通量算出来和谁比较呢？

按理说FVM搞Reconstruction, Evolution, Projection三步的时候，limiter也是只在Reconstruction步起作用，Evolution步应该不起作用吧，除非在Projection步起作用？

block只要是方阵非奇异，自己也能构成一个数域(field，像整数复数一样)做加减乘除，抽象来看和单个张量没太大区别。

关键是现在sparse linear solver挺多的呀，OF为啥不直接调用呢？

p.s. 我觉得OF有一点儿我没看懂，丫的本质上是个semi-implicit的Picard迭代，我看的文献显示semi-implicit的formulation很难做到很快的加速，除非你把快的物理过程和能量占比比较小的部分搞隐式了才行。但是OF把粘性项都给搞成一半隐式一半deferred correction了，搞得特别隐式有必要么？（我对deferred correction的理解就是显式的，除非多迭代几次）

p.s.2 因为OF没有求Jacobian，是求的全量，所以我觉得它是Picard迭代，而不是Newton迭代。

youmengtian

对，您理解的没错。就是在插值的时候用到限制器。roe等得到的一阶数值通量通过插值获得二阶或者最高二阶的计算通量

youmengtian

@程迪其实调用hypre等的矩阵求解器也并非不行。不过openfoam可能考虑到效率等问题吧，这方面还真不清楚。不过原则上openfoam也能够使用第三方矩阵求解器，我觉着

程迪

@youmengtian

sorry, 没看懂，数值通量是在界面的，surfaceScalarField怎么通过限制器差值得到另一个surfaceScalarField呢？毕竟最后要求div的。

youmengtian

@程迪其实就是reconstruction

程迪

@youmengtian

我觉得会不会是lduMatrix结构比较特殊，和常见的sparse linear algebra的矩阵数据结构CCS,COO啥的都不一样。但是我觉得不应该呀，这玩意儿和directed graph的adjacency matrix表示是一样的呀。应该用得还蛮多的吧...

youmengtian

@程迪本质上就是稀疏矩阵，主要是它有自己的lduaddressing五list的存储格式相关。因此在实际求解中自己实现比较便利。

程迪

@youmengtian

嗯，关键还是写好胶水代码。

youmengtian

@程迪其实我倒是觉着，cfd-china如果希望长期发展真的也有必要维护自己的一个openfoam的版本库，自己有一个子团队独立开发。这样以后也有足够的影响力，毕竟拿代码说话更实际已写完。

CFD中文网

@youmengtian 在 OF可压流求解器中说：

cfd-china如果希望长期发展真的也有必要维护自己的一个openfoam的版本库，

之前有个第三方求解器专区，现在已经删除了，因为没人贡献代码。不过我倒是支持一些国人写的库。这方面我曾经和 @李东岳讨论过，最后不了了之。目前来看，国内估计没有人会在这方面有所贡献，按照岳哥的想法，限制性很多:big_mouth: :big_mouth:

youmengtian

@cfd-china 的确存在这个问题。之前去知乎上也有讨论，由于国内知识产权问题，做开源还是个费力不讨好的事儿

程迪

@cfd-china @youmengtian

我觉得关键的限制性因素有两个：

OF是GPL的，有传染性，修改、调用的代码必须同样以GPL开源，这就排除了收费盈利的可能性；
中国IP保护就是个SHIT，参考:

目前，中国《著作权法》和《计算机软件保护条例》并没有对开源软件进行规定。在2011年北京市海淀区人民法院一审、北京市第一中级人民法院终审判决的一起案件中，两审法院虽然都认定开源协议有效，但仍然支持违反GNU GPL协议，没有公开其新增的软件源代码的原告方未公开的源代码享有著作权。

某律师观点：本案显示了中国法院的实用主义特点。从逻辑上，法院的观点是不成立的，既然法院承认开源软件协议是有效的，那么使用开源软件开发软件者就应当遵守协议的规定，如果不遵守开源协议，其软件就不应当受到法律保护。但是目前90%以上的开源软件代码是国外开发者贡献，中国公司贡献很少，因此，不保护开源软件对国内产业影响不大，同时，目前法院需要保护国内竞争秩序，中国国内开发者不规范使用开源软件的情况比较普遍，虽然本案中的原告违反了开源协议，但其还是为软件付出了一定创造性劳动，如果不予保护，将使类似公司都面临问题，从而影响国内市场的竞争秩序。

李东岳

最近也在实现一种通量计算方法，主要用于High order kinetics based finite volume method (KBFVM)( http://www.sciencedirect.com/science/article/pii/S0021999109004070 ). 目前并没有中文文献做这个，也不知道怎么翻译。主要思想是迎风格式比较耗散，高阶格式有时会不稳定（虽然理论上TVD是稳定的） http://www.cfd-china.com/topic/729/一阶迎风的耗散性/2 于是针对我的研究领域我需要植入KBFVM（基于rhoCentralFoam）。在实现了算法之后，我发现原来和通量分裂的想法是相同的。我们这个领域叫做KBFVM，空气动力学领域称之为通量分裂？:surprised:

看来还得多涉猎，才能各个领域的技术互相贯通。

lhzhu

@李东岳从动理学方程（如BGK方程）构造连续流（NS方程）的可压缩格式，这一思路已经被发展很久了，如K. Xu(HKUST) 等人发展的Gas kinetic scheme （GKS）。另外也可以看看这个http://www.math.ust.hk/~makxu/PAPER/ohwada-2013.pdf 。

程迪

@lhzhu

BGK还是太复杂了，Kn数不太大的时候，Burnett方程也可以使使。

youmengtian

@李东岳本质上存在相关性，甚至可以在某种程度上当做一个概念范畴。我觉得现在很限制openfoam发展的就是底层稀疏矩阵了，现在的求解资源上块矩阵还是可以接受的。但是openfoam并没有在这方面有很连续的发展，或者发展计划。

李东岳

@youmengtian 发展方向这和老大的研究兴趣和资金有关。基金会老大本身燃烧出身。如果你看OpenFOAM官方版，拉格朗日、超音速、传热模型方面并没有太大改动。多相，CFD离散以及代码架构更新一直很频繁，毕竟本行。并且基金会赞助一直少。老大一直都自己干。Wikki那面老大本身是大学教授，带博士并且承接项目。大家都知道博士期间一个博士一般都能写个求解器雏形，再加上Wikki老大20多年经验，导致Extend那面各种求解器。因为最近也在看rhoCentralFoam，这个求解器只是进行了通量分裂，你们提到的Roe，WENO并没有植入进去，基金会做这个应该非常简单。但是OpenFOAM的发展取决于感兴趣的人，和资金赞助。本身做高阶格式的人非常少，再一个没有人赞助高阶格式开发，这些东西只能研究人员开发了。Wikki老大在大学很方便接项目了和申请基金了。当然，Wikki求解器比发布的还要多，并且Wikki的Extend外挂求解器是收费的。

基金会完全开源，并且并没有人提供足够的赞助，不能奢求更多。同理在中国，依据个人些许经验和百度，赞助的项目完全不够支持开发的开销。

nuaawqf

@youmengtian 目前openfoam的可压缩求解器确实没有不可压缩求解器那么强大。我也在参考densityBased求解器做一些算法植入工作。目前有人已经实现了LU-SGS方法，不知他的实现方法和blockMarix有何联系？
附上它的文章：
Shen C, Sun F, Xia X. Implementation of density-based solver for all speeds in the framework of OpenFOAM[J]. Computer Physics Communications, 2014, 185(10): 2730-2741.
Shen C, Xia X, Wang Y, et al. Implementation of density-based implicit LU-SGS solver in the framework of OpenFOAM[J]. Advances in Engineering Software, 2016, 91: 80-88.
期待进一步交流！

youmengtian

@nuaawqf 这两篇文章刚好最近在看。其中实现方法并没有涉及blockmatrix。最近着手在测试blockmatrix的灵活性，发现extend4.0版本或者3.x版本原则上可以实现不同维度数据结构以及基本运算的构建，从Vector，Tensor以及基于此的场以及矩阵数据结构都没问题。甚至感觉原则上能够实现任意多个方程的离散计算。其实如果不涉及非稳态计算（或者时间推进法？）都不会用到块矩阵。这个可以参考densitybasedturbo中的transonicSteadyMultiDesnityFoam。单纯的lusgs方法原则上也能够在不涉及blockmatrix的前提下实现，就如您提到的文章中的一篇。但是如果再加上预处理可能就有点儿无能为力了，包括一些matrix-free方法。

以上自己的一点理解，如有错误望各位斧正。希望也不会造成任何的误导，另希望有所帮助。多多交流！

李东岳

LU-SGS求解器

感兴趣的或许可以看看这个文章。

youmengtian

@李东岳谢谢，李博士！:happy: 这个帖子我也在一直跟进，目前也是我课题方面的小瓶颈。帖子提到作者的两篇文章都拜读过了，目前也在J.Blazek《computational fluid dynamics:principles and applications》找到了相关说明。同时也在关注newton一类的求解方法，最近忙完会整理一下，也期待能和各位分享。

程迪

最近看到一篇硕士论文，基于FOAM的可压缩流耦合求解器，不过是某国当地土话写的，而不是英语。。

Numerical Simulation of Compressible Flows using a Coupled Density-Based Solution Algorithm

@youmengtian
@李东岳
 @nuaawqf

李东岳

@程迪
我想我在周末的时候，会看看可压缩LU-SGS方面的论文研究一下，目前不是很理解LU_SGS的精度如何满足瞬态精度的要求。

另外对于密度基求解器，coupled耦合算法相比segregated常规的分离算法有什么优点？

程迪

@李东岳

LU-SGS是可以无矩阵非迭代求线性问题的方法。外套牛顿迭代就可以解瞬态了呀。有问题么？

对于密度基求解器，coupled耦合算法相比segregated常规的分离算法有什么优点？

感觉本质上也就是个收敛快的问题，分离相当于矩阵解法的Jacobi迭代，没有数据依赖。
耦合分点隐和全隐，大概相当于GS迭代吧。不过收敛不是快一倍两倍。而是好多倍。

程迪

https://github.com/chengdi123000/compressibleFoam/tree/of41
把 http://pavanakumar.github.io/compressibleFoam 移植到了openfoam 4.1下。里面有roe格式。没啥大区别。

youmengtian

@程迪其实也并不只是收收敛快慢的问题，还有更重要的是耦合关系的处理问题。

nuaawqf

@程迪终于找到和我研究方向相同的FOAMer了！这个代码我也研究过，虽然思路很清晰明了，与我之前Fortran编写可压缩流求解器相同。但似乎没那么FOAM了？OF里面很多东西都没有用起来，似乎只是当成了一个编程语言在用。还有一个AeroFOAM也挺久没更新了，似乎面向对象的思想更多一些？不知是否研究过？　希望以后多多交流。:cheeky:

程迪

@youmengtian

耦合关系处理好了，不久快了么？

程迪

@nuaawqf
刚把AeroFoam v1-2008从1.5移植到了201612+，感觉基本上也是另起炉灶搞的。
AeroFoam v2-2013 最新支持到2.0，更是另起炉灶，fvMesh都给加功能改了，还没有移植成功。

gyzhangqm

时隔四年了，还是没有有基于Godunov的近似通量和隐式推进方法的开源OpenFOAM application。
已有的替代解决方案是：
1、使用rhoCentralFoam的KT和KNP格式，本质上还是压力基的求解器。可能存在的问题是耗散大以及收敛性差。
2、使用foam-extend的dbnsFoam，里边有气动人常用的HLLC格式和Roe格式，但推进方法只有龙格库塔显式推进。并且Roe格式熵修正处理不好的话会有Cabuncle现象。
3、使用论文Implementation of density-based solver for all speeds in the framework of OpenFOAM作者公开的allSpeedUnsteadFoam,空间格式使用的是带低速预处理的AUSM系列格式。高超声速热化学非平衡计算中很多人喜欢使用AUSM系列的格式。但allSpeedUnsteadFoam依然只有Runge-Kutta推进。

可以按照论文Implementation of density-based implicit LU-SGS solver in the framework of OpenFOAM 的方法实现LUSGS推进方法，工作量其实很小。如果原作者能开源其lusgsFoam最好了。

不过如果想进一步实现其他隐式推进方法，还是需要搞明白blockLduMatrix，并且组装Jacobian矩阵。我想对于foam-extend的大佬来讲，他们已经实现了blockLduMatrix类，以及后续的代数方程预处理及求解器，如果实现密度基的隐式推进方法应该是易如反掌的。不过等了四年依然没有看到有进展。

空闲时间我会自己着手做这件事情。有人同样在做的话可以一起交流合作~

dzw05

@gyzhangqm 看看这个代码，https://hisa.gitlab.io/index.html

gyzhangqm

@dzw05 十分感谢！
这个似乎可以完美应用于空气动力学亚跨超和高超问题的计算。自带AUSM+up全速域通量格式和HLLC格式，有LUSGS预处理的GMRES推进方法。貌似不是Jacobian Free的。还有作者的论文。非常好的资源。
我会慢慢测试几个定常的高超算例，确定比较合适的梯度计算方法、限制器等参数。大佬多多指教~

heray

还有一个myFoam，github可以搜到，里面有个lusgsFoam求解器