Multi-task management system for seismic data processing

Abstract

The invention provides a multi-task management system for seismic data processing, and relates to the field of seismic data processing, and the system comprises a seismic data interface which is used for providing an interface for a single-task actuator to read seismic data in different data formats; the task chain comprises a plurality of single-task actuators connected in series, the first single-task actuator reads seismic data through the seismic data interface, the last single-task actuator writes a data processing result into the storage device, and the multiple single-task actuators in the middle are used for executing different data processing tasks; and the task manager is used for managing the task chain. According to the invention, a unified seismic data interface is provided, so that various seismic data in different formats can be read through the unified interface. In addition, the seismic data is subjected to serial and multi-task processing through the task chain, and the data processing efficiency is remarkably improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of seismic data processing, and particularly relates to a multi-task management system for seismic data processing. BACKGROUND

[0002] In the field of oil geophysical exploration, node acquisition is increasingly popular. The characteristics of the node are to continuously acquire seismic data in order to obtain high-quality and effective data. In the process of processing seismic data, the amount of seismic data is huge, and the data formats are various.

[0003] In the related art, the processing of different seismic data formats usually requires specific interface and algorithm support. Due to the diversity of data formats, developers need to write different processing codes for each data format, which increases the complexity and maintenance cost of the system. At the same time, the management of seismic data processing tasks is usually complex, and there is a lack of a unified manager to coordinate and control the data flow and task execution between each task executor, which increases the debugging difficulty and instability of the system. Therefore, an efficient, flexible and scalable management method and framework are needed to process these seismic data. SUMMARY

[0004] Embodiments of the present disclosure provide a multi-task management system for seismic data processing, which aims to solve the problems in the background art.

[0005] In order to solve the above technical problems, the present disclosure is implemented as follows:

[0006] Embodiments of the present disclosure provide a multi-task management system for seismic data processing, which comprises:

[0007] a seismic data interface, configured to provide an interface for a single-task executor to read seismic data in different data formats;

[0008] a task chain, comprising a plurality of single-task executors connected in series, wherein the first single-task executor reads seismic data through the seismic data interface, the last single-task executor writes the data processing result to a storage device, and the plurality of single-task executors in the middle are used to execute different data processing tasks;

[0009] a task manager, configured to manage the task chain.

[0010] Optionally, for the plurality of single-task executors in the middle of the task chain, each single-task executor comprises a corresponding input executor and at least one corresponding output executor.

[0011] Optionally, the single-task executor is bound with at least one thread; for any single-task executor, at least one independent thread is enabled to execute the data processing task.

[0012] Optionally, if new functional requirements are detected, the new functional requirements can be met by adding new single-task executors and / or adjusting the combination of existing single-task executors in the task chain.

[0013] Optionally, the task manager is used to control the unidirectional transmission of the seismic data in the task chain, and to record and publish the progress data returned by each individual task executor in the task chain.

[0014] Optionally, after receiving the execution instruction to execute the data processing task, the single-task executor transfers the data processing task to any bound thread for execution, and sends a task completion notification to the task manager after execution is completed.

[0015] Optionally, the single-task executor implements its functionality based on a single-task executor base class; the single-task executor base class is configured with a first type of interface, a task execution signal, a task execution slot function, and a task completion signal;

[0016] The first type of interface is the only interface through which derived class functions implement task execution logic;

[0017] The task execution slot function is bound to the task execution signal so that the single task executor executes the corresponding data processing task after receiving the task execution signal;

[0018] The task completion signal is used to send a notification to the task manager when the data processing task is completed.

[0019] Optionally, the task manager is also used for:

[0020] The seismic data processing task is divided into multiple sub-tasks;

[0021] Create a task manager base class, specify the same number of threads and single-task executors as the number of subtasks, and implement the functionality based on the task manager base class;

[0022] Bind each thread to a single-task executor;

[0023] From the task manager object, assign a corresponding single-task executor to each subtask.

