- Request #146 (s. Zuzlewski): ------------------------------ We are now proposing to replace the fields 'depth_type' & 'depth_datum' by one field 'mdepth'. This new field 'mdepth' would contain the model depth and the existing field 'depth' would contain the geoid depth. We see two main arguments to this proposal: - All RSN's except for NC & SC currently store geoid depths in their database ('depth' field). The addition of this new field 'mdepth' would be transparent to them as they would most likely never make use of it. NC & SC currently store model depths in the 'depth' field. Under this proposal, they would start computing both geoid & model depths and store them respectively in the 'depth' & 'mdepth' fields. They could also recompute geoid depths for historic solutions where 'mdepth' is NULL and update appropriately the 'depth' & 'mdepth' fields. - On the application side, we are concerned about overhead associated with the computation of the different depth types for each solution. Any given application would have to test the 'depth_type' field and based on its value (GD or MD), compute appropriately the value of the other depth type. This would certainly affect negatively the application performances. On the other hand, by having the two precomputed depths already stored in the database, applications can select both of them in one statement and use the appropriate one depending on the task at hand. For hypoinverse arc files generation, the depth datum would be computed by substracting the geoid depth from the model one. Both geoid & depth datum would be filled in the summary card. Note: This new proposal does not affect the crustal model fields. We are still proposing to add the 'crust_type' & 'crust_model' fields to the Origin table. In summary, we are now proposing the following changes to the Origin table: 1.- New field Origin.crust_type: Definition: The type of crust model used for travel time calculations: each type has its own geometry of velocity layers or gradients within layers, tied to the options of the location program. Datatype: VARCHAR2(1) Constraints: crust_type IN ('H','T','E','L','V') H - Homogeneous layers, all stations at top (hypoinverse CRH model) T - Travel time table with linear gradient, all stations at top (hypoinverse CRT model) E - Hypoellipse layer model, using station elevations (hypoinverse CRE model) L - Hypoellipse single gradient model, using station elevations (CRL) V - Hypoellipse single gradient over halfspace model, using station elevations (CRV) 2.- New field Origin.crust_model: Definition: The code for the regional (geographic) crust model that is dominant in the travel time calculations. The crust model depends on the location of the earthquake origin and not on the recording station. The code is for the highest weighted model if more than one is used. Datatype: VARCHAR2(3) Constraints: Any free-format string up to 3 characters 3.- New field Origin.mdepth: Definition: Distance in km of the earthquake source below the model surface. For model depths, all the recording stations are located at the top of the model and their elevations are not used. Station corrections can incorporate the effects of elevation. Model types T or H if uncorrected by depth datum are always model depths. Datatype: NUMBER(7,3) 4.- Update existing field Origin.depth: Definition: Distance in km of the earthquake source below the geoid. Hypoinverse model types E, L or V are always geoid depths. --------------------------------------------------------------------- ==> Discussed. PH, DN & SZ revised the original proposal. Hyp2ps & Jiggle will need to be updated. Members agree that the 2 fields representation seems like a better choice. Outstanding issue is should current depth field become geoid depth and new field model depth or vice versa. If the former, more work is required from CISN. If the latter, more work is required from other RSNs. Parties want to have an idea of how long it'd take to compute geoid depths for historic solutions. AW has code to do that. How many events would not be able to be handled by AW's code (no arrivals)? Based on the results, we will decide if we add gdepth or mdepth. ---------------------------------------------------------------------