A real-time storage method for multi-process dynamic data for fusion steady-state operation
A client-server shared memory system addresses the memory challenges in nuclear fusion data archiving by enabling real-time storage and viewing of dynamic data during long-pulse operations, stabilizing data management and reducing memory demands.
Patent Information
- Application Number
- CN202410212084.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-02-27
- Publication Date
- 2024-12-27
- Estimated Expiration
- 2044-02-27
AI Technical Summary
Current data archiving methods for nuclear fusion experiments, particularly in tokamak devices, are inadequate for long-pulse steady-state operations due to high memory demands, leading to pressure on memory resources and unsuitable for stable, real-time data storage and analysis.
A client-server architecture utilizing a shared memory system for real-time data storage, where clients monitor algorithm changes and move data to shared memory before the end of the operation cycle, and servers periodically segment and store data in a database, decoupling discharge duration from memory requirements.
Enables real-time storage and viewing of multi-process dynamic data during nuclear fusion long pulses, reducing memory pressure and allowing stable, efficient data management during extended discharge periods.
Smart Images
Figure CN118093587B_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the field of nuclear fusion Toca plasma control systems, and in particular relates to a multi-process dynamic data real-time storage method for fusion steady-state operation. Background Art
[0002] The tokamak device plasmatizes fusion materials through magnetic confinement, establishes plasma, and heats the plasma to a certain high temperature so that it is close enough to cause nuclear fusion reactions and release nuclear fusion energy. During the experiment, a very important parameter for studying plasma characteristics is plasma density. The plasma density obtained by measurement is required to remain stable and last for a long time during the tokamak discharge experiment, especially under high density conditions. It is also required to be able to reach a higher density more stably, especially during the discharge process of the EAST device, the real-time data generated during the discharge process needs to be stored in the database, including real-time collected data, calculated intermediate process data, and command data for output. These data provide valuable resources for fusion research. Technicians can explore new research directions for fusion through analysis and comparison of historical data, deepen their understanding of nuclear fusion, and promote the progress of nuclear fusion research.
[0003] The current data archiving method is to "accumulate" the data in the memory during the discharge process, and then store all the data in the database at once after the discharge is completed. The memory for storing all the data is pre-allocated before discharge, and the memory demand increases with the longer the discharge time and the more algorithms that generate data. This method puts great pressure on the memory during long-pulse steady-state discharge and is not suitable for long-pulse steady-state discharge. Summary of the invention
[0004] The purpose of the present invention is to provide a real-time storage method for multi-process dynamic data of steady-state operation of fusion, to realize a real-time storage scheme for multi-process dynamic data of steady-state operation of nuclear fusion long pulse, to realize real-time storage of data during steady-state operation of nuclear fusion long pulse; at the same time, to realize real-time viewing of data during steady-state operation of nuclear fusion long pulse; and to decouple the relationship between discharge duration and memory requirements.
[0005] To achieve the above object, the present invention proposes a multi-process dynamic data real-time storage method for fusion steady-state operation, comprising the following method steps:
[0006] S1. Deploy a server for archiving data to the database, and deploy a client in each process that requires data storage service;
[0007] S2. The client monitors the algorithm entry or exit changes of the system in real time and updates the data list of the data to be stored;
[0008] S3, before the end of the operation cycle, the real-time data is "moved" to the shared memory according to the data list for retention;
[0009] S4. The server periodically segments and organizes the data in the shared memory and stores them in the database.
[0010] Optionally, the database in S4 is the MDSPlus database.
[0011] Optionally, the steps for constructing the MDSPlus database are as follows:
[0012] 1) In the plasma control system configuration stage, first create a data template in MDsplus;
[0013] 2) Before a new discharge, the plasma control system creates a new data tree with the gun number as the name according to the data template;
[0014] 3) During the discharge process, the data is stored in the data tree in real time.
[0015] Optionally, the shared memory in S3 includes data information coexistence and data value coexistence. A multi-cache dynamic shared memory structure design is designed, which includes a shared memory subspace Area for storing data information of each algorithm and multiple shared memory cache Buffers for storing real-time data values, and uses Header to record the running algorithm to establish the corresponding relationship between the data information in the Area and the data value in the Buffer. The specific design is as follows:
[0016] The shared memory structure is designed for the following reasons: First, the client copies the data item value from the data engine to the shared memory one by one. If the number of data items is very large, the client's execution is also very time-consuming. Second, although the data item information is only transmitted in the first cycle after the algorithm is switched, the client will still have a large time overhead in this cycle, affecting the stability of system control. In response to the above risks, the data engine adopts the design of data grouping memory block (Block) after considering similar requirements for real-time data archiving, that is, related data (same algorithm, same memory type, same category) are allocated to the same continuous memory, increasing the granularity of data transmission. In this way, the client can "move" the data "in blocks" from the data engine to the shared memory, solving the time-consuming problem of the client in the case of large data volume. On this basis, real-time data archiving establishes the link relationship (Alg-Block-Data) between the algorithm algorithm (Alg) and the data block Block in the algorithm, as well as the data block and the data item (Data) contained therein, and writes the link relationship information (Alg Blocks List, Block Data List) into the shared memory in the non-real-time stage before the discharge starts after the system is started.
[0017] See also Figure 3 The list of algorithms to be run by the component is deployed in the Header area, and the data value of each cycle is stored in the Buffer. During the discharge process, in the first cycle after the algorithm is switched, the client only needs to write the name of the switched algorithm into the shared memory Header. In subsequent operation cycles, the client copies data from the data engine to the Buffer in units of Block memory blocks according to the Alg-Block-Data list, reducing the number of data copies and improving execution efficiency. After the Buffer is full, the server establishes a correspondence between the data items and data information in the Buffer Slice based on the algorithm name and link relationship information, reads and organizes the data, and stores the data in the MDSplus database.
[0018] The entry or exit of the algorithm is realized through the external interface of the component service in the system architecture. The client subscribes to the init and exit events of the algorithm to add or delete the algorithm from the real-time storage data algorithm list. At the same time, the algorithm to which the data belongs is obtained by combining the registered name (ALG.TYPE.NAME) of the real-time data in the data engine to decide whether the data is stored. Finally, the storage data list follows the dynamic changes of the actual operation algorithm of the plasma to meet the needs of dynamic data storage.
[0019] Multi-buffer shared memory manages buffers in a queue manner during use. Buffers in the queue are accessed in a first-in-first-out (FIFO) order. The basic operations of the queue include enqueue and dequeue. The client will
[0020] To sum up, the final shared memory structure design is as follows Figure 2 As shown in the figure, the multi-buffer shared memory area for transmitting data is divided into two parts. One part is the buffer area for storing data values. The number of buffer areas can be customized in the code. The figure takes three buffers A, B, and C as an example. The other part is the header area for recording storage information, which contains buffer management control quantity and buffer information item pool info. Pool info records the algorithm name to which the data in the buffer belongs, and is used to find the area for recording algorithm data items from the shared memory, as well as information such as the number of algorithms and the number of data slices.
[0021] Optionally, the deployment of the pre-discharge data information in the memory is as follows:
[0022] In the non-real-time stage after the system is started and before the discharge begins, the data information of the CoilCurrent algorithm is collected and pre-stored in the specified subspace Area of the shared memory. The order of the data information must be guaranteed to be consistent with the order in which the data is arranged in the data engine memory; during the discharge process, after the client monitors that the algorithm has switched to the CoilCurrent algorithm, the name of the shared memory space Area where the CoilCurrent algorithm data information is stored is transmitted to the server.
[0023] Optionally, the data values coexist during the discharge process, specifically as follows:
[0024] Using a multi-cache shared memory method, the client and server agree on the data organization structure in advance and divide the memory into two or more cache areas Buffer. During operation, the client writes data to one cache (Buffer 1), and the server reads data from another cache (Buffer 2) and stores it in the database. The Header area is opened for concurrency control.
[0025] Optionally, the multi-buffer shared memory mode implements buffer management in a queue manner, as follows:
[0026] The buffers in the queue are accessed in the order of first-in-first-out (FIFO). The basic operations of the queue include enqueue and dequeue. The client adds the full buffer to the end of the queue, and the server obtains the buffer from the head of the queue and reads its data, thereby realizing sequential data transmission and concurrency control.
[0027] Optionally, the client in S2 monitors the entry and exit of the algorithm in real time to dynamically update the shared memory data structure.
[0028] Optionally, the S3 stores the algorithm data in a shared memory in real time by each client end, and the specific steps are as follows:
[0029] S41, system startup phase: Archive client statistics engine information is stored to prepare for the subsequent real-time data storage; first traverse all data item management containers in the system - data engines, and store all data information of each algorithm in the shared memory subspace Area;
[0030] S42, during the discharge process: the client first monitors whether there is an algorithm entering or exiting to update the algorithm list information in the shared memory Header. The client copies the data generated by the currently running algorithm in this cycle from the data engine to the shared memory Buffer;
[0031] S43, after the discharge is completed: the client needs to queue the unfilled cache Buffer and set the archive end flag.
[0032] Optionally, the S4 obtains data information and data values from the server, sorts the data in the shared memory Buffer according to time and stores them in the database to achieve data archiving.
[0033] Compared with the prior art, the present invention has the following beneficial effects:
[0034] The present invention adopts a client-server mode and designs management and organization of data based on a shared memory, thereby realizing a real-time storage solution for multi-process dynamic data of nuclear fusion long pulse steady-state operation, and realizing real-time storage of data during the nuclear fusion long pulse steady-state operation; at the same time, it realizes real-time viewing of data during the nuclear fusion long pulse steady-state operation; and decouples the relationship between discharge duration and memory requirements. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 It is a schematic diagram of the data storage structure of the present invention;
[0036] Figure 2 It is a schematic diagram of the structure of shared memory;
[0037] Figure 3 A schematic diagram of the structure of shared memory for real-time data archiving;
[0038] Figure 4 It is a flow chart of real-time data archiving service;
[0039] Figure 5 This is a schematic diagram of data storage client deployment;
[0040] Figure 6 It is a schematic diagram of the interface during data discharge;
[0041] Figure 7 This is a schematic diagram of the plasma current data storage results in the pcftree database during the 1.4061-1.4067 period in the 128990 experimental gun;
[0042] Figure 8 The data visualization tool EASTViewer shows the plasma profile of the 129010 gun at 4.988 seconds;
[0043] Fig. 9 It is a schematic diagram of dynamic data storage;
[0044] Fig.10 This is a schematic diagram of the maximum time consumed by the client in all cycles of each experimental cannon;
[0045] Fig.11 This is a schematic diagram of the 24-hour simulated discharge data storage results. DETAILED DESCRIPTION
[0046] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0047] See also Figure 1-Figure 7 As shown, in this embodiment, a multi-process dynamic data real-time storage method for fusion steady-state operation is implemented in sequence by the following steps:
[0048] Step 1: Deploy a server for archiving data to the database, and deploy a client in each process that requires data storage service;
[0049] Step 2: The client monitors the algorithm entry or exit changes of the system in real time and updates the list of data to be stored;
[0050] Step 3: Before the end of the operation cycle, the real-time data is "moved" to the shared memory according to the data list for storage;
[0051] Step 4: The server periodically segments and organizes the data in the shared memory and stores them in the database;
[0052] In the process of real-time data storage task deployment, the client is deployed on the real-time computing process with data storage requirements, and is implemented as a real-time component. The server provides services according to data storage requirements and archives data only when the Buffer (shared memory buffer) is full. Therefore, the server runs on demand and is implemented as a non-real-time component.
[0053] Real-time data storage To ensure the real-time performance of the client process during the discharge process, the client will deploy as many tasks as possible before discharge. The specific steps are as follows:
[0054] 1. System startup phase: Archive client collects data engine information to prepare for real-time data storage later; first traverse all data item management containers in the system - data engines, and store all data information of each algorithm in the shared memory subspace Area;
[0055] 2. During the discharge process: the client first monitors whether there is an algorithm entering or exiting to update the algorithm list information in the shared memory Header (shared memory control block). The client copies the data generated by the currently running algorithm in this cycle from the data engine to the shared memory Buffer;
[0056] 3. After the discharge is completed: the client needs to queue the unfilled cache Buffer and set the archive data archiving end flag.
[0057] like Figure 3 As shown in the figure, the client and the server store data through shared memory and coordinate to achieve real-time data storage. Considering that real-time data storage needs to serve multiple processes, in order to prevent interference between processes and avoid data corruption, the shared memory is designed to allocate a separate shared memory for each client to retain real-time memory data, and the server is equipped with a dedicated service thread for each shared memory to organize and store the shared memory data. Each thread is not directly associated with the client. In this way, while decoupling the client and the server, the storage speed is improved in a multi-threaded concurrent manner to ensure data security.
[0058] The database is the MDSPlus database.
[0059] The steps to construct the MDSPlus database are as follows:
[0060] The data model of MDSplus is based on a tree structure, and each node can contain one or more data items. Each node has a name and a data type, which can be a scalar, array, or other complex data type. The name of the node can be any descriptive string for easy identification and management. During the system configuration phase of the plasma control system, a data template is first created in MDsplus. The data template is represented by a tree structure to define the type, structure, and format of the node. Before a new discharge, the plasma control system creates a new data tree named after the gun number based on the data template. During the discharge process, the data is stored in real time in the data tree. At the same time, researchers can use the MDSPlus interface or secondary development visualization tools (such as EAST's UDAclient) to access and analyze the data.
[0061] For long pulse storage of plasma control systems, MDSplus supports segmented data storage, that is, data does not need to be written or read all at once, and long pulse data can be stored by time period.
[0062] The Archive server is used to obtain data information, obtain data values, and archive data.
[0063] 1) Get data information: Buffer stores only the data value. To achieve data storage, we need to get the node name of the data in the database, the data type and other information. The Archive server combines the algorithm name list recorded by the Archive client in the header and the algorithm data information written to the shared memory by the client during the system startup phase to generate a data-node map corresponding to the data and data information stored in the Buffer, such as Figure 2 .
[0064] 2) Get data value: The client writes periodically generated data slices into continuous shared memory. There is only one data item in a data slice. When storing in the database, it is necessary to extract a data item from all data slices in a buffer to form a data group for storage.
[0065] 3) Data archiving: After the Archive server receives the shot number before the discharge begins, it creates a tree storage structure based on the shot number. During the discharge process, MDSplus provides a long pulse segment storage interface makeSegment() to store the data segments divided by time into shared memory.
[0066] 1. System deployment phase: Deploy data storage client components in each real-time process, such as Figure 5 ,During the system startup phase, data storage related components are started along with the system;
[0067] 2. During the EAST discharge process, the data storage module is used for real-time data storage. The data storage module must complete the 16 real-time calculation processes in Table 1 and store data in two MDSPlus databases. The PEFIT process data is stored in the pefitrt_east database, and the remaining process data is stored in the pcftree database.
[0068] Real-time data storage supports real-time viewing of data during the discharge process.
[0069]
[0070]
[0071] Table 1
[0072] like Figure 6 During the discharge of the 128136 gun in July 2023, the right tracking system can view the experimental data, while the left EAST PCS cannot display the data because the discharge has not ended and the data has not been archived. Real-time data viewing during the discharge process can be realized to analyze the data while performing the experiment, so as to better formulate the discharge plan for the next time period. This is an essential function for the future steady-state operation discharge duration in hours or days.
[0073] 3. View the stored data and analyze the stored results after the EAST device is discharged.
[0074] Basic functions of data storage
[0075] Figure 7 The red line in the middle is the plasma current data storage results in the pcftree database during the 1.4061-1.4067 period in the 128990 experimental shot. The signal is one-dimensional data. Figure 7 In the process, the DAQ acquisition process acquires data. The operation cycle of DAQ is 50 microseconds, which is the fastest process in the plasma control system. Figure 7 It can be seen that the data point appears every 50 microseconds, and the real-time data storage ensures full data preservation.
[0076] Figure 8The data visualization tool EASTViewer shows the plasma profile of 129010 shots for 4.988 seconds. The dotted lines in the red area are equal magnetic flux lines, which are lines formed by connecting grid points with the same magnetic field by dividing the profile into 33×33 grids. The data format is a 33×33 two-dimensional array in the data. The blue line is the plasma boundary, which is connected by 99 coordinate points. The data format in the database is 99×2 two-dimensional data. The plasma profile is successfully displayed, which shows the effectiveness of multi-dimensional data storage. The plasma configuration description at each moment is the presentation of the storage results of multiple sets of two-dimensional data of the plasma boundary in the pefitrt database displayed by EAST.
[0077] Dynamic Data Storage
[0078] like Fig. 9 The data items stored in the data store change dynamically as the algorithm enters or exits. For example, the plasma shape control item shape executes the coil current control algorithm CoilCurrent algorithm in the plasma establishment and climbing stage between -9 seconds and 0.2 seconds, and executes the limit algorithm in the plasma flat top stage between 0.2 seconds and 12 seconds.
[0079] like Fig. 9 After the control item shape exits at 0.2 seconds, the coil current target value cctpf1 data item of the CoilCurrent algorithm also stops archiving, and the current target value lmtipref data item related to the limited algorithm starts archiving. This shows the effectiveness of real-time data storage in responding to dynamic changes in data items.
[0080] Real-time analysis
[0081] The real-time data storage client is essentially an ordinary real-time component, and its function is to store data for other real-time components in the computing process. The client has been designed to place tasks such as data sorting in the non-real-time stage as much as possible to reduce the impact of real-time data storage in the discharge process on the real-time performance of the process. The experimental data of 100 guns in this round were selected to conduct a statistical analysis of the time consumption of the daq process data storage client (the amount of daq data is medium-to-high among all processes in the control system, and data to be stored is generated in each cycle).
[0082] Fig.10 It is the maximum time consumed by the client in all cycles of each experimental gun. From the figure, we can see that its maximum time consumption is less than 10 microseconds. Both indicators are much smaller than the preset control cycle value of DAQ (50 microseconds), leaving enough time for the real-time algorithm logic to run, and the real-time data storage client has good real-time performance.
[0083] 4. If Fig.11 As shown, Fig.11 Figures a, b and c in the middle show the data storage results for one hour at the beginning, middle and end of discharge. The test shows that the data storage can complete the storage of 24 hours of discharge data, and the data storage is stable and reliable.
[0084] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A method for real-time storage of multi-process dynamic data for steady-state fusion operation, characterized in that: The method includes the following steps: S1. Deploy a server for archiving data to the database, and deploy a client in each process that requires data storage service; S2. The client monitors the algorithm entry or exit changes of the system in real time and updates the list of data to be stored; S3. Before the end of the operation cycle, the real-time data is moved to the shared memory according to the data list for storage; The shared memory in S3 uses a multi-cache structure to store data, and uses a shared memory subspace Area to store algorithm data information, and realizes the corresponding relationship between data value and data information through a shared memory Header; The pre-discharge data information is pre-deployed in the memory as follows: In the non-real-time stage after the system is started and before the discharge begins, the data information of the CoilCurrent algorithm is collected and pre-stored in the specified subspace Area of the shared memory. The order of the data information must be guaranteed to be consistent with the order of the data in the data engine memory. During the discharge process, after the client monitors that the algorithm has switched to the CoilCurrent algorithm, the name of the shared memory space Area storing the CoilCurrent algorithm data information is transmitted to the server. During the discharge process, the data values are stored in the memory in real time, as follows: Using a multi-cache shared memory method, the client and the server agree on the data organization structure in advance, and also divide the memory into two or more buffer areas. During operation, the client writes data to one buffer, and the server reads data from another buffer and stores it in the database. In the multi-buffer shared memory structure, the management and concurrency control of multi-buffer buffers are implemented in a queue manner, as follows: The cache buffer in the queue is accessed in the first-in-first-out order. The operations of the queue include enqueue and dequeue. The client adds the full cache buffer to the end of the queue, and the server obtains the cache buffer from the head of the queue to read its data, so as to realize the sequential transmission of data and concurrency control; Each client stores the algorithm data in shared memory in real time. The specific steps are as follows: S41, system startup phase: the client collects data engine information to prepare for the subsequent real-time data storage; first, all data engines in the system are traversed, and all data information of each algorithm is stored in the shared memory subspace Area; S42, during the discharge process: the client first monitors whether there is an algorithm entering or exiting to update the algorithm list information in the shared memory Header. The client copies the data generated by the currently running algorithm in this cycle from the data engine to the shared memory Buffer; S43, after the discharge is completed: the client needs to queue the unfilled cache Buffer and set the archive end flag; S4. The server periodically segments and organizes the data in the shared memory and stores them in the database.
2. A multi-process dynamic data real-time storage method for fusion steady-state operation according to claim 1, characterized in that: The database in S4 is the MDSPlus database.
3. A multi-process dynamic data real-time storage method for fusion steady-state operation according to claim 2, characterized in that: The steps for constructing the MDSPlus database are as follows: 1) In the plasma control system configuration stage, first create a data template in MDsplus; 2) Before a new discharge, the plasma control system creates a new data tree with the gun number as the name according to the data template; 3) During the discharge process, the data is stored in the data tree in real time.
4. A multi-process dynamic data real-time storage method for fusion steady-state operation according to claim 1, characterized in that: The client in S2 monitors the entry and exit of the algorithm in real time to dynamically update the shared memory data structure.
5. The method for real-time storage of multi-process dynamic data for fusion steady-state operation according to claim 1, characterized in that: The S4 obtains data information and data values from the server, sorts the data in the shared memory Buffer according to time and stores it in the database to achieve data archiving.