[0024] Optionally, the task manager base class is configured with a second type of interface, an initialization function, and a task execution progress signal;

[0025] The second type of interface is used to create a base class for a single-task executor;

[0026] The initialization function is used to bind threads and single-task executors one by one;

[0027] The task execution progress signal is used to indicate that any single task executor has completed its respective data processing task.

[0028] Optionally, the task manager is also used to specify individual task execution parameters for each subtask, including: creating a parameter object for each subtask; and writing the specified task execution parameters into the respective parameter object.

[0029] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects:

[0030] This disclosure provides a unified seismic data interface, enabling the reading of seismic data in various formats through a single interface. Developers only need to develop algorithms for this unified interface, without having to write different code for each data format. Furthermore, this disclosure utilizes task chains to process seismic data serially and in multiple tasks, significantly improving data processing efficiency. The task chain is managed and organized through a task manager, systematizing the entire seismic data processing workflow and offering advantages such as ease of management and monitoring. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram of a multi-task management system for seismic data processing provided in one embodiment of this disclosure;

[0033] Figure 2 This is a schematic diagram of a task chain structure provided in one embodiment of the present disclosure;

[0034] Figure 3 This is a schematic diagram of the main process of seismic data processing provided in one embodiment of the present disclosure. Detailed Implementation

[0035] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0036] Figure 1This is a schematic diagram of a multi-task management system for seismic data processing provided in one embodiment of this disclosure, as shown below. Figure 1 As shown, the system includes:

[0037] Seismic data interface 101 is used to provide an interface for a single-task executor to read seismic data in different data formats;

[0038] Task chain 102 includes multiple serially connected single-task executors, wherein the first single-task executor reads seismic data through the seismic data interface, the last single-task executor writes the data processing results to the storage device, and the multiple single-task executors in the middle are used to perform different data processing tasks.

[0039] Task Manager 103 is used to manage the task chain.

[0040] The seismic data interface 101 supports multiple seismic data formats (such as SEGY, SAC, MiniSEED, etc.) to ensure the system can process seismic data from different data sources. The seismic data interface provided in this disclosure primarily simplifies and unifies access to seismic data in different formats, particularly to header data and trace data. Header data contains metadata for each trace, such as sampling rate and start time, while trace data is the actual seismic signal. The seismic data interface provides a unified access method, eliminating the need to consider differences in specific data formats, and encapsulates the underlying data parsing logic, allowing upper-layer applications to easily read and write seismic data. Therefore, processing seismic data in different formats becomes simpler and more efficient.

[0041] Task chain 102 is a flow control structure for processing seismic data, comprising multiple cascaded single-task executors. Each single-task executor executes a specific task sequentially within the task chain. The first single-task executor reads seismic data through the seismic data interface SeisDataInterface and initializes the data processing flow. The intermediate single-task executors perform a series of different data processing tasks, such as data preprocessing, filtering, feature extraction, and signal enhancement. The last single-task executor writes the processed data results to a storage device, completing the entire data processing flow. This disclosure's task chain design, implemented by cascading multiple single-task executors, enables efficient and flexible completion of complex data processing tasks.

[0042] The following example uses Python to demonstrate the implementation of a task chain:

[0043]

[0044]

[0045]

[0046] In the example above, each task (reading, preprocessing, filtering, feature extraction, and saving) is encapsulated in an independent class and runs independently in each single-task executor. The reading task is executed by the first single-task executor, and the saving task is executed by the last single-task executor. The intermediate processing steps (preprocessing, filtering, and feature extraction) are executed sequentially by the three defined single-task executors. It is evident that the task chain structure is modular, with each single-task executor responsible for only a specific task, facilitating development and maintenance. Data processing tasks are decomposed into multiple smaller tasks, with each single-task executor focusing on a single function, allowing for optimization and acceleration of that function's execution. The entire task chain executes multiple tasks serially, reducing the overhead of data conversion between different processing stages and improving overall processing efficiency.

