PSTM inputs and outputs

Oil and natural gas exploration -- geology and geophysics
Post Reply
jefry123
Silver Member
Silver Member
Posts: 38
Joined: Wed Oct 05, 2016 4:25 am

PSTM inputs and outputs

Post by jefry123 »

Hi,

What are the inputs to do a Kirchhoff PSTM? What do we need?
And, what is the outcome of a PSTM algorithm? Image gathers?

GuyM
VIP Member
VIP Member
Posts: 625
Joined: Sat Mar 24, 2012 11:35 pm
Top poster of the Month

Re: PSTM inputs and outputs

Post by GuyM »

Input should be pre-stack, unmigrated seismic data with noise removed.

- if its land data, you should have residual statics applied
- if its land data, check out how your algorithm manages a floating datum (if you have one) as it varies
- you may need to "scale" the edges of the migration to avoid artifacts, or this might be built in
- you may need to remove the spherical divergence correction prior to migration, or this might be built in
- data order may or may not be important for processing efficiency, depending on s/ware

In general I would recommend applying regularization and bin centring (so 5D interpolation for a 3D dataset) however again, you need to know your specific algorithms; does it need to use the source-receiver X,Y values to calculate a *real* operator (or just use CDP location and offset) - and how are these managed by the regularisation process?

Output is usually "image ray gathers" - that is to say there is still an value offset, but each trace has been corrected as if

- source and receiver were co-located
-the raypath from source/receiver to the reflection events makes a 90 degree angle with the surface

By contrast NMO correction produces "normal ray gathers" - there is an offset value, and each trace is corrected as if:

- source and receiver were co-located
- the raypath from source/receiver to the reflected event makes a 90 degree angle with the reflected event

The ray path is still refracted (curved within a layer if velocity is increasing, and bent at interfaces) although that may be partially addressed with a curved ray algorithm (again, know your algorithm!); similarly it may or may not correct for anisotropic effects (algorithm again!)

The output is usually "flattened" CDP gathers, but it might also come out in offset-plane order (or indeed a more jumbled order if run in parallel) and need some kind of sorting - depending, as you might expect, on the algorithm,...

GuyM
VIP Member
VIP Member
Posts: 625
Joined: Sat Mar 24, 2012 11:35 pm
Top poster of the Month

Re: PSTM inputs and outputs

Post by GuyM »

Oh - and you might also need:

Velocities.
These are usually NMO velocities with a dip correction applied (ie real RMS velocities) but typically we just approximate that with stacking velocities and then repick. If there's a big difference that might mean remigrating, not just a residual correction.

You can of course make a more sophisticated model using time interpretations, wells, vertical velocity gradients and so on; that's probably a good idea if you have super-complex structure with rapid lateral velocity changes.

For an anisotropic PreSTm you'll need an anisotropic model - 4th order velocity picks or soemthing like that.

Or you could just smooth your stacking velocities.

A mute
Deopending on your routine and how good the operator limits and anti-alias filters are then you might want to apply a mute to the image gathers after migration; this is sometimes built in.

Coordinates
The input gathers need to be positioned spatially some how; that might be done using the CDP and offset (as an approximation) or the sourceX,Y data, but the system needs to be able to relate that to the velocity (CDP) location and CDP grid. That might be automatic, but you might have to supply data.

jefry123
Silver Member
Silver Member
Posts: 38
Joined: Wed Oct 05, 2016 4:25 am

Re: PSTM inputs and outputs

Post by jefry123 »

Thank you dear Guy,

These image ray gathers you mentioned are the same as common image gathers?

If the output be the flattened CDP gathers, so could we do some residual velocity analysis to update and get a better velocity model?

And, if the input being in Source Index Number (SIN) order, the output is still flattened CDP gathers?

How can we obtain a final stack of the subsurface from these image ray gathers?

In some review kind of paper, results of imaging were really better for Angle domain CIGs rather than common offset CIGs, I think being able to choose the type of CIG again depends on the s/were, however, is it always true that the results of using angle domain CIGs are better than common offset CIGs?

GuyM
VIP Member
VIP Member
Posts: 625
Joined: Sat Mar 24, 2012 11:35 pm
Top poster of the Month

Re: PSTM inputs and outputs

Post by GuyM »

These image ray gathers you mentioned are the same as common image gathers?

I'd say "yes" - I think in some cases the "-ray" part has been dropped in the technical write-ups
If the output be the flattened CDP gathers, so could we do some residual velocity analysis to update and get a better velocity model?
This is where people do "residual moveout analysis" or "RMO" to make a new velocity model.

That might be applied *directly* to the image gathers (by applying the residual moveout correction using the NMO equation) or you might use the RMO picks to *update* the model and run a new migration. That's all part of the "quality, time, cost" triangle that is constraining your project.
And, if the input being in Source Index Number (SIN) order, the output is still flattened CDP gathers
That depends on the internal working of the specific algorithm you have, as well as the details of the upstream software.
My 3DPreSTM reads inputs in any order, and outputs offset planes - but my software can also efficiently sort-on-read, so it doesn't make any difference.
So - I can run the preSTM from sail-lines in shot order, and then read the output directly into the velocity analysis tool for RMO analysis and make QC stacks.
Your situation might be different - good software tends to pay attention to this kind of detail as it makes workflows easier(!)
How can we obtain a final stack of the subsurface from these image ray gathers?
You stack them, usually with a mute, as you would with NMO corrected gathers.

Beware of the word "final" though; we have an *approximation* to the sub-surface geology. The "observable" is the normal ray scattered data.

Once you have applied a (mathematical) model to collapsed the wavefield based on a (velocity) model of the sub-surface you have an artifact that is certainly easier to interpret, but it's an approximation that is using an approximation.

Every time I use the word "final" I have ended up re-running for some reason!!!
However, is it always true that the results of using angle domain CIGs are better than common offset CIGs?
All algorithms have their pros and cons. They are all approximations. As a rule of thumb we aim to use the *fastest* and *cheapest* approach we can, and then if that doesn't produce the "quality" we want, we spend more time, effort and money. All a single paper can do is to show specific examples of where this technique worked better - they won't show you examples of where the improvements were marginal, and they won't have run it on *all possible* data.

I take the (slightly cynical) view that most papers are selling you something - it might be software, services or just the brilliance of the authors and their organisations. The papers that review techniques and discuss their pros and cons openly tend to be better - be wary of any paper that doesn't identify the limitations and drawbacks of the approach!

Post Reply
  • Similar Topics
    Replies
    Views
    Last post