DATA PROBLEM REPORTS Fields that must be filled in by the individual are designated by underlining. Fields are separated by tab characters. The DATA PROBLEM REPORT, Problem Description, and END are required entries. DATA PROBLEM REPORT PROBLEM IDENTIFIER Report Date Reporting Organization Reporting Individual Data Source Station Network Channel Start_Time End_Time Problem Description Problem Type . . (several lines of problem description) . # Lines beginning with a # are displayed within the DMS but not for general users . END The fields above are as follows: PROBLEM IDENTIFIER This is a unique code maintained by each of the reporting organizations. For instance University of Washington codes will start with UW93:1 (or UW1993:1) and increase sequentially for the entire year of 1993. I would suggest that the other prefixes be similar to HRV93, ASL1993, IDA93, DMC1993, etc. Each organization is responsible for using a new code for each new problem. Report Date This is the date when the problem was found. The format of this data is YYYY/MM/DD such as 1993/03/01 for March 1, 1993. The day the problem is found should be the day it is reported to the DMS. If a problem was found to exist for a longer time duration than originally specified in the problem report, the date should be corrected in the Data Problem Report and the Report should be resubmitted. Reporting Organization This is one of the following: Harvard WQC University of Washington IDA DCC ASL DCC IRIS DMC OTHER Reporting Individual The name of the individual reporting the problem. Data Source Where the data problem reporter received their data. Possible values here might be DMC, GOPHER, Harvard, ASL, IDA, NEIC, etc. Station This is the name of the Station that has the problem. Wild cards are not supported. Network Code This is the two digit SEED network code assigned by the international Federation of Digital Seismograph Networks (FDSN). Channel This is the SEED channel name of the time series that has the problem. The wild card characters ? and * are supported. These two wild cards are equivalent and substitute for one or more characters each. Only include channels where the problem was actually seen, do not infer that problems were on other channels. Location codes may be specified before a channel name and delimited with a "/". The location code should be specified with each channel entry in the list. Omitting the location code and "/" implies that the location code is blank or not used. These sample channel list entries for station XX.STN1 translate as follows: Channel String Describes 01/BH? XX.STN1.01.BHE XX.STN1.01.BHN XX.STN1.01.BHZ XX.STN1.01.BH1, etc. 01/BHE 01/BHN XX.STN1.01.BHE XX.STN1.01.BHN 01/BHE BHN XX.STN1.01.BHE XX.STN1..BHN 00/*HE or 00/?HE XX.STN1.00.BHE XX.STN1.00.LHE XX.STN1.00.VHE, etc 00/*H* or 00/?H? XX.STN1.00.BHE XX.STN1.00.BHN XX.STN1.00.BHZ XX.STN1.00.LHE, etc. */* XX.STN1.00.BHE... XX.STN1.01.BHE... XX.STN1.00.LHE... XX..STN1.01.LHE... Start_Time The starting time of the problem in SEED format. 1993,001,04:23. As in SEED you can express the time to the desired resolution. Of course one might not know the real time the problem started, but this is the earliest time that the problem was observed. End_Time The ending time of the problem in SEED format. As in SEED you can express the time to the desired resolution. Of course one might not know the real time the problem ended, but this is the latest time that the problem was observed. It is possible that the Start Time and End Time are the same. Presently, we are conforming to SEED convention that if a problem is ongoing, and continues past the data that is being QC'd, an ending time of " ~ " (tilde)is to be included, to discriminate between simply forgetting to put an ending date, and one that will continue until the DPR is resolved and closed. This is referred to as an "OPEN" DPR. Problem Type The first line of the multiple line problem description is a generic problem type. In the past, these entries were drawn from the following standard list: INCORRECT TIME TIME TEARS DATA DROPOUTS DATA GLITCHES DATA LOGGER PROBLEM DEAD CHANNEL HIGH FREQUENCY NOISE LOW FREQUENCY NOISE POLARITY REVERSED CHANNEL ORIENTATION INCORRECT LOCATION INVALID RESPONSE OTHER The goal in this list was to have a unique word that classifies each various type of problem so that a user can search for a specific problem class. It is now accepted for reporting organizations to compile their own list of Problem Types as they find useful. The problem type field is up to 80 characters long; alphabetical characters should be upper case. Problem Description Following the Problem Type line, a series of lines can follow that more fully describe the line. If you wish to convey information within the IRIS DMS that you do not want to have displayed to the community in general, start a hidden comment line with a # character. The problem description must end with a line with the single word END on it. Do not report multiple problems in a single problem report. For instance if the data are contaminated with low frequency noise and there are timing problems, there should be two problem reports not a single one. If the report pertains only to data with a specific quality flag, for example R data, (see the Data header indicator in byte 7 of the miniseed fixed header), it should be noted in this description section. Remember the fields are tab separated, spaces do not act as field delimiters. In the following example tabs are designated by "\t" and newlines by "\n". An example follows: DATA PROBLEM REPORT \t DMC93:23 \n 93/03/01 \t IRIS DMC \t Tim Ahern \t DMC \n GSC \t TS \t LHE LHN \t 1992,231 \t 1992,234 \n Problem Description \n TIME TEARS \n Station GSC has multiple time tears for the long period channels. This is \n not observed on the broad band channels. \n # Gee, what gives, is the clock tolerance set correctly. \n END All such problem reports should be electronically mailed to qc@iris.washington.edu. If for some reason the information in the initial problem report needs to be altered in any way, the Problem Reporting nodes should simply resend the problem report using the same Problem Identifier number. The later report will replace the newer one and a new copy of the report will be forwarded to the problem resolving node if needed. Information Flow The IRIS DMC will act as the central point of contact for all such data problem reports. Problem reports will flow from Problem Reporting Nodes such as the Harvard Waveform Quality Center and the University of Washington to the IRIS DMC. The problem report will be reviewed by DMC staff and when necessary forwarded to the appropriate problem resolving node. The bulletin board will be updated to reflect the current status of the problem. The problem report will also be posted in the Bulletin Board for user viewing. The DCCs will be responsible for resolving each data problem. When the problem has been resolved to the satisfaction of the Problem Resolving Node, they will send a Problem Resolution Report to the IRIS DMC. The Problem Resolution will be posted in the Bulletin Board at the DMC and closure will be reached. The originating Problem Reporting entity can consult the Bulletin Board to see if their reported problems have been resolved. The IRIS DMC will be responsible to ensure all problems are resolved. When the DMC receives Data Problem Reports, they will be reviewed and when appropriate forwarded to the appropriate DCC. A line will be appended to the Problem Report such as REFERRED ORGANIZATION DATE where ORGANIZATION will be the name of the DCC or other organization that the DMC has sent the problem to and DATE is the date in YYYY/MM/DD format. Problem Resolution Reports Problem Resolving Nodes will receive relevant problem reports from the DMC. It is their responsibility to respond to the various problem reports by submitting a problem resolution report. PROBLEM RESOLUTION REPORT PROBLEM IDENTIFIER Resolution Date Organization Individual Description of Problem Resolution Type of Resolution Report .(several lines as needed) . . . END When reporting nodes submit a Problem Resolution Report, they should resubmit the original Data Problem Report with the end date included along with the Resolution Report. Problem Resolution Reports should be mailed to qc@iris.washington.edu. Fields in the Problem Resolution Report should be separated by tab characters. A description of the various fields follows. PROBLEM IDENTIFIER This is the same unique identifier as in the original Problem Report. Resolution Date This is the date the problem was resolved. The format of this date is YYYY/MM/DD. Such as 1993/03/01 for March 1, 1993. It should be the same date as when the resolution is sent to the DMC. Organization This is the name of the Problem Resolving Node. Individual The name of the individual who resolved the problem. Type of Resolution Report This is one of the four following words that follows the words Description of Problem Resolution on a separate line Comment Resolution Supplement None Use Comment when you have no real resolution to the problem, such as station noisy, but you wish to agree with the observation. Use Resolution when you feel that you have identified the cause of the problem and the action that has been taken to resolve it. Use Supplement when you wish to add to a previous Resolution Report that you have already filed. Use None if no resolution report is needed. The DMC will sometimes file this type of resolution report so that the DCC does not need to respond to a received problem report. These are sent to DCCs for informational purposes only. Description of Problem Resolution The is a multi line description of how the problem was resolved. As with problem reports, lines that begin with a # will not be displayed in the bulletin board for the general public. The Description must end with an END on a line by itself. An example of a Problem Resolution Report follows. PROBLEM RESOLUTION REPORT \t DMC93:23 \n 93/03/20 \t ASL \t Bob Woodward \n Description of Problem Resolution \n Resolution \n The clock tolerance was inadvertently set to the wrong value in previous \n SEED volumes. The correct value has now been forwarded to the IRIS DMC \n and future SEED volumes should not show this problem. # The clock tolerance for the L channels for GSC should be changed. We will \n #send you the necessary SEED update volume tomorrow. \n END If the Problem Resolving node finds a need to update their problem resolution they simply need to resend the original Data Problem Report and Problem Resolution Report with the same Problem Identifier. The new DPR/PRR pair will replace the older pair. The complete Problem Report and Problem Resolution would remain in the Bulletin Board and would appear as: DATA PROBLEM REPORT DMC93:23 93/03/01 IRIS DMC Tim Ahern DMC GSC TS LHE LHN 1992,231 1992,234 Problem Description TIME TEARS Station GSC has multiple time tears for the long period channels. This is not observed on the broad band channels. REFERRED ASL 93/03/02 PROBLEM RESOLUTION REPORT DMC93:23 93/03/20 ASL Bob Woodward Description of Problem Resolution Resolution The clock tolerance value was inadvertently set to the wrong value in previous SEED volumes. The correct value has now been forwarded to the IRIS DMC and future SEED volumes should not show this problem. All data from channels LHE, LHN, and LHZ for stations GSC were affected from 1992,220 through 1992, 240. END