企业官网建设流程全解析

燃烧后CO2捕集MEA吸收过程模拟教程（15）：收敛诊断与初值工程——速率基塔不收敛的根因与对策

版本声明块

• 工具/软件：Aspen Plus（当前 aspenONE 版本，引用前需在官网核对，本系列不写具体版本号）；速率基多级分离的官方产品名为Aspen Rate-Based Distillation，文献中常称RateSep
• 语言/环境：Python 3.9+，依赖 numpy；COM 脚本另需 Windows + 本机 Aspen Plus 桌面版 + pywin32
• 本文目标：把「不收敛」从一句抱怨变成一份可执行的诊断清单——先判物理可行性，再判初值，最后才动求解器参数

一句话结论：速率基 CO₂ 吸收塔的收敛路径应当固定为「先收敛 RadFrac 平衡级塔作为初值、再切换为 Aspen Rate-Based Distillation 速率基塔」（这是 AspenTech 官方课程的教学路径），而「怎么调都不收敛」的一类常见根因是填料高度与贫液负载共同构成的物理无解——此时增加迭代次数与放宽容差都不会有用。

〇、本篇要解决的认知问题

1. 速率基吸收塔不收敛时，第一步应该做什么？为什么「调容差」往往是错的？
2. 为什么必须先收敛 RadFrac 平衡级塔、再切换成速率基塔？平衡级解到底提供了什么？
3. 速率基塔为什么对黏度、表面张力、导热系数、二元扩散系数这么敏感？缺一个会怎样？
4. 残差轨迹的「单调发散」「等幅振荡」「停滞不前」分别指向什么根因？
5. 填料高度过小为什么会导致「任何贫液负载和 L/G 都无解」？

一、机制解析

1.1 三级排查顺序（不要跳级）

第 1 级：物理可行性 ├─ 填料高度 H 是否 >= 给定捕集率下的最小填料高度？ ├─ 目标富液负载是否 <= 体系上限（文献实测 0.275-0.476 mol CO2/mol MEA）？ ├─ 目标贫液负载是否落在可实现的贫液区间（文献实测 0.075-0.239 mol CO2/mol MEA）？ └─ 若任一不满足 → 无解。求解器参数调一万次也没有用。 ↓ 通过 第 2 级：初值质量 ├─ 先跑 RadFrac 平衡级塔（AspenTech 官方课程教学路径） ├─ 把平衡级的温度剖面、各板流量、组成直接作为速率基的初值 └─ 速率基与平衡级共用同一套进料/压力/塔径输入，减少变量跳变 ↓ 通过 第 3 级：数值与子模型 ├─ 传递物性是否齐全（黏度/表面张力/导热系数/二元扩散系数） ├─ 是否过早启用了第二代速率基的膜内离散（计算量显著上升） └─ 容差：先放宽跑通、再收紧复核（而不是反过来）

为什么顺序不能反：第 1 级的失败在第 3 级看起来完全一样——都是「跑了 200 步还在跳」。只有当你能独立证明「这个工况物理上有解」时，才有资格去怀疑求解器。反过来做（一上来就调容差、调阻尼、调最大迭代数），最好的结果是侥幸收敛到一个物理上荒谬的解：例如富液负载算出 0.9 mol CO₂/mol MEA，远超文献实测上限，你会以为成功了，其实模型在骗你。

1.2 平衡级初值到底提供了什么

RadFrac 是 Aspen Plus 最常用的平衡级多级分离模型，速率基模型在其之上扩展。平衡级模型求解的是「每级的相平衡 + 物料/能量衡算」，变量数远少于速率基（后者还要解每级的传质速率与界面条件）。所以平衡级解给速率基提供的是三样东西：

1. 温度剖面：MEA 吸收塔内 40–60 ℃ 是典型设计区间（经验值，不是标准规定），但真实剖面形状（塔顶塔底的温差分布）由平衡级先算出来，比「线性插值」的猜测好得多；
2. 各板流量与组成：速率基的水力学与传质系数都依赖流量；
3. 一个已经满足总体物料衡算的状态：速率基只需要在守恒的基础上细化传质，不需要从零搜索守恒。

