Virtual beamline software platform for advanced synchrotron light source

Abstract

The application discloses a virtual beamline software platform for an advanced synchrotron radiation light source, and belongs to the fields of synchrotron radiation experiment simulation, control technology and data processing. The platform adopts a three-layer architecture of a user interaction layer, a virtual device layer and a data management layer, and supports two working modes of full simulation experiment based on a physical model and data reproduction based on a historical data set. The core lies in that the physical device is abstracted into a virtual instance conforming to the EPICS standard through the virtual device layer, seamless compatibility with real control code is realized, the user interaction layer is based on the Bluesky framework to arrange an experiment process, and the data management layer adopts block reading and memory mapping technology to optimize the access efficiency of massive scientific data. The application solves the experiment process fault caused by the fragmentation of an existing tool chain, realizes full-process high-fidelity virtualization from experiment design, device control to data acquisition and analysis, and provides a unified software environment for construction, debugging and operation optimization of the synchrotron radiation light source.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of synchrotron radiation experiment simulation, control technology and data processing, and particularly relates to a virtual beamline software platform for advanced synchrotron light source. BACKGROUND

[0002] As an important platform for frontier scientific research, the design, debugging and operation of the beamline station of a synchrotron light source highly depend on three types of tool software, i.e., computer simulation, device control and data management. However, the existing technical solutions have a serious problem of "tool fragmentation and process fault", and lack a complete and high-fidelity virtual environment to support the pre-validation and testing of the entire experiment process.

[0003] In terms of optical simulation, tools represented by SHADOW and its graphical integration platform OASYS can simulate the propagation of X-rays in optical devices based on the principle of ray tracing. However, such tools focus on front-end optical design and lack virtualization capabilities for core devices of the experiment station (such as detectors and sample tables), and cannot simulate the complete data flow of "device control-data acquisition", which is disconnected from the subsequent experiment control link.

[0004] In terms of device control, EPICS (Experimental Physics and Industrial Control System) is a standard control framework widely used in the field of synchrotron radiation. However, the IOC (Input Output Controller) simulator of EPICS has simple functions and can only simulate the process variable response of a single device, making it difficult to reproduce complex timing logic for collaborative work between multiple devices (such as triggering detector acquisition after motor movement), and even more difficult to support specialized function linkage simulation for synchrotron dedicated devices (such as double-crystal monochromators), limiting the efficiency and reliability of virtual debugging.

[0005] In terms of experiment process and data management, frameworks such as Bluesky focus on the definition of experiment process arrangement, but they do not have the ability to virtualize devices and efficiently reproduce historical data. Users need to manually configure real device parameters to generate scan plans, and cannot directly drive virtual devices. At the same time, when loading historical experiment data (such as GB / TB-level HDF5 / NeXus files), there is a significant delay (usually more than 100 milliseconds), which prevents the "experiment arrangement" from forming an effective closed loop with "virtual control" and "data generation / reproduction".

[0006] In summary, the existing "optical simulation-equipment control-experiment management" tool chain is independent of each other, resulting in a fault in the "equipment-control-data" whole process. This technical bottleneck restricts the construction and operation efficiency of new generation light sources such as High Energy Photon Source (HEPS), and lacks a low-cost pre-validation platform for the complete experiment process during the construction period, and lacks effective tools for user training and software testing during the operation period. Therefore, developing a unified software platform that can deeply integrate the above functions and realize whole-process closed-loop virtualization has become a key technical problem to be solved. SUMMARY

[0007] To solve the above technical problems, the present application provides a virtual beamline software platform for advanced synchrotron radiation light source, which establishes a deep coupling and dynamic interaction relationship between equipment control, experiment scheduling and data management by designing a "protocol-data-timing" bidirectional mapping and bridging mechanism, and realizes high-precision virtualization of key equipment of the synchrotron radiation beamline station, providing a high-fidelity, whole-process virtual environment for the development, testing and optimization of beamline software and experiment pre-commissioning.

[0008] To achieve the above purpose, the present application adopts the following technical solutions:

[0009] The virtual beamline software platform for advanced synchrotron radiation light source comprises a three-layer architecture of user interaction layer, virtual device layer and data management layer, supports full simulation experiment based on physical model and data reproduction based on historical experiment data set dual working modes; wherein,

[0010] The user interaction layer is realized based on the Bluesky experiment control framework, and is used for scheduling experiment process and issuing control instructions to the virtual device layer;

[0011] The virtual device layer comprises a virtual experiment station engine, a device virtualization module, a data simulation module and a data reproduction module; wherein the device virtualization module abstracts the physical device into an input-output controller instance conforming to the EPICS standard, each instance receives control instructions through a process variable and returns data; the data simulation module internally has a high-fidelity physical model for generating simulation data in the full simulation experiment mode; the data reproduction module is used to load and play back the historical experiment data set in the data reproduction mode; the virtual experiment station engine schedules the device virtualization module according to the selected working mode, so that it can obtain data from the data simulation module or the data reproduction module, and respond to the upper layer through a unified process variable interface;

[0012] The data management layer adopts block reading and memory mapping technology for efficient storage and access of historical data sets.

[0013] Further, the experiment flow arrangement in the user interaction layer is realized by object-oriented encapsulation of process variables PV of virtual devices by the Ophyd library; the encapsulation encapsulates a virtual detector as a VirtualAreaDetector class and internally embeds a dark current noise injection method, and encapsulates a virtual motor as a VirtualEpicsMotor class and supports configuration of backhaul difference parameters; the encapsulation class establishes bidirectional binding with underlying PV through the EPICS Channel Access protocol, so that Bluesky experiment arrangement instructions can directly drive virtual devices.

[0014] Further, the user interaction layer provides graphical and programmed interfaces for defining experiment parameters and flow; in data reproduction mode, it can automatically parse experiment timing metadata embedded in historical data sets and generate corresponding experiment instruction sequences.

[0015] Further, the physical devices abstracted by the device virtualization module include virtual detectors, virtual motors, and virtual optical devices; the virtual detectors include zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors, the virtual motors include linear translation motors and angular rotation motors, and the virtual optical devices at least include a virtual double-crystal monochromator, a virtual electric four-blade slit, and a virtual beam position probe.

[0016] Further, the physical models embedded in the data simulation module include a two-dimensional elliptical Gaussian function model for simulating light intensity distribution and a three-dimensional projection integral model based on the Shepp-Logan model for simulating CT projection data, and can inject Poisson noise into generated simulation data to simulate detector dark current.

