Do the processing flow and testing have the same meaning?

[onur89]

I am new on seismic data processing. Just started processing a data. From some articles I read, what I understood was that these two concepts are the same but some indicated they`re different. . could you please, explain the difference with an example (if possible )?

Also, as I mentioned before I am new and If you have any suggestions on how to start processing, or any books that explain processing steps (why, when, pros cons ) very well, or anything you think it could be helpful (as you are the ones who are experienced) , it would highly be appreciated.

Thank you...

[GuyM]

Hi -

In general we break down a processing sequence into a series of processing stages

Each processing stage will usually apply more that one algorithm or processing steps to the data.

The main reason to have multiple processing steps in each processing stage is to limit the amount of data stored on disc, and the associated I/O overhead for reading that data. Some of this is historical, since we used to use magnetic tapes for all data storage (which is very slow), but even at 300Mbytes/second or more, a 750Gbyte 3D seismic survey (and that's small - maybe 500-600sqkm) will still take 90 minutes or so to read and then write back out, with no other processing applied.

So - the idea is to build processing stages that are CPU-bound (ie speed depends on computer processing power) and not I/O bound (ie speed depends on reading and writing data)

The other consideration for breaking a sequence up into processing stages is the need for manual analysis (picking first breaks, velocities, mutes, horizons etc) and QA.

We do need to test each processing step separately, however. This is usually done on a representative subset of the data for speed; you might be able to apply multiple tests in a given flow (using repeat copies of the data) or need a new flow for each parameter variation.

So - we have two types of processing flow:

- test flows to determine the parameters for a a give processing step
- "production" stages that apply a multiple processing steps to the entire dataset in an optimized way

In a large-scale project with a team working on it you might have one person conducting tests to build the flows for the next processing stage, while another person "runs production" - that is pushes all of the data through the already-determined processing stages and conducts quality control checks or manual analysis.

To sum up:

- a processing step comprises one or more modules used to apply a specific algorithmic approach, such as "Tau-p deconvolution" or "SRME"
- a processing flow contains an input module, a number of processing steps, and a display or output module
- "test" processing flows are applied to a subset of the data to test each algorithmic approach in tern, one at a time
- "production" processing flows (or "stages") are applied to all of the data in a project or survey, and may contain multiple processing steps
- a processing sequence is a combination of all of the processing and analysis stages used

Hope that makes sense!

[onur89]

Thank you very much for your time, GuyM...

It surely makes perfect sense now. To check if I understand correctly, let me sum up what I understood.

1-Algorithms (processing steps) ------> processing stages --------> Processing sequence(flow) to give an example,
(For instance, Kirchoff) ------------> Migration-------------------> All processing stages applied

There are different migration types such as Kirchoff, Stolt, Gazdag... these are processing stage of migration and each has different algorithms. To see which one is the best, we try all of them on a sampled data. Whichever gives best image that is the one. What we are doing here is called testing.

2- Also, I never thought that the data volume is that important. Thanks to advancing tech, it is now ,as you said, CPU bound, and the duration required to process a whole data to get an image of subsurface depends on processing speed of the computer, CPU. Now, I see why processing 3D data takes 4-12 months. First, It seemed to me like exaggerated. I thought how come it does take too long. it is a computer-related and should not be that long.

3- Here, you said... We do need to test each processing step separately, however. This is usually done on a representative subset of the data for speed.... by saying representative subset of the data, you meant first try it on a small scale, right ? For example, I have 3- component data, which means 3 representative subsets of data. To do what you said, I need to pick one component, say vertical, then first try all different kind of algorithms (again let say gazdag stolt..for migration) on this component then after finding the best one, apply it on other components, too. And do it for every stages(velocity analysis, migration and others ) that have different types of algorithms to find the best you have got.

Am I correct ?

Thanks

PS:I realize that I am asking too much. The questions I have asked could seem to be very easy for some but not for me now. I started to processing data like one week ago. These are the questions that come to my mind while I was studying concepts of seismic data processing. I have a data processing flows for the data sets I have and I am reprocessing exactly the same flow as a beginner. I just want to understand what they are, why, how, and when....to learn this job.

[GuyM]

I think you are mostly there.

On your point (1)

In general we have a pretty good idea of the processing sequence we want to apply and the pros and cons of different algorithms and what you will need to apply in this context. So - we don't usually test *everything* we have unless there's a specific problem to be addressed.

You could test Gazdag, Kirchhoff and Stolt migrations if you wanted to, but in general (these days) you'd be more likely to be running a Kirchhoff PreSTM and testing the parameters within that which constrain the operator shape - dip angle, anti-alias filter strength, migration aperture and near-offset protection in a quality Vs noise Vs processing time way.

We used to use post-stack Phase-Shift (Gazdag) or FK (Stolt) migrations because they had low computation needs; these largely got dropped in favour of post-stack Omega-X methods in the 1990s and subsequently replaced by Kirchhoff pre-stack migrations in the late 1990s as parallel Linux clusters become available.

So - you'd need a compelling reason to look at Gazdag or Stolt migration (limited resources is compelling) or even using a post-stack migration instead of pre-stack (poor offset distribution or signal-to-noise, for example)

(see : http://seismicreflections.globeclaritas ... tion.html )

On point (2) - yup, data size is still a problem. We have a 500sqkm 3D marine project which is about 750Gbytes of data at 4ms sample interval. If you process that through 8-10 stages you are going to need to have 6-8Tbytes of data storage available for that one small project. If you only applied one processing step at a time you might need to have 20+Tbytes of storage. While that's not a *huge* amount it's still significant. To *process* that data is likely to take 20-40,000 "core-hours" or more. If you have an 48-core machine that's still 35+ days of solid runtime, and you have a velocities and QC to factor in around that. And a 500sqkm 3D is really quite small for modern marine surveys.

On point(3) - You'd usually have a "test line" or a "test area" in 3D for the parameter tests; you might even use some selected shots within that line, or selected CDPs, or part of the line. You are looking for data that is typical of the problems you need to solve - not much point testing a migration algorithm on flat events, for example. Multi-component data is a more complex issue - you'd generally aim at applying the same sequence to all of the components.

[onur89]

Hello GuyM, and

Again, Thank you so much for your help...It is very nice of you to make time for answering to my question...

[GuyM]

Thank you so much for your help...It is very nice of you to make time for answering to my question.

No problem. It's good practice for me to explain these kind of things from scratch!