![]()
Notification, communication and procedures for the PTS-WMO atmospheric backtracking response system
International Data Centre (IDC)/Monitoring and Data Analysis Section (MDA)/Data Fusion Unit (DF)

Version 1.0
Last modification: Oct 22, 2007
Author: G. Wotawa, Atmospheric Sciences Officer, IDC/MDA/DF
Preface
This document describes notification, communication, file formats, file naming conventions and other procedures for the PTS-WMO atmospheric backtracking response system. The system has been included into the WMO Manual for the Global Data Processing and Forecasting System. The full text as added can be seen in report WMO-No. 1017, Commission for Basic System, Extraordinary Session, Seoul, Republic of Korea, 9-16 Nov. 2006, Abridged final report with resolutions and recommendations (http://www.wmo.ch/pages/governance/tc/documents/1017_E.pdf).
The PTS has set up the following web page for the PTS-WMO response system:
Communication: Point of Contact, data upload for response system participants
All WMO Centres are requested to specify an operational Point of Contact (PoC) with an e-mail address. This PoC can be a human or a computer program, who
Furthermore, we would also ask you to specify a contact person (CP) with e-mail, Telephone and Fax. Ideally, this would be a 24x7 shift operator.
All standardized notifications/request for support e-mails would be sent simultaneously to the PoCs and CPs. All further correspondence related to the response and the data would be sent only to the CPs. Any non-real-time/non-exercise correspondence would be sent to the managers, as usual.
WMO Centres are requested to upload their backtracking results on the server specified in the request/notification e-mail, using the user name and password announced there. They are requested to respond only in case that the request message has been posted by the PTS to the web as specified in the message (see also section "Notification mail").
Currently, data are uploaded to the following server:
https://fts.ctbto.org/cgi-bin/put-atm/
To provide technical reference, a user manual for the server can be downloaded here.
Automated upload of data to our server is highly recommended. There are several ways to achieve this. A sample perl script for automated data upload is provided in the user manual (see appendix) or can be downloaded here. Roland Draxler (RSMC Washington) kindly provided an update capable to pass the required arguments through the command line. For using perl, it is crucial to have LWP (SSL-enabled) and HTTP perl modules available, which can be obtained in source code form from:
We can offer only very limited support for automated data upload from your organization towards the secure web interface and recommend, especially if you are not familiar with perl, to contact your own System Administrator on this issue, providing him with our documentation. Besides perl, Windows-based clients do exist that can achieve the same result.
Procedures: Notification mail
CTBTO requests for support are sent out via standardized e-mail message
and are simultaneously put on the secure web interface, for authentication purposes (mails can be manipulated, but nobody except us has write access to the download area of the secure web interface). The notification mail message is intended to allow for automated processing of the request within the participating organization. The IDC is ready to offer - limited - support to allow for automated processing. The issue of automated data upload is addressed in the section "Communication: Data upload for response system participants".The e-mail message provides information on
Each participant is
kindly requested to send back the WHOLE notification mail message to the IDC as soon as possible to confirm operational participation. In case of delayed participation or non-participation, the respective changes in the response form should be done before sending back the notification mail message to the IDC.A sample notification mail message can be downloaded here
As soon as the computations are finished, each participant is requested to upload the requested source-receptor matrices in the requested form (see formats and naming conventions) to the server specified in the e-mail notification message. There is no further message necessary from the participant, since the server incoming area is continuously monitored by software that notifies IDC atmospheric transport operations as soon as new data are arriving.
In case of problems that prevent the participant from the submission of results within the time limits, he is asked to notify the IDC point of contact via e-mail (or, if necessary, via other means of communication).
What do we need - source receptor relationship
The IDC requests from the participants information on the so-called "source-receptor relationship" for a number of stations with specific measurement times. This information is needed, for example, to get information on possible sources. For one single measurement at one station, the source-receptor relationship is nothing else than the sensitivity of the measurement to a source at a certain position and time. We need this sensitivity for each point on the globe (1 degree resolution) and for each time increment starting from the end of measurements (collection stop) and going backward to a certain time (e.g. 144 hours; calculation end date/time is specified in the notification mail). The time increment will be 3 hours.
The following shall be (implicitly) assumed:
Source-grid: 1 degree globally
Source duration (for backward modellers: adjoint concentration output sampling interval): 3 hours
Source strength: 1.3 1015 Bq
Backward simulations (recommended):
In a backward (adjoint) simulation using an Atmospheric transport model, the required source-receptor sensitivity can be easily obtained as follows
Forward simulations (possible):
Forward simulations are totally valid, but usually computationally inefficient to address our problem (as long as the number of measurement stations is small). Anyway, the following approach would be equivalent to our backward simulation:
File formats and names
It has been recommended during the CTBTO-WMO Workshop 2002 to follow the WMO file format and naming standards. While going to GRIB/BUFFR formats is still an important target, for the time being we request that the participants submit the source-receptor relationship (source-receptor matrix) information in gnu-zipped (or
Unix-compressed) ASCII files.File formats:
Example file (click to download)
Header line (line 1)
Longitude of station / latitude of station/ measurement (collection) start time/ Measurement stop time [UTC]/ Total mass [Bq] released in backward model / Maximum number of hours backward/ Output frequency [hours] / averaging time [hours] / resolution of output grid in longitude / latitude [degrees] / station identifier [as specified in notification mail message]
[there is no specific number format required]
Data lines (line 2 - line k)
Latitude of grid point (*) / longitude of grid point (*)/ backward time step number / value of source-receptor sensitivity [Bq/m3]
In our example, timestep number 1 is 3-0 hours before sample collection stop; timestep number 2 is 6-3 hours before sample collection stop; and so on
Please leave away all zero-value grid points
You can write out the data in any order you wish to
(data loop can go across longitude, latitude or time, you can start with collection stop and go backward in time (forward in time step number) or with the start of model simulation and go forward in time (backward in time step number).
Please gnu-zip (or unix-compress) all files before upload
Show source receptor sensitivity plot for current example
(*) Please note that the latitude/longitude value of the grid point denote the lower left corner of the model grid cell.
File naming convention:
You should name your file as follows:
AAAAA.YYYYMMDDhh.num.txt
|
AAA |
Station identifier |
|
YYYYMMDDhh |
collection stop date/time |
|
num |
your WMO centre identifier |
In this example:
SEP63.2003010709.
<Your-WMO-id>.txtSubmission of zip and tar files:
During CTBTO-WMO exercises, or in a treaty verification case, we may request, in total, on the order of 20-30 computations. You can expect 5-10 stations (measurements) per request. To facilitate data upload, we provide the opportunity to submit standard zip (archive) files or unix tar files to the server. The following procedures should be followed: