企业官网建设流程全解析

简介：这份PPT面向从事三维流体动力学仿真、需要扩展Flow-3D V9.4功能的工程师、研究人员与研究生，聚焦二次开发中的客制化流程与落地要点。压缩包仅含1个PPT文件，大小约1.11MB，篇幅集中，便于快速浏览整体框架。内容以V9.4版本为基准，围绕Intel Fortran子程序客制化展开，结合边界条件与造波副程式示例，梳理可编程子程序范围、Visual Studio工程编译链接、Custom double precision前处理设置及运行验证与结果对比等关键环节，并提示源码备份、依赖项检查和常见排错思路；对理解波浪高度计算、流场速度更新如何接入求解流程也有参考价值，对版本差异、工程配置与编译产物管理也有提醒。已有1345人学习，适合具备一定Fortran与流体模型基础、希望将默认模型扩展为特定物理过程或边界条件的读者作为入门索引和流程参考。

1. 从“改参数”到“换执行文件”：flow-3D 二次开发到底改了什么

很多团队第一次做 flow-3D 二次开发，会把它理解成在前处理里多填几个数。真到现场才发现，客制化动的是 Fortran 子程序，最后要重新编译出一个执行文件，前处理还要选到 Custom double precision，否则改过的 bc.f 根本不参与计算。

FLOW-3D V9.4 的客制化不是插件机制，它更像在现有求解器骨架上换一个边界条件入口：源码里的 f、u、w 怎么赋值，编译链怎么把子程序链进新执行文件，前处理怎么识别这个执行文件，三件事必须同时对齐。

这份流程适合已经能跑通默认算例、需要做造波边界或特殊边界的人；只想点按钮出图的新手，先别碰。

2. 拆开 Cumtom_double.sln：工程结构、编译链与 bc.f 的入口

客制化工程的第一道门槛不是 Fortran 语法，而是“哪个文件会被编进去”。随软件附带的示例工程通常把解决方案、源码目录、公共 include 文件分开放置，bc.f 只是其中一个可编程子程序。先认清目录关系，后面改错文件、备份文件被误编、include 找不到这些问题会少很多。我一般会先把工程复制一份到独立目录，再动任何一行源码，避免把默认安装目录当成试验田。

2.1 解决方案与源码目录：先认清哪个文件会被编进执行文件

输入资料里给出的入口是 Cumtom_double.sln，注意这个文件名拼写是 Cumtom_double，不是 Custom_double，实际工程里先核对一遍拼写，不要凭记忆新建。用配套的 2005 版 IDE 打开解决方案后，重点看两处：解决方案资源管理器里哪些源文件参与了构建，以及 Source 目录下 bc.f、name.f 与 comdeck 目录的相对位置。常见目录形态类似下面这样，实际以工程为准：

# 常见客制化工程目录形态，仅示意层级，不要照抄文件名大小写 Cumtom_double.sln Source/ bc.f # 边界条件客制化入口，示例里改这里 name.f # 输入资料里提到的另一个源码文件 ... comdeck/ ijk.f # 网格索引宏 mijk.f # 相邻网格索引宏

这段目录示意只说明一件事：bc.f 不是孤立文件，它依赖 comdeck 下的 ijk.f、mijk.f。编译时如果 include 路径只指到 Source，而代码里写的是include '../comdeck/ijk.f'，编译器就会按相对路径往上找一层。很多“编译报错找不到 ijk.f”的根因不是文件丢了，而是 IDE 的工作目录或 include 搜索路径与源码里的相对路径不一致。先把这个关系理顺，再谈改波浪公式。

源码文件里 name.f 和 bc.f 的角色不同。bc.f 是边界条件子程序，适合做随时间、空间变化的边界赋值；name.f 更像命名或辅助入口，具体以工程里的调用关系为准。不要因为资料里提到 name.f 就顺手改它，先确认它是否被当前构建配置引用。工程里存在但未加入构建的文件，改得再多也不会进执行文件，这是后面排查“改了没效果”的第一条线索。

2.2 为什么边界条件客制化优先动 bc.f

