- Seisunix - mailman.seismic-unix.org

Re: [Seisunix] segydread
by Cemal Erdemir 09 Sep '21

09 Sep '21

Hi John, and the others I have a segd files, and I need them read and converted to segy/su urgently, is there such a tool within my reach? Thanks much, Cemal > sufind segd gives me the below information, but no segdread does not exist --------------------- " cemal01@cemal-LatE6530:PPT$ sufind segd + SEGBREAD - read an SEG-B tape segbread > stdout tape= + SEGDREAD - read an SEG-D tape segdread > stdout tape= ingtpatternsssns SUNAME listings containing the pattern: segd >$ segdread segdread: command not found " --------------------- Cemal Erdemir Email: cerdemir(a)hotmail.com Cell: +1 832 668 6289 Office: +1 281 858 7653 ________________________________ From: Seisunix <seisunix-bounces(a)mailman.seismic-unix.org> on behalf of John Stockwell <john.19071969(a)gmail.com> Sent: Wednesday, July 24, 2019 12:29 PM To: petro(a)roxo.org <petro(a)roxo.org> Cc: seisunix(a)mailman.seismic-unix.org <seisunix(a)mailman.seismic-unix.org> Subject: Re: [Seisunix] Janitor project? (also a test of the new list server) People interested in editing the codes are encouraged to clone the github version at https://github.com/JohnWStockwellJr/SeisUnix With git and to push your changes up to the github site. Sent from my iPhone On Jul 24, 2019, at 9:26 AM, Fernando M. Roxo da Motta <petro(a)roxo.org<mailto:petro@roxo.org>> wrote: Hi all, I was just installing the 44R16 release and noticed a lot of warnings during compilation. As an example: /usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] Just changing the "_BSD_SOURCE" for "_DEFAULT_SOURCE" in 'Makefile.config' reduced a lot the number of warnings. Other warnings still are issued though. Some of us are sort of development savvy and could (perhaps) use some time to try to fix those warnings. They are possibly harmless most of the time, but their meaning is that the software can have some weakness. Wouldn't be interesting to incentive whoever are interested to try to fix those? By the way, GCC is becoming more and more picky about many things, that is, it is evolving. Some things that were treated as a warning or even accepted are being flagged as error these days. I got some of these in FreeUSP compiling recently and I am having an error in compilation of sfio/segdread: cc -c -I. -I.. -O -Dvt_threaded=0 stdfgetc.c In file included from /usr/include/wchar.h:43:0, from ../sfhdr.h:304, from stdio_s.h:11, from stdfgetc.c:1: /usr/include/x86_64-linux-gnu/bits/types/__FILE.h:5:25: error: conflicting types for ‘__FILE’ typedef struct _IO_FILE __FILE; ^~~~~~ In file included from stdfgetc.c:1:0: stdio_s.h:8:25: note: previous declaration of ‘__FILE’ was here typedef struct _sfio_s *__FILE; ^~~~~~ Makefile:25: recipe for target 'stdfgetc.o' failed make[5]: *** [stdfgetc.o] Error 1 I will try to dig it. Best regards. Roxo -- ---------------- Non luctari, ludare -------------------+ WYSIWYG Fernando M. Roxo da Motta <petro(a)roxo.org<mailto: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(a)mailman.seismic-unix.org<mailto:Seisunix@mailman.seismic-unix.org> https://mailman.seismic-unix.org/listinfo/seisunix

3 2

Fortran open (access=direc)t vs fortran open ( access=stream) speed
by Necati Gulunay 28 May '21

28 May '21

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(a)gmail.com> Cc: petro(a)roxo.org; seisunix(a)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(a)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(a)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(a)roxo.org> wrote: >>> >>> On Sun, 11 Aug 2019 08:44:31 +0300, "Necati Gulunay" >>> <n.gulunay(a)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(a)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(a)mailman.seismic-unix.org >>> https://mailman.seismic-unix.org/listinfo/seisunix >> _______________________________________________ >> Seisunix mailing list >> Seisunix(a)mailman.seismic-unix.org >> https://mailman.seismic-unix.org/listinfo/seisunix

1 0

Problem in code of vzestf.f
by Fernando M. Roxo da Motta 17 Feb '21

17 Feb '21

