快速上手LibreHardwareMonitor硬件监控
2026/9/19 22:50:43
简介：这份PDF资料面向CFD方向的研究生、科研人员与工程技术人员，系统讲解OpenFOAM程序开发的入门路径，帮助读者从商业软件使用者过渡到开源求解器的二次开发者。内容围绕三类应用展开：直接调用标准求解器、基于finiteVolume等类库自定义求解器，以及修改离散格式与代数求解器底层代码，并梳理了环境变量、常用shell命令、求解器与算例的文件结构等基础知识。资源包共1个PDF文件，大小约1.06MB，便于随时查阅与打印。目前已有563人学习下载，适合希望掌握OpenFOAM开发流程、理解顶层求解器编写与算例组织方式的读者，可作为入门阶段的知识框架与查阅手册。
1. 从 icoFoam 出发：为什么每个 CFD 工程师迟早都要碰 OpenFOAM 求解器源码
很多人第一次用 OpenFOAM 跑算例，流程都差不多：复制一个 tutorial，改system/controlDict、constant/transportProperties和0/下的边界条件，敲一句icoFoam，看残差曲线往下走，收工。这套流程能撑很久，直到某天你需要一个标准求解器里没有的源项、一个非牛顿黏度模型，或者想把某个中间量按自己的方式输出。这时候你会发现，改字典文件已经不够了，必须动 C++ 源码。
OpenFOAM 的程序开发门槛不在语言本身，而在于它把有限体积法、张量运算、网格拓扑、并行通信全部封装成了一套自己的类体系。你写一个求解器，本质上是在组装fvMesh、fvMatrix、volField这些积木，而不是从零写离散格式。标题里的「程序开发初步」，讲的正是从「会用求解器」跨到「会写求解器」这一步：理解icoFoam这类不可压求解器的骨架，知道wmake怎么把源码编译成可执行文件，然后能自己加一个方程、改一个模型、编出一个能跑的新求解器。适合已经能跑通算例、想往二次开发走的工程师，也适合需要定制边界条件或后处理工具的人。
2. OpenFOAM 求解器骨架与 wmake 编译链路
2.1 一个求解器目录里到底有什么
OpenFOAM 的应用代码放在$FOAM_APP下，求解器在applications/solvers里按物理领域分目录。以icoFoam为例，它的源码目录通常只有三个文件：icoFoam.C主程序、createFields.H场量初始化、Make/files和Make/options编译配置。这种「一个 .C 加几个头文件」的结构是 OpenFOAM 求解器的标准形态，读懂它比读任何文档都直接。
Make/files告诉wmake要编译哪些源文件、生成的可执行文件放哪：
icoFoam.C EXE = $(FOAM_APPBIN)/icoFoam第一行是源文件列表，EXE指定输出路径，$(FOAM_APPBIN)是环境变量，指向$FOAM_USER_APPBIN或平台相关的 bin 目录。Make/options则声明头文件搜索路径和链接库：
EXE_INC = \ -I$(LIB_SRC)/finiteVolume/lnInclude \ -I$(LIB_SRC)/meshTools/lnInclude EXE_LIBS = \ -lfiniteVolume \ -lmeshToolsEXE_INC里的lnInclude是 OpenFOAM 用wmakeLnInclude生成的软链接目录，把散落在各处的头文件聚到一起，避免写一长串-I。EXE_LIBS链接的是编译好的动态库，finiteVolume提供fvMatrix和离散算子，meshTools提供网格工具。少链接一个库，编译时就会报一堆 undefined reference。
2.2 wmake 的编译流程与常见报错
wmake不是简单的g++包装，它会读取$WM_PROJECT_DIR/wmake下的规则，根据Make/options拼出编译命令，再调用底层编译器。在求解器目录下直接执行：
wmake它会先检查依赖、生成lnInclude，然后编译。第一次编译icoFoam可能要一两分钟，之后增量编译只重编改动的文件。几个高频报错值得记住：
| 报错信息 | 原因 | 处理方式 |
|---|---|---|
undefined reference to ... | Make/options里漏了库 | 补-l链接项，重新wmake |
No such file or directory: xxx.H | 头文件路径没加 | 在EXE_INC补-I路径 |
wmake: command not found | 环境变量没 source | 执行source $WM_PROJECT_DIR/etc/bashrc |
cannot find -lxxx | 库没编译或路径不对 | 先wmake libso编库，再编求解器 |
提示：改完
Make/options后如果报错依旧，先wclean再wmake，避免旧的依赖缓存干扰。
2.3 从 icoFoam.C 看不可压求解器的主循环
icoFoam.C的主干其实很短，去掉注释和输出，核心就是建场、建网格、进时间循环、解动量方程、解压力方程、修正通量。下面这段是简化后的骨架，保留了关键调用：
#include "fvCFD.H" int main(int argc, char *argv[]) { #include "setRootCase.H" // 解析命令行参数 #include "createTime.H" // 建时间对象 #include "createMesh.H" // 建 fvMesh #include "createFields.H" // 建 p、U 等场量 while (runTime.loop()) // 时间推进主循环 { #include "CourantNo.H" // 算库朗数 // 动量预测 fvVectorMatrix UEqn ( fvm::ddt(U) + fvm::div(phi, U) - fvm::laplacian(nu, U) ); solve(UEqn == -fvc::grad(p)); // 压力修正（PISO 循环） for (int corr = 0; corr < nCorr; corr++) { volScalarField rAU(1.0/UEqn.A()); volVectorField HbyA(rAU*UEqn.H()); surfaceScalarField phiHbyA ( "phiHbyA", fvc::flux(HbyA) ); fvScalarMatrix pEqn ( fvm::laplacian(rAU, p) == fvc::div(phiHbyA) ); pEqn.solve(); phi = phiHbyA - pEqn.flux(); } } return 0; }fvm::前缀表示隐式离散，进矩阵；fvc::表示显式离散，直接算。UEqn.A()取矩阵对角，UEqn.H()取除对角外的贡献，这是 PISO 算法里构造压力方程的标准手法。solve()负责调用线性求解器，具体用哪个求解器由system/fvSolution决定。理解这段骨架，后面加源项、改模型才有落脚点。
3. 动手改一个求解器：加源项、加标量方程、编出可执行文件
3.1 复制 icoFoam 建自己的求解器目录
不要直接改$FOAM_APP下的源码，标准做法是复制到用户目录：
mkdir -p $FOAM_RUN/../applications/solvers/myFoam cp -r $FOAM_APP/solvers/incompressible/icoFoam/* \ $FOAM_RUN/../applications/solvers/myFoam/ cd $FOAM_RUN/../applications/solvers/myFoam改Make/files里的输出名，避免覆盖原求解器：
myFoam.C EXE = $(FOAM_USER_APPBIN)/myFoam$(FOAM_USER_APPBIN)指向用户自己的 bin 目录，通常在$HOME/OpenFOAM/$USER-<version>/platforms/.../bin。这样编出来的myFoam和系统自带的icoFoam互不干扰，which myFoam能直接找到。
3.2 给动量方程加一个体积力源项
假设要模拟一个带恒定体积力的流动，比如某种驱动机制，最直接的做法是在动量方程右边加一项。在UEqn构造之后、solve之前插入：
dimensionedVector g ( "g", dimensionSet(0, 1, -2, 0, 0, 0, 0), vector(0.1, 0, 0) ); fvVectorMatrix UEqn ( fvm::ddt(U) + fvm::div(phi, U) - fvm::laplacian(nu, U) == g ); solve(UEqn == -fvc::grad(p));dimensionedVector带量纲，OpenFOAM 在矩阵组装时会做量纲检查，量纲不对直接报错，这比运行时算出个错误结果强。g放在==右边表示显式源项，不贡献矩阵系数。如果源项依赖U，比如阻尼项-fvm::Sp(c, U)，就要用fvm::Sp隐式处理，否则大系数下会发散。
3.3 新增一个标量输运方程
很多定制需求是追踪一个被动标量，比如浓度或温度。在createFields.H里加场：
Info<< "Reading field T\n" << endl; volScalarField T ( IOobject ( "T", runTime.timeName(), mesh, IOobject::MUST_READ, IOobject::AUTO_WRITE ), mesh );MUST_READ表示必须从0/T读初值，AUTO_WRITE表示每个写出时刻自动保存。然后在主循环里加方程：
fvScalarMatrix TEqn ( fvm::ddt(T) + fvm::div(phi, T) - fvm::laplacian(DT, T) ); TEqn.solve();DT是扩散系数，需要在transportProperties或constant下定义。注意phi是面通量，由压力修正后更新，所以标量方程要放在 PISO 循环之后，保证用的是满足连续性方程的通量。
3.4 编译、运行与验证
改完源码后：
wmake编译成功后，把算例复制一份，在0/下补T文件，constant/transportProperties里加DT，然后：
myFoam > log.myFoam 2>&1看log.myFoam里有没有FOAM Warning或FOAM FATAL。验证新方程是否正确，最省事的办法是设一个解析解场景：均匀流场加恒定初值，看T是否按预期平流。如果结果不对，先查phi的量纲和方向，再查DT的单位，最后查边界条件类型是否匹配。
注意：新增场量后，
0/下必须有对应文件，否则MUST_READ会直接终止。并行运行时还要检查decomposeParDict和场的boundaryField是否一致。
4. 调试、并行与代码组织：让自研求解器能长期用下去
4.1 用 Info 和 gdb 定位求解器崩溃
OpenFOAM 求解器崩溃时，日志最后几行往往只给一个FOAM FATAL ERROR，信息有限。第一招是在关键位置插Info：
Info<< "max(U) = " << max(mag(U)).value() << " at time " << runTime.timeName() << endl;max(mag(U))返回DimensionedField，.value()取纯数值。把库朗数、残差、场极值打出来，能快速判断是发散还是逻辑错误。如果崩溃在库内部，用gdb挂上去：
gdb --args myFoam -case ./myCase (gdb) run (gdb) btbt打出调用栈，能看到是哪个fvMatrix操作触发的。编译时加-g保留符号，在Make/options的EXE_INC后追加-g即可。注意 OpenFOAM 的库本身可能没带调试符号，栈里会出现??，这时候重点看自己代码的帧。
4.2 并行运行自研求解器的检查清单
自研求解器要并行，前提是所有场量和矩阵操作都走 OpenFOAM 的并行接口。常见坑有三个：一是自己写的循环直接遍历mesh.C()而没考虑 halo 单元；二是新增场量忘了在createFields.H里用IOobject正确注册；三是Make/options漏了-lparallel相关库。并行跑之前先串行验证，再：
decomposePar -case ./myCase mpirun -np 4 myFoam -parallel -case ./myCase > log.par 2>&1 reconstructPar -case ./myCasedecomposePar按system/decomposeParDict切分网格，-parallel让求解器走并行分支，reconstructPar把分块结果拼回整体。如果并行结果和串行对不上，优先查边界条件的processor类型和phi在处理器边界上的守恒性。
4.3 把公共代码抽成库而不是复制粘贴
当你有三四个自研求解器，每个都复制一份createFields.H和源项代码，维护会失控。标准做法是把公共部分编成库：
mkdir -p $FOAM_RUN/../src/myLib在myLib/Make/files里写：
myModel.C LIB = $(FOAM_USER_LIBBIN)/libmyModelLIB而不是EXE，wmake libso编出.so。然后在求解器的Make/options里加-lmyModel和对应-I路径。这样改一次模型，所有求解器重新链接即可。库的接口设计上，尽量用抽象基类加runTimeSelectionTable，让模型可以在字典里按名字选，而不是硬编码在源码里。
5. 从改求解器到写边界条件：几个能立刻上手的进阶技巧
自定义边界条件往往比改求解器更实用，因为很多定制需求其实只是「入口速度随时间变」或「壁面通量按公式给」。OpenFOAM 的边界条件本质是一个继承自fvPatchField的类，编译成库后在0/U里按类型名引用。最小自定义边界条件只需要实现updateCoeffs()：
void myBCFvPatchField::updateCoeffs() { if (updated()) { return; } const scalar t = this->db().time().value(); operator==(sin(t) * vector(1, 0, 0)); fixedValueFvPatchField<vector>::updateCoeffs(); }operator==把值写进边界场，updated()防止重复计算。编成库后，在0/U的boundaryField里写type myBC;，并在system/controlDict的libs里加载libmyBC.so。这套流程和改求解器共用wmake和Make/options，学会一个另一个就通了。
验证自定义边界条件是否生效，最快的办法是在updateCoeffs()里加一行Info，跑一步看输出。如果值不对，检查db().time().value()取的是不是当前时间，以及operator==的右值量纲是否和场一致。另一个高频技巧是用foamDictionary或foamGet在脚本里批量改字典，配合自研求解器做参数扫描：
for nu in 0.001 0.005 0.01; do foamDictionary -entry nu -set $nu constant/transportProperties myFoam > log.nu$nu 2>&1 donefoamDictionary直接改字典条目，不用手写 sed，避免格式错乱。参数扫描跑完，用foamListTimes和postProcess批量提取结果，整条链路就闭环了。真正让自研求解器产生价值的，不是它多复杂，而是它能被稳定地重复调用、批量跑、和现有工具链拼在一起。
本文还有配套的精品资源，点击获取