[0047] This relates to Task Manager 103, a system used to manage and coordinate individual task executors in a task chain. For example... Figure 1 As shown, the Task Manager is similar to a framework that encapsulates the execution of task chains, and can effectively manage and control the execution of task chains. The Task Manager will be explained further later, and will not be repeated here.

[0048] This disclosure provides a unified seismic data interface, enabling the reading of seismic data in various formats through a single interface. Developers only need to develop algorithms for this unified interface, without having to write different code for each data format. Furthermore, this disclosure utilizes task chains to process seismic data serially and in multiple tasks, significantly improving data processing efficiency. The task chain is managed and organized through a task manager, systematizing the entire seismic data processing workflow and offering advantages such as ease of management and monitoring.

[0049] For example, for the multiple single-task executors in the middle of the task chain, each single-task executor includes a corresponding input executor and at least one corresponding output executor.

[0050] Except for the first and last single-task executors in the task chain, each intermediate single-task executor includes a corresponding input executor. The first single-task executor can be configured with only one output executor; similarly, the last single-task executor can be configured with only one input executor. The input executor is responsible for obtaining data from the previous single-task executor, and the output executor is responsible for passing the processed data to the next single-task executor or storage device.

[0051] Figure 2 This is a schematic diagram of the task chain structure provided in one embodiment of the present disclosure, as shown below. Figure 2As shown, at the beginning of the task chain, the first single-task executor reads seismic data from the data source through the seismic data interface. This seismic data interface is responsible for communicating with the data source and performing data reading operations to ensure that the seismic data is accurately acquired. The read seismic data is then passed to the first-level intermediate single-task executor in the task chain through the output executor of the first single-task executor. After receiving the seismic data, the first-level intermediate single-task executor performs preliminary processing on the data according to the preset processing tasks and parameters. The processed data continues to be passed to the next-level single-task executor through its output executor.

[0052] In the middle stage of the task chain, multiple intermediate single-task executors sequentially receive and process seismic data. Each intermediate single-task executor is equipped with corresponding input and output executors to ensure sequential data transmission. After receiving data from the previous stage, each intermediate single-task executor performs specific processing tasks, such as data cleaning, filtering, transformation, or analysis. The processed data is then passed to the next-level single-task executor via the output executor for further processing. At the end of the task chain, the input executor of the last single-task executor receives the processed seismic data from the last-level intermediate single-task executor. The last single-task executor outputs the data results, and optionally, may perform further final processing, such as integration, summarization, or further analysis. After processing, this single-task executor transmits the final processing result to a storage device via its output executor. The storage device can be a disk, tape, or other suitable storage medium. The last single-task executor is responsible for writing the data to the storage device via the seismic data interface, ensuring the secure storage and effective management of the data processing results.

[0053] Suppose there is a data processing task chain, which includes three single-task executors, Task1, Task2, and Task3, which are responsible for data reading, data cleaning, and data analysis tasks, respectively.

[0054] The input executor of Task 1 reads raw data from the file system, and the output executor passes the read data to the data cleaning task. The input executor of Task 2 receives the output data from the data reading task, and the output executor passes the cleaned data to the data analysis task. The input executor of Task 3 receives the output data from the data cleaning task, and the output executor saves the analysis results to the database or passes them to subsequent processing stages. In each task, the input executor obtains data from the previous task, and the output executor passes the processed data to the next task.

[0055] Each single-task executor in the task chain can independently handle its own task, and can also be closely linked with other tasks through input and output executors to form a complete task processing flow. This clear structure and well-defined functions ensure the efficiency of data processing and the maintainability of the task chain.

[0056] For example, the single-task executor is bound to at least one thread; for any single-task executor, at least one independent thread is enabled to execute the data processing task.

