Method, device and equipment for configuration management of material calculation and visualization software set for supercomputer and medium

CN123011307APending Publication Date: 2026-10-30国家超级计算天津中心
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611477173.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-09-22
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0004]这套流程的核心问题是,计算环节依赖的软件版本与可视化环节的解析工具版本各自挂靠在全局环境中,既容易出现多版本依赖库冲突导致计算报错,也会因计算输出文件的解析依赖与生成时的环境不一致,导致可视化工具无法正常读取结果

Benefits of technology

[0005]为了解决上述技术问题或者至少部分地解决上述技术问题,本申请提供了一种面向超算的材料计算与可视化软件集的配置管理方法、装置、设备及介质。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123011307A_ABST
    Figure CN123011307A_ABST
Patent Text Reader

Abstract

The embodiment of the application provides a kind of material calculation and visualization software set configuration management method, device, equipment and medium for supercomputer, comprising: constructing software warehouse, archiving the dependent library and adaptation configuration information of calculation software and supporting visualization software according to version and recording the index relationship of software version and running resource, so that each version resource can be independently positioned and called.Response software selection instruction, independent running space is constructed with the current supercomputer system running environment and the basic environment of supercomputer system, the selected version dependent library and environment variable are loaded in the running space, and a job submission file is generated.After calculation, continue to call the visualization tool and graphic rendering resource matched with the calculation result in the running space for analysis rendering, and remotely transmit the visualization image to user terminal for display.No need to migrate files or switch dependent versions across environments, both avoid multi-version dependency and global library conflict, and eliminate the analysis failure caused by inconsistent calculation and visualization environment.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a configuration management method, apparatus, device and medium for a set of materials calculation and visualization software for supercomputing. Background Technology

[0002] Materials research and development now widely relies on multi-scale computational simulations, covering areas such as microscopic first-principles calculations, molecular dynamics simulations, mesoscopic phase diagram thermodynamic calculations, phase field evolution, and macroscopic finite element simulations. This requires the use of computational software of different scales, such as VASP, LAMMPS, OpenCalphad, OpenPhase, and OpenFoam, as well as visualization tools like P4VASP, VMD, OVITO, and Paraview. Materials computational tasks typically run on supercomputers, but different supercomputing clusters have different operating system versions, scheduling frameworks, and hardware architectures. Furthermore, the rapid iteration of materials computational software versions and the complex nature of its dependencies have kept deployment at a high level.

[0003] Currently, the material calculation process on supercomputers is basically fixed: administrators pre-install a small number of commonly used software versions in the system's global directory. After logging into the node, users manually load the corresponding environment using the `module` command, write their own job submission files adapted to the current cluster scheduling framework, submit the task, and wait for the calculation to complete. Afterward, users need to download the result files to their local machine and use locally installed post-processing tools to perform visualization analysis. A few platforms offer web-based visualization functions, but their built-in visualization tools are still fixed versions pre-installed by the platform and are not related to the actual operating environment of the computation process.

[0004] The core problem with this process is that the software versions required for the computation stage and the parsing tool versions required for the visualization stage are each attached to a global environment. This can easily lead to conflicts between multiple versions of dependency libraries, causing computational errors, and the visualization tool may be unable to read the results correctly because the parsing dependencies of the computation output file are inconsistent with the environment at the time of generation. Summary of the Invention

[0005] To solve the above-mentioned technical problems, or at least partially solve them, this application provides a configuration management method, apparatus, device, and medium for a materials calculation and visualization software suite for supercomputing.

[0006] This application provides a configuration management method for a materials calculation and visualization software suite for supercomputing, the method comprising: This application provides a configuration management method for a set of materials computation and visualization software for supercomputing. This method includes archiving pre-compiled programs, dependency libraries, and adaptation configuration information of various versions of computation software and supporting visualization tools through a unified software repository, and establishing a version index. This allows different versions of the same software to be independently located and retrieved. When responding to a software selection command, the method first identifies the current supercomputing system's operating environment. Based on the matching relationship between the selected version's adaptation configuration information and the current environment, a separate runtime space belonging to the current task is constructed. Within this space, the corresponding version's dependency libraries and environment variables are loaded. Simultaneously, an executable job submission file is generated based on the resource requirements of the selected software and the current scheduling framework specifications. After the computation task is completed, the visualization tools and graphics rendering backend parsing results matching the computation software version are retrieved within this runtime space. The image stream is then pushed to the user terminal via remote rendering. The entire process eliminates the need to migrate files across environments or switch dependency versions, fundamentally avoiding conflicts between multiple version dependencies and the system's global library, and also eliminating parsing failures caused by inconsistencies between the computation generation environment and the visualization parsing environment.

