Origin Story: Part 1
Seeing the Problem: Where near surface seismic imaging approaches have failed
Background
During my undergraduate studies at University of Washington, I took a course on active source seismic imaging, primarily focused on reflection methods and their interpretation at Oil and Gas scales. This course initially peaked my interest in seismic methods but I was unsure about going into the Oil and Gas field. Around the same time, I took a course within the geology department on geotechnical engineering, which very briefly discussed the use of active source seismic methods for geotechnical investigations. The idea of utilizing seismic methods at engineering scales was intriguing to me. Why had I not heard about this more?
Through my own cursory investigations, it seemed that seismic methods were just too cumbersome and expensive for most engineering scale studies. Either way, I wanted to continue my education exploring seismic methods for near surface environments. I was presented with a Masters opportunity at Boise State University, to work on a project to develop, build, and test a multicomponent seismic land streamer system. This system was to be used for the rapid collection of data in highly urban environments, and explore how various processing steps can be improved by bringing in additional geophone orientations. This system enabled us to collect a TON of high quality data with significantly less effort and time. I thought very early on that this streamer is the “Silver Bullet” solution and will drive the wider adoption of seismic methods for engineering scale problems (and everyone needed one!). Even better, this streamer was perfectly suited for data collection in difficult urban conditions, where quantifying earthquake hazards are even more critical due to the increased risk with larger buildings and higher population densities.
While the streamer significantly reduced the necessary labor required for data acquisition and increased output, it highlighted other serious shortcomings of near-surface seismic methods that I had not thought of.
Issues come to light
With all the data in hand from the land streamer, it now needed to be processed in a variety of ways to quantify seismic related hazards. The various seismic processing methods included:
- Reflection processing used to identify and map evidence of active faulting
- Refraction tomography to map water table depth in unconsolidated sediments
- Surface Wave analysis (MASW) to estimate local seismic amplification
Using all of these methods has the added benefit of being able to jointly analyze the results and create additional useful estimates, for instance estimating Poisson Ratio or liquefaction susceptibility.
So how hard can running all of these analyses be? They are using the same data, and these methods are not new, so obviously there should be a pretty nice software package to process it all? I quickly learned that processing was anything but straightforward.
Complexity in data processing
Chief among the issues was the level of complexity needed to process all of the data. For a masters student, early on in his journey, all of the software required to process the data was intimidating to say the least. There was:
- Scripts, spreadsheets, and Seismic Unix to prepare the seismic data for other software
- Rayfract, Promax, and Surfer for first break analysis to estimate P-wave velocities (Vp)
- More scripts, Surfseis, and custom Matlab code needed for surface wave analysis (MASW) to estimate shear wave velocities (Vs)
- More scripts, spreadsheets, and Matlab code to integrate the various 2D results
It was usually somewhere between 8-10 different pieces of software, not to mention ALL the files needed to be kept track of to move between software, in addition to all the intermediate files the geophysical software required. In my naivete, I thought that a software stack like this was unique to our land streamer approach, especially considering how some of these processing approaches got sold to me as being “simple” (or at least “not that hard”). What I quickly discovered was this level of processing complexity was very common and absolutely not unique to us. Even a single type of analysis (i.e. first break tomography, or MASW) would still require multiple pieces of software and very often some level of “Kludge” to accomplish.
Processing errors
Issues also arose from “Complexity’s” every present right-hand man: “Mistakes” (more than I care to admit). As seems to be the case in any field or endeavor, and likely fundamental to nature itself: the more complex a system (i.e. the more moving parts a system has), the more likely something will fail. Here are some examples of mistakes, with varying degrees of potential impact, that I have seen first hand (i.e. my own mistakes):
- Incorrect source to first receiver distance when calculating dispersion images for MASW
- Cause: Missed changing a variable in some custom code
- Actual/Potential Impact: May have some minor amplitude normalization ramifications
- Severity: Minor
- Incorrect receiver spacing assigned to data
- Cause: Used the wrong spreadsheet in a script
- Actual/Potential Impact: All picked dispersion curves were invalid and first break inversion results would be incorrect
- Severity: Major
- Overwriting manual pick results file every time the custom code was executed
- Cause: Poorly tested and vetted code
- Actual/Potential Impact: Lost a weeks worth of work before it was noticed
- Severity: Painful…
The common denominator in all the mistakes above, as well as the majority of the other mistakes I have seen, happen in the “Kludge” steps: the scripts, input/output files, spreadsheets, custom code, and the other practitioner implemented solutions NECESSARY to get to the required solution.
What can be done?
Although there may be several potential approaches to addressing these problems, the most obvious to me was to reduce the processing complexity (i.e. have less moving parts). This could be accomplished by reducing the number of different software and the associated transfer of data between them. What seemed especially important to try to eliminate, was the need for practitioner created scripts/manual processes at different points, as these were the most error prone steps in my experience. And since all of these different processes are fundamentally linked to the same set of seismic data, why couldn’t all of these steps be combined more fully?
Maybe there could be a Single software package, containing all of the necessary components to begin with unprocessed waveforms, do all data-qc and preprocessing, get estimates of Vs from surface wave analyses (e.g. MASW), Vp from first break analyses, and end up with fully integrated results. Why not? Or is this just a wild idea?
Well this wild idea, a unified software from which to do all near surface seismic analyses, is what lead to the creation of GeoFennex and our flagship product: NeST.
Stay tuned
We will be continuing next with Part 2 of the GeoFennex Origin Story.