[0017] Further, when loading and playing back historical experiment data sets, the data reproduction module specifically performs the following operations: calls down the high-speed data processing module of the data management layer to obtain data streams optimized by block reading and memory mapping technology; automatically parses experiment metadata and acquisition logic embedded in the historical experiment data set file, and generates corresponding data acquisition scripts uploaded to the user interaction layer; drives virtual devices to execute data reproduction processes according to original experiment timing.

[0018] Further, the data management layer includes an efficient data management module and a high-speed data processing module; the efficient data management module is used to parse metadata structure and device configuration information of historical data sets, and the high-speed data processing module is used to perform high-performance data reading operations based on block indexing and memory mapping.

[0019] Further, the data management layer's block reading and memory mapping technology specifically includes: a pre-constructed HDF5 / NeXus file data block physical address mapping table, zero-copy data reading through the memory mapping function of the operating system, and pre-reading of subsequent data blocks by using a double-buffer pipeline mechanism to ensure the continuity of access.

[0020] Further, the experimental method in the full simulation experiment mode based on the physical model includes:

[0021] Environment preparation, deployment of the basic software environment and initialization of the user interaction layer;

[0022] Virtual device service startup, starting the virtual device instance and configuring parameters according to the experiment mode and type;

[0023] Data acquisition task configuration, defining control parameters, acquisition scripts and data saving settings;

[0024] Virtual experiment process execution, driving the virtual device to perform acquisition operations according to the arrangement scheme, and generating and storing simulation data in real time.

[0025] Further, the experimental method of the data reproduction double working mode based on the historical experiment data set includes:

[0026] Reproduction environment preparation, deployment of the basic software environment and initialization of the user interaction layer;

[0027] Historical data import, loading the timestamp-aligned HDF5 / NeXus format historical data set;

[0028] Virtual device instance creation, automatically creating and initializing the virtual device of the corresponding type according to the historical data characteristics;

[0029] Data reproduction process execution, automatically generating acquisition scripts according to historical data, and driving the virtual device to reproduce the experiment process according to the original time sequence.

[0030] The beneficial effects of the present application are:

[0031] Full-process closed-loop virtualization is achieved: the limitations of existing tools focusing on a single link are broken, and experiment arrangement, device control and data management are deeply integrated in a unified platform, realizing full-link closed-loop from experiment design, pre-validation to data analysis, and greatly improving the efficiency of experiment preparation and software testing.

[0032] Innovative double-mode driving architecture: supporting two working modes of “physical model simulation” and “historical data reproduction”. Both can flexibly design new experiment schemes based on high-fidelity models and accurately and efficiently replay real historical experiments, covering the whole life cycle of device construction, debugging, running and optimization.

[0033] Deep protocol compatibility and seamless migration are achieved: through full simulation of the EPICS control protocol by the virtual device layer, control code, user interfaces and data analysis programs developed for real physical devices can be directly run in the virtual environment without any modification, realizing seamless migration from the real environment to the virtual environment and ensuring the reusability of the development results.

[0034] An efficient data management scheme is provided: for massive scientific data of synchrotron radiation, the data management layer uses optimization techniques such as block reading-memory mapping, significantly improving the loading and playback speed of TB-level historical experimental data, effectively solving the delay bottleneck of data reproduction, and realizing smooth data rollback and analysis.

[0035] The high fidelity of the virtual environment is ensured: the virtual device is embedded with physical and error models (such as detector noise, motor back difference), making the generated simulation data closer to the real experimental results, greatly improving the reliability and robustness of the data acquisition and control software developed based on the platform in actual deployment.

[0036] The cost and risk of the experiment are significantly reduced: by replacing part of the physical device debugging link with a high-fidelity virtual environment, the risk of damage to high-value optical elements is reduced, and a safe and flexible operation training and scenario rehearsal environment is provided for researchers, effectively reducing the learning cost and operation risk. BRIEF DESCRIPTION OF DRAWINGS

[0037] Figure 1 The structural diagram of the virtual beamline software platform for advanced synchrotron radiation light source of the present application is shown in the figure;

[0038] Figure 2 The experiment scheduling control flowchart of the user interaction layer is shown in the figure;

[0039] Figure 3 The virtual device type diagram is shown in the figure;

[0040] Figure 4 The data acquisition workflow diagram in full simulation mode is shown in the figure;

[0041] Figure 5 The data acquisition workflow diagram in historical data reproduction mode is shown in the figure. DETAILED DESCRIPTION

[0042] The present application will be further described below in conjunction with the drawings and examples.

[0043] The application relates to a virtualization software platform for a synchrotron radiation light source experiment station, and through innovative design of a three-layer architecture and a double driving mode, a double-mode driving architecture of a full simulation experiment mode based on a physical model and an experimental data reproduction mode based on a historical data set is established, and through deep coupling of an EPICS device control protocol and a Bluesky experiment arrangement framework (such as object-oriented encapsulation of a virtual device PV by an Ophyd library), full-process closed-loop virtualization from experiment design, virtual device control to virtual data acquisition and analysis is realized, and the experiment process and the device characteristics of a beamline station (such as imaging, XRD (X-ray diffraction) mapping) are completely matched. The core lies in the double-mode data driving architecture, the platform can be flexibly switched or used in cooperation between the two modes according to task requirements, and a complete virtualization environment that can be used for innovative design and historical backtracking is provided for the whole experiment process. In the full simulation experiment mode based on the physical model, the platform generates simulation data through built-in high-fidelity physical models. For example, a virtual detector can output a spot image based on a Gaussian function or CT projection data generated by a 3D Shepp-Logan model, and can simulate real noise (such as dark current); a virtual motor can move according to a user preset trajectory and simulate mechanical errors (such as back difference). In the data reproduction mode based on the historical data set, the platform supports importing historical experiment data sets in HDF5 / NeXus and the like. Through efficient data loading technologies such as block reading-memory mapping, real data is aligned according to timestamps and then loaded into corresponding virtual device modules, and the data acquisition process and environmental state of the original experiment are completely reproduced.

[0044] As shown in Figure 1 The software platform adopts a three-layer software architecture of a user interaction layer, a virtual device layer and a data management layer, data exchange and function calling are carried out between the layers through a clearly defined interface protocol, a cooperative working mechanism is formed: the user interaction layer is responsible for experiment process arrangement and instruction issuing; the virtual device layer undertakes device virtualization and data generation core functions; and the data management layer provides efficient data access support. The architecture design ensures that the platform maintains the independence of each module while realizing the high cooperation of the overall function.

