George Helffrich
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
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
-
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
-
1) What are the values you would like to use for each body, and how would these numbers be updated ?
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
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 ?
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.
-
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,
George Helffrich
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<at>bris.ac.uk
-
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,
George Helffrich
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<at>bris.ac.uk
-
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,
George Helffrich
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<at>bris.ac.uk
-
-
-
Brian Savage
Arthur Snoke
