Find research datasets worth reusing

Artifact for A Survey on Techniques to Profile the Energy Consumption of Android Applications

<p>To ensure availability and reproducibility, we have made all study artifacts publicly available for "<strong>A Survey on Techniques to Profile the Energy Consumption of Android Applications</strong>", a paper submitted to <strong><em>ACM Computing Surveys</em></strong>. In this study, we review state-of-the-art software-based energy profilers tailored for Android applications and propose a novel taxonomy for comparative analysis. We provide a brief overview of these energy profilers and compare their features. Based on the conducted literature review, we present conceptual architectures of the different types of software-based energy profilers to help build a tool that addresses the existing limitations in energy profiling.</p> <p>This repository contains the following files:</p> <ul> <li>Coding list generated from the Nvivo project (Files compared by number of codes). This file contains the codes used in taxonomy and the number of code references.</li> <li>Coding hierarchy generated from the Nvivo project (Codes compared by number of coding references). This file shows the hierarchy of codes and their share visually.</li> <li>List of selected papers (generated from the Nvivo project). This file presents the list of selected papers and metadata about these papers including publishing year, publisher, type of publication, etc.</li> <li>Search queries (SearchQueries). This file contains the search queries that are used to obtain the publications for review.</li> <li>Summary of the papers generated from the Nvivo project (Summary). This file contains the summary of the papers.</li> </ul>

AWESOME Energy System Model data and model

<p><span>This repository collects all the necessary items defined to setup and to run the Energy System optimization model for the AWESOME project.</span></p> <p><span>Detailed specifications of the adopted model (OSeMOSYS) and data are descripted in Deliverable D2.4 document: "</span><span>Future Energy Scenarios".</span></p> <p><span>In particular, the repository provides all essential data and scripts to define the energy model defined for projecting the energy scenarios developed for the AWESOME project. The document reports the development of an open-source energy system optimization model of the energy supply chain for the spatial domain useful for the AWESOME project (i.e. including Egypt, Ethiopia, and Sudan). The model is then used to explore different pathways of future energy scenarios in terms of energy demand and infrastructure evolution and their economic and environmental impacts. The future sectoral energy demand scenarios are developed based on the Socio-economic Pathways (SSPs) and the outcomes of D2.1 (Demographic projections), using a multi-sectoral optimal resource allocation economic model. </span></p> <p>This record contains:</p> <p>- The Deliverable D2.4, where the optimization model and the calculation of the energy system scenarios under different climatic scenarios are presented.</p> <p>- The results for each implemented scenario, in terms of installed capacity and energy generation of energy technologies (.tif files and excel files), for the Nile River Basin and at the national level for each focus country (Ethiopia, Sudan and Egypt).</p> <p>- Description of the data (excel file and pdf file)</p>

Multiple Parameter Replica Exchange Gaussian Accelerated Molecular Dynamics for Enhanced Sampling and Free Energy Calculation of Biomolecular Systems

Open the record for dataset details and reuse information.

openmit-licenseApr 2024View details →

Modelling and Comparing Converter Architectures and Energy Harvesting ICs for Battery-Free Systems

<p>Artifacts containing measurement scripts, data sets, and simulations for the paper "Modelling and Comparing Converter Architectures and Energy Harvesting ICs for Battery-Free Systems" (currently submitted and under review).</p>

Distance Dependence of the Energy Transfer Mechanism in WS2-Graphene Heterostructures

<h2>Description of Uploaded Raw Data and Programs for Recreating Figures</h2> <h3>Raw Data</h3> <p>The raw data in this dataset is primarily in  ".np" binary format, which is used by the python package numpy.</p> <h3>Software and Programs</h3> <p>The figures in the paper were generated using Python programs, as well as Jupiter Notebooks, which are included in the dataset. These programs are sorted in their respective folders.</p>

Source Data for the publication "Sub-100-fs energy transfer in coenzyme NADH is a coherent process assisted by a charge-transfer state"

<p>Molecular Structures for solvated NADH. </p> <p>The folder "QMMM_OPTIMIZED_STRUCTS" contains the pdb files of the six  representatives for the three conformational clusters obtained after REMD used in the Supplementary Information.</p> <p>The folder "SOLVENT_ENSEMBLE_AROUND_FIXED_SOLUTE" conatins AMBER RESTART files for 200 solvent configurations around two cluster reps displayed in Figure 2 of main manuscript. </p> <p>The folder "PARAMETERS_FOR_MLMCTDH" contains the input file, operator file and parameters for ML-MCTDH dynamics for the structures shown in Main Manuscript and Supplementary. </p>

