A multi-terminal portable simulation software adaptation implementation method and device and medium

Abstract

The application discloses a multi-terminal portable simulation software adaptation implementation method and device and medium, and the method comprises the following steps: providing an interactive view to a user to collect user input through an interactive view adaptation layer, and converting the user input into a structured parameter object through an algorithm parameter description layer; serializing a unified task request object of a task type identifier, the structured parameter object, a trigger time, an execution target and a state callback address, and calling a corresponding algorithm module for execution after determining an execution back end in combination with the unified task request object; analyzing original calculation results of the execution back end into a unified result object and displaying the unified result object through an interactive view through a result state backfill layer; and generating target terminal configuration products of the unified task request object, the structured parameter object, the execution back end and backfill results according to a compilation environment of a system platform of the target terminal through a portable compilation adaptation layer. The application can greatly reduce the migration cost of industrial simulation software cross-end migration.

Description

Technical Field

[0001] This invention relates to the field of industrial algorithm simulation, and in particular to a method, apparatus and medium for adapting simulation software to multiple terminals. Background Technology

[0002] Most existing industrial simulation and scientific computing software are primarily desktop applications. In this form, users input data paths, select algorithm methods, set thresholds and iteration counts in a desktop window, and the same program directly calls the local solver, scripting environment, dynamic library, or external executable program to complete the calculation. This model is relatively straightforward when running on a single machine. However, when migrating these industrial simulation and scientific computing software from desktop to browser, remote server, command-line batch processing, or cloud computing, several issues arise: First, due to the high coupling between parameters and interface controls, parameter inconsistencies occur when migrating to other terminals. Second, desktop clients can access local file system platforms and local solvers, while browsers typically cannot directly access local dynamic libraries, external executables, or complete file system platforms; directly porting desktop logic requires extensive rewriting. Third, since local threads, external processes, command-line programs, and server queues usually have different state and error formats, the interactive interfaces on different terminals need to be handled separately for each execution method, increasing software maintenance costs. Fourth, because desktop clients rely on window system platforms, local solvers, Python runtimes, and dynamic libraries, while browsers rely on WebAssembly, WebGL, and HTTPAPI, dependency conflicts can occur during compilation and migration.

[0003] Therefore, there is an urgent need for a portable simulation software adaptation method to solve the problems that exist when migrating software across platforms. Summary of the Invention

[0004] In order to overcome the shortcomings of the prior art, one of the objectives of this invention is to provide a multi-platform portable simulation software adaptation method, which can solve the problem of high development costs when migrating simulation software across platforms in the prior art.

[0005] The second objective of this invention is to provide a multi-platform portable simulation software adaptation implementation device, which can solve the problem of high development costs when migrating simulation software across platforms in the prior art.

[0006] The third objective of this invention is to provide a computer-readable storage medium that can solve the problem of high development costs when migrating simulation software across different platforms in the prior art.

[0007] One of the objectives of this invention is achieved through the following technical solution: A method for adapting simulation software to multiple platforms, wherein the simulation software configuration method includes: Input collection steps: Provide an interactive view to the user through the interactive view adaptation layer to collect user input; the user input includes algorithm input, method selection, operation control, output settings, and result status; Parameter object conversion steps: The user input is extracted from the control variables of the interactive view through the algorithm parameter description layer to form a structured parameter object; the structured parameter object includes parameter fields, parameter types, default values, constraint ranges, version numbers, and import / export rules; The steps for generating a unified task request object are as follows: A task type identifier is generated based on the source of the task triggering event through the task orchestration bridging layer. The task type identifier, structured parameter object, trigger time, execution target, and status callback address are then serialized into a unified task request object. This unified task request object includes an algorithm object, an encapsulated algorithm identifier, an input resource description, client type, version number, and task information. The execution backend determination steps are as follows: the execution backend adaptation layer selects the execution backend based on the execution capabilities of the current terminal, and calls the corresponding algorithm module to execute based on the execution backend and the unified task request object; the execution backend is at least one of the following: local process, container, cloud function, remote queue, cluster scheduling system platform, and browser WebWorker; Result backfilling steps: The original calculation results returned by the execution backend are parsed into a unified result object through the result status backfilling layer, and the unified result object is backfilled into the interactive view for display; the unified result object includes result summary, numerical data, error information, calculation time and convergence index; the original calculation results include at least: log, error, result summary, result content and task status; Compilation steps: Obtain the target terminal through the portable compilation adaptation layer and derive the target terminal's system platform based on the target terminal, then select the compilation environment based on the target terminal's system platform; and generate the target terminal configuration artifact that can run on the target terminal by using the unified task request object, structured parameter object, execution backend, and backfill results based on the compilation environment.

