High‑Performance Computing Applications in Oil Exploration: Data Processing, Storage, and Workflow

The main fields of HPC applications are scientific and engineering computing, such as high‑energy physics, nuclear explosion simulation, weather forecasting, petroleum exploration, earthquake prediction, earth simulation, drug discovery, and CAD‑based simulation and modeling. With the maturity of cloud computing and big data, HPC has penetrated HPDA and HPC‑Cloud, and to make the concept concrete we take geophysical exploration as an example to start the journey of HPC in this domain.

Petroleum exploration is a typical HPC‑geophysics case. It works by reflecting seismic waves and consists of three steps: data acquisition, seismic data processing, and data interpretation.

The seismic data processing system requires extremely high computational performance and stability because the data volume and difficulty are huge. In a typical workflow, explosives are detonated on the surface, instruments record the reflected seismic waves, the raw wavefield is cleaned and transformed into geological information, and finally the location for drilling is determined.

With continuous updates in petroleum‑exploration technology and the infiltration of information technology, companies are forced to adopt high‑performance, cost‑effective computing systems to stay competitive.

Step 1: Initial data – often tens to hundreds of terabytes.

Step 2: Seismic data processing – the raw data are cleaned, validated, and converted into useful geological information. Raw seismic data contain overlapping and distorted signals that cannot be directly used for geological interpretation, so indoor processing is required.

High‑performance computing for seismic exploration can be divided into two major categories: seismic data processing and reservoir simulation.

Seismic data processing is a typical floating‑point‑intensive workload that solves data‑dense wave equations, demanding high floating‑point performance and good multi‑core scalability.

Reservoir simulation requires iterative solving of sparse‑matrix equations, very high memory‑bandwidth, and large caches, making it a memory‑bandwidth‑sensitive compute‑intensive application.

During seismic data processing, the network mainly handles parallel‑computing data communication and parallel file‑system data transfer.

Data communication during parallel computation involves frequent, relatively small exchanges of data between compute nodes while solving equation systems.

Parallel file‑system transfer mainly consists of reading and writing large files between compute nodes and storage nodes; the transfers are less frequent but involve massive data volumes, requiring high network bandwidth.

As the computational power of high‑performance servers increases, the amount of data that must be stored also grows, mainly intermediate data generated during computation, which requires a stable, high‑speed transmission bandwidth.

In addition to intermediate data, the storage system must keep large volumes of final results, demanding high reliability.

Seismic data processing follows three stages: initial data, intermediate data, and result data.

The first stage imports raw field data into the storage system. Fast ingestion of the raw data into compute nodes is required, and the intermediate data produced during computation must be kept online on high‑performance storage with very high I/O performance.

During computation, intermediate data can be dozens of times larger than the initial data and are read and written repeatedly, eventually producing the final result data.

Intermediate data cannot be deleted because a computation may need to restart from a certain point to improve efficiency.

HPC tasks may run for hours, days, or even weeks. With systems comprising tens of thousands of nodes, failures are inevitable, so checkpoint technology is widely used to periodically save the state and intermediate data, allowing recovery from the last checkpoint after a failure.

Intermediate data also have archiving requirements; keeping them online for long periods wastes storage resources, so they are migrated to near‑line or offline storage when they are no longer frequently accessed.

Result data are final, immutable, and must be preserved long‑term. The storage requirements for seismic data processing include:

1. Unified namespace: All compute nodes read and write data from a single namespace.

2. Large data volume: Initial data are tens of TB; intermediate data can be 10‑20× larger; result data are only about 0.5‑1% of the initial size.

3. High bandwidth: Although data transfers are infrequent, each transfer is large, demanding high network and storage bandwidth.

4. High reliability: Intermediate and result data are valuable and require reliable storage.

5. High scalability: Multiple compute clusters share a single storage system, avoiding data migration.

6. Ease of use and management: A single namespace, flexible quota allocation, and simple maintenance.

7. Archiving needs: After their lifecycle, intermediate and result data are rarely accessed and need to be archived.

Step 3: Interpretation – After digital processing, the seismic data provide numerous 2‑D sections or 3‑D volumes containing geological information. Interpretation extracts oil‑ and gas‑related information, such as potential reservoirs, storage layers, and rock properties, which is crucial for locating hydrocarbon fields.

Interpretation is the final and essential step of seismic exploration; its quality directly impacts the speed, quality, and accuracy of finding oil and gas fields.

For a detailed summary of high‑performance computing technology, solutions, and industry analysis, refer to the e‑book "High‑Performance Computing (HPC) Technology, Solutions, and Comprehensive Industry Analysis" linked in the original article.

Warm tip: Search "ICT_Architect" or scan the QR code to follow the public account and click the original link for the full article.

Thirst for knowledge, humility in learning