A problem showed up when trying to recompile SU during "make fremake" in cwp-44R19. In file 'vzestf.f' there is an inconsistency between the "subroutine vzest" and "subroutine readgrids_vzest", that is called by "vzvest". The "subroutine vzest" describes this dummy argument as: (about line 61) ..... + isort, !isort(2) + fnames, !integer*120 fnames(2) misfit file names + topcmigfile, !top c0 ..... and defines it as: (about line 143) character*120 fnames(2) The "subroutine readgrids_vzest" defines fnames as: (about line 1119) character*120 fnames(3) This definition contradicts the comment at the dummy argument list of "subroutine vzest" and the definition of the parameter in it: Most recent Gfortran can be very picky about this kind of inconsistency and abort compilation with an error message. Changing the definition of of the variable in "subroutine readgrids_vzest" to: (about line 1119) character*120 fnames(2) Solves this problem. HTH Roxo P.S.- The 'segdread' has a problem as well with conflicting definition of "__FILE" as defined in a GCC header file. Didn't look at it. -- ---------------- Non luctari, ludare -------------------+ WYSIWYG Fernando M. Roxo da Motta <petro(a)roxo.org> | Editor? Except where explicitly stated I speak on my own behalf.| VI !! PU5RXO | PX5Q6048 | I see text, ------------ Quis custodiet ipsos custodes?-------------+ I get text!

2 1

asking for SEG-Y rev1 and rev2 datasets
by David Forel 04 Feb '21

04 Feb '21

Hi Everyone - I am writing to ask a favor. Do you have any small (fit into an e-mail or you might have a DropBox link) SEG-Y rev1 and rev2 datasets? I am working on a YouTube video about importing from SEG-Y to SU ... and ... exporting from SU to SEG-Y. I am asking for these datasets so I can test "segyread" as I prepare the video and accompanying PDF documentation. (My YouTube channel is "Seismic Rocks" and my web site is www.SeismicRocks.com) I am pretty sure SU cannot handle an input SEG-Y file that has multiple trace headers (rev2). I don't see any parameters in "segyread" for handling multiple trace headers; although I admit, my C code knowledge is rusty. However, I think SU might be able to import a rev1 file, a SEG-Y file that has one or more 3200-byte text blocks after the 400-byte binary header and before the first 240-byte trace header (see the attached figure). The reason I think this import might work is because "segyread" has parameter xfile (file to store extended text block), a parameter that appears similar to parameters hfile and bfile. I would be grateful if you can send me small SEG-Y rev1 and rev2 files to test for my video. Thank you!David. . . . . . . . . . . . . . Note: Information relevant to rev1 is in the 400-byte binary header: The SEG-Y document counts bytes in the 400-byte binary header as a continuation of the 3200-byte text header. That means the first four bytes of the binary header are numbered 3201-3204 in the document. Below, I put that numbering first, then numbering that starts at 1 (one) in square brackets ([ ]). bytes 3501-3502 [301-302]: SEG-Y format revision number. bytes 3505-3506 [305-306]: Number of 3200-byte extended textual file header records following the binary header. . . . . . . . . . . . . .

1 0

Re: [Seisunix] wiki.seismic-unix.org
by Dominique ROUSSET 05 Jan '21

05 Jan '21

Hi, first of all, best wishes to everybody. We are living hard times, both with the pandemic and in the seismic business (which impacts academics, too). Actually, the SU wiki has been out of order a few days, following a dokuwiki upgrade (incompatible plugins). It's fixed and the wiki is now online again. I remind you that a live community of SU users needs a live wiki (or equivalent). A live wiki needs authors. So, feel free to ask an account to feed the wiki with case studies, tutorials and other interesting material ! D. PS. Please don't use the cwp mailing list anymore it's not maintained and new users subscribe to seisunix(a)mailman.seismic-unix.org). It may be useful to remove this address from your address books to avoid automatic completion. Le 04/01/2021 à 14:48, Halitim Bachir a écrit : > Hi Dominique, > I could not access the wiki.seismic-unix.org > <http://wiki.seismic-unix.org> , any idea ? > Thanks > > > _______________________________________________ > seisunix mailing list > seisunix(a)mailman.mines.edu > https://mailman.mines.edu/mailman/listinfo/seisunix > Unsubscribe: seisunix-unsubscribe(a)mailman.mines.edu -- |Dominique Rousset LFCR UMR5150 / E2S UPPA / Dpt des géosciences| |Univ. Pau et des Pays de l'Adour BP 1155 F-64013 Pau Cedex - France| |mailto:dominique.rousset@univ-pau.fr jami:drousset http://lfc.univ-pau.fr| |Off: +33 559 407 423|Cell: +33 660 861 391|xmpp: dominique(a)rousset.nom.fr|

