CFD求解任务无人值守自动启停实践方案

一、场景与痛点：为什么必须做无人值守

在流体仿真（CFD）工程实践中，有一类任务天然具备“长周期、多阶段”的属性：整体计算被拆分为几十甚至上百个连续推进的步，第 N+1 步必须以第 N 步的结果为初场继续求解，编号从 001 一路接力到 099，总时长以月计。这类任务通常伴随三个现实问题。

1. 大模型启动阶段的内存报错。 规模较大的定义文件在启动时，求解器需要在内存中一次性完成网格与物理模型的装配，若可用内存不足或地址空间受限，就会在启动阶段直接抛出内存错误。这一问题在带图形界面的桌面操作系统上尤其常见：图形环境本身占用资源，且内存分配策略对大块连续内存的申请并不友好。业界通行的做法是把这类重负载计算迁移到服务器端环境（以 Linux 为代表）执行——64 位系统地址空间充裕、无图形界面开销、批处理与远程管理生态成熟，配合本地并行能显著降低启动失败概率。

2. 人工无法持续在线。 若每一步都靠人工“点开始、盯进度、掐时间、点停止”，计算链越长人力成本越高；夜间与节假日更是无人响应——要么机器算完后空转数小时没人接续下一步，要么某一步早已报错退出却无人察觉。

3. 单步时长难以拿捏。 单步跑太久，一旦发散或参数不当，浪费的就是几天时间；单步跑太短，频繁启停又会带来装配与读写开销。理想模式是“每步跑满固定时长、到点优雅停下、自动进入下一步”，让整条链以稳定节拍自动推进。

针对上述问题，本文给出一套纯 Shell 实现的自动化方案，把“启动 → 限时运行 → 优雅停止 → 接续下一步”做成闭环。

二、方案总体设计

整体思路一句话概括：以结果文件接力组织计算链，以停止标志文件控制单步时长，以后台进程管理串起全流程。 下文涉及的文件命名（结果文件 .res、运行目录 .dir、停止文件 stp）均为示例，请以你所用求解器的实际约定为准。

2.1 计算链的组织：结果文件接力

把每个计算步的输入定义为上一步的输出结果文件，编号统一为三位数字，用 printf "%03d" 生成。三位定长编号有两个好处：一是字典序与数值序一致，文件列表的排序即时间序，排查问题一目了然；二是编号天然对应“步次”，便于日志与结果文件对账。脚本从 001 出发，循环执行 001→002、002→003……直至 098→099，共 98 次接力。

2.2 停止标志文件：优雅停机的关键

成熟求解器通常提供某种“优雅停止”通道，本方案采用停止文件机制：求解器在迭代间隙轮询自己的运行目录，一旦发现约定名称的标志文件（示例命名为 stp），便结束当前迭代、正常写出中间结果后退出。相比直接杀死进程，其价值在于磁盘上的结果是完整、可续算的——这是接力链能成立的前提。由此派生出单步时长控制方法：启动求解器后开始固定时长倒计时（本例 4 天，即 345600 秒），到点即在运行目录创建停止文件，求解器随即优雅退出。这样既保证每步“最多跑 4 天”，又保证停下时结果完好。

2.3 时间节拍：4 天运行 + 30 分钟缓冲

时间轴设计为两段：启动后立即开始 4 天倒计时，期间求解器在前台计算、脚本在后台守时；倒计时结束后创建运行目录与停止文件，触发优雅退出；再留 30 分钟（1800 秒）缓冲，给求解器足够时间完成当前迭代、落盘结果并正常退出；随后探测进程状态，若仍在则阻塞等待，最后编号加一进入下一轮。缓冲期不可省略：优雅退出并非瞬时完成，大规模结果落盘可能耗时不短；缓冲不足会导致脚本在结果尚未写完时就推进到下一步，接力链就此断裂。

2.4 进程管理三件套：&、$! 与 kill -0/wait

• 用 & 把求解器放到后台执行，主脚本得以继续跑倒计时，两条时间线互不阻塞；
• 启动后立即用 $! 捕获子进程 PID，它是后续所有状态探测的句柄；
• 用 kill -0 PID 做零信号探活：不发送任何真实信号，只检测进程是否存在。注意两点：其一，它只说明“进程还在”，不代表“计算健康”；其二，对尚未被回收的僵尸进程，kill -0 同样返回成功，因此后续仍需用 wait 正式回收子进程并获取退出码，避免僵尸进程残留。

