Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
733
datasets available to search
ShareScore release 0.7.1
Dataset results
733 results for “Scheduling”
Performance results of different scheduling algorithms used in the simulation of a modern game engine
<p><strong>Performance results of different scheduling algorithms used in the simulation of a modern game engine</strong></p> <p>These results are a companion to the paper entitled "<em>Exploring scheduling algorithms for parallel task graphs: a modern game engine case study</em>" by M. Regragui et al.</p> <p><strong>General information</strong></p> <p>This dataset contains raw outputs and scripts to visualize and analyze the scheduling results from our game engine simulator.<br> The result analysis can be directly reproduced using the script run_analysis.sh. A series of Jupyter Notebook files are also available to help visualize the results.</p> <p><strong>File information</strong></p> <p>- All Scenario*.ipynb files contain python scripts to visualize and analyze the simulation results.<br> - The Scenario*.py files contain python scripts that can be run directly with Jupyter Notebook.<br> - The requirements.txt file contains the names and versions of python packages necessary to reproduce the analysis.<br> - The run_analysis.sh file contains a bash script to install the required python packages and run the Scenario*.py scripts.</p> <p>The results are organized in five folders:</p> <p>1. Result_1 contains the results for Scenario 1 generated using file input_scenario_1.txt.<br> 2. Result_2 contains the results for Scenario 2 generated using file input_scenario_2.txt.<br> 3. Result_3 contains the results for Scenario 3 generated using file input_scenario_3.txt.<br> 4. Result_CP_1 contains the results for the critical path of Scenarios 1 and 2 generated using file input_CP_scenario_1.txt.<br> 5. Result_CP_3 contains the results for the critical path of Scenario 3 generated using file input_CP_scenario_3.txt.</p> <p>Each result file (e.g., HLF_NonSorted_Random_1_200_10.txt) contains 200 lines representing information of the 200 frames that were simulated. Each line contains four values: the frame number, the duration of the frame (in microseconds), a critical path estimation for the previous frame (in microseconds), and the load parameter (value between 0 and 1).</p> <p>The outputs of this analysis include some PDF files representing the figures in the paper (in order) and some CSV files representing the values shown in tables. The standard output shows the p-values computed in parts of the statistical analysis.</p> <p><strong>Software and hardware information</strong></p> <p>The simulation results were generated on an Intel Core i7-1185G7 processor, with 32 GB of LPDDR4 RAM (3200 MHz). The machine ran on Ubuntu 20.04.3 LTS (5.14.0-1034-oem), and g++ 9.4.0 was used for the simulator's compilation (-O3 flag).</p> <p>The results were analyzed using Python 3.8.10, pip 20.0.2 and jupyter-notebook 6.0.3. The following packages and their respective versions were used:</p> <p>- pandas 1.3.2<br> - numpy 1.21.2<br> - matplotlib 3.4.3<br> - seaborn 0.11.2<br> - scipy 1.7.1<br> - pytz 2019.3<br> - python-dateutil 2.7.3<br> - kiwisolver 1.3.2 <br> - pyparsing 2.4.7 <br> - cycler 0.10.0 <br> - Pillow 7.0.0<br> - six 1.14.0 </p> <p><strong>Simulation information</strong></p> <p>Simulation results were generated from 4 to 20 resources. Each configuration was run with 50 different RNG seeds (1 up to 50).</p> <p>Each simulation is composed of 200 frames. The load parameter (lag) starts at zero and increases by 0.01 with each frame up to a value equal to 100% in frame 101. After that, the load parameter starts to decrease in the same rhythm down to 0.01 in frame 200.</p> <p><strong>Algorithms abbreviation in presentation order</strong></p> <p>FIFO serves as the baseline for comparisons.</p> <p>1. FIFO: First In First Out.<br> 2. LPT: Longest Processing Time First.<br> 3. SPT: Shortest Processing Time First.<br> 4. SLPT: LPT at a subtask level.<br> 5. SSPT: SPT at a subtask level.<br> 6. HRRN: Highest Response Ratio Next. <br> 7. WT: Longest Waiting Time First.<br> 8. HLF: Hu's Level First with unitary processing time of each task.<br> 9. HLFET: HLF with estimated times.<br> 10. CG: Coffman-Graham's Algorithm.<br> 11. DCP: Dynamic Critical Path Priority.</p> <p><strong>Metrics</strong></p> <p>* SF: slowest frame (maximum frame execution time)<br> * DF: number of delayed frames (with 16.667 ms as the due date)<br> * CS: cumulative slowdown (with 16.667 ms as the due date)<br> </p>
Intersection Vehicular Traffic Flow Scheduling Datasets
<p><strong>Background</strong></p> <p>Vehicular traffic congestion remains a major problem in most modern cities of the world. Therefore, efforts to minimize these congestions and their accompanying effects continuously receive much attention from researchers, traffic engineers, policymakers, etc.</p> <p>One important element required in the efforts of traffic engineering for the minimization of traffic congestion is data. Data influence the modeling and deployment of traffic scheduling systems. Most importantly, the objectives of modeling and deploying the traffic scheduling system influence the nature of the data to be used.</p> <p><strong>Aim</strong></p> <p>The aim of this study was to generate and provide a dataset that may be used in the training of computationally intelligent systems having basic objects of minimizing waiting time, travel time, etc. at various intersections (isolated intersections or roundabouts).</p> <p><strong>Methodology</strong></p> <p>The dataset (<strong><em>.csv</em></strong>) consisted of waiting time (W), queue length (Q), and phase duration (P). The waiting time is the time duration vehicles have waited at an intersection/roundabout before being scheduled to utilize the intersection/roundabout. The queue length refers to the number of vehicles (vehicular count) waiting at an intersection/roundabout. Phase duration is the time period a given vehicular flow (lane) is assigned the green wave to utilize the intersection/roundabout. The dataset was obtained through repeated training, testing, and modification of phase duration and the Adaptive Neuro-Fuzzy Inference System (ANFIS) model.</p> <p>The dataset considered bounded conditions on the three parameters (W, Q, P). The W and Q were bounded between zero and ninety – [0, 90] and the P is [13, 50]. That is, when W and Q are greater than or equal to the upper bound, the upper bound is used. Every flow may be assigned a minimum P of 13s and a maximum of 50s. The P-bounds assumed that the lower bound is large enough for vehicles on the assigned traffic flow to move to the safe region of the intersection before the scheduling system switches assignment to another traffic flow. </p> <p><strong>Conclusion</strong></p> <p>The dataset may be used as a benchmark dataset for the improvement of traffic flow controllers as well as other datasets.</p>
Instances of parallel related machine scheduling problem with jobs release dates and deadlines
<p>The following dataset contains randomly generated problem instances for the related machine scheduling problem with job's release dates and due dates.<br> There are 4 instance classes each of which contains 10 random instances (i.e., 10 text files) with n=120 jobs and m=26 machines. The instance classes differ one from another in the expected relative width of job's time windows.</p> <p>The text file structure is as follows:<br> n=<number of jobs>;<br> m=<number of machines>;<br> p_{ij}=<br> <n*m matrix: each entry in j-th column and i-th row corresponds to the processing time of job j on machine i>;<br> r_j=<br> <vector with n elements: the j-th element corresponds to the release date of job j>;<br> d_j=<br> <vector with n elements: the j-th element corresponds to the due date of job j>;</p> <p>The jobs are sorted by release date in ascending order.</p>
[opendc-sc18-dataset] A Reference Architecture for Datacenter Scheduling: Data Artifacts
<p>This release contains the data artifacts of the paper A Reference Architecture for Datacenter Scheduling presented at <a href="https://sc18.supercomputing.org/">Supercomputing 2018</a></p> <p>For the paper, experiments have been run on the following traces:</p> <ul> <li><strong>Askalon (W-Eng)</strong> - <code>askalon_workload_ee</code></li> <li><strong>Chronos (W-Ind)</strong> - <code>chronos_exp_noscaler_ca</code></li> </ul> <p>Each of the directories for the traces have the following structure:</p> <ul> <li><strong>/setup.txt</strong><br> This text file describes the trace used for the experiment in addition to the amount of times the experiment was repeated and the amount of warm-up experiments.</li> <li><strong>/setup.json</strong><br> This JSON file describes the topology of the datacenter used in the experiments. Each item represents the identifiers of the resource (here, CPU type) to use in the machine. The available CPU types are (1) Intel i7 (4 cores, 4100 MHz) and (2) Intel i5 (2 cores, 3500 MHz).</li> <li><strong>/trace</strong><br> This directory contains the trace used in the simulation. The trace is stored in the Grid Workload Format. See the <a href="http://gwa.ewi.tudelft.nl/">Grid Workload Archive</a> for more information.</li> <li><strong>/data/experiments.csv</strong><br> A CSV file containing information of all simulations that have been run on the OpenDC platform for this experiment.</li> <li><strong>/data/job_metrics.csv</strong><br> A CSV file containing metrics (NSL, JMS, etc.) for each job that ran during the simulations.</li> <li><strong>/data/stage_measurements.csv</strong><br> A CSV file containing timing measurements for the scheduling stages that ran during the simulations.</li> <li><strong>/data/task_metrics.csv</strong><br> A CSV file containing metrics for each task that ran during the simulations.</li> <li> <p><strong>/data/tasks.csv</strong><br> A CSV file containing information about the tasks (submit time, runtime, etc.) that ran during the simulations as extracted from the traces.</p> <p>Additionally, we describe the format of each data file in the associated metadata file.</p> </li> </ul> <p><strong>Hardware</strong></p> <p>The hardware used for running the experiments is a MacBook Pro with a 2,9 GHz Intel Core i7 processor and 16 GB 2133 MHz LPDDR3 internal memory.</p> <p><strong>Reproduction</strong></p> <p>This section describes the instructions for reproducing the paper results using a provided Docker image. Please make sure you have <a href="https://www.docker.com/">Docker</a> installed and running.</p> <p>For reproduction, you will run the following experiments:</p> <ul> <li><code>askalon_workload_ee</code><br> This is the large experiment of the paper and will take approximately 4 hours to complete similar hardware.</li> <li><code>chronos_exp_noscaler_ca</code><br> This is the smaller experiment of the paper and will take approximately 5 minutes to complete on similar hardware.</li> </ul> <p>The Docker image <a href="https://hub.docker.com/r/atlargeresearch/sc18-experiment-runner/"><code>atlargeresearch/sc18-experiment-runner</code></a> can be used for running the experiments. A volume can be attached to the directory <code>/home/gradle/simulator/data</code> to capture the results of the experiments.</p> <p>Make sure you have, in your current working directory, the following files:</p> <ul> <li><strong>/setup.json</strong><br> This JSON file describes the topology of the datacenter and can be found in this archive at <code>askalon_workload_ee/setup.json</code>.</li> <li><strong>/askalon_workload_ee.gwf</strong><br> This file contains the trace for the Askalon workload. This file can be found in the archive at <code>askalon_workload_ee/trace/askalon_workload_ee.gwf</code>.</li> <li><strong>/chronos_exp_noscaler_ca.gwf</strong><br> This file contains the trace for the Chronos workload. This file can be found in the archive at <code>chronos_exp_noscaler_ca/trace/chronos_exp_noscaler_ca.gwf</code>.</li> </ul> <p>Then, you can start the Askalon experiments as follows:</p> <pre><code>$ docker run -it --rm -v $(pwd):/home/gradle/simulator/data atlargeresearch/sc18-experiment-runner -r 32 -w 4 -s data/setup.json data/askalon_workload_ee.gwf </code></pre> <p>The experiment runner can be configured with the following options</p> <ul> <li><strong>-r</strong>, <strong>--repeat</strong><br> The amount of times to repeat an experiment for each scheduler.</li> <li><strong>-w</strong>, <strong>--warm-up</strong><br> The amount of times to warm-up the simulator for each scheduler.</li> <li><strong>-p</strong>, <strong>--parallelism</strong><br> The number of experiments to run in parallel.</li> <li><strong>--schedulers</strong><br> The list of schedulers to test, separated by spaces. The following schedulers are available: <code>SRTF-BESTFIT</code>, <code>SRTF-FIRSTFIT</code>, <code>SRTF-WORSTFIT</code>, <code>FIFO-BESTFIT</code>, <code>FIFO-FIRSTFIT</code>, <code>FIFO-WORSTFIT</code>, <code>RANDOM-BESTFIT</code>, <code>RANDOM-FIRSTFIT</code>, <code>RANDOM-WORSTFIT</code>.</li> </ul> <p>After the Askalon experiments have been finished, you can start the Chronos experiments. <strong>Make sure</strong> you have a copy of the result files in your directory as the result files will be overwritten.</p> <pre><code>$ docker run -it --rm -v $(pwd):/home/gradle/simulator/data atlargeresearch/sc18-experiment-runner -r 32 -w 4 -s data/setup.json data/chronos_exp_noscaler_ca.gwf </code></pre>
Task Scheduler Performance Survey Results
<p><strong>Task scheduler performance survey</strong></p> <p>This dataset contains results of task graph scheduler performance survey.<br> The results are stored in the following files, which correspond to simulations performed on <br> the `elementary`, `irw` and `pegasus` task graph datasets published at https://doi.org/10.5281/zenodo.2630384.</p> <ul> <li>elementary-result.zip</li> <li>irw-result.zip</li> <li>pegasus-result.zip</li> </ul> <p>The files contain compressed pandas dataframes in CSV format, it can be read with the following Python code:<br> ```python<br> import pandas as pd<br> frame = pd.read_csv("elementary-result.zip")<br> ```</p> <p>Each row in the frame corresponds to a single instance of a task graph that<br> was simulated with a specific configuration (network model, scheduler etc.).<br> The list below summarizes the meaning of the individual columns.</p> <ul> <li><strong>graph_name</strong> - name of the benchmarked task graph</li> <li><strong>graph_set</strong> - name of the task graph dataset from which the graph originates</li> <li><strong>graph_id</strong> - unique ID of the graph</li> <li><strong>cluster_name</strong> - type of cluster used in this instance the format is <number-of-workers>x<number-of-cores>; 32x16 means 32 workers, each with 16 cores</li> <li><strong>bandwidth</strong> - network bandwidth [MiB]</li> <li><strong>netmodel</strong> - network model (simple or maxmin)</li> <li><strong>scheduler_name</strong> - name of the scheduler</li> <li><strong>imode</strong> - information mode</li> <li><strong>min_sched_interval</strong> - minimal scheduling delay [s]</li> <li><strong>sched_time</strong> - duration of each scheduler invocation [s]</li> <li><strong>time</strong> - simulated makespan of the task graph execution [s]</li> <li><strong>execution_time </strong>- real duration of all scheduler invocations [s]</li> <li><strong>total_transfer</strong> - amount of data transferred amongst workers [MiB]</li> </ul> <p>The file `charts.zip` contains charts obtained by processing the datasets.<br> On the X axis there is always bandwidth in [MiB/s].<br> There are the following files:</p> <ul> <li>[DATASET]-schedulers-time - Absolute makespan produced by schedulers [seconds] </li> <li>[DATASET]-schedulers-score - The same as above but normalized with respect to the best schedule (shortest makespan) for the given configuration.</li> <li>[DATASET]-schedulers-transfer - Sums of transfers between all workers for a given configuration [MiB]</li> <li>[DATASET]-[CLUSTER]-netmodel-time - Comparison of netmodels, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-netmodel-score - Comparison of netmodels, normalized to the average of model "simple"</li> <li>[DATASET]-[CLUSTER]-netmodel-transfer - Comparison of netmodels, sum of transfered data between all workers [MiB]</li> <li>[DATASET]-[CLUSTER]-schedtime-time - Comparison of MSD, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-schedtime-score - Comparison of MSD, normalized to the average of "MSD=0.0" case</li> <li>[DATASET]-[CLUSTER]-imode-time - Comparison of Imodes, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-imode-score - Comparison of Imodes, normalized to the average of "exact" imode</li> </ul> <p><strong>Reproducing the results</strong></p> <p><em>1. Download and install Estee (https://github.com/It4innovations/estee)</em></p> <p>$ git clone https://github.com/It4innovations/estee<br> $ cd estee<br> $ pip install .<br> <br> <em>2. Generate task graphs</em><br> You can either use the provided script `benchmarks/generate.py` to generate graphs<br> from three categories (elementary, irw and pegasus):</p> <p>$ cd benchmarks<br> $ python generate.py elementary.zip elementary<br> $ python generate.py irw.zip irw<br> $ python generate.py pegasus.zip pegasus<br> <br> or use our task graph dataset that is provided at https://doi.org/10.5281/zenodo.2630384.</p> <p><em>3. Run benchmarks</em><br> To run a benchmark suite, you should prepare a JSON file describing the benchmark.<br> The file that was used to run experiments from the paper is provided in<br> `benchmark.json`. Then you can run the benchmark using this command:<br> <br> $ python pbs.py compute benchmark.json</p> <p>The benchmark script can be interrupted at any time (for example using Ctrl+C).<br> When interrupted, it will store the computed results to the result file and restore<br> the computation when launched again.</p> <p><em>3. Visualizing results</em><br> <br> $ python view.py --all <result-file><br> <br> The resulting plots will appear in a folder called `outputs`.</p>
Task graphs for benchmarking schedulers
<p><strong>Workflow Task Graph Dataset</strong></p> <p>This dataset contains three sets of task graphs representing different types of task workflows:</p> <ul> <li><em>Elementary</em> - contains trivial graph shapes, such as tasks with no dependencies or simple fork-join graphs. This set should test how the scheduler heuristics react to basic graph scenarios that frequently form parts of larger workflows.</li> <li><em>IRW</em> - is inspired by real-world workflows, such as machine learning cross-validation or map-reduce.</li> <li> <em>Pegasus</em> - is derived from graphs created by Pegasus Synthetic Workflow Generators (https://github.com/pegasus-isi/WorkflowGenerator)</li> </ul> <p>All of the provided task graphs are generated and compatible with ESTEE (https://github.com/It4innovations/estee) that allows to simulate their execution on a distributed system using various scheduling heuristics and environment conditions.</p> <p><strong>Data Format</strong></p> <p>Task graphs are stored in {elementary, irw, pegasus}.zip files that contain JSON representation of respective task graphs with the following fields:</p> <ul> <li>`graph_name` - Task graph name</li> <li>`graph_id` - Unique task graph identifier</li> <li> `graph` - Task graph representation - list of tasks where each task is represented as a dictionary with the following keys:</li> <li> `d`: Actual task duration in seconds (float value)</li> <li> `e_d`: User estimated task duration in seconds (float value)</li> <li> `cpus`: Task CPU core requirements (integer value)</li> <li> `outputs`: List of task outputs (list of integers indicating sizes of task outputs in MiB)</li> <li> `inputs`: List of task inputs in format of list [task\_id, output\_index]}. Output index is zero-based.</li> </ul> <p>For example this task graph:</p> <p>[{'d': 200, 'e_d': 180, 'cpus': 1, 'outputs': [100], 'inputs': []},</p> <p>{'d': 50, 'e_d': 60, 'cpus': 2, 'outputs': [], 'inputs': [[0, 0]]}]</p> <p>contains two tasks. One requiring no input, single CPU core with estimated duration 180s, actual duration 200s and producing a single output of 100 MiB. And another one requiring as an input task0's 0-th output, requiring 2 CPU cores, producing no output with estimated duration 60s and actual duration 50s.</p> <p> </p> <p><strong>Parsing the data</strong></p> <p>In Python, to load the elementary task graph set run the following snippet:</p> <pre><code class="language-python">import pandas as pd graphs = pd.read_json("./elementary.zip")</code></pre> <p> </p> <p>If you have Estee installed, you can use its provided `json_deserialize`</p> <p>function to parse the JSON encoded graphs into Estee TaskGraph data structure.</p> <p> </p> <pre><code class="language-python">from estee.serialization.dask_json import json_deserialize graph_json = graphs.loc[0, "graph"] graph = json_deserialize(graph)</code></pre> <p> </p>
Fig. 9. T. thermophila cells immunostained with monoclonal anti-cdc14A in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 9. T. thermophila cells immunostained with monoclonal anti-cdc14A antibody. Cs and nCS – apical couplets of basal bodies for proter and opisthe, respectively; Ma – macronucleus. Other explanations as in Figs 1 and 8. Bar: 10 µm, bar in D for B–D.
Fig. 7. T. thermophila cells immunostained with the antiserum against component B in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 7. T. thermophila cells immunostained with the antiserum against component B of epiplasm. DF – staining around the deep fibers. Other explanations as in Fig. 1. Bar: 10 µm.
Fig. 2 in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 2. Localization of nuclei in control and roscovitine treated T. tetrmophila. The cells were immunostained with the anti-centrin 20H5 antibody and stained with DAPI. A and B – control cells in the VI stage of morphogenesis, and early cytokinesis, respectively; C and D – roscovitine treated cells (4 h) in the VI stage of morphogenesis and in cytokinesis respectively. Arrows – micronuclei (in the C micronucleus in opisthe is out of focus). Bar: 10 µm.
Fig. 4. Postdivider cells after 5.5 h in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 4. Postdivider cells after 5.5 h of roscovitine treatment. Cells were immunostained with anti-centrin 20H5 antibody. A and A' – ventral and dorsal views of the same proter cell with remnants of the OA2; B–C opisthe cells, B – opisthe with ARF on dorsal side, C – opisthe with remnants of oral structures; D and D' – ventral and dorsal views of the same cell; E and E' – ventral and dorsal views of the same opisthe during pinching off the OA. Other explanations as in Fig. 1. Bar: 10 µm for A–E'.
Fig. 5 in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 5. Mean cell sizes, positions of OA1, OA2 and fission zone in control and in roscovitine treated cells. Upper panel: early and late control dividers, lower panel: early dividers after 3.5 h roscovitine treatment, late dividers after 3.5 and 5.5 h roscovitine treatment. The shape of cells is represented by elipses. Solid horizontal lines – cells "equator", dotted horizontal lines – positions of the fission furrow. All sizes and distances were drawn to the same scale. Bar: 10 µm. The measurements represent means of at least 10 specimens for each cell sample.
Fig. 6 in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 6. Correlation of length of proters and shift of the fission zone in relation to OA2 induced by roscovitine in late dividers. The shift of the fission zone was measured as a difference between length of the proters and distance from cell apex to the anterior end of the OA2 (ordinate). Each point in this diagram represent individual cell. Open symbols – untreated cells, close symbols – cells treated with roscovitine for 3.5 and 5.5 h (pooled).
Fig. 10 in Effects of Roscovitine on Schedule of Divisional Morphogenesis, Basal Bodies Proliferation and Cell Divisions in Tetrahymena thermophila
Fig. 10. Western blot of T. thermophila fractions with monoclonal antibody anti-cdc14A. H – homogenate, S – supernatant, C – cortical fraction (pellet).
Data, scripts, and plots for the paper "A Comparative Study of OpenMP Scheduling Algorithm Selection Strategies"
<p>Data, scripts, and plots for the paper "A Comparative Study of OpenMP Scheduling Algorithm Selection Strategies"</p>
Benchmark instances and models for the Oven Scheduling Problem
<p>This dataset contains benchmark instances for the Oven Scheduling Problem that was introduced by the authors in Lackner, M.-L., Mrkvicka, C., Musliu, N., Walkiewicz, D., Winter, F., <em>Minimizing Cumulative Batch Processing Time for an Industrial Oven Scheduling Problem</em>. In: 27th International Conference on Principles and Practice of Constraint Programming (CP 2021). Moreover, MiniZinc models and CP Optimizer models as well as the solutions found for the benchmark set are provided.</p>
Instance data for "Scheduling Trucks on Factory Premises"
<p>Instance data for the paper</p> <ul> <li>Wirth, M., & Emde, S. (2018). Scheduling trucks on factory premises. <em>Computers & Industrial Engineering</em>, <em>126</em>, 175-186.</li> </ul> <p>Every instance is in a separate text file, of which there are 54 in total (18 small, medium, and large instances, respectively). The data format is as follows.</p> <p><num> is the running index of the instance.</p> <p><NumTrucks> is the total number of trucks (jobs).</p> <p><NumDoors> is the total number of dock doors (machines) on the factory premises.</p> <p><MaxDoors> denotes the maximum number of doors to be visited per truck.</p> <p><FactoryLength> denotes the size of the factory premises in meters (used to calculate the distances).</p> <p><Distribution> is the type of probability distribution used for generating the processing and transfer times.</p> <p><Processing> is a binary matrix signalling if a truck requires processing at a door: if and only if the entry in line i and column j is 1, truck j requires processing at door i.</p> <p><ProcessingTime> is the processing time matrix: the entry in line i and column j is the processing time of truck j at door i.</p> <p><DoorDistance> is the distance matrix between doors. The entrance / exit dummy door is the first line / column.</p> <p><ReleaseDate> is the release date vector for the trucks.</p> <p><DueDate> are the due dates of the trucks.</p> <p><Cost> are the weights in the objective for each truck.</p>
Data from: Dinosaurian survivorship schedules revisited: new insights from an age-structured population model
<p>Little is known on dinosaur population biology due to insufficient information on age-dependent fecundities and mortalities. So far, survivorship curves (hereafter SC) of only six dinosaurs (four tyrannosaurs, one ceratopsian, one hadrosaur) were erected from bone assemblages of aged specimens. They indicate high survival throughout most of their life with presumable higher mortalities after hatching and increasing mortalities towards its end. However, all studies ignored that assemblages must preserve stationary age distributions (i.e., the population's age distribution is stable and its size is constant over time as overall population fecundities match mortalities, hereafter SAD population) to infer a reliable SC for a taxon.</p> <p>To assess SCs of these dinosaurs, I built a simple population model with age-dependent fecundities and survival rates. Its few input parameters are maximum longevity, age at sexual maturation and maximum annual offspring number, on which information exists in these dinosaurs. As bone histological studies and scaling relationships provide estimates on its three parameters, my model is also applicable to other extinct taxa.</p> <p> Modelling suggests that bone assemblages did not preserve SAD populations. SCs determined for SAD populations of <i>Albertosaurus sarcophagus</i>,<i> Gorgosaurus libratus</i>, <i>Dasplatosaurus torosus</i> and <i>Tyrannosaurus rex</i> indicated that low mortalities follow high mortalities early in their life or that mortalities were rather constant throughout their life. In <i>Psittacosaurus lujiatuensis</i> modelling suggests low mortalities throughout most of its life that increase towards its end. The SC of <i>Maiasaura peeblesorum</i> was not questioned by my model as it is unable to capture sigmoidal or other composite SCs.</p>
Solutions and Solution Costs for "Exact and Meta-Heuristic Approaches for Unrelated Parallel Machine Scheduling"
<p>This record contains the solutions and solution costs described in the journal paper "<a href="https://doi.org/10.1007/s10951-021-00714-6">Exact and metaheuristic approaches for unrelated parallel machine scheduling</a>".</p> <p> </p> <p><strong>Content</strong></p> <p>The ZIP archives contain the actual solution files (.soln) for each of the solver runs per instance.<br> Additionally, information files (.soln.info) are provided which contain a bit of extra information for the corresponding solution file.</p> <p>The Excel sheets (.xlsx) contain the calculated solution costs as either Tardiness / Makespan pair, or as weighted sum as described in the paper.</p> <p> </p> <p><strong>Format of the Solution Files</strong></p> <p>The solution files start with a line containing the header <strong>[Schedules]</strong>.<br> After this follows a CSV-style description of the schedules (with semicolon as separator) – the first column denotes the machine ID, while all following entries denote the job IDs, in order of their schedule on the corresponding machine.</p> <p> </p> <p><strong>Example</strong></p> <p>[Schedules]<br> 0;1;5;3<br> 1;4;2<br> <br> This solution means that jobs 1, 5, and 3 are scheduled to run in this order on machine 0.<br> Similarly, machine 1 runs jobs 4 and 2 in this order.</p>
Dataset for A MILP approach for detailed operational scheduling of a supply chain in the phosphate industry
<p>10 instances to evaluate a MILP approach for detailed operational scheduling of a supply chain in the phosphate industry.</p>
Traces for studying Datacenter Scheduler Programming Abstractions
<p>Traces for the experiments for the research work that investigates the performance impact of various datacenter scheduler programming abstractions.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.