造波、周期边界、随水深变化的入口流速，这类需求最适合从 bc.f 下手，因为边界条件子程序本来就在求解器每个时间步或初始化阶段被调用，改动点集中，回退也容易。相比去改求解器核心，bc.f 的风险边界更清楚：你只需要关心边界网格上的 f、u、w 赋值，不需要重写压力泊松或自由面重构。对模拟项目里的造波入口，常见做法就是把波高、相位、衰减项写在 bc.f 里，让边界网格按解析式更新。

但“优先动 bc.f”不等于“只改 bc.f”。输入资料里的示例还涉及 dum1、dum2、dum3 这三个量。代码里如果没有给它们赋值，就必须在前处理 prepin 里给定；如果代码里给了固定值，前处理里的同名参数可能被覆盖或忽略，具体看调用顺序。这里容易翻车：有人在 bc.f 里写了dum1=...，又在 prepin 里填了另一套数，最后结果对不上，查半天以为是公式错。我的习惯是先把三个量的来源定死，要么全在源码里给，要么全在前处理给，并在注释里写清楚单位。

另外，bc.f 的备份要放在源码目录之外，或者至少改掉扩展名。输入资料里明确提醒建议备份 bc.f，这条不是客套。备份文件如果留在 Source 目录且扩展名仍是 .f，某些工程配置会把它一起纳入编译，轻则重复符号，重则链接到旧子程序。血泪经验是：备份文件名用bc.f.bak_日期还不够稳，最好放到backup/目录，构建配置里不包含该目录。

2.3 建立可回退的工程副本：备份、版本标记与编译产物隔离

动手前先复制整个解决方案目录，不要只复制 bc.f。编译产物、工程配置、include 路径都可能影响结果。复制完成后，在副本里做三件事：备份原始 bc.f、记录当前前处理文件与前处理版本、把新生成的可执行文件放到独立输出目录。这样后面出现“结果和默认算例不一致”时，能快速回到基线，而不是在一堆中间文件里猜。

# 在工程副本根目录执行，backup 目录不要加入构建 mkdir -p backup cp Source/bc.f backup/bc.f.bak_$(date +%Y%m%d_%H%M) # 记录当前源码指纹，方便确认后面编译的到底是哪一版 sha256sum Source/bc.f > backup/bc.f.sha256