[0057] Each single-task executor is bound to at least one thread, and each single-task executor will occupy at least one thread to complete its work when executing a data processing task. For any given single-task executor, at least one independent thread is used to execute a specific data processing task, which is not shared with other tasks, thus avoiding thread contention and resource disputes. When a single-task executor is initialized, it binds to at least one thread, and the bound thread remains associated with the executor until the task is completed or the executor is destroyed. When executing a data processing task, the single-task executor uses its bound independent thread for processing.

[0058] As in the example above, three single-task executors, Task1, Task2, and Task3, are bound to threads A, B, and C, respectively. Task1, Task2, and Task3 execute data processing tasks through their corresponding and independent threads A, B, and C.

[0059] For example, when new functional requirements are detected, the new functional requirements can be met by adding new single-task executors and / or adjusting the combination of existing single-task executors in the task chain.

[0060] For seismic data processing tasks, the multi-task management system for seismic data processing provided in this disclosure detects new functional requirements in real time. When the system detects the need to add new functions or optimize existing functions during operation, this mechanism is triggered. That is, after detecting new functional requirements, new single-task executors are added to meet these requirements. The newly added single-task executors will be responsible for handling the new functions or tasks, ensuring that the system can handle the new requirements. In addition to adding executors, the combination of existing single-task executors in the task chain can also be adjusted to adapt to new functional requirements. That is, the existing single-task executors are rearranged or configured so that they can work together to handle new requirements.

[0061] Optionally, when the system detects a new functional requirement, it first assesses whether the existing single-task executors can handle the requirement. If not, a new single-task executor is created and added to the task chain. In some cases, the new requirement can be met by reconfiguring the combination of existing single-task executors. The existing task chain is analyzed to identify executors that can be optimized and adjusted, rearranging their working order or changing their working mode. Assuming the existing task chain contains three single-task executors (Task1, Task2, and Task3), the system takes the following actions after detecting a new requirement:

[0062] When a new functional requirement cannot be handled by the existing single-task executor, a new single-task executor, Task4, is added to the task chain. The new task chain can be represented as Task1→Task2→Task3→Task4. Alternatively, the new functional requirement can be met by adjusting the existing combination of single-task executors, such as adjusting the order of single-task executors Task2 and Task3 or changing their working mode. The new task chain can be represented as Task1→Task3→Task2.

[0063] By flexibly adding single-task executors and adjusting task chains, the system ensures timely response and meets new functional requirements. Adding single-task executors allows for rapid functional expansion; adjusting existing combinations of single-task executors enables functional optimization and optimal resource utilization without increasing system complexity. This flexibility enhances the overall system's adaptability and maintainability.

[0064] For example, the task manager is used to control the one-way transmission of the seismic data in the task chain, and to record and publish the progress data returned by each single task executor in the task chain.

[0065] The task manager controls the unidirectional flow of seismic data within the task chain, ensuring that data is transferred from one single-task executor to the next. This orderly and non-reverse data flow guarantees the continuity and consistency of data processing. In the task chain, each single-task executor processes the received seismic data and passes the processed data to the next executor. The task manager controls this transfer process, ensuring that data can only flow forward and does not return to the previous executor, avoiding loops or repetitions in data processing that could lead to unnecessary or erroneous multiple processing steps.

[0066] Meanwhile, the task manager is responsible for recording the progress data of each individual task executor in the task chain. Optionally, this includes information such as the status, completion rate, and timestamp of each individual task executor while processing seismic data. This ensures that the task manager can track the entire data processing process and understand the working status and progress of each executor. The task manager not only records progress data but is also responsible for publishing this data. Published progress data can be used for real-time monitoring, system logging, or feedback to users and other system components. By publishing progress data, a transparent processing procedure is provided, allowing all parties to understand the current working status and data processing progress.

[0067] For example, after receiving the execution instruction to execute the data processing task, the single-task executor transfers the data processing task to any bound thread for execution, and sends a task completion notification to the task manager after execution is completed.

