1.- New Requests: ================= 1.1.- Request #133 (R. Hartog): ------------------------------- ----------------------------------------------------------------- --> Request for additional Event Types from PNSN (lf, su & px). It would be possible for us to use a subset of the event types already available in AQMS, however the current nomenclature doesn't present us with choices that represent the signals (particularly some associated with Cascade volcanoes) in a straightforward manner. We feel the need for three more event types, which will actually simplify our analysis as well as make it more faithful to what we know about seismic sources: 1) Surface event. We suggest 'su'. We don't feel that we can distinguish between a rock fall, a landslide, an ice quake, a lahar, a volcanic explosion, (etc), just by looking at the waveforms when picking (timing) an event. We would like to add an Event Type for a more generic very shallow source (in practice this would mostly be used to describe various signals near our volcanoes). Where we can distinguish between ice quake, ice/rock interface quake, snow and ice avalanche, ice/rock avalanche, rockfall, etc. we would use the comments to record. 2) Low-frequency appearance. We suggest 'lf'. Signals with a low-frequency appearance could have a long-period source, or not. In the volcanological community, the term 'long-period earthquake' is used for events with a very specific type of source mechanism (Chouet's models), and we would rather not give any events that label based only on appearance. 3) Probable blast or explosion. We suggest 'px'. The event types available for explosions ('qb', 'ex') imply that it is known, or confirmed, that an event was a blast. We would like to have a category for unconfirmed blasts/explosions. We often suspect from the waveform, the general location, and the time of day that an event was a blast, but we do not often get confirmation that it was. ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Approved. ----------------------------------------------------------------- 2.- Review of pending requests: =============================== 2.1.- Request #131 (E. Yu): --------------------------- --> Store categories of applications in an AppCategory and AssocAppCat table (similar to event types). ----------------------------------------------------------------- ==> Ellen sent a link to a GUI. People to look at it and come back with some feedback. ----------------------------------------------------------------- 2.2.- Request #53 (D. Given): ----------------------------- --> Add integer attribute for each channel to hold COSMOS "Table 6" value. ------------------------------------------------------------------------ ==> Allan sent a new version of the Cosmos schema. - Stephane loaded the Cosmos schema on a test database and updated createv0_xml to use those tables. Other applications could benefit from those tables. For example: v02mseed, Shakemap. - NC & SC will start writing an application to populate the main table (C_ChannelData) for their respective networks. - Stephane updated the tables with new values from the Cosmos documentation. Sent out new version of the schema. - Stephane sent an initial spreadsheet for BK sites to Peggy. Outstanding issue concerning borehole sites. - SC will go through their site codes. ------------------------------------------------------------------------ ----------------------------------------------------------------- ==> Tony said that code 52 should be used for boreholes. Current SC algorithm for assigning site codes: IF depth < 10 m THEN 4 ELSE 52 Ellen is working on an application to populate the Cosmos schema main table. ----------------------------------------------------------------- 2.3.- Request #4 (B. Worden): ----------------------------- --> Add new association table between amps and events. ----------------------------------------------------------------- ==> Approved. Three tables (AMPSET, ASSOCEVAMPSET, AMPSETTYPES). Tables EVENT & ASSOCAMO remain as is. DDL scripts are available in the SVN repository (PI schema). - Applications affected: * Shakemap harvester. * SGM import. * Ampgen. - Allan updated ampgen & SGM import. - Pete updated the shakemap harvester code and sent it to Bruce Worden (changes are optional though since we are still associating amplitudes with origins). - Pete tested everything on test DB and all is OK. - Historic data in DB need to be updated (union of latest amps for all origins). - NC & SC installed the tables in production but they are not being used yet (RT still testing ampgen). ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Tables should be used in production: - Next week in NC. - In 2-3 weeks in SC. Pete & Stephane came up with a plan to update historic data in NC. ----------------------------------------------------------------- 2.4.- Request #128 (S. Zuzlewski): ---------------------------------- --> Allow NULL for Amp.datetime. ------------------------------------------------------------------------ Amplitude times in the database are only approximations and therefore are not reliable. Affected readings are: - NC WA amplitudes readings from pre-CISN software. - ALL CISN SGM spectral acceleration times imported from CISN partners. ==> Approved. After seeking guidance from the Standards group, the following was approved: - Allow NULL values in the Amp.datetime field and make use of the existing fields 'wstart' (Window start) and 'duration' to represent respectively the approximate time and its associated error. * For each amplitude where we know the time and the window (ex: current RT): We can set all the fields (datetime, wstart, duration). * For each amplitude where we know the time but not the window: Amp.datetime = Amp.wstart Amp.duration = 0 * For each amplitude where we don't know the time nor the window: Amp.datetime = NULL Amp.wstart = Amp.duration = NULL - Action Items: * Caltech will use 'wstart' to partition the Amp table. * Pete will look at affected RT apps (trimag, ampgen). * Allan will look at PP (jiggle, ampgen_pp, hypomag) & SGM import apps. * Each DC will look at its historic data and update appropriately the Amp fields datetime, wstart & duration. * Databases: - Remove NOT NULL constraint on Amp.datetime. - Add NOT NULL constraint to Amp.wstart. * RT apps: - datetime: actual time of pick. - wstart: start of window. - duration: filling in. - Need to be changed to use the correct API's (nominal vs. true). * PP apps: - Need to update gmp2db & db2gmp. - NC added the datetime constraint. Wstart constraint cannot be added yet because some values are NULL. - Pete checked/updated RT apps. Allan checked/updated PP apps. SGM import apps are waiting for the new version of the SGM packets. ------------------------------------------------------------------------ ----------------------------------------------------------------- ==> Everybody is sending the new version of the SGM packets except for CGS. Pete & Stephane came up with a plan to update historic data in NC. ----------------------------------------------------------------- 2.5.- Request #10 (D. Given): ----------------------------- --> Add new column "nobs" to NETMAG table. ------------------------------------------------------------------------ ==> Request has been approved. - This change has eventual implications for the following applications: Trimag, EC, Jiggle, MT, dbselect, Stored Procedures, STP(SC), RTMd(SC). - Ellen tested and documented a procedure to perform a DDL operation in a replication environment. - Ellen used the procedure to add the new field in SC. - Allan updated Jiggle & the stored procedures. - NC added the new field to its production databases. - Historic data need to be updated in the database. Shang Lin needs to update STP. - Pete updated trimag, EC & TMTS. New version of dbselect cannot be installed until historic data is corrected. ------------------------------------------------------------------------ ----------------------------------------------------------------- ==> No change is needed for STP. ----------------------------------------------------------------- 2.6.- Request #130 (S. Zuzlewski): ---------------------------------- --> AppChannels vs Config_Channel. ------------------------------------------------------------------------ Issue of config_channel/program tables use by RT programs and applications/appchannels by post proc. We should ideally create one set of tables and both should use the same set. It will simplify the schema, and avoid the confusion of what tables to populate for program's channel lists. - In NC, Pete created a script to reconfigure channel list Id's and names. Also Config_Channel is now a view of AppChannels and Program a synonym of Applications. - Ellen mentioned that she is working on a better way to manage channel lists with a GUI interface. ------------------------------------------------------------------------ ----------------------------------------------------------------- ==> Ellen sent a link to a GUI. People to look at it and come back with some feedback. ----------------------------------------------------------------- 2.7.- Request #129 (S. Zuzlewski): ---------------------------------- --> Add hardware ownership information. ------------------------------------------------------------------------ We want to add hardware ownership information to the HT schema in order to identify which piece of hardware belongs to whom (similar to the 'owners' table in SIS). It would require a new table: ownerid int (PK) name string contact string lddate date We would then add the field 'ownerid' as a foreign key in the Sensor, Filamp & Datalogger tables. - D. Given pointed out that contact information can change often. NC to discuss some more about it. - Currently waiting on ANSS looking at SIS. ------------------------------------------------------------------------