NWPC笔记:构建图片产品制作脚本
之前的文章《NWPC笔记:构建图片产品制作系统》介绍如何使用 ecFlow 构建图片产品制作系统,主要侧重在后处理系统的流程设计方面,即如何使用 ecFlow 的 Python API 构建系统流程。
本文进一步介绍如何设计图片产品制作任务的脚本执行逻辑,方便快速添加新的绘图任务。
图片产品制作
NWPC 目前使用多种绘图软件完成业务产品的图形绘制,包括 GrADS、NCL、IDL 等。 我负责建设和维护的后处理系统主要使用 NCL 脚本绘制图片,具有相似的执行逻辑。
NWPC 基于 NCL 开发绘图库 ncllib,提供通用的绘图功能。 所以业务系统直接调用的 NCL 脚本侧重在数据处理、样式选择等方面。 不过,我只关注绘图脚本向外部提供的接口。
因为 NWPC 发布的每类图片产品的样式都是固定的,所以绘图样式被隐藏在 NCL 脚本中。 仅需要通过输入参数确定使用的数据,就可以完成绘图。
业务系统中使用的 NCL 绘图脚本主要需要以下的参数用于确定使用的数据文件:
- 时间信息,比如起报时次、预报时效等
- 数据信息,比如数据目录、图片输出目录等
需要注意的是,参数中并没有显示指定数据文件名,因为某些图形可能需要使用多个数据文件。 文件名信息被隐藏在 NCL 脚本中。
注:文件名信息隐藏可以简化接口,但会影响绘图脚本的通用性。 可能也间接导致每个业务系统都有自己的绘图脚本(当然,还有其它更重要的原因)。
获取输入参数有以下几种方式:
- 命令行参数
- 环境变量
- 参数文件
另外,还包括从当前目录获取数据文件等隐含约定。
图形绘制任务就是要按照 NCL 脚本的需求准备数据,设置需要的环境变量,准备参数文件,并调用 NCL 命令。
下一节介绍在 GRAPES MESO 3KM/9KM 图片制作系统中使用的绘图任务设计方案。
设计方案
绘图任务一般包含下面几个步骤:
- 准备数据
- 准备绘图脚本运行环境
- 执行绘图脚本
- 分发绘图结果
下图是 GRAPES MESO 3KM/9KM 图片制作系统中绘图任务的流程示意图。
系统中 initial
任务负责监听数据产品制作系统生成的 GRIB2 文件。
每当检测到一个时效的文件已生成,该任务就在系统运行目录的 data
目录下创建该文件的链接,并发出相应时效的 ecflow 事件。
绘图任务按不同的类型组织,每种绘图任务的不同时效图片都在各自独立的目录中制作。
例如,meso_cn/cn_500height_850wind
的 001 时效图片会在 ${run_base}/graph/meso_cn/cn_500height_850wind/001
目录中制作。
绘图任务可能只需要当前时效的数据,也可能需要前面时效的数据。
为了进一步简化绘图任务脚本,系统将 data
目录中的所有已检测到的 GRIB2 数据都连接到运行目录中。
同时,系统通过设置多个触发器,保证绘图任务运行时,所需的数据都已经被链接到 data
目录中。
因此,GRAPES MESO 3KM/9KM GRAPH 系统的绘图任务完成以下操作:
- 准备运行目录
- 链接 ncllib 库
- 链接 data 目录下的所有数据
- 生成参数文件 grapes_meso_data
- 执行绘图脚本
- 重命名图片文件
- 将图片文件拷贝到归档目录
对于不同的绘图任务,1 - 4 步骤完全相同,可以同一个脚本实现。 而 5 - 6 步骤虽然不同,但代码行数较短,可以为每个任务创建单独的脚本。
另外,系统将 FTP 分发任务放到独立的 upload 任务中,也可以按照类似的方式将任务分成通用脚本和独立的任务脚本。
上传任务完成以下操作:
- 准备运行目录
- 检测输出文件
- FTP 传输
- 检测上传是否成功
其中 1 和 4 两个步骤是通用的,2 和 3 步骤则需要单独编码。
实现
下面分别介绍图片绘制任务和上传任务的具体实现脚本。
绘图任务
绘图任务脚本首先执行通用脚本,再执行与绘图任务相关的具体绘图任务。
通用脚本
创建运行目录,并清空目录下所有文件
test -d ${plot_dir} || mkdir -p ${plot_dir}
test -d ${current_forcast_hour_run_dir} || mkdir -p ${current_forcast_hour_run_dir}
cd ${current_forcast_hour_run_dir}
rm -rf *
准备 ncllib 库
cp ${script_dir}/ps2gif_NoRotation_NoPlot.scr .
ln -sf ${ncl_lib}/gsn_code.ncl .
ln -sf ${ncl_lib}/gsn_csm.ncl .
ln -sf ${ncl_lib}/GFS_T639.ncl .
ln -sf ${ncl_lib}/cn_map_function.ncl .
ln -sf ${ncl_lib}/common.ncl .
ln -sf ${ncl_lib}/data_file_name.ncl .
ln -sf ${ncl_lib}/ncl_variable.ncl .
ln -sf ${ncl_lib}/region.csv .
ln -sf ${ncl_lib}/contributed.ncl .
ln -sf ${ncl_lib}/lib .
生成参数文件 grapes_meso_date
export NEWDATE=$(smsdate ${local_start_time} +${forecast_hour} )
cat > grapes_meso_date << EOF
${local_start_time}${forecast_hour}
${NEWDATE}
EOF
链接 data 目录下的所有文件
ln -sf ${orig_grib_data}/* .
绘图脚本
包含通用脚本
%include <plot_task_common.ecf>
执行绘图脚本
ncl ${script_dir}/grapes_meso_3km_500_height_850hPa_wind.ncl
重命名图片文件
./ps2gif_NoRotation_NoPlot.scr
cp GRAPES_MESO-3KM-500hPa-height-850hPa-wind-speed-${local_start_time}_${forecast_hour}.png \
SEVP_CNWP_NWPR_SRGRP_EGHEDA_ACHN_L50A85_P9_${local_start_time}00${forecast_hour}03.png
拷贝图片文件到归档目录
cp SEVP*.png ${plot_dir}/.
上传任务
通用脚本
进入绘图任务的运行目录
local_start_time=${START_TIME}
test -d ${plot_dir} || mkdir -p ${plot_dir}
test -d ${current_forcast_hour_run_dir} || mkdir -p ${current_forcast_hour_run_dir}
cd ${current_forcast_hour_run_dir}
上传脚本
执行通用脚本
%include <upload_task_common.ecf>
检测图片文件是否存在
file_name=SEVP_CNWP_NWPR_SRGRP_EGHEDA_ACHN_L50A85_P9_${local_start_time}00${forecast_hour}03.png
if [ ! -f ${file_name} ]; then
we_got_an_error 'image not found'
fi
执行 FTP 上传
if [ "${FLAG_UPLOAD_GRAPH}" = ".true." ];then
# ftp
...skip...
fi
使用通用脚本检查上传是否成功
%include <check_ftp_output.h>
检查上传
使用 grep
判断是否无法连接的 FTP 服务器
NCONNECT=0
NCONNECT=`grep 'Not connected' %ECF_JOBOUT% |grep -v grep|wc -l`
if [ $NCONNECT -ne 0 ] ;then
echo "The net broken! Check the net work!!! "
error
fi
背景
虽然在一季度总结中我提到将在二季度使用最短的时间完成业务系统升级任务,但实际上整个 5 月中下旬都在进行与 GRAPES MESO 3KM 升级相关的系统建设工作。 其中就包括将 GRAPES MESO 10KM 的图片产品迁移到 GRAPES MESO 3KM 和 GRAPES TYM(GRAPES MESO 9KM)。
我个人认为,我们单位尚未形成业务系统建设的统一标准,对如何快速构建 ecFlow 系统也没有形成共识。 但这仅仅是我的个人观点,正如最近在讨论业务运维优化方案时大家提到应该加强对所有业务系统的了解一样,可能我只是不清楚其他同事是否已形成具有通用性的系统建设模式。
因为我负责 5 个模式的后处理系统建设,所以我一直在寻找能快速构建产品后处理系统的方法。 此次 GRAPES MESO 3KM 升级可能是最后一次在 ecFlow 上的大规模尝试。 部门已计划将产品后处理迁移到将于明天(2020年6月1日)业务化的气象大数据云平台(即天擎)上。
迁移方案正在通过工程项目进行试点开发,并已形成基本的实施路径。 不过,我觉得不应该放弃在工作流软件 SMS/ecFlow 上获得的业务系统建设和维护经验。 即便新的环境提供新的工具,我们也应该在已有经验的基础上开发新的业务系统,而不是完全放弃过去十多年的积累。
新的平台需要新的思路。不过鉴于目前每人负责各自不同任务的相对独立的工作方式,迁移到新平台会带来更严峻的挑战和更激烈的冲突。
我是否准备好了?值得思考。