2022年第二季度工作总结

thoughts
目录

最近天气比较热，二季度工作总结拖了 22 天才写完，第三季度已经快过去四分之一，必须尽快将总结这项必须任务完结，好开启下一个阶段。

我在一季度末决定减少涉猎的工作项目，专注于工作流工具开发。 现在虽然还看不到这个决定是否正确，但有一点可以肯定，这三个月中我纠结应该做哪项工作频率明显降低，工作流工具开发也有了明显的进展。 当然，开发一个自娱自乐的项目对工作来说没有任何价值，接下来我应该继续坚持专注一个领域，把工作做深做实，争取开发出有实用的工具。

计划完成情况

第二季度工作只做了一项工作，即工作流工具开发，计划完成情况如下：

  • 工作流
    • ✔️ 模式积分流程：已实现 CMA-TYM 模式流程和 CMA-GFS 部分后处理流程
    • 🚧 功能开发：正在进行中
  • 模式要素库
    • ❌ 调研 FDB 库
    • 🚧 团队讨论：已进行一次，尚需更多讨论
  • 分布式调度
    • ❌ 分析第一季度试验结果
    • ❌ 技术报告
    • ❌ 应用：因活动推迟，保障系统尚未建立
  • 运维技术
    • ✔️ 产品消息：已测试 CMADaaS 消息
    • ❌ Redis 产品消息库
  • reki
    • ❌文档和测试用例
    • ❌ 推广
  • sokort
    • ❌ PI 预安装环境
    • ❌ 更新 JupyterHub 环境
  • meda：
    • ❌ 调研
    • ❌ 开发
  • ❌ mofis：未开展

工作

业务系统

CMA-GFS V3.3 后处理

新版 CMA-GFS V3.3 业务系统将使用 CMA-PI 上的 SSD 分区，后处理系统也同样调整到 /g0 分区下运行。 第二季度构建了 V3.3 版的后处理系统，通过业务化测试。 因为平行试验效果问题，原定于 6 月底升级切换延后到第三季度。

本次 CMA-GFS 后处理移植暴露了一个会对后续更新有潜在影响的问题：业务系统程序目录结构混乱，存在大量未使用的历史程序，需要进行整理。 实际上，业务系统运行脚本也有类似的问题，代码需要进一步规范化，尽量让各个后处理系统的相似模块从任务名称到脚本实现都保持一致。 之前也将整合系统的工作列入到计划中，但都没有实现。 第三季度可以将目标缩小一些，从整理程序目录入手，逐渐调整后处理系统的任务脚本，通过优化脚本来进一步提高系统更新工作的效率。 争取在年底前形成一套后处理系统流程建设规范。

CMA-MESO 1KM 后处理

CMA-MESO 1KM 系统的冷启动时次和暖启动时次积分开始的时间点不同，例如：

  • 冷启动 00 时从 00 点开始积分
  • 暖启动 01 时从 00 点开始积分
  • 暖启动 02 时从 01 点开始积分
  • 冷启动 12 时从 12 点开始积分

对于暖启动 2022071306 时次来说，模式积分从 2022071305 点开始，后处理产品 2022071306.000 时效对应模式积分 1 小时的结果，也就是 2022071305.001 的输出。

CMA-MESO 1KM 冷启动和暖启动模式输出与产品的对应关系

第一季度更新 nwpc-oper/nwpc-data-client 项目，支持 MESO 1KM 系统所需要的时次、时效计算功能。

MESO 1KM 暖启 modelvar 的配置文件如下：

default: NOTFOUND

file_names: 
  - modelvar{generateStartTime .StartTime -1 | getYear}{generateStartTime .StartTime -1 | getMonth}{generateStartTime .StartTime -1 | getDay}{generateStartTime .StartTime -1 | getHour}{generateForecastTime .ForecastTime "1h" | getForecastHour |printf "%03d"}00

paths:
  - type: local
    level: runtime
    path: /g2/nwp_sp/NWP_RMFS_DATA/grapes_meso_1km_new/warm/{.Hour}/fcst/grapes_model/run

其中 file_names 字段第一个文件名就包含了对时次时效的计算函数，也使用了 GOLANG 模板内置的 printf 函数。

其他

为了处理运行超时但 slurm 不退出的问题，在 CMA-MESO 后处理系统某任务的拷贝命令中添加 timeout 命令，但实际运行过程中还没有体现效果。 详情参看博文《CEMC笔记：业务系统任务运行超时的两种检测方法》。

项目

信息化工程

信息化工程方面，第二季度末终于在天擎上形成了五个主要业务系统的模式专题库，包括：

