next up previous contents index
Next: 15. Using filenr.lis, DIRF Up: SEISAN Previous: 13. Inserting events into   Contents   Index

14. Updating final locations in database, UPDATE and UPD


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 with events in chronological order.

At this time, an S-file might contain several old ID-lines which in an append process have been converted to comment lines. These are deleted when doing an update. The remaining ID-line is updated with the action UPD, the operator ID and the time. At the same time, all the error lines are deleted and only the one belonging to the prime location is kept.

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. 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 ******

The first time an update is done, the S-files get a new name according to the origin time now calculated and the internal ID is changed accordingly. The ID is then locked indicated by an L in column 76 of the ID line. For all future updates, by default, the ID will remain the same, the S-file name will also be the same irrespective if the origin time changes. 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. Optionally, Update can make a new ID each time the program runs (not recommended). It might be necessary sometimes to allow this in case the events are no longer in chronological order according to origin time (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). However, this is rarely a problem after the first location is done and it is recommended to use the default option of locking the ID.

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 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.


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 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.

next up previous contents index
Next: 15. Using filenr.lis, DIRF Up: SEISAN Previous: 13. Inserting events into   Contents   Index
Peter Voss : Mon Feb 27 10:16:12 UTC 2017