[0007] This application embodiment also provides a configuration management device for a materials calculation and visualization software suite for supercomputing, the device comprising: The building unit is used to build software repositories, archive and calculate the runtime resources of software and supporting visualization software by version, and record the index relationship between software versions and runtime resources. The response unit is used to respond to the software selection instruction, determine the running resources of the selected software version according to the index relationship, and construct a running space independent of the supercomputing system's basic environment in combination with the current supercomputing system's running environment. In the running space, the dependent libraries and environment variables corresponding to the selected software version are loaded, and a job submission file is generated. The writing unit is used to submit the job submission file to the supercomputing scheduling system to execute the computing task, retrieve visualization tools and graphics rendering resources that match the computing results of the computing task from the software repository, and configure them in the running space. The calling unit is used to call the visualization tool within the running space to parse the calculation results, drive the graphics rendering resources to render the generated parsing results to generate a visualization image, and remotely transmit the rendered visualization image to the user terminal for display.

[0008] This application also provides an electronic device, which includes: a processor; a memory for storing executable instructions of the processor; the processor is configured to read the executable instructions from the memory and execute the instructions to implement the configuration management method for a supercomputing-oriented materials calculation and visualization software suite as provided in this application.

[0009] This application also provides a computer-readable storage medium storing a computer program for executing a configuration management method for a supercomputing-oriented materials calculation and visualization software suite as provided in this application. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this application will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0011] Figure 1 A flowchart illustrating a configuration management method for a materials calculation and visualization software suite for supercomputing, provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a configuration management device for a supercomputing-oriented materials calculation and visualization software suite provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0013] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0014] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0015] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0016] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0017] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0018] Materials research and development now widely relies on multi-scale computational simulations, covering areas such as microscopic first-principles calculations, molecular dynamics simulations, mesoscopic phase diagram thermodynamic calculations, phase field evolution, and macroscopic finite element simulations. This requires the use of computational software of different scales, such as VASP, LAMMPS, OpenCalphad, OpenPhase, and OpenFoam, as well as visualization tools like P4VASP, VMD, OVITO, and Paraview. Materials computational tasks typically run on supercomputers, but different supercomputing clusters have different operating system versions, scheduling frameworks, and hardware architectures. Furthermore, the rapid iteration of materials computational software versions and the complex nature of its dependencies have kept deployment at a high level.

[0019] Currently, the material calculation process on supercomputers is basically fixed: administrators pre-install a small number of commonly used software versions in the system's global directory. After logging into the node, users manually load the corresponding environment using the `module` command, write their own job submission files adapted to the current cluster scheduling framework, submit the task, and wait for the calculation to complete. Afterward, users need to download the result files to their local machine and use locally installed post-processing tools to perform visualization analysis. A few platforms offer web-based visualization functions, but their built-in visualization tools are still fixed versions pre-installed by the platform and are not related to the actual operating environment of the computation process.

[0020] The core problem with this process is the lack of an independent runtime environment for each individual computation task, spanning the entire chain from environment configuration and task execution to result visualization. The software versions required for the computation phase and the parsing tool versions required for visualization are each hosted in the global environment. This easily leads to conflicts between different dependency libraries, causing computational errors, and also results in the visualization tool being unable to correctly read the results because the parsing dependencies of the computation output files are inconsistent with the environment at the time of generation.

[0021] In view of this, this application provides a configuration management method for a set of materials calculation and visualization software for supercomputing. This method includes archiving pre-compiled programs, dependency libraries, and adaptation configuration information of various versions of computing software and supporting visualization tools through a unified software repository, and establishing a version index, so that different versions of the same software can be independently located and retrieved. When responding to a software selection instruction, the method first identifies the current supercomputing system's operating environment. Based on the matching relationship between the selected version's adaptation configuration information and the current environment, a separate runtime space belonging to the current task is constructed. Within this space, the corresponding version's dependency libraries and environment variables are loaded. Simultaneously, an executable job submission file is generated based on the resource requirements of the selected software and the current scheduling framework specifications. After the calculation task is completed, the visualization tools and graphics rendering backend parsing results matching the computing software version are retrieved within this runtime space. The image stream is pushed to the user terminal via remote rendering. The entire process eliminates the need to migrate files across environments or switch dependency versions, fundamentally avoiding conflicts between multiple version dependencies and the system's global library, and also eliminating parsing failures caused by inconsistencies between the computational generation environment and the visualization parsing environment.

