Intelligent calculation job submission management method based on mobile terminal

Abstract

The invention discloses an intelligent calculation job submission management method based on a mobile terminal, a Web system is deployed based on an open source Open OnDemanand platform, and the Web system is packaged into a mobile terminal APP to realize visual one-stop management of an HPC platform, and the method specifically comprises the following steps: S1, session establishment and authentication: the mobile terminal APP initiates a connection request to a Web service gateway deployed at the front end of an HPC cluster; according to the method, traditional Linux command line operation is replaced through graphical interaction and template design of the mobile terminal, the technical threshold is greatly reduced, and non-computer professional scientific researchers can also conveniently complete operation management; and meanwhile, by means of real-time monitoring, instant response and whole-process mobile coverage of the mobile terminal, the constraint of a fixed desktop environment is eliminated, so that a user can grasp the operation state in real time and quickly process an abnormal task in any scene, and the flexibility and efficiency of intelligent calculation operation management are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of job submission management technology, and in particular to a mobile-based intelligent computing job submission management method. Background Technology

[0002] High-performance computing (HPC) and intelligent computing (AI computing) have become indispensable infrastructures in fields such as scientific research, engineering simulation, and artificial intelligence model training. Traditional HPC job submission and management methods rely heavily on command-line terminals and desktop workstations. Users need to interact with the job scheduling system through specific commands to complete a series of operations such as job script writing, file transfer, task submission, and status monitoring.

[0003] However, with the increasing complexity of computing tasks and the diversification of application scenarios, this traditional model has revealed significant limitations: 1. Its operation has a high technical threshold, requiring users to be familiar with the Linux operating system and various scheduler commands, which poses a barrier to use for researchers who are not computer science professionals; 2. Users are bound to a fixed desktop environment and cannot conveniently manage time-consuming computing tasks in mobile scenarios, nor can they respond to job status in real time (such as needing to resubmit immediately if a task fails), lacking flexibility; In view of the above, this application proposes a mobile-based intelligent computing job submission management method. Summary of the Invention

[0004] Based on the technical problems existing in the background technology, this invention proposes a mobile-based intelligent computing job submission management method.

[0005] This invention proposes a mobile-based intelligent computing job submission and management method. It deploys a web system based on the open-source OpenOnDemand platform and packages the web system into a mobile app, enabling visualized, one-stop management of the HPC platform. The method specifically includes the following steps:

[0006] S1: Session establishment and authentication: The mobile app initiates a connection request to the Web service gateway deployed at the front end of the HPC cluster, and the user completes the authentication by entering credentials through the authentication interface integrated in the mobile app, thus establishing a secure session.

[0007] S2: Resource Discovery and Selection: The mobile app obtains and visualizes the resource status of currently available compute nodes and queues by calling the cluster status query API, including CPU / GPU load, memory usage and queue waiting status. Based on the resource status, users can select the target compute queue or node on the graphical interface.

[0008] S3: Job Preparation and File Management: Users can access their HPC home directory or project directory through the file manager module of the mobile app in a graphical manner. In the directory, they can perform at least one of the following operations: create input files, upload local files to the cluster, edit the content of existing files, or organize the dataset required for the job.

[0009] S4: Job Configuration and Submission: Users configure the calculation job parameters through the job submission form of the mobile APP. The parameters include: job name, execution command, number of cores required, memory size, estimated runtime and dependent software environment. The mobile APP encapsulates the user-configured job parameters into a standard job description script and submits it to the selected queue through the job scheduling system interface.

[0010] S5: Real-time monitoring and interaction of job status: The mobile APP periodically polls or receives status updates from the job scheduling system via WebSocket connection. On the mobile interface, the job status is displayed in real time in the form of a list or chart, including "Queuing", "Running", "Completed" or "Error". At the same time, user interaction controls are provided to allow users to terminate, requeue or view detailed logs of a specified job.

[0011] S6: Result Acquisition and Post-processing: When the job status changes to "Completed", the mobile APP automatically notifies the user. The user can browse, preview or download the standard output, standard error and result files generated by the job to the local mobile device through the file manager module.

[0012] Preferably, in step S1, the mobile app establishes a connection by encapsulating the web service interface of the Open OnDemand platform, and the secure session adopts the platform's identity authentication system, supporting linkage verification with the unified identity authentication system of the HPC cluster.

[0013] Preferably, the specific logical steps of S2 are as follows:

[0014] S201: When the mobile app launches the "Resource Discovery" function, it automatically completes the configuration of permissions and filtering parameters, as well as the interface and security configuration.

[0015] S202: The mobile app sends a resource query request to the HPC cluster Web service gateway. The Web service gateway pulls data from the monitoring node and returns it. The returned data must include the fields necessary for formula calculation.

[0016] S203: After validating the raw data, the mobile app calculates key indicators using formulas to generate "user-readable resource status data," as detailed below:

[0017] S2031: Calculate CPU / GPU load rate and memory usage.

[0018] CPU load rate = (used CPU / total CPU) × 100%;

