[CWP/SU] segywrite - format option

[Mark Howie]

Hi

I have a problem with segywrite. I have an SU file that I want to
convert to a segy file.; I am using segyhdrs and segywrite.

My main problem is that the only options that affect the format of the
sample bytes is segywrite's conv= and endian= parameters. The format=
parameter for segywrite does nothing. The format= parameter for segyhdrs
only affects the binary header and not the actual sample bytes in the
segy file.

I am running Seismic Unix version 41, compiled under Linux (Redhat
Enterprise 4), with only a few minor changes to the default Makefile.config.

Also - segywrite's conv parameter : what does this do?

Also - the only way that I get a segy with the same sample byte format
as the SU file is if I use
segywrite conv=0 endian=1
Now, the SU file byte format is specified as being native-endian IEEE.
So I expected that I would have had to use
segywrite conv=0 endian=0
Why do I have to set it to big-endian to get the same byte format when
in fact I am running Linux on a standard PC?

Finally, I do actually want to produce little-endian IEEE data in the
SEGY file. But with all the above problems, I cannot be sure of
anything that segywrite is producing.

Any help will be very much appreciated. I have been using Seismic Unix
for over five years - it's a very useful tool.

Regards
Mark

This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.

_______________________________________________
seisunix mailing list
seis...@dix.mines.edu
http://www.cwp.mines.edu/mailman/listinfo/seisunix

[Reginald Beardsley]

Mark,

When you write out a file specify "lheader=1" and you'll have a SEG-Y file in your native floating point format, though the format descriptor in the binary line header will be wrong. You can make this the default behavior by specifying -DSU_LINE_HEADER at compile time.

For example:

suplane lheader=1 >little_endian_ieee.sgy

suplane lheader=0 >>little_endian_ieee.sgy

will concatenate additional traces when -DSU_LINE_HEADER is setg.

Have Fun!
Reg

BTW

conv=0 means don't change the floating point format

endian=1 means don't swap bytes

[Gary Billings]

Mark, if you need little-endian IEEE in your 'SEGY' file to suit a
commercial application, please lean on your application vendor to have
them make their software compliant with the SEGY standard. SEGY rev 1,
section 3.3, specifies that only big-endian is allowed in conforming
SEGY formatted files. I.e., strictly speaking, little-endian IEEE is
not a valid SEGY file.

Curmudgeonly, Gary Billings

[Mark Howie]

Hi

The use of IEEE is not in the SEGY standards, but segyread allows for
the binary format field (BHED.format) to be 5 to indicate IEEE
formatting. It seems sensible that segywrite should also allow for IEEE
output?

Can you confirm what format SU files are stored in. The online
documentation suggests native-endian IEEE. Since I am working in linux I
would expect the following to produce a file with identical sample bits :
> segywrite conv=0 endian=0
This is not the case.

My problem is that I wish to use Seismic Unix to process a segy file. I
wish to ensure that the output format is identical to the input format.

The segy file I start with is in little-endian IEEE format. I read it with
> segyread endian=0 tape=file.segy

The processing I do is minimal, just trace decimation :
> suwind j=4 s=1 < file.su > file2.su

Then I create segy header files with :
> segyhdrs < file2.su format=5

Finally I try to produce segy in IEEE format :
> segywrite tape=fileout.segy < file2.su conv=0 endian=0 format=5

I have found that the format parameter for segyhdrs sets the header
field correctly but this does not affect the output from segywrite.
There is an option to pipe output from segyhdrs to another SU file but
this does nothing to the byte format. Also using the format parameter
for segywrite does nothing.

It seems that with all the various options for changing the sample byte
format none of them actually do anything to the sample bytes
themselves. The endian parameter to segywrite does flip endian-ness I
seem to have to set it to 'endian=1' to get the bytes to match those in
the SU file, suggesting that the SU file is in fact big-endian. Maybe I
have something wrong in the configuration file before I compiled Seismic
Unix?

Regards
Mark

