A general application platform design method and system for CAE software

Abstract

A method and system for designing a universal application platform for CAE software, relating to the field of CAE software design, is disclosed. It addresses the current lack of a standardized system and technical approach for software integration across multiple software subsystems in the design of universal application platforms for CAE software. The method includes the following steps: dividing the universal application platform into a vertical operation process and a horizontal operation process; the vertical operation process includes registration, initialization, event loop, and memory release; the horizontal operation process includes application architecture, global data, component management, signal transceivers, program driver manager, UI event processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface. This invention is applicable to the design of universal application platforms for CAE software.

Description

Technical Field

[0001] This invention relates to the field of CAE software design, and more specifically to a design method for a general application base for CAE software. Background Technology

[0002] CAE software, as a powerful tool, is widely used in many fields such as automotive, aerospace, electronics, and machinery to simulate and analyze the physical behavior of products in order to predict their performance, reliability, and durability.

[0003] Several technical solutions exist for general application foundations for CAE software. These solutions aim to provide a stable, efficient, and scalable platform to support the development, operation, and optimization of CAE software. The following are some key technical solutions and their characteristics: 1. Standardized and Systematized Process Customization: Developing specific standardized process systems based on a particular application scenario and application software, encapsulating specific business logic and operational scenarios, improving work efficiency, and reducing the probability of errors from manual intervention. 2. Cloud Computing Platform: Cloud computing platforms can install multiple software programs onto a unified platform, enabling access to multiple software programs through cloud desktops or browser logins, improving the ease of use and efficiency of CAE software, and reducing users' hardware costs. 3. Integrated CAD / CAE Technology: Creating a 3D product model using CAD software (such as UG) and converting it to a format suitable for import into CAE software, then using CAE software to mesh the 3D model. The integrated application of CAD / CAE technology achieves the integration of design, analysis, and manufacturing processes, improving design efficiency and quality.

[0004] The above-described general application platform design schemes and systems for CAE software are partly customized for specific application scenarios of specific software, and partly provide a broad software runtime environment, allowing each software to run independently. Currently, the technical solutions do not address the issue of software integration standards and technical routes for multiple software and multi-subsystem applications. Summary of the Invention

[0005] This invention addresses the problem that existing general application platform designs for CAE software lack a software integration standard system and technical approach for multi-software, multi-subsystem applications.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] This invention provides a method for designing a universal application platform for CAE software, the method comprising the following steps:

[0008] Step S1: Divide the general application base into a vertical running process and a horizontal running process;

[0009] Step S2: The vertical operation process is divided into registration, initialization, event loop, and memory release;

[0010] Step S3: The horizontal operation process is divided into application architecture, global data, component management, signal converter, program driver manager, UI time processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface.

[0011] Furthermore, in a preferred embodiment, the above registration is used to realize the creation and registration of data creators and event handlers;

[0012] The above initialization is used to perform initialization operations on the registered objects and create various global data objects;

[0013] The event loop described above is used to handle complex business process events based on user interactions;

[0014] The memory release described above is used to reclaim and release memory after the process ends.

[0015] Furthermore, in a preferred embodiment, the above application architecture is used to provide a registration interface for factories and event handling;

[0016] The aforementioned global data is used to manage global data;

[0017] The aforementioned component management is used to manage the generated components and provide access interfaces;

[0018] The aforementioned signal converter is used to forward signals between components, including console information and thread execution progress;

[0019] The aforementioned program driver manager is used to start and terminate third-party applications, achieving process-level integration;

[0020] The UI timing handling described above is used to implement global event responses;

[0021] The above main interface generator is used to load the QSS and translation files while generating the main interface;

[0022] The aforementioned global data factory is used to generate global data and place it into the global data management system;

[0023] The aforementioned component factory is used to create components and place them into the component manager;

[0024] The above software settings are configured during software runtime and can read and write INI files;

[0025] The command-line processor described above is used to process command-line arguments;

[0026] The aforementioned signal processor is used for personalized signal processing;

[0027] The aforementioned event handlers are used for personalized event processing;

[0028] The Python registration interface described above is used to implement Python calls.

[0029] Furthermore, there is a preferred embodiment that defines the above application architecture based on QApplication.

[0030] Furthermore, in a preferred embodiment, the aforementioned global data includes geometric data, mesh data, physical model data, and post-processing data.

