procedure for PSTM velocities?
-
- Silver Member
- Posts: 30
- Joined: Fri Nov 24, 2017 4:36 am
procedure for PSTM velocities?
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?
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.
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.
-
- Silver Member
- Posts: 30
- Joined: Fri Nov 24, 2017 4:36 am
Re: procedure for PSTM velocities?
Thank for that. I hadn't considered the possibility of a second migration.
Re: procedure for PSTM velocities?
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.
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.
-
- Similar Topics
- Replies
- Views
- Last post
-
- 4 Replies
- 1493 Views
-
Last post by GuyM
-
- 1 Replies
- 1149 Views
-
Last post by Michael_Seman
-
- 1 Replies
- 952 Views
-
Last post by GuyM
-
- 5 Replies
- 2603 Views
-
Last post by GuyM
-
- 0 Replies
- 3205 Views
-
Last post by jefry123