## 5 Statistical Analysis of the Dataset
As expected, the three data series appear to have very different domains, especially for average power consumption: e.g., while most jobs running on 2 nodes have average power consumption under 1000 W, running on 8 nodes consumes between 1000 W and 3000 W, and jobs on 16 nodes generally consume between 3000 W and 5000 W. We remark that the graph presents the average power consumption for different numbers of nodes on the \(x\) axis (cumulative power, summing all nodes), and on the \(y\) axis, the number of jobs showing that power. It was built by first computing the power profiles of each job over time (summing together the contribution of different nodes if the job runs in parallel on multiple machines) and then calculating the mean value of that profile. Depending on such a value, the job contributes to increasing by one the height of the corresponding bar in the plot. Hence, as expected, the plot suggests an increase in the average power consumption linear with the number of employed nodes. Delving more into the dataset, we observe that jobs running on 2 nodes have a mean power consumption of 504 W on average, on 8 nodes 2240 W (around \(\times\)4 with respect to 2 nodes), and on 16 nodes 4271 W (around \(\times\)8 with respect to 2 nodes). On the other hand, Figure 4 shows that the energy and runtime profiles of the three series have domains not as distinct as that of the power metrics, highlighting that some jobs running on just two nodes needed more time to complete, and, as a consequence, consumed a considerable amount of energy, comparable to that of shorter jobs involving many more nodes. This behaviour, which may appear counterintuitive, is derived from two apparently unrelated factors: _(i)_ the jobs are not always launched saturating the cores available on the involved nodes; _(ii)_ both IMe and ScaLAPACK parallel solvers operate on large data structures generating contention between the MPI ranks executing on different cores of the same machine in the access to the bus, cache and memory. This is especially true if the job saturates the machine's available cores. As a consequence, the execution of a certain job on the minimum number of physical machines may require so much more time than executing it on more machines, so that the increase in the energy derived by the employment of more nodes is actually conterb balanced by the fact that the job requires much less time to execute. The same considerations can be made looking at Figure 5, which correlates energy and runtime: jobs are ordered by runtimes on the \(x\) axis and the two lines show the energy consumed by the job (total energy) and its value normalised by the number of involved nodes (energy per node). As expected, the energy per node is linear in the runtime, while the total energy consumed by a job shows a much higher variability caused by the aforementioned resource contention. Different trends are visible in Figure 6, where the data distributions are limited to three distinct matrix ranks (5280, 26,400, and 42,240). In general, jobs working on smaller matrices have lower runtimes and energy utilisation than solvers working on big matrices, while the distributions of average and peak power consumption seem to be less matrix-size-independent. Figure 7 shows the distribution of the four metrics when different rank assignment methods are employed (\"span\" and \"fill\"). All in all, the trends do not highlight a significant difference in any metric between the two cases. Similar considerations can be made for Figure 8, which unveils the distributions when single or double precision is used in the  
While a comparison by algorithm did not highlight significant differences, in Figure 9, the focus is on the level of fault tolerance that the solver can handle (i.e., the maximum number of processors that can incur a hard fault without invalidating the whole computation). For the sake of clarity, only two levels of fault tolerance are shown in the graph: 0 (i.e., the fault tolerance method is not implemented) and 8.