John Stockwell wrote:
> Hi Mark,
>
> The original SEGY data format requires that the data be written in
> a particular IBM tape format (not IEEE). The conv=0 parameter turns
> off this conversion so that the data are written in the native binary
> format of your machine. If you are working on a little endian machine
> you should set endian=0 so that the headers get byte swapped accordingly.
>
> The segywrite program does what it is written to do is to write SEG
> data according to the SEG's tape standard booklet. Please note that
> little endian IEEE is not one of the formats supported even by SEGY
> rev 1.
>
> I will check the format= parameter in segywrite. I haven't looked at
> that in awhile to see that it functions as it is supposed to.
>
> -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.

[Reginald Beardsley]

Mark,

A few points:

SEG-Y revision 1 does allow IEEE floating point (format=5), but does not endorse LittleEndian data. However, most seismic software supports IEEE SEG-Y of either byte order.

Native SU floating point format is the native format of the system you're using unless you set -DSUXDR in which case it becomes BigEndian IEEE.

If you compile CWP/SU w/ -DSU_LINE_HEADER you can read and write native IEEE SEG-Y directly as SU format data. SU doesn't do anything w/ the input line header, but it does pass the contents along to the output. You'll need to be careful about the trace header contents, but simple stuff will work.

for example:

suwind <in.sgy >out.sgy count=100

will peel off the first 100 traces from your segy file and preserve the existing text and binary line headers.

CAVEAT: The endianess of the data must match the system you're running on.

The feature is "dumb" in the sense that no attempt is made to use the information in the line headers, so if you need to alter the input line headers you'll have to do that yourself.

I implemented the feature, so this is the "authoritative" answer ;-)

Take a look at the sections delimited by "#ifdef SU_LINE_HEADER" in fputtr.c & fgettr.c.

Have Fun!
Reg

BTW If you need to be able to write other legal SEG-Y formats w/ segywrite, I can implement them if you can get your boss to pay for it :-)

[Reginald Beardsley]

Mark,

After I sent my email, I got to thinking about it and looked at the code again.

If you have LittleEndian IEEE SEG-Y data and are running on an Intel or AMD processor,

suwind <in.sgy >out.sgy lheader=1 j=4 s=1

will do exactly what you ask for independent of whether you compiled w/ -DSU_LINE_HEADER. You don't need the segyread/segywrite steps. Not a well documented feature, but it works reliably.

Have Fun!
Reg

[Gery Herbozo Jimenez]

Hi, three questions:
 
1) When I get geometry setting from a SU file using the sugethw command (i.e., output=geom), I can choose it in ASCII format. Is it the standard ASCII format (i.e., 7 bits for each character)? if so, would it be the same as the ASCII format provided by the Golden Surfer Software and Excel?
 
2) I have x,y navigation coordinates in WGS84 UTM 18S obtained from the software SonarWiz.Map v4 (e.g., 685224.256) from a CSF file (subbottom profile). They are in CSV format, so I can open it with Surfer or Excel, multiply them by 100 and save them in ASCII format. If they are in ASCII, I should convert them to binary format (using a2b command) and putting into my SU file (after getting rid of my old sx,sy,gx,gy) using the sushw command. However, this tool (sushw) does not allow me to do it, why?
 
3) Regarding to velocity analysis, how could I do to get the flatness-events approach explained in the Yilmaz (pp. 293, Fig. 3.2-4, Seismic Data Analysis, Volume 1)?, Is it possible using the SU commands?
 
Hope you can support me,
 
Best Regards,
 
Gery. 

---

La cartera, las gafas. ¿te falta algo? Ahora llévate Messenger en tu móvil

[Dominique Rousset]

Le Thursday 09 October 2008 17:48:08 Gery Herbozo Jimenez, vous avez écrit :
> Hi, three questions:
>
> 1) When I get geometry setting from a SU file using the sugethw command
> (i.e., output=geom), I can choose it in ASCII format. Is it the standard
> ASCII format (i.e., 7 bits for each character)? if so, would it be the same
> as the ASCII format provided by the Golden Surfer Software and Excel?