官方佐证：AspenTech 官方课程页明确把「Recognize the capabilities of Aspen Rate-Based Distillation for CO₂ removal modeling」和「Convert an Aspen Plus RadFrac (equilibrium) CO₂ Absorber column to a column that uses Aspen Rate-Based Distillation」列为教学要点——也就是说，「平衡级 → 速率基」是官方认可的教学路径，不是民间偏方。第 8 篇已经把这套切换的实操写过一遍，本篇补的是「切过去之后不收怎么办」。

1.3 传递物性：速率基独有的脆弱点

速率基模型显式计算界面上的质量与能量传递，因此显式要求这些传递物性：黏度、表面张力、导热系数、二元扩散系数。这与平衡级模型的差别是根本性的——平衡级只需要相平衡与焓，速率基还额外需要「传得有多快」。

对 MEA 体系，液相黏度常用 Aspen 的二次混合规则加Jones-Dole 电解质校正（LLNL/CCSI 报告口径），CCSI 的 MEA 稳态模型则专门开发了四类子模型：黏度/密度/表面张力/扩散的物性模型、水力学模型、界面面积模型、反应动力学模型，并用 NCCC 中试数据整定验证。

缺一个物性会怎样：轻则传质系数被默认值顶替（算出「能收敛但结果没意义」的塔），重则每步迭代的传质通量符号都可能在跳，表现为参数扫描到某些工况突然发散——这也解释了为什么同一套输入，在 A 工况收敛、B 工况不收敛：不是求解器不稳定，是 B 工况下的物性数据缺了或外推出了适用范围。

另一个经验性提醒：吸收塔与再生塔的常用温度区间（吸收 40–60 ℃、再生 100–120 ℃）属于典型设计区间（经验值），不得声称出自 ISO 或任何官方标准。本系列已核实的温度锚点只有三个：贫液进塔 49 ℃（Sherman FEED）、DCC 将烟气冷却至 20–25 ℃ 并增湿（TCM）、再生压力优化值 0.15 MPa 与高捕集率下 2.4 bar。

1.4 三类失败模式的轨迹特征

最后一行是经验性做法：AspenTech 的官方 FAQ 确认了第二代速率基方法把气液膜离散成小段、并可在线性或对数间距上离散，对快速反应更准但计算量显著上升。既然方程结构是「加一层离散、加一层未知量」，那么分阶段启用就是顺理成章的工程做法——但它属于常见做法，不要包装成官方推荐。

二、完整代码与逐行剖析

代码 1：残差轨迹诊断器（区分四类失败模式）

环境：Python 3.9+，仅依赖 numpy。
数据声明：本段用程序生成的示意轨迹（四条：收敛、单调发散、等幅振荡、停滞）来验证分类器。真实使用时，把iter、residual两列换成从求解器日志/报表中导出的迭代残差即可。

# 15_1_residual_diag.py —— 残差轨迹失败模式分类# 环境：Python 3.9+ / numpyimportnumpyasnpdefmake_demo_traces(n=120,seed=7):"""生成四条示意轨迹：收敛 / 单调发散 / 等幅振荡 / 停滞。 为什么要有"收敛"这条：分类器如果只会喊"有问题"，就没法用它做回归测试。"""rng=np.random.default_rng(seed)k=np.arange(1,n+1)traces={}traces["converged"]=1.0*np.exp(-0.08*k)+1e-4*rng.random(n)traces["diverging"]=1.0*np.exp(+0.03*k)+1e-3*rng.random(n)traces["oscillating"]=0.5+0.5*np.cos(0.7*k)# 等幅，不衰减traces["stagnant"]=0.30+1e-5*rng.random(n)# 长期不动但不达标returntracesdefclassify(res,tol=1e-3,trend_win=20):""" 分类规则（全部基于"轨迹形状"，不依赖任何软件内部信息）： 1) 末段均值 < tol -> converged 2) 末段均值 vs 首段均值 单调放大 -> diverging 3) 末段极差/末段均值 大且无衰减趋势 -> oscillating 4) 末段变化极小但仍高于 tol -> stagnant 为什么先用"末段"而不是全局：求解器前期本来就在大幅调整， 拿全程判断会把正常收敛过程误判成发散。"""res=np.asarray(res,float)tail=res[-trend_win:]head=res[:trend_win]iftail.mean()<tol:return"converged"# 用"末段峰值是否大于首段峰值"判断发散，比单看均值更抗噪iftail.max()>head.max()*1.5andtail[-1]>tail[0]:return"diverging"# 振荡判据：末段相对波动幅度大（>10%），且无单调趋势rel_amp=(tail.max()-tail.min())/max(abs(tail.mean()),1e-12)ifrel_amp>0.10andabs(tail[-1]-tail[0])<0.5*(tail.max()-tail.min()):return"oscillating"if(tail.max()-tail.min())/max(abs(tail.mean()),1e-12)<1e-3:return"stagnant"return"unknown"# 未知形态要显式暴露，而不是硬塞进某一类if__name__=="__main__":forname,resinmake_demo_traces().items():print(f"{name:>12}->{classify(res)}")# 预期输出：# converged -> converged# diverging -> diverging# oscillating -> oscillating# stagnant -> stagnant

