Data Download and Transcription in Nodal Seismic Acquisition Systems
Data Download and Transcription in Nodal Seismic Acquisition Systems
Nodes have become a popular system architecture for seismic data acquisition due to the benefits of higher operational efficiency, lower downtime, lower HSE risk and lower environmental impact. Our very own Dennis Pavel discusses Data Download and Transcription in Nodal Seismic Acqusition Systems and the key steps involved in order to deliver seismic data.
Introduction
Nodes have become a popular system architecture for seismic data acquisition due to the benefits of higher operational efficiency, lower downtime, lower HSE risk and lower environmental impact. However, there are obvious operational differences associated with nodal acquisition compared to traditional cable-based acquisition. Most notably, cable systems offer real-time access to seismic data during source production since all acquisition units are interconnected, ultimately delivering data directly to a central computer system. Nodes are autonomous acquisition units with no interconnectivity, a key system architecture difference that contributes to achieving the benefits described above. Nodes record continuously and store data in local memory, requiring data to be downloaded from each node after source production has completed. For example, either during receiver roll over the course of the project, at the completion of the project or typically both.
This distinction makes the process of data download and transcription a critical aspect of a nodal system. The process must be highly efficient to prevent eroding the benefits gained from nodal architecture. It is important to note that while the process is often referred to simply as “data download” or “data harvest”, this describes only the first step. There is much more the system must do to provide final data output in accordance with user requirements.
Data Download Path
Moving data efficiently from nodes to final output in a desired structure and format requires attention to each step along the way. The path can be fraught with potential throughput bottlenecks both in hardware and in software. Figure 1 highlights key areas of the download and transcription path. The path starts at node memory and then proceeds through the node physical interface, passing across network interconnections until reaching the transcription computer. Once at the transcription computer internal disks and memory are utilized for temporary data storage by software orchestrating transcription. Finally, data is archived onto hard disks and written to delivery media, completing the path of potential bottlenecks. For simplicity, Figure 1 shows only a single node connection but in practice this will be hundreds or even thousands of nodes simultaneously connected and being harvested which further burdens the downstream network, transcription computer and storage devices.
Node Data
Data is typically stored in the node in a proprietary native format and is recorded continuously during the time period the node is programmed each day up to the full 24 hours per day. Shots are dispersed throughout the continuous recording based on the type of source production employed and rate of production. The volume of data contained in each node can be large depending on the acquisition parameters and number of days recording prior to download. In high productivity vibroseis operations, sweep records can be overlapping which means the volume of sweep data recorded is actually greater than the volume of continuous data. When multiplied by tens of thousands of nodes on a project the total amount of data that needs to be managed during download increases even more.
Network
The configuration of a node download network is analogous to a client-server computer network.
Each node connected to the network acts as a client and the transcription computer acts as a server. They communicate through a unique secure protocol whereby the transcription computer sends instructions to the nodes to execute certain tasks such as, download data, perform tests and program operational parameters, to name a few.
Similar to a computer network there are two primary considerations for node download networks; throughput and bandwidth. Throughput is the rate at which data can be transferred across the network while bandwidth is the maximum data capacity the network can support. Both are important in achieving overall efficiency.
Transcription Computer
The transcription computer plays a pivotal role in the overall node download system and requires server class computing power. In addition, working disks and memory for data handling require fast read and write speeds in order to move data quickly during processing, formatting and other data transcription workflows. Likewise, the software performing these tasks needs to be streamlined. Database schema should be structured efficiently for rapid indexing required to generate data output in required arrangements and formats.
Output Data Storage and Archive
Separate from the transcription computer’s internal storage the data management system includes additional storage for archiving project data and writing final data to media for delivery to the client. Project data can be archived on RAID arrays which are scalable to hundreds of terabytes storage capacity and can be daisy-chained to increase total archive capacity beyond a petabyte. These devices provide redundancy to protect against loss of valuable seismic data in the event of a hardware failure. Final data output is written to portable or removable high speed disk drives often in duplicate for further data redundancy.
Node Download and Charge Capacity
The quantity of node racks, or more specifically the quantity of node slots, used for data download and battery charging are an inherent part of the system efficiency discussion.
Adding additional node capacity to the system increases the volume of nodes that can be processed at one time and also increases requirements on network bandwidth for data transfer. Adding node capacity has a greater impact on reducing overall battery charge time, since more nodes are charged concurrently. The amount of time required to recharge batteries depends on how long the nodes have been recording in the field; that is, how much battery has been used. For example, the node with lowest power consumption currently available on the market can record continuously for 50 days or more on a single charge, depending on configuration. The typical deployment duration is much shorter than 50 days so only a fraction of the available battery capacity is consumed, allowing quicker recharge back to full capacity.
Determining the proper node capacity for a download system requires an understanding of data volume, processing speeds and battery charge requirements as dictated by operational parameters and project time constraints.
Transcription Process Flows
The first step in the transcription process converts data from the node’s native format to a working format the transcription computer will use to generate data output required by the user. The type of output determines what additional pre-processing steps need to be taken. For example, any output option that requires data sorted by source point requires extracting shot records from the node continuous data. Therefore, these processes require information related to the source point, such as the shot number, shot time, record length and other pertinent information. Once shot records are extracted further pre-processing may still be required. For example, in the case of vibroseis source, individual sweep records may require stacking and/or correlation with a pilot sweep. Depending on desired output, traces can be sorted by receiver point or by source point. For microseismic or high productivity vibroseis applications data can be output in common time gathers or continuous time receiver gathers. An advanced transcription system will have the capability to provide all of these options.
Data Output
The end objective of the transcription process is to produce final data output delivered to the client as fast as possible in a prescribed format with records structured as defined by the seismic acquisition contract. Various types of data output sorting may be required.
Continuous Time Reciever Gatherers
Continuous time receiver gathers are the simplest form of node data output requiring no preprocessing, no source information and minimal sorting. This option provides raw continuous data that is sliced into user-defined time sections. Precise recording time is provided in trace headers allowing later processing relative to source events. Figure 2 shows example file outputs for hypothetical receivers R1 and R2. The individual time records within each receiver output file, that is R1T1, R1T2, R1T3and so on, are contiguous with one sample overlap. All of the time records are contained in a single file for each receiver, or node. Events are spaced throughout the records based on the time they were acquired.
Common Time Gathers
Common time gathers are similar to continuous time receiver gathers in that this output also does not require source information or pre-processing. However, in this instance the emphasis is on a user-specified time segment of recording. Files are generated containing records from all receivers for that time period. Referring to Figure 3, time records for a given receiver in one file have a one sample overlap with its continuing time record in the next file. For example, the record R1T1in file named Time Segment T1 has a one sample overlap with record R1T2in the next file, Time Segment T2. Event records are time aligned within the segment file. Like continuous time receiver gathers, precise recording time is provided in trace headers for later processing relative to source events.
Receiver Gathers
Unlike the previous time-based output options, receiver gathers require source point information in order to extract shot or sweep records from the continuous node data. In this instance, the output file contains shot records for all source points associated with a common receiver. Figure 4 shows an example receiver gather output file with shot records sorted by offset distance from a receiver that is in close proximity to source point S1.
Shot Gathers
Like receiver gathers, shot gathers also require source point information in order to extract shot records from each receiver. The output file contains shot records for all receivers associated with a common source point. The primary difference between a receiver gather and shot gather lies in the way the records are sorted in the output file. Figure 5 shows an example shot gather output file with receiver records sorted by offset distance from a source point that is in close proximity to receiver R1. A shot gather (or receiver gather) file will be incomplete until all nodes required in the gather file have been retrieved from the field.
Conclusion
Download and transcription is a crucial element of a nodal acquisition system that demands attention to each step of the process in order to maximize efficiency. The method needs to be flexible and have the ability to scale up to support different aspects of the seismic operation and data requirements. For example, the burden on the process changes depending on the stage of the seismic survey. Data volumes during receiver roll may be smaller than at the end of a project when many more nodes require data management once the final source point is acquired and the full receiver template is taken out of the field. Accordingly, the amount of time required to complete the process may be much shorter during receiver roll than at project roll off since nodes during receiver roll are required to be returned to the field quickly to keep pace with source production. In both phases, time is of the essence for different reasons therefore the download and transcription operation must be designed from a holistic viewpoint to meet changing operational requirements and process time expectations.
With nodal systems, the node acquisition unit itself usually garners much of the attention. That attention is justified for evaluating field operation concerns. However, it is the system, particularly the download and transcription part of the system that also differentiates one offering from another. It is just not as apparent until put into practice.