[0008] Furthermore, the compilation step specifically includes: when the target terminal is a desktop terminal, the target terminal configuration output includes a desktop executable program and a project configuration file; when the target terminal is a command-line terminal, the target terminal configuration output includes a command-line terminal algorithm CLI and input / output JSON / CSV files; when the target terminal is a browser WebAssembly terminal, the target terminal configuration output includes the browser WebAssembly terminal's index html, JavaScript, wasm, and resource data files; when the target terminal is a server terminal, the target terminal configuration output includes the server terminal's task status JSON, result JSON, CSV, PLT, or ZIP result files.

[0009] Furthermore, the file format of the unified task request object includes JSON, XML, YAML, Protocol Buffers, Message Pack, and database; the interactive view includes a desktop real-time mode interface, a browser DOM interface, a Qt interface, and a command-line parameter interface; the browser DOM interface also includes a local web interface and a remote web console.

[0010] Furthermore, the parameter object conversion step also includes: configuring a mapping relationship between interactive space variables and field paths for each algorithm module to identify the field paths of parameter objects from interactive control variables, then extracting the corresponding user input based on the field paths, and finally converting the user input into structured parameter objects; specifically, configuring a mapping relationship between interactive space variables and field paths for each algorithm module includes: defining a field path string for each parameter of each algorithm module, using a hierarchical dot-matrix path format to distinguish input parameters, method parameters, and output parameters; defining data types for each parameter field, including numeric, string, boolean, enumeration, array, and file path types; defining constraint ranges for each parameter field, including upper and lower limits of numeric values, a list of enumeration optional values, regular expression validation rules, and a file type whitelist; defining default values ​​and version numbers for each parameter field for compatibility checks and missing value completion during parameter migration; and defining import / export rules, including serialization format, field mapping relationships, and version upgrade conversion rules.

[0011] Furthermore, the task triggering events include interface button triggering events, remote submission triggering events, command-line batch processing start-up triggering events, and server-side triggering events; the server-side triggering events include service interface triggering times, timed scheduling triggering events, and message queue triggering times; wherein, the interface button triggering event is specifically the event triggered when the user clicks the corresponding button on the algorithm parameter page on the desktop; the remote submission triggering event is specifically called in the button event on the browser; the command-line batch processing start-up triggering event refers to the event triggered when the same type of configuration is read and executed through a dedicated CLI program or batch processing entry.

[0012] Furthermore, the format of the unified task request object is at least any one of JSON, XML, YAML, Protocol Buffers, Messenger Pack, and database.

[0013] Furthermore, the execution capabilities of the current terminal specifically include: compilation platform identifier, whether it has local file system platform access capabilities, whether it can start local processes or solvers, whether it has browser file upload interface, whether it can access HTTP task API, and whether the target terminal has corresponding algorithm CLI or server-side runner.

[0014] Furthermore, the compilation step also includes: importing the target terminal configuration output into the corresponding target terminal so that the corresponding target terminal can reproduce the experimental conditions and task flow according to the same algorithm module, input resources, parameter settings, and backfill results; specifically, saving the generated parameter object and unified task request object as a configuration file, importing the configuration file into the corresponding target terminal, and then writing the parameter values ​​in the configuration file back to the interactive control in the interactive view according to the field path, and performing version compatibility verification and parameter constraint verification; and when the verification passes, regenerating the unified task request object on the target terminal according to the same algorithm module, input resources, parameter settings, and submitting it for execution, thereby realizing cross-terminal reproduction of the same algorithm task.

[0015] The second objective of this invention is achieved by the following technical solution: A multi-terminal portable simulation software adaptation implementation device includes a memory and a processor. The memory stores a simulation software adaptation implementation program that runs on the processor. The simulation software adaptation implementation program is a computer program. When the processor executes the simulation software adaptation implementation program, it implements the steps of a multi-terminal portable simulation software adaptation implementation method as one of the objectives of this invention.

