CFD中文网

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

@cfd-china 确实很实用，用一次的东西就应该这样搞！:cheeky:

非常感谢谢你的回复。

不过我感觉单独这个fieldAverage并不能实现我要的功能。不过后来我的想法是写个functionObject每隔100步就触发一次重置初始场，然后再用一个fieldAverage每隔100步就触发一次，把当前步的场跟之前的average field合起来平均，并且它的window设成1，resetOnOutput设为false。

@wwzhao 这至少可以说明用icc和gcc 编译OpenFOAM出来的solver运行速度不相上下，前者平台主频略低，但支持AVX2.0。

@cfd-china 曾经在OF240上测试过： http://www.cfd-online.com/Forums/openfoam-installation/147526-howto-optimize-openfoam-core-i7-cpu-using-extended-instruction-set.html#6

有大神知道OpenFOAM里面时间上的系综平均怎么弄吗？

比如我跑一个非稳态的算例，跑到100步停。但是我每次从头开始跑到100步，物理场（比如U）结果都是不一样的（因为用的是蒙特卡洛方法）。
为了减小统计噪音，我需要这样跑10000次（每次从头开始跑100步），然后把这10000个结果平均一下（10000个U场相加除以10000）。

有没有什么functionObject可以比较方便的实现这个功能?

我查到从OF30开始有个fieldValue的functionObject有个 ensemble average选项（的。https://github.com/OpenFOAM/OpenFOAM-3.0.x/blob/4b5e129783d9bea7ea00a617b6ee3b73b0f308e4/src/postProcessing/functionObjects/field/fieldValues/faceSource/faceSource.H#L97 ），但是感觉不是我想要的（可能那个是空间上的简单平均，就是不带cell volume加权的平均）。

@张志国

您好！

谢谢关注。

DUGKS还有稍早的UGKS方法都是用一种方法统一的处理不同流域（连续流到自由分子流）的问题，这也是其名字中Unified的意思。与一般的耦合方法在不同的流域使用不同尺度的计算方法这种思路不同，所以并不需要划分流动区域。

DUGKS中所说的跨尺度应该理解为使用有限体积方法求解Boltzmann方程时，分布函数通量的计算是多尺度的。可以理解为在 时间步长 >> 分子平均碰撞时间（连续流）时，分布函数通量自动恢复到NS方程对应的分布函数通量， 而在 分子平均碰撞时间 >> 时间步长 时，自动恢复到自由分子流的对应的分布函数通量。在中间的滑移区和过渡区也是准确的。

以前一些kinetic格式并不能保证在计算连续流并且时间步长>> 平均分子碰撞时间时算得的分布函数通量能对应到NS方程的解。为了准确求解连续流这一宏观问题却需要解析到分子平均自由程这一微观尺度，所以相较而言只能算是单尺度的方法。同理，DSMC方法也受此限制，属于单尺度方法，因为DSMC方法也要求时间不长小于平均分子碰撞时间。

希望上述解释能有所帮助！

lhzhu

@cfd-china
vim + ctags

@Aeronastro 你试下在每个node的~/.bashrc添加source ~/OpenFOAM/OpenFOAM-2.4.0/etc/bashrc ..... ， 感觉是mpirun的时候，在每个node上of240还没加载。

@wwzhao 有道理！！

@wwzhao 在 有关GPU计算 中说：

GPU性价

:lol: 这个得看方法。不知道是不是OF里面的好多solver在GPU上加速效果不理想。

搞LBM的可能觉得这类显式均匀笛卡尔网格方法尤其适合GPU（相对串行CPU, 单块GPU达到2个两级加速），所以性价比比较高（显存更大点就更好了）。

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

Hi, @Aeronastro

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

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

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

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

@xuebao1989

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

@cfd-china 在 有关GPU计算 中说：

众所周知，OpenFOAM已经有了一些第三方的GPU计算包。困惑的是，目前GPU计算并没有广泛使用，其原因是因为支持CUDA的显卡比较少？还是什么？