[0022] To address the aforementioned issues, this application provides a configuration management method for a materials calculation and visualization software suite for supercomputing. The method will be described below with reference to specific embodiments.

[0023] Figure 1 This is a flowchart illustrating a configuration management method for a supercomputing-oriented materials calculation and visualization software suite, provided in an embodiment of this application. This method can be executed by a configuration management device for the supercomputing-oriented materials calculation and visualization software suite, wherein the device can be implemented in software and / or hardware, and is generally integrated into an electronic device. Figure 1 As shown, the method includes: S101: Build a software repository, archive the runtime resources of the software and its supporting visualization software by version, and record the index relationship between the software version and the runtime resources.

[0024] For example, a software repository can be a centralized, tiered storage facility where configuration management electronics are pre-deployed on shared storage or high-speed storage nodes of a supercomputing system, used for unified archiving and storage of resources of various versions. The archived objects here include materials calculation software and its associated visualization software.

[0025] Materials computational software can be categorized into three levels based on computational scale: microscopic, mesoscopic, and macroscopic. For example, the microscopic level can include first-principles calculation software and molecular dynamics simulation software; the mesoscopic level can include phase diagram calculation software and phase field simulation software; and the macroscopic level can include finite element simulation software. Supporting visualization software can include post-processing tools and their dedicated plugins.

[0026] In some possible implementations, version-archived runtime resources can specifically include three categories: pre-compiled programs, dependency libraries, and adaptation configuration information. Pre-compiled programs refer to executable binary files that have been compiled and optimized for specific supercomputer CPU architectures (such as x86_64, ARM) and interconnect networks (such as InfiniBand, RoCE), allowing users to run them directly without needing to configure complex compilation environments and perform repeated compilations in their personal settings. Dependency libraries can include low-level mathematical libraries (such as MKL, OpenBLAS), compiler runtimes (such as GCC Lib, CUDA Toolkit), MPI parallel libraries (such as OpenMPI, Intel MPI), and specific dynamic link libraries required for software operation. Adaptation configuration information can include environment variable templates for this version of the software (such as LD_LIBRARY_PATH, PATH setting rules), resource request suggestions (such as empirical values ​​for single-core memory usage), job script templates, and a list of compatible scheduling frameworks (such as Slurm, PBS, LSF). These pre-compiled programs, dependency libraries, and adaptation configuration information constitute the aforementioned runtime resources, with each version archived independently and without overwriting the others.

[0027] The indexing relationship between software versions and runtime resources can be recorded using a structured mapping table built into the unified software repository (such as an SQLite database or key-value store system), which is the aforementioned software version index. Each record in the table can uniquely correspond to a software version, and the fields of the record can include, but are not limited to: software name, version number, applicable scale, function category, compatible system identifier, dependency list, parallel compilation parameters, and resource storage path. The purpose of this indexing relationship is to establish a strong association between the software version and its corresponding resource path in physical storage, thereby avoiding users manually traversing complex storage directories to find the required resources.

[0028] In some possible implementations, the software repository can also provide a standardized search interface. This interface can support multi-dimensional combined queries; for example, it can support searching by software name (e.g., entering "VASP") to return a list of all historical versions of the software; it can support searching by applicable scale (e.g., selecting "microscopic") to return a list of all available computational and visualization software at that level; and it can support searching by functional category (e.g., selecting "structure optimization" or "molecular dynamics") to return a list of software with that specific function. Each entry in the search results can include the precise storage path of that version of the resource. Based on the search results, the configuration management electronic device can directly retrieve at least one of the pre-compiled programs, dependency libraries, and adaptation configuration information from the corresponding directory of the software repository according to the storage path recorded in the index relationship, without requiring the user to manually upload or compile the software, nor requiring the user to know the actual physical storage location of the resources.

