[Seisunix] Reading long SEGY traces
Heigl, Werner
I have just been provided with a SEGY file whose traces are 60,000 samples long, and I can't seem to figure out how to convert them into SU format.
Any ideas are highly appreciated,
Werner
_______________________________________________
seisunix mailing list
seis...@mailman.mines.edu
https://mailman.mines.edu/mailman/listinfo/seisunix
Unsubscribe: seisunix-u...@mailman.mines.edu
John Stockwell
You will have to install a non-standard version of SU, as a separate
installation.
Do this by changing in segy.h the type of the ns field from "short" to "int"
and change SUNFLTS to something that is bigger than 60000. Then
do make remake.
You should be able to read the data, but it will not be in a form
that other SU installations can read.
There may be some type conflicts, but you can fix these.
If possible I would use suresamp to resample the data back to something
less than
30,000 samples per trace, write out the data as segy and then
read *that* file in your regular version of SU.
Otherwise, you will be working in your own SU universe.
-John
John Stockwell | jo...@dix.Mines.EDU
Center for Wave Phenomena (The Home of Seismic Un*x)
Colorado School of Mines
Golden, CO 80401 | http://www.cwp.mines.edu/cwpcodes
voice: (303) 273-3049
Our book:
Norman Bleistein, Jack K. Cohen, John W. Stockwell Jr., [2001],
Mathematics of multidimensional seismic imaging, migration, and inversion,
(Interdisciplinary Applied Mathematics, V. 13.), Springer-Verlag, New York.
Vincent Vandeweijer
One way I can think of dealing with this issue is making smart use of dd and cutting the traces in parts. But this is might quickly become a horrid task...
I'm curious to what other solutions are out there...
Regards,
Vincent
Turbo lag is there for a reason; it gives you the time to put your coffee in the cup holder...
John Stockwell
larger than SHRT_MAX in sample number, likely the trace headers are
not standard SEGY. You need to have the header map of the data before
proceeding. You may need to read it into Promax, and then proceed
from there.
John Stockwell | jo...@dix.Mines.EDU
Center for Wave Phenomena (The Home of Seismic Un*x)
Colorado School of Mines
Golden, CO 80401 | http://www.cwp.mines.edu/cwpcodes
voice: (303) 273-3049
Our book:
Norman Bleistein, Jack K. Cohen, John W. Stockwell Jr., [2001],
Mathematics of multidimensional seismic imaging, migration, and inversion,
(Interdisciplinary Applied Mathematics, V. 13.), Springer-Verlag, New York.
_______________________________________________
Reginald Beardsley
You MUST make certain that expanding ns to int from short does not break the alignment of the next int in the structure. Doing this requires deleting a short from the header which is after ns & before the next int.
I've attached a patchfile which allows a megasample trace (1024*1024 samples)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I HAVE NOT TESTED THIS TO ANY SIGNIFICANT DEGREE. USE AT YOUR OWN RISK !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Have Fun!
Reg
Gary Billings
to unsigned short in segy.h? Then SUNFLTS could be up to 65535. I'm
thinking that would give enough of an increase for Werner's problem,
would not change the overall length of the headers, would not require
removing a defined header, wouldn't cause alignment problems, ... Am
I missing something?
I'm not advocating this as change to the released su -- just a kludge
for Werner to read his non-SEGY-compliant dataset.
g.
> <long.patch>_______________________________________________
Heigl, Werner
Sent from my iPhone
Adelson Santos de Oliveira
short. The same holds for the sample rate.
I had this problem once and wondered why SU didn't implement this
correctly.
Em 17-02-2011 22:04, Heigl, Werner escreveu:
> Great idea. Would make sense for this to be the default.
>
> Sent from my iPhone
>
> On Feb 17, 2011, at 9:01 PM, "Gary Billings"<obs...@gmail.com> wrote:
>
>> I'm curious: would it work to change the data type of ns from short
>> to unsigned short in segy.h? Then SUNFLTS could be up to 65535. I'm
>> thinking that would give enough of an increase for Werner's problem,
>> would not change the overall length of the headers, would not require
>> removing a defined header, wouldn't cause alignment problems, ... Am
>> I missing something?
>>
>> I'm not advocating this as change to the released su -- just a kludge
>> for Werner to read his non-SEGY-compliant dataset.
>>
>> g.
>>
>>
>> On 17-Feb-11, at 3:41 PM, Reginald Beardsley wrote:
>>
>>> FYI I tested modifying the header definition in 42 to allow longer
>>> traces. In general this seems to work, though doubtless there are
>>> some programs which will fail.
>>>
>>> You MUST make certain that expanding ns to int from short does not
>>> break the alignment of the next int in the structure. Doing this
>>> requires deleting a short from the header which is after ns& before
Gary Billings
both binary and trace headers is 2 bytes, twos complement integer,
i.e. a signed short. It would have been good if those who wrote the
standard had made it unsigned, but they didn't.
g.
Heigl, Werner
Sent from my iPhone
Gary Billings
writes files that are SEGY-standard compliant and that su format maps
cleanly to SEGY. So, I vote against changes to the "official" su that
cause it to violate (as opposed to extend, e.g. in unused header
fields) the SEGY standard especially in one of the most critical
fields (ns): if we want to change the SEGY standard, the place is the
SEG Technical Standards Committee. They "own" the standard! They
meet at every SEG convention. Their meeting is open to anyone who
wants to attend -- I've been to some: I think the "regulars" were
shocked that a new face was there!
g.
Mark Wiederspahn
There are several locations where the possibility of an
unsigned number would have been nice. However, the standard
is quite clear about this, and always has been (SEGY
came from Fortran coding practice where there were no
unsigned datatypes at all). To change it because of
convenience invites the very chaos which a standard is
supposed to overcome, particularly when the value
affects the structure of the file.
If you have to have long SEGY-like traces, consider
use of PASSCAL segy has other useful attributes too.
> Gary Billings <obs...@gmail.com> wrote:
> I looked at the standards documents today, from the SEG site. ns in
> both binary and trace headers is 2 bytes, twos complement integer,
> i.e. a signed short. It would have been good if those who wrote the
> standard had made it unsigned, but they didn't.
>> Em 17-02-2011 22:04, Heigl, Werner escreveu:
>> Great idea. Would make sense for this to be the default.
>>
>> On Feb 17, 2011, at 9:01 PM, "Gary Billings"<obs...@gmail.com>
>> wrote:
>>
>>> I'm curious: would it work to change the data type of ns from short
>>> to unsigned short in segy.h? Then SUNFLTS could be up to 65535.
mw
--
Mark Wiederspahn
Institute for Geophysics/Jackson School of Geosciences
University of Texas at Austin
Adelson Santos de Oliveira
Check, for instance, at this site:
http://utam.geophys.utah.edu/ebooks/rhe5220/segy.html
look at bytes 115 and 117.
Gary Billings
recollection that ns was unsigned. But I went to the SEG site today,
and downloaded both the rev 0 (1975) and rev 1 (2002) standards.
Neither of those documents say the ns field is unsigned. Both
documents say all the fields are either 2 byte or 4 bytes twos
complement integers.
Somewhere I have a paper copy of the SEGY standard, published by the
SEG and purchased about 1993. I'll look for it. And the original
standard was published in Geophysics...
g.
Heigl, Werner
Sent from my iPhone
Glenn Reynolds
Has anybody had experience with negative ns? What is it designed for?
Does REV1 of SEGY also use a short?
Maybe they meant unsigned short at the time. There's a spelling error
in a rev 0 header that has never been fixed. Laziness rather than evil
genius may be behind both.
Muahahahaha
Glenn
Mobile
On 18 Feb, 2011, at 9:31 AM, Adelson Santos de Oliveira
Gary Billings
I know of no reason for ns<0. In fact, I'd say it is bad practice to
let a field like that accept a value that is nonsensical. But that
gets in to one of the big problems with SEGY: it defines the boxes,
but with no logic about what is put in them.
g.
Gary Billings
not be able to output it as SEGY.
yes, I'm a zealot about SEGY standards... I continue to spend too
much of my life fixing files that people tell me are SEGY, but aren't.
g.
Heigl, Werner
Sent from my iPhone
Reginald Beardsley
FWIW At the time of the original SEG-Y standard, FORTRAN was the 'lingua franca' in the seismic community so they couldn't specify an unsigned short. The concept didn't exist within that community. C is a systems programming language. It was designed to replace assembly language.
Have Fun!
Reg
--- On Thu, 2/17/11, Glenn Reynolds <gdrey...@gmail.com> wrote:
Gary Billings
part of the code, I think SU_NFLTS was hardcoded at 32767
users beware, if generating segy files from su files with ns>32767!
not clear then why Werner's file would not read.
g.
<snip>
Gary Billings
myself here), SU_NFLTS was hard-coded to be 32768, and ns and dt were
unsigned shorts
So, while not pretty, that would still ensure su didn't try to
generate non-standard SEGY traces in segywrite.
I'm smelling rotting horsemeat here, so time to pack it in...
g.
JURANDYR SCHMIDT
that was what I did some time ago when working with passive seismic data (more than 60000 samples ).
I remap the segy.h making ns a int instead a short and change the SUNFLTS to 1000000.
I remap segy.h to fit some features of the PASSCAL format.
It works pretty well for my needs. In fact I haven´t test everything.
Atached is the hdr.h
jurandyr
> Date: Thu, 17 Feb 2011 08:51:04 -0700
> From: jo...@dix.mines.edu
> To: Werner...@apachecorp.com
> CC: seis...@mailman.mines.edu
> Subject: Re: [Seisunix] Reading long SEGY traces
>
>
> You will have to install a non-standard version of SU, as a separate
> installation.
> Do this by changing in segy.h the type of the ns field from "short" to "int"
> and change SUNFLTS to something that is bigger than 60000. Then
> do make remake.
>
> You should be able to read the data, but it will not be in a form
> that other SU installations can read.
>
> There may be some type conflicts, but you can fix these.
>
> If possible I would use suresamp to resample the data back to something
> less than
> 30,000 samples per trace, write out the data as segy and then
> read *that* file in your regular version of SU.
> Otherwise, you will be working in your own SU universe.
>
> -John
>
> >
> > I have just been provided with a SEGY file whose traces are 60,000 samples long, and I can't seem to figure out how to convert them into SU format.
> >
> > Any ideas are highly appreciated,
> > Werner
> >
> > seisunix mailing list
> > seis...@mailman.mines.edu
> > https://mailman.mines.edu/mailman/listinfo/seisunix
> > Unsubscribe: seisunix-u...@mailman.mines.edu
> >
>
> Center for Wave Phenomena (The Home of Seismic Un*x)
> Colorado School of Mines
> Golden, CO 80401 | http://www.cwp.mines.edu/cwpcodes
> voice: (303) 273-3049
>
> Our book:
> Norman Bleistein, Jack K. Cohen, John W. Stockwell Jr., [2001],
> Mathematics of multidimensional seismic imaging, migration, and inversion,
> (Interdisciplinary Applied Mathematics, V. 13.), Springer-Verlag, New York.
>
John Stockwell
are calculated and tabled upon installation, so your version
of SU would have a gap in the header, but it doesn't matter
because the offsets are tabulated in the file hdr.h.
The offset is only an issue if you are attempting to transfer SU
data from this installation of SU to another version of SU. Then
you would have to use segywrite to write a new segy file.
John Stockwell | jo...@dix.Mines.EDU
John Stockwell
John Stockwell | jo...@dix.Mines.EDU
Center for Wave Phenomena (The Home of Seismic Un*x)
Colorado School of Mines
Golden, CO 80401 | http://www.cwp.mines.edu/cwpcodes
voice: (303) 273-3049
Our book:
Norman Bleistein, Jack K. Cohen, John W. Stockwell Jr., [2001],
Mathematics of multidimensional seismic imaging, migration, and inversion,
(Interdisciplinary Applied Mathematics, V. 13.), Springer-Verlag, New York.
_______________________________________________
John Stockwell
John Stockwell | jo...@dix.Mines.EDU
Center for Wave Phenomena (The Home of Seismic Un*x)
Colorado School of Mines
Golden, CO 80401 | http://www.cwp.mines.edu/cwpcodes
voice: (303) 273-3049
Our book:
Norman Bleistein, Jack K. Cohen, John W. Stockwell Jr., [2001],
Mathematics of multidimensional seismic imaging, migration, and inversion,
(Interdisciplinary Applied Mathematics, V. 13.), Springer-Verlag, New York.
_______________________________________________
Gary Billings
standard.
In the standard, as retrieved from the SEG website yesterday, ns and
dt are two byte, twos complement integer. su42 has them as unsigned
short. Also, su42 has SU_NFLTS as 65535, but it should be 32,767, the
max positive value that twos complement integer can represent.
Way back in su34, ns and dt were unsigned short, but SU_NFLTS as
32,768 (8, not 7).
g.
Reginald Beardsley
This is not idle speculation on my part. ARCO expanded the SEG-Y header to 340 bytes and in the process broke the word alignment. I got *lots* of experience with the problem 20 years ago when everyone was getting a RISC machines.
This was not a problem on byte addressable machines like the 360/370 series. However, it produces bus errors on most, if not all, current machines unless compiler flags are set to do byte moves of misaligned words. The SSE2 instructions for the x86 family require alignment and there is a substantial performance hit for misaligned access.
Have Fun!
Reg
--- On Fri, 2/18/11, John Stockwell <jo...@dix.mines.edu> wrote:
> From: John Stockwell <jo...@dix.mines.edu>
> Subject: Re: [Seisunix] Reading long SEGY traces
Reginald Beardsley
It might break some data, but certainly not all.
Look at segy.h in CWP/SU 42 (downloaded this morning):
#define SU_NFLTS USHRT_MAX /* Arbitrary limit on data array size */
unsigned short ns; /* number of samples in this trace
USHRT_MAX is stipulated to be at *least* 65536 in section 5.2.4.2.1 of the C99 standard.
Have Fun!
Reg
--- On Fri, 2/18/11, John Stockwell <jo...@dix.mines.edu> wrote:
> From: John Stockwell <jo...@dix.mines.edu>
> Subject: Re: [Seisunix] Reading long SEGY traces
> To: "Heigl, Werner" <Werner...@apachecorp.com>
> Cc: "seis...@mailman.mines.edu" <seis...@mailman.mines.edu>
> Date: Friday, February 18, 2011, 10:56 AM
John Stockwell
SU.
The current value of SU_NFLTS is defined as follows as:
#define SU_NFLTS USHRT_MAX
So, what are you suggesting? That I change dt and ns to "shorts" and
change SU_NFLTS to 32767?
-John
John Stockwell
are proposing that I do?
-John
Reginald Beardsley
I'm not proposing you or anyone do anything. In fact, I'm opposed.
I was pointing out that your statement about making SU_NFLTS = 65536 breaking all SU files was not correct. And that the suggestions about a need to change the current code to handle 60,000 samples were also incorrect.
If anyone wants arbitrarily long traces, the patch I posted will let them, do that. I made the patch for someone who wanted to process earthquake seismograph records. I see no reason to drag the rest of the CWP/SU community along with them. That is why I never sent it to you or posted it before.
I hope that clarifies things adequately. There was a great flurry of posts which showed people had not read what was actually in the current release.
Vincent Vandeweijer
Are you discussing
1. what the Seg-y format is?
2. what Su is/was/should be?
3. What one person can do to be able to read in some loooong traces.
It is my personal opinion that If someone wants to modify code (live in his own universe) to get the job done. Well great! Problem solved. No need to change whatever more. Or am I missing something?
Regards,
Vincent
Turbo lag is there for a reason; it gives you the time to put your coffee in the cup holder...
--
Turbo lag is there for a reason; it gives you the time to put your coffee in the cup holder...
Heigl, Werner
Sent from my iPhone
Gary Pavlis
generated. First, a few pragmatic statements:
1. It is clear this detail of SU format is deeply embedded in the
concepts SU uses for handling data. All you have to do to verify this
is look at the library routines used in SU for how it handles data. As
someone pointed out changing this would break almost everything.
2. A standard is useful because it is standard.
3. The fundamental problem is that SEGY was originally developed as an
"exchange" format more than 30 years ago. We've had I don't know how
many orders of magnitude increases in computer processor capabilities
and storage capacity. The raises havoc with assumptions that made sense
in the early 1970s.
In my opinion, this problem is not solvable without extensive surgery to
SU that is likely unjustified. If this particularly capability is
essential for someone they need to recognize it is their problem not the
developers of SU. There are numerous solutions out there to deal with
this issue and the right one depends upon what you need to do with long
traces. As someone pointed out, one of these is tools available in the
public domain from IRIS-PASSCAL. Another is the IGEOS package written
by Igor Morozov which is also open source. Few modern commercial
packages will not have a way to deal with this issue.
What most prompted me to write this email, however, is that this
dialogue is, to me, a classic example of a fundamental misunderstanding
of data that most people in geophysics hold. That is, people tend to
think of "my data" in terms of a specific format like SEGY. SEGY is an
implementation of a concept we call seismic data. Lots of elements of
SEGY like this esoteric issue of number of samples stored in a 16 bit
integer are an implementation detail. The "concept" of the "number of
samples", however, is a fundamental element of ALL seismic data. The
other elements of the lowest common denominator are: sample interval
(or sampling frequency) and what concept is used for the time of the
first sample (in earthquake seismology we have to use UTC for example).
Everything else in the SEGY header is, in the modern world, better
viewed as "metadata" meaning it is auxiliary. The only other issue is
how you store the samples, but SU and every other system I've every seen
uses the same fundamental data structure: a vector of sample data.
If you want to see an example of an abstraction of seismic data see this
page:
http://geology.indiana.edu/pavlis/software/seispp/html/d7/df8/classSEISPP_1_1TimeSeries.html
You may want to click the link that says "List all members". I will
not claim that API is perfect, but it illustrates what I'm trying to say
specifically since it is my design.
SU works and is extremely efficient at what it does because it uses a
frozen format that allows accessing specific trace metadata through a
clean, simple indexing scheme using byte offsets. This is why the 16
bit limit for number of samples is so so hard to overcome. The example
I point to above is more modern, but most definitely comes at the cost
of a higher overhead in the implementation. However, it illustrates how
future enhancements or developments should go; a basic rule in modern
software engineering is to design software in such a way as to abstract
the general concepts and make that the API hide the implementation
details behind the interface. SU is great as a practical tool for what
it does, but it's age shows in not using modern software design concepts
like this. This seems particular issue is a place where this problem
comes to the fore.
--
====================================================
Prof. Gary L. Pavlis
Department of Geological Sciences
Indiana University
1001 East 10th Street
Bloomington, IN 47405
email: pav...@indiana.edu
phone: 812-855-5141
fax: 812-855-7899
====================================================