[0019] GPU load rate = (used GPU / total GPU) × 100%;

[0020] Memory utilization rate = (usedMem / totalMem) × 100%;

[0021] S2032: Calculate the average queue waiting time:

[0022] Current timestamp = 1716825600, n = 3 is the number of waiting jobs;

[0023] Average waiting time = [(1716825600-1716825480)+(1716825600-1716825360) +(1716825600-1716825240)] / 3 = (120+240+360) / 3 = 240 seconds;

[0024] S2033: Remaining available resources for compute nodes:

[0025] Remaining CPU = total CPU - used CPU;

[0026] Remaining GPUs = total GPUs - used GPUs;

[0027] Remaining memory = total memory - used memory;

[0028] S2034: Calculate queue resource utilization:

[0029] Total CPU usage in the queue = total Nodes in the Queue × total CPU.

[0030] Queue used CPU = Sum of used CPU of each node;

[0031] Queue CPU utilization = (Used CPU / Total CPU) × 100%;

[0032] S2035: Convert the calculation results into an easy-to-read format and store them as a "visualized dataset";

[0033] S204: Based on the calculation results of S203, the mobile app presents the resource status graphically to help users quickly determine its status. The specific content presented includes:

[0034] (1) Node status cards: Each node card displays "CPU load rate", "GPU load rate", "memory usage rate" and "remaining CPU". Load rate >80% is red, 50%-80% is yellow, and <50% is green, which intuitively distinguishes the busy level of the node;

[0035] (2) Queue status charts: The average waiting time of the GPU_HIGH queue and the average waiting time of the GPU_NORMAL queue are displayed using bar charts, and the CPU utilization of the GPU_HIGH queue is displayed using a pie chart. Users can click on the charts to view the calculation details.

[0036] (3) Filtering control: Provides buttons including but not limited to "Filter GPU load rate < 50%" and "Filter average waiting time < 5 minutes". After clicking, resources that do not meet the conditions will be automatically filtered out, and only nodes / queues with qualified calculation results will be displayed.

[0037] S205: When the user clicks "GPU_001 node + GPU_HIGH queue", the APP pops up a confirmation box, showing the key results of the calculation in step S203. At the same time, the mobile APP reads the estimated requirements of the user's job to be submitted and compares them with the "remaining resources" calculated in step S203: Remaining CPU > Job requirements, Remaining GPU > Job requirements, Remaining memory > Job requirements. If the verification passes, if the remaining resources are insufficient, a prompt will pop up: "The selected node has insufficient remaining CPU. We recommend the GPU_003 node with 60 remaining CPU cores" and display the calculation results of the recommended node.

[0038] S206: After the user confirms the selection, the mobile APP caches the "GPU_001 node ID, GPU_HIGH queue ID" and the corresponding calculation results. The mobile APP calls the "resource locking API" to send a request to the scheduling system to "pre-request 8-core CPU and 1 GPU". The scheduling system determines the availability of resources based on the "remaining resources" calculated in step S203 and returns a "pre-request successful" receipt to ensure that resources are not completely occupied before the user submits the job.

[0039] Preferably, in step S3, the file management module operations include at least one of the following: creating, viewing, deleting, renaming, moving, downloading, copying, and pasting files or directories;

[0040] Editing the content of existing files is achieved by calling the web-based code editor integrated into the app or by using a command-line text editor through the embedded WebShell terminal;

[0041] The file management module supports executing file and directory operation commands via command line through the Web Shell terminal integrated into the mobile app. The Web Shell terminal is linked in real time with the terminal service of the Open OnDemand platform and operation logs are saved synchronously.

[0042] Preferably, in step S4, the job submission form integrates a job template library function. The template library is built based on the Job Composer module of the OpenOnDemand platform. Users can select the platform's pre-set intelligent computing job templates or customize and save job parameter templates and synchronize them to the platform's cloud.

[0043] The specific logical steps of S4 are as follows:

[0044] S401: After opening the "Assignment Configuration" page of the mobile APP, the system automatically connects to the backend template library and displays two types of templates: one is the platform's preset templates, and the other is the user's previously saved custom templates. If the user has submitted an assignment and used a template before, the system will automatically read the history and pre-fill the default parameters of the last template into the current assignment form to reduce repeated input.

[0045] S402: Users can filter templates by "scenario tags" according to the current job requirements. Clicking on any template will allow users to view detailed parameters. If the default parameters of the template do not meet the requirements, users can modify them directly in the form. Modified parameters will be marked with a special color to facilitate users to check and adjust the content.

[0046] S403: If no existing template is available, users need to manually fill in all necessary parameters in the form, including job name, execution command, required number of cores / memory, estimated runtime, and dependent software environment. After filling in the parameters, click the "Save as Template" button, enter the template name and tags, and select template permissions. The system will synchronize the template to the cloud for easy reuse later. After saving, the system will report "Template created successfully" and generate a unique template ID. The template can be found directly in the template library without repeated configuration.