[0029] S102: In response to the received software selection instruction, determine the running resources of the selected software version according to the index relationship, and construct a running space independent of the supercomputing system's basic environment in combination with the current supercomputing system's running environment. Load the dependency libraries and environment variables corresponding to the selected software version in the running space and generate a job submission file.

[0030] The software selection command can be a JSON-formatted request submitted by the user through a web-based front-end interface or command-line interface. This command can carry at least three key pieces of information: the name of the software to be used, its version number, and the type of computational task (e.g., static self-consistent computation, molecular dynamics simulation). After receiving the command, the electronic device can use the software name and version number as a combined primary key, locate the corresponding record according to the aforementioned index relationship, thereby determining the runtime resources of the selected software version, and retrieving the adaptation configuration information for that version from the software repository.

[0031] When identifying the operating environment of the current supercomputing system, electronic devices can obtain environmental parameters by calling system APIs or reading specific files. For example, they can obtain the operating system distribution and kernel version by reading the / etc / os-release file, obtain the type and version of the cluster scheduling framework by executing the sinfo or qstat command, obtain the CPU architecture, number of cores and GPU model by parsing the output of / proc / cpuinfo and nvidia-smi, and obtain the total amount of available memory and network topology by querying the node status database of the scheduling system.

[0032] Runtime space can be an isolated environment created by configuration management electronics for the current running session. This runtime space is logically completely isolated from the supercomputing system's underlying environment and the runtime spaces of other users. Process IDs, mount points, file system views, and environment variables in different spaces are not visible to each other, thereby avoiding dependency library conflicts between multiple versions of software at the source.

[0033] In some possible implementations, constructing a runtime space independent of the supercomputing system's underlying environment can specifically include: creating a file system view and process namespace independent of the current running session. Loading the dependency libraries and environment variables corresponding to the selected software version within the runtime space can specifically include: writing the dependency library paths of the selected software version into the environment variable priority sequence within the file system view (e.g., prioritizing path insertion in ld.so.conf or modifying the RPATH of the binary file using the patchelf tool), and allocating an independent process ID space for the processes of the selected software version based on the process namespace.

