Segy file and segy2grd

I find a bit difficult to use segy2grd specially to know the right parameters. Often I have to use too many trial and errors to get the output that I want.

How can I know which parameters to use for segy2grd?
Is there any way to extract them from the segy file? Something like gmt grdinfo segy.

Any suggestions? Besides using Julia.

For the record, I found that dd can be used to extract info from the file (and them used gmt convert) to get info from the binary header of the file.

For example, to get the number of samples (located in bytes 21-22 of the bin header) this command can be used:

dd if=segy.file bs=2 count=1 skip=3220 iflag=skip_bytes | gmt convert -bi1h+b

1 Like

Usind dd is really cool.

You might want to try Seismic Un*x as well.

Thanks. Have You use dd for segy files?

I found it because I want to split a very large segy (48 GB) into hundreds of pieces. I try segyio (in python) but I needed more memory.

I look at SeismicUnix but as far as I know, there is no direct way to just split the segy file without converting it to a SU format. Do you know if it possible? My idea is to use it when I need to process the seismic data.

I came across a similar example as you posted which basically outputs the header;

$ dd if=file.sgy conv=ascii ibs=3200 count=1
C 1 ........
C 2.........
C 3.........

See:

So you want to split up a segy file and be able to process/look at each split file like it’s a standalone file? Do not know of any good ways of doing that unfortunately.

If you just want to split a huge file into smaller pieces, transfer to some place, and then merge (ending up with the same huge file you started out with), that’s trivial I think.

1 Like

Thanks. It is good to know that dd it is used for segy files.

In orther to split the segy I made this script:

# Input Data
# --------------------------------------------------------------
# File to split (input)
in=test.sgy

# Output file
out=dd_001.sgy

# Start and end trace of output file
TraceI=100
TraceF=1932

# 1. Extract information from Bin Header and perform calculations
# -----------------------------------------------------------------------------
# 1A. Extract Number of Samples (NS) per trace (bytes 21-22)
NS=$(dd if=$in bs=2 count=1 skip=3220 iflag=skip_bytes | gmt convert -bi1h+b)

# 1B. Extract Code from Data Sample Format (bytes 25-26) 
SF=$(dd if=$in bs=2 count=1 skip=3224 iflag=skip_bytes | gmt convert -bi1h+b)
# Indexed arrays (byte list for Data Sample Format code according to Table 2 of SEG-Y_r2.0 Hagelund (2017).
SFC=(0 4 4 4 2 4 4 4 4 8 3 1 8 4 2 8 0 0 0 3 1)
Bytes=${SFC[$SF]}

# 1C. Perform calculations to find out which bytes to extract
NT=$$(($TraceF-$TraceI+1)) # Number of Traces
BT=$$(($NS*$Bytes+240)) # Amount of Bytes per Trace (header + header)
BTI=$$(($BT*($TraceI-1)+3600)) # Number of bytes of the initial trace

# 2. Create the new Segy
# -----------------------------------------------------------------------------
# 1. Copy Header (it is always the first 3600 bytes)
dd if=$in bs=3600 count=1 > $out

# 2. Add trace data
dd if=$in skip=$BTI iflag=skip_bytes bs=$BT count=$NT >> $out

Translated with www.DeepL.com/Translator (free version)
1 Like

He says, file size doesn’t matter

1 Like

Very cool. And sorry, I don’t know of a way to split files without converting to SU.

Are you dealing with 3D-seismic data? Those are big file sizes.

@Joaquim: do you know of any Julia tools that can read multibeam .all-files (Kongsberg) and water column data?

GMT.jl, off course :slight_smile:

More seriously, my GMT installer for Windows comes with this GMT custom lib https://github.com/joa-quim/mbgmt
and with it, one can load MB files in Julia and have them available to GMT.
Documentation is (surprise) very scarce but from my test list I can see that at least these functions exists

mbgetdata, mbimport, mbsvplist, mblevitus

1 Like

This is mb-system with a different interface, or does it expand it’s capabilities? I’m especially interested in the ability of working with water column data, and mb-system does not have that feature (yet).

It’s plain MB less (most of) the executables.
Don’t know about water column data formats. Suspect that they must use some sort of seismic format. But if MB can read them, it should be possible to read them with GMT.jl too (or make it do so).

1 Like

Thanks @Joaquim!