[0016] The third objective of this invention is achieved by the following technical solution: A computer-readable storage medium storing a simulation software adaptation implementation program thereon, the simulation software adaptation implementation program being a computer program, wherein when the simulation software adaptation implementation program is executed by a processor, it implements the steps of a multi-terminal portable simulation software adaptation implementation method as one of the objectives of this invention.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention provides a reusable task flow for simulation software, enabling different running segments of the same algorithm module to be reproduced with consistent parameter semantics, task flow, and result backfilling, thereby reducing the development cost when migrating simulation software from the desktop to the browser, server, or command line. Attached Figure Description

[0018] Figure 1 The flowchart illustrates a method for adapting and implementing multi-terminal portable simulation software provided by this invention. Detailed Implementation

[0019] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments. It should be noted that, without conflict, the various embodiments or technical features described below can be arbitrarily combined to form new embodiments.

[0020] Example 1

[0021] Based on the shortcomings of existing industrial software, this invention provides a portable simulation software adaptation method, which enables the same algorithm module to be run on different terminals, and to reproduce parameter semantics, task flow and result backfilling methods, thereby reducing the development cost of migrating simulation software from desktop to other terminals.

[0022] like Figure 1 As shown, the present invention provides an embodiment of a portable simulation software adaptation implementation method, comprising: Step S1: Provide an interactive view to the user through the interactive view adaptation layer to collect user input; user input includes data source, algorithm module identifier, solution method, running control parameters and running trigger events.

[0023] This invention configures an interactive view adaptation layer within the system platform to configure the parameter interface of the interactive view, enabling interaction with the user and collecting user input. Specifically, users perform corresponding operations through the interactive view, such as: algorithm module entry, parameter page, file selection, run button, result preview, configuration import / export, etc. The system collects user input based on these operations. User input includes algorithm input, method selection, runtime control, output settings, and result status. Algorithm input includes the data source and the input parameters required for the specific algorithm; method selection includes the algorithm category and specific solution method; runtime control includes threshold parameters, iteration parameters, and runtime trigger events; output settings include output location and output format. Each algorithm module can configure corresponding specific parameter fields according to its own runtime requirements. The algorithm category is used to distinguish the type of algorithm, including matrix solving, equation solving, CFD, symbol recognition, physical constraint machine learning, etc. The specific solution method is used to distinguish CG, GMRES, AMG, or other algorithm options within the same module. In other words, multiple algorithm modules are stored and registered within the system platform, such as matrix solving, equation solving, batch equation processing, XFOIL-ENKF, CFD, symbolic regression, dimension fusion, PIML displacement field, and PIML topology optimization. Each algorithm module is associated with a set of parameter objects, including independent parameter fields, parameter types, default values, value ranges, constraints, and import / export rules. When a user selects an algorithm module through the interactive view, the interactive view loads and displays the corresponding parameter configuration content based on the association between the algorithm module and the parameter objects.

[0024] More preferably, the interactive view can adopt a desktop real-time mode interface, a browser DOM interface, a Qt interface, a command-line parameter interface, or a remote web console. The type of interactive view can be selected based on the target client type, operating environment, deployment method, and user configuration. For example, it can be specified by the user in a configuration file or parameter page, or it can be automatically determined by the interactive view adaptation layer based on the client type or operating environment. That is, the interactive view, according to its interface implementation method, includes a desktop real-time mode interface, a Qt interface, a browser DOM interface, and a command-line parameter interface; according to the deployment and access method, the browser DOM interface can further include a local web interface or a remote web console. Specifically, for example: a local desktop client can use a desktop real-time mode interface or a Qt interface; a browser client can use a browser DOM interface; a command-line client can use a command-line parameter interface; and for cases where the backend service is deployed on a remote server and users access it via the network, a remote web console can be used.

[0025] Step S2: Extract user input from the control variables of the interactive view through the algorithm parameter description layer to form a structured parameter object.

[0026] Each interactive control variable in the interactive view is mapped to a field path. When the user performs a corresponding operation, the field path of the data can be obtained from the control variable of each interactive view. Then, the user input can be extracted from the field path, and the parameter object of the algorithm module can be extracted from the user input. The parameter object includes parameter fields, parameter types, default values, value ranges, constraints, and import / export rules.

