Brian Savage
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:
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.
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).
complained about initially having to use sactosac with whatever
heritage their data is.
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.
can post this and get both if you want.
George Helffrich
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) needAmen. But where? There really isn't any "formal" SAC documentation
to be documented.
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,I'm not sure whether SAC always wrote files that way, but for as long
why change it, make it the standard and document it.
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 endianI'm not as certain as you are about this. MacSAC users haven't
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.
complained about initially having to use sactosac with whatever
heritage their data is.
If we specify an endianness, we are introducing more bugs on linuxPrevious comments apply. It is simple to modify sactosac to always
machines as they will not be able to read current sac files which are
written in little endian.
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.
BrianPS 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
-
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
Amen. But where? There really isn't any "formal" SAC documentation
to be documented.
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,
I'm not sure whether SAC always wrote files that way, but for as long
why change it, make it the standard and document it.
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
I'm not as certain as you are about this. MacSAC users haven't
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.
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
Previous comments apply. It is simple to modify sactosac to always
machines as they will not be able to read current sac files which are
written in little endian.
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
-
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)
Amen. But where? There really isn't any "formal" SAC documentation
need to be documented.
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
I'm not sure whether SAC always wrote files that way, but for as long
way, why change it, make it the standard and document it.
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
I'm not as certain as you are about this. MacSAC users haven't
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.
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
Previous comments apply. It is simple to modify sactosac to always
machines as they will not be able to read current sac files which
are written in little endian.
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
-
Peter Goldstein