粗略的看一下CUDA编程，如果GPU计算只是意味着调用GPU计算并且使用另外一种编译器的话。为什么会存在GPU计算不如CPU稳定的情况？

Nvidia的目前的GPU应该都支持CUDA吧。

不知道楼主说的GPU计算不如CPU稳定的是否是指的桌面级（GeForce、Titan）显卡？我感觉Tesla系列（用过C1060, K20, K40）的都还挺稳定的。桌面级显卡还有另一问题是双精度浮点数计算速度远小于单精度计算速度。而目前的Tesls系列的double都是float计算速度的一半。

使用GPU计算需要专门写在GPU执行的程序段(CUDA, OpenCL)，或者使用OpenACC这种加编译指导语句到串行代码（和OpenMP很像），再或者使用别人做好的GPU加速库。前两种方法需要专门的编译器。

@wwzhao, GPU按说也不是太贵， 一块Nvidia K40 目前两万出头都买得到(半年前就是这个价)。 跟搞两颗12 cores 的E5-2680v3 差不多的价, 要知道K40还搭载了12GB高带宽显存。

感谢管理员，

这个minimal example 不写文件确实是因为我忘了加上runTime.write():cold_sweat: 。它并不能重现我原来solver里面的问题。我再找找原因。

感谢，我看了下，UserGuide里面U28说的是把scale关掉，这会导致所有的箭头长度和箭头头部大小都一样。目前从ParaView的控制面板上还找不到保持箭头头部大小不变，而箭头长度随速度大小scale的选项。

一般的工具（Matlab, matplotlib, Paraview）里面， quiver图 里面的箭头大小都跟着箭头长度一起变，所以在矢量很小时候，效果很糟糕。如下图就是Matlab里面quiver画出来的，

不过后来找到一个比较好的办法，在latex里面使用pgfplot宏包可以解决。
比如如下代码(来自这里)

\documentclass{standalone}
\usepackage{tikz}
\usepackage{pgfplots}
\begin{document}
\begin{tikzpicture}
\begin{axis}[domain=-3:3, view={0}{90}]
\addplot3[blue, quiver={u={1}, v={(x-y)}, scale arrows=0.15}, -stealth,samples=20] {0};
\end{axis}
\end{tikzpicture}
\end{document}

可以产生画出：

可以看到箭头大小不随箭头长度改变。

有没有合适的工具可以画出如下这种速度quiver 图？ 其特征是箭头头部的大小不随箭头长度（速度大小）改变。尝试过Matlab和matplotlib 里面的quiver都不行。目前看到的比较繁琐的方法就是把每个箭头一个一个的用annotation的方式加进去。
yig

只是好奇， 比discuz 清爽多了。

感谢管理员，

这段代码是在一个函数里面写的，每一步演化这个函数都被调用一次。如果我在后面加一句df.write()就可以写了，但是这样会每一步都写一个时间目录，而不是由controlDict里面的参数控制。

这个问题可以由下面这段完整简单的代码重现，

#include "fvCFD.H"
#include "scalarIOList.H"

int main(int argc, char *argv[])
{
    #include "setRootCase.H"
    #include "createTime.H"
    #include "createMesh.H"
    scalarIOList df
    (
        IOobject
        (
             "DF",
             runTime.timeName(),
             mesh,
             IOobject::NO_READ,
             IOobject::AUTO_WRITE
        )
    );
    while(runTime.run())
    {
        runTime++;
        df = df + 1;
    }
   //  df.write();
    return 0;
}

system/controlDict 相关设置是，

startFrom       startTime;

startTime       0;

stopAt          endTime;

endTime         0.5;

deltaT          0.001;

writeControl    timeStep;

writeInterval   10;

这个拟solver跑起来，并不会每10步输出一个时间目录底下带一个DF文件。

谢谢建议，

过段时间文章投了之后我来补上。