[0027] More specifically, step S2 includes: configuring a mapping relationship between interactive space variables and field paths for each algorithm module to identify the field paths of parameter objects from interactive control variables, extracting the corresponding user input based on the field paths, and then converting the user input into structured parameter objects. Specifically, configuring the mapping relationship between interactive space variables and field paths for each algorithm module includes: defining field path strings for each parameter of each algorithm module, using a hierarchical dot-matrix path format to distinguish input parameters, method parameters, and output parameters; defining numeric types for each parameter field, including numeric, string, boolean, enumeration, array, and file path types; defining constraint ranges for each parameter field, including numeric upper and lower limits, an enumeration list of optional values, regular expression validation rules, and a file type whitelist; defining default values ​​and version numbers for each parameter field for compatibility checks and missing value completion during parameter migration; and finally defining import / export rules, including serialization format, field mapping relationships, and version upgrade conversion rules.

[0028] Step S3: Generate a task type identifier based on the source of the task triggering event through the task orchestration bridge layer, and serialize the task type identifier, structured parameter object, trigger time, execution target and status callback address into a unified task request object.

[0029] The task type identifier is used to identify local tasks, command-line tasks, browser tasks, or server-side tasks.

[0030] When a task is triggered, a task type identifier is generated based on the task trigger entry point, and this identifier is written to the unified task request object as task metadata. For example, when the run button on the local interactive interface is triggered, the task type is a local task, and the local task identifier is written to the unified task request object as task metadata. When triggered by a command-line instruction, a command-line task identifier is written; when triggered by a browser interface, a browser task identifier is written; and when triggered by a remote service submission entry point, a server-side task identifier is written. The task orchestration bridging layer reads the task type identifier from the unified task request object and distributes the task to the corresponding task adapter or task queue.

[0031] Meanwhile, by assigning a globally unique task number to each algorithm task, the lifecycle state of the same algorithm task is maintained. Specifically, when an algorithm task is triggered, such as when the task is completed, saved, or submitted, the parameter object corresponding to each algorithm task is serialized into a unified task request object containing nested JSON, XML, or equivalent structures according to the field path. Furthermore, when an algorithm task needs to import configuration parameters, these parameters are written back to the interaction space and algorithm parameter variables according to the same field path.

[0032] More preferably, different clients generate different events when algorithm tasks are triggered. Therefore, the task trigger type can be determined based on the type of task trigger event, and then the parameter object can be converted into a serialized unified task request object based on the task trigger type. Specifically, depending on the client type, task trigger events include: interface button trigger events, remote submission trigger events, command line batch processing start trigger events, and server-side trigger events. Server-side trigger events can be any one of service interface trigger events, scheduled event trigger events, and message queue trigger events. For example, when a user clicks an interface button such as Solve, Calculate, Run, or RunBatc on the desktop algorithm parameter interface, an interface button trigger event is triggered; when a user calls the task submission interface through the task submission button on the browser to serialize the current parameters into JSON and submit, a remote submission event is triggered; when a user submits a task through a dedicated CLI program or batch processing entry, a command line batch processing start trigger event is triggered; and events generated by the user triggering the algorithm task through server-side operation buttons, such as service interface calls, scheduled events, or message queues, are also server-side trigger events.

[0033] More preferably, serializing the parameter object into a unified task request object according to the task trigger type specifically includes: When the target terminal is a desktop, the parameter object calls SaveConfigJson to generate a JSON string, and combines the algorithm identifier (algorithm) with the payloadJson to form a request body, thus forming a unified task request object.

[0034] When the target terminal is a web client, submit fields such as algorithm, payload, client, and rendering via POST / api / tasks to serialize the unified parameter object into a unified task request object.

[0035] When the target terminal is a server, a unified task request object is formed by creating a taskId and saving the payload.

[0036] More specifically, the unified task request object includes an algorithm object, an encapsulated algorithm identifier, an input resource description, a client type, a version number, and task information. The encapsulated algorithm identifier is based on the algorithm module identifier selected by the user; the input resource description refers to the source and type of the engineering data; and the client type distinguishes the type of terminal, including desktop, browser, server, and command-line terminals.

[0037] Specifically, for example, when the algorithm type is matrix solving, the unified task request object includes the matrix solving task's a file, b file, solver, preconditioner, tolerance, etc.; the algorithm parameters include sparse threshold, maximum iteration parameter, time step and regular sparsity; the input resource description includes CSV matrix, grid file, boundary conditions and database dataset.