[0031] Furthermore, in a preferred embodiment, the aforementioned global event response includes keyboard and mouse events and a registerable event handler.

[0032] Furthermore, in a preferred embodiment, the universal application base proposed in this invention can be used for the integration of various CAE software and their subsystems.

[0033] The method for designing a universal application platform for CAE software described in this invention can be entirely implemented using computer software. Therefore, correspondingly, this invention also provides a system for designing a universal application platform for CAE software, the system including a storage device for performing the following steps:

[0034] Step S1: Divide the general application base into a vertical running process and a horizontal running process;

[0035] Step S2: The vertical operation process is divided into registration, initialization, event loop, and memory release;

[0036] Step S3: The horizontal operation process is divided into application architecture, global data, component management, signal converter, program driver manager, UI time processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface.

[0037] The present invention also provides a computer-readable storage medium storing a computer program, which is executed by a processor, and is a general application base design method for CAE software as described in any one of the above claims.

[0038] The present invention also provides a computer device, the device including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes a general application base design method for CAE software as described in any one of the above.

[0039] The beneficial effects of this invention are as follows:

[0040] This invention provides a design method for a universal application platform for CAE software. The designed universal application platform, applied to the CAE software development process, serves as a support platform for CAE software and can achieve the following: 1. Providing a unified integration environment: CAE software involves subsystems and subroutines from multiple disciplines and fields. The platform can integrate the subsystems and subroutines of different CAE software into a unified platform, allowing end-users to complete multiple analysis tasks on a single interface, improving work efficiency. 2. Enabling data sharing and exchange: Through the platform, data between different CAE systems can be easily shared and exchanged, avoiding data format conversion and redundant modeling issues. 3. Through the platform, data between different CAE software can be easily shared and exchanged, avoiding data format conversion and redundant modeling issues. 4. For engineering problems in different fields (such as stress analysis of TV stands, mold design of LCD monitor stands, etc.), the platform can provide customized solutions to meet specific user needs.

[0041] This invention is applicable to the design of a general application base for CAE software. Attached Figure Description

[0042] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0043] Figure 1 This is a structural block diagram of the universal application base for CAE software described in this invention;

[0044] Figure 2 The registration process described in this invention is implemented through the main function. (Program diagram)

[0045] Figure 3 This is a flowchart of the running program of the CAE software described in this invention, implemented through the main function. Detailed Implementation

[0046] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0047] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention.

[0048] Implementation Method 1, see [link] Figure 1 This embodiment addresses the current lack of standardized software integration protocols and technical approaches for multi-software, multi-subsystem applications in existing CAE software application base designs. It proposes a method for designing a universal application base for CAE software, allowing other functional components to be inserted into the application base designed in this embodiment to achieve specific functionalities.

[0049] The design methodology includes the following steps:

[0050] Step S1: Divide the general application base into a vertical running process and a horizontal running process;

[0051] Step S2: The vertical operation process is divided into registration, initialization, event loop, and memory release;

[0052] Step S3: The horizontal operation process is divided into application architecture, global data, component management, signal converter, program driver manager, UI time processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface.

[0053] In practical applications, this embodiment divides the CAE software according to its functions and operational processes, specifically into several processes: geometric model processing, mesh generation, physical modeling, solution calculation, and post-processing. These processes and functions can be broken down into different components, each implementing a specific function. In other words, other functional components can be inserted into the application platform designed in this embodiment to achieve specific functionalities.

[0054] The general application platform is written in C++, and based on a unified abstract interface and registration mechanism, it achieves complete independence between business logic and functional implementation, supporting convenient function combination and personalized business logic expansion. The application platform is designed both vertically and horizontally, such as... Figure 1 As shown, the vertical operation of the application platform is divided into four processes: registration, initialization, event loop, and memory release. Horizontally, the application platform is divided into 14 key parts, implemented through 14 C++ classes, specifically including application architecture, global data, component management, signal transceiver, program driver manager, UI event handling, main interface generation, global data factory, component factory, software settings, command-line processor, signal processor, event processor, and Python registration interface.

[0055] Implementation Method 2: This implementation method is a detailed description of the design method for a general application platform for CAE software described in Implementation Method 1 above.

[0056] The vertical operation of the program base is divided into registration, initialization, event loop, and memory release;

[0057] The registration process involves creating and registering data creators and event handlers; the initialization process performs initialization operations on registered objects and creates various global data objects; the event loop handles complex business process events based on user interactions; and memory release refers to the reclamation and release of memory after the main software process ends.