[0045] The user interaction layer is a unified interface for user interaction with the software platform, and the core is a user experiment arrangement operation module. The module is realized based on the Bluesky experiment control framework, provides two interactive modes of graphical and programming, allows the user to select a virtual experiment device, define experiment parameters (such as scanning range, step length, exposure time) and formulate a complex experiment process (such as CT scanning, XRD mapping), and in the data reproduction mode based on the historical data set, the system can automatically analyze the original experiment logic and generate an experiment instruction sequence.

[0046] As shown in Figure 2As shown, the core innovation of the user experiment orchestration operation module lies in its bidirectional instruction conversion capability. The user can customize the running logic and data acquisition timing of the virtual device based on the designed data acquisition template. All virtual devices implement standardized interfaces through the EPICS Channel Access protocol, supporting device control and data reading through PV; in the data reproduction mode based on historical data sets, it can receive and automatically execute the acquisition scripts generated by the data reproduction module based on the analysis of the original historical data, achieving intelligent reverse reconstruction of the experiment process without manual intervention. Specifically:

[0047] Orchestration interface design: Provide "programmatic + graphical" dual interface - Programmatic interface supports defining experiment processes through BlueskyScan Plan syntax (standard Python) (such as CT continuous rotation scanning: scan([virtual_2d_det], virtual_rot_motor, 0, 180, 180)); The graphical interface presets imaging, diffraction, and spectroscopy experiment templates, and the user only needs to input key parameters (such as exposure time, scan step) to generate an orchestration plan.

[0048] Device interface encapsulation: Since all virtual devices expose standardized PV interfaces through the EPICS Channel Access protocol, Ophyd library is used for object-oriented encapsulation to form a "virtual device-specific class library". The virtual detector is encapsulated as a VirtualAreaDetector class (inherits AreaDetector), with a built-in dark current noise injection method (set_dark_current()); The virtual motor is encapsulated as a VirtualEpicsMotor class (inherits EpicsMotor), supporting backlash parameter configuration (set_backlash()). Encapsulated classes establish bidirectional binding with underlying EPICS PV through the Channel Access protocol, ensuring that orchestration instructions can directly drive virtual devices.

[0049] Reproduction mode adaptation: In the historical experiment data reproduction mode, the system parses the experiment timing (such as motor position-time curve, detector acquisition trigger signal) in the HDF5 / NeXus file through the virtual device layer data reproduction module, automatically converts it into a standard Bluesky Plan instruction sequence (without manual coding), and realizes reverse reconstruction of the experiment process.

[0050] The virtual device layer, as the platform core, consists of a virtual experiment station engine, a device virtualization module, a data simulation module, and a data reproduction module.

[0051] The virtual experiment station engine is used as a scheduling center, schedules and coordinates the work of other modules according to the selected work mode (full simulation / reproduction) of the user, and allocates computing resources; specifically:

[0052] Device instance scheduling: according to the selected experiment type (such as CT experiment) of the user, the device virtualization module is automatically called to generate a "virtual optical device + virtual motion device + virtual detection device" cluster - for example, a CT experiment needs to generate a "virtual double-crystal monochromator + virtual rotating motor + virtual 2D detector", and load the corresponding device parameter template (such as monochromator Si(111) crystal parameters, detector resolution 1024x1024 size) through a preset script.

[0053] Work mode scheduling: according to the selected mode of the user, the corresponding data module is triggered. In the full simulation mode, the "physical model calling instruction" (such as CT experiment calling 3D Shepp-Logan model) is sent to the data simulation module, and the error parameters (such as detector dark current 15 counts / s) are injected synchronously; in the historical reproduction mode, the "historical data loading request" is sent to the data reproduction module, the HDF5 / NeXus file path and data block are specified, and the data and virtual device timing alignment are ensured.

[0054] As shown in Figure 3 The device virtualization module is the core of the entire layer, and its innovation lies in the unified abstraction of different types of physical devices (such as 1D / 2D detector, motor, monochromator) into EPICS standard IOC (Input / Output Controller) instances. Each virtual device instance exposes a set of process variables (PV) through the EPICS Channel Access protocol, thereby receiving control instructions and returning data. Its key function is to support dual-mode data response: in simulation mode, data calculated based on physical models is obtained from the data simulation module; in reproduction mode, time-stamped historical data is obtained from the data reproduction module.

[0055] The virtual detector class is composed of zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors.

[0056] Zero-dimensional detector refers to a detector that has only one dimension with significant size in three-dimensional space, usually in the form of a point or a spherical structure. Its simulation core principle is based on the "baseline + random noise" model, and the baseline value can be configured (such as 100 counts). The noise is simulated by a random number generator with a settable range (such as ±5 count fluctuation). Configurable parameters include engineering units (EGU), sampling period, readout (RBV), and noise intensity. It can be used to simulate the response of photodiodes, ionization chambers (such as Keithley 6485 / 6487), and counters.

[0057] One-dimensional detector is usually used to obtain linear spatial distribution information, such as line array CCD or linear scanning radar, which only provides intensity distribution in linear direction. Its simulation principle is based on the model of "ideal intensity distribution + Gaussian noise", and the ideal distribution can be selected as linear gradient or peak distribution, and the noise intensity is positively correlated with exposure time. The core simulation function parameters (corresponding to PV in EPICS) are as follows: ImageMode (single \ multiple \ continuous); Acquire (start acquisition \ stop acquisition); ArrayData (one-dimensional array of simulated fluctuations); AcquireTime (exposure time, unit s); NumImage (number of single exposure acquisition); TriggerMode (currently only supports soft trigger).

[0058] Two-dimensional detector is usually used to record two-dimensional spatial distribution information of X-ray, and is widely used in X-ray imaging, X-ray diffraction, X-ray scattering and other fields. Its simulation principle is to call the physical model (Gaussian spot, 3D Shepp-Logan CT projection) in full analog mode and inject Poisson noise (simulate dark current); In the reproduction mode, load ArrayData in the historical HDF5 / NeXus data. Its core simulation parameters are as follows: ImageMode (single \ multiple \ continuous); Size_X (horizontal size); Size_Y (vertical size); AcquireTime (exposure time); Acquire (start acquisition \ stop acquisition); ArrayData (two-dimensional data provided by the data reproduction and data simulation modules); NumImage (number of single exposure acquisition); TriggerMode (only supports soft trigger).

[0059] For virtual electric machines, in order to meet the needs of sample table and equipment adjustment in synchrotron radiation source experiments, it is divided into linear translation motor and angle rotation motor, and high-precision virtualization is realized through "motion model + error injection + EPICS PV control".

