## 3 Execution Framework
The actual number of cores needed by the MPI algorithm will be defined in the MPI launch script, and if the algorithm uses fewer cores than specified, the unused processors will turn to the _idle_ state but will not be released. In this way, we can test, for example, a job distributing its work to 48 ranks, in different settings: e.g., using all cores of one machine, using 24 cores of two different machines, or using 12 cores of four machines. Requirement R2 is needed because, by default, LSF aims to maximise the whole datacenter utilisation: if a physical node is partially used by other users, LFS may decide to assign some processes of a job to the remaining cores. Therefore, just requesting LSF a number of cores equal to 48 multiplied by the desired nodes (as stated to comply with R1) is not enough to actually guarantee that those 48 cores will belong to the same machine. The launch step is therefore responsible for specifying that each node must have 48 free cores in the LSF context of CRESCO6. Finally, the third requirement is needed to ensure the proper measurement of the job's energy consumption through the communication mechanism with the node acquiring data from the sensors. To achieve this, the launch step relies on the dependency requirements between jobs. In particular, the specified requirement is like \"ended(_previous_job_name_)\", indicating that the job at hand can only start after the previously submitted job has finished. The termination condition is valid independently of the termination status (error/success) of the predecessor job. This flexibility maximises the overall time efficiency of the benchmark workflow and helps to ensure continuity of operations by reducing possible delays due to individual failures. Since LSF dynamically decides at runtime the allocation of jobs to physical nodes, we implemented a mechanism to communicate this association to the script that collects sensor data. To communicate this information to the monitoring node, options were introduced to allow a _pre-execution phase_ to run on the first host assigned to the job by LSF. In detail, once a job is submitted, it enters the LSF queue until sufficient resources are available to satisfy the constraints specified in the submit command. When it is picked from the queue, a pre-execution script starts. The success of this script is a prerequisite for the actual execution of the job. In our context, the usefulness of the pre-execution script is related to how LSF allocates resources (i.e., nodes) based on constraint satisfaction. Since the allocated nodes may vary from job to job, the pre-execution script communicates the resource information to the measurement software. In order to limit the overhead caused by the monitoring  
Figure 2: Framework scheme. task, our approach monitors only the nodes involved in the current job, rather than the entire system. The third step in Figure 2 is the _Execution Phase_. Each machine in the CRESCO6 cluster is a Lenovo Think System SD530 equipped with vendor-specific sensors [49] that can measure various parameters, including energy consumption and node temperature. To obtain their data, during job execution, a command must be run on an isolated node in the CRESCO6 architecture (the monitoring node), which cannot be reached by user access nodes. Whenever this command is invoked, the instantaneous values sensed by the sensors on the CRESCO6's node passed as the input parameter are returned. The collection of the measures is performed through multiple parallel instances of the same measurement script. These instances act as daemons and operate cyclically, each collecting data from a single node with configurable frequency, and populating a database. For an efficient and effective operation of the monitoring system, a locking mechanism ensures that only the necessary parallel instances are used, while the others remain idle.