- Seisunix - mailman.seismic-unix.org

by nickag64759＠gmail.com

Dear sirs, I am a university student in Geology and I am interested in the use of cwp-su package. I would like to use it on my Windows 10 64 bit PC: does cwp-su be used on that kind of platform ? In the case which is/are the requirements ? Thanks in advance for your help. Regards Giulia

1 year, 11 months

8
7
0 0

Incremental Seismic Un*x Release 44R21

by John Stockwell

Dear Seismic Unix user, I have put some fixes in for the Fortran codes and for the SFIO installations so that you should be able to install everything. Mac OS X Big Sur was a painful upgrade. As you might guess, I am preparing for Release 45. If you have codes that can be shared under the Berkeley style license (no GPL), that is in the style of SU, but honors the existing header structure, has a demo that generates its own data, and that you would like to have included in SU, please email me at: john.19071969(a)gmail.com <mailto:john.19071969@gmail.com> so we can discuss how best to include the code. Thank you for using Seismic Un*x. John Stockwell | john.19071969(a)gmail.com https://wiki.Seismic-Unix.org (The New Home of Seismic Un*x) ——— Release notes for 44R21 ---- Summer 2018 - Thanks to Dominque Rousset of the University of Pau, Seismic Unix distributions and other information may be found at https://wiki.seismic-unix.org Installation tip. If you get error messages regarding the XDR materials you may need to install libtirpc from your Linux distribution. John Stockwell retired from the Colorado School of Mines effective 1 Jan 2018. He continues to work with Seismic Unix. Please email: john.19071969(a)gmail.com if you have questions, or if you want to supply bug fixes or new SU code. What is new in the SU package: character*120 fnames(2) from fnames(3) Thanks to Fernando Roxo da Motta Fortran/Raytrace3d/ktime_3d_rayq.f - ERROR of argument mismatch in two locations. fix: added -fallow-argument-mismatch to the FFLAGS in Makefile.config_Big_Sur this might need to be propagated to all of the Makefile.config_* and this likely takes care of the vzestf.f error as well. Sfio/ Replaced these files with versions from the 2002 release of sfio. ./src/lib/sfio/Stdio_b/sprintf.c ./src/lib/sfio/Stdio_b/vsprintf.c ./src/lib/sfio/Stdio_s/stdsprintf.c The make sfio should work now. demos/Ordinary_differential_equations - has been added to go with the new ordinary_differential equation items in par/main John Stockwell | john.19071969(a)gmail.com https://wiki.Seismic-Unix.org (The New Home of Seismic Un*x) 58 Johns-iMac.local> more news44RXX Summer 2018 - Thanks to Dominque Rousset of the University of Pau, Seismic Unix distributions and other information may be found at https://wiki.seismic-unix.org Installation tip. If you get error messages regarding the XDR materials you may need to install libtirpc from your Linux distribution. John Stockwell retired from the Colorado School of Mines effective 1 Jan 2018. He continues to work with Seismic Unix. Please email: john.19071969(a)gmail.com if you have questions, or if you want to supply bug fixes or new SU code. What is new in the SU package: Restructuring: par/main is now: par/main/apertures par/main/cellular_automata par/main/data_conversion par/main/material_parameters par/main/ordinary_differential_equations par/main/parameter_file_utilities par/main/plotting_utilities par/main/ray_theory par/main/refraction par/main/resampling par/main/smoothing par/main/statistics par/main/velocity_model_building par/main/velocity_perturbation par/main/wavelet_transform New: ramac2su - converts RAMAC GPR files to su format with a nominal geometry Thanks to: Hervé Perrou,d 12/2000and Dominique Rousset, 2019 of the Universith of Pau configs/Makefile.config_Linux_Ubuntu Makefile.config_Mac_OSX_Mojave Makefile.config_Linux_Fedora_32 Makefile.config_Linux_ARCH Makefile.config_MacOSX_Catalina Makefile.config_Mac_OSX_Big_SUR par/main/ordinary_differential_equations logisticfit.c - extract growth and carrying capacity for logistic model seirepidemic.c - SEIR epidemic model sirepidemic.c - SIR epidemic model sirdepidemic.c - SIRD epidemic model voltlotka.c - classic Lotka Volterra predator-prey model demos/Ordinary_differential_equations Epidemiology Logistic_Equation Predator_Prey Fixed: su/main/amplitudes/sugain.c - fixed a but in the AGC function seen on GPR data but not apparent on seismic data Thanks to Dominique Rousset of the University of Pau su/lib/getSPSfile.c - replaced // comments with /* comments */ owing to a problem on CENTOS version 7. Fortran/Vzest/vzestf.f - changed (about line 1119) to character*120 fnames(2) from fnames(3) Thanks to Fernando Roxo da Motta Fortran/Raytrace3d/ktime_3d_rayq.f - ERROR of argument mismatch in two locations. fix: added -fallow-argument-mismatch to the FFLAGS in Makefile.config_Big_Sur this might need to be propagated to all of the Makefile.config_* and this likely takes care of the vzestf.f error as well. Sfio/ Replaced these files with versions from the 2002 release of sfio. ./src/lib/sfio/Stdio_b/sprintf.c ./src/lib/sfio/Stdio_b/vsprintf.c ./src/lib/sfio/Stdio_s/stdsprintf.c The make sfio should work now. demos/Ordinary_differential_equations - has been added to go with the new ordinary_differential equation items in par/main John Stockwell | john.19071969(a)gmail.com https://wiki.Seismic-Unix.org (The New Home of Seismic Unix)

