NAME
rotvctr - module to rotate a vector of multicomponent data
(1s X 2r) about the third axis. Used to re-orient VSP data,
and also to find the "principal time series" for split shear
waves in anisotropic media.
SYNOPSIS
rotvctr [ -Nroot_ntap ] [ -Oroot_otap ] [ -rsStart_record ]
[ -reEnd_record ] [ -nsStart_time ] [ -neEnd_time ] [
-sSrc_index ] [ -axRotnAxis ] [ -rDegrees ] [ -Rfile ] [
-hwindex ] [ -V ] [ -? ]
DESCRIPTION
rotvctr : This routine performs single-source/multiple-
receiver (SS/MR)rotation of a vector of seismic data. It
expects two input data files and will produce two rotated
output data files [see DISCUSSION below for specifics].
rotvctr gets both its data and its parameters from command
line arguments. These arguments specify the input and out-
put file root names, the start and end records and traces
for processing, the source component orientation, the rota-
tion axis orientation, either a static rotation angle or a
file of rotation angles as a function of some index down the
line, the index mnemonic to associate with said file, and a
verbose printout flag. You may use sticky or non-sticky
arguments as you wish.
Command line arguments
-N name_root
Enter the input data set filename-root immediately
after typing -N. This input filename-root should
include the complete path name if the files reside in a
different directory. For example, -N/b/mc/test tells
the program to look for files test.21 and test.22 (or
files test.11 and test.12, depending on the source
index specified with -S), in directory '/b/mc'.
-O root_otap [optional]
Enter the output data set root filename immediately
after typing -O. This output filename-root should
include the complete path name if you want the files to
reside in a different directory. For example,
-O/b/mc/testout tells the program to create files
starting in testout in directory '/b/mc'.
-rs Start_record
Enter start record number. Default value is the first
record.
-re End_record
Enter end record number. Default value is last record.
-ns Start_trace
Enter start trace number. Default value is the first
trace.
-ne End_trace
Enter end trace number. Default value is last trace.
-s src_index
Enter the index of the source polarization. The
default is 2 (eg crossline).
-ax axis_index
Enter the index of the rotation axis. The default is 3
(eg vertical).
-r degrees
Enter the rotation angle (in + or - degrees clockwise,
viewed from above, ie along the + direction of the
rotation axis). The vector data will be rotated to
refer to new coordinates, rotated from the old ones, by
this amount. rotvctr will unwrap angles outside +/-
90 degrees. The default is 0.
-R file
Enter the fully qualified filename of a flat file con-
taining (index, angle) pairs used to vary the rotation
angle down the line. The flat file format is one pair
per line. The program reads them in free format so you
can either separate the index from the angle with a
space or a comma as you wish and use integers or float-
ing point numbers also as you wish. rotvctr will
unwrap angles outside +/- 90 degrees. [see DISCUSSION
below for convention on measurement of angle]. The
output dataset will have the axis and component
appended to the output root as well as the string
_var_ to signify a variable rotation angle. If no
entry is present the static rotation angle input at -r
above will be used.
-hw index
Enter the trace header mnemonic with which to associate
the index in the attached (index, angle) file. The
default is RecNum .
-V Enter the command line argument '-V' to get additional
printout.
-V Enter the command line argument '-IKP' for IKP process-
ing.
-? or -h
Enter the command line argument '-?' or -h to get
online help. The program terminates after the help
screen is printed.
DISCUSSION
: This routine performs single-source/multiple-receiver
(SS/MR)rotation of a vector of seismic data. It is used in
two contexts:
1) As a simple re-orientation of vector seismic data, as
when a 3C VSP dataset must be rotated from the uncontrolled
orientation of the sonde to an orientation which is known
with respect to the survey coordinates.
2) To find the "principal directions", and "principal time
series" for shear waves split by propagation through an
anisotropic medium (sometimes called "Thomsen" rotation
(cf T86-E-24, Azimuthal Anisotropy: Determination of the
Principal Time-Series). In this way, one can separate the
two pure modes of shear-wave propagation, which travel at
different speeds (unless by chance the medium happens to be
isotropic), and interfere with one another (and hence with
interpretation) on any single recorded component (unless by
chance both source and receiver happen to be favorably
oriented).
Strictly speaking, the algorithm should be applied only to
traces resulting from a single raypath; a stacked trace may
be an acceptable noise-reduced surrogate for a vertical-ray
trace under certain (poorly-understood) conditions. The
algorithm assumes that, for rays in this single direction,
the directions of the principal axes do not vary with dis-
tance.
In order to eliminate the need for you to input manually all
filenames (two input and two output), a MULTICOMPONENT NAM-
ING CONVENTION is used (see below). Hence, the input files
are identified on the command line (after "-N") by the root
of their filenames only, as with a vector. (BUT see IKP
exception, below!)
Since the naming convention includes an index for source-
orientation, rotvctr requires you to specify, on the command
line (after "-s"), the source orientation: 1, 2, or 3 (for
x, y, or z, respectively). The default is 2 (y, or cross-
line). (If the data come from a scalar source (eg dynamite,
or air-gun), just use any index for naming the files, but
note this in the header.)
rotvctr rotates the data about one of the (right-handed)
coordinate vectors, specified on the command line (after "-
ax") by 1, 2, or 3; the default is 3.
rotvctr rotates the data with one angle only (for all
times); different rotation angles for different times is
unphysical, in a split-shear wave context. (If the princi-
pal axes have different directions in different layers, then
there will be multiple splitting (at each such layer), and
the output of the rotation will not conform to the descrip-
tion below. See USP routine mctshift to address this prob-
lem.) The rotation angle is specified on the command line
(after "-r").
The rotation angle for re-orienting VSP data is sometimes
given from a gyroscope mounted on the tool, as it twists in
the hole. Especially if the hole is non-vertical, the
application of this orientation data (to refer the seismic
data to a constant coordinate system, eg to the "survey
coordinate system") requires careful thought. The orienta-
tion data may be given in terms of "Euler angles", which
specify an ordered sequence of rotations about the various
coordinate axes. rotvctr should enable you to accomplish
this.
If there is no gyroscope, you can still orient the sonde,
using an offset P-wave source, rotating the 3C data until no
energy appears in the P-wave time-window on the y-component.
This establishes the x-z plane as the plane of incidence.
If the hole is not vertical, ray-tracing (or a straight-ray
assumption) can establish the angle-of-incidence in this
plane, thus determining the vertical direction.
For split shear-wave data, finding the optimum rotation
angle requires multiple applications of rotvctr, followed by
a selection among the various results. The selection cri-
terion is: that rotation angle is best for which the two
output traces look similar to each other, except for smooth,
time-variable stretching, and possibly non-smooth amplitude
differences. (By contrast, before rotation, the traces may
look substantially different from each other, because of
interference between the two pure modes of shear propaga-
tion.) This criterion is currently implemented only by eye-
ball; quantification and automation will come later.
The two output traces, rotated with the optimum split-shear
angle, are called the "principal time-series" (cf T86-E-24),
because they contain the two pure modes of shear-wave propa-
gation (the eigen-modes, or principal modes) when the
assumptions of the algorithm (see above) are met.
The results of rotating 2 files test.ij about the z-axis by
angle 75 degrees are written in 2 files named test.r3+75.ij,
stored in the directory from which rotvctr was executed.
(BUT see IKP exception, below!)
MULTICOMPONENT NAMING CONVENTION
All multicomponent files are stored as SEPARATE COMPONENTS
in SIS format, and conform to all conventions established
for single- component seismic data (including headers, his-
torical line headers, etc.). The tie between the various
components is established in their names, which end in
'.ij', like subscripts on a matrix. The subscripts i and j
are taken as integers (1, 2, or 3) following the normal
algebraic convention (also adapted in the proposed multi-
component data standards of the SEG) as follows:
* The FIRST subscript (i) refers to the orientation of the
source, since the source action occurs prior to the recep-
tion.
* The SECOND subscript (j) refers to the orientation of the
receiver.
* The indices refer to a RIGHT-HANDED coordinate system,
which may be either:
# line-oriented (if only a single line is under considera-
tion), or
# map-consistent (if multiple lines are considered, then
most multicomponent situations require that a single coordi-
nate system be used throughout, in order to avoid error).
As long as one is consistent, some flexibility is avail-
able, but it is easy to err; the best advice is to just fol-
low the "most natural" choices defined below. Use your
creativity somewhere else!
* The POLARITY of the signals must conform to the coordinate
system, so that a positive trace value on any component
implies motion in the positive direction of that axis. With
multicomponent data, it is much easier to screw up the
polarities than with single-component data (roughly 3**2 = 9
times easier!); take care (in both acquisition and process-
ing)!
In some contexts (eg in an offset VSP), the indexing may
correspond to another right-handed coordinate system (eg
with the z-axis aligned with the downgoing ray, and the x-
axis lying in the saggital plane). In such a case, this
coordinate system should be derived from the foregoing by a
proper rotation, using rotvctr, or rottnsr (if multiple
sources are used).
* The numerical identifiers are:
1 = x-axis (horizontal) If line-oriented, this is most
naturally the INLINE direction (since we are accustomed to
drawing x-z cross-sections); the polarity must be the same
on both sides of the source. If map-consistent, this is
most naturally EAST, or aligned with the long-axis of a mul-
tiline or 3D survey.
2 = y-axis (horizontal) If line-oriented, this is most
naturally the CROSSLINE direction, and (right-handed) care
must be used in the polarity. If map-consistent, this is
most naturally SOUTH, rather than north, or (for a multiline
or 3D survey) 90 degrees clockwise from +x viewed from
above, (as with a matrix), rather than counter-clockwise (as
with a graph); see below.
3 = z-axis (vertical) Whether line-oriented or map-
consistent, the SEG convention is to take positive DOWN,
rather than up, as a physicist might prefer. (This conven-
tion, along with +x = East, is what forces +y to be South,
or 90 degrees clockwise, as discussed above. If you insist
on North (or 90 degrees counter-clockwise), the right-handed
convention means that +z is UP; this may get you into trou-
ble later... )
ALGORITHM
rotvctr implements the following equation at every time t:
y.ik(t) = sum-over-j: R[iaxis].kj(degrees) * x.ij(t)
where y(t) is the output vector (occupying two columns of
row i of the y-tensor)), x(t) is the input vector (occupying
two columns of row i of the x-tensor)), and
R[iaxis](degrees) is the rotation matrix for rotation about
iaxis.
rotvctr gets both its data and its parameters from command
line arguments. These arguments specify the input, the start
and end records, the start and end traces, the source polar-
ization, the rotation axis, the rotation angle, and the IKP
and verbose printout flags.
IKP processing
If rotvctr is run inside IKP, the input and output com-
ponents are connected via the process box, rather than by
the command line argument -N. The connections are specified
in the following manner: spigots 0,3 are for input com-
ponents IN THIS ORDER (using here the above MULTICOMPONENT
NAMING CONVENTION):
For rotation about the x-axis: i2, i3.
For rotation about the y-axis: i1, i3.
For rotation about the z-axis: i1, i2.
You must specify the FULL identifier for each spigot; ie NOT
just the name-root, as is done outside IKP (consequently,
the names need not conform to the CONVENTION). Similarly,
spigots 1,4 are for the output components (in the same
order as the input). Again, you must specify fully the
desired destination of these outputs.
BUGS
None known.
SEE ALSO
rottnsr(1) mctshift(1)
AUTHOR
Leon Thomsen (APR x 3920; zlat02)
USP updates by P.G.A. Garossino
(APR x3932; pgarossino@trc.amoco.com )
COPYRIGHT
copyright 2001, Amoco Production Company
All Rights Reserved
an affiliate of BP America Inc.
Man(1) output converted with
man2html