[0060] Virtual linear translation motor is suitable for the linear motion control scenario of the beamline station of the synchrotron radiation light source, and can simulate the X / Y / Z axis positioning of the sample table and the driving of the electric four-blade slit. Its motion is based on the "trapezoidal speed curve": starting from the initial speed, accelerating to the maximum speed, and stopping at the target position with the same deceleration, the dynamic characteristics match the real motor. The core EPICS PV parameters include configurable items such as initial speed, acceleration, maximum speed, and soft limit (±100 mm), and read-only items such as motion state (Status) and actual position feedback (RBV); support for back difference error injection (such as ±0.001 mm), compensate for errors before updating the position during reverse motion, and restore the mechanical characteristics. In typical applications, when driving the virtual four-blade slit, the "one-key opening and closing" algorithm can be used to update the target position of the four-blade motor synchronously, ensuring that the spot center remains unchanged.

[0061] Virtual angle rotation motor focuses on the sample table pose adjustment and CT experiment of the synchrotron radiation light source, and can simulate Pitch / Roll / Yaw three-degree-of-freedom control and CT rotation axis motion. The motion model is the same as the linear translation motor (trapezoidal speed curve), but the engineering unit is "degree (°)", and supports 360° continuous rotation. The core EPICS PV parameters include initial speed, acceleration, maximum speed, soft limit (±185°), target angle, and actual angle feedback (RBV); support for angle drift error injection (such as ±0.01° / min) to simulate real motor temperature drift. In CT experiments, the target angle can be updated according to the Bluesky scanning plan (such as 0-180°, step 1°), and the detector is exposed after reaching the target angle, ensuring positioning accuracy through RBV.

[0062] For virtual optical devices, related to the simulation of synchrotron radiation light. Mainly including double-crystal monochromator, electric four-blade slit and beam position probe. Among them, the virtual double-crystal monochromator is based on the angle rotation motor core architecture expansion, the virtual electric four-blade slit is based on the linear translation motor expansion in the virtual motor class, and the virtual beam position probe is based on the virtual probe class expansion.

[0063] Virtual double-crystal monochromator is based on the angle rotation motor core architecture expansion, and is specially designed to simulate the double-crystal monochromator used for X-ray energy selection in the beamline station. In addition to inheriting the Bragg angle control (SIM:DCM:Bragg), the core function parameters are as follows: target energy value (SIM:DCM:Energy.VAL), actual energy feedback value (SIM:DCM:Energy.RBV), crystal switching parameter (SIM:DCM:Sel) and crystal temperature (SIM:DCM:Temp).

[0064] The target energy value is used to set the monochromator target energy, and the actual energy feedback value is used to obtain the energy feedback value of the virtual double-crystal monochromator. The two parameters are linked with the motor target position and actual position feedback value.

[0065] The linkage between the angle and energy of the virtual double-crystal monochromator is automatically calculated using Bragg's law, and the core formula is:

[0066] ,

[0067] Among them, : diffraction order (usually 1); : X-ray wavelength (Å); : interplanar spacing (Å); : Bragg angle (degree). Its conversion to energy ( Relationship with angle:

[0068] .

[0069] The crystal switching parameter is used to realize the crystal switching function in the monochromator. Corresponding to the following table 1 two kinds of optional crystal parameter data.

[0070] Table 1

[0071]

[0072] The core of the virtual electric four-blade slit is composed of four virtual linear displacement motor instances (Top, Bottom, Left, and Right) and a one-key opening and closing control function. The one-key opening and closing control function is realized through an intelligent intermittent control algorithm, and the algorithm formula is as follows. By automatically calculating the blade displacement, the four blades are moved, that is, the blades in the horizontal x (Left and Right) and vertical y (Top and Bottom) directions are respectively mirror moved to ensure that the center position of the light beam does not change.

[0073] ,

[0074] Among them, the initial state of the four blades is located at zero position (center origin), and the unit is mm; is the target horizontal gap; is the target vertical gap, , , , respectively represent the displacement of the blade in the corresponding direction; by setting the values of the upper and lower blades will be automatically adjusted, such as 1mm, the upper virtual motor moves 0.5mm upward (positive direction), and the lower virtual motor moves 0.5mm downward (negative direction). By setting The values of the left and right knives will be automatically synchronized, as is 1mm, the left knife virtual motor moves 0.5mm to the left (negative direction), and the right knife moves 0.5mm to the right (positive direction).

[0075] The virtual beam position probe is a zero-dimensional probe expansion based on the virtual detector class. A four-quadrant electrode array is composed of four virtual zero-dimensional probe instances, which simulate the real BPM electrode signal acquisition and processing process in real time through the EPICS signal channel. This system innovatively uses dynamic signal reconstruction technology to convert the physical electrode response of traditional hardware BPM into a programmable virtual signal source. Not only does it retain the key algorithm characteristics of (A+B+C+D) and signal monitoring, (A+D-B-C) / Σ normalization position calculation, but also realizes real-time calculation and feedback of beam position parameters through the Derived Signal mechanism. This virtual device can still provide beam orbit monitoring functions without physical hardware, while supporting multi-device linkage simulation and global debugging scene applications.

[0076] The data simulation module is applied to the full-analog experiment mode and has a built-in high-fidelity physical model to respond to PV read-write requests from virtual devices and generate corresponding simulation data. For example, it can dynamically generate Gaussian spot images based on a two-dimensional elliptical Gaussian function model, or generate CT projection data based on a 3D Shepp-Logan model and Radon transform, and can inject pre-set noise and error models into the data.

[0077] The data reproduction module is applied to the historical experiment data reproduction mode, and its core function is to connect down to the data management layer, load the timestamp-aligned HDF5 / NeXus format historical dataset, and realize efficient data stream playback through block reading-memory mapping technology. In addition, this module can automatically parse the experimental metadata and acquisition logic embedded in the original data file and generate corresponding data acquisition scripts for uploading to the user interaction layer. Specifically:

[0078] For Gaussian spot simulation, a two-dimensional elliptical Gaussian function model is used to simulate the intensity distribution of the synchrotron radiation beam for virtual 2D detector spot data generation. Its core design expression is as follows:

[0079] ,

[0080] Where: is the intensity at point ; A is the amplitude (spot peak intensity); is the spot center coordinate, which is by default located at the center of the detector and can be offset by adjusting the value, with an offset accuracy of 0.01 pixels; is the horizontal standard deviation; It is the standard deviation in the vertical direction. It supports asymmetric spot simulation. It can accurately simulate elliptic beams and dynamically respond to parameter changes with a parameter update delay of less than 10ms. In terms of data output, it outputs 16-bit integer data (matching the data format of a two-dimensional detector), which can be directly input into the ArrayData PV of the virtual 2D detector and supports linkage with the virtual beam position probe (calculating the beam center position through the beam intensity distribution).

[0081] For the simulation of CT projection data, a 3D Shepp-Logan model is used as the basis, and accurate simulation of CT projection data is achieved based on the three-dimensional projection integral formula (a generalization of Radon transform). The core design expression for projection calculation is as follows:

[0082] ,

[0083] in: Indicates the angle The two-dimensional projection data below, For the coordinates of the projection plane, Represents three-dimensional projection data; The projection angle has a range of values. Uniform distribution sampling is used: (Total number of angles); Let be the Dirac function, representing the angle along the projection direction. The line integral process of ).