[0047] S404: The system automatically checks the form to confirm that the required fields "Job Name, Execution Command, Target Queue, and Required Cores" are filled in completely. If any are missing, it will prompt "Please select the queue to submit the job". Combining the remaining resources of the node determined in the previous "Resource Discovery and Selection" step, it will determine whether the resources required for the current job are within the allocable range. At the same time, the system checks whether the selected "Dependency Software Environment" has been installed on the target node. If the target node does not have it installed, it will prompt "This node does not have it and recommends switching to a node where the software is installed".

[0048] S405: After the parameter verification is successful, the system will automatically convert the user-configured parameters into a standard "job description file" according to the operation rules of the target queue. The file will contain basic job information, software environment loading commands, job execution commands, and log storage paths.

[0049] S406: After the user clicks the "Submit Job" button, the system will display a "Job Submission Confirmation Page," listing key information such as job name, target queue, required resources, and estimated duration. After confirming that everything is correct, the user clicks "Confirm Submission." The system will then send the job description file to the HPC cluster's scheduling system. The scheduling system will assign a unique job ID and provide feedback on the submission result. If successful, it will display "Job submission successful, job ID: xxxx, currently in the queue." If it fails, it will display the specific reason. At the same time, the system will save the "job ID, submission time, parameter configuration, and template usage record" to both the local machine and the cloud for easy viewing of job status and reuse of parameters or templates later.

[0050] Preferably, in step S5, the job status monitoring also includes the management of interactive job sessions. The mobile app can display interactive session information created through the Open OnDemand platform and provide operation controls for session deletion and renewal.

[0051] Preferably, in step S6, during result acquisition and post-processing, the visualization application of the OpenOnDemand platform can be directly opened via a mobile APP to preview the visualization charts and engineering simulation image result files generated by the job online, without having to download them to the local machine.

[0052] Preferably, the specific logical steps of S5 are as follows:

[0053] S501: After the user submits the job, the mobile APP will automatically start the "job monitoring" function. The APP will detect the current network latency in real time. If the latency is >1000ms, it is judged as "unstable network"; if 300ms≤latency≤1000ms, it is judged as "stable network"; if the latency is <300ms, it is judged as "good network".

[0054] S502: When the network is stable / high-quality, a WebSocket long connection is used to receive status updates in real time without polling. When the network is unstable, it automatically switches to periodic polling and calculates the actual polling interval using the following formula:

[0055] S503: The mobile app associates all jobs under the user's account, pulls the initial status from the scheduling system as monitoring baseline data, and presents the acquired status data in a visual form for easy and intuitive viewing by the user.

[0056] S504: After the mobile app receives a status change, it processes the information according to priority and notifies the user. The priority rules are as follows: When the status changes to "Completed" or "Error", a pop-up window and notification bar message will be sent, which will include the job name, status and operation suggestions.

[0057] S505: The mobile app provides interactive controls to support user operations on the job, specifically:

[0058] S5051: Based on the current status of the job, the corresponding control is enabled. For jobs in the "Queued / Running" state, the "Terminate" button is displayed; for jobs in the "Error / Terminated" state, the "Re-queue" button is displayed; and for jobs in all states, the "View Log" button is displayed.

[0059] S5052: When the user clicks "Terminate," the mobile app sends a termination request to the scheduling system. Upon successful termination, the status updates to "Terminated." When the user clicks "Re-queue," the mobile app reuses the original job configuration to submit the request, and the status updates to "Queuing." When the user clicks "Logs," they can view the execution log, error log, and system log. Keyword search is supported, and the matching degree is calculated using formulas and displayed in sorted order.

[0060] S5053: After each operation, the mobile APP will pop up a window to show the result, ensuring that the user is aware of the operation status;

[0061] S506: Users can manually adjust monitoring settings and view historical data. When users click "Pause Monitoring" in "Settings", the mobile app stops receiving status updates; when users click "Resume Monitoring", the connection is re-established and the latest status is retrieved. When users click "History", the mobile app displays the timeline of completed tasks and resource usage statistics to help users review the task status.

[0062] Compared with existing technologies, the beneficial effects of this invention are:

[0063] 1. Significantly lowering the technical barrier through mobile-based visual interaction design: Operations such as "resource selection, job configuration, file management, and log viewing," which traditionally required command-line interaction, are transformed into a graphical interface interaction on a mobile app. Users do not need to remember complex commands such as the SLURM scheduler and PBS scheduler; they can complete the entire process simply by clicking and selecting. Furthermore, a job template library is built based on the Job Composer module of the Open OnDemand platform, providing scenario-based pre-built templates such as "AI model training and engineering simulation," while also supporting user-defined template saving and reuse. The system automatically completes parameter verification, script encapsulation, and environment dependency resolution. Non-computer science users do not need to concern themselves with the underlying technical details to quickly submit compliant jobs, completely solving the "usage barriers caused by unfamiliarity with the operating system and scheduling commands."