这段命令做的是可回退，不是编译。cp把 bc.f 复制到 backup 目录，文件名带时间戳，避免覆盖；sha256sum记录当前源码指纹，后面如果怀疑“编译的不是我改的那份”，直接比对指纹。注意 backup 目录不要出现在工程源文件列表里，也不要被通配符Source/*.f扫进去。编译产物隔离可以用 IDE 的输出目录设置，也可以手工把新执行文件复制到独立 run 目录，前处理文件跟着 run 目录走，别和默认安装目录混在一起。

版本标记不只是文件名。前处理文件里的版本类型要跟执行文件精度一致，输入资料里要求选 Custom double precision，这意味着你编译的是双精度客制化版本。如果工程副本里同时存在单精度和双精度两套配置，编译前看清当前活动配置，别用单精度的 obj 去链双精度的库。这个坑在后面第 5 章还会展开，这里先记住：工程副本、源码备份、输出目录三者分开，是后续所有排查的地基。

3. 改 bc.f 的造波边界：把数学式落到 f、u、w 三个数组

bc.f 里真正要改的不是一整段“波浪理论”，而是边界网格上的三个量：自由面函数 f、水平速度 u、垂向速度 w。输入资料给出的示例是一个造波边界：先算波高，再把波高换算成边界网格的 f 值，然后在自由面以下按指数衰减给 u、w。代码看起来短，但循环范围、索引宏、零值分支任何一个写错，结果都会从“波形不对”变成“第一步就发散”。这一章把公式和数组赋值拆开看。

3.1 读懂 dum1、dum2、dum3 与相位项

示例里反复出现 dum1、dum2、dum3，它们不是求解器内部保留变量，而是客制化子程序里用来传波浪参数的三个槽位。按示例的用法，dum1 参与相位中的时间项，dum2 参与空间相位和指数衰减，dum3 是波幅或与波高相关的系数。代码里用phasc=dum2*xi(imax)-dum1*t算相位，再用wvcosc=dum3*cos(phasc)、wvsinc=dum3*sin(phasc)拆成余弦和正弦分量。这里的xi(imax)是边界处的水平坐标，t是当前时间。

如果这三个量没有在源码里赋值，就必须在前处理 prepin 给定。输入资料特别提醒了这一点。实际排查时，先确认它们在前处理里的单位与源码公式匹配：dum1 如果按角频率使用，单位是弧度每秒；dum2 如果按波数使用，单位是弧度每米；dum3 如果按波幅使用，单位是米。单位不统一时，波形可能看起来“有波”，但周期和衰减完全不对。我一般会在 bc.f 开头加一段注释，把三个量的来源、单位、典型范围写清楚，后面换人接手不用靠猜。

c bc.f 造波边界片段，固定格式，注释列从 c 开始 c 先判断是否在目标边界和目标边界类型上，不满足直接返回 if(dum3.lt.ztest .or. wr.ne.6) return c 相位：dum2 参与空间项，dum1 参与时间项 phasc=dum2*xi(imax)-dum1*t wvcosc=dum3*cos(phasc) wvsinc=dum3*sin(phasc) c 右侧相邻位置的余弦项，供 u 赋值使用 wvcosr=dum3*cos(dum2*x(im1)-dum1*t) c 边界网格取 imax-1，避免把外部虚拟网格写穿 i=imax i=imax-1 c 垂直和横向循环范围由 kprb/kprt、jprf/jprb 控制 do 8000 k=kprb,kprt do 8000 j=jprf,jprb include '../comdeck/ijk.f' include '../comdeck/mijk.f' c 波高 = 静水位 + 余弦分量 fhtw=flhtr+wvcosc c 把波高换算成当前网格的 f 值，并限制在 0 到 1 fhtz=max(fhtw-z(k-1),zero)*rdz(k) fhtz=min(fhtz,one) if(fhtz.gt.ztest) then c 边界网格赋自由面函数 f(ijk)=fhtz c 相邻网格和当前网格的水平速度，按水深指数衰减 u(imjk)=dum1*wvcosr*exp(dum2*(zk(k)-flhtr)) u(ijk)=dum1*wvcosr*exp(dum2*(zk(k)-flhtr)) c 垂向速度用正弦分量 w(ijk)=dum1*wvsinc*exp(dum2*(z(k)-flhtr)) else c 自由面以下没有流体，三个量清零 f(ijk)=zero u(ijk)=zero w(ijk)=zero endif 8000 continue

这段代码的逻辑顺序是：先做入口过滤，不满足边界类型直接返回；再算相位和波高；然后把波高换算成当前垂直网格的 f 值，并用 ztest 判断是否真的有流体；最后在自由面以下给 u、w，否则清零。参数上，wr.ne.6是边界类型判断，示例里只在类型 6 上生效，实际工程要按自己的边界编号改；flhtr是静水位参考；ztest是自由面判断阈值；zero、one是求解器预定义常量，不要用0.0、1.0硬替，精度配置不同时容易出小量误差。

rdz(k)是垂直方向网格间距的倒数，z(k-1)是当前网格底高程，zk(k)是网格中心高程。max(fhtw-z(k-1),zero)*rdz(k)这一步把“波高超过网格底的距离”归一化成当前网格的流体体积分数，再min(...,one)截到 1。这个写法只适合边界网格与自由面相交的简化处理，复杂地形下要先确认网格分层是否足够。别把它当成通用波高公式，它只是示例边界的一种赋值方式。

3.2 循环范围 kprb/kprt、jprf/jprb 与 ijk 宏

示例里的三重循环只保留了两层：k=kprb,kprt和j=jprf,jprb，i 固定在imax-1。kprb、kprt 是垂直方向边界网格的起止层，jprf、jprb 是横向起止列。它们不是全局网格范围，而是当前边界面的有效范围。写错范围最典型的现象是：波形只在局部出现，或者边界角点出现异常速度。排查时先打印或在前处理里核对这四个范围，确认它们对应的是目标边界面，而不是相邻边界面。

include '../comdeck/ijk.f'和mijk.f提供的是索引宏。ijk把 (i,j,k) 映射到一维数组下标，imjk是 i-1 方向相邻网格的下标。Fortran 里数组下标从 1 开始还是从 0 开始，取决于求解器配置，不要自己手写i + j*nx + k*nx*ny。用宏的好处是网格维度变化时不用改公式，坏处是 include 路径必须对，否则编译器在第一行宏展开时就报错。实际工程里如果 comdeck 目录被移动，bc.f 里的相对路径也要跟着改，或者把 include 搜索路径加到工程配置里。

c 循环范围要和前处理里的边界网格范围一致 c kprb/kprt：垂直方向起止层，jprf/jprb：横向起止列 c i 固定为 imax-1，imjk 由 mijk.f 给出前一个 i 的索引 do 8000 k=kprb,kprt do 8000 j=jprf,jprb include '../comdeck/ijk.f' include '../comdeck/mijk.f' if(fhtz.gt.ztest) then f(ijk)=fhtz u(imjk)=dum1*wvcosr*exp(dum2*(zk(k)-flhtr)) u(ijk)=dum1*wvcosr*exp(dum2*(zk(k)-flhtr)) w(ijk)=dum1*wvsinc*exp(dum2*(z(k)-flhtr)) else f(ijk)=zero u(ijk)=zero w(ijk)=zero endif 8000 continue

这段只保留循环和赋值，方便对照。8000 continue是固定格式里的标号循环结尾，两个do 8000共用同一个标号，表示内层 j 循环结束后继续 k 循环。改代码时不要把标号写丢，也不要在循环里提前return，否则后面的边界网格不会被更新。参数说明：kprb、kprt、jprf、jprb来自前处理或公共块，具体名字以工程里的 comdeck 为准；imax是边界方向的网格上限；imjk只在 u 赋值时使用，w 和 f 不需要。

3.3 赋值顺序与零值分支：避免自由面被“抹平”

示例里先算fhtz，再判断fhtz.gt.ztest，满足才给 f、u、w，否则全部清零。这个分支不能省。曾经有人在调试时把 else 分支删掉，想让“没有流体”的网格保留上一步的值，结果自由面附近出现一层扫不掉的虚假流体，波形越跑越胖。原因是边界网格的 f 不归零，求解器会把它当成持续存在的流体来源。零值分支不是装饰，它决定了边界上“水到哪里为止”。

另一个顺序问题是 u 和 w 的赋值位置。示例里u(imjk)和u(ijk)都赋了值，w(ijk)只赋当前网格。imjk是 i-1 的相邻网格，这样做的目的是让边界附近的水平速度过渡更平滑。如果只赋u(ijk)，边界内侧可能出现速度台阶；如果两个都赋但相位用错，比如wvcosr用了wvcosc，水平速度和自由面不同步，短算几步就能看到波形扭曲。我的习惯是改完后先用一个规则波、小波幅、短时长算例跑几十步，看自由面是否连续，再放大参数。

还有一处容易忽略：exp(dum2*(zk(k)-flhtr))里的 dum2 同时出现在相位项和衰减项。如果 dum2 按波数取值，指数项会随水深快速衰减；如果按其他参数取值，衰减可能过强或过弱。示例只是给出结构，具体数值要按你的波浪理论重新推。不要直接把示例里的 dum 数值当成通用解，尤其换单位制、换网格尺度后，dum1、dum2、dum3 都要重算。这里没有“一套参数打天下”的好事。

4. 从源码到可执行文件：编译、链接与前处理版本选择

bc.f 改完只是半成品。求解器运行时读的是执行文件，不是源码。输入资料里的 Step 4 是重新生成可执行文件，Step 5 是前处理文件版本类型选 Custom double precision。这两步少一步，结果都会退回默认边界。中间章这一节把编译前检查、生成执行文件、前处理选型与短算验证串起来，重点是让“我改的代码真的进了执行文件”这件事可验证。

4.1 编译前检查：include 路径、精度宏与运行时库

打开解决方案后，先别急着点构建。检查当前活动配置是不是双精度客制化配置，检查 Source 目录下 bc.f 是否在工程源文件列表里，检查 comdeck 的相对路径能否被解析。输入资料里的代码用include '../comdeck/ijk.f'，如果工程文件所在目录与 Source 的相对关系变了，编译器会报找不到文件。常见做法是把 comdeck 放在与 Source 同级的目录，或者在工程配置里增加 include 搜索路径。两种都行，但不要一半用相对路径一半用搜索路径，后面换机器容易乱。

# 在工程根目录检查 bc.f 里的 include 路径和工程引用 grep -n "include" Source/bc.f grep -n "bc.f" Cumtom_double.sln # 确认 comdeck 相对 Source 的位置 ls -l comdeck/ijk.f comdeck/mijk.f

这段检查命令只做三件事：看 bc.f 里 include 写了什么、看解决方案文件里有没有引用 bc.f、看 comdeck 文件是否存在。grep的输出能快速暴露路径拼写问题，比如../comdeck写成了../comdeck/或者大小写不一致。Windows 下大小写通常不敏感，换到其他环境或打包后可能就敏感了。Cumtom_double.sln里能否搜到 bc.f 不是唯一判据，有些工程用通配符或项目文件引用，但至少能确认它没有被完全排除。

精度宏和运行时库也要对齐。双精度配置下，zero、one这类常量、real声明、库文件的精度后缀都要一致。输入资料要求前处理选 Custom double precision，说明执行文件是双精度客制化版本。如果编译时混入了单精度的 obj，链接可能不报错，运行时却出现自由面判断异常。排查这类问题没有捷径，只能看构建日志里的编译单元和库列表。我一般会保留一份干净的构建日志，出问题时先比对“这次编了哪些文件”。

4.2 生成新的 double 精度执行文件

在 IDE 里执行重新构建，不要只做“编译当前文件”。bc.f 编成 obj 后还要链接到求解器主程序，才能生成新的执行文件。输入资料里的 Step 4 写的是“重新生成可执行文件”，重点在“重新生成”。如果 IDE 只做了增量编译，而链接步骤被跳过，输出目录里的执行文件时间戳不会变，运行的自然还是旧逻辑。构建完成后先看输出目录的时间戳和文件大小，再看构建日志里有没有 bc.f 的编译记录。

# 构建后在输出目录确认执行文件时间戳，路径按实际工程改 ls -l run/flow3d_custom_double* 2>/dev/null || ls -l bin/*custom* 2>/dev/null # 从构建日志里确认 bc.f 参与了编译 grep -n "bc.f" build.log | tail -20

这段命令不是通用编译命令，只是构建后的核验。ls -l看时间戳，确认执行文件是刚生成的；grep看构建日志里有没有 bc.f。不同工程的输出文件名不一样，不要照抄flow3d_custom_double，按你的工程实际名字查。如果时间戳没变，先清理再重建，不要在前处理里反复改参数浪费时间。构建日志里如果只有链接没有编译，说明 bc.f 可能没被加入当前配置，回到 4.1 检查源文件列表。

生成执行文件后，不要立刻覆盖默认安装目录里的原执行文件。把它放在独立 run 目录，前处理文件也复制一份到该目录，运行时的相对路径、输入文件、输出文件都围绕这个目录组织。这样即使客制化版本有问题，默认版本还在，后悔药留好了。实际项目里我见过直接把新执行文件覆盖到默认目录，结果默认算例也跑不起来，最后只能重装。没有必要冒这个险。

4.3 在 prepin 里选 Custom double precision 并做一次短算验证

前处理文件的版本类型必须选 Custom double precision，这是输入资料 Step 5 的明确要求。选错版本时，前处理可能仍然能生成输入文件，但运行时读不到客制化入口，或者调用了不匹配的精度的库。表现不一定是报错，更多是“结果和默认一样”。所以短算验证不能只看有没有报错，要看边界处的 f、u、w 是否按你的公式变化。常见做法是先跑一个规则波小算例，输出边界附近几个网格的时序，和解析式对比前几个周期。

短算验证的时长不要一上来就跑完整周期。先跑几十到几百步，看自由面是否连续、边界网格有没有异常值，再逐步加长。输入资料里的示例是造波边界，波高、相位、衰减三个量任何一处不对，长算只会放大问题。我的习惯是：默认算例、客制化短算、客制化长算，三份结果分开存，后面写报告或排查都有基线。不要用“看起来差不多”来判断，边界处的时序曲线比云图更早暴露问题。

5. 客制化避坑：五条从编译失败到结果发散的排查记录

这一章按“现象→原因→解决”记录五条常见坑。它们不是理论问题，都是工程里反复出现的操作细节。客制化最怕黑匣子心态：编译过了就以为生效，结果跑了半天才发现前处理选的是默认版本。下面每条都给出可执行的排查动作，能少走弯路。

5.1 现象：编译通过但运行仍走默认边界

现象很直接：bc.f 改了，构建也成功了，但结果和默认算例一模一样，边界处的 f 不随相位变化。原因通常有三种：前处理版本类型没选 Custom double precision；新执行文件没有放到运行目录，实际调用的是旧文件；bc.f 没加入当前构建配置，编译日志里根本没有它。解决时先看运行目录里的执行文件时间戳，再看前处理版本类型，最后看构建日志里有没有 bc.f 的编译记录。三步都对齐后，再检查边界类型判断wr.ne.6是否把你的边界面排除了。

5.2 现象：结果第一步就发散或自由面消失

现象是短算几步后速度异常增大，或者边界附近自由面直接消失。原因常见于 dum1、dum2、dum3 没有赋值，或者单位不匹配；也可能是fhtz没有做min(...,one)截断，边界 f 大于 1；还可能是 else 分支被删掉，没有流体的网格保留了旧值。解决时先把三个 dum 量的来源固定，源码给值或前处理给值只选一种；再检查fhtz=max(...)*rdz(k)和min(...,one)是否完整；最后确认零值分支存在。短算时输出边界网格的 f、u、w，和解析式对前几个时间步，不要只看云图。

5.3 现象：前处理选错版本，读不到客制化入口

现象是前处理能生成输入文件，运行时也不报错，但客制化边界完全没有反应。原因是前处理版本类型与执行文件精度不匹配，常见于工程里同时存在单精度和双精度配置，构建时用了双精度，前处理却选了默认类型。解决时把前处理版本类型改成 Custom double precision，重新生成输入文件；同时检查构建配置里的精度宏和库文件是否一致。不要只看工程名里有没有 double，活动配置才是实际生效的那一套。

5.4 现象：备份文件被一起编译，链接冲突

现象是构建时报重复符号，或者运行结果像是旧代码和新代码混在一起。原因是bc.f.bak、bc_old.f这类备份文件留在 Source 目录，被工程通配符或手动添加进了构建。解决时把备份移到 Source 外的 backup 目录，清理工程里对备份文件的引用，重新构建。备份文件名改扩展名只能降低风险，不能完全避免通配符扫描，最稳的还是目录隔离。每次构建前看一眼源文件列表，确认只有当前要用的 bc.f。

5.5 现象：换机器后 include 找不到

现象是同一套工程在另一台机器上打开就报找不到../comdeck/ijk.f。原因是工程目录层级变了，或者 IDE 的工作目录与源码里的相对路径不一致。解决时先确认 comdeck 与 Source 的相对位置，保持../comdeck这条路径成立；如果不成立，就在工程配置里增加 include 搜索路径，或者把 comdeck 放到约定位置。不要为了临时跑通把源码里的 include 改成绝对路径，换机器又会坏。改完路径后做一次干净构建，确认日志里没有旧路径残留。

6. 验证客制化是否真的生效：三步对照与一个可复用检查表

验证不要从云图开始，云图好看但掩盖细节。我一般做三步对照：默认执行文件跑同一算例、客制化执行文件跑短算、客制化执行文件跑长算，三份结果分开存。第一步确认基线，第二步看边界 f、u、w 是否按公式变化，第三步看波形是否稳定。短算阶段输出边界附近几个网格的时序，比整场云图更早发现问题。

6.1 三步对照

第一步用默认执行文件和默认前处理版本跑一个短算，记录边界处 f、u、w 的时序。第二步换成客制化执行文件，前处理版本选 Custom double precision，其余参数不变，再跑同样的步数。第三步把两次时序放在同一张表里比对：f 是否从 0 到 1 周期变化，u 的相位是否与 f 对齐，w 的幅值是否随水深衰减。如果第二步结果和第一步完全一样，先回第 5 章查版本和执行文件，不要怀疑公式。

6.2 一个可复用检查表

这张表不替代物理验证，但能挡住大部分“改了没生效”的低级问题。从那以后我每次改 bc.f 都强制先备份、再短算、再对照默认算例，少一步都不行。希望帮到你。

本文还有配套的精品资源，点击获取