简介这份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链接项重新wmakeNo such file or directory: xxx.H头文件路径没加在EXE_INC补-I路径wmake: command not found环境变量没 source执行source $WM_PROJECT_DIR/etc/bashrccannot 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 21看log.myFoam里有没有FOAM Warning或FOAM FATAL。验证新方程是否正确最省事的办法是设一个解析解场景均匀流场加恒定初值看T是否按预期平流。如果结果不对先查phi的量纲和方向再查DT的单位最后查边界条件类型是否匹配。注意新增场量后0/下必须有对应文件否则MUST_READ会直接终止。并行运行时还要检查decomposeParDict和场的boundaryField是否一致。4. 调试、并行与代码组织让自研求解器能长期用下去4.1 用 Info 和 gdb 定位求解器崩溃OpenFOAM 求解器崩溃时日志最后几行往往只给一个FOAM FATAL ERROR信息有限。第一招是在关键位置插InfoInfo 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 21 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而不是EXEwmake 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)); fixedValueFvPatchFieldvector::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 21 donefoamDictionary直接改字典条目不用手写 sed避免格式错乱。参数扫描跑完用foamListTimes和postProcess批量提取结果整条链路就闭环了。真正让自研求解器产生价值的不是它多复杂而是它能被稳定地重复调用、批量跑、和现有工具链拼在一起。本文还有配套的精品资源点击获取 OpenFOAM求解器开发入门：从icoFoam到自定义求解器与边界条件
简介这份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链接项重新wmakeNo such file or directory: xxx.H头文件路径没加在EXE_INC补-I路径wmake: command not found环境变量没 source执行source $WM_PROJECT_DIR/etc/bashrccannot 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 21看log.myFoam里有没有FOAM Warning或FOAM FATAL。验证新方程是否正确最省事的办法是设一个解析解场景均匀流场加恒定初值看T是否按预期平流。如果结果不对先查phi的量纲和方向再查DT的单位最后查边界条件类型是否匹配。注意新增场量后0/下必须有对应文件否则MUST_READ会直接终止。并行运行时还要检查decomposeParDict和场的boundaryField是否一致。4. 调试、并行与代码组织让自研求解器能长期用下去4.1 用 Info 和 gdb 定位求解器崩溃OpenFOAM 求解器崩溃时日志最后几行往往只给一个FOAM FATAL ERROR信息有限。第一招是在关键位置插InfoInfo 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 21 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而不是EXEwmake 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)); fixedValueFvPatchFieldvector::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 21 donefoamDictionary直接改字典条目不用手写 sed避免格式错乱。参数扫描跑完用foamListTimes和postProcess批量提取结果整条链路就闭环了。真正让自研求解器产生价值的不是它多复杂而是它能被稳定地重复调用、批量跑、和现有工具链拼在一起。本文还有配套的精品资源点击获取