[0064] 2. Achieve high flexibility in job management through real-time mobile monitoring and interactive design: Supports two monitoring modes: Web Socket long connection and periodic polling. Users can view the status of jobs in real time on mobile devices such as mobile phones and tablets, including "queuing, running, completed, and error". The progress bar provides an intuitive understanding of the running progress, eliminating the need for a fixed desktop workstation. When a job encounters an "error" or "completed" error, the mobile app will proactively remind the user through pop-ups and notifications. Users can directly perform operations such as "terminating abnormal jobs and requeuing failed jobs" on the mobile device without returning to the desktop. This is especially beneficial for time-consuming intelligent computing tasks, enabling timely handling of unexpected situations, avoiding resource waste, and significantly improving job management efficiency. The entire process, from "session authentication, resource selection, job configuration submission" to "status monitoring and result acquisition", is completed on the mobile device. Users can manage HPC jobs in any scenario, such as in the laboratory, on business trips, or at home, completely breaking the constraints of a "fixed desktop environment" and meeting the flexible management needs of diverse application scenarios.

[0065] This invention replaces traditional Linux command-line operations with mobile graphical interaction and template-based design, significantly lowering the technical threshold and enabling non-computer science researchers to easily manage their jobs. At the same time, relying on real-time monitoring, instant response, and full-process mobile coverage, it breaks free from the constraints of a fixed desktop environment, allowing users to monitor job status in real time and quickly handle abnormal tasks in any scenario, significantly improving the flexibility and efficiency of intelligent computing job management. Attached Figure Description

[0066] Figure 1 This is a flowchart of a mobile-based intelligent computing job submission and management method proposed in this invention. Detailed Implementation

[0067] The present invention will be further explained below with reference to specific embodiments.

[0068] Example

[0069] Reference Figure 1 This embodiment proposes a mobile-based intelligent computing job submission and management method. It deploys a web system based on the open-source Open OnDemand platform and packages the web system into a mobile app, enabling visualized one-stop management of the HPC platform. The specific steps include:

[0070] S1: Session establishment and authentication: The mobile app initiates a connection request to the Web service gateway deployed at the front end of the HPC cluster, and the user completes the authentication by entering credentials through the authentication interface integrated in the mobile app, thus establishing a secure session.

[0071] The mobile app establishes a connection by encapsulating the web service interface of the Open OnDemand platform. The secure session adopts the platform's identity authentication system and supports linkage verification with the unified identity authentication system of the HPC cluster.

[0072] S2: Resource Discovery and Selection: The mobile app obtains and visualizes the resource status of currently available compute nodes and queues by calling the cluster status query API, including CPU / GPU load, memory usage and queue waiting status. Based on the resource status, users can select the target compute queue or node on the graphical interface.

[0073] The specific logical steps are as follows:

[0074] S201: When the mobile app launches the "Resource Discovery" function, it automatically completes the configuration of permissions and filtering parameters, as well as the interface and security configuration.

[0075] S202: The mobile app sends a resource query request to the HPC cluster Web service gateway. The Web service gateway pulls data from the monitoring node and returns it. The returned data must include the fields necessary for formula calculation.

[0076] S203: After validating the raw data, the mobile app calculates key indicators using formulas to generate "user-readable resource status data," as detailed below:

[0077] S2031: Calculate CPU / GPU load rate and memory usage.

[0078] CPU load rate = (used CPU / total CPU) × 100%;

[0079] GPU load rate = (used GPU / total GPU) × 100%;

[0080] Memory utilization rate = (usedMem / totalMem) × 100%;

[0081] S2032: Calculate the average queue waiting time:

[0082] Current timestamp = 1716825600, n = 3 is the number of waiting jobs;

[0083] Average waiting time = [(1716825600-1716825480)+(1716825600-1716825360) +(1716825600-1716825240)] / 3 = (120+240+360) / 3 = 240 seconds;

[0084] S2033: Remaining available resources for compute nodes:

[0085] Remaining CPU = total CPU - used CPU;

[0086] Remaining GPUs = total GPUs - used GPUs;

[0087] Remaining memory = total memory - used memory;

[0088] S2034: Calculate queue resource utilization:

[0089] Total CPU usage in the queue = total Nodes in the Queue × total CPU.

[0090] Queue used CPU = Sum of used CPU of each node;

[0091] Queue CPU utilization = (Used CPU / Total CPU) × 100%;

[0092] S2035: Convert the calculation results into an easy-to-read format and store them as a "visualized dataset";

[0093] S204: Based on the calculation results of S203, the mobile app presents the resource status graphically to help users quickly determine its status. The specific content presented includes:

[0094] (1) Node status cards: Each node card displays "CPU load rate", "GPU load rate", "memory usage rate" and "remaining CPU". Load rate >80% is red, 50%-80% is yellow, and <50% is green, which intuitively distinguishes the busy level of the node;

[0095] (2) Queue status charts: The average waiting time of the GPU_HIGH queue and the average waiting time of the GPU_NORMAL queue are displayed using bar charts, and the CPU utilization of the GPU_HIGH queue is displayed using a pie chart. Users can click on the charts to view the calculation details.

