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


Hyp2ps & Jiggle will need to be updated.
Members agree that the 2 fields representation seems like a better
choice. Outstanding issue is whether current depth field should 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.

---------------------------------------------------------------------
==> The group approved the following changes to the Origin table:

- New field 'crust_type' : Type of crust model.
- New field 'crust_model': Code for geographic crust model.
- New field 'mdepth'     : Model depth.
- Existing field 'depth' : Redefine to contain geoid depth.

We do not want the schema change to be implemented until all
historic geoid depths have been computed because centers do
not want to be locked into older versions of the stored procs.
Computations would most likely be done offline and stored in
a temporary table until the transition.

Event coordinator, Jiggle and double-difference codes need to
be updated. New version of Hypoinverse (v1.40) needs to be installed
on the solution server. It is already installed in SC with the
appropriate flags to ignore the new parameters.

We need to identify what other pieces of code need to be updated;
take care of the metadata issues (FK will contact CS about NP
elevations) and outline the steps to do all the changes in real
time. Metadata issue is most likely the biggest hurdle to compute
geoid depths for historic events.

Action items:
- PH, FK & SZ will look at metadata issues in NC.
- EY will send out a strawman outlining the procedure to follow
  during the transition. Other people will fill in the document.
- SZ will take a look at the Datum package.
---------------------------------------------------------------------