[0058] The application foundation is horizontally divided into 14 key parts, each implemented through a separate C++ class. These include application architecture, global data, component management, signal transceiver, program driver manager, UI event handling, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface.

[0059] The 14 horizontal sections are shown in Table 1 below:

[0060] The application architecture (FITKApplication) is based on QApplication and defines the main processes of software operation. It provides registration interfaces for factories and event handling.

[0061] FITKGlobalData is used for global data management, including managing global data such as geometric data, mesh data, physical model data, and post-processing data.

[0062] Component management (FITKCmponents) is used for component management, including managing generated components and providing access interfaces.

[0063] The FITKSignalTransfer is used for signal forwarding between a small number of components, including console information, thread execution progress, etc. It can register signal processors to achieve personalized signal processing.

[0064] The FITKProgramTaskManager is used for managing third-party program drivers, starting and terminating third-party applications, and achieving process-level integration.

[0065] UI event handling (FITKGlobalEventFilter) is used for global event responses, including keyboard and mouse events. Event handlers can be registered to achieve personalized event handling.

[0066] The main interface generator (FITKAbstractMainwindowGenerator) is an abstract class used to generate the main interface and load the QSS and translation files.

[0067] The global data factory (FITKAbstractGlobalDataFactory) is used to generate global data and manage it within the global data center. A derived subclass must be registered with FITKApplication.

[0068] The component factory (FITKComponentFactory) is used to create components and put them into the component manager. It needs to be registered with FITKApplication through derived subclasses.

[0069] The software settings (FITKAppSettings) are used to set settings at runtime. They can read and write INI files and can derive subclasses to register with FITKApplication.

[0070] The command-line handler (FITKCommandLineHandler) is used to process command-line arguments and can be subclassed and registered with FITKApplication.

[0071] The signal processor (FITKSignalTransfer) is used for personalized signal processing. It can be registered with the FITKSignalTransfer signal processor, and the slot function naming format is "on_ <signal>"At that time, it can automatically associate signals in FITKSignalTransfer.

[0072] The event handler (FITKAbstractEventFilter) is used to implement personalized event handlers. Derived subclasses can be registered to FITKGlobalEventFilter.

[0073] The Python registration interface (FITKAbstractPythonRegister) is used to register C++ class decorators with Python Qt, enabling Python calls. It requires a derived subclass to be registered with FITKApplication.

[0074] Table 1

[0075]

[0076]

[0077]

[0078]

[0079] Implementation Method 3, see below Figure 2 and Figure 3 This embodiment describes the specific operation process of the general application base designed in the above embodiments.

[0080] The operation of an application software framework can be divided into several steps: registration, initialization, command execution, message and event handling, data persistence, and memory release. Among these, the registration step is crucial in determining the software's appearance and business functions; the other parts are executed autonomously by the framework.

[0081] The registration process involves overriding virtual functions in a base class and registering them at designated locations. During subsequent program execution, the software framework will automatically call these virtual functions to perform specific operations. Objects requiring registration fall into two categories: those that must inherit from a base class, override virtual functions, and then register with the framework (primarily the classes `FITKbstractMainwindowGenerator`, `FITKbstractGlobalDataFactory`, and `FITKComponentFactory`); and those that can be registered based on specific business needs. For example, if command-line arguments are not processed, `FITKCommandLineHandler` does not need to be registered. The registration process is typically implemented in the `main` function, as shown in the example below. Figure 2 As shown.

[0082] The initialization process refers to the operations such as creating data objects and UI objects necessary for software operation and reading configuration files. Initialization is the foundation for subsequent command execution and message event processing. The initialization process is roughly as follows: operations marked with * are operations that will definitely be executed, and other operations will not be executed if no object is registered.

[0083] (1) Read the software configuration INI file [FITKAppSettings]

[0084] (2) Generate global data and store it in the global data manager (FITKGlobalData).

FITKabstractGlobalDataFactory

[0085] (3) *Load the QSS page style file and bilingual file.

FITKAbstractMainwindowGenerator

[0086] (4) Load and create components, and store them in the component management class (FITKComponents).

FITKComponentFactory

[0087] (5) *If "-nogui" is present in the command line, it is considered to be running without a GUI, the initialization process ends, and the command execution phase begins.

FITKApplication

