2022年第三季度工作总结
计划完成情况
核心任务
- 工作流
- ✔️ 目标：连续一周运行 CMA-GFS 后处理
- ✔️ 开发：开发时间依赖
主要任务
- 模式产品消息库
- ✔️ 消息：已接收 CMADaaS 消息，完成消息工具开发
- ✔️ 消息库：已建立基于 redis 的产品消息库
- 🚧 应用：通过 redis 产品库对接加工流水线算法
- 绘图调度工具 ploto
- ✔️ 绘图：已集成 sokort 绘图
- ✔️ 数据：通过挂载目录对接 CMADaas 模式数据集
- ❌ 应用：尚未找到适合云平台的产品后处理任务运行集成技术方案
- 分布式调度技术
- ❌ 试验：分析批量试验数据，开展更多试验
- ❌ 总结：将已测试结果整理为技术文档
- ❌ 应用：寻找其他应用场景（较难）
工具开发
- reki
- ❌ 测试：开发多环境测试代码 (CMA-PI，Linux，Cloud)
- ❌ 文档：完善文档，为已开发功能撰写用户文档
- nuwe-cmaddas-python
- ❌ 文档：完善文档，为已开发功能撰写用户文档
- ❌ 开发：仿照业务检索程序开发新功能
- meda
- ❌ 调研：调研业界主流 Python 气象绘图包，撰写调研报告
- ❌ 开发：继续仿制业务图形，争取确定 API 接口风格
- mofis
- ❌ 随意发挥
工作
业务系统
CMA-GFS V3.3 后处理升级切换
CMA-GFS V3.3 的后处理系统已在第二季度完成开发，原定于 9 月 14 日进行切换，因为当时有台风，为保证预报性能稳定，推迟到 9 月 21 日正式切换。
本次切换后有用户询问下发产品的获取渠道，升级发文通知的附件中未写出产品下发方式，未来业务每次升级的附件中最好都要明确写出下发产品的获取方式，方便用户使用。 当然这块也需要与 NMIC 进行沟通，了解不同用户的数据获取渠道。
BK 系统建设
第三季度我参与了 BK 系统的建设，包括 CMA-GFS 和 CMA-MESO 的两个简化后的后处理系统。
第二季度开发 CMA-GFS V3.3 时发现业务系统程序目录结构婚恋的问题，这次建设 BK 系统又在我搭建的产品后处理业务系统中发现两个影响可移植性的问题：
- 配置信息和流程逻辑紧耦合，无法实现一个 ecFlow 流程脚本的多次部署
比如，第三季度最多有三套几乎相同的 CMA-GFS 后处理系统在运行：业务 3.2 系统、平行试验 3.3 系统以及 BK 3.3 系统。 因为目录之类的配置项都写在代码中，一个 ecFlow 流程脚本派生出三个不同的脚本，不方便保存到版本控制系统中。 下一步需要将配置项目从流程代码中分离，放到单独的配置文件中 (YAML)，尝试使用同一个脚本 + 多个配置文件的方式来实现后处理业务系统的多次部署。
- 减少产品通过注释代码实现，缺少产品制作开关配置项设计
BK 系统的后处理部分仅需要最基本的数据产品，无需制作派生数据产品，也不用绘图。 CMA-MESO 后处理已将数据制作任务和绘图任务拆分为两个系统，CMA-GFS 后处理没有拆分。 当前，BK 系统中两个后处理系统都注释了大量无需制作产品的相关代码。 但这种方式同样无法保存到版本控制系统中，需要设计一种更灵活的产品定制系统。 其中一种方法就是为每种产品设置开关选项，下一步可以在拆分配置项和流程逻辑的基础上为产品增加配置开关，或者将每个产品做成独立的模块，在构建系统流程时动态组装。
当前产品后处理系统已逐渐暴露一些问题：
- 台风检索等模块同时出现在多个模式系统中，一次更新需要改动多个系统，重复劳动多。 需要为台风等专业产品服务构建独立的业务系统
- 基于 ecFlow 搭建的流程变动不够灵活，无法适应快速变化的产品需求，ecFlow 也不太适合制作多模式融合产品
上述第二个问题更合适的解决方案是构建独立的产品制作平台，不再依赖 ecFlow 控制产品制作流程，这也是信息化系统工程项目想要达到的目标。 不过，我一直在使用天擎和不依赖天擎之间不停摇摆，缺乏广泛调研和深入思考。 想要构建一个独立的平台需要抓紧时间明确具体方向，克服各种困难坚持下去才行。
项目
信息化工程
开发天擎数值预报数据消息接收程序，从东方通消息中间件接收数据消息，转换成 CEMC 产品消息，并保存到 Redis 数据库中。 该程序使用 Python 实现，运行在桌面电脑上，下一步需要寻找合适的方式将程序部署到服务器上。
第三季度终于实现将绘图算法部署到流水线上运行，但依然存在不少问题。 容器封装的算法不能同时运行多个镜像，导致之前预想的同时运行方案无法实现。 当前在同一个虚拟机资源中运行一个程序，通过多进程实现同时绘制多张图片，受限于申请的资料，目前只有2个进程。 我本人非常不赞成这种调度方式，不方便处理故障，无法让程序单独绘制某一张图片，同时需要更多开发工作生成日志信息才能知道图片的实际生成情况。 NCC 已集成的系统在流水线上部署了上百个任务，同一个容器可以对应多个任务，如果实在没有合适的解决方案，我们只能采用 NCC 的方式将每张图片都设定为一个任务。
工具
工作流 takler
实现了最基础的时间依赖，支持滚动运行。已成功运行 CMA-GFS 后处理系统超过一周时间（包含故障处理）。
绘图整合包 sokort
更新 sokort 软件包，支持 CMADaaS 数据挂载目录，
其他工具
没有开发
思考
没有思考
总结
总结写了这么长时间，都不要再单独总结了。
下一步工作计划
核心任务
- 工作流
- 目标：支持服务的断点重启，支持动态更新服务中的工作流树形结构
- 开发
- 设计并实现工作流定义、状态的序列化
- 实现工作流树形结构的动态更新功能
- 实现命令行客户端的等待重试功能
主要任务
- 产品制作平台
- 消息库：部署消息转存程序（Linux服务器/天擎算法）
- 应用：在 CMADaaS 上使用当前消息对接方式开展批量绘图测试
- 设计：重新设计适合 CMADaaS 平台的绘图任务调度方案（是否使用 ploto 方式，或者重新设计？）
- 探讨：构思产品制作平台的设计方案，满足不同产品制作任务的需求
- 模式产品库
- 设计：参考现有规定设计产品库文件名规范，确定产品区分方式（目录 + 文件名 vs 文件名）
- 开发：基于 CMADaaS 对象存储开发产品库
- 应用：将 CMADaaS 绘图算法生成的图片产品保存到模式产品库
工具开发
reki
延续第一季度任务（第二次推迟）
- 测试：开发多环境测试代码 (CMA-PI，Linux，Cloud)
- 文档：完善文档，为已开发功能撰写用户文档
meda
延续第一季度任务（第二次推迟）
- 调研：调研业界主流 Python 气象绘图包，撰写调研报告（是否合作开展）
- 设计：明确预期目标和开发形式，争取形成初步的合作开发机制
- 开发：从仿制业务图形开始，逐渐确定项目设计方向
nuwe-cmaddas-python（待定）
延续第三季度任务
- 待定：是否继续开发？
- NMIC 要求 CMADaaS 相关代码不管新旧都要从公网下线，待接到正式通知后本项目会转为私有项目或者直接下线，后续开发可能会搁置
- 是否有必要重复造轮子？是否应该转变一下开发方式，采用合作开发模式？
- 文档：完善文档，为已开发功能撰写用户文档
- 开发：仿照业务检索程序开发新功能
- 待定：是否继续开发？
mofis
延续第一季度工作（第二次推迟）
- 随意发挥
其他任务
分布式调度技术
延续第一季度任务（第二次推迟）
- 试验：分析批量试验数据，开展更多试验
- 总结：将已测试结果整理为技术文档
- 应用：寻找其他应用场景（较难）
年终
- 总结：完成全年工作总结
- 计划：组织内部讨论，制定明年及未来几年的工作方向
- 数据管理
- 研发支撑
- 系统建设与运行维护
- …
展望
总结写了一个月也没写完，可见整个十月都没做什么工作。 虽说因十一加上疫情十月大半月都在家办公，但老问题依然存在。 在家办公基本没什么效率，很容易就做其他事情了，而一旦兴趣转移就会占用太多精力而忽略工作任务，就连一篇小小的总结都拖着没有完成。
第四季度又到了收尾总结的时候，而且今年的年度总结和明年的工作计划一定会提前布置。 现在最急迫的事情是回到工作中，以工作流工具开发为核心开展计划中的各项工作，至少不能在上班期间浪费时间。
数值预报支撑工作并不只有我们一个部门在做，NMIC 改组后 Advanced Computing Division 中的 Intelligent Application Support Section 就从事相关工作。 该部门的一个职责是负责 Version Control、Workflow Engine 等 NWP Suport 相关 Software、Compute Resource unified management software system 的开发。
有竞争就会带来压力，而且负责超算硬件维护的 NMIC 部门在部署方面一定会占据巨大的优势，但我们作为用户方依然能决定最终使用哪种工具，在竞争中不一定会处在劣势。 存在竞争也是一件耗时，说明数值预报支撑工作也是不可缺少的一个部分，值得花大力气去攻关。
期望我在接下来的一个月或两个月时间抓紧开发工作流软件，争取年终总结时能拿出一个看得过去的版本。
