Page 1 of 1

procedure for PSTM velocities?

Posted: Fri Oct 30, 2020 4:25 am
by Michael_Seman
It's a while since I have done this. For Kirchoff prestack time migration, one uses a horizontally-smoothed velocity field. Then one finds some gathers that aren't flat. So do you apply inverse NMO with smoothed velocities, then do final round of velocity picking? Presumably if they are nearly flat, then you could just do residual NMO trim on them.

Re: procedure for PSTM velocities?

Posted: Fri Oct 30, 2020 11:27 pm
by GuyM
Yup - preSTM, reverse NMO and repick is one approach; some packages will let you read in the "flattened" preSTM gathers and PreSTM velocity and work from that (they have usually have an RMO processing module that will read the both velocity fields and apply a residual)

The other approach is to reverse the NMO, repick and run another PreSTM.

Depends how distorted the first-pass PreSTM gathers are and the local vertical/horizontal velocity gradients.

Re: procedure for PSTM velocities?

Posted: Mon Nov 02, 2020 8:22 am
by Michael_Seman
Thank for that. I hadn't considered the possibility of a second migration.

Re: procedure for PSTM velocities?

Posted: Mon Nov 02, 2020 1:30 pm
by GuyM
There's a balancing act between the accuracy/complexity of the actual migration approach used, the model, and the residual moveout.

You can't (for example) remigrate the data to deal with raypath bending or anisotropic effects if those are not part of the migration algorithm and/or model in some way; at that point you need to do an RMO approach to "mop up" the things that the migration cannot deal with.

If, on the other hand, the residual moveout is down to the model alone - that is to say the model was wrong because it was created from unmigrated data (and so the image was mispositioned) then remigration is worth it.

As a rule of thumb, if you have rapid lateral changes in velocity (salt domes, big faults and so on) or when you run a quick PostSTM events move a long way laterally, then a second migration is likely to be worth it. If the migration error on gathers is small, and located on the far offsets more than the nears, then you probably need a better algorithm, and so RMO is a better option.