geoscience-community-codes/GISMO

More load_sac issues ...

gthompson opened this issue · 2 comments

gthompson commented

From @GoogleCodeExporter on August 1, 2015 21:51

** What steps will reproduce the problem?

ifile = '/home/carltape/gismo_test/10992159.CI.SMM.BHE.sac.d.T003_T030';
w = loadsac(waveform,ifile);


** What is the expected output? What do you see instead?
The network code should be 'CI' since the SAC header KNETWK is CI. Instead 
get(w,'network') returns 'CI 345'. More puzzling is that the network code is 
just 'CI' when displayed with disp: 

>> disp(w)
   station:    SMM       network: CI
   channel:    BHE      location: --
     start: 2001-07-20 12:52:27.600
     ....

The problem is undoubtedly in the load_sac interpretation of the header fields 
(and dependent functions. It is not hurting anything right now. But the right 
approach is an overhaul of load_sac, loadSacByFilenames, readsacfile and 
sac2waveform. These grew organically for logical reasons. But the current 
structure makes bug isolation very challenging. Unfortunately I just don't have 
time to look into it right now.

Original issue reported on code.google.com by mew...@alaska.edu on 23 Feb 2012 at 11:54

Copied from original issue: giseislab/gismotools#30

gthompson commented

From @CelsoReyes on August 14, 2015 13:13

I haven't checked out the other ones, but Thorne's stuff isn't appropriate. When Mike West refers to "organically grown"... it organically grew out of Thorne's codes. MatSAC.tar.gz looks like it also grew from Thorne's stuff. However, he designed it entirely for different set of uses (replecating the sac console commands), and it was hard to debug, even back then. Since then, I'm sure my own changes have helped keep it obscure.

Of the ones I've seen, matlab 46356 is the nicest looking, of the bunch.

I reworked the SAC stuff for IRIS, and could probably do it much nicer now. Let me take another look.