[0038] In addition, the parameters of the unified task request object come from four sources: First, the values, switches, drop-down options, and paths entered by the user in the interactive interface; Second, the default values ​​of each algorithm configuration, such as the maximum number of iterations, tolerance, and algorithm options; Third, the algorithm configuration JSON or project configuration project.bfproj.json / panels / .json imported by the user; Fourth, the resource path returned by the server after the browser uploads the file.

[0039] The unified task request object is saved in the following file formats: JSON, XML, YAML, Protocol Buffers, Messenger Pack, and database.

[0040] Step S4: The execution backend adaptation layer selects the execution backend based on the current terminal's execution capabilities, and calls the corresponding algorithm module to execute based on the execution backend and the unified task request object.

[0041] The execution backend refers to the runtime environment where the actual computation is performed, including local processes, containers, cloud functions, remote task queues, cluster scheduling system platforms, and browser WebWorkers. Specifically, this invention obtains the execution capabilities of the current terminal through an execution backend adaptation layer, and selects the corresponding execution backend based on these capabilities to perform the computation of the corresponding algorithm module, thereby outputting the raw computation results. The raw computation results include: logs, errors, result summaries, result content, and task status, etc.

[0042] Preferably, the execution capabilities of the current terminal include the compilation platform identifier, whether it has access to the local file system platform, whether it can start local processes or solvers, whether it has a browser file upload interface, whether it can access the HTTP task API, and whether the target terminal has the corresponding algorithm CLI or server-side runner. Specifically, the execution capabilities of the current terminal can be derived from the compilation and runtime phases; during the compilation phase, macros such as PLATFORM_DESKTOP, PLATFORM_WEB, and BASEFRAME_WEB_CLIENT are used to distinguish the packaging forms of desktop, WebAssembly, and Web clients; during the runtime phase, the availability of the local file system platform, browser upload interface, HTTP API, algorithm CLI executable file, and solver resources is determined.

[0043] More preferably, when selecting the execution backend, this invention also constructs a set of platform capabilities by reading the compiler platform identifier and runtime environment detection results. Specifically, the execution capabilities of the current terminal include local file system platform access capabilities, local solver availability, and script execution capabilities. When no remote computation is specified, the desktop local execution path is selected, and the computation is completed by directly calling the local solver dynamic library or executable program. When the execution capabilities of the current terminal indicate that it is running in a browser sandbox and does not have the ability to call local dynamic libraries, the unified task request object and the uploaded input resource files are submitted to the server-side task API, and the server schedules the corresponding algorithm runner for execution. When the task source is a batch dataset or an automated construction process, the command-line execution path is selected, and the unified task request object is passed in through CLI parameters or standard input.

[0044] Step S5: Parse the original calculation results returned by the execution backend into a unified result object through the result status backfill layer, and backfill the unified result object to the interactive view for display.

[0045] By constructing a result status backfill layer, the raw computation results returned by the execution backend, including logs, errors, result summaries, result content, and task status, are converted into a unified result object. This unified result object includes a result summary, numerical results, error messages, computation time, and convergence metrics. For example, taking matrix solving as an example, after the execution backend reads the matrix path, vector path, solver options, and tolerance from the unified task request object, it calls MatrixSolverCli.exe or the local solver execution logic to generate a unified result object from the raw computation results. This unified result object is then returned to the corresponding interactive view in the interactive view adaptation layer for display.

[0046] Step S6: Obtain the target terminal through the portable compilation adaptation layer and derive the system platform of the target terminal based on the target terminal. Then, select the compilation environment based on the system platform of the target terminal and generate the target terminal configuration product that can run on the target terminal by using the unified task request object, structured parameter object, execution backend and backfill result based on the compilation environment.

[0047] The compilation environment includes compilation units, platform macros, dependency libraries, export rules, and resource copying strategies.

[0048] The target terminal can be any one of a desktop, command-line, browser-based WebAssembly, or server. More preferably, the target terminal configuration artifacts differ depending on the target terminal, specifically including desktop application artifacts, command-line tool artifacts, WebAssembly static deployment artifacts, and server-side artifacts. Specifically, when the target terminal is a desktop, the target terminal configuration artifacts include the desktop executable program and project configuration files; when the target terminal is a command-line terminal, the target terminal configuration artifacts are the command-line algorithm CLI and input / output JSON / CSV files. When the target terminal is a browser-based WebAssembly terminal, the target terminal configuration artifacts are the browser-based WebAssembly index html, JavaScript, wasm, and resource data files. When the target terminal is a server, the target terminal configuration artifacts are the server-side task status JSON, result JSON, CSV, PLT, or ZIP result files.