1 0

SU in Reveal - Academic licenses
by A Lockwood 09 Nov '20

09 Nov '20

Good afternoon SU users Just a reminder that if you are an academic institution youcan get a free academic license to Reveal for teaching and pure research. What has this to do with Seismic Unix? You can drop SU into Reveal and use all our tools with theSU tools, all in the same flow – the best of both. Our academic licenses are free – get in touch if you areinterested and I would be happy to show you. We have 30+ academic institutions using it around the worldbut would like to offer it to more – and I know this group has many academicsin. Thanks Aaron Lockwood alockwood(a)shearwatergeo.com Reveal Seismic Software // Shearwater GeoServices | | | | Reveal Seismic Software // Shearwater GeoServices Shearwater Reveal provides time and depth processing and imaging for both land and marine environments from with... | | |

1 0

info derivative
by vld3 05 Nov '20

05 Nov '20

Hello everyone I would like to apply a derivative to a signal. I made a test with a simple cosine (created with suvibro) applying suop op=diff ... but I didn't get a sine. Why? thanks in advance -- luca

3 4

Re: [Seisunix] suwind
by Dominique ROUSSET 12 Oct '20

12 Oct '20

Hi, I would build a command line in a text file and read it with the par= option (common to all SU tools) I assume that the shotnumbers are ep and strictly positive. 1) transform the column file into a line (shot numbers separated by a comma) using paste -sd , <columnshotfile >lineshotfile add the accept= option at the beginning of the line (with a text editor or script) 2) use suwind key=ep max=0 par=lineshotfile <allshots.su >selectedshots.su D. Le 11/10/2020 à 08:51, Fateh Bouchaala a écrit : > > Dear all, > > > > With suwind command, I want to accept only some shots listed in a one > column file (I have many files). How can I make suwind read directly > from the file. > > I tried “suwind <sufile.su key=tracf max=0 accept=$file” however, it > only reads the first shot’s id. > > > > I appreciate if you can help me. > > > > Dr. Fateh Bouchaala > > Assistant Professor > > Earth Science > > P O Box 127788, , UAE > > T +971 2 675 168 > > F +971 2 447 2442 > > fateh.bouchaala(a)ku.ac.ae > > ku.ac.ae > > > > -- |Dominique Rousset LFCR UMR5150 / E2S UPPA / Dpt des géosciences| |Univ. Pau et des Pays de l'Adour BP 1155 F-64013 Pau Cedex - France| |mailto:dominique.rousset@univ-pau.fr jami:drousset http://lfc.univ-pau.fr| |Off: +33 559 407 423|Cell: +33 660 861 391|xmpp: dominique(a)rousset.nom.fr|

1 0

picking crosscorrelations
by Gabriel Perez 04 Oct '20

04 Oct '20

Dear all: I have a file with crosscorrelation traces and I want to pick the times at the crosscorrelation peaks, one per trace. Is there a program in SU that will allow me to do that? I know/guess a few programs do that internally for other things but I need one that gives me the times as output. Thanks for any help Gabriel ******************************************* Gabriel Perez Senior Geophysicist +1-281-840-3766 gabrielperezpinilla(a)yahoo.com Linkedin profile: www.linkedin.com/in/gabrielperezgeo

2 1

VSP
by Erdi Apatay 30 Sep '20

30 Sep '20

Hello all About my Zero offset synthetic VSP data, I thought something but I am not sure about the effect of this issue. If I get rid of the first three traces from the data before picking arrivals (deleting or killing), and continuing next process steps, that give rise to any effect for results? If not so, How should I write for getting rid of these three traces? I added my screenshot (plus signs denotes picking) Thank you Best Erdi

3 2

2024

2023

2022

2021

2020

2019

Seisunix