反直觉之处：分类器刻意保留unknown分支。工程脚本里最危险的不是判断错，而是被迫在所有情况下都给一个答案——那会把未知形态悄悄归到「停滞」，掩盖真正的新问题。

代码 2：分阶段收敛驱动脚本（COM）

环境：Windows + 本机已安装 Aspen Plus 桌面版 + Pythonpywin32。
风险声明：Apwn.Document、InitFromArchive2、Tree.FindNode、Node.Value、Engine.Run2()、Application.Stop()、SuppressDialogs、COMPSTATUS均来自第三方可运行实现与官方示例佐证，属第三方示例，随作者更新可能失效；IAP_REINIT_SIMULATION/IAP_REINIT_BLOCK/IAP_REINIT_CONVERGENCE来自官方 VB 示例中的go_Simulation.Engine.Reinit(IAP_REINIT_SIMULATION)用法，具体常量名需在本机验证。Engine.Run2()与Run2()两种写法在不同封装/版本中都被使用过，脚本按「二者之一」做容错。

# 15_2_staged_converge.py —— 分阶段收敛驱动（先平衡级、后速率基）# 环境：Windows + Aspen Plus 桌面版 + pywin32importtimeimportwin32com.clientaswin32 PROGID="Apwn.Document"# 第三方常用 ProgID；需在本机验证ARCHIVE=r"D:\cases\mea_absorber.apw"defdispatch():returnwin32.gencache.EnsureDispatch(PROGID)defrun_with_retry(app,attempts=3,wait_s=2.0):"""Run2 双写法 + 重试。 为什么要重试而不是直接抛错：COM 调用在界面未就绪或上一次运行未完全退出时 会抛异常，但这不是模型问题；用短退避重试能显著降低脚本的假失败率。"""foriinrange(1,attempts+1):forcallin(lambda:app.Engine.Run2(),lambda:app.Run2()):try:call()returnTrueexceptExceptionasexc:print(f" 第{i}次尝试失败：{exc}")time.sleep(wait_s)returnFalsedefcomp_status(app,path=r"\Data\Blocks\B1"):"""读取块的收敛/完整状态。路径需在本机核验（不同版本节点名可能迁移）。"""try:node=app.Tree.FindNode(path)ifnodeisNone:return"PATH_NOT_FOUND"returnstr(getattr(node,"COMPSTATUS","UNKNOWN"))exceptExceptionasexc:returnf"ERR:{exc}"defstaged_solve(app):"""分阶段推进：每一步都记状态，失败就停在那一步，而不是继续往下砸。"""stages=[]# 第 0 步：只做初始化（等价于"重置"），让所有模块回到一致初态try:app.Reinit()stages.append(("Reinit()","OK"))exceptExceptionasexc:stages.append(("Reinit()",f"ERR:{exc}"))# 第 1 步：整体仿真重置（官方 VB 示例中的常量名，需本机验证）try:app.Engine.Reinit(1)# 1 占位，对应 IAP_REINIT_SIMULATION 常量stages.append(("Engine.Reinit(IAP_REINIT_SIMULATION)","OK"))exceptExceptionasexc:stages.append(("Engine.Reinit(IAP_REINIT_SIMULATION)",f"ERR:{exc}"))# 第 2 步：跑通（速率基已开，但此时用的是平衡级留下的初值）ok=run_with_retry(app)stages.append(("Run2(pass-1)","OK"ifokelse"FAIL"))print(" 块状态 =",comp_status(app))# 第 3 步：若第一遍失败，做收敛级重置后再跑（对应 IAP_REINIT_CONVERGENCE）ifnotok:try:app.Engine.Reinit(3)# 3 占位，对应 IAP_REINIT_CONVERGENCE 常量stages.append(("Engine.Reinit(IAP_REINIT_CONVERGENCE)","OK"))exceptExceptionasexc:stages.append(("Engine.Reinit(IAP_REINIT_CONVERGENCE)",f"ERR:{exc}"))second=run_with_retry(app,attempts=2)stages.append(("Run2(pass-2)","OK"ifsecondelse"FAIL"))ifnotsecond:try:app.Stop()# 等价于"停止"按钮，避免求解器继续占用stages.append(("Stop()","OK"))exceptExceptionasexc:stages.append(("Stop()",f"ERR:{exc}"))returnstagesdefmain():app=dispatch()app.InitFromArchive2(ARCHIVE)app.Visible=Falseapp.SuppressDialogs=True# 必须：收敛失败弹窗会挂死脚本stages=staged_solve(app)# 每个阶段的成败都记录下来，失败即定位forname,statusinstages:print(f"{name:45s}{status}")# 把阶段日志落盘，便于与第 14 篇的稳态筛选结果对齐时间戳withopen("converge_stages.log","w",encoding="utf-8")asfp:fp.write("stage,status\n")forname,statusinstages:fp.write(f'"{name}",{status}\n')print("阶段日志见 converge_stages.log")if__name__=="__main__":main()

