I assume you are talking about reflection seismics. The time taken to process a dataset will typically depend on the size of the data as well as what you actually choose to do with the data. I just recently processed a 150 km 2D line that had 3000 shots and 120 channels per shot. It took me three months to process the data and produce a migrated section (though I am still relatively new to reflection processing so probably longer for a more experienced geophysicist). The processing included static corrections, filters, decon, stacking, residual statics, DMO and migration.

To answer your question about the most time-consuming steps, again it depends on a few factors, but I believe these steps will be the longest in general:

• Picking first breaks. Because most datasets will require manual picking (auto picking does not deal well with inconsistencies and "badly behaved" data) and seismic data will have a lot of traces, and therefore picks. For me, this was the longest step. (It cost me just under a month and a finger from all the clicking)
• Picking velocities. Creating the velocity field requires attention to detail in all sections of the line/cube and, like the previous point, must be done manually to assure accuracy.
• Residual statics and velocity refinement. Residual statics are an iterative process; you pick velocities then apply statics, then pick velocities again and apply statics again and so on. Depending on how much you want to repick, this can be a lengthy process.

The reason seismic data typically takes so long is because no two datasets will be the same; each dataset will have a unique processing sequence and you will find that once you have applied a process to the data, something new will catch your eye that will require another process. So the processing sequence can be quite subjective and is not automated.

My advice, if you have not already, is to jump into processing a survey yourself to get a feel of the steps and why each one takes the time that it does.

To answer your last question, the most common software, I believe, is Globe Claritas. And with good reason; it is very versatile and the learning curve is not so steep.

Michael Westgate Thank you for such a through answer. Yes, I was mentioning reflection seismic. Please pardon the lack of geophysics terminology in my post (my background is in computer science).

From what you said, i understand the processes that needs to be done manually, are highly susceptible to errors with automation based on sub-surface lithology and their velocity fields. However, in case someone wants to use a certain automatic process, are there any metrics or error functions defined/standardized that take into consideration the sub-surface factors to measure the quality of a generated output? Or is it just a matter of observing the outputs manually?

On another note, with my very general reading of seismic data processing pipeline yet, the processes you mention serve as a baseline/input to other processes that you mentioned too (like deconv, stacking, NMO, DMO, migration). Would you by any chance be aware of the computational or mathematical aspects of these processes that the industry uses? I would really appreciate if you could provide any insight or references about this.

Thanks!

No worries, I am still getting used to some of the terminology myself!

I guess if someone did want to automate any of the processes, they would have to define their own error functions based on their automation. There are quite a few automated process within the processing sequence already. Refraction statics, for example, makes use of inverse theory to create a model of the shallow geology using the first breaks as the input data and refraction theory as the forward model. The error in this process is quantified by the RMS time difference between the modeled first breaks and the manually picked first breaks. Velocity picking, on the other hand, often requires human intuition but there are guides that assist in picking the right velocities (semblance for example).

Yes the processing sequence is quite interwoven and complex, with some steps being dependent on prior steps (like stacking requiring a good velocity model) and other processes being iterative (like residual statics and velocity picking). And these steps will look different for different surveys.

If you want to dig more into the mathematics, I would highly recommend "Seismic Data Analysis" By Oz Yilmaz; it is seen as THE goto for seismic processing. It is very comprehensive and covers both mathematical as well as computation aspects in a pedagogical approach. A large portion of it has been made free on the SEG wiki: https://wiki.seg.org/wiki/Seismic_Data_Analysis

Michael Westgate Thank you and appreciate your help. I'll check out the book.

Seismic processing at its highest level consists of three separate steps, and elapse is the sum of these. There is some possibility to perform these steps simultaneously, but only at the expense of considerable cost/staff inefficiency.

1. Data QC and data conversion to the format used by the processing software. This step is the least predictable of the three steps. For a single data set, we would typically take 2-4 weeks to perform this step. For a suite of data sets (e.g. several vintages), I have seen this could take up to 3 months. This is all manual labour. So far, I am not aware of any success in automating this step.

2. Preprocessing (deconvolution/denoising/velocity picking/demultiple/regularization etc). This step usually takes about half the total elapse (2D: 4 weeks, large 3D: 4-6 months). It is manually involved, with lots of parameter testing. The key part that would improve the turn-around would be to find a objective measure that constitutes a good test result. You will find many papers in the literature that have attempted this, starting from mid '90s onwards. Still, most of this revolves around the expert subjective judgement of a processor.

Preprocessing research and work-flow improvements are still being worked on a lot in research.

3. Model building and migration. In most cases, this is CPU bound. We see more and more model-builiding tools that need very little manual intervention, and migration parameters are less and less finicky. Still, subjective input and creative adaptation of the model-building flow is applied continuously. The last 15 years, most research went into this step. I might step on people's toes with this but say it anyway: for all practical purposes, seismic migration has been solved (FWI model-building and Least-Squares Migration is the bees knees). For 2D data, this would typically take 4 weeks as well, for large 3D, the CPU alone could be over a month, and elapse some 3 months.

Note that for particularly large data sets, or very complex problems, I have seen projects to take up to 3 years(!)

Jeroen Goudswaard Thank you for your response!

The arguments you make in '1' and '2' seem reasonable to me. However, I have a question about your point '3'.

Coming from a computer science background, this becomes very interesting to me when you say the process is 'CPU bound'. In my understanding, there could be two aspects to this:

One, the algorithms/programs have a high degree of data movement between memory and CPU (and comparatively lesser computations), in which case the problem is not necessarily CPU bound but is more of I/O bound and could be made to perform better using more efficient dataflow that provides a higher computation to I/O ratio while still using CPU's.

Second, the algorithms already have a high computation to I/O ratio, but the current processors are not suitable for the computation patterns that are employed and maybe these processes could benefit from using better hardware like GPU's or a processing chip that is specialized for such applications.

One more thing I'm confused about is the statement: "for large 3D, the CPU alone could be over a month". Am I correct in assuming that this "over a month" period is a result of iterative process of parameter tuning and running model-building/migration on CPU's? Or does that period consist of CPU just crunching numbers for one set of parameters?

If it's the former case (i.e. iterative process), then would you happen to have any examples of run-time for migration programs for a certain amount of data?

Thanks!

Dear Suyash Bakshi and colleagues.

Trying to help you in schematically work-schedule, helping you to understand also what other colleagues have responded to you, please, let me share this picture. This is a real study-case, taking from a 3D PSTM processing in a project of Argentina.

If you started working next Monday, it would finish in approximately two months according to the detail of the references. You should pay attention to the volume of 3D seismic data and its variables. I hope this picture help to you.

Please, remember this words from Michael Westgate´s answer:

"The reason seismic data typically takes so long is because no two datasets will be the same; each dataset will have a unique processing sequence and you will find that once you have applied a process to the data, something new will catch your eye that will require another process. So the processing sequence can be quite subjective and is not automated."

Please, let me know if you need a little more help.

Best wishes, Mario E. Sigismondi