[0096] (3) Filtering control: Provides buttons including but not limited to "Filter GPU load rate < 50%" and "Filter average waiting time < 5 minutes". After clicking, resources that do not meet the conditions will be automatically filtered out, and only nodes / queues with qualified calculation results will be displayed.

[0097] S205: When the user clicks "GPU_001 node + GPU_HIGH queue", the APP pops up a confirmation box, showing the key results of the calculation in step S203. At the same time, the mobile APP reads the estimated requirements of the user's job to be submitted and compares them with the "remaining resources" calculated in step S203: Remaining CPU > Job requirements, Remaining GPU > Job requirements, Remaining memory > Job requirements. If the verification passes, if the remaining resources are insufficient, a prompt will pop up: "The selected node has insufficient remaining CPU. We recommend the GPU_003 node with 60 remaining CPU cores" and display the calculation results of the recommended node.

[0098] S206: After the user confirms the selection, the mobile APP caches the "GPU_001 node ID, GPU_HIGH queue ID" and the corresponding calculation results. The mobile APP calls the "resource locking API" to send a request to the scheduling system to "pre-request 8-core CPU and 1 GPU". The scheduling system determines the availability of resources based on the "remaining resources" calculated in step S203 and returns a "pre-request successful" receipt to ensure that resources are not completely occupied before the user submits the job.

[0099] S3: Job Preparation and File Management: Users can access their HPC home directory or project directory through the file manager module of the mobile app in a graphical manner. In the directory, they can perform at least one of the following operations: create input files, upload local files to the cluster, edit the content of existing files, or organize the dataset required for the job.

[0100] The file management module operations include at least one of the following: creating, viewing, deleting, renaming, moving, downloading, copying, and pasting files or directories;

[0101] Editing the content of existing files is achieved by calling the web-based code editor integrated into the app or by using a command-line text editor through the embedded WebShell terminal;

[0102] The file management module supports executing file and directory operation commands via command line through the Web Shell terminal integrated into the mobile APP. The Web Shell terminal is linked in real time with the terminal service of the Open OnDemand platform and operation logs are stored synchronously.

[0103] S4: Job Configuration and Submission: Users configure the calculation job parameters through the job submission form of the mobile APP. The parameters include: job name, execution command, number of cores required, memory size, estimated runtime and dependent software environment. The mobile APP encapsulates the user-configured job parameters into a standard job description script and submits it to the selected queue through the job scheduling system interface.

[0104] The job submission form integrates a job template library, which is built on the JobComposer module of the Open OnDemand platform. Users can choose the platform's pre-set intelligent computing job templates or customize and save job parameter templates and synchronize them to the platform's cloud.

[0105] The specific logical steps are as follows:

[0106] S401: After opening the "Assignment Configuration" page of the mobile APP, the system automatically connects to the backend template library and displays two types of templates: one is the platform's preset templates, and the other is the user's previously saved custom templates. If the user has submitted an assignment and used a template before, the system will automatically read the history and pre-fill the default parameters of the last template into the current assignment form to reduce repeated input.

[0107] S402: Users can filter templates by "scenario tags" according to the current job requirements. Clicking on any template will allow users to view detailed parameters. If the default parameters of the template do not meet the requirements, users can modify them directly in the form. Modified parameters will be marked with a special color to facilitate users to check and adjust the content.

[0108] S403: If no existing template is available, users need to manually fill in all necessary parameters in the form, including job name, execution command, required number of cores / memory, estimated runtime, and dependent software environment. After filling in the parameters, click the "Save as Template" button, enter the template name and tags, and select template permissions. The system will synchronize the template to the cloud for easy reuse later. After saving, the system will report "Template created successfully" and generate a unique template ID. The template can be found directly in the template library without repeated configuration.

[0109] S404: The system automatically checks the form to confirm that the required fields "Job Name, Execution Command, Target Queue, and Required Cores" are filled in completely. If any are missing, it will prompt "Please select the queue to submit the job". Combining the remaining resources of the node determined in the previous "Resource Discovery and Selection" step, it will determine whether the resources required for the current job are within the allocable range. At the same time, the system checks whether the selected "Dependency Software Environment" has been installed on the target node. If the target node does not have it installed, it will prompt "This node does not have it and recommends switching to a node where the software is installed".

[0110] S405: After the parameter verification is successful, the system will automatically convert the user-configured parameters into a standard "job description file" according to the operation rules of the target queue. The file will contain basic job information, software environment loading commands, job execution commands, and log storage paths.

[0111] S406: After the user clicks the "Submit Job" button, the system will display the "Job Submission Confirmation Page," which lists key information such as job name, target queue, required resources, and estimated duration. After confirming that everything is correct, the user clicks "Confirm Submission." The system will then send the job description file to the scheduling system of the HPC cluster. The scheduling system will assign a unique job ID and provide feedback on the submission result. If successful, it will display "Job submission successful, job ID: xxxx, currently in the queue." If it fails, it will display the specific reason. At the same time, the system will save the "job ID, submission time, parameter configuration, and template usage record" to the local machine and the cloud for easy viewing of job status and reuse of parameters or templates later.

