This is really not a question about SU but about disk read in fortran.
I know most people in this forum are experienced in C and this is an SU related forum but I am hoping someone experienced in these matters could shed light on an issue I have.
My question is about speed comparison for reading seismic data from random location on disk when data formats are different in a Fortran program.
In one case I have SU (seismic unix) formatted data which I read in fortran with access='direct' and record number corresponding to the trace. In the other data set I have the same file converted to SEGY format which I have to read with access='stream' and pos= values corresponding to the stating byte of the trace as record size is not fixed on segy data sets.
Trace locations accessed are same for both data but are quite random from call to call. Data length for traces is about 10 kilobytes.
I am observing speed ratio of about four between the two [ in favor of access=direct (i.e. for SU data) ]
Is this expected.
If not what could be wrong?
Is it possible that “stream” mode is reading more data than necessary as compared to the “direct” mode where record length (trace length in bytes) has to be specified when opening the file. There is no such thing in “stream mode”.
[]
By the way I don’t think I have this much difference between read speeds when I read traces in the order as they are on the disk (almost like sequential read but still reading with direct and stream modes)
I will appreciate your comments.
Necati Gülünay
From: Shuki Ronen [mailto:shuki.ronen@gmail.com] Sent: 12 Ağustos 2019 Pazartesi 12:45 To: Necati Gulunay n.gulunay@gmail.com Cc: petro@roxo.org; seisunix@mailman.seismic-unix.org Subject: Re: [Seisunix] short "header" in segyread
Necati, the relevance of XDR to your question is that if you cut and paste SU files using dd and cat, it may not work the way it used to work before SU was out on XDR.
But my message was not only about your question. I am not very happy to live with two alternative SU installation w w/o XDR, was horrified to see how complicated gettr and puttr became, and there is a segy rev 2 that covers data that was not foreseen at the time of segy rev1 so I think it’s about time somebody will modernize SU and will improve or do away with XDR.
SU was written in 1984 with segy 1975. I call it rev 1. If you want to call it rev 0 fine. It was the 1975 segy. With the last 60 bytes in the 240 byte trace headers as free / spare. Later, the seg clawed back and reclaimed those 60 bytes. But that was too late as SU already started using them. So we ended up with segy clean and some difficulties. But there was no practical way to comply with the what the seg did. So although SU started as compliant with segy, it stopped being so.
Segy 1975 was practical. I am not sure segy rev 2 is practical. It has some complications that segd has. Segd is too complicated to be practical for a system like SU. But segy rev 1 is not general enough for many data. Segy rev 2 is general enough—I think, and is practical enough—I hope.
Necati, this email except the first two lines is not directly about your questions. But it may lead to somebody solving your problem and some other not by scripting acrobatics but by programming.
On Aug 12, 2019, at 01:56, Necati Gulunay n.gulunay@gmail.com wrote:
Hi Shuki.
Thany you for responding.
I am not familiar with nuances you are talking about(xdr) and I could not see its relevance to the issue I reported.
Also, you seem to imply that Su is using segy rev 1, but I was recently told in this forum that segyread assumes segy data is in rev0 format, not rev1.
Regards
Necati Gülünay
On Sun, Aug 11, 2019, 8:21 PM Shuki Ronen shuki.ronen@gmail.com wrote:
One thing that used to be nice and simple in the original SU was the ability to use dd skip=3600 or count=1 , then cat to concatenation whatever you want to manipulate SU files. XDR messed it up. As far as I know, SU users like have two SU installations. One compiled with XDR and one without. We switch from one to another as needed. It is of course possible to exchange files in segy format but sometimes we need to switch XDR/bin. It’s about time somebody improves it. This can be done by teaching gettr to recognize the XDR and Endian in any SU files without relying on the user to find it, usuallt with trial and error. A few years ago I thought to do it but when I looked at puttr and gettr they were so mangled up by the XDR b****y thing that I gave up. So it’s still needs to be done by somebody else.
Maybe XDR can be improved if and when SU is upgraded from segy revision 1 to segy revision 2. Some short integers header words, especially the number of samples per trace requires acrobatics with continuous recording node data. Segy rev 2 has all that sorted out, as well as flexible headers and I think also an ascii tail that can take the processing history. So improving XDR can perhaps be done together with segy rev 2 upgrade that can be done backward compatible.
On Aug 11, 2019, at 07:00, Fernando M. Roxo da Motta petro@roxo.org wrote:
On Sun, 11 Aug 2019 08:44:31 +0300, "Necati Gulunay" n.gulunay@gmail.com wrote:
How short is the text (aka EBCDIC) header?
Would it be possible to provide a sample of the data (provided the there is no sensible information in text header)? The sample can be as short as the first trace. To obtain this you can use the 'dd' command available in all Linux/Unix installation. the command would be:
$ dd if=<segyfilename> bs=<N> count=1 of=sample.segy
The '<N>' aboce is the number of bytes to copy. It should be:
N= 3200 + 400 + 240 + nsamp*4 nsamp is the number of samples.
The output should contain just the first trace of the Seg-Y file.
HTH
Hello,
I don’t get full 3200 byte “header” (but 400 byte “binary” header size is OK) everytime I do segyread from segy data (that is generated by WesternGeco Omega software).
Anybody knows why and how to cure it.
Note:
segy data size (in bytes) that is input to segyread program is correct and is equal to
Su data(created) + 3200 + 400.
But the “header” created from segyread is short.
i.e.
Su data (created) +header(created) + binary(created)
is not equal to segy data size.
So segyread is somehow dropping some bytes.
Necati
Roxo
-- ---------------- Non luctari, ludare -------------------+ WYSIWYG Fernando M. Roxo da Motta petro@roxo.org | Editor? Except where explicitly stated I speak on my own behalf.| VI !! PU5RXO | I see text, ------------ Quis custodiet ipsos custodes?-------------+ I get text!
Seisunix mailing list Seisunix@mailman.seismic-unix.org https://mailman.seismic-unix.org/listinfo/seisunix
Seisunix mailing list Seisunix@mailman.seismic-unix.org https://mailman.seismic-unix.org/listinfo/seisunix