业务系统路径
CMA-GFS/CMADAAS/DATA/NAFP/BABJ/CEMC/CMA-GFS/FD-PSL/{@YYYY}/{@YYYYMMDD}
CMA-MESO/CMADAAS/DATA/NAFP/BABJ/CEMC/CMA-MESO/FD-PSL/{@YYYY}/{@YYYYMMDD}
CMA-TYM/CMADAAS/DATA/NAFP/BABJ/CEMC/CMA-TYM/FD-PSL/{@YYYY}/{@YYYYMMDD}
CMA-GEPS/CMADAAS/DATA/NAFP/BABJ/CEMC/CMA-GEPS/FD-PSL/{@YYYY}/{@YYYYMMDD}
CMA-REPS/CMADAAS/ORIG-DATA/NAFP/BABJ/CEMC/CMA-REPS/FD-PSL/{@YYYY}/{@YYYYMMDD}

同时 NMIC 也提供上述模式产品的消息通知格式和消息中间件 SDK。 基于新提供的消息通知机制，6 月份更新了产品后处理融入方案架构图，将远程运行单个容器执行算法改为运行服务化容器监听消息队列，即延续 ploto 项目的技术路线。 当然，该方案尚需更广泛的讨论，一些技术细节也需要进一步思考。 计划在第三季度开发基于消息通知的产品后处理算法触发机制，并在第三季度末初步走通完整链条。

产品后处理集约化改造方案，v2022.07.1

分布式调度

第二季度没有完成计划，没有分析测试结果，也没有撰写技术文档，仅为单位西南地区机器学习研究工作提取数据。

分布式调度项目需要从测试案例中提取通用技术，形成一个统一的框架，而不是现在这样通过各个毫无关联的例子来说明 Dask 库的用法。 我应该明确这个项目的研究目的是什么：是介绍如何将 Dask 库应用到产品制作的个例中？还是要形成以分布式调度为基础的数据分析处理技术。 同时，也需要考虑如何提供最终成果：是个例脚本？还是独立的程序库？

最理想的成果是将分布式调度功能封装成一个包，能方便编写产品制作脚本。 实际上 Dask 已经做了非常好的封装，再封装一层需要明确目的，意义不大。 但现有分散示例的方式确实不好交差，缺少一个完整的故事，会让人质疑这个项目到底做了什么。 在延续第二季度计划的基础上，第三季度要进一步思考分布式调度项目最终目标。

地球系统模式诊断软件平台

五年项目终于到了验收阶段，第二季度开始测试准备工作，编写测试文档。 第三季度将开展测试及后续的验收工作。 对于这个项目有不少感触，等到项目验收结束后再专门写一篇博文，探讨后续如何才能避免历史重演。

工具

工作流 takler

第二季度最核心的工作就是开发工作流工具 takler。 经过三个月开发，已用 takler 实现跑通一个时次的 CMA-TYM 模式系统和 CMA-GFS 模式后处理系统的数据产品部分，详情参见项目 perillaroc/cemc-takler-flows (private)。

Takler 服务执行 Shell 脚本任务示意图

Takler 服务使用异步 IO 处理客户端命令

第二季度开始仿照 ecFlow 文档为 takler 编写教程，结果发现很多基础功能都没有实现，仅完成第一部分，而且还需要根据开发进展持续修订。

撰写了两篇相关博文：

第三季度将继续编写 takler 教程，补全教程缺失的功能。 继续开发新功能，在第三季度末能完成持续运行一个业务系统。 可以是后处理系统，也可以是模式系统 + 后处理系统，考虑到个人账户的资源问题，单独运行后处理系统比较可行。

绘图整合包 sokort

修改 MESO 和 TYM 的绘图库，将硬编码目录替换为环境变量 GRAPHIC_PRODUCT_LIB_ROOT，让整合包可以在 HPC 之外环境中绘制图片。 将图形对象文件中的 docstring 移动到绘图类中，在打印图片类型时，提取绘图类的文档，并打印首行信息。 例如打印 CMA-GFS 图片列表：

python3 -u -m sokort list --system cma_gfs

部分输出如下：

cape_sfc_an_aea : CAPE
cdbz_sfc_an_aea : 雷达组合反射率
k_sfc_an_aea : GRAPES GFS 东亚 K指数
pte_p700_an_aea : 700hPa 假相当位温
pte_p850_an_aea : 850hPa 假相当位温
pwat_sfc_an_aea : 整层可降水量
qflxdiv_p700_an_aea : 700hPa 水汽通量散度
qflxdiv_p850_an_aea : 850hPa 水汽通量散度
rh2m_sfc_an_aea : 2m 相对湿度
t2m_sfc_an_aea : 2m 温度