2 years, 1 month

12
21
0 0

Doubly defined global variable

by Ricardo Biloti

Hi folks I've been trying to compile SU R22..24 on a Debian 11 with gcc 10.2.1 (20210110), but there is an error. make[4]: Entering directory '/usr/local/stow/su/src/su/main/filters' /usr/bin/gcc -I/usr/local/stow/su//include -g -m64 -Wno-long-long -DCWP_LITTLE_ENDIAN sulfaf.c -L/usr/local/stow/su//lib -lsu -lpar -lcwp -lm -o /usr/local/stow/su//bin/sulfaf */usr/bin/ld: /usr/local/stow/su//lib/libsu.a(fputgthr.o):/usr/local/stow/su/src/su/lib/fputgthr.c:51: multiple definition of `tr'; /usr/local/stow/su//lib/libsu.a(fgetgthr.o):/usr/local/stow/su/src/su/lib/fgetgthr.c:66: first defined here* collect2: error: ld returned 1 exit status make[4]: [Makefile:35: /usr/local/stow/su//bin/sulfaf] Error 1 (ignored) chmod: cannot access '/usr/local/stow/su//bin/sulfaf': No such file or directory The source for this bug is that the global variable tr is defined in src/su/lib/fgetgthr.c as well as in src/su/lib/fputgthr.c. Both objects are combined to build libsu.a. After a little googling, I found out that gcc 10.2 set -fnocommon as default now. So, adding -fcommon in Makefile.config fix the issue, but perhaps a better fix would be to place an extern across the multiple definitions of tr. Kind regards, R.Biloti Applied Math. Department IMECC/UNICAMP

2 years, 1 month

1
0
0 0

Re: [Seisunix] Tape use

by Marc Schaming (ITES)

Hi, depends on how many tape devices you have ! Generally seismic tapes are record oriented, is bloack may have differents length. If you have 2 tape devices, tcopy is useful. If not, you'll have to make a disk-copy, and then restore disk-copy to tape in the original set. You'll have to know the structure of the tape (ie length of each block). Using these informations you may use dd, or another program to copy to/from disk that take length into account. There are 2 seismic formats that could deal with this: SEG-RODE TIF, tape interchange Format. Cheers, Marc -- Marc Schaming Institut Terre et Environnement de Strasbourg (UMR7063-ITES CNRS-UNISTRA) Ecole et Observatoire des Sciences de la Terre 5 rue René Descartes F-67084 Strasbourg cedex Tel: +33 (0)3 68 85 00 93 Marc.Schaming(a)unistra.fr EPOS-IP AH <https://epos-ip.org/tcs/anthropogenic-hazards>

2 years, 1 month

1
0
0 0

Log space decon

by Graham Gillott

Hello there Does anyone have/know of an SU implementation of John Bancrofts log-space deconvolution algorithm. Kind regards Graham

2 years, 2 months

1
0
0 0

Re: [Seisunix] Seisunix Digest, Vol 21, Issue 1

by mark lee

Dear all, I have worked it out. There is no issue. Best regards, Mark Sent from my iPhone > On 22 Jan 2022, at 13:00, seisunix-request(a)mailman.seismic-unix.org wrote: > > Send Seisunix mailing list submissions to > seisunix(a)mailman.seismic-unix.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.seismic-unix.org/listinfo/seisunix > or, via email, send a message with subject or body 'help' to > seisunix-request(a)mailman.seismic-unix.org > > You can reach the person managing the list at > seisunix-owner(a)mailman.seismic-unix.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Seisunix digest..." > > > Today's Topics: > > 1. Dual Pass De-ghosting in SU (mark lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Jan 2022 18:31:58 +0000 (UTC) > From: mark lee <mark.lee336(a)yahoo.com> > To: "seisunix(a)mailman.seismic-unix.org" > <seisunix(a)mailman.seismic-unix.org> > Subject: [Seisunix] Dual Pass De-ghosting in SU > Message-ID: <626164105.457137.1642789918740(a)mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > Is the sudeghost module created solely for receiver de-ghosting or is it possible to apply a second pass of source de-ghosting setting h=source depth? I tried this but the resultant stack looked to add back data on the second pass when I set h=source depth. So I am unsure if the sudeghost module can deal with both receiver and source de-ghosting, or if there is a way or sequence to apply it correctly. > Best regards, > Mark >

2 years, 3 months

1
0
0 0

Dual Pass De-ghosting in SU

by mark lee

Hello, Is the sudeghost module created solely for receiver de-ghosting or is it possible to apply a second pass of source de-ghosting setting h=source depth? I tried this but the resultant stack looked to add back data on the second pass when I set h=source depth. So I am unsure if the sudeghost module can deal with both receiver and source de-ghosting, or if there is a way or sequence to apply it correctly. Best regards, Mark

2 years, 3 months

1
0
0 0

Re: [Seisunix] segydread

by Cemal Erdemir

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

2 years, 7 months

3
2
0 0

Fortran open (access=direc)t vs fortran open ( access=stream) speed

by Necati Gulunay

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

2 years, 11 months

1
0
0 0

Problem in code of vzestf.f

by Fernando M. Roxo da Motta

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!

3 years, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

Seisunix