## 2 Materials and Methods
### Architecture Design of the Cloud-Edge Hybrid Intelligent System (CEHIS)
#### 2.1.3 Pipelines  
Scientific computation approaches, such as the matrix multiplication and solving systems of linear equations, are essential components of the SSRF's computational activities.  
Figure 1: Hardware architecture of the CEHIS at the SSRF.  
\begin{table}
\begin{tabular}{c c c c c} \hline
**CPU** & **Memory** & **Storage** & **GPU** & **Application** & **Beamline** \\ \hline x86 \(\times\) 2 & & 192 GB & 192 TB & & \\
2.9 GHz & 16 cores & 7200 RPM \(\times\) 12 & & Big metadata & BL16U2 \\ \hline x86 \(\times\) 2 & & 96 TB & & \\
2.0 GHz & 512 GB & 7200 RPM \(\times\) 6 & & Big metadata & BL03 SB \\
64 cores & & & & \\ \hline x86 \(\times\) 2 & & 48 TB & RTX3080 TI & 3D data pipelines & BL17M \\
2.9 GHz & 192 GB & 7200 RPM \(\times\) 3 & & Big metadata & BL18B \\
16 cores & & & & Real-time pipelines & BL12 SW \\ \hline x86 \(\times\) 2 & & 184.32 TB & & & BL12 SW \\
2.9 GHz & 192 GB & Intel S4510 & RTX5000 \(\times\) 2 & 3D data pipelines & BL13U \\
16 cores & & \(\text{SSD}\times\text{24}\) & & & etc. \\ \hline \end{tabular}
\end{table}
Table 3: _Cont._These computations often involve the management of massive amounts of data and rely on parallel and distributed computing in order to enhance the data processing performance. For instance, after acquiring a dataset using the Aquarium system, the automated data analysis system at the SSRF MX beamline launches five HPC parallel pipelines concurrently. These pipelines apply a variety of data reduction techniques, and the best result from the five pipelines is then selected for further processing. Therefore, a single job sent by the Aquarium to the data center consists of five tasks with different degrees of complexity and execution time. The entire data processing workflow of the Aquarium system is illustrated in Figure 2.  
With our study, we have simulated the queuing jobs and tasks generated by the beamlines at the SSRF, where the computational tasks submitted by the users are modeled as jobs, with each job consisting of several tasks and scheduling being performed at the task level. A task is represented by \([submit\_time,duration,cpu,memory,job\_id,task\_id,instance\_num]\). The \(task\_id\) is the unique identifier for the task, whereas \(job\_id\) identifies the job to which the task belongs. The \(submit\_time\) specifies the time at which the task was submitted, whereas \(duration\) indicates the time required to run a single task instance. The \(cpu\) represents the computing resources necessary for the task, while \(memory\) signifies the memory resources necessary for the task, and \(instance\_num\) indicates the number of task instances. A variable number of task instances can be defined for each task, based on the analysis of the SSRF's computational requirements and task characteristics, as previously described. In contrast, a task instance is an individual execution instance of a task. When a task is repeated several times, either in parallel or with different input parameters, each of these executions is referred to as a task instance. The task instance is effectively a running instance of the task, and it is the task instance that is scheduled and executed on a computing node. A computational job and its structure are shown in Figure 3.