[0084] In terms of the generation process, based on the angle sequence of the virtual CT rotary motor (e.g., 0-180°, step size 1°), the projection data corresponding to each angle is calculated according to the above formula → Poisson noise is injected (simulating the dark current of the detector, the noise intensity is positively correlated with AcquireTime) → output to the ArrayData PV of the virtual 2D detector.

[0085] In terms of adaptability, it supports common projection sizes (such as 1024×1024, 2048×2048), and the grayscale distribution error between the projection data and the real CT experimental data is <5%, which can be used for virtual testing of CT reconstruction algorithms.

[0086] The data reproduction module is the core of the historical experimental data reproduction mode, which is specially used to load the standard HDF5 / NeXus format historical data and drive the virtual device to reproduce the original experimental process. The core functions are divided into two parts: "data loading management" and "experimental script analysis". The specific contents are as follows: in terms of data loading management, the module connects to the data management layer, controls the high-speed data processing module, and realizes automatic alignment and loading of HDF5 / NeXus format historical data set according to timestamp, ensuring efficient data access and providing reliable source support for data reproduction. In terms of experimental script analysis, the module can automatically analyze the corresponding data acquisition script, extract key information (such as device type, number, etc.), and return the analysis results to the user interaction layer for users to view and manage experimental configuration. The design of this module takes into account the efficiency of data loading and the accuracy of script analysis, providing complete technical support for the reproduction and analysis of historical experimental data.

[0087] The data management layer is composed of a high-speed data processing module and an efficient data management module, which adopts a block reading-memory mapping technology to optimize the loading and access speed of GB / TB level historical experimental data, and solves the data delay bottleneck in traditional methods. Specifically:

[0088] The high-speed data processing module adopts a core technical solution that integrates "HDF5 block storage index + memory mapping zero-copy + double buffering pipeline" technology. The GB level data loading delay is reduced from the traditional full reading of >100 ms to <10 ms, supporting high-throughput access of EB level data; at the same time, the HDF5 native LZ4 lossless compression is used to reduce storage occupancy (compression ratio about 2:1) while maintaining data quality. The specific technical process is as follows:

[0089] 1. Pre-built block index: Analyze the Chunked Storage structure of HDF5 file (such as 128x128 pixels per block), pre-construct the data block physical address mapping table, and realize accurate positioning on demand (without traversing the whole file);

[0090] 2. Memory mapping loading: Map the data block directly to the virtual device cache through the operating system mmap function, realizing "zero-copy reading" (avoiding repeated copying of data between memory and disk);

[0091] 3. Double buffering pipeline: Adopt a double buffering mechanism of "main thread processing current frame data + background thread pre-reading next 1-2 frames of data", combined with a ring sliding window cache (cache size can be configured, such as 10 frames), to ensure data sequence and continuity.

[0092] The high-efficiency data management module is designed for the HDF5 / NeXus scientific data format commonly used in synchrotron radiation sources, and has the capabilities of standardized analysis and flexible adaptation. Its core data analysis function extracts key information according to the standard path: from the " / entry / instrument / detector / " and " / entry / instrument / motor / " directories, respectively identify the detector type (0D / 1D / 2D through dimensions), the number of motors and parameters (speed, soft limit, etc.); from " / entry / instrument / monochromator / energy", extract the beam energy, combine " / entry / measurement / timestamps" to obtain the time stamp of each frame of data and the motor position-time curve, and synchronously collect metadata such as experiment name and collection time. When supporting data reproduction processes, the module transmits the parsed "device list" and "scan parameters" to the data reproduction module, providing the basis for generating Bluesky scan Plan scripts, and generating a "data-device" matching table to ensure that the detector data block and the corresponding motor position are accurately aligned during reproduction. In addition, the module supports custom data structures for different beamline stations (such as " / entry / CT / projections" for imaging scenarios and " / entry / XRD / patterns" for diffraction scenarios), and can extend the analysis rules through configuration files to adapt to diverse experimental data needs.

[0093] Based on the foregoing software platform, the application provides a virtual beamline full-simulation experiment method for a synchrotron radiation source, comprising the following steps:

[0094] Step 1, preparation of the running environment: deploy Python3 (version requirement greater than 3.6.8) and the EPICS7.0 basic control framework in the running environment, configure the necessary dependent libraries; initialize the user interaction layer and load the virtual device configuration interface;

[0095] Step 2, start of the virtual device service: start the corresponding virtual device instance according to the user-selected experiment mode and device type, and configure the device parameters, including the optical device state, detector parameters and motor parameters;

[0096] Step 3, configuration of the data acquisition task: define the experiment data acquisition task, including the virtual device control parameters, data acquisition script configuration, and experiment data saving path and file format setting;

[0097] Step 4, execution of the virtual experiment process: start the virtual experiment station engine according to the experiment arrangement scheme provided by the user interaction layer, drive the virtual device to perform data acquisition operations; real-time simulation data is generated and stored in the experiment data according to the preset format.

[0098] Further, in the step 1, the operating system supported by the running environment is Linux (Centos7.964 bits) or Windows10 (64 bits), and at least one graphic processing unit (GPU) supporting parallel computing.

[0099] Further, in the step 2, the optical device state includes monochromator crystal parameters, slit geometry parameters and beam position probe values; the detector parameters include image size, exposure time, exposure period, trigger mode and image mode; and the motor parameters include speed, acceleration, soft limit range and engineering unit.

[0100] Further, in the step 4, the virtual device is driven to run through an EPICS control interface, which is completely compatible with the real device and supports standard process variable reading and writing operations; the data acquisition process includes that the virtual motor moves according to a preset track and injects mechanical errors, the detector generates detection data based on the optical element state and the physical model, and the data acquisition system records the device state and output data in real time.