三、关键实现细节

3.1 带实时输出的倒计时函数

直接 sleep 345600 的最大问题是：数天之内终端毫无动静，运维人员无从判断是“正常等待”还是“脚本卡死”。改进方案是逐秒递减并用回车符 \r 原位刷新，实时打印剩余秒数：

countdown_sleep() {
    local total_sec=$1 msg=$2 sec
    echo "$(date '+%F %T') [INFO] ${msg} (共 ${total_sec}s)"
    for ((sec = total_sec; sec > 0; sec--)); do
        printf "\r%s [INFO] 剩余 %6d 秒" "$(date '+%F %T')" "$sec"
        sleep 1
    done
    echo -e "\n$(date '+%F %T') [INFO] 倒计时结束"
}

函数把“总时长”与“提示消息”参数化，4 天与 30 分钟两处等待复用同一实现，所有时间点均带时间戳，便于事后审计。

3.2 前置校验与快速失败

每轮循环开始前先做校验，任何一项不满足立即退出：一是当前步的输入结果文件必须存在；二是（建议补充）工作目录所在分区的剩余空间要高于阈值。无人值守脚本最忌讳“带着错误继续跑”——宁可当轮快速失败并告警，也不要让 98 步接力在某一环悄悄断掉。

3.3 一个高频语法坑