[0068] When a task node is routed to a single-task executor, the task manager sends specific processing instructions to that executor. The single-task executor then assigns the received data processing task to at least one independent thread it is bound to. Within that thread, the data processing task begins execution. The thread is responsible for specific calculations, processing, and analysis operations, completing data processing according to the specific requirements of the task. During execution, the thread can access and manipulate the necessary data resources, performing necessary processing steps until the task is completed. Upon completion of the data processing task, the thread notifies the single-task executor. Subsequently, the single-task executor sends a task completion notification to the task manager, containing necessary information such as the task's status and results, informing the task manager that the task has been completed. Sending the task completion notification ensures that the task manager can update the task progress in a timely manner and perform subsequent task scheduling and data transfer. Maintaining the task manager's real-time control over the task status improves the system's processing and task management effectiveness.

[0069] For example, the single-task executor implements its functionality based on a single-task executor base class; the single-task executor base class is configured with a first type of interface, a task execution signal, a task execution slot function, and a task completion signal; the first type of interface is the only interface through which derived class functions implement task execution logic; the task execution slot function is bound to the task execution signal so that the single-task executor executes the corresponding data processing task after receiving the task execution signal; the task completion signal is used to send a notification to the task manager when the data processing task is completed.

[0070] In this embodiment of the disclosure, the single-task executor is configured with a first type of interface, a task execution signal, a task execution slot function, and a task completion signal.

[0071] Single-task executors are derived from and implemented using a base class. They inherit the base class's attributes and methods and implement specific functionalities based on them. The first type of interface is the sole interface through which derived class functions implement task execution logic; any class derived from the single-task executor base class must implement its task execution logic through this interface. For example, if a single-task executor derived class needs to handle data analysis tasks, it will implement specific data analysis methods in the first type of interface.

[0072] As mentioned earlier, when a task node flows to a single-task executor, the task manager sends specific task processing instructions to that executor. Optionally, these instructions can appear as task processing signals, serving as a trigger mechanism to instruct the single-task executor to begin task execution. In the base class constructor, the task execution slot function is bound to the task execution signal, ensuring that the slot function is invoked upon receiving the signal. The task execution slot function then further calls the first-class interface implemented by the derived class to execute the specific data processing task.

[0073] The task completion signal is used to notify the task manager that the task has been completed and can proceed with the subsequent task flow. Upon receiving the task completion signal, the task manager can update the task status, record the results, and start the next single-task executor.

[0074] For example, the task manager is further configured to: divide the seismic data processing task into multiple subtasks; create a task manager base class, specify the same number of threads and single-task executors according to the number of subtasks, and implement the function based on the task manager base class; bind the threads and single-task executors one by one; and allocate a corresponding single-task executor from the task manager object for each subtask.

[0075] The Task Manager implements its specific functions by creating a base class, which is the foundation for the Task Manager's functionality and provides the necessary structure and methods.

[0076] The Task Manager is responsible for dividing seismic data processing tasks into multiple subtasks. This breaks down a large, complex seismic data processing task into smaller, more manageable subtasks, thereby improving processing efficiency and controllability.

[0077] Based on the number of subtasks, the task manager base class will specify the same number of threads and single-task executors, and bind them one by one. Each subtask has a dedicated thread and single-task executor to handle it, avoiding resource contention and improving serial processing capabilities.

[0078] The Task Manager object is responsible for assigning a corresponding single-task executor to each subtask. Specifically, the Task Manager selects and assigns a single-task executor to each subtask from its managed pool of single-task executors, ensuring that each subtask can be processed, thereby effectively utilizing system resources.

[0079] For the task manager, the seismic data processing task is first divided into multiple subtasks. Then, a task manager base class is created. Next, the same number of threads and single-task executors are specified according to the number of subtasks, and the threads and single-task executors are bound one by one. Finally, a corresponding single-task executor is assigned to each subtask.

[0080] Through the above mechanism, the task manager can efficiently and reliably manage and schedule seismic data processing tasks, ensuring that each subtask is processed in a timely manner and maximizing the utilization of system resources.