[0101] In addition, the application also provides a method for historical data reproduction of a virtual beamline of a synchrotron radiation light source, comprising the following steps:

[0102] Step 1, preparation of a reproduction environment: deploying Python3 (version requirement is greater than 3.6.8) and an EPICS7.0 basic control framework in a running environment, configuring necessary dependent libraries, initializing a user interaction layer and loading a virtual device configuration interface;

[0103] Step 2, historical data import: based on a high-speed data processing module of a data management layer, loading a timestamp-aligned HDF5 / NeXus format historical data set, automatically identifying a data organization structure, and quickly loading detector data and motor position data to the platform through a block reading-memory mapping technology;

[0104] Step 3, virtual device instance creation: automatically creating virtual detectors and virtual motor devices of corresponding types and quantities according to the characteristics of the imported historical data, and completing virtual device initialization according to the device configuration parameters contained in the data file;

[0105] Step 4, data reproduction process execution: automatically generating a data acquisition script according to the historical data, starting a virtual experiment station engine, driving the virtual device loaded with the historical data to execute the data reproduction process according to the original time sequence, and saving the output data in a preset format.

[0106] Further, in step 1, the operating environment supports Linux (CentOS7.9) or Windows10 (64bit) operating system, at least one graphics processing unit (GPU) supporting parallel computing is configured, and storage space not less than twice the size of the historical data set is provided.

[0107] Further, in step 2, the historical experimental data is stored in HDF5 / NeXus scientific data format, including device configuration parameters, detector raw data, motor movement data, experimental metadata, and corresponding timestamp information.

[0108] Further, in step 3, a smart device matching mechanism is used to automatically create virtual devices: by analyzing the dimension information of the detector data in the historical data, corresponding types of detector instances (0D, 1D, or 2D) are automatically created; according to the number of motors recorded in the data, corresponding virtual motors are generated; devices with complete configuration parameters are initialized according to the original parameters, and devices with missing parameters are intelligently parameterized according to the standard template.

[0109] Further, in step 4, the platform controls the virtual devices to perform operations according to the original experimental timing based on the timestamp information in the historical data, and all output data are automatically saved in standard format.

[0110] Embodiment 1: Full simulation CT experiment mode for HEPS imaging experiment station.

[0111] As shown in Figure 4 , this embodiment is based on the CT tomography scenario of the HEPS imaging experiment station of the synchrotron radiation source, and constructs a full-process simulation environment based on virtual beamline technology, focusing on verifying the dynamic collaboration capability of the virtual device cluster dedicated to synchrotron radiation and the physical fidelity of experimental data. The experimental parameters are set as follows: beam energy 10 keV (corresponding to wavelength 1.24 Å), spot size 1 mm x 0.5 mm (horizontal x vertical), fixed at the origin (0, 0, 0) of the sample table coordinate system; using continuous rotation scanning mode, angle range 0°-180°, step 1°, single frame exposure time 1s, detector output 1024x1024 two-dimensional projection.

[0112] Step 1, experimental environment deployment and standardized configuration:

[0113] Step 1.1, bottom technology stack construction.

[0114] To ensure normal operation of the system, the bottom technology stack needs to be constructed before system deployment, as follows:

[0115] (1) Python3 running environment: Before system deployment, python3 (version requirement greater than 3.6.8) needs to be installed on the computer or server;

[0116] (2) Control framework: install and deploy EPICS 7.0 base environment and AreaDetector module;

[0117] (3) Python library: install by pip but not limited to Bluesky, Ophyd, Numpy, etc. key essential libraries.

[0118] Step 1.2, virtual optical system initialization.

[0119] Based on the optical characteristics of the synchrotron beamline, the virtual front-end optical device cluster is configured. First, the double-crystal monochromator, by configuring the crystal parameters (Si(111), d=3.1356 Å) through the EPICS PV, setting the target energy to 10 keV, the system automatically solves the Bragg angle (11.40°) and updates the BraggAngle.RBV feedback value, and the energy stability is controlled within ±0.01 keV. Secondly, the electric four-blade slit, enable the "center keeping" algorithm dedicated to synchrotron radiation, through the PV parameter combination of Top=0.25mm, Bottom=-0.25mm, Left=-0.5mm, Right=0.5mm, under the premise of keeping the light spot center (0,0) unchanged, accurately control the beam cross section size. Finally, the beam position probe, simulate the four-quadrant ionization chamber signal output, through the XPos / YPos PV real-time feedback of the light spot drift (control accuracy ±5μm), data sampling rate 1kHz, as experimental metadata archiving.

[0120] Step 2, virtual experimental station core device parameter configuration:

[0121] The virtual experimental station core device (including a virtual two-dimensional detector, a virtual angle rotation motor, and three virtual linear translation motors), among which the two-dimensional detector is used to simulate CT projection acquisition, the three linear translation motors simulate three-dimensional positioning of the sample table, and the angle rotation motor simulates the rotation axis of CT scanning, to realize the simulation of the experimental station equipment.

[0122] Step 2.1, virtual detector system parameter calibration.

[0123] According to the experimental type and requirements, update the virtual two-dimensional detector EPICS PV value, that is, AcquireTime is 1s, TriggerMode is SoftTrigger (soft trigger), ImageMode is Single (single acquisition), Size_X is 1024, Size_Y is 1024, and NumImage is 1. The data source of the virtual two-dimensional detector is set to CT simulation projection data based on the 3DShepp-Logan model, 180 two-dimensional projection images from 0° to 180° (step length 1°) are generated by the projection calculation program, and it is ensured that the projection data is dynamically generated according to the angle sequence.

[0124] Step 2.2, sample motion system parameter configuration.

[0125] According to the assumption that the light spot position is fixed at the origin (0, 0, 0) of the sample table coordinate system, the actual position values of the three-axis motors (X, Y, Z axes) of the sample table are set to 0. The angle rotation motor is used as the CT rotation axis, the angle rotation motor limit range is set to ±185°, and the actual position of the CT starting point is set to 0°.

[0126] Step 3, experiment execution and data flow control:

[0127] Step 3.1, scan process arrangement and conversion.

[0128] Submit the CT experiment Bluesky scan Plan through the user interaction interface and set the scan parameters. The rotation angle range is 0° to 180°, the step interval is 1°, and the specific command is as follows,

[0129] scan([virtual_detector],virtual_rotation_motor,0,180,180);

[0130] The Ophyd device abstraction layer parses it into an EPICS control instruction sequence to generate a motion trajectory containing 180 angle points, each node is associated with a detector trigger signal, and the "motion-exposure" timing accuracy (±1ms) is ensured.

