Thread: Re: SAC/SACA file format verification

Started: 2009-03-31 03:13:58
Last activity: 2009-03-31 03:13:58
Topics: SAC Help
Daniel Griscom
2009-03-31 03:13:58
[Trying to send this a third time... Dan]

At 1:30 PM +0000 3/28/09, George Helffrich wrote:
On 28 Mar 2009, at 12:28, Daniel Griscom wrote:
At 10:39 AM +0000 3/28/09, George Helffrich wrote:
1) Undefined character values in the binary file should be
padded with blanks, not trailing zero characters, to their field
lengths (8 or 16 characters, as appropriate);

Are you sure? The SACA example I have uses trailing nulls (which
surprised me).

Positive. The binary format is defined by Fortran behavior.
Character fields are blank-filled; trailing nulls have no
significance in Fortran.


3) I think that you can safely set IDEP to IACC (integer
number 8) to signify that the dependent variable is acceleration.

The values in the data section are in m/s/s, not nm/s/s; would you
still suggest IACC ("Acceleration in nm/sec/sec")?

I'm not particularly bothered by the units discrepancy, but you
could fix it either by 1) multiplying samples by 10**9;

I've been wondering about limitations in the field width for SACA
files, which are specified as "G15.7". The example I have represents
a float in 15 characters: six characters holding spaces, one
character holding a space or minus sign, and nine characters with
digits and a decimal point, e.g.

1.000000 -12345.00 -12345.00 -12345.00 -12345.00
0.000000 1043.000 -12345.00 -12345.00 -12345.00
-12345.00 -12345.00 -12345.00 -12345.00 -12345.00

What if I need more than nine digits to represent something; can I
start expanding into those left six spaces?

2) setting SCALE to be 10**-9 with unchanged samples;


3) go back to setting IDEP to IUNKN (but you *do* know, after all).

Maybe I DO know, but just don't wanna tell...

Hmmm. The first character choice depends on the idea of a
seismometer's corner period, where its response to velocity turns
flat. Accelerometers aren't built to be flat to velocity anywhere.
Their response is broad band, however, because they are flat to
acceleration from DC to a very high frequency. In that spirit, I'd
use either B or H as appropriate to the sample rate.

Well, you can argue it either way, but I'm fine with B/H.

My vote for the last character is XYZ, since you'll never be
FDSN-compliant if you want to use Z (but a laptop on my lap isn't
guaranteed to have Z up, either). At least there will be a clear
link between the trace names and the computer-fixed coordinate

Makes sense to me.

P.S. For all you Mac-owning seismologists, I'd also be interested
in any feedback you may have about the data export process. Right
now you choose the axis and name and then save, which means to save
all three axes you have to enter three different names. I'm
considering going to saving a folder instead of a file, with the
folder containing three axis files. Thoughts?

Only this: Folders don't seem to have any benefit other than
reducing file name typing. In the save dialog just provide a choice
of a file prefix and whether to save X, Y, Z, or all components.
Then generate the suffixes like the component names.

The problem with this is that saving multiple files with one "Save
As" dialog means I have to handle file name collisions, as the
built-in code assumes you're saving with the name as typed by the
user. That's the big benefit of using the folder; it's a single item,
so the "Save As" dialog handles all the special cases correctly, but
I still end up with three files (I'm thinking with the name typed by
the user, plus ".X.SAC"/".Y.SAC"/".Z.SAC").

Trying to encode too much information in a file name leads to quite
cumbersome names like what rdseed writes!

Yeah, they're ugly, but here we'd only be adding another six
characters. Not too bad.

Thanks again,

Daniel T. Griscom griscom<at>
Suitable Systems
1 Centre Street, Suite 204 (781) 665-0053
Wakefield, MA 01880-2400

12:58:53 v.ad6b513c