[0081] For example, the task manager base class is configured with a second type of interface, an initialization function, and a task execution progress signal; the second type of interface is used to create a single-task executor base class; the initialization function is used to bind threads and single-task executors one by one; the task execution progress signal is used to indicate that any single-task executor has completed its respective data processing task.

[0082] The Task Manager base class is configured with the following key components: a second-class interface, an initialization function, and task execution progress signals. The main function of the second-class interface is to create single-task executor base classes. Through this interface, the Task Manager base class can dynamically generate multiple single-task executor base classes, thereby providing the necessary executor for each subtask.

[0083] The purpose of the initialization function is to bind each thread to a single-task executor. In the task manager base class, calling the initialization function ensures that each thread is bound to a single-task executor, thus enabling each subtask to be correctly assigned and processed.

[0084] The task execution progress signal is used to characterize the completion status of each individual task executor for its respective data processing task. Through the task execution progress signal, the system can monitor the task completion status of each individual task executor in real time, which helps to track and manage task execution progress and ensure that all subtasks are completed as planned.

[0085] For example, the task manager is also used to specify individual task execution parameters for each subtask, including: creating a parameter object for each subtask; and writing the specified task execution parameters into the respective parameter object.

[0086] The Task Manager is also responsible for specifying individual task execution parameters for each subtask, used to guide and control its execution. Specifically, for each subtask, the Task Manager creates a dedicated parameter object. Each parameter object corresponds to a subtask, and each subtask has its own independent set of parameters. The Task Manager writes the specified task execution parameters into its respective parameter object. These execution parameters include, but are not limited to, the subtask's specific execution requirements, resource configuration, priority, and other information. By writing parameters into the parameter objects, the Task Manager can flexibly adjust and manage the execution of each subtask.

[0087] For example, one embodiment of this disclosure relates to implementing a general framework for a multi-task management system for seismic data processing using the C++ programming language and Qt's signal-slot mechanism. This is achieved by defining a base class for task execution parameters (CTaskParam), a base class for single-task executors (CTaskExecutor), and a base class for task managers (CTaskController). Developers can use these classes to implement multi-task management for seismic data processing. The following is a detailed description of the steps:

[0088] The base class CTaskParam for task execution parameters does not contain any concrete parameters. During application development, a derived class of CTaskParam needs to be defined, and the task execution parameters should be defined as its member variables. When calling the task execution function of the task executor, an instance of this derived class needs to be created, the parameters stored in this instance, and then the instance is passed as a parameter to the task execution function.

[0089] The base class CTaskExecutor for single-task executors contains the following components: the virtual interface Execute(CTaskParamp)*, the task execution signal sig_Execute(CTaskParam p)*, the task execution slot function slot_Execute(CTaskParam p)*, and the task completion signal sig_ExecuteComplate(CTaskExecutor e)*.

[0090] This involves the virtual interface Execute(CTaskParam p)*, which is the first type of interface. Derived classes must implement this interface and call the actual task execution code within it.

[0091] The task execution signal sig_Execute(CTaskParam p)* is involved. When a task needs to be executed, the application developer sends this signal. In the constructor of the single-task executor base class, the sig_Execute signal is bound to the task execution slot function slot_Execute(CTaskParam p)*. When the main thread sends the sig_Execute signal, slot_Execute will be executed asynchronously in the thread bound to the single-task executor base class.

[0092] The operations involving the slot_Execute function are as follows: First, the virtual interface function Execute(CTaskParam*p) is called to execute the actual task; second, after the Execute function returns, a task completion signal is sent to notify the task manager.

[0093] The task manager base class CTaskController contains the following components: the virtual interface createTaskExecutor(), the initialization function init(int threadCount, int taskNum), and the task execution progress signal sig_ExecuteCount(int count).