思考

第二季度依然没有阅读多少论文、报道，也没有撰写多少技术文章和感想。 最近一年写博客次数明显减少，可能是年纪大了，还是应该多记录平时的工作心得，记录用到的一些技术。 不要害怕文章简单空洞，当成工作记录就可以了。

二季度写完两篇新闻感想：

《视界：将ECMWF新的高性能计算基础设施投入业务运行》

《视界：ECMWF模式IFS开源部分组件》

总结

虽然我一直在开发一些有用或者没用的软件工具，但今年第二季度是我第一次将工作重心确定为工具开发，将开发工作流软件作为唯一的核心任务。 两个多月的开发圆满完成了既定的目标，可以完整跑完模式积分的一个时次。 在仿制 ecFlow 教程时，发现 Takler 还欠缺很多 ecFlow 的基础功能，距离业务应用还有很远的路要走，想要达到 ecFlow 的高度则需要更长时间的积累。 专注于工具开发相当于一场赌博，毕竟还没有看到可以复制的成功路线。 不过这两天看到一个稍微有利的消息，《气象业务软件统筹发展工作方案（2022-2025年）》征求意见稿中特意强调了业务软件开发业绩，不知道在后续定稿实施阶段会不会将工具软件纳入到业务软件范畴。 无论政策如何变化，既然选择一条路，就要坚持走下去，再像之前那样频繁切换研究方向，也只会一事无成。

第二季度另一项工作是信息化工程项目。 随着项目推进，原定方案无法实现，所以第二季度根据目前已掌握的技术信息重新设计了产品制作系统的融入方案。 新方案不再将使用 ecFlow 调度作为核心，而是沿用之前青年基金课题《基于消息中间件的批量绘图调度技术》的成果，通过消息队列分发绘图任务，将一次运行的 docker 容器改为长时间运行的服务。 说到工程项目，就不能避开一个问题，即工程项目使用的核心组件是否自行开发。 在涉及工程项目方面我还是秉持自己的观点，即核心技术必须掌握在单位自己手里，工程项目仅做外围包装，但这似乎不是主流观点。 不过，第三季度我还是会尝试将已有成果引入到工程项目中，寻找一条通过工程项目落地研究成果的合适路线。

第二季度，科级内部针对未来发展方向进行多次讨论，交流促进了解，也暴露一些问题。 调动每个人的积极性向共同的目标前进，是团队保持健康发展的重要方式，需要团队带头人有足够的协调管理调度能力。 过去十年分散粗放的发展模式没有带来一个可用的平台，部门也已经意识到不能再维持现状，想要寻找可以开展团队合作的可行方向。 第二季度讨论了哪些工作方向可以做，但还没有讨论这些方向该如何做。接下来需要梳理讨论结果，进一步探讨实施方案。 未来的道路尚不清晰，还需仔细探索。

下一步工作计划

核心任务

  • 工作流：
    • 目标：连续一周运行一个完整的业务系统（后处理 or 模式+后处理）
    • 开发：根据进度逐步开发各个组件和功能

主要任务

  • 模式产品消息库
    • 消息：接收 CMADaaS 消息，开发消息工具
    • 消息库：基于 redis 建立模式产品消息库
    • 应用：对接加工流水线算法
  • 绘图调度工具 ploto
    • 绘图：集成 sokort 绘图
    • 数据：对接 CMADaas 上的模式数据集
    • 应用：研究云平台集成技术方案，寻找合适的后处理任务运行方案
  • 分布式调度技术

    延续第一季度任务

    • 试验：分析批量试验数据，开展更多试验
    • 总结：将已测试结果整理为技术文档
    • 应用：寻找其他应用场景（较难）

工具开发

  • reki

    延续第一季度任务

    • 测试：开发多环境测试代码 (CMA-PI，Linux，Cloud)
    • 文档：完善文档，为已开发功能撰写用户文档
  • nuwe-cmaddas-python
    • 文档：完善文档，为已开发功能撰写用户文档
    • 开发：仿照业务检索程序开发新功能
  • meda

    延续第一季度任务

    • 调研：调研业界主流 Python 气象绘图包，撰写调研报告
    • 开发：继续仿制业务图形，争取确定 API 接口风格
  • mofis

    延续第一季度工作

    • 随意发挥

展望

拖了太久才写完这篇总结，就不必写什么展望了。

参考

《2022年第一季度工作总结》