[0049] This invention generates a target terminal configuration product through the aforementioned platform, and then imports this product into the corresponding target terminal. This allows the target terminal to reproduce experimental conditions and task flows using the same algorithm modules, input resources, parameter settings, and backfill results, thereby achieving cross-platform migration of industrial simulation software. After cross-platform migration, no reconfiguration is required, eliminating parameter inconsistencies, reducing software maintenance costs, and increasing the migration success rate.

[0050] More preferably, cross-platform reproduction further includes: saving the generated parameter object and unified task request object as a configuration file; importing the configuration file on the target terminal; writing the parameter values ​​in the configuration file back to the interaction space according to the field paths; and performing version compatibility verification and parameter constraint verification. Once the verification passes, the unified task request object is regenerated on the target terminal using the same algorithm module, input resources, parameter settings, and is submitted for execution, thus achieving cross-platform reproduction of the same algorithm task. This invention connects the software process with the physical process of engineering simulation to achieve cross-platform reproduction of industrial simulation.

[0051] Specifically, this invention uses the algorithmic task of matrix solving to illustrate the implementation of the technical solution: First, register the matrix solving module in the algorithm module list of the system platform, and build three parameter pages for the matrix solving module: input file, solution method, and result export. Then, interact with the user through these three parameter pages to collect user input. Specifically, obtain the matrix A file and vector b file from the input file page; obtain the solver type, preconditioner, maximum number of iterations, relative convergence tolerance, and absolute convergence tolerance from the solution method page; and collect the export position of the solution vector from the result export page.

[0052] The user input is then mapped to structured parameter objects, such as: input.matrixAPath, input.vectorBPath, method.solverIndex, method.preconditionerIndex, method.maxIterations, method.relativeTolerance, method.absoluteTolerance, and output.exportXPath.

[0053] When a task is triggered, the task trigger type is determined based on the task trigger event, and a unified task request object is generated from the parameter object according to the task trigger type. Specifically, when the user clicks the solve button, the aforementioned unified parameter object is serialized into a unified task request object, and algorithm identifier, client identifier, and version number are appended.

[0054] Next, the execution backend is determined based on the current terminal's execution capabilities and the unified parameter object. The execution backend then completes the matrix solving task and synchronizes the result status according to the unified task request object. The execution backend adaptation layer is used to determine the execution capabilities of the current terminal. Specifically, local execution is selected when the desktop client has a local file system platform and solver; server-side task API is selected when the browser-based WebAssembly client cannot directly launch the local solver; and matrix solving CLI is selected for batch processing scenarios.

[0055] The raw calculation results and task status returned by the execution backend are then parsed into a unified result object, which is then populated back into the corresponding interface of the interactive view for display. Specifically, the task status retrieves the raw calculation results from the execution backend and derives the unified result object. Task statuses include: queued, running, completed, or failed, etc.

[0056] Finally, the target terminal is obtained, and the target platform identifier is derived based on the target terminal. Then, based on the target platform identifier, the interaction implementation, task interface, execution backend, platform macros, and resource files are selected. The matrix solving process, including the unified task request object, parameter configuration, execution backend type, and backfill results, is saved as a JSON configuration file. The x.csv file, the resulting JSON file, or the server-side ZIP result are exported as target terminal configuration artifacts. Applying these target terminal configuration artifacts to the corresponding target terminal allows the same matrix solving task to be reproduced on that specific target terminal. The target terminal configuration artifacts include: x, number of iterations, final residual, convergence status, solution time, and the selected backend method.

[0057] For example, this invention uses the symbolic regression algorithm task to specifically illustrate the implementation of the technical solution: First, the platform developers register the algorithm for the symbolic equation recognition module in the system platform and provide pages for data import, variable selection, algorithm settings, and result viewing. The data import page collects experimental data tables or simulation result tables; the variable selection page reads the table header and collects the input variables, output variables, and candidate symbols; and the algorithm settings page collects algorithm categories such as SINDy, weak form recognition, neural network regression, or hybrid recognition, as well as parameters such as time step, sparsity threshold, regularization coefficient, number of training epochs, window width, and output directory.