[0034] For example, a file system view can be an independent directory within the runtime space. Electronic devices can mount the dependency library directories of the selected software version (e.g., / repo / software / VASP / 6.3.0 / lib), precompiled program directories (e.g., / repo / software / VASP / 6.3.0 / bin), and the user's current working directory all within this view. Process namespaces ensure that processes started within this space have independent PID 1, preventing them from viewing or manipulating processes in the base environment or other namespaces, and preventing them from sending signals to the supercomputing system's base daemons, thus avoiding accidental impacts on system stability. Controlling the environment variable priority sequence ensures that the software loads the corresponding version of the dependency libraries from the repository first, without being overwritten by libraries with the same name in the system's global directory or other versions. The entire loading process only modifies the environment variable configuration files of the current runtime space, without modifying the global configuration files of the supercomputing system's base environment (e.g., / etc / profile or .bashrc in the user's root directory), therefore it will not interfere with the runtime environment of other users or other concurrent tasks.

[0035] In some possible implementations, the method may further include: Based on the functional characteristics of the selected software version, determine its default calculation parameter range. Combined with the available hardware resources of the current supercomputing system, allocate the number of CPU cores, GPU cards, memory capacity, and parallel processes to the computing tasks in the running space, and write the allocation results into the job submission file.

[0036] For example, the functional characteristics of different materials computing software result in significantly different hardware resource requirements. First-principles calculations (DFT) typically require high memory bandwidth and single-core floating-point performance; large-scale molecular dynamics (MD) calculations, on the other hand, require high multi-core parallel efficiency, GPU acceleration, network latency, and system storage capacity. The electronic device can determine a recommended default range of computational parameters by reading historical benchmark data or official performance white papers from the software's adaptation configuration information, based on the selected software's functional classification. This range can include recommended values ​​for the number of parallel processes, memory usage, and MPI call version. The electronic device can also query the supercomputing scheduling system for the current status of available hardware resources, obtaining information such as the number of idle CPU cores, total idle memory, number of idle GPUs, and network load between nodes. When allocating resources, electronic devices can prioritize meeting the minimum resource requirements of the selected software. If the available resources are insufficient to support the minimum requirements, the electronic devices can return an alarm message to the user, prompting the user to wait for resource release or adjust the task size. If the available resources are sufficient, the electronic devices can try to match the optimal resource configuration within the scope allowed by the scheduling framework, avoiding excessive resource requests that cause tasks to queue for too long, or insufficient resource requests that cause a significant drop in computing performance.

[0037] In some possible implementations, generating the job submission file may specifically include: generating a job submission file that includes the environment variable configuration corresponding to the selected software version, MPI parallel startup parameters, and task execution commands, and the file conforms to the current supercomputing system's scheduling framework syntax specification.

[0038] For example, the job submission file can be a shell script or a dedicated script for a specific scheduling framework (such as the .slurm file for Slurm, or the .pbs file for PBS). This file can include three core parts: an environment variable configuration section, used to write the paths to dependent libraries, the main program path, and temporary directories within the runtime space; an MPI parallel startup parameter section, used to specify the number of MPI processes (-np), process distribution rules (such as -map-by socket), communication protocol type (such as UCX_TLS=rc,sm), and network interface binding information (such as --bind-to ib0) to adapt to the multi-node communication architecture of the supercomputer; and a task execution command section, used to specify the absolute path of the main program, input filenames (such as POSCAR for VASP software, in.lmp for LAMMPS software), output file path, and specific runtime parameters (such as -npool 4 for QuantumESPRESSO software). The electronic device can automatically match the corresponding script template based on the previously identified scheduling framework type, filling the template with environment variables, MPI parameters, and execution commands to generate a script that can be directly submitted.

[0039] S103: Submit the job submission file to the supercomputing scheduling system to execute the computing task. After the computing task is completed, retrieve the visualization tools and graphics rendering resources that match the computing results of the computing task from the software repository and configure them in the running space.

[0040] For example, after receiving a job submission file, the supercomputing scheduling system can add the task to the corresponding queue for scheduling according to the resource amount requested in the script. Once the resources are ready, the scheduling system will allocate computing nodes and start the computing task. During the execution of the computing task, the generated computing results (such as OUTCAR, traj.xtc, phase_field.dat) can be written to the user's working directory in the runtime space in real time. Electronic devices can detect whether the task has been completed by monitoring the task status code of the scheduling system (such as JOB_COMPLETE in Slurm) or polling the size changes of the result file. After the task is completed, the electronic device can automatically trigger the post-processing process without requiring the user to manually check the task status or download the result file.

[0041] In some possible implementations, retrieving visualization tools and graphics rendering resources from the software repository that match the calculation results may specifically include: After the computation task is completed, a multi-format parsing kernel pre-installed in the software repository is invoked to identify the file format of the computation result within the runtime space; based on predefined format association rules, a target visualization tool and its version that support the file format are matched according to the file extension or data structure identifier of the computation result; based on the matching result, the target visualization tool and its dependent libraries and graphics rendering backend are retrieved from the software repository as the matched visualization tool and graphics rendering resources.

[0042] The multi-format parsing kernel can be a lightweight, headless, general-purpose parsing module pre-installed in a software repository. This kernel can embed the output file format definitions of dozens of mainstream materials calculation software programs and associate each visualization tool with its supported file formats. For example, it can recognize OUTCAR and CHGCAR files generated by VASP, dump files generated by LAMMPS, and .rst files generated by ANSYS. The kernel can extract key information from these files, such as atomic coordinates, lattice parameters, energy values, stress tensors, and trajectory frame data, and convert them into an intermediate data format common to visualization tools. The multi-format parsing kernel can also embed a format association table to carry the aforementioned format association rules; for example, the structural visualization tool OVITO supports parsing .cif, .poscar, and .xyz formats; the trajectory playback tool VMD supports parsing .trj, .xtc, and .dcd formats; and the data plotting tool Grace supports parsing .out, .log, and .dat formats.

[0043] When matching visualization tools, the electronic device first reads the file extension of the calculation results (e.g., .xtc) and searches for a list of tools that support that extension based on a format association table. If the file extension is mistakenly changed or multiple tools support the same extension (e.g., a .dat file can be both text and image data), the electronic device can further read the magic number or specific data structure identifier field in the header of the result file. For example, the header of a VASP OUTCAR file typically includes a version identifier string starting with "vasp.", and the header of a LAMMPS dump file includes the identifier "ITEM:TIMESTEP". The electronic device can accurately match the unique visualization tool and its best compatible version based on these data structure identifiers, thus avoiding parsing failures caused by incorrect file extensions.

[0044] Visualization tools can be specialized software retrieved from software repositories for post-processing of material calculation results. For example, VESTA or OVITO can be used for visualizing crystal structures; VMD or PyMOL can be used for visualizing molecular dynamics trajectories; and Grace or Matplotlib can be used for plotting data curves. The graphics rendering backend is the graphics processing component on which the visualization tool depends. It can include server-side implementation libraries of graphics APIs such as OpenGL and Vulkan (e.g., mesa-libGL), used to perform heavy graphics rasterization calculations on the supercomputing server without requiring the user terminal to have a high-performance graphics card. The dependent libraries and graphics rendering backend of the target visualization tool retrieved here constitute the aforementioned graphics rendering resources.

[0045] The computing device can load visualization tools, their dependent libraries, and graphics rendering backend into the aforementioned existing runtime space, i.e., configure them within that runtime space. Since the runtime space is not destroyed after the computation task is completed, the already built isolated environment can be reused directly without recreating the runtime space or reconfiguring dependencies. This reuse mechanism ensures environmental consistency between the computation and visualization phases, guaranteeing that the visualization tools can recognize all temporary files and dependent library versions generated during the computation phase, thereby avoiding result file parsing failures due to environmental differences (such as ABI incompatibility caused by library version upgrades).

[0046] S104: Within the operating space, the visualization tool is invoked to parse the calculation results, and the graphics rendering resources are driven to render the generated parsing results to generate a visualization image. The rendered visualization image is then remotely transmitted to the user terminal for display.

[0047] In some possible implementations, the step of calling the visualization tool to parse the calculation results and drive the graphics rendering resources may specifically include: within the runtime space, using the intermediate data extracted by the parsing kernel to drive the visualization tool to perform scene rendering, and having the graphics rendering backend convert the vector graphics data into bitmap frames to generate the visualization image.

[0048] The remote transmission of visualized images to user terminals for display can include two optional implementation modes to adapt to different network conditions and user needs.

[0049] For example, the first is the lightweight web image streaming push mode. In this mode, the electronic device calls a graphics rendering backend (such as a software-based OpenGL software renderer or a hardware-based Vulkan GPU renderer) within its runtime space to render the visualized image. The rendered image frames are encoded into highly compressed H.264 or WebP format streams and pushed to the user's browser via the HTTP / WebSocket protocol for display. The user's terminal does not need to install any plugins or client software; a modern browser is sufficient to view the results.

[0050] The second mode is automatic VNC forwarding. In this mode, a lightweight VNC (Virtual Network Computing) server is automatically started within the runtime environment, and the server's default port (such as 5900) is encrypted and forwarded to the user terminal via an SSH tunnel. Users can connect to the visual tool desktop within the runtime environment using a local VNC client (such as RealVNC or TightVNC) to obtain a near-native operating experience, including full window manager support and high-resolution rendering.

[0051] These two modes can be chosen by the user based on the current network bandwidth, latency, and whether complex interactive operations are required.

[0052] In some possible implementations, the method may further include: The system receives interactive commands from the user terminal based on the visualized image, and forwards these commands to the visualization tool within the runtime space. This drives the visualization tool to update the visualized image in response to the commands, and then remotely transmits the updated image back to the user terminal. The interactive commands returned by the user terminal may include, but are not limited to: left-clicking and dragging to rotate the viewpoint, right-clicking to select atoms, using the scroll wheel to zoom in and out of the scene, using keyboard shortcuts to switch display modes (e.g., showing / hiding cell borders), and specific viewpoint rotation or slicing operations. Upon receiving these commands, the electronic device forwards them to the visualization tool within the runtime space, causing the tool to recalculate scene lighting, projection matrices, and geometric data, re-render and generate an updated visualized image, and then remotely transmits the updated image back to the user terminal, thus achieving smooth, real-time interactive visualization operations.

[0053] This application embodiment archives pre-compiled programs, dependency libraries, and adaptation configuration information of various versions of computing software and supporting visualization tools in a unified software repository and establishes a version index, enabling different versions of the same software to be independently located and retrieved. When responding to a software selection instruction, the current supercomputing system's operating environment is first identified. Based on the matching relationship between the selected version's adaptation configuration information and the current environment, a separate running space belonging to the current task is constructed. Within this space, the corresponding version's dependency libraries and environment variables are loaded. Simultaneously, an executable job submission file is generated by combining the resource requirements of the selected software and the current scheduling framework specifications. After the computing task is completed, the visualization tools and graphics rendering backend parsing results matching the computing software version are still retrieved within this running space. The image stream is pushed to the user terminal through remote rendering. The entire process does not require cross-environment file migration or dependency version switching, fundamentally avoiding conflicts between multiple version dependencies and the system's global library, and also eliminating parsing failures caused by inconsistencies between the computing generation environment and the visualization parsing environment.

[0054] To implement the above embodiments, this application also proposes a configuration management electronic device for a set of materials calculation and visualization software for supercomputing.

[0055] Figure 2 This is a schematic diagram of a configuration management electronic device for a supercomputing-oriented materials calculation and visualization software suite, provided as an embodiment of this application. This electronic device can be implemented by software and / or hardware, and is generally integrated into an electronic device. For example... Figure 2 As shown, the electronic device includes: Building unit 210 is used to build a software repository, archive the running resources of the software and its supporting visualization software by version, and record the index relationship between the software version and the running resources.

[0056] The response unit 220 is used to respond to the software selection instruction, determine the running resources of the selected software version according to the index relationship, and construct a running space independent of the supercomputing system's basic environment in combination with the current supercomputing system's running environment. In the running space, it loads the dependency libraries and environment variables corresponding to the selected software version and generates a job submission file.

[0057] The writing unit 230 is used to submit the job submission file to the supercomputing scheduling system to execute the computing task, retrieve visualization tools and graphics rendering resources that match the computing results of the computing task from the software repository, and configure them in the running space.

[0058] The calling unit 240 is used to call the visualization tool within the running space to parse the calculation results, drive the graphics rendering resources to render the generated parsing results to generate a visualization image, and remotely transmit the rendered visualization image to the user terminal for display.

[0059] The configuration management electronic device for the supercomputing-oriented materials calculation and visualization software set provided in the embodiments of this application can execute the configuration management method for the supercomputing-oriented materials calculation and visualization software set provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method.

[0060] To implement the above embodiments, this application also proposes a computer program product, including a computer program / instruction, which, when executed by a processor, implements the configuration management method for the supercomputing-oriented materials calculation and visualization software set in the above embodiments.

[0061] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0062] The following is a detailed reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing the electronic device 300 in the embodiments of this application. The electronic device 300 in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0063] like Figure 3 As shown, the electronic device 300 may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a memory 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processor 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0064] Typically, the following electronic devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0065] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program including program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from memory 308, or installed from ROM 302. When the computer program is executed by processor 301, it performs the functions defined in the configuration management method for a supercomputing-oriented materials calculation and visualization software suite according to embodiments of this application.