[0088] (6) Generate the software's main interface and store its pointer in the global data (FITKGlobalData).

FITKAbstractMainwindowGenerator

[0089] (7) Render the initial UI of the main interface.

FITKApplication

[0090] (8) Register Python decorators.

FITKAbstractPythonRegister

[0091] (9) Start the autosave function.

FITKApplication

[0092] Command execution refers to the execution of command-line arguments and the processing file parameters related to Workbench. Whether a command-line command is executed depends on two factors: whether a command-line processor is registered and whether command-line arguments are provided at runtime. The command will only be executed if both are provided. The Workbench-related processing logic is similar: it depends on whether it is driven by Workbench and whether a processor is registered. Execution will only occur if both are provided.

[0093] Message events primarily refer to events generated by UI interactions, such as button click events and mouse / keyboard events. These events are mainly executed through slot functions in the main interface or its child interfaces. Mouse / keyboard events can be handled using `FITKAbstractEventFilter`. These events require a high degree of customization.

[0094] Data persistence is performed after the message event ends (usually when the entire UI is closed). Generally speaking, data persistence refers to writing data in memory to a file. Most of the data persistence functionality is handled by message events, triggered by buttons in the UI to read and write files. The data persistence discussed here includes two parts: one is writing software configuration information, implemented through FITKAppSettings; the other is writing the files required by Workbench.

[0095] Releasing memory is the last step in the software's lifecycle. When releasing memory, first shut down the thread pool (FITKThreadPool) and terminate all running tasks in the third-party program manager (FITKProgramTaskManager), and then release all data in FITKApplication.

[0096] The AppFramework is used to divide the horizontal operation process of CAE software into more than a dozen processes, and a series of personalized registration interfaces are provided to realize personalized business. Specifically, the framework integrates multiple modules to form a complete CAE software.

[0097] First, the overall workflow of AppFramework is fixed. It begins by registering interface classes according to business needs, then starts the program, executing the steps in the order described in the previous section. The registration order is independent of the execution order. The main function of the entire program is as follows: Figure 3 As shown in the diagram, line 4 is used to create the application framework; lines 8-16 are used to register a series of interface classes; and line 19 is used to run the framework. It's clear that the most crucial aspect of using the framework is understanding how to define interface classes. The following will explain each registered interface class.

[0098] 1. Application Programming Interface (FITKApplication)

[0099] The FITKApplication application is the foundation of the entire software and serves as the central interface for all data access. During program runtime, it frequently needs to access application objects or retrieve data from them. The application provides several access interfaces, including:

[0100] The application class inherits from QApplication and can be accessed via QApplication. It can also be accessed via the fast access macro FITKAPP. The main function is as follows:

[0101] 1.#include"FITKApplication.h" 2. / / Get the file directory where the app is located 3. / / FITKAPP is a pointer to the application object. 4.QStringappPath=FITKAPP->applicationDirPath();

[0102] Based on the application framework, some global data can be accessed, and then a search can be performed layer by layer to find all valid data objects. This provides an alternative solution for data object lookup and access besides the Core module's repository. In addition to the registration function, commonly used access interfaces are as follows:

[0103]

[0104]

[0105] 2. Main Interface Generator (FITKAbstractMainwindowGenerator)

[0106] The main function of the main interface generator is to generate the main interface and specify the QSS style files and language pack files to be loaded. During development, it is necessary to inherit from FITKAbstractMainwindowGenerator and override the following functions:

[0107]

[0108]

[0109] The object registration interface is located in FITKApplication:

[0110] 1. / / Register main interface generator 2.voidregMainWindowGenerator(FITKAbstractMainwindowGenerator*generator);

[0111] The window object generated by the main interface can be accessed from the global data (FITKGlobalData).

[0112] 3. Global Data Generator (FITKAbstractGlobalDataFactory)

[0113] The global data generator is used to generate global data related to the simulation process, mostly data management classes, such as mesh data, geometric data, and physical model data. When developing a global data generator, you need to inherit the `FITKAbstractGlobalDataFactory` class and override the following functions. These functions are not pure virtual functions; if they are not needed in the application, they do not need to be overridden. Examples are shown below:

[0114]

[0115]

[0116] The object registration interface is located in FITKApplication:

[0117] 1. / / Register main interface generator 2.voidregMainWindowGenerator(FITKAbstractMainwindowGenerator*generator);

