14. Updating final locations in database, UPDATE and UPD

UPDATE

Both the monthly epicenter files in \SEISMO\REA\BER__\CAT and the updated S-files are generated with program UPDATE which is a special version of HYP. Type UPDATE to start the program and there will be questions about time period and database. The program will also ask for operator ID (4 chars), which is stored in the updated log file and the S-file, see below.
By updating, both the S-files and the CAT-files in the CAT-directory are updated. The reason for updating both at the same time is to ensure that there is a correspondence between the two.

The program will go through as many months as specified by the user. When the program is running, one line will be printed out for each event. The S-files will be overwritten with the updated location, residuals etc. At the same time, a monthly CAT file is created in the CAT directory containing all events, also events not located. If a monthly file is already present, it is overwritten.

Update can also work on a local database. The S-files are updated as described above. Since there is no CAT database, the Update program makes a CAT file in the local directory called hyp.cat with events in chronological order.

The ID line is updated with the action UPD.

The update process can also change all S-file names according to the origin time and the ID's are changed correspondingly. This is done in order for the database to be in chronological order according to origin time and not the more random times used when the events were first registered into the database. E.g. a teleseismic event is put in with the ID corresponding to the recording time, when located, the origin time is many minutes before and it will appear too late in the database). Even if the event is marked not to be located with a * in header line column 45, the ID will still be updated (same for program UPD). Like with the SPLIT program, if two events of the same type (L, R or D) have the same origin time to the second, one second is added to the file name part indicating seconds (see also section 13). The event will also be in chronological order in the CAT database.

*****VERY IMPORTANT ******

By default, the ID and file name are not changed by using the UPDATE program. However, optionally this can be done. The user gets the qustion:

Keep sfile name and ID (default=enter) or synchronize sfile name and ID with origin time (s)

By synchronizing, the S-filename and ID is synchonized to the origin time. If no origin time, the earliest time of the phases is used. At the same time an S is put in on the ID line column 76 to indicate event has been synchornized (this was L in version 11 and before). The S will remain for all future updates so it only indicates that the event has been synchronized at some time. To find out when, see the history of the ID lines. The S is only used for information. When the file has been syncronized, the action is set to UPS.

This is VERY important in case data is taken out of the database for some special analysis and then put back in to overwrite the original data. If the ID is the same, the correct event will be replaced.

NOTE: When an update takes place, the old location, magnitudes (except 3. if a different agency from the default agency), residuals etc are removed. If an event cannot be located, the old location etc is lost. This is intentional since the updated database should represent the data available. If a location should be retained, special flags must be set, see section 7, “Fixing location” (a `*' in column 45 in header line).

In order to keep track of how and when the database has been updated, every run of UPDATE creates a log file of the update process. This file is located in a subdirectory of the database directory (default BER__). If e.g. updating REA, the logfiles will be in ../REA/BER__/LOG/ (unix). Filenames are similar to S-files. Below is an example of a logfile with name 01-0000-00L.S199606:

1996 06 kk   99-09-08 14:30 03-1955-35D. 25-0337-29L.     6 
1996 06 jh   98-09-08 14:29 03-1955-40D. 25-0337-31L.     5

The content is as follows: date and time of file updated, operator ID, time of update, event id of first and last event of the month, number of events for month. The example above shows that June 96 has been updated 2 times, the last time on September 10, 1999. For each update, one line is added to the top of the file, so the update history is saved.

Note: If the command UPDATE(U) is used from EEV, only one S-file is updated (name stays the same), and a general update should be made.
UPDATE recalculate moments if distances (or depths) change, however it does not change the Vp or Vs velocities used if a change is made in MULPLT.DEF.

Problem: If UPDATE crash, there will not be a correspondence between S-files and the CAT data base: Redo UPDATE.

UPD

The command UPD is very similar to the UPDATE command, however there is no modification of the S-file except the ID line. The program can optionally synchonize the S-filename and ID with the origin time in the same ways as UPDATE. The only difference is that the action is US instead of UPS to indcate that no relocaiton has been made. The program is used to simply move single S-files into the monthly CAT-files without relocating. It is mainly used to manipulate database events already processed. E. g. if ISC data a available and it is desirable to have it in individual files to be able to use EEV, the same data can then be copied into the CAT part of the database using UPD without modifying the original solutions. The data must be in the CAT part of the database in order for SELECT to work fast. KNOWN BUG: On Sun OS, it seems that UPD can only operate on up to a 4 year time period.