Both the shooting and where the shooting occurs are handled by the acquisition crew, while relating the two is often left to someone in the processing centre as not all field crews have the capability to check the navigation/seismic merge in the field. It’s not that common for the person processing the data to also be in the field acquiring it, so it can be easy to fall into a ‘field vs. office’ mentality when errors are found. “They can fix that in the processing” is uttered from time to time by field crews so that they don’t have to fix a problem encountered during acquisition. Alternatively you might hear “if the acquisition crew had just done a better job this wouldn’t be an issue” from a processor, complaining about the extra work. The truth lies somewhere in the middle. Despite every effort being taken in the field during acquisition, from time to time issues do arise that lead to the data being recorded with errors and this is something that you, the processor, have to deal with.
The field can sometimes be a harsh environment. When things go wrong it can range from being soaked in stormy weather, to guerrilla encounters and a coup d’état! Not to mention the long days, temperamental equipment and pesky local wildlife; one observer log entry read “two exploded camels” as reason for a misfire. Nevertheless a lot of time can be lost in the processing centre having to solve for navigation errors (e.g. two stations with the same location) that really shouldn’t exist. Field or office, everyone makes mistakes and you need to have steps in place to lessen the effects.
“Garbage in, garbage out” is a famous computer axiom which basically states that if invalid data is entered into a system, the resulting output will also be invalid. Pretty straightforward really. It should then come as no surprise that if you incorrectly set up your geometry (one of the first steps in processing) your results will be incorrect. Don’t underestimate the importance of quality control (QC) at this stage; the price of rewinding an entire project because the geometry was wrong is not one you want to pay.
When merging seismic data with coordinate data you are actually setting up a database (of sorts) which contains all of the survey information; such as shot point definitions, source and receiver coordinates, and elevations. This ‘database’ is accessed for a variety of uses including refraction statics calculations, CDP binning, creating CDP gathers, and populating SEG-Y trace headers.
|Geometry database summary|
With seismic processing in general, it’s good practice to follow robust QC procedures and there’s no exception when it comes to setting up and proofing geometry. Here are three useful methods:
- Review the diagnostic text and check that values are consistent. Typical errors are likely to come from: seismic numbering, navigation numbering, shot location, and receiver spread. If an error message pops up, read it! It may be telling you something important about your data. An example of this was where a client was ignoring warning messages and was unable to build the geometry. The message was trying to inform them of a 6 m elevation difference from one station to the next. As it turns out the survey was shot in two phases and in between, a flood had washed away tons of sediment in the area, leaving a small chasm. Moral of the story, read the observer logs and pay attention to pop ups. Good software will be checking data consistency for you and alert you when it isn’t.
|Shot position on map with live update diagnostic information|
- You’ve heard it again and again – “A picture is worth a thousand words” – the adage that it is easier to absorb large amounts of data quickly through visualization. If you graphically represent the information by producing a plot/map it will help you highlight any obvious inconsistencies. You can display source/receiver positions and quickly identify erroneous positions; e.g. a station that is shifted 30 metres away from the spread. It would pay to check the observer logs as there may have been a valid reason for relocating the position, such as a creek in the way. Other useful information to display graphically include: source/receiver elevations, first break picks, CDP fold, and bin locations.
|Map showing source (red) and receiver positions|
|Map showing Common Mid Point positions|
- You’ll need to check if the geometry, once applied to the data, is correct. Start by overlaying the offset from the trace headers onto the seismic traces. This can be done by applying an estimated linear velocity to convert offset to time. Check that the apex of the offset values, match the apex of the seismic record. You can also apply a linear moveout (LMO) making sure that your velocity estimate gives you roughly horizontal first-breaks when the LMO is applied. Now you can cycle through the shots and if the header offsets are incorrect, the LMO will be out of sync and there will be a clear 'step' at zero-offset.
|Offset from trace headers (red) does not match shot record; in this case channel numbers are not matched correctly against stations|
Ideally you want the geometry to be loaded into the trace headers before it reaches you, and for it to be correct. Unfortunately it’s best to assume that it is incorrect and get into the habit of checking! If it hasn’t already been applied in the field you should receive the coordinate information in the form of Shell Processing Support (SPS) files. The SPS format was developed by Shell Internationale Petroleum Maatschappij as a common standard for positioning-data, between their 3D land field crews and the processing centres. The format proved durable enough that it was adopted by the Society of Exploration Geophysicists (SEG) Technical Standards Committee in 1993 (SEG SPS Revision).
Most SPS files today are generated automatically by the seismic recording instrumentationconsist of a set of three files; a Source file [s], a Receiver file [r], and a Cross Reference file [x]. There is also an optional fourth file for comments. The Receiver file contains information about the geophones such as their ID, type, and position (Easting, Northing, and Elevation). The Source file contains information about the seismic source, namely its position and ID. The Cross Reference file contains information about the Shot ID, and the source and receivers associated with that Shot ID.