[0118] Objects generated by the global data generator can be accessed from the global data (FITKGlobalData).

[0119] 4. Component Generator (FITKComponentFactory)

[0120] Components are an important part of FastCAE, encapsulating specific business functions. Software development based on components enables function reuse and improves software development and integration efficiency. The role of a component generator is to specify the components used in the application and create software handles. When using a component factory, you need to inherit from FITKComponentFactory and override the functions, as shown in the example below:

[0121]

[0122]

[0123] The component generator's registration interface is located in FITKApplication:

[0124] 1. / / Register component generator 2.voidregComponentsFactory(FITKComponentFactory*fac);

[0125] Component handles generated by the component generator can be accessed from the component manager (FITKCmponents).

[0126] 5. Configuration file reading and writing (FITKAppSettings)

[0127] Configuration file reading and writing refers to reading the INI configuration file when the software starts, restoring some parameters from the last software run, such as the working directory, to provide a better and more convenient user experience. Simultaneously, when the software terminates, necessary information is written back to the INI file. To use configuration file reading and writing, you need to inherit from FITKAppSettings and override the read function, as shown in the example below:

[0128]

[0129]

[0130] The configuration file registration interface is located in FITKApplication:

[0131] 1. / / Read the registration configuration file 2.voidregAppSettings(FITKAppSettings*settings);

[0132] Reading the configuration file only requires rewriting the read function. The writing process is controlled by the framework. It directly writes the path to the input, without adding any extra parameters, so there is no need to expose an interface.

[0133] 6. Command-line argument handler (FITKCommandLineHandler)

[0134] When software starts, it may sometimes be launched via command line in cmd or a Linux terminal, providing additional parameters, such as: XXX.exe -ribbon -p abc.pro. Different applications require different command-line processing logic; therefore, a command-line processor extension interface is provided. When customizing a command-line processor, it is required to inherit from FITKCommandLineHandler and override the exec function to process the command-line parameters. Note that the base class recognizes the "nogui" parameter, considering it a command that runs without a GUI; therefore, no additional processing is needed in the subclass. An example is shown below:

[0135]

[0136] The registration interface for the command-line processor is located in FITKApplication.

[0137] 1. / / Register command-line argument processor 2.voidregCommandLineHandler(FITKCommandLineHandler*handler);

[0138] 7. Global Signal Processor (QObject)

[0139] A small number of global signals are defined in the application framework. These global signals are forwarded through the FITKSignalTransfer object. Custom processing of these signals can be performed in different applications. Multiple global signal handlers can be added. This global event handler has two requirements:

[0140] I) It must be a subclass of QObject and expand the metaobject using the Q_OBJECT macro;

[0141] II) Name the slot function that needs to be associated with the signal as "on_<signal name>".

[0142] Example as follows:

[0143]

[0144] The `on_sendProcessSig` slot function in the code above is designed to handle the `sendProcessSig` signal in `ITKSignalTransfer`. When an object of this class is registered with the application framework, the framework will automatically associate it with the signal in `ITKSignalTransfer` according to the rule "on_<signal name>", without requiring manual association. Example registration code is as follows:

[0145] 1. / / Create a processor 2.MyThreadTaskProcessHandler*sigH=newMyThreadTaskProcessHandler; 3. / / Add to application framework; multiple can be added. 4.FITKAPP->addGolbalSignalProcesser(sigH);

[0146] 8. Global Event Handler (FITKAbstractEventFilter)

[0147] Corresponding to the global signal handler processing global signals, the global event handler filters and processes events (QEvents). Since different applications require different event handling, event handlers are added to achieve personalized processing for different events. Adding an event handler requires inheriting from `FITKAbstractEventFilter` and overriding the `eventFilter` function. An example is shown below:

[0148]

[0149] Once the above object is added to the application framework, the eventFilter will be automatically invoked when a message event occurs. Example code is shown below:

[0150] 1. / / Create an event filter 2.MyMouseKeyEventFilter*evf=newMyMouseKeyEventFilter; 3. / / Add event filters 4.FITKAPP->addEventFilter(evf);

[0151] 9. AutoSaver (FITKAbstractAutoSaver)

[0152] The autosaver is used to automatically save project files, script files, etc., to prevent data loss due to software crashes. The autosaver uses a timer timeout method to automatically save files at regular intervals. The file autosaver needs to inherit from FITKAbstractAutoSaver and override the autoSave and finalize functions, as shown in the example below:

