Seisunix May 2021

seisunix@mailman.seismic-unix.org

1 participants
2 discussions

Incremental Seismic Un*x Release 44R21
by John Stockwell 29 Mar '22

29 Mar '22

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)

12 21

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

2024

2023

2022

2021

2020

2019

Seisunix May 2021