[0066] It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, electronic device, or apparatus, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium that includes or stores a program, which can be used by or in conjunction with an instruction execution system, electronic device, or apparatus. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, electronic device, or apparatus. The program code included on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0067] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0068] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0069] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the aforementioned configuration management method for the supercomputing-oriented materials calculation and visualization software suite.

[0070] Electronic devices can be programmed with computer program code in one or more programming languages ​​or a combination thereof to perform the operations of this application. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0071] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0072] The units described in the embodiments of this application can be implemented in software or hardware. The names of the units are not, in some cases, limiting the scope of the unit itself.

[0073] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0074] In the context of this application, a machine-readable medium can be a tangible medium that may include or store a program for use by or in conjunction with an instruction execution system, electronic device, or apparatus. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, electronic devices, or apparatuses, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0075] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

[0076] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0077] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A configuration management method for a materials calculation and visualization software suite for supercomputing, characterized in that, include: Build a software repository, archive and calculate the runtime resources of the software and its supporting visualization software by version, and record the index relationship between the software version and the runtime resources; In response to the software selection instruction, the running resources of the selected software version are determined according to the index relationship, and a running space independent of the supercomputing system's basic environment is constructed in combination with the current supercomputing system's running environment. The dependency libraries and environment variables corresponding to the selected software version are loaded in the running space, and a job submission file is generated. The job submission file is submitted to the supercomputing scheduling system to execute the computing task. Visualization tools and graphics rendering resources that match the computing results of the computing task are retrieved from the software repository and configured in the running space. Within the operating space, the visualization tool is invoked to parse the calculation results, and the graphics rendering resources are driven to render the generated parsing results to produce a visualization image. The rendered visualization image is then remotely transmitted to the user terminal for display.

