Vector Wave Analysis in USP

Introduction

Seismic wave motion is intrinsically a vector process, even though the exploration industry has for years successfully ignored this, operating solely on vertical components of the displacement, or scalar amplitudes. However today, many applications require consideration of the vector nature of the wave motion.

In particular, fracture detection in the subsurface has recently become a topic of considerable interest within APC. In coalbed methane plays, and also in other tight formation gas plays, the detection from the surface of "sweet spots" of intense fracturing is viewed as critical to economic success. Perhaps the best method to detect such fractures is to use split-shear wave analysis to interpret the azimuthal anisotropy which is typically induced by the fractures. ( If you are not familiar with the basic concepts and vocabulary of split shear waves, you may wish to read Thomsen (1988) for an introduction to the topic.)

Hence, the time is ripe for construction, within USP, of appropriate routines for handling vector datasets as easily as scalar datasets. A start along these lines is evident in the list of existing "multicomponent" routines (cf eg xuspman), but inspection of these reveals a variety of different approaches to the problem of generalizing from scalar thinking to vector thinking.

This Note announces the availability of four USP programs which are useful in vector wave analysis. All are defaulted for use with horizontal components of vertically travelling shear waves. However, two are more broadly useful in conjunction with re-orienting vector data in other contexts (eg VSP's). Further, they represent an initial implemention of an approach to the general problem stated above which should prove to be generally useful.

• rotvctr implements a vector rotation of seismic data, about a user-selected axis. It is useful, for example, in re-orienting 3-component data, eg 3C VSP data wherein the sonde twists uncontrollably in the borehole. In the split-shear context, it implements the singlesource/multiple receiver (SS/MR) algorithm for deducing the principal time series.
• rottnsr implements a tensor rotation of seismic data about a user-selected axis. (Seismic data assumes the character of a tensor when the vector nature of the source, as well as of the receiver, is considered.) rottnsr is useful, for example, in re-orienting offset 9C VSP data to transform the z-axis to the ray direction. In the split-shear context, it implements the fundamental multiple-source/multiple-receiver (MS/MR) rotation ("Alford rotation").
• mctshift implements "Thomsen-Tsvankin layer-stripping" of surface-recorded shear data, solving the problem of multiple splitting of shear waves caused by vertically variable orientation of azimuthal anisotropy.
• rltt implements "the linear transform technique" of Li and Crampin (1993) for deducing the principal time series of split shear waves.

Multi-component Naming Convention

A common problem with multi-component seismic data is the FORMAT of the data . The routines described here use a data storage format and naming convention that has been found useful in this context; it should be more broadly useful for other multi-component applications as well. (However, note that other conventions have been proposed, eg Done, 1991.)

In brief, the present convention allows vector (or tensor) seismic data to be handled as easily as scalar data. You can refer to it by its vector (or tensor) name-root, just as you do algebraically (letting the various components take care of themselves). In this way, scripts can be written to perform data processing which is automatically uniform for all components (for example, in scaling), rather than relying on the vigilance of the processor for such uniformity.

All multi-component files are stored as SEPARATE COMPONENTS in SIS format, and conform to all conventions established for single-component seismic data (including headers, historical line headers,etc.). Hence, each may be handled in single-component fashion in conventional ways. The tie between the various components is established via their NAMES, which all consist of a common filename root, followed by `.ij', like subscripts on a matrix; for example: test.12. (Embedded periods, etc, are permitted.) The filename root then serves as the handle for the entire dataset.

• The FIRST subscript ( i ) refers to the orientation of the source, since the source action occurs prior to the reception. The man pages address issues which arise with a scalar source (dynamite or air-gun).
• The SECOND subscript ( j ) refers to the orientation of the receiver.

The convention relies upon a full description of the coordinate system (in fact, without a commonly understood coordinate-system description, we are doomed from the start to future confusion). The indices refer to a RIGHT- HANDED orthogonal coordinate system, which may be either:

• line-oriented (if only a single line is under consideration), or
• map-consistent (if multiple lines are considered, then most multi-component situations require that a single coordinate system be used throughout, in order to avoid error).

As long as one is consistent, some flexibility is available, but it is easy to err; the best advice is to just follow 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 particle motion in the positive direction of that axis. With multi-component data, it is much easier to screw up the polarities than with single-component data (roughly 3 2 = 9 times easier!).

The subscripts i and j are integers (1, 2, or 3), following the normal algebraic convention (also adapted in the proposed multi-component data standards of the SEG):

• 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 multi-line survey, or the acquisition direction of a 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 (see below).
• If map-consistent, this is most naturally SOUTH (rather than north, see below), or in the case of a multi-line survey or a 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 convention, along with +x=East, is what forces +y to be South, or 90 degrees clockwise from +x, see above. If you insist on +y being 90 degrees counterclockwise from +x(as viewed from above), the right-handed convention means that +z is UP; this may get you into trouble later...)

In any case, if there is the slightest possibility that someone else may use the dataset, one should write a full description, in the header, describing the reference coordinate system!

In some contexts, the indexing may correspond to some other right-handed coordinate system. For example, in a deviated borehole, the acquisition geometry of a downhole three-component receiver may not have any axis vertical. As another example, with pre-stack reflection data, or in an offset VSP, it is necessary to consider the data in a coordinate system whose z-axis is aligned with the downgoing ray, with the x-axis lying in the saggital plane (cf Thomsen, 1986). In such cases, this coordinate system may be derived from the foregoing by a proper rotation, eg using rotvctr.

rotvctr

This routine performs single-source/multiple-receiver rotation of seismic data . Perhaps the most common use of this algorithm is in the orientation of data from a three-component VSP survey, where the sonde orientation normally differs at each level. The recorded data may be referenced to any righthanded coordinate system using rotvctr. For example, if the rotation angle is selected to minimize the energy (from an offset source on the y-axis in the P-wave time-window), this fixes the plane-of-incidence as the x-z plane. The man page addresses issues which arise in a non-vertical borehole.

rotvctr rotates the coordinate system into a new coordinate sytem, ie it refers the data vector to new axes which are rotated from the original ones by a user-specified angle. If the original right-handed coordinate system has positive z downwards, as recommended above, then a positive rotation angle means a clockwise rotation (viewed from above).

For split-shear-wave analysis, rotvctr has the same functionality as rottnsr (see below), but utilizes only half as much data. Hence, it is less robust, but more economical (in those situations where it is sufficient) because only half as much data need be acquired (eg, only one source orientation). The same restrictions (as with rottnsr, see below) apply, concerning the single raypath, and the single orientation of azimuthal anisotropy.

To get the optimum rotation angle for split shear-wave separation, multiple applications of rotvctr are required, followed by a selection among the various results. The selection criterion is: that rotation angle is best for which the two output traces look similar to each other, except for smooth 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 propagation.) This criterion is currently implemented only by the interpreter's eyeball; quantification and automation will come later.

The command-line arguments are:

rotvctr -N FileNameRoot -rs StartRecord -re EndRecord -ns StartTrace
-ne EndTrace -s SrcIndex -ax RotnAxisIndex -r Degrees -IKP -V -?

The scalar arguments (-rs, etc) have defaults which follow USP conventions; see the man pages. The default source index is 2 (-s2, eg crossline source). The default rotation axis is 3 (-ax3, eg vertical source). As an example, to rotate all records, and all traces, in 2 files test.2j by 60 degrees about the verical axis, enter

rotvctr -N test -r 60

Since you are rotating the crossline-source data about the z axis, rotvctr knows that you are rotating the ij = 21 and 22 components. Given the axis conventions cited earlier as "most natural", with positive z downwards, this rotates the data axis by 60 degrees clockwise (viewed from above). The results of this rotation are written in 2 files named test.r3+60.2j, stored in the directory from which rotvctr was executed. There is an exception for IKP; see the man pages. Piping routines are forthcoming.

(Note: rotvctr succeeds an earlier routine named rotzs1, which is limited to rotation about a vertical axis, and which also applies an angle-dependent normalization. Also, rotzs1 rotates the principal axes into the survey axes (the reverse of the present procedure); equivalently one may say that rotzs1 produces a counter-clockwise angle (viewed from above), whereas rotvctr produces a clockwise rotation.)

(Note: this functionality overlaps substantially with that of USP program wrot, which does have some additional functionality, but does not utilize the multi-component naming convention described above.)

rottnsr

This routine performs multiple-source/multiple-receiver (MS/MR) rotation of seismic data. A common use of this algorithm is in the orientation of data from a nine-component VSP survey. Once the receivers have been oriented to the survey coordinate system using rotvctr, the entire 3x3 tensor may be re-oriented (via rotation about the y-axis), so that the new z-axis is aligned with the ray direction, so that the shear-waves are recorded exclusively on the new x and y axes. They may then be separated into their principal components, as discussed below.

rottnsr rotates the coordinate system into a new coordinate sytem, ie it refers the data tensor to new axes which are rotated from the original ones by a user-specified angle. If the original right-handed coordinate system has positive z downwards, a positive rotation angle means a clockwise rotation (viewed from above).

In the split shear context, rottnsr is used to rotate MS/MR data, in order to produce the two principal time series ("Alford" rotation, cf Alford, 1986, Thomsen, 1986). Strictly speaking, the algorithm should be applied only to traces resulting from a single raypath (usually in the 3-direction). A stacked trace is often an acceptable noise-reduced surrogate for a vertical-ray trace, however we don't really understand under which conditions this is valid.

The algorithm assumes that, for rays in this single direction, the directions of the principal axes do not vary along this travel path (Thomsen, 1986). Hence, rottnsr rotates the data with one angle only (for all times); different rotation angles for different times is unphysical. In the case where the azimuthal direction of anisotropy actually changes with depth (hence with record time), the waves will split again at each horizon where the azimuth changes. Hence the rotation algorithm will fail in this situation, ie there will be no good optimum rotation angle, as described below. (Routine mctshift, described further below, provides a means to cope with this situation.)

To get the optimum rotation angle for split shear-wave separation, multiple applications ofrotnsr are required, followed by a selection among the various results. The selection criterion is: that rotation angle is best for which the two off-diagonal output traces are minimized, ie contain the lowest signal/noise ratio (usually measured as the lowest continuity on the corresponding off-diagonal output sections). The two diagonal output races should then resemble each other closely, except for smooth stretching, and possibly non-smooth amplitude differences. (By contrast, before rotation, all four traces may have similar signal/noise ratios.) This criterion is currently implemented only by the interpreter's eyeball; quantification and automation will come later.

The command-line arguments are:

rottnsr -N FileNameRoot -rs StartRecord -re EndRecord -ns StartTrace -ne EndTrace -R Degrees -AX RotnAxisIndex -V -IKP -?

The scalar arguments have defaults which follow USP conventions; see the man pages. The default rotation axis is 3 (-AX3, eg vertical source). As an example, to rotate all records, and all traces, in 4 files test.ij by 60 degrees about the vertical axis, enter

rottnsr -N test -R 60

Since you are rotating about the z axis, rottnsr knows that you are rotating the ij = 11, 12, 21, and 22 components. Given the axis conventions cited earlier as "most natural", with positive z downwards, this rotates the survey axis by 60 degrees clockwise (viewed from above) into the principal axes of the anisotropy. The results of this rotation are written in 4 files named test.R3+60.ij, stored in the directory from which rottnsr is an exception for IKP; see the man pages.

Piping routines are forthcoming. In particular, a script is available ( cf A-Team, 1994 (App. 4), or M. Mueller, HOU x 2251 ) which automatically performs the rotations for a series of angles, and presents the results in a series of 4x4 plot matrices, one for each angle. Although this is not yet USP-ized, it may prove useful in the interim.

(Note: rottnsr succeeds an earlier routine named rotzs2, which is limited to rotation about a vertical axis. Also, rotzs2 rotates the principal axes into the survey axes (the reverse of the present procedure); equivalently one may say that rotzs2 produces a counter-clockwise angle (viewed from above), whereas rottnsr produces a clockwise rotation.)

mctshift

This routine is needed to complement MS/MR rotation of split-shear reflection data, in the case where the principal directions of the azimuthal anisotropy vary with depth. This appears to be a common circumstance in the sedimentary crust; Winterstein and Meadows (1991) show that where they have used the VSP version of the present algorithm, they do find that the direction often varies, on a coarse-layer basis.

In such a case, it is not sufficient to rotate independently at each time-step, since the shear-waves will re-split at every horizon where the anisotropy orientation changes (and re-split again while upcoming). The result is (at every depth) only two distinct polarizations (of course), but with each component composed of a large number of superposed wavelets, with differing time delays and amplitudes. Such an operation is possible, of course, at least in an approximate (optimal) way, or by assuming that source and receiver rotations are mutually independent (cf program ackr), but since it does not recognize this physics of wave-splitting, the resulting angles and time delays have no physical interpretation. Further, any such sample-by- sample algorithm operates on noise as well as signal, and hence risks confusing one for the other.

Program mctshift addresses these issues by assuming that the anisotropy alters its direction only on a coarse- layer basis. (The acronym denotes multi-component time-shift.) The rotation (eg using routine rottnsr) is followed by an analysis (currently done visually) to determine at which reflection time the optimum angle of reflection no longer adequately fulfills the Alford criterion above (ie near-elimination of signal on the off-diagonal (mismatched) traces). This determines the time corresponding to the bottom of a coarse layer of uniform anisotropic direction. Then, application of routine mctshift performs a layer-stripping ("downward continuation") action, replacing the split-shear displacements at this layer-bottom by a single wave, polarized in the fast direction. The operation is then repeated for the next layer, etc.

Thus, "Thomsen-Tsvankin layer-stripping", like "Winterstein layer-stripping" of VSP data, consists of a series of Alford rotations, followed by static shifts. The difference consists of a simple, but fundamental difference in the static shifts. mctshift static-shifts the slow trace in time by a user-specified amount, and also shifts the two off- diagonal traces by half that amount (since each of these corresponds to travel down as a fast mode, and up as a slow mode, or vice versa).

The same restrictions (as with rottnsr) apply, concerning the single raypath.

The command-line arguments are:

mctshift -N FileNameRoot -rs StartRecord -re EndRecord -ns StartTrace -ne EndTrace -s SlowIndex -dt TwoWayDelay -V -?

The scalar arguments have defaults which follow USP conventions; see the man pages. In addition, the default for the index of the slow trace (the principal trace to be time-shifted is 22). As an example, to shift file test.22 by 18.5 msec, and files test.12 and test.21 by 9.25 msec, enter

mctshift -N test -dt 18.5

The results of this shift are written in 4 files named test.sh18.5.ij, stored in the directory from which mctshift was executed. Piping routines are forthcoming.

(For true layer-stripping, the shifted traces should be written layer-by-layer (or, more precisely, time-window-by- time-window) into new files; this is not yet implemented.)

Example of the foregoing

The following is an example of the usage of these routines, taken from a recent APR Report (A-Team, 1994). The figure below shows synthetic normal-incidence traces for a flat-lying coalbed sequence underlying a uniform, azimuthally anisotropic clastic overburden. The coalbed sequence has many thin coalbeds (all below sesimic resolution), with a uniform orientation of azimuthal anisotropy, different from that of the overburden. The four traces shown in each record are, respectively, for the 22, 21, 12, and 11 components, and reside in files example.22, etc.

Record 1 shows the original data (as calculated), mis-oriented by 30 degrees with respect to the principal direction of the overburden. The non-zero data appearing on the mismatched traces (21 and 12) is a good indicator of the presence of azimuthal anisotropy, in this setting.

Record 2 is a rotation of this original data by an incorrect angle (20º), using :

rottnsr -N example -R 20

That the rotation angle is incorrect (ie 10 degrees off) is indicated by non-zero values on the mismatched traces. Close inspection reveals, however, that the first reflection from the coal bed sequence (just at the pick-line) has almost disappeared on the mismatched traces of Record 2, whereas the following coda from the coalbed sequence is roughly unchanged in amplitude. This indicates that 20º is almost the correct angle for the overburden, and that the coalbed sequence has a different anisotropic orientation.

The correct angle for the overburden is found using:

rottnsr -N example -R 30

as shown in Record 3, wherein the first arrival actually vanishes on the mismatched traces. Record 3 also shows the delay in trace 22 (the first trace), relative to trace 11, indicating a slight anisotropy in the overburden, with an accumulated delay of 10 msec.

Record 4 shows this overburden stripped off, using:

mctshift -N example.R3+30 -dt 10

leaving the two principal traces in sync at the pick, but obviously different in their codas. This is the result to be expected if the overburden were isotropic.

Record 5 shows the result of rotating the stripped data to find the principal directions of the coalbed sequence(which happened to be the original coordinate system):

rottnsr -N example.R3+30.sh10 -R-30

The correct angle is identified by the vanishing of data on the mismatched traces. This time, those traces are null at all times, indicating a uniform orientation of anisotropy throughout this entire interval.The results are written in files example.R3+30.sh10.R3-30.ij.

rltt

The routines rotvctr and rottnsr simply apply geometrical rotations to the data; no physical assumptions are made. (The interpretation that the resulting traces are the principal time series of split shear waves depends upon the assumption that the medium between source and receiver is anisotropic, with a uniform orientation of its principal polarizations for shear. With the addition of mctshift, there is still the assumption that within each interpreted coarse layer, the anisotropy orientation is uniform. All interpretations assume, in addition, that there is no interference from multiples, etc.) Of course, these assumptions may be checked by examining the signal on the mismatched traces. So, these operations are relatively free of strong, modelling-type assumptions.

By contrast, rltt does make a strong assumption, which is that the four measured components comprise two (orthogonal) split shear waves, each linearly polarized (this corresponds to assuming a uniform orientation of anisotropy between source and receiver, and a single source polarization on each record). Thus, it combines an interpretation step with the calculation step. Within a user specified time window, it takes four measured amplitudes, and deduces two output (principal trace) amplitudes, and the angle between the source coordinate system and the fast principal direction. (The fourth degree of freedom can be used to calculate non-orthogonal components (cf Li and Crampin, 1993), but this is not implemented in rltt.)

In order to stabilize the calculation, the solution uses the orientation of the eigenvector of the amplitude covariance matrix (in a user-specified window), rather than the instantaneous amplitudes. (This essentially finds an average orientation, over that time-window.) Finally, the time-delay between the two principal traces is determined, by crosscorrelation; this also determines which one of the output traces is, in fact, the fast one.

In order to allow you to gauge the validity of the basic assumption above, rltt also outputs (as quality control) the off-diagonal result traces, the cross-correlation of the principal traces, and (in a plot file) the correlation coefficient at the optimum lag. (Note that the algorithm does not (as erroneously stated by Li and Crampin, 1993) assume that the anisotropy is "caused by stress-aligned fluid-filled inclusions (EDA-cracks)", it simply assumes uniform orientation of azimuthal anisotropy between source and receiver, yielding the split shear waves mentioned above.)

(rltt is a modified version of a routine named ltt, which is contained in a package named SWAP. The Shear Wave Analysis Package contains research-grade code obtained from the Edinburgh Anisotropy Project (C. MacBeth, director (S. Crampin, former director)), which is supported by Amoco/UK, and monitored by D. Marsden and M. Mueller. The entire package is installed and available in Denver, Houston and Tulsa, and contains many other routines which also might prove useful in split shear-wave analysis. rltt is the only one (so far) which has been made compatible with USP, although others may be so rendered in the future, as the need appears. While AMOEX continues to support EAP, they will continue to provide enhancements and extensions of SWAP. USP provides a convenient way to make these unconventional algorithms available to the Amoco user community; it is hard to see how this functionality could be provided in any other way.)

The command-line arguments are:

rltt -N FileNameRoot -rs StartRecord -re EndRecord -ns StartTrace -ne EndTrace -s StartTime -e EndTime -V -? or -h
-cwo OuterXcorWin -cwi InnerXcorWin -positive -pick -P PickFileName -pdt PickFileSampMultplr

The scalar arguments have defaults which follow USP conventions; see the man pages. The outer cross-correlation window (-cwo; default: 200) specifies the window over which the covariance is calculated (see above). The inner cross-correlation window (-cwi; default 100) is used to calculate the time lag (see above).

[The original algorithm exhibits an instability: the reported anisotropy angle frequently jumps by 90 degrees, then jumps back. This artifact happens because at such places, the apparent time lag (as determined by maximum crosscorrelation) is negative, leading to the conclusion that the fast and slow traces had been swapped. (Note that other explanations exist, eg, there could be noise present.) To cope with this symptom, Li and Crampin simply assume that this was the problem, reverse the sign of the lag, and subtract 90 degrees from the angle. Evidently, this is not a sufficiently robust way to handle the problem, as it leads to these physically implausible results. The option -positive, when specified, finds the maximum correlation among positive lags only, thus ignoring the possibility that the two traces might have been swapped. It does not exhibit the 90 degree shifts, but it does exhibit anomalous time lags. The comparison of the two calculations (with and without -positive) offers a good quality control check. Better ways to determine which of the principal traces is the fast one (and by how much) are forthcoming.]

If you wish to process between picked events, rather than over a fixed window, specify -pick, and a pickfile name (using -P). If the sampling interval is different in the pickfile than in the processed traces, correct this with multiplier -pdt.

The program outputs (to the directory from which it was executed):

FileNameRoot_s1 (fast trace)
FileNameRoot_s2 (slow trace)
FileNameRoot_s3 (one off-diagonal trace)
FileNameRoot_s4 (the other off-diagonal trace)
FileNameRoot_CrossCorr (cross-correlation of _s1 & _s2)
FileNameRoot_Polarity (instantaneous polarity trace)
FileNameRoot_Xgraph (plot file showing the anisotropy angle, time lag, smoothed versions of these, & the correlation coefficient at the picked lag)

Caveat

At present, none of the commercial processing systems offer any multi-component processing capability (although PROMAX is rumored to be building such capability). At present, to apply these commercial systems to multi-component data, you have to force multiple components into scalar equivalents (for example by merging components); even so one may not perform any operations (such as those discussed herein) which combine data from different components in vector fashion. Hence, even the present (emergent) USP capability provides Amoco with a distinct competitive advantage.

However, these routines are in a state of rapid flux, and may not always behave as advertised. We will try to keep the man pages up-to-date, and we advise you, as always, to scan the amoco.exploration.update newsgroup on xvnews. We welcome your comments and complaints, viewing these as necessary steps in the evolution of processing tools suitable for handling vector datasets.

References

• Alford, R. M., Shear data in the presence of azimuthal anisotropy, APR Report F86-E-6, 1986. See also U.S. Pat. 4,803,666; SEG Expdd Absts, 1986.
• A-Team, Application of shear-wave techniques to coalbed methane exploration, APR Report F93-G-1 (40 pp), 1994.
• Li, X.-Y., and S. Crampin, Linear-transform technique for processing shear-wave anisotropy in four-component seismic data, Geoph., 58 (2), 240-256, 1993.
• Done, W. J., Recommendations for the preparation of multicomponent, multisource data using DISCO, APR Report T91-E-5, 1991.
• Thomsen, L., Azimuthal anisotropy: determination of the principal time-series, APR Report T86-E-2, 1986.
• Thomsen, L., Reflection seismology over azimuthally anisotropic media, Geoph., 53 (3), 304-313, 1988.
• Winterstein, D., and M. Meadows, Shear-wave polarizations and subsurface stress directions at Lost Hills field, Geoph., 56 (9), 1331-1348, 1991.

Return to the USP Home Page

Frame Doc to html conversion by Tony Garossino