[sac-dev] byte order and swapping]

[Peter Goldstein]

I'm just coming into this discussion as I catch up on my email after 
being out all last week.

I feel somewhat strongly that we should leave the byte-order alone, 
update the web pages
http://www.iris.edu/manuals/sac/manual.html  to document what we have,
and fix the writeheader issue (I'm sorry I haven't been able to get to it.)

As for SGF, I think Art has a reasonable short term solution.   I 
suspect that a better long
term solution would be to provide options to write more standard 
output graphics formats.
I'm not certain, but I think some of the modifications Brian made 
last summer take us a
long way towards being able to do that.  I'd have to take another look.

My main objection to fixing the byte-order is that it will introduce 
an unnecessary change that
could impact many users.  I think Brian or others have already covered this.



At 9:00 AM -0500 11/22/05, Brian Savage wrote:
>I do not see the inherent advantage to going to a single byte order 
>over allowing the sac program to read two different byte orders 
>seamlessly.
>What does that gain us ?
>
>I would agree that SAC would need better documentation about the 
>file formats and how certain operations are done.
>Arthur would you be willing the document the file formats ?
>
>Brian
>
>Brian Savage wrote:
>>I forgot to post to the list, but instead sent just to George.
>>This is George's response to me.
>>
>>Hi Brian -
>>
>>On Monday, November 21, 2005, at 06:22 PM, Brian Savage wrote:
>>
>>>It sounds like whatever we decide, the file formats (SAC and SGF) 
>>>need to be documented.
>>
>>
>>Amen.  But where?  There really isn't any "formal" SAC documentation
>>any more, just broken links hanging around on the web and outdated
>>pieces of paper that I have from old SAC manuals.  It would be valuable
>>to have that roff source code (or whatever word processor LLNL used)
>>available somewhere to build modern documentation from.
>>
>>>
>>>Concerning SGF.  If it has always written the files in the same 
>>>way, why change it, make it the standard and document it.
>>
>>
>>I'm not sure whether SAC always wrote files that way, but for as long
>>as I've worked on it it has.  Still, that may not be the way that
>>others like Arthur have written SGF files!  You are implicitly
>>abandoning that community (which is probably small).
>>
>>>
>>>Concerning SAC.  If we decide all SAC files should be in big 
>>>endian format (or even little) I am certain there will be an 
>>>outcry from the community who uses Sac for processing and as a 
>>>data file format.
>>
>>
>>I'm not as certain as you are about this.  MacSAC users haven't
>>complained about initially having to use sactosac with whatever
>>heritage their data is.
>>
>>>If we specify an endianness, we are introducing more bugs on linux 
>>>machines as they will not be able to read current sac files which 
>>>are written in little endian.
>>
>>
>>Previous comments apply.  It is simple to modify sactosac to always
>>write big-endian or little-endian.  Besides, SAC isn't an archival
>>format, but a processing format.  One doesn't need to change anything
>>until it is used.
>>
>>>
>>>Brian
>>>
>>
>>PS if you meant to post your response to the list, only I got it.  You
>>can post this and get both if you want.
>>
>>
>>      George Helffrich
>>
>>_______________________________________________
>>sac-dev mailing list
>>sac-dev at iris.washington.edu
>>http://www.iris.washington.edu/mailman/listinfo/sac-dev
>
>_______________________________________________
>sac-dev mailing list
>sac-dev at iris.washington.edu
>http://www.iris.washington.edu/mailman/listinfo/sac-dev


-- 

Peter Goldstein, Ph.D.      (925) 423-1231 (office) 
  L-103, PO Box 808        (925) 422-5844 (fax)    
  Livermore, CA 94551      peterg at llnl.gov (email) 
  web pages: http://earthscience.llnl.gov/peterg/
             http://www.llnl.gov/sac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.iris.washington.edu/pipermail/sac-dev/attachments/20051129/7768e15f/attachment.html