上机提醒：app.Engine.Reinit(1)/Reinit(3)里的整数占位不能照抄——官方示例使用的是具名常量IAP_REINIT_SIMULATION等，Python 侧通常需要先取到这些枚举值再传参。请在本机用dir()/ 类型库查看真实枚举名后再替换；本文不臆造枚举数值。这个脚本的正确用法是「照结构改写」，不是「照数字运行」。

代码 3：物理可行性自检——最小填料高度判据

环境：Python 3.9+，依赖 numpy。
模型声明：这是一个简化示意模型（示意参数），用于演示「先判物理可行性」的思想。它把平衡线取线性、把传质单元数按对数平均推动力估算，不具定量预测能力。真实判据必须来自速率基模型本身（第 8 篇）或文献结论。

# 15_3_feasibility.py —— 最小填料高度 / 负载边界的可行性自检（示意模型）# 环境：Python 3.9+ / numpyimportnumpyasnp# 文献锚点（底账已核实）：富液 0.275-0.476、贫液 0.075-0.239 mol CO2/mol MEARICH_MAX,RICH_MIN=0.476,0.275LEAN_MIN,LEAN_MAX=0.075,0.239# 填料高度参照：Sherman 15 m（两塔并联）、TCM 24 m（三床 12+6+6 m）H_REF={"Sherman":15.0,"TCM":24.0}# 以下三个是【示意参数】，不对应任何真实体系：# 塔底混合气条件下与液相平衡的负载、塔顶出口气条件下与液相平衡的负载、传质单元高度A_EQ_BOT,A_EQ_TOP,HTU=0.60,0.12,4.0defrequired_height(alpha_lean,alpha_rich):""" 示意估算：H = HTU * NTU，NTU 用对数平均推动力估算。 推动力 d1 = A_EQ_BOT - alpha_rich （塔底：液体还能"吃"进多少 CO2） 推动力 d2 = A_EQ_TOP - alpha_lean （塔顶：贫液是否还具备吸收能力） NTU = (alpha_rich - alpha_lean) / LMDF 为什么用对数平均而不是算术平均： 塔内推动力沿高度衰减，算术平均会系统性低估 NTU（即低估所需高度）， 这正是"看起来够高、实际不够"这类判断失误的来源。 为什么要显式返回 inf： d1 或 d2 非正，代表该工况在任何填料高度下都不可能实现 —— 这正是"物理无解"与"数值不收敛"的分界线。 """d1,d2=A_EQ_BOT-alpha_rich,A_EQ_TOP-alpha_leanifd1<=0ord2<=0orabs(d1-d2)<1e-12:returnnp.inf lmdf=(d1-d2)/np.log(d1/d2)returnHTU*(alpha_rich-alpha_lean)/lmdfdefcheck(alpha_lean,alpha_rich,h_packing):"""返回 (可行性, 原因, 所需高度)。"""ifnot(LEAN_MIN<=alpha_lean<=LEAN_MAX):returnFalse,f"贫液负载{alpha_lean}超出实测可实现区间{LEAN_MIN}-{LEAN_MAX}",np.infifnot(RICH_MIN<=alpha_rich<=RICH_MAX):returnFalse,f"富液负载{alpha_rich}超出实测区间{RICH_MIN}-{RICH_MAX}",np.infifalpha_rich<=alpha_lean:returnFalse,"富液负载必须大于贫液负载",np.inf h_req=required_height(alpha_lean,alpha_rich)ifh_req==np.inf:returnFalse,"塔顶或塔底推动力非正：任何填料高度都无解",np.infifh_req>h_packing:returnFalse,f"所需填料高度{h_req:.2f}m > 现有{h_packing:.1f}m",h_reqreturnTrue,"OK",h_reqif__name__=="__main__":print(f"{'贫液':>6}{'富液':>6}{'H需(m)':>8}判定")fora_lean,a_richin[(0.09,0.45),(0.21,0.45),(0.09,0.30),(0.21,0.30),(0.05,0.45)]:ok,why,h_req=check(a_lean,a_rich,H_REF["TCM"])print(f"{a_lean:6.2f}{a_rich:6.2f}{h_req:8.2f}{'可行'ifokelse'不可行'}-{why}")# 预期输出（本机实测，塔高取 TCM 的 24 m）：# 0.09 / 0.45 -> H需 19.31 m 可行# 0.21 / 0.45 -> inf 不可行（贫液 0.21 已高于塔顶平衡负载 A_EQ_TOP=0.12）# 0.09 / 0.30 -> H需 7.16 m 可行# 0.21 / 0.30 -> inf 不可行（同上）# 0.05 / 0.45 -> inf 不可行（贫液低于实测下限 0.075，属越界）