[0094] This involves the virtual interface `createTaskExecutor()`, also known as the second type of interface. Derived classes must implement this interface, which returns a pointer to a `CTaskExecutor` object. Derived classes can override this interface to create and return an object of a derived class of the task manager base class.

[0095] The initialization function `init(int threadCount, int taskNum)` is involved. This function takes the number of threads and the actual number of tasks to be executed as parameters, creates a number of thread objects equal to `threadCount` and a single-task executor base class object (created by calling the `createTaskExecutor` interface to create `CTaskExecutor` objects), and binds each `CTaskExecutor` object to a thread object.

[0096] The Task Manager base class is also configured with a task completion slot function slot_ExecuteComplate(CTaskExecutor e)*, which is used to receive the sig_ExecuteComplate signal sent by the CTaskExecutor object after the task is completed.

[0097] The task execution progress signal sig_ExecuteCount(int count) is involved. This signal is sent once after each subtask is completed. It can be bound to a progress bar to display the progress.

[0098] Optionally, developers can use this management framework by following these steps:

[0099] Step S1: Define a derived class CTaskParamImp of CTaskParam, and define the actual task execution parameters in it.

[0100] Step S2: Define a derived class CTaskExecutorImp of CTaskExecutor, override the Execute(CTaskParam*p) interface function, and implement or call the actual task execution code in it.

[0101] Step S3: Define a derived class CTaskControllorImp of CTaskControllor, override the createTaskExecutor interface function, create a CTaskExecutorImp object and return it.

[0102] Step S4: Create a thread object controllerthread, create a CTaskControllorImp object controller, and move the controller into the thread controllerthread so that the controller can receive and process messages in a separate thread, avoiding interference with the main thread.

[0103] Step S5: Divide the seismic data processing task to be executed into several independently running subtasks, define the task execution parameters for each subtask, and bind the controller's sig_ExecuteCount signal to the progress display interface of the interface progress display object to display the task completion progress in real time.

[0104] Figure 3 This is a schematic diagram of the main process of seismic data processing provided in one embodiment of the present disclosure, as shown below. Figure 3 As shown, the main process includes seismic data interface initialization, task manager configuration, task chain creation, task management, task execution, and data processing. This disclosure implements it as follows:

[0105] This involves initializing the seismic data interface, configuring its connection parameters, and ensuring correct connections to the data source and target storage device. It also verifies the interface functionality to ensure normal data read and write operations. Ultimately, it ensures the interface provides a unified function for reading and writing seismic data.

[0106] This involves configuring and initializing the task manager, which is used to manage the entire task chain. Specifically, this includes setting the task manager's control parameters to control the unidirectional transmission of seismic data within the task chain. It also involves configuring the task manager to record and publish progress data returned by each individual task executor, ensuring the execution status of the task chain is transparent and monitorable.

[0107] The task chain creation involves configuring the first single-task executor to read seismic data through the seismic data interface; configuring multiple intermediate single-task executors to execute different data processing tasks; and configuring the last single-task executor to write the data processing results to the storage device.

[0108] This involves configuring task executors, ensuring each single-task executor is bound to at least one thread to guarantee the independence of data processing task execution. Specifically, this includes allocating thread resources to each single-task executor to ensure data processing tasks execute in independent threads; and meeting new functional requirements by adding new single-task executors or adjusting the combination of existing single-task executors in the task chain when new functional requirements are detected.

[0109] This involves task management, dividing seismic data processing tasks into multiple subtasks and creating corresponding single-task executors and threads. Specifically, this includes implementing functionality based on a task manager base class, creating a single-task executor base class through a second type of interface; using initialization functions to bind threads and single-task executors one-to-one, ensuring that each subtask executes in an independent thread; specifying individual task execution parameters for each subtask and writing these parameters into their respective parameter objects to ensure the accuracy and independence of task execution.