[0131] Step 3.2, dynamic data acquisition and association.

[0132] After the data acquisition starts, the Bluesky RunEngine executes the data acquisition task according to the established process. First, the Ophyd sends a stepping instruction to the virtual rotary motor through the EPICS channel, and at the same time, it reads the motor feedback value in real time to ensure the accuracy of the angle positioning. After each step angle is stabilized, the system triggers the soft acquisition instruction of the virtual detector, and the detector simulation module calculates the 3D Shepp-Logan projection based on the current angle to generate the required simulation image data, and transmits the data stream through the AreaDetector module. In this process, the system synchronously records the device state information including the monochromator energy, the size of the slit opening and closing, and the beam position signal, and associates these metadata with each frame of image.

[0133] Step 3.3, data archiving and standardized storage.

[0134] After the data acquisition is completed, the system receives the detector data stream through the interface of Bluesky, and each frame of image triggers an event containing the original pixel array and related scanning parameters. These data are automatically reorganized and stored according to the HDF5 / NeXus standard structure. The original data layer saves 180 projection images, forming a 180x1024x1024 three-dimensional data set; the metadata layer records important information such as monochromator energy parameters, sample stage geometric position information, and slit process variable history data in detail.

[0135] This embodiment verifies the technical feasibility of the virtual platform in the simulation of beamline-level experiments by reproducing the core features of the synchrotron CT experiment, such as optical control, precision motion, and timing coordination. The data output conforms to the standard of synchrotron experiment data, and can directly support the development of subsequent reconstruction algorithms and optimization of experimental schemes.

[0136] Example 2: Historical data reproduction mode for XRD Mapping experiment.

[0137] As shown in Figure 5 , this embodiment focuses on the historical data reproduction scenario of the XRD Mapping experiment of the synchrotron light source, and realizes the accurate reproduction of the real experiment process based on the high-efficiency processing technology of large scientific data and the virtualization scheme of standardized equipment. It focuses on verifying the technical advantages of the virtual platform in the analysis of historical data, high-fidelity equipment mapping, and low-latency data loading.

[0138] Step 1, deployment of experimental environment and standardized configuration:

[0139] To ensure the normal operation of the system, the underlying technology stack needs to be built before the system is deployed, as follows:

[0140] (1) Python3 runtime environment: Before system deployment, install Python3 (version requirement greater than 3.6.8) on the computer or server;

[0141] (2) Control framework: Install and deploy the EPICS7.0 basic environment and AreaDetector module;

[0142] (3) Python library: Install through pip, but not limited to, Bluesky, Ophyd, Numpy, etc. Key required libraries;

[0143] (4) CUDA acceleration environment: Download the CUDA Toolkit installation package (.deb,.rpm or.exe) corresponding to the operating system from the NVIDIA website and install it on the computer;

[0144] (5) Storage configuration: Requires storage space ≥ 2.5 times the size of the historical data set (including data cache and temporary files), for example, 100 GB of historical data requires the configuration of 250 GB or more SSD storage to ensure the random access speed of the block data.

[0145] Step 2.1, data standardization analysis.

[0146] After importing the HDF5 / NeXus format data file of the XRD Mapping experiment, the efficient data management module of the data management layer performs structured analysis: through traversing the file / entry / instrument / directory, the device configuration is identified, the key parameters of the two linear motors (speed 5 mm / s, soft limit ±100 mm) are parsed from the X / Y child nodes under / entry / instrument / motor / , and according to the dimensions node value (1) in / entry / instrument / detector / , it is determined that it is a 1D XRD detector (2048 channels, exposure time 100 ms); At the same time, the experiment identifier (ExpID: XRD_20240510), acquisition time (2024-05-10 09:30:00), beam energy (8 keV) are extracted from / entry / experiment / node, the timestamp sequence containing 546 time nodes (interval 100 ms) is obtained from / entry / measurement / timestamps / , the two-dimensional scanning parameters (X axis 0-10 mm, step 0.5 mm, 21 points; Y axis 0-5 mm, step 0.2 mm, 26 points) are restored, and the scanning trajectory is determined as a "snake path" (X axis reciprocating, Y axis advancing line by line), which provides complete data basis for subsequent virtual device matching and process reproduction.

[0147] Step 2.2, block-in-memory mapping efficient loading.

[0148] High-performance data loading is performed by the high-speed data processing module of the data management layer. The core uses the "chunked index pre-building + memory mapping zero-copy" technical solution. The specific process is as follows:

[0149] Chunk strategy definition: based on the Chunked Storage structure of the HDF5 file (the original data block size is 128x2048, i.e. 128 scan pointsx2048 channels), a "timestamp-data block physical address" mapping table is pre-built, and the target data can be located without traversing the entire file;

[0150] Memory mapping construction: through the mmap function of the operating system, the energy spectrum data block ( / entry / measurement / detector_data) in the HDF5 file is directly mapped to the cache address space of the virtual detector, realizing "zero-copy reading" - the data does not need to be copied from the disk to the memory buffer, and the virtual detector can directly access the mapping address to obtain historical data, and the loading delay is reduced to less than 8ms (the traditional full reading delay is >120ms);

[0151] Double-buffered pipeline scheduling: enable the "main thread data reproduction + background thread preloading" double-buffering mechanism. When the main thread processes the data of the current scan point (such as X=0mm / Y=0mm), the background thread synchronously preloads the next 2 data blocks (X=0.5mm / Y=0mm, X=1.0mm / Y=0mm). Combined with the ring-shaped sliding window cache (cache capacity of 10 data blocks), the continuity of data reproduction is ensured, and there is no interruption.

[0152] Step 3.1, the device automatically creates and parameter mapping.

[0153] First, create two virtual linear motors to simulate the X-axis and Y-axis movement of the sample table. Set the moving speed to 5mm / s and configure the ±100mm soft limit protection. At the same time, initialize the virtual XRD detector, set the single-frame exposure time to 100ms, and specify the multi-frame acquisition mode. Bind the pre-loaded historical XRD energy spectrum data to the virtual detector as the data source, ensuring that 2048 channels of data of the corresponding scan point can be read from the mapping address every time the acquisition is triggered.

[0154] Step 3.2, device communication verification.

[0155] Verify the accessibility of all virtual device PVs through the EPICS Channel Access protocol to ensure that the virtual device service has been started correctly.

[0156] Step 4.1, experiment process reproduction.