这里对应文献结论：研究指出，在给定捕集率下存在一个最小填料高度，低于它时任何贫液负载与 L/G 组合都无法达到近似最优的富液负载。代码 3 是这个结论的可执行版本，它把「无解」拆成两类：

• 推动力型无解（d2 = A_EQ_TOP − alpha_lean ≤ 0）——贫液负载已经高到塔顶无法再吸收，此时required_height返回inf，增加填料高度、调整 L/G 都没用；
• 高度型无解（H_req > H_packing）——推动力是正的，但塔太矮，此时「加高填料」是唯一出路。

两类无解的处置完全不同，而在求解器日志里它们长得一模一样。这就是为什么第 1 级排查必须用物理判据先做分类，而不是去看残差曲线。

三、常见报错与排查

现象 1：塔收敛失败弹窗，脚本卡死
根因：未设置SuppressDialogs = True，弹窗阻塞了 COM 调用。
解法：批量脚本第一行就设app.SuppressDialogs = True；并把app.Stop()放进异常处理路径，避免求解器持续占用。

现象 2：残差单调增大，无回摆
根因：初值离解太远，或贫液负载被设到了低于可实现下限（文献实测贫液下限 0.075 mol CO₂/mol MEA）。
解法：退回 RadFrac 平衡级解作为初值；用代码 3 先做负载边界自检。不要在发散轨迹上调阻尼系数。

现象 3：残差等幅振荡不衰减
根因：循环回路（贫液 + 贫富液换热器 + 再生侧）强耦合；或速率基的传质-反应耦合步长不匹配。
解法：先把循环流股断开、给贫液一个外部固定条件跑到收敛，再闭合回路；这是常见做法，不属官方推荐。

现象 4：塔能收敛，但富液负载算到 0.7 mol CO₂/mol MEA 以上
根因：传递物性缺项被默认值顶替，传质被显著高估。注意速率基显式要求黏度、表面张力、导热系数、二元扩散系数。
解法：先检查物性方法是否覆盖 MEA-H₂O-CO₂ 全部物种；液相黏度确认是否含Jones-Dole 电解质校正；再核对算出的负载是否落在文献实测区间内。

现象 5：改用第二代速率基后立刻发散
根因：膜内离散把方程规模与刚性同时抬高，旧初值不够用；AspenTech 官方 FAQ 已说明第二代方法把膜离散成小段、计算量显著上升。
解法：分阶段启用——先无反应、再开反应、最后开膜离散；每一步都用上一步的解做初值。

现象 6：Tree.FindNode返回None却无异常
根因：COM 在路径不存在时返回None，COMPSTATUS于是永远读到PATH_NOT_FOUND。
解法：像第 13 篇那样做路径探针 + 落盘比对，升级后 diff 一次即可发现迁移断点。