Since sushw outputs numbers you should'nt have problems with encoding.

> 2) I have x,y navigation coordinates in WGS84 UTM 18S obtained from the
> software SonarWiz.Map v4 (e.g., 685224.256) from a CSF file (subbottom
> profile). They are in CSV format, so I can open it with Surfer or Excel,
> multiply them by 100 and save them in ASCII format. If they are in ASCII, I
> should convert them to binary format (using a2b command) and putting into
> my SU file (after getting rid of my old sx,sy,gx,gy) using the sushw
> command. However, this tool (sushw) does not allow me to do it, why?

sushw infile= should do the job. You have to be more accurate in the
description of the problem.

> 3) Regarding to velocity analysis, how could I do to get the
> flatness-events approach explained in the Yilmaz (pp. 293, Fig. 3.2-4,
> Seismic Data Analysis, Volume 1)?, Is it possible using the SU commands?
>
> Hope you can support me,
>
> Best Regards,
>
> Gery.

If you need a basic training in velocity analysis, you need to read Yilmaz's
book with attention. Velocity anlysis using NMO correction is a common
analysis tool with multioffset data any seismic processing book will describe
it.
For use within SU, you can get a look at the demos in $CWPROOT/src/demos
(NMO and Velocity_Analysis at least). You can also get benefits from the book
Seismic Data Processing sith Seismic Un*x (SEG)

D.
--
|Dominique Rousset Modélisation et imagerie en géosciences - UMR 5212|
|Univ. Pau et des Pays de l'Adour BP 1155 F-64013 Pau Cedex - France|
|mailto:dominiqu...@univ-pau.fr http://migp.univ-pau.fr|
|Fixe:+33 5 59 40 74 23 | Mobile: +33 6 60 86 13 91 | Fax: +33 5 59 40 74 15|

[Gery Herbozo Jimenez]

 

Hello SU users,

 

I would like some support about the common offset method (COF), is it possible to do it with SU? I'm in a offshore survey and getting shallow marine seismic data with a boomer (280 joules boomer plate, with a single-channel streamer of 8 hydrophones) through the sonarwizmap software. I get the unprocessed seismic section (ussually with lots of ringing) and I'm confused because don't know if it is necessary to arrange it like COF or it is already done, do I have to? what would it be my "optimum window" source-receiver offset?. My data test range is:

 

2215 traces:
tracl    14512 16726 (14512 - 16726)
fldr     14512 16726 (14512 - 16726)
tracf    1
ep       98 118 (98 - 118)
trid     1
gdel     0 8 (0 - 2)
sdel     0 8 (0 - 2)
gwdep    0 8 (0 - 2)
scalel   1
scalco   -100
sx       65433584 65594174 (65433584 - 65594174)
sy       918254208 918265033 (918264852 - 918254208)
counit   1
ns       3000
dt       33
year     2008
day      327
hour     15
minute   2 22 (2 - 22)
sec      0 59 (20 - 3)
timbas   2

 

How could I calculate my offset keyword header? About my survey configuration, the boomer plate (catamaran) and the hydrophone streamer are towed 20-m behind the ship and they are separated around 2-m each other (since the starboard). The streamer microphone and plate run parallel. The boomer source power has 280 joules, trigger rate of 533 ms (0.5 ms) and frequency sample of 30 kHz/channel (I think it has to be between 8 or 16 kHz, but 30 kHz was a test). With this configuration I got lots of ringing and practically no penetration (around 6-8 m penetration, but I expected around 20-30 m of penetration because the geology of the area is mainly composed of fine-grained unconsolidated and consolidated sandy sediments). The water column depth range goes from 3 m to 20 m.

 

Also, is it possible to do some deterministic deconvolution in SU to attenuate the multiples of my data?

 

Any help is very grateful, thanks in advance.

 

With Best Regards,

 

Gery. 

 

---

¡Pasa del Pendrive! Skydrive almacena hasta 5 GB online gratis

[Gery Herbozo Jimenez]

[hosseini...@gmail.com]