[0110] Regarding task execution, after receiving an instruction to execute a data processing task, the single-task executor transfers the data processing task to its bound thread for execution. Specifically, upon receiving the task instruction, the single-task executor starts the corresponding thread to begin the data processing task; after the data processing task is completed, the single-task executor sends a task completion notification to the task manager; the task manager base class is configured with task execution progress signals to indicate the real-time execution status of each single-task executor for its respective data processing task.

[0111] Involving data processing, within the task chain, each individual task executor cooperates with its corresponding input and output executors to complete data reading, processing, and transmission. Specifically, data flows unidirectionally within the task chain, from the first individual task executor to the last, sequentially completing each processing task; each individual task executor performs corresponding data processing operations according to its configured task execution parameters.

[0112] Regarding result storage, the last single-task executor is responsible for writing the processed data to a storage device (such as a disk or tape) through the seismic data interface.

[0113] Although preferred embodiments of the present disclosure have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present disclosure. Finally, it should be noted that in the description of this specification, the reference to terms such as "some embodiments," "in one example," "exemplarily," etc., means that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples. Any process or method described in the flowcharts or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. The scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved, as will be understood by those skilled in the art to which the embodiments of this application pertain. Although embodiments of this application have been shown and described above, it is to be understood that the above embodiments are optional and should not be construed as limiting the application. Those skilled in the art can make variations, modifications, substitutions, and alterations to the above embodiments within the scope of this application.

Claims

1. A multitasking management system for seismic data processing, characterized by, The system comprises: a seismic data interface for providing an interface for a single-task executor to read seismic data in different data formats; a task chain comprising a plurality of single-task executors connected in series, wherein the first single-task executor reads seismic data through the seismic data interface, the last single-task executor writes data processing results into a storage device, and the plurality of single-task executors in between are used to perform different data processing tasks; a task manager for managing the task chain.

2. The system of claim 1, wherein, For the plurality of single-task executors in the task chain, each single-task executor comprises a corresponding input executor and at least one corresponding output executor.

3. The system of claim 1, wherein, The single-task executor is bound to at least one thread; for any single-task executor, at least one independent thread is enabled to perform a data processing task.

4. The system of claim 1, wherein, In the case of detecting a new functional requirement, a new single-task executor is added and / or the combination mode of the original single-task executors in the task chain is adjusted to meet the new functional requirement.

5. The system of claim 1, wherein, The task manager is used to control the one-way transmission of the seismic data in the task chain, and record and publish the progress data returned by each single-task executor in the task chain.

6. The system of claim 3, wherein, After receiving an execution instruction for a data processing task, the single-task executor transfers the data processing task to any bound thread for execution, and sends a task completion notification to the task manager after execution is completed.

7. The system of claim 6, wherein, The single-task executor realizes functions based on a single-task executor base class; the single-task executor base class is configured with a first type of interface, a task execution signal, a task execution slot function, and a task completion signal; The first type of interface is the only interface for the derived class function to implement task execution logic; The task execution slot function is bound to the task execution signal, so that the single-task executor executes the corresponding data processing task after receiving the task execution signal; The task completion signal is used to send a notification to the task manager when the data processing task is completed.

8. The system of claim 1, wherein, The task manager is also used to: divide a seismic data processing task into a plurality of subtasks; create a task manager base class, specify the same number of threads and single-task executors according to the number of subtasks, and the task manager realizes functions based on the task manager base class; bind the threads and single-task executors one by one; allocate a corresponding single-task executor to each subtask from the task manager object.

9. The system of claim 8, wherein, The task manager base class is configured with a second type of interface, an initialization function, and a task execution progress signal; The second type of interface is used to create a single-task executor base class; The initialization function is used to bind the threads and single-task executors one by one; The task execution progress signal is used to indicate that any single-task executor has completed its respective data processing task.

10. The system of claim 8, wherein, The task manager is also used to specify respective task execution parameters for each subtask, including: for each subtask, creating a respective parameter object; and writing the specified task execution parameters into the respective parameter object.

Images