2. The method according to claim 1, characterized in that, The runtime resources include at least one of the following: pre-compiled programs, dependency libraries, and adaptation configuration information; the fields of the index relationship record include software name, applicable scale, function category, adaptation system identifier, dependency list, and parallel compilation parameters; the software repository provides a search interface, which supports searching by software name, applicable scale, or function category, and supports retrieving at least one of the following: pre-compiled programs, dependency libraries, and adaptation configuration information of the corresponding version based on the search results.

3. The method according to claim 1, characterized in that, The aforementioned construction of an operating space independent of the supercomputing system's basic environment includes: Creates a file system view and process namespace independent of the currently running session; The loading of the dependency libraries and environment variables corresponding to the selected software version within the runtime space includes: Write the dependency library paths of the selected software version into the environment variable priority sequence within the file system view, and allocate an independent process ID space for the process of the selected software version based on the process namespace.

4. The method according to claim 1, characterized in that, The method further includes: Determine the default calculation parameter range based on the functional characteristics of the selected software version; The system queries the available hardware resource status of the current supercomputing system, and allocates the number of CPU cores, GPU cards, memory capacity, and parallel processes to the computing task based on the default computing parameter range and the available hardware resource status. The allocation results are then written to the job submission file. Submitting the job submission file to the supercomputing scheduling system for computational task execution includes: The job submission file containing the allocation results is submitted to the supercomputing scheduling system to execute the computing task.

