[rsf-user] I can't figure out how to import segy

152 views
Skip to first unread message

Sven Lars Tobias Stål

unread,
Oct 1, 2014, 6:45:51 PM10/1/14
to RSF-...@lists.sourceforge.net
Dear all,

I have problem to convert segy files to rsf using sfsegyread. I’m new in this, so I’m grateful if anyone can point me in the right direction. I’m using 64bit OS X.

My segy raw data looks good in e.g. OpendTect.

Scenario 1
I’ve converted seg-2 files using the SU program seg2segy. The raw data looks correct in OpendTect. If I run

sfsegyread < 1001.sgy endian=y su=y tfile=1001.rsf

everything seems to work, Header data displays:

d2=1
o1=0
n2=17711
o2=0
label1="Time"
data_format="native_float"
head="1001.rsf"
label2="Trace"
esize=4
in="stdout"
unit1="s"
d1=0
n1=0
in="stdin"

but when I try for example
sfgraph < 1001.rsf title="1001" > 1001.vpl
or any processing I get:

sfgraph: Wrong data type (need float or complex)

Setting format= or endian= makes no change.

sfattr < 1001.rsf
*******************************************
rms = 1.71108e+07
mean = 3824.69
2-norm = 2.17226e+10
variance = 2.92779e+14
std dev = 1.71108e+07
max = 2.1465e+09 at 85 17620
min = -2.12704e+09 at 85 17653
nonzero samples = 1260468
total samples = 1611701
*******************************************

sfin 1001.rsf
1001.rsf:
in="./1001.rsf@"
esize=4 type=int form=native
n1=91 d1=? o1=?
n2=17711 d2=? o2=?


Scenario 2
I used IXSeg2SegY to convert the data from SEG-2 to SEGY. Raw SEGY looks good in SeisLab or OpendTect. I’ve also tried to re-export from other applications, but no help when I try to convert to rsf

I run: sfsegyread < 1001.sgy endian=y tfile=1001.rsf

This time the header doesn’t display correctly, but a rsf file is generated. Again, when I try for example
sfgraph < 1001.rsf title="1001" > 1001.vpl or any processing I get:

sfgraph: Wrong data type (need float or complex)

I (believe) that I tried all possible format and endian settings.

What do I do wrong?

Best regards
Tobias


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
RSF-user mailing list
RSF-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsf-user

Karl Schleicher

unread,
Oct 3, 2014, 11:58:25 AM10/3/14
to rsf users list
Tobias,
The rsf volume is output to stdout.   
tfile is the the trace header file.  It is integer.  You can verify with
sfin <1101.sgy

I have recently downloaded and displayed a 3D stacked volume.  The attached SConstruct files download/convert_to_rsf and convert_to_3d and display.  If you have the development version of Madagascar installed you can run:
cd $RSFSRC/book/data
# get the most recent scripts below this disctory
svn update
cd /new-zealand/parihaka-3d/fetch
#download and convert segy to rsf (first attached SConstruct)
scons
cd ../displaying
#display the volume (second attached SConstruct)
scons view

Hope this helps.
Karl Schleicher
SConstruct
SConstruct

Sergey Fomel

unread,
Nov 1, 2014, 12:38:25 PM11/1/14
to Sven Lars Tobias Stål, rsf user
Tobias,

You should not use the same name for tfile= and the standard output. These are two different files.

Try

sfsegyread < 1771.sgy endian=y su=n  tfile=t1771.rsf > 1771.rsf

sfheaderattr < t1771.rsf

SF

On Mon, Oct 27, 2014 at 11:22 AM, Sven Lars Tobias Stål <smp...@alumni.ku.dk> wrote:

I’d very grateful for any advice, I’ve a background in geology rather than programming, so I suspect that it’s a very basic misstake, but I can’t figure out what and none of my colleagues nor the forum could help me. 

I’ve used the SU program seg2segy to convert seg2 files. The resulting sgy file can easily be opened and inspected in various application as e.g. OpendTect (screen dump and segy attached). Binary header appears correct (96 traces, 22000 samples, 500 us sample interval) but “format" is set to 2. The traces looks correct, it’s sweep data, in this case placed near station 50. 

However, when I’m trying to convert the segy to rsf

sfsegyread < 1771.sgy endian=y su=n  tfile=1771.rsf > 1771.rsf

I get this result:

sfheaderattr < 1771.rsf
22000 headers, 96 traces
sfheaderattr: build/system/seismic/segy.c: The header is too long: 22000 > 256

Sergey Fomel <sergey...@gmail.com> wrote:

Tobias,

sfsegyread splits the information in SEGY file into two files: the trace header file and the raw traces file.

If you run

sfsegyread < 1001.sgy endian=y su=y tfile=1001.rsf > file.rsf

the seismic traces will be in file.rsf and the trace header information will be (in integer format) in 1001.rsf You can examine trace headers with

sfheaderattr < 1001.rsf

and display seismic traces with

sfgrey < file.rsf | sfpen

More information at http://www.ahay.org/wiki/Guide_to_RSF_file_format#Reading_and_writing_SEG-Y_and_SU_files

SF

Reply all
Reply to author
Forward
0 new messages