[0112] S5: Real-time monitoring and interaction of job status: The mobile APP periodically polls or receives status updates from the job scheduling system via WebSocket connection. On the mobile interface, the job status is displayed in real time in the form of a list or chart, including "Queuing", "Running", "Completed" or "Error". At the same time, user interaction controls are provided to allow users to terminate, requeue or view detailed logs of a specified job.

[0113] The job status monitoring also includes the management of interactive job sessions. The mobile app can display interactive session information created through the OpenOnDemand platform and provide operation controls for session deletion and renewal.

[0114] The specific logical steps are as follows:

[0115] S501: After the user submits the job, the mobile APP will automatically start the "job monitoring" function. The APP will detect the current network latency in real time. If the latency is >1000ms, it is judged as "unstable network"; if 300ms≤latency≤1000ms, it is judged as "stable network"; if the latency is <300ms, it is judged as "good network".

[0116] S502: When the network is stable / high-quality, a WebSocket long connection is used to receive status updates in real time without polling. When the network is unstable, it automatically switches to periodic polling and calculates the actual polling interval using the following formula:

[0117] S503: The mobile app associates all jobs under the user's account, pulls the initial status from the scheduling system as monitoring baseline data, and presents the acquired status data in a visual form for easy and intuitive viewing by the user.

[0118] S504: After the mobile app receives a status change, it processes the information according to priority and notifies the user. The priority rules are as follows: When the status changes to "Completed" or "Error", a pop-up window and notification bar message will be sent, which will include the job name, status and operation suggestions.

[0119] S505: The mobile app provides interactive controls to support user operations on the job, specifically:

[0120] S5051: Based on the current status of the job, the corresponding control is enabled. For jobs in the "Queued / Running" state, the "Terminate" button is displayed; for jobs in the "Error / Terminated" state, the "Re-queue" button is displayed; and for jobs in all states, the "View Log" button is displayed.

[0121] S5052: When the user clicks "Terminate," the mobile app sends a termination request to the scheduling system. Upon successful termination, the status updates to "Terminated." When the user clicks "Re-queue," the mobile app reuses the original job configuration to submit the request, and the status updates to "Queuing." When the user clicks "Logs," they can view the execution log, error log, and system log. Keyword search is supported, and the matching degree is calculated using formulas and displayed in sorted order.

[0122] S5053: After each operation, the mobile APP will pop up a window to show the result, ensuring that the user is aware of the operation status;

[0123] S506: Users can manually adjust monitoring settings and view historical data. When users click "Pause Monitoring" in "Settings", the mobile app stops receiving status updates. Clicking "Resume Monitoring" will re-establish the connection and retrieve the latest status. When users click "History", the mobile app will display the timeline of completed tasks and resource usage statistics to help users review the task situation.

[0124] S6: Result Acquisition and Post-processing: When the job status changes to "Completed", the mobile APP automatically notifies the user. The user can browse, preview or download the standard output, standard error and result files generated by the job to the local mobile device through the file manager module.

[0125] When acquiring and post-processing results, the Open OnDemand platform's visualization application can be directly opened via a mobile app, allowing users to preview the generated visualization charts and engineering simulation image result files online without downloading them to their local device.

[0126] This embodiment replaces traditional Linux command-line operations with mobile graphical interaction and template-based design, significantly reducing the technical threshold and allowing non-computer science researchers to easily complete job management. At the same time, relying on real-time monitoring, instant response and full-process mobile coverage, it breaks free from the constraints of a fixed desktop environment, enabling users to grasp the job status in real time and quickly handle abnormal tasks in any scenario, significantly improving the flexibility and efficiency of intelligent computing job management.

[0127] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A mobile-based intelligent computing job submission management method, characterized in that, Deploying a web system based on the open-source Open OnDemand platform and packaging the web system into a mobile app to achieve visualized, one-stop management of the HPC platform, specifically includes the following steps: S1: Session establishment and authentication: The mobile app initiates a connection request to the Web service gateway deployed at the front end of the HPC cluster, and the user completes the authentication by entering credentials through the authentication interface integrated in the mobile app, thus establishing a secure session. S2: Resource Discovery and Selection: The mobile app obtains and visualizes the resource status of currently available compute nodes and queues by calling the cluster status query API, including CPU / GPU load, memory usage and queue waiting status. Based on the resource status, users can select the target compute queue or node on the graphical interface. S3: Job Preparation and File Management: Users can access their HPC home directory or project directory through the file manager module of the mobile app in a graphical manner. In the directory, they can perform at least one of the following operations: create input files, upload local files to the cluster, edit the content of existing files, or organize the dataset required for the job. S4: Job Configuration and Submission: Users configure the calculation job parameters through the job submission form of the mobile APP. The parameters include: job name, execution command, number of cores required, memory size, estimated runtime and dependent software environment. The mobile APP encapsulates the user-configured job parameters into a standard job description script and submits it to the selected queue through the job scheduling system interface. S5: Real-time monitoring and interaction of job status: The mobile APP periodically polls or receives status updates from the job scheduling system via WebSocket connection. On the mobile interface, the job status is displayed in real time in the form of a list or chart, including "Queuing", "Running", "Completed" or "Error". At the same time, user interaction controls are provided to allow users to terminate, requeue or view detailed logs of a specified job. S6: Result Acquisition and Post-processing: When the job status changes to "Completed", the mobile APP automatically notifies the user. The user can browse, preview or download the standard output, standard error and result files generated by the job to the local mobile device through the file manager module.

2. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, In S1, the mobile APP establishes a connection by encapsulating the web service interface of the Open OnDemand platform. The secure session adopts the platform's identity authentication system and supports linkage verification with the unified identity authentication system of the HPC cluster.

3. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, The specific logical steps of S2 are as follows: S201: When the mobile app launches the "Resource Discovery" function, it automatically completes the configuration of permissions and filtering parameters, as well as the interface and security configuration. S202: The mobile app sends a resource query request to the HPC cluster Web service gateway. The Web service gateway pulls data from the monitoring node and returns it. The returned data must include the fields necessary for formula calculation. S203: After validating the raw data, the mobile app calculates key indicators using formulas to generate "user-readable resource status data," as detailed below: S2031: Calculate CPU / GPU load rate and memory usage. CPU load rate = (used CPU / total CPU) × 100%; GPU load rate = (used GPU / total GPU) × 100%; Memory utilization rate = (usedMem / totalMem) × 100%; S2032: Calculate the average queue waiting time: Current timestamp = 1716825600, n = 3 is the number of waiting jobs; Average waiting time = [(1716825600-1716825480)+(1716825600-1716825360) +(1716825600-1716825240)] / 3 = (120+240+360) / 3 = 240 seconds; S2033: Remaining available resources for compute nodes: Remaining CPU = total CPU - used CPU; Remaining GPUs = total GPUs - used GPUs; Remaining memory = total memory - used memory; S2034: Calculate queue resource utilization: Total CPU usage in the queue = total Nodes in the Queue × total CPU. Queue used CPU = Sum of used CPU of each node; Queue CPU utilization = (Used CPU / Total CPU) × 100%; S2035: Convert the calculation results into an easy-to-read format and store them as a "visualized dataset"; S204: Based on the calculation results of S203, the mobile app presents the resource status graphically to help users quickly determine its status. The specific content presented includes: (1) Node status card: Each node card displays "CPU load rate", "GPU load rate", "memory usage rate" and "remaining CPU". Load rate > 80% is red, 50%-80% is yellow, and < 50% is green, which intuitively distinguishes the busy level of the node; (2) Queue status charts: The average waiting time of the GPU_HIGH queue and the average waiting time of the GPU_NORMAL queue are displayed using bar charts, and the CPU utilization of the GPU_HIGH queue is displayed using a pie chart. Users can click on the charts to view the calculation details. (3) Filtering control: Provides buttons including but not limited to "Filter GPU load rate < 50%" and "Filter average waiting time < 5 minutes". After clicking, resources that do not meet the conditions will be automatically filtered out, and only nodes / queues with qualified calculation results will be displayed. S205: When the user clicks "GPU_001 node + GPU_HIGH queue", the APP pops up a confirmation box, showing the key results of the calculation in step S203. At the same time, the mobile APP reads the estimated requirements of the user's job to be submitted and compares them with the "remaining resources" calculated in step S203: Remaining CPU > Job requirements, Remaining GPU > Job requirements, Remaining memory > Job requirements. The verification passes. If the remaining resources are insufficient, a prompt will pop up: "The selected node has insufficient remaining CPU. We recommend the GPU_003 node with 60 remaining CPU cores". The calculation results of the recommended node will be displayed. S206: After the user confirms the selection, the mobile APP caches the "GPU_001 node ID, GPU_HIGH queue ID" and the corresponding calculation results. The mobile APP calls the "resource locking API" to send a request to the scheduling system to "pre-request 8-core CPU and 1 GPU". The scheduling system determines the availability of resources based on the "remaining resources" calculated in step S203 and returns a "pre-request successful" receipt to ensure that resources are not completely occupied before the user submits the job.

4. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, In S3, the file management module operations include at least one of the following: creating, viewing, deleting, renaming, moving, downloading, copying, and pasting files or directories; Editing the content of existing files is achieved by calling the web-based code editor integrated into the app or by using a command-line text editor through the embedded WebShell terminal; The file management module supports executing file and directory operation commands via command line through the Web Shell terminal integrated into the mobile app. The Web Shell terminal is linked in real time with the terminal service of the Open OnDemand platform and operation logs are saved synchronously.

5. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, In S4, the job submission form integrates a job template library function. The template library is built based on the Job Composer module of the Open OnDemand platform. Users can select the platform's pre-set intelligent computing job templates or customize and save job parameter templates and synchronize them to the platform's cloud. The specific logical steps of S4 are as follows: S401: After opening the "Assignment Configuration" page of the mobile APP, the system automatically connects to the backend template library and displays two types of templates: one is the platform's preset templates, and the other is the user's previously saved custom templates. If the user has submitted an assignment and used a template before, the system will automatically read the history and pre-fill the default parameters of the last template into the current assignment form to reduce repeated input. S402: Users can filter templates by "scenario tags" according to the current job requirements. Clicking on any template will allow users to view detailed parameters. If the default parameters of the template do not meet the requirements, users can modify them directly in the form. Modified parameters will be marked with a special color to facilitate users to check and adjust the content. S403: If no existing template is available, users need to manually fill in all necessary parameters in the form, including job name, execution command, required number of cores / memory, estimated runtime, and dependent software environment. After filling in the parameters, click the "Save as Template" button, enter the template name and tags, and select template permissions. The system will synchronize the template to the cloud for easy reuse later. After saving, the system will report "Template created successfully" and generate a unique template ID. The template can be found directly in the template library without repeated configuration. S404: The system automatically checks the form to confirm that the required fields "Job Name, Execution Command, Target Queue, and Required Cores" are filled in completely. If any are missing, it will prompt "Please select the queue to submit the job". Combining the remaining resources of the node determined in the previous "Resource Discovery and Selection" step, it will determine whether the resources required for the current job are within the allocable range. At the same time, the system checks whether the selected "Dependency Software Environment" has been installed on the target node. If the target node does not have it installed, it will prompt "This node does not have it" and recommend switching to a node where the software is installed. S405: After the parameter verification is successful, the system will automatically convert the user-configured parameters into a standard "job description file" according to the operation rules of the target queue. The file will contain basic job information, software environment loading commands, job execution commands, and log storage paths. S406: After the user clicks the "Submit Job" button, the system will display a "Job Submission Confirmation Page," listing key information such as job name, target queue, required resources, and estimated duration. After confirming that everything is correct, the user clicks "Confirm Submission." The system will then send the job description file to the HPC cluster's scheduling system. The scheduling system will assign a unique job ID and provide feedback on the submission result. If successful, it will display "Job submission successful, job ID: xxxx, currently in the queue." If it fails, it will display the specific reason. At the same time, the system will save the "job ID, submission time, parameter configuration, and template usage record" to both the local machine and the cloud for easy viewing of job status and reuse of parameters or templates later.

6. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, In S5, the job status monitoring also includes the management of interactive job sessions. The mobile APP can display interactive session information created through the OpenOnDemand platform and provide operation controls for session deletion and renewal.

7. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, In S6, during result acquisition and post-processing, the visualization application of the Open OnDemand platform can be directly opened via a mobile APP to preview the visualization charts and engineering simulation image result files generated by the job online, without having to download them to the local machine.

8. The intelligent computing job submission management method based on a mobile terminal according to claim 1, characterized in that, The specific logical steps of S5 are as follows: S501: After the user submits the job, the mobile APP will automatically start the "job monitoring" function. The APP will detect the current network latency in real time. If the latency is >1000ms, it is judged as "unstable network"; if 300ms≤latency≤1000ms, it is judged as "stable network"; if the latency is <300ms, it is judged as "good network". S502: When the network is stable / high-quality, a WebSocket long connection is used to receive status updates in real time without polling. When the network is unstable, it automatically switches to periodic polling and calculates the actual polling interval using the following formula: S503: The mobile app associates all jobs under the user's account, pulls the initial status from the scheduling system as monitoring baseline data, and presents the acquired status data in a visual form for easy and intuitive viewing by the user. S504: After the mobile app receives a status change, it processes the information according to priority and notifies the user. The priority rules are as follows: When the status changes to "Completed" or "Error", a pop-up window and notification bar message will be sent, which will include the job name, status and operation suggestions. S505: The mobile app provides interactive controls to support user operations on the job, specifically: S5051: Based on the current status of the job, open the corresponding control. For jobs in "Queued / Running", display the "Terminate" button; for jobs in "Error / Terminated", display the "Re-queue" button; and for jobs in all statuses, display the "View Log" button. S5052: When the user clicks "Terminate," the mobile app sends a termination request to the scheduling system. Upon successful termination, the status updates to "Terminated." When the user clicks "Re-queue," the mobile app reuses the original job configuration to submit the request, and the status updates to "Queuing." When the user clicks "Logs," they can view the execution log, error log, and system log. Keyword search is supported, and the matching degree is calculated using formulas and displayed in sorted order. S5053: After each operation, the mobile APP will pop up a window to show the result, ensuring that the user is aware of the operation status; S506: Users can manually adjust monitoring settings and view historical data. When users click "Pause Monitoring" in "Settings", the mobile app stops receiving status updates; when users click "Resume Monitoring", the connection is re-established and the latest status is retrieved. When users click "History", the mobile app displays the timeline of completed tasks and resource usage statistics to help users review the task status.

Images