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.