Thread: Re: doubles in sac

Started: 2007-11-29 15:49:44
Last activity: 2007-11-29 19:28:21
Topics: SAC Help
Arthur Snoke
2007-11-29 15:49:44
I used the wrong address for the sac-help listserv.

---------- Forwarded message ----------
Date: Wed, 28 Nov 2007 22:49:36 -0500 (EST)
From: Arthur Snoke <snoke<at>vt.edu>
To: Tim Ahern <tim<at>iris.washington.edu>, Brian Savage <savage<at>uri.edu>,
Robert B. Herrmann <rbh<at>eas.slu.edu>
Cc: sac-help-request<at>iris.washington.edu
Subject: Re: [SAC-HELP] doubles in sac

Tim and others,

Bob touched on what I think is the biggest problem in modifying sac: the header
is fixed in length so one could not easily double all the floats.

The simplest interim solution as I see it that would allow sac to continue to
live is to have rdseed spew out single precision to a sac format. Except for
timing as in Bob's example or in very high sample rates in general, where are
doubles needed?

Arthur

On Wed, 28 Nov 2007, Robert B. Herrmann wrote:

sac-help-request<at>iris.washington.edu wrote:

Tim: I do not know if this response will get back to the mailing list - so
you get a copy

If the data stream should be modified to have doubles for the data, we should
also consider doubles for the SAC float header values - One CANNOT pick time
correctly at 23:59:59 for 200 Hz data sets (I know this is extreme) is the
continuous data stream starts at 00:00:00 - the seven digit accuracy of
floating point is exceeded

One would just need to redefine a new header version - I believe tha tthe
current header is at version 7

Given a define change, gsac would have it implemented in about one hour.
Internally gsac uses doubles for the float header values.
1
Date: Wed, 28 Nov 2007 11:41:39 -0800
From: Tim Ahern <tim<at>iris.washington.edu>
Subject: [SAC-HELP] Double Precision
To: sac-help<at>iris.washington.edu
Cc: Doug Neuhauser <doug<at>seismo.berkeley.edu>, Robert Uhrhammer
<bob<at>seismo.berkeley.edu>, Chris Laughbon
<chris<at>iris.washington.edu>,
Charley Weiland <cweiland<at>stanford.edu>

Greetings

We have a question for the SAC users group. Recently a need to support
double precision floating point for data in SEED format has been identified.
While SEED itself can support this, the problem comes with possible output
formats the rdseed program should support. The most widely used format is
SAC format in our estimation.

Our question is, is it possible for SAC to support double precision floating
point values without loosing precision? Would it be extremely difficult to
add double precision support for SAC? Even if SAC can not support the
format, would it make sense to have a double precision version of the SAC
Format, if you understand what I mean by that.

One further question is, assuming that SAC and SAC format are not ready for
double precision and it would be difficult to support it... what new format
do you think we might consider supporting as an output format for rdseed?
Do any of you have suggestions as to possible ways to deal with double
precision floats as an output format?

Thanks for any help you can provide us.

Cheers
Tim

  • Brian Savage
    2007-11-29 19:28:21
    All,

    I am shifting this conversation over to sac-dev

    Cheers,
    Brian

    On Nov 29, 2007, at 7:49 AM , Arthur Snoke wrote:

    I used the wrong address for the sac-help listserv.

    ---------- Forwarded message ----------
    Date: Wed, 28 Nov 2007 22:49:36 -0500 (EST)
    From: Arthur Snoke <snoke<at>vt.edu>
    To: Tim Ahern <tim<at>iris.washington.edu>, Brian Savage
    <savage<at>uri.edu>,
    Robert B. Herrmann <rbh<at>eas.slu.edu>
    Cc: sac-help-request<at>iris.washington.edu
    Subject: Re: [SAC-HELP] doubles in sac

    Tim and others,

    Bob touched on what I think is the biggest problem in modifying
    sac: the header is fixed in length so one could not easily double
    all the floats.

    The simplest interim solution as I see it that would allow sac to
    continue to live is to have rdseed spew out single precision to a
    sac format. Except for timing as in Bob's example or in very high
    sample rates in general, where are doubles needed?

    Arthur

    On Wed, 28 Nov 2007, Robert B. Herrmann wrote:

    sac-help-request<at>iris.washington.edu wrote:
    Tim: I do not know if this response will get back to the mailing
    list - so you get a copy
    If the data stream should be modified to have doubles for the
    data, we should also consider doubles for the SAC float header
    values - One CANNOT pick time correctly at 23:59:59 for 200 Hz
    data sets (I know this is extreme) is the continuous data stream
    starts at 00:00:00 - the seven digit accuracy of floating point is
    exceeded
    One would just need to redefine a new header version - I believe
    tha tthe current header is at version 7
    Given a define change, gsac would have it implemented in about one
    hour. Internally gsac uses doubles for the float header values.
    1
    Date: Wed, 28 Nov 2007 11:41:39 -0800
    From: Tim Ahern <tim<at>iris.washington.edu>
    Subject: [SAC-HELP] Double Precision
    To: sac-help<at>iris.washington.edu
    Cc: Doug Neuhauser <doug<at>seismo.berkeley.edu>, Robert Uhrhammer
    <bob<at>seismo.berkeley.edu>, Chris Laughbon
    <chris<at>iris.washington.edu>,
    Charley Weiland <cweiland<at>stanford.edu>
    Greetings
    We have a question for the SAC users group. Recently a need to
    support double precision floating point for data in SEED format
    has been identified. While SEED itself can support this, the
    problem comes with possible output formats the rdseed program
    should support. The most widely used format is SAC format in our
    estimation.
    Our question is, is it possible for SAC to support double
    precision floating point values without loosing precision? Would
    it be extremely difficult to add double precision support for
    SAC? Even if SAC can not support the format, would it make sense
    to have a double precision version of the SAC Format, if you
    understand what I mean by that.
    One further question is, assuming that SAC and SAC format are not
    ready for double precision and it would be difficult to support
    it... what new format do you think we might consider supporting
    as an output format for rdseed? Do any of you have suggestions as
    to possible ways to deal with double precision floats as an
    output format?
    Thanks for any help you can provide us.
    Cheers
    Tim
    _______________________________________________
    sac-help mailing list
    sac-help<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/sac-help


16:41:02 v.22510d55