[0157] In the experimental reproduction phase, the user first submits the XRD Mapping reproduction experiment instruction through the user interface. The system automatically analyzes the original scan parameters stored in the historical data file, including the two-dimensional scan range (X axis 0-10 mm, Y axis 0-5 mm), step interval (X axis 0.5 mm, Y axis 0.2 mm) and each point collection time (100 ms) and other key parameters. Based on these parameters, the system generates a corresponding Bluesky reproduction plan, which contains the complete coordinate sequence extracted from the historical data.

[0158] The Ophyd device layer is responsible for converting the reproduction plan into specific EPICS process variable control instructions. The virtual X-axis and Y-axis motors update the target position step by step according to the historical time sequence, while the virtual XRD detector binds the historical spectrum data as the data source. This step ensures that the device can accurately reproduce the motion trajectory and data acquisition process of the original experiment.

[0159] During the experiment execution process, the Bluesky RunEngine strictly follows the time sequence control flow. The virtual motor moves to each target position through the EPICS channel protocol, and the system reads the position feedback value in real time to ensure the movement accuracy. After reaching each target position, the system sends a hardware trigger signal to the virtual detector, which returns the pre-stored XRD spectrum data. These data are output through the AreaDetector module.

[0160] Step 4.2, data archiving and standardized storage.

[0161] After data acquisition is completed, the system will structure all data according to the HDF5 / NeXus standard. The original spectrum data is saved in the form of N×2048 array in the specified path, and all related metadata, including motor coordinate history, original experiment identification and other information will be recorded completely.

[0162] This embodiment solves the large scientific data loading delay problem through the block-memory mapping technology, combines standardized device virtualization and time sequence reproduction logic, and realizes high-fidelity reproduction of the XRD Mapping experiment. Its technical scheme focuses on the "efficiency, standardization and scene" demand in the field of scientific research information processing, and can directly support the compatibility test and optimization of the data acquisition software of the synchrotron radiation beamline.

[0163] The above specific embodiments further illustrate the purpose, technical solutions and advantages of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A virtual beamline software platform for advanced synchrotron radiation sources, characterized in that: The platform comprises a three-layer architecture: a user interaction layer, a virtual device layer, and a data management layer. It supports dual working modes: full simulation experiments based on physical models and data reproduction based on historical experimental datasets. It also enables a complete closed-loop virtualization process, from experimental design and virtual device control to virtual data acquisition and analysis, entirely independent of physical hardware. The user interaction layer, implemented based on the Bluesky experimental control framework, is used for orchestrating experimental processes and sending control commands to the virtual device layer. The virtual device layer includes a virtual experimental station engine, a device virtualization module, a data simulation module, and a data reproduction module. The device virtualization module abstracts the physical equipment of a synchrotron radiation beamline station into input / output controller instances conforming to the EPICS standard. Each instance receives control commands and returns data through process variables. The data simulation module has a built-in high-fidelity physical model for simulating synchrotron radiation experimental data, used to generate simulation data in full simulation experimental mode. This high-fidelity physical model includes a two-dimensional elliptic Gaussian function model for simulating light intensity distribution and a three-dimensional projection integral model based on the Shepp-Logan model for simulating CT projection data. The data reproduction module loads and replays historical experimental datasets by calling the data management layer in data reproduction mode. The virtual experimental station engine schedules the device virtualization module according to the selected working mode, enabling it to obtain data from the data simulation module or the data reproduction module and respond to the upper layer through a unified process variable interface. The data management layer employs block reading and memory mapping technology for efficient storage and access of historical datasets.

2. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental orchestration in the user interaction layer is specifically implemented by object-oriented encapsulation of the process variables PV of the virtual device through the Ophyd library. The encapsulation encapsulates the virtual detector as the VirtualAreaDetector class, which has a built-in dark current noise injection method, and the virtual motor as the VirtualEpicsMotor class, which supports the configuration of the backflash difference parameter. The encapsulated VirtualAreaDetector class and VirtualEpicsMotor class establish a two-way binding with the underlying PV through the EPICS Channel Access protocol, so that Bluesky experimental orchestration commands can directly drive the virtual device.

3. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The user interaction layer provides both graphical and programmatic interfaces for defining experimental parameters and procedures. In data reproduction mode, it can automatically parse the experimental time series metadata embedded in the historical dataset and generate the corresponding experimental instruction sequence.

4. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The physical devices abstracted by the device virtualization module include virtual detectors, virtual motors, and virtual optical devices; wherein, the virtual detectors include zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors, the virtual motors include linear translation motors and angular rotation motors, and the virtual optical devices include at least a virtual dual-crystal monochromator, a virtual electric four-blade slit, and a virtual beam position probe.

5. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The physical model embedded in the data simulation module can inject Poisson noise into the generated simulation data to simulate the dark current of the detector.

6. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, When loading and replaying historical experimental datasets, the data reproduction module performs the following operations: calls down to the high-speed data processing module of the data management layer to obtain the data stream optimized by block reading and memory mapping technology; automatically parses the experimental metadata and acquisition logic embedded in the historical experimental dataset, and generates the corresponding data acquisition script to be uploaded to the user interaction layer; and drives the virtual device to execute the data reproduction process according to the original experimental sequence.

7. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The data management layer includes an efficient data management module and a high-speed data processing module; The high-efficiency data management module is used to parse the metadata structure and device configuration information of the historical dataset, and the high-speed data processing module is used to perform high-performance data reading operations based on block indexing and memory mapping.

8. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The block reading and memory mapping technology of the data management layer specifically includes: pre-building a physical address mapping table of data blocks for HDF5 / NeXus files, implementing zero-copy data reading through the memory mapping function of the operating system, and using a double-buffered pipeline mechanism to pre-read subsequent data blocks to ensure the continuity of access.

9. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental methods in the physical model-based full simulation experimental mode include: Prepare the runtime environment, deploy the basic software environment, and initialize the user interaction layer; The virtual device service starts, launching a virtual device instance and configuring parameters according to the experiment mode and type. Configure data acquisition tasks, define control parameters, acquisition scripts, and data saving settings; The virtual experiment process is executed by driving virtual devices to perform data acquisition operations according to the orchestration scheme, generating and storing simulation data in real time.

10. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental method for reproducing dual working modes based on historical experimental datasets includes: Prepare the reproduction environment, deploy the basic software environment, and initialize the user interaction layer; Import historical data, loading historical datasets in HDF5 / NeXus format aligned by timestamps; Virtual device instance creation: Automatically create and initialize virtual devices of the corresponding type based on historical data characteristics; The data reproduction process is executed by automatically generating a collection script based on historical data, which drives the virtual device to reproduce the experimental process in the original time sequence.

Images