Data: relation between soft tissue energy dissipation and leg stiffness in running at different step frequencies

<p>Data set - paper:  <span>Relation between soft tissue energy dissipation and leg stiffness in running at different step frequencies </span></p>

Molecular docking analysis was performed to assess the affinity of onalespib for their targets LOX, elucidating binding poses, protein interactions, and associated binding energies.

<p>To analyze the binding affinities and interaction modes between the drug candidates and their targets, we employed the Autodock Vina software [21]. Molecular structures of the candidate drugs and targets of hub genes were retrieved from Pubchem (https://pubchem.ncbi.nlm.nih.gov/) and Protein Data Bank database (http://www.rcsb.org/), respectively. <span>In the analysis of docking, the files for all proteins and molecules were converted to PDBQT format. Water molecules were removed and polar hydrogen atoms were added. The grid box was positioned at the center to encompass the protein domain, allowing for unrestricted movement of molecules.</span></p>

Key results and plot files for the paper "Diversity of biomass usage pathways to achieve emissions targets in the European energy system"

<p>Key results and plot files for the paper:</p> <p>Millinger, M., Hedenus, F., Zeyen, E. <em>et al.</em> Diversity of biomass usage pathways to achieve emissions targets in the European energy system. <em>Nat Energy</em> <strong>10</strong>, 226–242 (2025). https://doi.org/10.1038/s41560-024-01693-6</p>

Surface Kinetic energy from MITgcm-GEOS5 Coupled Ocean-Atmosphere Simulation

<p>Annual mean of surface kinetic energy computed from MITgcm-GEOS5 coupled ocean-atmosphere simulation, with a spacing grid of 4 km.</p> <p>The temporal coverage for the annual mean spans from March 01, 2020, to March 01, 2021.</p>

Disentangling Sources of Uncertainty in CLM5 Model Predictions: Water, Energy, and Carbon Fluxes at European Observation Sites

<p>The datasets include:</p> <ul> <li>EC data from Europement measurement sites in <a href="https://www.icos-cp.eu/data-products/2G60-ZHAK">ICOS</a>, <a href="https://fluxnet.org/login/?redirect_to=/data/download-data/">FLUXNETS</a>, and <a href="https://doi.org/10.34731/x9s3-Kr48">COSMOS-Europe</a>.</li> <li>Ensemble simulation data used for analysis</li> </ul> <p>The atmospheric forcings used in driving the model were all local measurements pre-processed using the script in GitHub repository <a href="https://github.com/FedoAIworld/CLM5-Disentangling-Uncertainty/tree/main/00_create_forcing_ds">CLM5-Disentangling-Uncertainty</a>.</p>

Supplementary material for "Comprehensive framework for dynamic energy assessment of building systems using IFC graphs and Modelica"

<p>The provided files include the following:</p> <ul> <li>The IFC model of the demo building used in Section 2.</li> <li>The parsed space boundaries graph.</li> <li>The resulting fragmented space boundaries graph.</li> </ul>

Heating by Dissipation of Energy from Absorbed Light: Molecular Mechanisms Underlying the Survival Strategy of Polar Algae

<p>The original data, which served as the source material for the scientific article on the polar alga <em>Pediastrum orientale, co</em>llected from Reindeer Lake on Spitsbergen. Consists of datasets obtained using various techniques: fluorescence microscopy (microscope_fluo), fluorescence lifetime microscopy (FLIM), high-performance liquid chromatography (HPLC), atomic force microscopy (AFM), Raman microspectroscopy (RAMAN), fluorescence lifitime spectroscopy (lifetime) and fluorescence spectroscopy (Fluo).<br><br>HPLC - Nexera LC-40 (Shimadzu, Japan)<br>FLIM - OLYMPUS IX71 confocal microscope MicroTime 200 with SymPhoTime 64 software package (PicoQuant, GmbH, Germany)<br>RAMAN - inVia Reflex confocal Raman microscope with the WiRE 5.5 software package (Renishaw, UK)<br>AFM - JPK Nanowizard 3 system with JPKSMP data processing software (Bruker, USA)<br>Lifetime - FluoTime 300 spectrometer with FluoFit Pro v 4.5.3.0 (PicoQuant, Germany)<br>Microscope_Fluo - Zeiss LSM980 confocal microscope with Airy2 and Elyra7 detectors and ZEN 3.1 software (Zeiss, Germany)<br>Fluo - OLYMPUS IX71 confocal microscope MicroTime 200 system with the spectrograph SR-163 and the Newton 970 EMCCD camera (Andor Technology)<br><br></p> <p> </p> <p> </p>

opencc-by-4.0Oct 2024View details →

Free Energy of Membrane Pore Formation and Stability from Molecular Dynamics Simulations

Open the record for dataset details and reuse information.

opencc-by-4.0Feb 2024View details →

Bluetooth Low Energy Separate Channel Fingerprinting dataset with Frequency-Scanned Antennas and Monopole

<p><span>This dataset contains Bluetooth Low Energy Separate Channel (SC BLE) Fingerprinting (FP) data recorded in an indoor facility. The dataset includes Received Signal Strength Information (RSSI) data collected from two independent location systems: one created with four BLE beacons connected to four traditional monopole antennas, and the other four beacons connected to two dual-port Frequency-Scanned Leaky Wave Antennas (FS LWA). Both systems are installed covering the same 7m x 5m area located in a basement zone. </span></p> <p><span>The dataset includes a reference radiomap file for each point equidistant 50cm to generate Fingerprinting techniques. The calibrated radiomap files are included in the Calibration_21112023 folder. In the name of each file, the {x, y} position where the data were recorded is included, with a total of 130 reference points. The data labelled as P1 and P2 are the RSSI recorded from beacons connected to FS LWA1, while P3 and P4 data corresponds to RSSI obtained from beacons of FS LWA2. Finally, P5, P6, P7 and P8 data sets belong to beacons connected to individual monopole antennas. Each calibration file contains 100 samples of RSSI received from the corresponding beacons at each one of the 130 reference points forming the calibration grid. </span></p> <p><span>The dataset also includes test samples for different days. These days are labelled as day 1, 8, 15, 22, 29, 51, 86 and 94 after the calibration day 0. This way, the variation of the different SC FP BLE antenna systems’ performance over time, can be studied. This classification of the data as a function of time, is categorized in the folders with the names Test_day_XX_date. As done with the reference calibration information for day 0, a file with the RSSI collected in each reference point (within a total of 130 grid points) can be found in each folder. The name of the file indicates the reference point where the data were collected. </span></p> <p><span>Different to the reference calibration data of day 0 (where 100 RSSI samples were considered for each one of the 130 calibrated {x, y} positions), the test data obtained in different subsequent days is composed by ten samples of RSSI for each one of the 130 test point. </span></p> <p><span>Moreover, to test the performance of the systems when some modifications occur where the calibration was performed, some data tests are collected adding several offices' furniture on the days 15, 22, 29, 51 and 94 after the calibration procedure performed at day 0. These data are stored in folders with the name Test_day_XX_with_furnitures_date. Similar to the previous test data, the name of the file includes 130 reference {x,y} points, with 10 RSSI samples each, and for the corresponding eight beacons (P1..P8), which are labelled for both monopole (P5, P6, P7 and P8) and FS LWA antenna systems (P1 and P2 for FS LWA1 and P3 and P4 for FS LWA2). <span> </span></span></p>

opencc-by-4.0Jul 2024View details →

Data and GDS file for "Methods to achieve near-millisecond energy relaxation and dephasing times for a superconducting transmon qubit"

<p>Data and GDS files for "Methods to achieve near-millisecond energy relaxation and dephasing times for a superconducting transmon qubit"</p>

opencc-by-4.0Oct 2024View details →

Understanding the Energy Consumption of Cloud-native Software Systems

<p>These artifacts contain the dataset generated in the paper "Understanding the Energy Consumption of Cloud-native Software Systems". The dataset contains resource utilisation, power consumption, estimated power consumption and load metrics for a cloud-native software system. The test setup is consists of 6 machines running an OpenStack cluster. This OpenStack cluster is running 12 virtual machines that are in turn hosting a Kubernetes cluster. Performance and (estimated) power consumption are measured on all levels of the system.</p> <p>The Bare-Metal (BM) and Virtual Machines (VM) are identified by their IP addresses. For BM the IP mapping is as follows:</p> <ul> <li>192.168.1.109 - i3-04</li> <li>192.168.1.110 - i3-02</li> <li>192.168.1.111 - i5-02</li> <li>192.168.1.112 - i3-01</li> <li>192.168.1.113 - i5-01</li> <li>192.168.1.114 - i5-04</li> </ul> <p>For VM the IP mapping is:</p> <ul> <li>192.168.1.190 - kubernetes-agent-7</li> <li>192.168.1.191 - kubernetes-agent-6</li> <li>192.168.1.192 - kubernetes-agent-10</li> <li>192.168.1.194 - kubernetes-master</li> <li>192.168.1.196 - kubernetes-agent-3</li> <li>192.168.1.197 - kubernetes-agent-1</li> <li>192.168.1.198 - kubernetes-agent-2</li> <li>192.168.1.201 - kubernetes-agent-4</li> <li>192.168.1.203 - kubernetes-agent-9</li> <li>192.168.1.204 - kubernetes-agent-5</li> <li>192.168.1.207 - kubernetes-agent-8</li> <li>192.168.1.209 - kubernetes-agent-11</li> </ul> <p>The VMs are deployed on the BMs as follows:</p> <ul> <li>i3-01 <ul> <li>kubernetes-agent-2</li> <li>kubernetes-agent-8</li> </ul> </li> <li>i3-02 <ul> <li>kubernetes-agent-1</li> <li>kubernetes-agent-6</li> </ul> </li> <li>i3-04 <ul> <li>kubernetes-agent-10</li> <li>kubernetes-agent-11</li> </ul> </li> <li>i5-01 <ul> <li>kubernetes-agent-3</li> <li>kubernetes-agent-5</li> </ul> </li> <li>i5-02 <ul> <li>kubernetes-master</li> <li>kubernetes-agent-7</li> </ul> </li> <li>i5-04 <ul> <li>kubernetes-agent-4</li> <li>kubernetes-agent-9</li> </ul> </li> </ul> <p>Note that the following BMs are excluded from the experiments as they have other roles in the cluster and do not run workloads:</p> <ul> <li>i3-03 (Juju - deploying OpenStack on BM nodes)</li> <li>i3-05 (ProxMox - external observability tools that do not run in the cluster)</li> <li>i5-03 (MAAS - provisioning of BM nodes)</li> </ul> <h1>Data Sets</h1> <p>The artifacts consists of 3 separate data sets: <code>constant</code>, <code>direct</code> and <code>linear</code>, corresponding to the respective load profile applied to the SUT as discussed in the paper. Each data set contains the same metrics, but the system is put under a different load.</p> <p>Every experiment is repeated 3 times. All 3 repetitions are included in the data set. The data is collected using Prometheus and stored in JSON files.</p> <p>For the <code>constant</code> and <code>linear</code> data sets, load is applied by deploying the "OpenTelemetry demo application", and sending automated user requests to the application. For the <code>direct</code> dataset, this application is not used and instead Kubernetes pods are created that apply a constant load to the cluster.</p> <p>The timestamps of the experiments are as follows:</p> <table> <tbody> <tr> <th>Run</th> <th>Iteration</th> <th>Start</th> <th>End</th> </tr> </tbody> <tbody> <tr> <td>Constant - 0 users</td> <td>1</td> <td>02-05-2024 10:08</td> <td>02-05-2024 10:52</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 13:20</td> <td>06-05-2024 13:58</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:20</td> <td>07-05-2024 09:54</td> </tr> <tr> <td>Constant - 50 users</td> <td>1</td> <td>02-05-2024 13:26</td> <td>02-05-2024 13:57</td> </tr> <tr> <td> </td> <td>2</td> <td>15-05-2024 14:06</td> <td>15-05-2024 14:38</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:56</td> <td>07-05-2024 10:39</td> </tr> <tr> <td>Constant - 100 users</td> <td>1</td> <td>02-05-2024 14:00</td> <td>02-05-2024 14:40</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 14:40</td> <td>06-05-2024 15:30</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 10:42</td> <td>07-05-2024 11:33</td> </tr> <tr> <td>Constant - 200 users</td> <td>1</td> <td>16-05-2024 09:37</td> <td>16-05-2024 10:09</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 15:32</td> <td>06-05-2024 16:13</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 11:34</td> <td>07-05-2024 12:11</td> </tr> <tr> <td>Constant - 400 users</td> <td>1</td> <td>02-05-2024 15:24</td> <td>02-05-2024 15:55</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 16:14</td> <td>06-05-2024 16:49</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 12:13</td> <td>07-05-2024 13:08</td> </tr> <tr> <td>Linear</td> <td>1</td> <td>22-05-2024 15:13</td> <td>22-05-2024 15:56</td> </tr> <tr> <td> </td> <td>2</td> <td>22-05-2024 16:05</td> <td>22-05-2024 16:48</td> </tr> <tr> <td> </td> <td>3</td> <td>23-05-2024 09:58</td> <td>23-05-2024 10:41</td> </tr> <tr> <td>Direct</td> <td>1</td> <td>2024-05-23 13:01:28</td> <td>2024-05-23 14:00:05</td> </tr> <tr> <td> </td> <td>2</td> <td>2024-05-23 14:33:23</td> <td>2024-05-23 15:32:01</td> </tr> <tr> <td> </td> <td>3</td> <td>2024-05-23 15:39:36</td> <td>2024-05-23 16:38:12</td> </tr> </tbody> </table> <p>A complete log of the experiments can be found in <code>experiments_log.txt</code>.</p> <h2>Constant</h2> <p>The constant data set contains the metrics for the system under a constant load. The load is generated by a Locust script that sends requests to the system. Data collection starts 1 minute after the desired number of concurrent users is reached and requests have stabilised. This experiment is performed for the following constant number of concurrent users:</p> <ul> <li>0 users</li> <li>50 users</li> <li>100 users</li> <li>200 users</li> <li>400 users</li> </ul> <p>Note that the <code>0 users</code> data does not contain the <code>report_*.html</code> and <code>request_*.csv</code> files, as these are generated by Locust and Locust is not run for the <code>0 users</code> scenario.</p> <p>Furthermore, note that Horizontal Pod Autoscaling is <em>not</em> enabled for this data set.</p> <h2>Linear</h2> <p>The linear dataset contains the metrics for the system under a linearly scaling load. The load is generated through Locust. It starts at 0 users, and scales up to 100 users at a rate of 1 user per 20 seconds. After the load reaches 100 users, another 10 minutes of data is recorded. Every dataset is 45 minutes long, with 1.7 minutes of no load, 33.3 minutes of scaling up, and 10 minutes of max load.</p> <p>Note that Horizontal Pod Autoscaling <em>is</em> enabled for this data set.</p> <h2>Direct</h2> <p>The direct data set compliments the linear dataset. While the linear dataset provides a realistic load with things like networking factors being taken into account, the linear dataset can bottleneck on things like networking and the request client, so CPU usage is not maxed out. The direct dataset scales up linearly by applying direct CPU load to the Kubernetes pods without any application simulating a real usecase. The dataset works by deploying Kubernetes pods that max out immediately on exactly 200mCPU of load. The experiment starts with 1 pod, and 2 pods are added every 90 seconds up till 77 pods (the maximum number of pods the cluster allows to be scheduled). The first 1.5 minutes is no load, then 57 minutes to scale up, and then another 1.5 minutes at max load.</p> <p>Note that the <code>direct</code> data set does not contain the <code>app_*.json</code> files, as this data set does not deploy an application and therefore no application specific metrics are collected. Instead, a <code>script_log.txt</code> is provided that explains when and how the direct load was scaled up.</p> <h1>Files</h1> <p>A table for each file in the data set can be found below, including the unit of the metric and a description of what data is collected in that file. The format of all JSON files is the API response format used by Prometheus. More information on this topic can be found here: <a title="https://prometheus.io/docs/prometheus/latest/querying/api/" href="https://prometheus.io/docs/prometheus/latest/querying/api/">https://prometheus.io/docs/prometheus/latest/querying/api/</a>. All timestamps are in the CEST timezone.</p> <table> <tbody> <tr> <th>Filename</th> <th>Unit</th> <th>Description</th> </tr> </tbody> <tbody> <tr> <td>app_ads_ad_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the ad microservice</td> </tr> <tr> <td>app_currency_counter_total.json</td> <td>Total Count</td> <td>Total currency that circulated through the system</td> </tr> <tr> <td>app_frontend_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the frontend service</td> </tr> <tr> <td>app_payment_transactions_total.json</td> <td>Total Count</td> <td>Total transactions made to the transaction microservice</td> </tr> <tr> <td>app_recommendations_counter_total.json</td> <td>Total Count</td> <td>Total recommendations made by the recommendation microservice</td> </tr> <tr> <td>container_blkio_device_usage_total.json</td> <td>Total Bytes</td> <td>Total bytes used by blkio devices for pods</td> </tr> <tr> <td>container_cpu_usage_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative cpu time consumed by the pod</td> </tr> <tr> <td>container_cpu_user_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative user cpu time consumed by the pod</td> </tr> <tr> <td>container_fs_reads_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes read by the pod</td> </tr> <tr> <td>container_fs_writes_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes written by the pod</td> </tr> <tr> <td>container_memory_rss.json</td> <td>Bytes</td> <td>Resident Set Size of the pod</td> </tr> <tr> <td>kepler_container_bpf_cpu_time_ms_total.json</td> <td>Milliseconds</td> <td>CPU time for the pod as measured through a Kepler BPF program</td> </tr> <tr> <td>kepler_container_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores used by a pod</td> </tr> <tr> <td>kepler_container_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM used by a pod</td> </tr> <tr> <td>kepler_container_joules_total.json</td> <td>Total Joules</td> <td>Aggregated total energy consumption of a pod</td> </tr> <tr> <td>kepler_container_package_joules_total.json</td> <td>Total Joules</td> <td>Cumulative energy consumed by all cores and uncore components of a pod</td> </tr> <tr> <td>kepler_node_core_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of core_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_dram_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of dram_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_package_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of package_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>node_cpu_scaling_frequency_hertz.json</td> <td>Hertz</td> <td>Current scaled cpu thread frequency of a machine (BM or VM)</td> </tr> <tr> <td>node_cpu_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds the CPU worked on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_read_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent reading disk on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_write_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent writing disk on a machine (BM or VM)</td> </tr> <tr> <td>node_hwmon_temp_celsius.json</td> <td>Celsius</td> <td>Temperature of the machine (BM) as reported by its monitoring hardware</td> </tr> <tr> <td>node_load1.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 1 minute</td> </tr> <tr> <td>node_load5.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 5 minutes</td> </tr> <tr> <td>node_load15.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 15 minutes</td> </tr> <tr> <td>node_memory_Active_bytes.json</td> <td>Bytes</td> <td>Active number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_memory_Committed_AS_bytes.json</td> <td>Bytes</td> <td>Committed number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_rapl_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_package_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine package, estimated by RAPL</td> </tr> <tr> <td>node_rapl_psys_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine psys, estimated by RAPL</td> </tr> <tr> <td>power_consumption.json</td> <td>Watt</td> <td>Energy consumption as measured by the physical power plugs</td> </tr> <tr> <td>report_*.html</td> <td>-</td> <td>HTML report describing details of locust actions during the experiment</td> </tr> <tr> <td>requests_*.csv</td> <td>-</td> <td>Request summary per endpoint generated by locust</td> </tr> <tr> <td>scaph_host_power_microwatts.json</td> <td>Microwatt</td> <td>Power consumption of the whole machine as estimated by Scaphandre</td> </tr> <tr> <td>scaph_process_cpu_usage_percentage.json</td> <td>Percentage</td> <td>Per-process CPU usage as a percentage of total machine CPU</td> </tr> <tr> <td>scaph_process_memory_bytes.json</td> <td>Bytes</td> <td>Per-process memory usage</td> </tr> <tr> <td>scaph_process_power_consumption_microwatts.json</td> <td>Microwatt</td> <td>Per-process energy consumption as estimated by Scaphandre</td> </tr> <tr> <td>script.log</td> <td>-</td> <td>Log for the direct experiments for scaling up the pods</td> </tr> </tbody> </table> <h1>Scripts</h1> <div> <div>All scripts used to query this data from the prometheus endpoint and to generate the results in the associated paper are included in the scripts directory. To run a script, the script must be placed in the same directory as the data it is operated on (e.g. /scripts/constant/power_estimation.ipynb has to be in /constant).</div> </div>

opencc-by-4.0Sep 2024View details →

Data for "Thermal Desorption Kinetics, Binding Energies, and Entrapment of Methyl Mercaptan Ices"

<p>This data includes infrared and mass spectra for thermal desorption experiments of methyl mercaptan and methanol ices. There are also Gaussian 16 log files that were used for complementary analysis of the data (i.e. single/dimer molecule optimization+frequency and harmonic/anharmonic band strength calculations) using the M062X/cc-pVDZ or M062X/cc-pVQZ or B3LYP/cc-pVDZ levels of theory. </p>

opencc-by-4.0Jun 2024View details →

China's gridded fugitive energy methane emissions over 2011-2020

Open the record for dataset details and reuse information.