[0153]

[0154]

[0155] Once the above objects are registered with the application framework, the execution logic of the relevant virtual functions will be automatically invoked. The registration interface for the autosaver is located in FITKApplication, and the registration code example is as follows:

[0156] 1. / / Initialize the application framework 2.AppFrame::FITKApplicationapp(argc,argv); 3. / / Auto-save 4.app.regAutoSaver(newAutoSaver);

[0157] 10. System Environment Check (FITKAbstractSysChecker)

[0158] The system environment check is used to check the hardware and software environment before software initialization to determine whether the basic requirements for the software to run are met. If the basic requirements are not met, an error message is returned, and the program will terminate. To use the system environment check, you need to inherit from FITKAbstractSysChecker and override the check function, as shown in the example below:

[0159]

[0160]

[0161] Once the above objects are registered in the application framework, the execution logic of the relevant virtual functions will be automatically invoked. The system checks the usage in the following code example:

[0162] 1. / / Initialize the application framework 2.AppFrame::FITKApplicationapp(argc,argv); 3. / / System check 4.app.checkSystem(newSystemChecker);

[0163] Implementation Method 4: The method for designing a universal application platform for CAE software described in the above implementation methods can be entirely implemented using computer software. Therefore, this implementation method provides a system for designing a universal application platform for CAE software, the system including a storage device for performing the following steps:

[0164] Step S1: Divide the general application base into a vertical running process and a horizontal running process;

[0165] Step S2: The vertical operation process is divided into registration, initialization, event loop, and memory release;

[0166] Step S3: The horizontal operation process is divided into application architecture, global data, component management, signal converter, program driver manager, UI time processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface.

[0167] Implementation Method 5: This implementation method provides a computer-readable storage medium storing a computer program, which is executed by a processor to provide a general application base design method for CAE software as described in any one of the above embodiments.

[0168] Implementation Method Six: The invention provides a computer device, which includes a memory and a processor. The memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes a general application base design method for CAE software as described in any one of the above embodiments.

[0169] This embodiment provides a computer device, the hardware of which is a general-purpose model and is not shown in the figure. The system includes a processor and a memory, which can be connected by a bus or other means. The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs and modules, as well as corresponding program instructions / modules. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions and modules stored in the memory, so as to realize a general application base design method and steps for CAE software in the above method embodiment.

[0170] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of the claims of the present invention.< / signal>

Claims

1. A method for designing a universal application platform for CAE software, characterized in that, The method is as follows: S1: Divide the general application platform into a vertical running process and a horizontal running process; S2: The vertical operation process is divided into registration, initialization, event loop, and memory release; Registration is used to create and register data creators and event handlers; Initialization is used to perform initialization operations on registered objects and create various global data objects; The event loop is used to handle complex business process events based on user interactions; Memory release is used to reclaim and release memory after the process ends; S3: The horizontal operation process is divided into application architecture, global data processor, component management, signal transceiver, program driver manager, UI time processing, main interface generation, global data factory, component factory, software settings, command line processor, signal processor, event processor, and Python registration interface; The application architecture is defined based on QApplication, which provides registration interfaces for factories and event handling. The global data unit is used to manage global data, which includes geometric data, mesh data, physical model data, and post-processing data. Component management is used to manage the generated components and provides access interfaces; Signal transceivers are used to forward signals between components, including console information and thread execution progress; The program driver manager is used to start and terminate third-party applications, enabling process-level integration; UI event handling is used to implement global event responses, which include keyboard and mouse events and registerable event handlers. The main interface generator is used to load the QSS and translation files while generating the main interface. The global data factory is used to generate global data and put it into the global data management system; The component factory is used to create components and place them into the component manager; Software settings are configured during software runtime and can read and write INI files. Command line processors are used to process command line arguments; Signal processors are used for personalized signal processing; Event handlers are used for personalized event processing; The Python registration interface is used to implement Python calls.

2. The method for designing a universal application platform for CAE software according to claim 1, characterized in that, A universal application platform that can be used for integration with various CAE software and their subsystems.

3. A universal application platform design system for CAE software, characterized in that, The system includes a storage device for executing the general application base design method for CAE software as described in claim 1.

4. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, provides a method for designing a universal application base for CAE software as described in any one of claims 1-2.

5. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes a general application base design method for CAE software as described in any one of claims 1-2.

Images