Thread: SAC changes for non-Earth use

Started: 2013-06-11 17:58:20
Last activity: 2013-06-25 00:18:11
Topics: SAC Developers
George Helffrich
2013-06-11 17:58:20
Dear All -

Bristol's planetary group is working on non-Earth seismic data and synthetics. I intend putting support into our SAC for this. The design I'm planning to use is to use an unassigned I-format header field to encode the body/reference ellipsoid for geometric calculations (distance, azimuth, etc.). If not set in existing headers, Earth is assumed.

For forward compatibility with future SAC header changes, it would be wise to agree on the header variable name supplied to GETIHV/SETIHV for this purpose. I propose 'BODY'. This is generic enough to include both planets, moons, asteroids and the Sun. The enumerated variables would be IEARTH, ISUN, ...

Any complaints, let me know.

George Helffrich
george.helffrich<at>bris.ac.uk



  • Brian Savage
    2013-06-14 17:12:24
    George,

    This looks like an interesting addition to the sac header format. I am good with this update.

    However, there are a few details that I am concerned with.

    1) What are the values you would like to use for each body, and how would these numbers be updated ?
    Currently the values for the Earth are hard coded into the src/ucf/distaz subroutine. I was unable to find a reference for the current numbers for flattening (and Radius). Would it be easier or simpler to include a pair of numbers for radius and flattening for this calculation ?

    2) Arthur Snoke and I put together a "plan" to update the precision of the sac header, incrementing the version number to 7. We have set this aside due to the disruption it would cause, but I would see this as a convenient time to include your additions.

    Brian


    On Jun 11, 2013, at 5:58 AM, George Helffrich wrote:

    Dear All -

    Bristol's planetary group is working on non-Earth seismic data and synthetics. I intend putting support into our SAC for this. The design I'm planning to use is to use an unassigned I-format header field to encode the body/reference ellipsoid for geometric calculations (distance, azimuth, etc.). If not set in existing headers, Earth is assumed.

    For forward compatibility with future SAC header changes, it would be wise to agree on the header variable name supplied to GETIHV/SETIHV for this purpose. I propose 'BODY'. This is generic enough to include both planets, moons, asteroids and the Sun. The enumerated variables would be IEARTH, ISUN, ...

    Any complaints, let me know.

    George Helffrich
    george.helffrich<at>bris.ac.uk


    _______________________________________________
    sac-dev mailing list
    sac-dev<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/sac-dev



    • Arthur Snoke
      2013-06-14 17:58:03
      1) What are the values you would like to use for each body, and how would these numbers be updated ?
      Currently the values for the Earth are hard coded into the src/ucf/distaz subroutine. I was unable to find a reference for the current numbers for flattening (and Radius). Would it be easier or simpler to include a pair of numbers for radius and flattening for this calculation ?

      I worked on elliptical earth stuff a few years ago. (Now GMT has an elliptical earth, as a result). In the od Fortran version of distaz.f, it says

      data rad/6378.160/,fl/0.00335293/
      data twopideg/360./
      data c00,c01,c02,c03/1.,0.25,-4.6875e-02,1.953125e-02/
      data c21,c22,c23/-0.125,3.125e-02,-1.46484375e-02/
      data c42,c43/-3.90625e-03,2.9296875e-03/
      data degtokm/111.3199/

      It is not in distaz.c, but it is probably in somewhere like ucf.h.

    • George Helffrich
      2013-06-17 19:27:04
      Dear Brian -

      The actual ellipsoid parameters are the equatorial radius and the flattening. Degrees per km on the ellipsoid is derived from the equatorial radius.

      The values I've used are:

      1) Earth - SAC's historic value (in code described as "the 1968 ellipsoid" and numerically equivalent to the IAU 1968 Earth ellipsoid).
      2) all else - IAU reference documentation. Citation: Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2009. Clestial Mech. Dyn. Astr., Special Report, 2010. doi: 10.1007/s10569-010-9320-4

      If there is any need for future ellipsoid changes, then introducing another I-type identifier can tag the new/redefined values (e.g. IWGS84). Using a name tag for the combination of a radius/flattening value is established practice for all geodetic software packages that I investigated. Thus separate specification of radius and flattening values isn't endorsed by the geodesy community ... and takes up more precious header space from SAC's viewpoint. Those factors motivated my choice of I-type header values.

      For the record, here are the header variables/I-codes I've used/defined for the purpose of ellipsoid ID:

      BODY == ihdr13

      ISUN = 98
      IMERCURY = 99
      IVENUS = 100
      IEARTH = 101
      IMOON = 102
      IMARS = 103

      An undefined value means Earth and the IAU68 ellipsoid.

      On 14 Jun 2013, at 15:12, Brian Savage wrote:

      George,

      This looks like an interesting addition to the sac header format. I am good with this update.

      However, there are a few details that I am concerned with.

      1) What are the values you would like to use for each body, and how would these numbers be updated ?
      Currently the values for the Earth are hard coded into the src/ucf/distaz subroutine. I was unable to find a reference for the current numbers for flattening (and Radius). Would it be easier or simpler to include a pair of numbers for radius and flattening for this calculation ?

      ...

      Brian


      On Jun 11, 2013, at 5:58 AM, George Helffrich wrote:

      Dear All -

      Bristol's planetary group is working on non-Earth seismic data and synthetics. I intend putting support into our SAC for this. The design I'm planning to use is to use an unassigned I-format header field to encode the body/reference ellipsoid for geometric calculations (distance, azimuth, etc.). If not set in existing headers, Earth is assumed.

      For forward compatibility with future SAC header changes, it would be wise to agree on the header variable name supplied to GETIHV/SETIHV for this purpose. I propose 'BODY'. This is generic enough to include both planets, moons, asteroids and the Sun. The enumerated variables would be IEARTH, ISUN, ...

      Any complaints, let me know.

      George Helffrich
      george.helffrich<at>bris.ac.uk


      _______________________________________________
      sac-dev mailing list
      sac-dev<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/sac-dev




      George Helffrich
      george.helffrich<at>bris.ac.uk



      • Brian Savage
        2013-06-24 18:24:50
        George,

        Sorry for the delay.

        This all looks ok to me. I would imagine that we would not need to increment the header version to accomplish this. As the point in the header where this variable would go should already be undefined.

        I am curious, is there a need to prefix all variables with an "I" ? Is it possible we can drop the "I" prefix ?

        Once you have the constants set in your version, would you mind sending the updated fortran code my way for consistency ?

        Brian

        On Jun 17, 2013, at 7:27 AM, George Helffrich wrote:

        Dear Brian -

        The actual ellipsoid parameters are the equatorial radius and the flattening. Degrees per km on the ellipsoid is derived from the equatorial radius.

        The values I've used are:

        1) Earth - SAC's historic value (in code described as "the 1968 ellipsoid" and numerically equivalent to the IAU 1968 Earth ellipsoid).
        2) all else - IAU reference documentation. Citation: Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2009. Clestial Mech. Dyn. Astr., Special Report, 2010. doi: 10.1007/s10569-010-9320-4

        If there is any need for future ellipsoid changes, then introducing another I-type identifier can tag the new/redefined values (e.g. IWGS84). Using a name tag for the combination of a radius/flattening value is established practice for all geodetic software packages that I investigated. Thus separate specification of radius and flattening values isn't endorsed by the geodesy community ... and takes up more precious header space from SAC's viewpoint. Those factors motivated my choice of I-type header values.

        For the record, here are the header variables/I-codes I've used/defined for the purpose of ellipsoid ID:

        BODY == ihdr13

        ISUN = 98
        IMERCURY = 99
        IVENUS = 100
        IEARTH = 101
        IMOON = 102
        IMARS = 103

        An undefined value means Earth and the IAU68 ellipsoid.

        On 14 Jun 2013, at 15:12, Brian Savage wrote:

        George,

        This looks like an interesting addition to the sac header format. I am good with this update.

        However, there are a few details that I am concerned with.

        1) What are the values you would like to use for each body, and how would these numbers be updated ?
        Currently the values for the Earth are hard coded into the src/ucf/distaz subroutine. I was unable to find a reference for the current numbers for flattening (and Radius). Would it be easier or simpler to include a pair of numbers for radius and flattening for this calculation ?

        ...

        Brian


        On Jun 11, 2013, at 5:58 AM, George Helffrich wrote:

        Dear All -

        Bristol's planetary group is working on non-Earth seismic data and synthetics. I intend putting support into our SAC for this. The design I'm planning to use is to use an unassigned I-format header field to encode the body/reference ellipsoid for geometric calculations (distance, azimuth, etc.). If not set in existing headers, Earth is assumed.

        For forward compatibility with future SAC header changes, it would be wise to agree on the header variable name supplied to GETIHV/SETIHV for this purpose. I propose 'BODY'. This is generic enough to include both planets, moons, asteroids and the Sun. The enumerated variables would be IEARTH, ISUN, ...

        Any complaints, let me know.

        George Helffrich
        george.helffrich<at>bris.ac.uk


        _______________________________________________
        sac-dev mailing list
        sac-dev<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/sac-dev




        George Helffrich
        george.helffrich<at>bris.ac.uk




        • George Helffrich
          2013-06-25 00:18:11
          Dear Brian -

          My view is that it is good practice to flag enumerated values, which makes them simpler to parse and pithier to recall. Thus you have IMOON, ISUN, etc. But the header variable is straightforwardly BODY. When listed, the printed version of the variable is understandable -- see below. You only need to use the I-constant when using CH or calling SETIHV.


          SAC> funcgen seismogram
          SAC> lh


          FILE: SEISMOGR
          --------------
          ...
          KSTNM = CDV CMPAZ = 0.0
          CMPINC = 0.0 STLA = 48.0
          STLO = -120.0 KEVNM = K8108838
          EVLA = 48.0 EVLO = -125.0
          EVDP = 0.0 IEVTYP = AFTERSHOCK
          DIST = 373.063 AZ = 88.1471
          BAZ = 271.853 GCARC = 3.35746
          LOVROK = TRUE
          SAC> ch body isun
          SAC> lh


          FILE: SEISMOGR
          --------------
          ...
          KSTNM = CDV CMPAZ = 0.0
          CMPINC = 0.0 STLA = 48.0
          STLO = -120.0 KEVNM = K8108838
          EVLA = 48.0 EVLO = -125.0
          EVDP = 0.0 IEVTYP = AFTERSHOCK
          BODY = the Sun DIST = 40634.1
          AZ = 88.1416 BAZ = 271.858
          GCARC = 3.34506 LOVROK = TRUE
          SAC>

          Imagine six degrees of separation ...

          On 24 Jun 2013, at 16:24, Brian Savage wrote:

          George,

          Sorry for the delay.

          This all looks ok to me. I would imagine that we would not need to increment the header version to accomplish this. As the point in the header where this variable would go should already be undefined.

          I am curious, is there a need to prefix all variables with an "I" ? Is it possible we can drop the "I" prefix ?

          Once you have the constants set in your version, would you mind sending the updated fortran code my way for consistency ?

          Brian




          George Helffrich
          george.helffrich<at>bris.ac.uk



Page built 23:47:10 | v.359e0ab5