Hello greetings! I am a beginner. I have a big su file with huge shot points, but I want to see a particular shot point in reduced velocity mode. I made a single file for those particular shot by using key=fldr. Now this file should have total 636 traces. I wrote a command suwind < indut su file key=tracl max=636 ....... However, in image I got values from2.84*10^5 to 2.85*10^5. Even when I want to see the image in reduced velocity mode, I need to set rv= >1000 whereas it should be rv=1 to 2. It seems like there are something wrong with units in the headers. Would anyone please help me with how can I fix these??? I am a new user; I will appreciate your help and time. Here I attached the header info. Thanks FYI 636 traces: tracl 1 636 (1-636) tracr 284929 285564 (284929-285564) fldr 2245 tracf 1 636 (1-636) cdp 2245 offset 112464 120401 (112464-120401) sx 376962 sy 5176643 gx 376962 gy 5176643 ns 2001 dt 4000
Hi,
1) sureduce assumes that the offset is in meters and the reduction velocity in km/s. (or anything else with a ratio of 1000). Are the offsets in meters ? The geometry of this collection looks very strange (>100 km offset), with a recording of only 8s. 2) How can your data exhibit varying offsets with constant source and receiver locations ?
Check the geometry of your traces and try again.
D.
Le 27/10/2022 à 19:25, eloraafrin5@gmail.com a écrit :
Hello greetings! I am a beginner. I have a big su file with huge shot points, but I want to see a particular shot point in reduced velocity mode. I made a single file for those particular shot by using key=fldr. Now this file should have total 636 traces. I wrote a command suwind < indut su file key=tracl max=636 ....... However, in image I got values from2.84*10^5 to 2.85*10^5. Even when I want to see the image in reduced velocity mode, I need to set rv= >1000 whereas it should be rv=1 to 2. It seems like there are something wrong with units in the headers. Would anyone please help me with how can I fix these??? I am a new user; I will appreciate your help and time. Here I attached the header info. Thanks FYI 636 traces: tracl 1 636 (1-636) tracr 284929 285564 (284929-285564) fldr 2245 tracf 1 636 (1-636) cdp 2245 offset 112464 120401 (112464-120401) sx 376962 sy 5176643 gx 376962 gy 5176643 ns 2001 dt 4000 _______________________________________________ Seisunix mailing list --seisunix@mailman.seismic-unix.org To unsubscribe send an email toseisunix-leave@mailman.seismic-unix.org
I haven’t run su in a very long time… but it looks to me like your offset header values are wrong, so sureduce isn’t going to work right. Also, gx and gy which you might use to compute offset, appear to be constant (same value on all traces), so you won’t be able to calculate offset using them.
You might be able to make a “quick and dirty” offset value using tracl: subtract a constant (if a split spread, probably 318; if it is a 3D record from multiple receiver lines, etc., this won’t work) and multiply by the trace spacing in meters. This doesn’t fix your header values, but might get you the plot you need.
Gary Billings
On Oct 27, 2022, at 11:25 AM, eloraafrin5@gmail.com wrote:
Hello greetings! I am a beginner. I have a big su file with huge shot points, but I want to see a particular shot point in reduced velocity mode. I made a single file for those particular shot by using key=fldr. Now this file should have total 636 traces. I wrote a command suwind < indut su file key=tracl max=636 ....... However, in image I got values from2.84*10^5 to 2.85*10^5. Even when I want to see the image in reduced velocity mode, I need to set rv= >1000 whereas it should be rv=1 to 2. It seems like there are something wrong with units in the headers. Would anyone please help me with how can I fix these??? I am a new user; I will appreciate your help and time. Here I attached the header info. Thanks FYI 636 traces: tracl 1 636 (1-636) tracr 284929 285564 (284929-285564) fldr 2245 tracf 1 636 (1-636) cdp 2245 offset 112464 120401 (112464-120401) sx 376962 sy 5176643 gx 376962 gy 5176643 ns 2001 dt 4000 _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Hi eloraafrin5
If you have access to the original field files (SEG-D, SEG-Y, etc), that may shed some light about the units used, where in the header to search for reliable information, etc. SU may have captured the wrong original headers, or may have been used in a wrong way, etc. As others said, the trace header values look inconsistent with each other. Likewise, if there is any paper record or spreadsheet of the field work, that may help. In any case, we had sonobuoy records here with offsets of many km. Not to mention seismological records.
Otherwise, without other source of information, it becomes wild guesswork, as below.
You could try to rewrite the trace headers with these values (save the original file first), then try to plot the reduced velocity seismogram, to see if it makes sense.
1) Assuming the units are in feet, the old fashioned British/Imperial System, still the American way, doesn't help much. The conversion factor to meters is ~0.3048, and this would make the first offset 34279m, down from 112464m but still large.
2) Assuming the units are centimeters (yes, once upon a time, the CGS system was popular) is better, reducing the first offset to 1124.64m.
However, the units could be anything: mm, inches, yards, fathoms, furlongs, while the header values could just be dead wrong.
I hope this helps, Gus Correa
On Thu, Oct 27, 2022 at 1:54 PM Gary Billings obs681@gmail.com wrote:
I haven’t run su in a very long time… but it looks to me like your offset header values are wrong, so sureduce isn’t going to work right. Also, gx and gy which you might use to compute offset, appear to be constant (same value on all traces), so you won’t be able to calculate offset using them.
You might be able to make a “quick and dirty” offset value using tracl: subtract a constant (if a split spread, probably 318; if it is a 3D record from multiple receiver lines, etc., this won’t work) and multiply by the trace spacing in meters. This doesn’t fix your header values, but might get you the plot you need.
Gary Billings
On Oct 27, 2022, at 11:25 AM, 112464 wrote:
Hello greetings! I am a beginner. I have a big su file with huge shot
points, but I want to see a particular shot point in reduced velocity mode. I made a single file for those particular shot by using key=fldr. Now this file should have total 636 traces. I wrote a command suwind < indut su file key=tracl max=636 .......
However, in image I got values from2.84*10^5 to 2.85*10^5. Even when I
want to see the image in reduced velocity mode, I need to set rv= >1000 whereas it should be rv=1 to 2. It seems like there are something wrong with units in the headers. Would anyone please help me with how can I fix these??? I am a new user; I will appreciate your help and time. Here I attached the header info. Thanks
FYI 636 traces: tracl 1 636 (1-636) tracr 284929 285564 (284929-285564) fldr 2245 tracf 1 636 (1-636) cdp 2245 offset 112464 120401 (112464-120401) sx 376962 sy 5176643 gx 376962 gy 5176643 ns 2001 dt 4000 _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
I have been failing to get segdread to handle 8015 and 8036 SEGD files. It handles 8058 without problem. I may end up seeing other formats, all demultiplexed.
My example files can be viewed and headers examined in SegDSeeMp. The header listings agree with what I can make out in a binary editor.
I've run segdread in a debugger to examine where things go wrong. It looks as though it begins misinterpreting headers at some point. The general header states there is one scan type, and 10 channel sets. During the read it may encounter scan type 63 and channel set 46, which are outside the bounds of an array. From there we segfault.
Before I go further, I thought I'd ask whether anyone else has had similar issues.
regards Graeme Murray
Hi Graham,
Last time I had SEGDREAD problems , I managed to read the data straight off using openseaseis so that might be the quickest route.
Prior to that I think I had to hack the code to bypass whatever issue it was having. Pretty sure I have read 8015 format previously without issues though.
Regards
Rob
-----Original Message----- From: Graeme Murray murray@geocom.com.au Sent: Thursday, 8 December, 2022 12:22 PM To: seisunix@mailman.seismic-unix.org Subject: [Seisunix] segdread and 8015
I have been failing to get segdread to handle 8015 and 8036 SEGD files. It handles 8058 without problem. I may end up seeing other formats, all demultiplexed.
My example files can be viewed and headers examined in SegDSeeMp. The header listings agree with what I can make out in a binary editor.
I've run segdread in a debugger to examine where things go wrong. It looks as though it begins misinterpreting headers at some point. The general header states there is one scan type, and 10 channel sets. During the read it may encounter scan type 63 and channel set 46, which are outside the bounds of an array. From there we segfault.
Before I go further, I thought I'd ask whether anyone else has had similar issues.
regards Graeme Murray _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
Rob,
Thanks for the reply.
I have been iterating through the debugger to try spot where goofy numbers are being extracted. The dream is to identify a blindspot in the code that I can fix and make it all work as expected :)
I am trying to design a workflow which uses dd to extract SEGD off tape, tee the result to a disc file and feed stdout into segdread to ultimately produce SEGY for production of near trace gathers for QC image preparation. This is for the government of a developing nation and there are over 15000 tapes.
Part of the job is to demonstrate the resulting SEGD disc files are usable. SegDSeeMp can deal with these files fine. I have the source code for SegDSeeMp, but its SEGD code is couched within their Qt framework. Both SegDSeeMp and segdread are somewhat dense, which is to be expected with a standard like SEGD.
regards Graeme
On 8/12/22 20:38, rob@xsgeo.com wrote:
Hi Graham,
Last time I had SEGDREAD problems , I managed to read the data straight off using openseaseis so that might be the quickest route.
Prior to that I think I had to hack the code to bypass whatever issue it was having. Pretty sure I have read 8015 format previously without issues though.
Regards
Rob
-----Original Message----- From: Graeme Murray murray@geocom.com.au Sent: Thursday, 8 December, 2022 12:22 PM To: seisunix@mailman.seismic-unix.org Subject: [Seisunix] segdread and 8015
I have been failing to get segdread to handle 8015 and 8036 SEGD files. It handles 8058 without problem. I may end up seeing other formats, all demultiplexed.
My example files can be viewed and headers examined in SegDSeeMp. The header listings agree with what I can make out in a binary editor.
I've run segdread in a debugger to examine where things go wrong. It looks as though it begins misinterpreting headers at some point. The general header states there is one scan type, and 10 channel sets. During the read it may encounter scan type 63 and channel set 46, which are outside the bounds of an array. From there we segfault.
Before I go further, I thought I'd ask whether anyone else has had similar issues.
regards Graeme Murray _______________________________________________ Seisunix mailing list -- seisunix@mailman.seismic-unix.org To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
seisunix@mailman.seismic-unix.org
-
Dominique ROUSSET -
eloraafrin5＠gmail.com -
Gary Billings -
Graeme Murray -
Gus Correa -
rob＠xsgeo.com