这类脚本最常见的报错来自 while[ 与 if[：Shell 语法要求方括号与关键字之间必须有空格，正确写法是 while [ ... ] 与 if [ ... ]。此外，所有变量展开建议加双引号（如 "$cur_res"），避免路径中含空格时被错误拆分。

四、完整参考脚本

下面的脚本实现了完整的接力与限时节拍。其中求解器命令路径及命令行参数名仅为示意，请按你所使用求解器的手册替换：

#!/bin/bash
# ================= 可配置区 =================
BASE_DIR="/data/cfd/case"                  # 工作目录
PREFIX="case"                              # 文件名前缀
SOLVER_CMD="/opt/cfd/solver/bin/solver"    # 求解器可执行文件,按实际环境修改
PART_NUM=16                                # 并行分区数
RUN_SECONDS=345600                         # 单步限时:4天
DRAIN_SECONDS=1800                         # 优雅退出缓冲:30分钟
START_NUM=1                                # 起始编号(支持断点续跑)
MAX_NUM=99                                 # 终止编号
# ============ 工具函数:带实时输出的倒计时 ============
countdown_sleep() {
    local total_sec=$1 msg=$2 sec
    echo "$(date '+%F %T') [INFO] ${msg} (共 ${total_sec}s)"
    for ((sec = total_sec; sec > 0; sec--)); do
        printf "\r%s [INFO] 剩余 %6d 秒" "$(date '+%F %T')" "$sec"
        sleep 1
    done
    echo -e "\n$(date '+%F %T') [INFO] 倒计时结束"
}
# ==================== 主循环 ====================
current_num=$START_NUM
while [ "$current_num" -lt "$MAX_NUM" ]; do
    next_num=$((current_num + 1))
    cur_res=$(printf "%s/%s_%03d.res" "$BASE_DIR" "$PREFIX" "$current_num")
    next_base=$(printf "%s/%s_%03d" "$BASE_DIR" "$PREFIX" "$next_num")
    run_dir="${next_base}.dir"
    stop_file="${run_dir}/stp"
    # 1. 前置校验:输入不存在,快速失败
    if [ ! -f "$cur_res" ]; then
        echo "$(date '+%F %T') [ERROR] 输入文件不存在: $cur_res,中止"
        exit 1
    fi
    # 2. 磁盘水位校验:剩余少于10GiB直接中止(阈值按结果体量调整)
    avail_kb=$(df -Pk "$BASE_DIR" | awk 'NR==2 {print $4}')
    if [ "$avail_kb" -lt 10485760 ]; then
        echo "$(date '+%F %T') [ERROR] 磁盘剩余空间不足,中止"
        exit 1
    fi
    echo "$(date '+%F %T') [STEP ${current_num} -> ${next_num}] 启动求解器..."
    # 3. 后台启动求解器并捕获PID(参数名按所用求解器手册替换)
    "$SOLVER_CMD" \
        --input "$cur_res" \
        --double \
        --partitions "$PART_NUM" \
        --parallel "Local Parallel" \
        --output "$next_base" &
    solver_pid=$!
    # 4. 限时运行:倒计时结束后创建停止文件,触发优雅退出
    countdown_sleep "$RUN_SECONDS" "第 ${current_num} 步限时运行中"
    mkdir -p "$run_dir"
    touch "$stop_file"
    echo "$(date '+%F %T') [INFO] 已创建停止文件: $stop_file"
    # 5. 缓冲期:等待求解器落盘并退出
    countdown_sleep "$DRAIN_SECONDS" "等待求解器写出结果并退出"
    if kill -0 "$solver_pid" 2>/dev/null; then
        echo "$(date '+%F %T') [INFO] 求解器仍在收尾,阻塞等待其退出..."
        wait "$solver_pid"
    fi
    echo "$(date '+%F %T') [INFO] 本步结束,进入下一步"
    current_num=$next_num
done
echo "$(date '+%F %T') [INFO] 全部步骤(${START_NUM} -> ${MAX_NUM})执行完成"

五、健壮性增强建议

1. 提前发现求解器崩溃。 上述节拍有一个隐患：若求解器在第 1 分钟就崩溃，脚本仍会傻等满 4 天才推进。增强方法是在倒计时循环中顺带探测进程存活，一旦消失立刻终止等待并转入异常处理（校验结果完整性、重试或告警）：

countdown_with_watch() {
    local total_sec=$1 watch_pid=$2 sec
    for ((sec = total_sec; sec > 0; sec--)); do
        if ! kill -0 "$watch_pid" 2>/dev/null; then
            echo "$(date '+%F %T') [WARN] 求解器已提前退出,终止等待"
            return 1
        fi
        printf "\r%s 剩余 %6d 秒" "$(date '+%F %T')" "$sec"
        sleep 1
    done
    return 0
}

1. 检查退出码。 wait 之后取 $?，非零说明该步异常，应记录日志并按策略决定重试还是暂停整链，而非无条件续跑。
2. 日志留痕。 全部输出重定向追加到带日期的日志文件，例如 nohup bash run_chain.sh >> chain_$(date +%F).log 2>&1 &；日志是事后审计与排错的唯一依据。
3. 断点续跑。 把起始编号做成命令行参数（如 bash run_chain.sh 57 表示从 057 续跑），某步失败修复后无需从头再来。
4. 会话托管。 长脚本务必脱离登录会话运行：可用 nohup、终端复用工具，或注册为系统服务托管；若迁移上云，也可依托百度智能云等云平台的云服务器承载计算，并配合日志服务、监控告警等通用能力实现远程运维与异常通知。
5. 信号处理。 用 trap 捕获中断信号，退出前清理后台子进程，避免脚本被终止后求解器变成孤儿进程继续空占算力：

cleanup() {
    [ -n "${solver_pid:-}" ] && kill "$solver_pid" 2>/dev/null
    exit 1
}
trap cleanup INT TERM

1. 时钟同步。 数月级倒计时依赖系统时钟，建议开启网络校时，并确认服务器时区与日志时间戳一致，避免排错时被时间差误导。
2. 双精度与分区数权衡。 双精度提升数值稳健性但内存占用约翻倍；分区数应与物理核数匹配，盲目调大反而增加通信开销。遇到启动期内存报错，可先降低分区数再评估内存余量。

六、常见问题排查

• 创建了停止文件但求解器没停？ 依次核对：文件名拼写、文件是否位于该作业的运行目录、所用求解器是否支持该机制，并检查求解器输出中是否有识别到停止请求的记录。
• 停止后结果文件不完整？ 多为缓冲期不足，可加大缓冲秒数，或在推进前增加结果文件存在性校验。
• kill -0 显示存活但计算疑似卡死？ 探活只能证明进程存在，建议叠加日志关键字或迭代进度心跳做二次判断。
• 脚本退出了，求解器还在跑？ 检查是否遗漏 wait 回收与 trap 清理。
• while[、if[ 直接语法报错？ 补上空格即可。

七、小结

无人值守的本质是三件事的自动化：任务的接续（结果文件接力）、时长的控制（停止标志文件 + 固定倒计时）、状态的确认（PID 探活 + 退出码回收）。把这三件事封装进一个带日志、带校验、可断点续跑的脚本，再辅以会话托管与监控告警，数月级的仿真链条就能在无人干预下稳定推进。方案不依赖任何图形界面，全部逻辑由标准 Shell 完成，稍加改造即可适配不同求解器的启动参数与文件命名约定。