Thread:

Started: 2005-11-21 23:10:05
Last activity: 2005-11-30 04:53:51
Topics: SAC Developers
Brian Savage
2005-11-21 23:10:05
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


  • Brian Savage
    2005-11-22 17:00:12
    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


    • Peter Goldstein
      2005-11-30 04:53:51

      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
05:01:42 v.22510d55