5. The method according to claim 1, characterized in that, The job submission file includes the environment variable configuration corresponding to the selected software version, MPI parallel startup parameters and task execution commands, and conforms to the current supercomputing system's scheduling framework syntax specifications. Submitting the job submission file to the supercomputing scheduling system for computational task execution includes: The supercomputing scheduling system parses the job submission file, and based on the parsed environment variable configuration and MPI parallel startup parameters, starts the pre-compiled program of the selected software version in the running space, and drives the pre-compiled program to execute the computing task according to the task execution command.

6. The method according to claim 1, characterized in that, The step of retrieving visualization tools and graphics rendering resources from the software repository that match the computation results of the computation task includes: After the computation task is completed, a multi-format parsing kernel pre-installed in the software repository is invoked to identify the file format of the computation result within the runtime space. The multi-format parsing kernel associates each visualization tool with its supported file formats. Based on predefined format association rules, the target visualization tools and their versions that support the file format are matched according to the file suffix or data structure identifier of the calculation result. Based on the matching results, the target visualization tool and its dependent libraries and graphics rendering backend are retrieved from the software repository as the matching visualization tool and graphics rendering resources.

7. The method according to claim 1, characterized in that, The method further includes: The system receives an interactive instruction returned by the user terminal based on the visualization image, sends the interactive instruction to the visualization tool in the runtime space, drives the visualization tool to respond to the interactive instruction and update the visualization image, and remotely transmits the updated visualization image to the user terminal.

8. A configuration management device for a materials calculation and visualization software suite for supercomputing, characterized in that, include: The building unit is used to build software repositories, archive and calculate the runtime resources of software and supporting visualization software by version, and record the index relationship between software versions and runtime resources. The response unit is used to respond to the software selection instruction, determine the running resources of the selected software version according to the index relationship, and construct a running space independent of the supercomputing system's basic environment in combination with the current supercomputing system's running environment. In the running space, the dependent libraries and environment variables corresponding to the selected software version are loaded, and a job submission file is generated. The writing unit is used to submit the job submission file to the supercomputing scheduling system to execute the computing task, retrieve visualization tools and graphics rendering resources that match the computing results of the computing task from the software repository, and configure them in the running space. The calling unit is used to call the visualization tool within the running space to parse the calculation results, drive the graphics rendering resources to render the generated parsing results to generate a visualization image, and remotely transmit the rendered visualization image to the user terminal for display.

9. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 7.