四、动手练习

练习 1（轨迹分类器回归测试）
在代码 1 中把oscillating的振幅改为衰减型（乘exp(-0.02 * k)），观察分类结果是否改变。
成功判据：本机实测现判据会把衰减振荡误判为oscillating（因为末段相对波动幅度仍大于 10%，而末段首尾差仍小于半个极差）。你的任务是补一条「末段振幅衰减率」判据——例如比较末段前半与后半的极差之比——使其判为converged；补完后重测，要求 4 类示意轨迹仍全部判对，且unknown分支没有被误用。

练习 2（可行性自检）
用代码 3 扫描贫液负载 0.075–0.239、富液负载 0.275–0.476 的网格（步长 0.002），统计在 15 m 与 24 m 两种填料高度下「可行」格点占比。
成功判据（本机实测）：填料 15 m 时可行占比 16.4%（1373/8383），24 m 时 24.9%（2086/8383）；并找出使required_height返回inf的边界——本示意模型下它是一条竖直线alpha_lean = A_EQ_TOP = 0.12，说明在这个体系里「贫液负载上限」比「富液负载」更早成为瓶颈。

练习 3（分阶段收敛实验）
在你本机的 Aspen Plus 里，把吸收塔从 RadFrac 平衡级切到速率基，分别记录「直接切」与「先跑平衡级再切」两种路径的迭代次数与最终负载结果。
成功判据：能给出两组迭代次数，并说明哪一组更少；若直接切也能收敛，请把填料高度或贫液负载往边界推，直到复现不收敛，再验证「先平衡级」的救回效果。

五、小结与下一篇预告

收敛问题的本质是分级排查：先证明物理上有解（最小填料高度、负载边界），再保证初值质量（平衡级 → 速率基，官方教学路径），最后才动数值选项（容差、分阶段启用、膜离散）。传递物性是速率基独有且最容易被忽略的一环——黏度、表面张力、导热系数、二元扩散系数缺一不可，液相黏度的 Jones-Dole 电解质校正不是可选项。同时我们把经验性内容与官方结论严格分开：吸收 40–60 ℃ / 再生 100–120 ℃ 只能写成典型设计区间（经验值），已核实的温度锚点是贫液 49 ℃ 与 DCC 冷却至 20–25 ℃。

到这里，商业软件路线（第 4、8、11、13、14、15 篇）已经走通。下一篇（第 16 篇）换轨：DWSIM 开源自建路线。我们会把DWSIM.Automation.Automation3的真实方法（LoadFlowsheet、CalculateFlowsheet3、CreateFlowsheet、ReleaseResources）、属性包清单（NRTL / UNIQUAC / UNIFAC / IdealElectrolyte / CAPEOPEN，没有 eNRTL）、CAPE-OPEN 集成与位数不匹配排查一次性讲清，并处理 pythonnet 调用「属社区做法、非官方文档」这个必须标注的风险。

本篇认知问题回显（FAQ）

Q1：Aspen Plus 速率基吸收塔不收敛时，第一步应该做什么？

A：先做物理可行性自检，确认填料高度不低于给定捕集率下的最小填料高度、且贫富液负载在可实现区间内，再检查初值，最后才调数值选项。

Q2：为什么 Aspen Plus 速率基塔要先收敛 RadFrac 平衡级再切换？

A：RadFrac 平衡级解先提供温度剖面、各板流量组成与满足总体衡算的状态，变量数远少于速率基；把平衡级解当速率基初值可大幅降低发散概率。

Q3：速率基吸收塔为什么对黏度、表面张力、扩散系数这么敏感？

A：速率基模型显式计算界面传质，必须输入黏度、表面张力、导热系数与二元扩散系数；缺项会被默认值顶替，导致传质被高估、富液负载算出物理上不可能的值。

Q4：残差轨迹单调发散、等幅振荡、停滞分别说明什么？

A：单调发散多为初值太远或负载设定越界；等幅振荡多为循环回路强耦合；长期停滞多为容差过紧或物性外推，三类对策分别是退初值、断回路、放宽后复核。

Q5：填料高度过小为什么会导致速率基塔无解？

A：给定捕集率下存在最小填料高度，低于它时推动力不足，任何贫液负载与液气比组合都达不到近似最优富液负载，属于物理无解而非数值问题。