王传军, 王德清, 肖 健, 尹树成, 王 锋,范玉峰, 和寿圣, 丁 旭
(1.中国科学院云南天文台,云南昆明 650216;2.中国科学院天体结构与演化重点实验室,云南昆明 650216;3.中国科学院大学,北京 100049;4.天津大学智能与计算学部,天津 300350;5.广州大学天体物理中心/物理与电子工程学院,广东广州 510006)
天文学从肉眼观星到通过望远镜观星,从全波段天文学到多信使天文学,人类认识宇宙的手段逐渐丰富。2017年10月16日,全球多国科学家同步举行新闻发布会,宣布人类第1次直接探测到来自双中子星合并的引力波,并同时“看到”这一壮观宇宙事件发出的电磁信号①http://news.ifeng.com/a/20171016/52663786_0.shtml。引力波提供了一种与以往观测方式完全不同的手段,天文学研究已进入大数据、多信使时代[1]。
在观测手段丰富的同时,大型望远镜的观测数据量也越来越大[2],这些海量天文数据对存储、计算、网络、软件、算法乃至工作模式等提出了新的需求[3]。天文学家需要将庞大的数据进行标准化的存储及传输,FITS(Flexible Image Transport System)文件格式已成为天文数据的通用标准[3-4]。FITS文件包括文件头和数据矩阵两部分,可以扩展,但文件大小必须是2 880字节的整数倍。在对观测数据进行入库管理时,将FITS头关键词的值也进行入库归档,从而便于后续的检索访问[5]。虽然在观测数据的FITS头中,已经记录了大部分信息,但是这些FITS头信息的内容却由于来自不同的终端而千差万别,而且有些终端观测数据的FITS头中包含的信息不完整,商品化终端设备的FITS头内容更是无法进行修改和补充。因此,在获取观测数据的过程中,往往需要观测日志对观测过程中的详细情况进行记录,以便对观测数据进行更好的分类管理。
光学望远镜的观测日志是在使用光学望远镜及其观测终端进行观测的过程中记录的相关信息的文档,内容包括望远镜、选用的观测终端、观测目标、曝光时间、选用的滤光片或光栅、观测类型、狭缝、数据采集时刻等。对于用户而言,观测日志是处理数据必须依赖的文档,观测日志中提供的信息往往能给观测数据的处理带来便利。对于各台望远镜的运行和维护而言,观测日志为观测数据的存储、归档、预处理和后期发布提供依据,参照观测日志可以在预处理时剔除无用数据,并根据观测条件对数据进行更好的预处理,对观测数据的分类管理也提供了便利。此外,对于做数据统计的用户而言,观测日志更加重要,通过查找多年的观测日志,可以快速查询到同一目标不同时间观测过的数据,提高观测数据查找和统计的效率。
在丽江2.4 m望远镜的实际观测过程中,首先由用户给观测助手提供观测目标的坐标信息及观测需求,观测助手将观测目标输入望远镜控制系统并驱动望远镜指向目标,根据用户的需求对观测终端进行对应的配置,在望远镜和观测终端准备就绪后开始曝光,同时记录观测日志。在目前的观测模式下,观测日志的记录依赖于观测助手或者用户手工记录,在观测过程中时间有限,手工记录的观测日志难免存在笔误,影响观测效率,此外纸质版的日志也不利于保存和传播。为了保证观测日志记录的准确性,减少观测日志记录的时间,提高观测效率,针对2.4 m望远镜的主力观测终端云南暗弱天体成像光谱仪(Yunnan Faint Object Spectrograph and Camera,YFOSC)[6]设计研发了一套自动记录观测日志的辅助系统。
观测日志辅助系统旨在对观测日志进行自动化记录,帮助观测人员摆脱琐碎的手写记录观测日志的工作,将望远镜观测日志的管理流程化、自动化,简化观测助手在观测中的操作,减少因人工疏忽导致的失误。通过观测日志辅助系统,可以实现观测数据的自动录入、查询、打包下载及相关辅助功能,为观测日志的管理提供了高可靠性、高自适应性的服务。本系统的研发目标是在不修改原始FITS文件的基础上,集监听和查询功能于一体,对FITS头信息进行必要的修正,将FITS头信息与补充信息整合成一条观测日志存入数据库,供后期数据处理使用。
该系统需要实现的主要功能包括:
(1)在曝光结束、观测数据保存到硬盘后,系统能读取观测数据文件的FITS头信息,并将信息写入数据库,同时在辅助系统的前台界面显示;
(2)在观测辅助系统的前台界面,用户可以对采集的信息进行检查,添加信息或修改出错的信息,并提交更新数据库;
(3)在观测时可以选择不同用户的不同观测时间申请书的编号,使观测数据与用户的编号联系在一起,便于观测数据的管理;
(4)能根据用户名或者观测时间申请书编号,对观测数据进行查询、打包和下载,同时生成规定格式的观测日志文件;
(5)将常用的用户固定在前台界面上显示,方便观测期间的操作;
(6)在前台界面显示系统运行状态及用户操作相关的运行情况,以确保辅助系统的正常运行;
(7)用户可以对观测日志记录进行批量提交,如果没有修改,默认使用从FITS头中读取的信息,并保存到数据库。
在系统研发的过程中,采用分层式的系统架构方案,将系统的整体架构分为4层,即:视图层、控制层、服务层和数据层(如图1)。其中:
图1 系统架构图Fig.1 The system architecture
(1)视图层:主要负责显示监听到的观测数据FITS头对应的日志信息,接受用户的监听控制和对观测日志内容的修改操作,以及显示当前软件运行的状态信息和用户的操作记录。
(2)控制层:介于前台界面和后台数据库之间,主要负责接收视图层产生的用户请求并路由到服务层,调用服务层的处理程序,将服务层处理的结果返回视图层。
(3)服务层:主要完成系统软件与数据层之间的交互,并为控制层提供调用所有相关服务所需要的接口,各个服务之间根据需要相互调用。该层主要包含6类服务,即文件监听、数据导出、FITS服务、日志服务、日志文件服务、配置服务。
(4)数据层:对应于系统涉及的所有相关数据文件,包括望远镜的观测数据(原始FITS文件)、系统运行的配置文件和保存在数据库中的结构化数据。主要负责响应服务层的请求,对请求进行处理并返回结果。
结合系统架构图可知,系统要实现的所有功能需要不同层次之间的程序配合才能完成,为了提高安全性,各层之间彼此相互独立,且不能跨层次调用。
在系统实现的过程中,采用模块化思想实现系统的所有功能,根据主要功能将系统划分成界面显示模块、数据监控模块、数据查询模块、数据导出模块、系统日志模块和系统配置模块等6个功能模块。
观测日志辅助系统在Ubuntu13.10操作系统平台上进行研发和运行,采用JDK 1.7(Java Development Kit 1.7)编译环境,面向对象的Java语言[7],后台使用PostgreSQL数据库系统[8]。在系统中调用了几个开源的Java开发包:
• Commons-compress-1.8.jar②http://commons.apache.org/proper/commons-compress/index.html:apache出品,主要实现对用户查询得到的原始观测数据进行打包的功能;
• Dom4j-2.0.00-ALPHA-2.jar③http://dom4j.github.io/:是dom4j.org出品的一个开源的XML解析包,性能优越,功能强大。
• jxl.jar④https://sourceforge.net/projects/jxl/:来自Java Excel开源项目,用于实现读取Excel文件的内容、创建新的Excel文件和更新已经存在的Excel文件。
• postgresql-9.3-1101.jdbc4.jar⑤https://jdbc.postgresql.org/download.html:为Java语言提供与postgreSQL数据进行连接的数据库中间件。
界面显示模块使用Java的图形界面库Swing[9]开发,最终正常运行的效果如图2。用户界面包含不同的功能区,主要包括:
(1)观测日志显示区:当曝光结束有新数据文件产生后,系统读取FITS文件的头信息,并在该区域显示,用户可以对该区域的数据进行修改。
(2)数据监控操作区:提供了选择观测用户的Proposal ID,开始监听、停止监听、修改观测日志记录之后提交、添加长期观测项目的用户及其Proposal ID等功能。
(3)数据查询、数据导出操作区:用于观测数据查询和导出操作,输入起止时间和观测者后点击“查询”;查询结束后,用户可以勾选需要导出的文件(Excel是观测日志,TAR是观测数据),然后点击“导出”按钮进行打包和压缩,并导出到配置文件的存储路径下。
(4)软件状态显示区:用于显示系统软件运行的状态,用户的每一条操作及对应的反馈信息都在这个区域显示,从而方便用户实时监控软件状态,一旦出错立即进行相应的处理。
观测数据的监听从用户在界面上选择观测项目并点击“开始”后启动,程序后端会启动一个线程对观测数据的保存目录进行扫描,将扫描结果保存在哈希表中,然后每秒重新扫描该目录,比对当前文件是否已经存在哈希表中。如果没有,则表示有新观测数据产生,则对该数据进行相应的处理,将处理结果保存到数据库中,并以一条观测日志的模式显示在用户界面上。当该用户的观测结束之后,通过“停止”按钮可以停止此次监听,选择新的观测项目后再次启动监听,直到所有观测结束。数据监控模块的处理流程如图3。
观测日志数据表的格式如表1,除常规的观测时间以及曝光时间信息外,还包含与用户相关的字段、与望远镜相关的指向坐标(RA、DEC)、焦点等字段以及与观测终端相关的滤光片、光栅、狭缝等字段。
数据查询模块主要通过Java数据库连接(Java DataBase Connectivity,JDBC)对观测日志数据库进行查询操作。当观测日志记录入库之后,用户可以根据需求对历史的观测日志记录进行查询,如果在查询到的记录中发现错误,也可以对其进行必要的修改。
在查询时,用户需要提供观测数据覆盖的时间段和观测项目负责人的信息(负责人姓名,对应的数据库字段是:Observer)进行查询,查询的结果除了显示在用户界面上,也会保存在缓存中以便生成所需要的观测日志文件。
数据导出模块实现了对用户查询到的观测数据的结果导出的功能,该模块可以同时导出观测数据和对应的观测日志,从而直接将两部分的文件打包发给用户,方便用户进行观测数据的处理。
观测数据通过后台的打包程序将检索到的结果打包并压缩,观测日志则通过后台的Excel处理软件生成与观测数据对应的观测日志文件,所有的文件最后输出到配置文件指定的目录中。
图3 观测数据监听功能流程图Fig.3 Flow chart of observational data monitoring function
系统日志模块将所有的日志信息划分为软件状态日志、软件操作日志和错误信息日志三种类型。其中:
软件状态日志:将日志的输入流接口重新定向到Swing的文本框组件中进行实时显示,从而显示软件运行的状态,该部分的日志不会以文件的形式保存。
软件操作日志:记录软件的主要运行状态、观测数据生成的时间以及用户操作软件的相关信息,该类日志信息可以在发现观测日志有误时对当时的情景进行复现。
错误信息日志:用于记录软件在运行过程中具体的出错信息,从而可以协助研发者更好地定位软件的错误位置。
软件操作日志和错误信息日志都按天生成一个新文件,系统主要通过Log4jUtil类⑥http://logging.apache.org/log4j/2.x/完成对系统日志的管理,通过一个独立的线程将必要的信息写入日志文件。
系统配置信息保存在XML文件中,系统软件正常运行需要两个相关的XML文件,用户可以通过修改这两个配置文件更新系统的配置,当再次打开软件运行时就可以使用更新后的配置。其中:
configure.xml:保存系统运行相关的配置信息,包括数据库连接地址、数据库账号、需要监听的目录、观测数据和观测日志输出目录。
longterm.xml:保存2.4 m望远镜长期观测项目的用户信息,包括用户的姓名和用户申请书的编号(ProposalID),目前最多只能配置6个用户的信息。该功能还可以应用到机会源(Target of Opportunity,ToO)观测中,当有机会源观测时,可以通过修改配置文件临时建立一个用户信息,并实时在软件的界面上显示,便于准确记录观测日志。
表1 观测日志数据表格式Table 1 Observational log table format
观测日志辅助系统开发完成后,部署在丽江2.4 m望远镜圆顶观测室的一台计算机上,并在运行中验证各部分的功能。图2展示了系统正常运行时的情况,图中①和④两部分分别表示监听到的数据信息和软件运行时的一些必要的日志信息。图4展示了数据查询的情况,图5展示了数据导出的情况(其中TAR文件是观测数据的压缩文件,Excel文件是对应的观测日志文件)。
图4 数据查询结果情况Fig.4 Query result of the observational data
图5 观测数据和观测日志导出情况Fig.5 Observational data and log exported by this system
该系统已经在丽江2.4 m望远镜上运行,能通过对观测数据的监听获取基本的观测日志信息,大大降低了手工记录日志的工作量及出错的概率。在观测结束后,针对用户进行观测数据的查询和导出,根据查询结果生成观测日志,简化了观测数据拷贝的过程,也保证了保护期内用户观测数据的安全性。此外,该系统还与天文领域云相关联,与天文领域云系统上的观测时间申请系统和数据管理系统进行协调工作,下一步可以实现从观测时间分配到观测数据获取的完整观测数据生产周期。但在使用过程中也发现了一些问题:
(1)每个观测季开始前,需要手动导入一次观测时间申请表,以便更新系统内的用户和观测申请编号等相关信息;
(2)每年的观测申请数较多,观测过程中通过下拉菜单选择用户(PI NAME)有点麻烦,需要简化该操作;
(3)系统的数据库中以观测数据的文件名为唯一主键,对观测数据的命名规则有一定要求,移植到其他观测终端需要重新进行二次开发;
(4)没有考虑未来可能的新增字段而设置保留字段,不利于系统的扩展。
在接下来的工作中将逐步解决系统存在的问题,对整个系统进行优化和完善,使其具备通用性,从而可以推广到其他观测终端和望远镜中。