Go to the list of seismic processes.      Go to SIOSEIS introduction.

QUESTION:

Here's some questions about SIOSEIS that I'm hoping you will answer for me. I will form these as a list so as not to send you an email for each question. 1) I notice that in c_gather script, time is in seconds (diskin, set) and that distance is in cm (geom,gpx). Does this inconsistancy matter later on with velocity or are we working in cm/s? jah says we are working in cm/s (as I think I have seen with a velocity of 8000 in a script)

ANSWER:

SIOSEIS uses the SEG-Y trace header as a "database" for many variables. Unfortunately, the SEG-Y format was created in the early '60s when memory was expensive and 32 bit computation was unusual. Range, the distance from the source to the receiver, is a 32 bit integer in SEG-Y. Process GEOM just modifies the SEG-Y trace header by creating the range and the rp number. The rp number calculation is done in floating point before the range truncation, sp only subsequent processes get the truncation to integer. Process NMO uses the range from the SEG-Y header and the velocity input through the user parameters; the user velocity must be the same units as the range in the SEG-Y header. SIOSEIS keeps time in seconds. The SEG-Y specifies the sample interval in microseconds, but most exploration digitizers are in miliseconds. SIOSEIS tried to eliminate this confusion by keeping to seconds. Problems do arise in GPR, which uses nanoseconds, and in OBS and acoustic systems that digitize as a sample rate (128 samples per second or 1024 samples per second are not integer sample intervals). SIOSEIS has a special entry for some of these "well known" rates and makes them floating point. All processes such as NMO use this floating point time in seconds rather than the SEG-Y time unit of microseconds. So, the range definition in geom is the same used by NMO. If geom is in cm, NMO is in cm/s.

QUESTION:

2) rp, smear, and gather: I see in c_gather script: ********** gather maxtrs 6 mintrs 3 end end geom gxp 1 60 12 5 13 -5 24 -60 dfls 20 dbrps 2.5 smear 2.5 end end ******************** where geom is called before gather. from your web page: SMEAR - The subsurface smear factor. The distance from a rp in which to look for a trace. The smear is centered about the rp. a) does this mean +/- SMEAR around rp or +/- SMEAR/2 around rp, I bet the former, because the later would give you no gain for dbrps 2.5 smear 2.5

ANSWER:

"The smear is centered about the rp." means the rp +/- smear/2. Smear exists in the script simply to reinforce what's happening. One of the test I did was to change both dbrps and smear in an effort to increase the stacking fold.

QUESTION:

b) from geom above, is this 3 or 4 fold. Graphically, in the most idea case (looking at shots at each end and the two inbetween and shooting to the RT and LF), I can make it 4 fold, but there is this 'null' space under the shot.... ANSWER: gather maxtrs 6 mintrs 3 end means that each cmp gather will have a maximum of 6 traces and a minimum of 3 traces. I used maxtrs 6 simply to reduce the amount of scratch disk needed during the gather process (the preset would be 24 for the 24 trace shots). I used mintrs so that sioseis would put a zero trace in the gather if the stack fold was less than 3. As I recall, the CATS line started with dfls 10 and changed to dfls 20. The split spread geometry with 24 trace cable yields 12 CDP when shots advance by two geophones, 6 CDP when shots advance by four geophones. gxp 1 60 12 5 13 -5 24 -60 dfls 20 dbrps 2.5 smear 2.5 end describes a geometry with 24 phones that advances by 4 phones - nominally. Indeed, the rp under the shot has one fewer traces and one a couple away has an extra trace. As I recall, John and I felt that traces farther than 30cm did not contain reflections and were eliminated in process weight by weighting the traces to zero using the xwp parameter.

QUESTION:

c) why have a range of number of traces to use in gather? or really, why have a max number of traces to use in gather? if the smear is as above, then there would be a possible of 3 traces per shot, so 3 times the fold would be the total max traces that 'could' be used, yes? if so, then 3 x 3 fold (jah says 3 fold not 4, but cant explain why graphics don't indicate this) would yield 9 possible traces per rp or gather, but you use 6?? what about the mintrs of 3??

ANSWER:

Hopefully the other explanations answered this one.

QUESTION:

I'm trying to understand your migration process. I see in /nautilus2/henkart/cats/fkmigr* that the process fkmigr call for a velocity of 60 and a trace spacing of 2.5: fkmigr vel 60 deltax 2.5 end end I'm confused. in c_stk we used vtp 6000 (cm/s) because geom was in cm, but above in fkmigr this would be inconsistent units (vel m/s and deltax in cm).

ANSWER:

FKMIGR uses the user's DELTAX and VEL, so just be consistent. The SEGY range used in NMO is not used in FKMIGR. DELTAX is the uniform distance between traces, which on this stacked dataset is 2.5 cm.

ANSWER:

John and I never resolved a factor of two in velocities. All velocities in sioseis pertain to the seismograph two-way travel time. John thinks of them as being okay one-way travel times.

QUESTION:

How does one use the elevation (epath) parameter in geom when the data have been shot point gathered since the range is just repeated for each phone gather?

ANSWER:

Process geom parameter elevation just enters the elevations into the trace header and process shift applies the datum shift. So gather doesn't affect the traces headers - it keeps the trace header with the data trace, so all is well.

QUESTION:

I don't see any muting in the plot.

ANSWER:

Is mute in the procs list? Sioseis only does the process if it's in the procs list, even if the parameters are given.

QUESTION:

I used the same script to plot stacked data and migrated data for the three lines: 1a, 1b, and 3. All are different lengths (number of rps, physical dist...) using the same vscale and trpin I get three different time/depth scales, but the horizontal (dist) is about the same for each i.e., it fills the page? what's going on here? this must be a suntops thing..... how can I keep the scaling the same (i.e., I want to match up the 1a and 1b figures and have figure 3 proportional to the others). I guess I just tweek the suntops parameters? suntops -w 8 -h 10.5 < sunfil > psfil

ANSWER:

Yup, suntops makes every Sun rasterfile be 8x10.5 Some other image format conversions programs might do what you want.
Go to the list of seismic processes.      Go to SIOSEIS introduction.