[0058] Then, the user input is mapped into structured parameter objects through the algorithm parameter description layer, such as result.excelPath, result.headers, result.isInput, result.isOutput, result.symbolCandidates, result.algorithmFamily, result.dt, result.threshold, result.alpha, and result.outputDir.

[0059] Subsequently, when the user clicks "Start Recognition," the serialized parameter object is converted into a unified task request object through the task orchestration bridging layer, and an algorithm identifier, client identifier, and version number are appended.

[0060] The execution backend is then determined based on the unified task request object and the execution capabilities of the current terminal. That is, the execution capabilities of the current terminal are determined by the execution backend adaptation layer, and the execution backend is determined in conjunction with the unified task request object. For example: if the desktop client has a Python runtime environment or algorithm CLI, local script execution is selected; if the browser client cannot directly run local scripts, server-side task API is selected; and for batch dataset scenarios, batch processing CLI or server-side batch processing runner is selected.

[0061] The backend then executes the symbolic regression task based on the unified task request object and synchronizes the results status. Specifically, the desktop client reads the data table path, variable selection, and algorithm parameters from the unified task request object, calls a local Python script or algorithm CLI to complete the symbolic regression, and the browser client first uploads the data table and then submits the same task payload, which is then run by the server-side symbolic regression runner.

[0062] Next, the task status and raw calculation results returned by the execution backend are obtained and populated back into the interactive view. Specifically, the task queuing, running, completion, failure and result status are synchronized through the task orchestration bridging layer, and the result status backfilling layer populates the results page with the identified equation expression, fitting error, training log, image file and result text.

[0063] Finally, the platform generates the target terminal configuration product by importing the data import fields, variable selection fields, algorithm parameters, unified task request objects, and result backfill content through the portable compilation adaptation layer. The platform saves the symbolic regression parameters as configuration JSON and exports the equation text, image, CSV, database record, or ZIP result package, thereby reproducing the same data column selection, algorithm category, and threshold setting on the corresponding target terminal.

[0064] Example 2 Based on Embodiment 1, the present invention provides a simulation software adaptation implementation device based on multi-terminal portability, including a memory and a processor. The memory stores a simulation software adaptation implementation program that runs on the processor. The simulation software adaptation implementation program is a computer program. When the processor executes the simulation software adaptation implementation program, it performs the following steps:

[0065] Example 3 Based on Embodiment 1, the present invention also provides a computer-readable storage medium storing a simulation software adaptation implementation program thereon. The simulation software adaptation implementation program is a computer program, and when executed by a processor, the simulation software adaptation implementation program performs the following steps: The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for adapting simulation software to multiple platforms, characterized in that, The simulation software configuration method includes: Input collection steps: Provide an interactive view to the user through the interactive view adaptation layer to collect user input; the user input includes algorithm input, method selection, operation control, output settings, and result status; Parameter object conversion steps: The user input is extracted from the control variables of the interactive view through the algorithm parameter description layer to form a structured parameter object; the structured parameter object includes parameter fields, parameter types, default values, constraint ranges, version numbers, and import / export rules; The steps for generating a unified task request object are as follows: A task type identifier is generated based on the source of the task triggering event through the task orchestration bridging layer. The task type identifier, structured parameter object, trigger time, execution target, and status callback address are then serialized into a unified task request object. This unified task request object includes an algorithm object, an encapsulated algorithm identifier, an input resource description, client type, version number, and task information. The execution backend determination steps are as follows: the execution backend adaptation layer selects the execution backend based on the execution capabilities of the current terminal, and calls the corresponding algorithm module to execute based on the execution backend and the unified task request object; the execution backend is at least one of the following: local process, container, cloud function, remote queue, cluster scheduling system platform, and browser WebWorker; Result backfilling steps: The original calculation results returned by the execution backend are parsed into a unified result object through the result status backfilling layer, and the unified result object is backfilled into the interactive view for display; the unified result object includes result summary, numerical data, error information, calculation time and convergence index; the original calculation results include at least: log, error, result summary, result content and task status; Compilation steps: Obtain the target terminal through the portable compilation adaptation layer and derive the target terminal's system platform based on the target terminal, then select the compilation environment based on the target terminal's system platform; and generate the target terminal configuration artifact that can run on the target terminal by using the unified task request object, structured parameter object, execution backend, and backfill results based on the compilation environment.

2. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The compilation steps specifically include: when the target terminal is a desktop terminal, the target terminal configuration output includes a desktop executable program and a project configuration file; when the target terminal is a command-line terminal, the target terminal configuration output includes a command-line algorithm CLI and input / output JSON / CSV files; when the target terminal is a browser WebAssembly terminal, the target terminal configuration output includes the browser WebAssembly terminal's index html, JavaScript, wasm, and resource data files; when the target terminal is a server terminal, the target terminal configuration output includes the server terminal's task status JSON, result JSON, CSV, PLT, or ZIP result files.

3. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The file formats of the unified task request object include JSON, XML, YAML, Protocol Buffers, MessagePack, and database; the interactive views include a desktop real-time mode interface, a browser DOM interface, a Qt interface, and a command-line parameter interface; the browser DOM interface also includes a local web interface and a remote web console.

4. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The parameter object conversion step further includes: configuring a mapping relationship between interactive space variables and field paths for each algorithm module to identify the field paths of parameter objects from interactive control variables, extracting the corresponding user input based on the field paths, and then converting the user input into structured parameter objects; specifically, configuring a mapping relationship between interactive space variables and field paths for each algorithm module includes: defining a field path string for each parameter of each algorithm module, using a hierarchical dot-matrix path format to distinguish input parameters, method parameters, and output parameters; defining data types for each parameter field, including numeric, string, boolean, enumeration, array, and file path types; defining constraint ranges for each parameter field, including upper and lower limits for numeric values, a list of enumerated optional values, regular expression validation rules, and a file type whitelist; defining default values ​​and version numbers for each parameter field for compatibility checks and missing value completion during parameter migration; and defining import / export rules, including serialization format, field mapping relationships, and version upgrade conversion rules.

5. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The task triggering events include interface button triggering events, remote submission triggering events, command-line batch processing start triggering events, and server-side triggering events; the server-side triggering events include service interface triggering times, timed scheduling triggering events, and message queue triggering times; wherein, the interface button triggering event is specifically triggered when the user clicks the corresponding button on the algorithm parameter page on the desktop; the remote submission triggering event is specifically called in the button event on the browser; the command-line batch processing start triggering event refers to the event triggered when the same type of configuration is read and executed through a dedicated CLI program or batch processing entry.

6. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The format of the unified task request object is at least any one of JSON, XML, YAML, Protocol Buffers, Messenger Pack, and database.

7. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The execution capabilities of the current terminal specifically include: compilation platform identifier, whether it has local file system platform access capability, whether it can start local processes or solvers, whether it has browser file upload interface, whether it can access HTTP task API, and whether the target terminal has corresponding algorithm CLI or server-side runner.

8. The method for adapting multi-terminal portable simulation software according to claim 1, characterized in that, The compilation steps also include: importing the target terminal configuration output into the corresponding target terminal so that the corresponding target terminal can reproduce the experimental conditions and task flow according to the same algorithm module, input resources, parameter settings, and backfill results; specifically, saving the generated parameter object and unified task request object as a configuration file, importing the configuration file into the corresponding target terminal, and then writing the parameter values ​​in the configuration file back to the interactive control in the interactive view according to the field path, and performing version compatibility verification and parameter constraint verification; and when the verification passes, regenerating the unified task request object on the target terminal according to the same algorithm module, input resources, parameter settings, and submitting it for execution, thereby realizing cross-terminal reproduction of the same algorithm task.

9. A multi-terminal portable simulation software adaptation implementation device, comprising a memory and a processor, wherein the memory stores a simulation software adaptation implementation program running on the processor, characterized in that, The simulation software adaptation implementation program is a computer program. When the processor executes the simulation software adaptation implementation program, it implements the steps of the multi-terminal portable simulation software adaptation implementation method as described in any one of claims 1-8.

10. A computer-readable storage medium having a simulation software adaptation implementation program stored thereon, characterized in that, The simulation software adaptation implementation program is a computer program, and when the simulation software adaptation implementation program is executed by the processor, it implements the steps of the multi-terminal portable simulation software adaptation implementation method as described in any one of claims 1-8.

Images