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.
478
datasets available to search
ShareScore release 0.9.0
Dataset results
478 results for “artifact”
Research data, sources and documents for thesis on Exploring Complexity Metrics for Artifact-Centric Business Process Models
<p>Research data, sources and documents for thesis on Exploring Complexity Metrics for Artifact-Centric Business Process Models This repository contains the supplemental material for the <a href="https://pqdtopen.proquest.com/pubnum/10759956.html">thesis "Exploring Complexity Metrics for Artifact-Centric Business Process Models" by Marin, Mike A., Ph.D., University of South Africa (South Africa), 2017.</a></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>
Doctoral Thesis Artifact "User-Centered Tool Design for Data-Flow Analysis"
<p>This artifact contains the evaluation data and source code accompanying the doctoral thesis "User-Centered Tool Design for Data-Flow Analysis" by Lisa Nguyen Quang Do. The artifact contains (1) the survey questions and anonymized answers of the surveys conducted during the thesis, (2) the user study questionnaires, results, and test applications of the user studies conducted for the thesis, (3) the source code of the research prototypes and video demonstrations of their interfaces, and (4) the benchmark suites used for the empirical evaluation of those prototypes.</p>
[Artifact] Qubit Allocation as a Combination of Subgraph Isomorphism and Token Swapping
<p>Object-Oriented Programming, Systems, Languages & Applications (OOPSLA'19) artifact for the paper: "Qubit Allocation as a Combination of Subgraph Isomorphism and Token Swapping".</p>
Casting about in the Dark - Artifact Evaluation
<p>Companion dataset artifact used in the paper "Casting about in the Dark".</p> <p>This version incorporates some additional minor changes to the artifact, related to the additionally sampled cast instances. This version is the one used in the final version of the paper.</p> <p>---</p> <p>Abstract:</p> <p>The main goal of a static type system is to prevent certain kinds of errors from happening at run time. A type system is formulated as a set of constraints that gives any expression or term in a program a well-defined type. Yet mainstream programming languages are endowed with type systems that provide the means to circumvent their constraints through <em>casting</em>.</p> <p>We want to understand how and when developers escape the static type system to use dynamic typing. We empirically study how casting is used by developers in more than seven thousand Java projects. We find that casts are widely used (8.7% of methods contain at least one cast) and that 50% of casts we inspected are not guarded locally to ensure against potential run-time errors.</p> <p>To help us better categorize use cases and thus understand how casts are used in practice, we identify 25 cast-usage patterns, recurrent programming idioms using casts to solve a specific issue. This knowledge can be: (a) a recommendation for current and future language designers to make informed decisions (b) a reference for tool builders, <em>e.g.</em>,<br> by providing more precise or new refactoring analyses, (c) a guide for researchers to test new language features, or to carry out controlled programming experiments, and (d) a guide for developers for better practices.</p>
Figures 2-3. 2 in First report of Rhantus validus Sharp (Coleoptera: Dytiscidae) as necrophage and generator of postmortem artifacts in a human corpse found in an artificial freshwater pond from the Región de La Araucanía, Chile
Figures 2-3. 2. Adult of Rhantus validus Sharp. Dorsal and ventral view. Scale bar: 10 mm. 3. Two Rhantus validus adults (indicate with red arrows) associated to a postmortem artifact in left ear.
Figure 4 in First report of Rhantus validus Sharp (Coleoptera: Dytiscidae) as necrophage and generator of postmortem artifacts in a human corpse found in an artificial freshwater pond from the Región de La Araucanía, Chile
Figure 4. Two Rhantus validus adults (indicate with red arrows) associated to a postmortem artifact in upper chest.
Dataset Artifact for paper "Root Cause Analysis for Microservice System based on Causal Inference: How Far Are We?"
<p>Artifacts for the paper titled <strong><em>Root Cause Analysis for Microservice System based on Causal Inference: How Far Are We?</em></strong>.</p> <p>This artifact repository contains 9 compressed folders, as follows: </p> <table> <tbody> <tr> <td><strong>ID</strong></td> <td><strong>File Name</strong></td> <td><strong>Description</strong></td> </tr> <tr> <td>1</td> <td>syn_circa.zip</td> <td>CIRCA10, and CIRCA50 datasets for Causal Discovery</td> </tr> <tr> <td>2</td> <td>syn_rcd.zip</td> <td>RCD10, and RCD50 datasets for Causal Discovery</td> </tr> <tr> <td>3</td> <td>syn_causil.zip</td> <td>CausIL10, and CausIL50 datasets for Causal Discovery</td> </tr> <tr> <td>4</td> <td>rca_circa.zip</td> <td>CIRCA10, and CIRCA50 datasets for RCA</td> </tr> <tr> <td>5</td> <td>rca_rcd.zip</td> <td>RCD10, and RCD50 datasets for RCA</td> </tr> <tr> <td>6</td> <td>online-boutique.zip</td> <td>Online Boutique dataset for RCA</td> </tr> <tr> <td>7</td> <td>sock-shop-1.zip</td> <td>Sock Shop 1 dataset for RCA</td> </tr> <tr> <td>8</td> <td>sock-shop-2.zip</td> <td>Sock Shop 2 dataset for RCA</td> </tr> <tr> <td>9</td> <td>train-ticket.zip</td> <td>Train Ticket dataset for RCA</td> </tr> </tbody> </table> <p>Each zip file contains the generated/collected data from the corresponding data generator or microservice benchmark systems (e.g., online-boutique.zip contains metrics data collected from the Online Boutique system). </p> <p><strong>Details about the generation of our datasets</strong></p> <p><em>1. Synthetic datasets</em></p> <p>We use three different synthetic data generators from three previous RCA studies [15, 25, 28] to create the synthetic datasets: CIRCA, RCD, and CausIL data generators. Their mechanisms are as follows:<br><br>1. CIRCA datagenerator [28] generates a random causal directed acyclic graph (DAG) based on a given number of nodes and edges. <span>From this DAG, time series data for each node is generated using a </span><span>vector auto-regression (VAR) model. A fault is injected into a node </span><span>by altering the noise term in the VAR model for two timestamps. <br></span><span><br>2. RCD data generator [25] uses the pyAgrum package [3] to generate </span><span>a random DAG based on a given number of nodes, subsequently </span><span>generating discrete time series data for each node, with values ranging from 0 to 5. A fault is introduced into a node by changing its </span><span>conditional probability distribution.<br><br>3. CausIL data generator [15] generates causal graphs and time series data that simulate </span><span>the behavior of microservice systems. It first constructs a DAG of </span><span>services and metrics based on domain knowledge, then generates </span><span>metric data for each node of the DAG using regressors trained on </span><span>real metrics data. Unlike the CIRCA and RCD data generators, the </span><span>CausIL data generator does not have the capability to inject faults.<br><br></span>To create our synthetic datasets, we first generate 10 DAGs whose nodes range from 10 to 50 for each of the synthetic data generators. Next, we generate fault-free datasets using these DAGs with different seedings, resulting in 100 cases for the CIRCA and RCD generators and 10 cases for the CausIL generator. We then create faulty datasets by introducing ten faults into each DAG and generating the corresponding faulty data, yielding 100 cases for the CIRCA and RCD data generators. The fault-free datasets (e.g. `syn_rcd`, `syn_circa`) are used to evaluate causal discovery methods, while the faulty datasets (e.g. `rca_rcd`, `rca_circa`) are used to assess RCA methods. </p> <p><em>2. Data collected from benchmark microservice systems </em></p> <p>We deploy three popular benchmark microservice systems: Sock Shop [6], Online Boutique [4], and Train Ticket [8], on a four-node Kubernetes cluster hosted by AWS. Next, we use the Istio service mesh [2] with Prometheus [5] and cAdvisor [1] to monitor and collect resource-level and service-level metrics of all services, as in previous works [ 25 , 39, 59 ]. To generate traffic, we use the load generators provided by these systems and customise them to explore all services with 100 to 200 users concurrently. We then introduce five common faults (CPU hog, memory leak, disk IO stress, network delay, and packet loss) into five different services within each system. Finally, we collect metrics data before and after the fault injection operation. An overview of our setup is presented in the Figure below.</p> <p></p> <p><strong>Code</strong></p> <p>The code to reproduce the experimental results in the paper is available at <a href="https://github.com/phamquiluan/RCAEval">https://github.com/phamquiluan/RCAEval</a>.</p> <p><strong>References</strong></p> <p>As in our paper.</p>
Understanding API Usage and Testing: An Empricial Study of C Libraries (Artifact)
<h1>LibProbe Artifact</h1> <p>For the sake of the evaluation we preprocessed the CCScanner data to identify all clients of the libraries used in our evaluation and included those in our <code>MongoDB</code> database. This artifact will start by importing this pre-processed dependency information into a docker image which is then used for the evaluation.</p> <h2>Running the docker image</h2> <ul> <li> <p>First load the docker image by running</p> <ul> <li> <div> <div><code>gunzip -c libprobe_v2.2.tar.gz | sudo docker import - libprobe:latest </code></div> </div> </li> </ul> <p>this will load the image in your local docker images.</p> </li> <li> <p>Run a container from the image: <code>sudo docker run -it --device /dev/snd --privileged libprobe:latest /bin/bash</code> This will run a docker container which maps the pulseaudio and alsa configurations from your local host to the docker image. This is necessary to get some clients for some target libraries to build correctly. You will need an ubuntu host machine which has pulseaudio and alsa installed.</p> </li> <li>Run <code>mongod --fork --logpath /var/log/mongodb/mongod.log</code> followed by <code>mongorestore --drop --db apiusage /tmp/libprobe/database/apiusage</code> to import the results saved in the artifact. </li> </ul> <h2>Validating analysis results</h2> <ul> <li>The docker image provided does not contain any clients due to size limitations on sharing. The Mongo database contains all the results of running this evaluation.</li> <li>We provide a script <code>clone_clients.py</code> with a <code>client_repos.json </code>file in <code>/tmp/libprobe/extra</code> which can be used to clone the clients in the clients directory. </li> <li>To get the results it's possible to run <code>python3 libprobe.py analyse all -n</code> from <code>/tmp/libprobe</code>. This will overwrite the JSON files in the <code>json_files</code> directory and overwrite the graphs in the <code>graphs</code> directory.</li> </ul> <h2>Running the evaluation for one library (vorbis)</h2> <ul> <li>Download clients: Go to <code>/tmp/libprobe</code> and run <code>python3 libprobe.py download vorbis</code></li> <li>Prepare the library: <ul> <li>In /tmp/data/libraries/xiph@@vorbis run make clean then make and make check and make install.</li> <li>Copy all C files from /tmp/data/libraries/xiph@@vorbis/lib to /tmp/data/libraries/xiph@@vorbis/lib/.libs to collect accurate API coverage information.</li> </ul> </li> <li>Process the library to get the APIs and the coverage information : <code>python3 libprobe.py processlib vorbis</code></li> <li>Prepare clients for excluding sub directories that might contain vorbis library code: <code>python3 libprobe.py prepclients vorbis</code></li> <li>Get client usages: <code>python3 libprobe.py fetchusages vorbis</code></li> <li>Analyse: <code>python3 libprobe.py analyse vorbis -n</code></li> <li>(optional) Measure differential coverage for improved coverage libs: <code>python3 libprobe.py coverage vorbis</code></li> </ul> <h2>Running the evaluation for all libraries (this requires at least 300GB of disk space)</h2> <ul> <li>Download clients: Go to <code>\tmp\libprobe</code> and run <code>python3 libprobe.py download all</code></li> <li>Process the libraries: <code>python3 libprobe.py processlib all</code></li> <li>Prepare clients: <code>python3 libprobe.py prepclients all</code></li> <li>Get usages: <code>python3 libprobe.py fetchusages all</code></li> <li>Analyse: <code>python3 libprobe.py analyse all -n</code></li> <li>(optional) Measure differential coverage for improved coverage libs: <code>python3 libprobe.py coverage <library></code></li> </ul> <h2>Getting baseline coverage for libraries</h2> <p>All libraries are cloned in <code>/tmp/data/libraries</code> and clients are cloned in <code>/tmp/data/clients</code>.</p> <div> </div> <ul> <li>MBedtls: Copy the script <code>coverage_mbedtls.sh</code> from <code>/tmp/libprobe/extra</code> into the the build directory of Mbedtls <code>/tmp/data/libraries/Mbed-TLS@@mbedtls/build</code> and run <code>./coverage_mbedtls.sh</code> followed by <code>genhtml baseline.info --output-directory</code> out this will calculate the baseline coverage for mbedtls.</li> <li>FFTW: Copy the script coverage.sh from /tmp/libprobe/extra into the the root dir of FFTW and run ./coverage.sh baseline this will calculate the baseline coverage for fftw</li> <li>HDF5: Copy the script coverage_hdf.sh from /tmp/libprobe/extra into the the root dir of HDF and run <code>./coverage_hdf.sh baseline</code> this will calculate the baseline coverage for HDF.</li> <li>LMDB: Copy the script coverage_lmdb.sh from /tmp/libprobe/extra into the <code>/tmp/data/libraries/LMDB@@lmdb/libraries/liblmdb</code> and run <code>./coverage_lmdb.sh baseline</code> this will calculate the baseline coverage for LMDB.</li> <li>Zip: Copy the script coverage_zip.sh from /tmp/libprobe/extra into <code>/tmp/data/libraries/kuba--@@zip/build/CMakeFiles/zip.dir/sr</code>c and run <code>./coverage_zip.sh baseline</code> this will calculate the baseline coverage for zip.</li> <li>Vorbis: Copy the script cal_cov.py from /tmp/libprobe/extra to <code>/tmp/data/libraries/xiph@@vorbis/lib/.libs</code> and then copy all source files in the <code>.libs</code> folder by running <code>cp ../*.c .</code> from the <code>.libs</code> folder. Finally run <code>python3 cal_cov.py .</code>.</li> <li>XXhash: Copy the script coverage.sh from /tmp/libprobe/extra into /tmp/data/libraries/Cyan4973@@xxHash and run ./coverage.sh baseline this will calculate the baseline coverage for xxhash</li> </ul> <h2>Reproducing increased coverage using clients</h2> <ul> <li> <p>LMDB: The client we will use is Knot DNS.</p> <ul> <li>Change directory to <code>/tmp/data/clients/CZ-NIC@@knot</code> and run <code>autogen.sh</code>.</li> <li>Run <code>./configure --with-lmdb=/usr/local</code>.</li> <li>Then <code>make && make check</code>.</li> </ul> <p>Now go back to the LMDB directory and run</p> <ul> <li> <p>Run <code>./coverage_lmdb.sh after_knot</code>.</p> </li> <li> <p>Now go /tmp/libprobe and run <code>python3 libprobe.py coverage lmdb</code></p> </li> </ul> </li> <li> <p>VORBIS: The client we will use in SFML.</p> <p>Go to the vorbis library dir <code>/tmp/data/libraries/xiph@@vorbis</code> and run <code>make clean</code>.</p> <ul> <li>Run <code>make && make check && make install</code>.</li> <li>Go to the <code>.libs</code> folder and copy all c files there by doing <code>cp ../*.c .</code>.</li> <li>Copy <code>/tmp/libprobe/extra/cal_cov.py</code> into the <code>.libs</code> folder and run <code>python3 cal_cov.py .</code>. This will show the baseline coverage.</li> </ul> <p>Go to the SFML directory <code>/tmp/data/clients/SFML@@SFML</code>.</p> <ul> <li>Create build directory <code>mkdir build && cd build</code>.</li> <li>Run <code>cmake -DSFML_BUILD_TEST_SUITE=TRUE -GNinja ..</code>.</li> <li>Run <code>ninja</code>.</li> <li>Run <code>ctest</code>. You will see some failing tests. Thats normal as we are only interested in the Audio tests for vorbis. All Audio tests should pass.</li> </ul> <p>Go back to the <code>.libs</code> folder in vorbis and re-run the <code>cal_cov.py</code> script.</p> <ul> <li>Now go /tmp/libprobe and run <code>python3 libprobe.py coverage vorbis</code></li> </ul> </li> </ul> <ul> <li>SDL: The client we will use in UFOAI.<br> <ul> <li> <p>Go to the SDL library dir <code>/tmp/data/libraries/libsdl-org\@\@SDL</code> and then the <code>build2</code> directory where the built library is. .</p> </li> <li>Run <code>make clean && make && make install && make test</code>.</li> <li>Copy <code>/tmp/libprobe/extra/coverage_sdl.sh</code> into the <code>build2</code> folder and run <code>./coverage_sdl.sh baseline</code>. Run <code>genhtml baseline.info --output-directory out</code></li> </ul> </li> </ul> <p> Go to the UFOAI directory <code>/tmp/data/clients/ufoaiorg\@\@ufoai</code></p> <ul> <li> <ul> <li>Run <code>./configure --target-os=linux --disable-uforadiant</code> && <code>make</code>.</li> <li>Run .<code>/testall</code></li> </ul> </li> </ul> <p> Now go /tmp/libprobe and run <code>python3 libprobe.py coverage sdl</code></p> <p> </p> <ul> <li>FFTW: The client we will use in CAVA.</li> </ul> <p> Go to the FFTW3 library dir <code>/tmp/data/libraries/FFTW@@fftw3</code> and run <code>reset_cov.sh</code> then <code>make clean</code></p> <ul> <li> <ul> <li>Run <code>make && make install && make check</code>.</li> <li>Copy <code>/tmp/libprobe/extra/coverage.sh</code> into root directory of the library and run the <code>.libs</code> folder and run <code>./coverage.sh baseline</code> This will show the baseline coverage.</li> </ul> </li> </ul> <p> Go to the CAVA directory <code>/tmp/data/clients/karlstav@@cava</code>.</p> <ul> <li> <ul> <li>Run <code>./autogen.sh</code> followed by <code>./configure</code> then <code>make</code></li> <li>Run the script <code>./run_all_tests.sh</code> . </li> </ul> </li> </ul> <p> Go back to the FFTW3 library and run <code>./coverage.sh after_cava</code></p> <ul> <li> <ul> <li>Now go /tmp/libprobe and run <code>python3 libprobe.py coverage fftw3</code></li> </ul> </li> </ul>
Companion data artifacts: Technical framework demonstration for deep learning-based wood species classification with advanced sub-μ-CT imaging
<p>This is the companion data artifact collection for the IWAWA paper manuscript by Jannik Stebani, Tim Lewandrowski, Kilian Dremel, Simon Zabler and Volker Haag.It is generally to be used with the visualization and prediction showcases implemented in the Binder notebooks launched from this <a href="https://github.com/stebix/woodnet-showcase" target="_blank" rel="noopener">woodnet-showcase</a> GitHub repository.</p> <p>The artifacts amount to the following:</p> <ol> <li><code>acer-artifact.hdf5</code> : Exemplary <code>(256, 256, 256)</code> subvolume from a <em>Acer pseudoplatanus</em> sub-μ-CT scan</li> <li><code>pinus-artifact.hdf5</code> : Exemplary <code>(256, 256, 256)</code> subvolume from a <em>Pinus sylvestris </em>sub-μ-CT scan</li> <li><code>weights-artifact.pth</code> : Exemplary PyTorch trained weights for a woodnet/deep neural network to demonstrate classification of the above samples</li> </ol>
Model Checking of Spacecraft Operational Designs: A Scalability Analysis - Artifact
<p>This artifact contains the accompanying experiment data for the publication "Model Checking of Spacecraft Operational Designs: A Scalability Analysis".</p>
N Wahl - Digital Artifacts
<div> <div> <div> <div> <p><strong>Pizza in Italy</strong>: Savoring Italy: Authentic pizza, unforgettable flavours, and a taste of true Italian culture.</p> <p><strong>Lake View</strong>: Nature's Mirror: Peaceful reflections by the lake, where time seems to stand still.</p> <p><strong>Car</strong>: On the Road: Every drive is an adventure, fueled by freedom and the open road.</p> </div> </div> </div> </div> <div> <div> <div> </div> </div> </div>
Intermediary artifact from GT method
<p>File with the record of the texts considered relevant for the research, such as sustainability aspects, concepts, terms related to sustainable SE and promising elements on the subject as taxonomies and propositions extrated from GT method.</p>
Examples of ancient Near Eastern artifacts imaged and visualized with PLD system
<p><strong>From top to bottom: a coin, a cylinder seal impression, impressions on the bottom of a funerary cone, and a cuneiform tablet. For each artifact four visualizations were generated with the PLD MLR viewer. From left to right: coloor, shaded, automated sketch, normal map. References for the objects: Greek silver coin: o.i. 522 (©️ KU Leuven Art Collection); Modern impression Old Akkadian cylinder seal: O.861 (©️ Art & History Museum, Brussels - RMAH); Old Egyptian funerary cone: E.3984 (©️ Art & History Museum, Brussels); Old Akkadian cuneiform tablet: O.95 (©️ Art & History Museum, Brussels).</strong></p>
Artifact for Paper ParaQooba: A Fast and Flexible Framework for Parallel and Distributed QBF Solving
<p>The artifact for the paper "ParaQooba: A Fast and Flexible Framework for Parallel and Distributed QBF Solving" submitted to the <a href="https://tacas.info/artifacts-23.php">TACAS2023 artifact evaluation</a>.</p> <p>We thank the reviewers for their comments and added the missing dependencies to this revised version. No other parts have been changed.</p>
Artifact for "Identifying Concepts in Software Projects"
<p>This artifact complements the manuscript "Identifying Concepts in Software Projects". It contains all data necessary to independently verify our findings.</p>
Dataset Artifact for Prodigy: Towards Unsupervised Anomaly Detection in Production HPC Systems
<p>The dataset contains a small set of application runs from Eclipse supercomputer. The applications run with and without synthetic HPC performance anomalies. More detailed information regarding synthetic anomalies can be found at: https://github.com/peaclab/HPAS.</p> <p>We have chosen four applications, namely LAMMPS, sw4, sw4Lite, and ExaMiniMD, to encompass both real and proxy applications. We have executed each application five times on four compute nodes without introducing any anomalies. To showcase our experiment, we have specifically selected the "memleak" anomaly as it is one of the most commonly occurring types. Additionally, we have also executed each application five times with the chosen anomaly. The dataset we have collected consists of a total of 160 samples, with 80 samples labeled as anomalous and 80 samples labeled as healthy. For the details of applications please refer to the paper.</p> <p>The applications were run on Eclipse, which is situated at Sandia National Laboratories. Eclipse comprises 1488 compute nodes, each equipped with 128GB of memory and two sockets. Each socket contains 18 E5-2695 v4 CPU cores with 2-way hyperthreading, providing substantial computational power for scientific and engineering applications.</p>
Model-based analysis of sample index hopping reveals its widespread artifacts in multiplexed single-cell RNA-sequencing
<p>Supplementary data that are needed to rerun the reproducible notebooks from the first steps using Alevin output and configuration files.</p> <p>Intermediate R data object that can be used to rerun the reproducible notebooks after the filtering steps.</p> <p>Validation data for inferring the sample index hopping rate. The <em>hiseq4000_joined_datatable_plexed_nonplexed.zip file contains read counts for four samples (two non-multiplexed and two multiplexed) joined by a cell-barcode, UMI, and gene-ID (CUG) key combination. The hiseq4000_inner_joined_with_labels.zip file contains only those CUGs that are observed in both the non-multiplexed and multiplexed samples.</em><em> </em></p>
Fluorescence correlation spectroscopy TCSPC data with and without peak artifacts - PEX5 applied experiment
<p>This is a dataset of Fluorescence Correlation Spectroscopy (FCS) Time-Correlated Single Photon Counting (TCSPC) data with and without peak artifacts. The provenance of the data is recorded in <a href="https://github.com/aseltmann/fluotracify/blob/data/data/exp-220120-correlate-ptu/LabBook-exp-220120-correlate-ptu.org">this file</a> (see a rendered version <a href="https://aseltmann.github.io/fluotracify/data/LabBook-all.html#sec-2-5">here</a>). This parent project (<a href="https://github.com/aseltmann/fluotracify">https://github.com/aseltmann/fluotracify</a>) also contains examples of how to use these models and related Python code.</p> <p>The following connected paper is currently under review and should be cited together with these model versions: <em>Seltmann, A.; Carravilla, P.; Reglinski, K.; Eggeling, E.; Waithe, D. Neural Network Informed Photon Filtering Reduces Artifacts in Fluorescence Correlation Spectroscopy Data. 2023 (currently under review)</em></p> <p><strong>Note on the file formats and notation:</strong></p> <p>"Primary data" refers to the <code>.ptu</code> files, so the actual TCSPC data. "Secondary data" refers to the <code>.pqres</code> files, which are derived files by the proprietary PicoQuant software.</p> <p><strong>Note on sample preparation (from the Supplementary Note of the paper above):</strong></p> <p>The peak artifacts measurements were produced by 20 nM Trypanosoma brucei-PEX5 N-term fused to eGFP in solution, and the corresponding control measurements by 5 nM Homo sapiens-PEX5 N-term fused to eGFP in solution. The detailed sample preparation is described elsewhere. We prepared the samples on #1.5 coverslips mounted on Attofluor Cell Chambers (Thermo Fisher Scientific). We acquired the data on a MicroTime 200 microscope (PicoQuant) equipped with an Olympus UPlanSApo 60× 1.2NA water immersion objective lens and a HydraHarp 400 TCSPC module (PicoQuant). Excitation was achieved with a 488 nm pulsed laser (PicoQuant) with a power of 5 mW measured at the sample plane. We used a 20 nM solution of Alexa Fluor for calibrating the correction collar. One TCSPC measurement had a length of 20 s for PEX5 experiments.</p>
Fluorescence correlation spectroscopy TCSPC data with and without peak artifacts - AlexaFluor 488 applied experiment
<p>This is a dataset of Fluorescence Correlation Spectroscopy (FCS) Time-Correlated Single Photon Counting (TCSPC) data with and without peak artifacts. The provenance of the data is recorded in <a href="https://github.com/aseltmann/fluotracify/blob/data/data/exp-220120-correlate-ptu/LabBook-exp-220120-correlate-ptu.org">this file</a> (see a rendered version <a href="https://aseltmann.github.io/fluotracify/data/LabBook-all.html#sec-2-5">here</a>). This parent project (<a href="https://github.com/aseltmann/fluotracify">https://github.com/aseltmann/fluotracify</a>]) also contains examples of how to use these models and related Python code.</p> <p>The following connected paper is currently under review and should be cited together with these model versions: <em>Seltmann, A.; Carravilla, P.; Reglinski, K.; Eggeling, E.; Waithe, D. Neural Network Informed Photon Filtering Reduces Artifacts in Fluorescence Correlation Spectroscopy Data. 2023 (currently under review)</em></p> <p><strong>Note on the file formats and notation:</strong></p> <p>"Primary data" refers to the <code>.ptu</code> files, so the actual TCSPC data. "Secondary data" refers to the <code>.pqres</code> files, which are derived files by the proprietary PicoQuant software.</p> <p><strong>Note on sample preparation (from the Supplementary Note of the paper above):</strong></p> <p>The peak artifact measurements were produced by mixing 20 nM of the small dye Alexa Fluor 488 (Thermo Fisher Scientific) with 10 μM of slow, large (100 nm) unilamellar vesicles (LUVs) labelled with DiO in the membrane (0.1 % mol lipid:dye). The corresponding control measurements were 20 nM Alexa Fluor 488 in solution. We prepared the LUVs by the extrusion method: 1−palmitoyl−2−oleoyl−glycero−3−phosphocholine (POPC, Avanti Polar Lipids) was vacuum dried on a glass vial for 1 h and resuspended on phosphate buffered saline to form lipid vesicles. The vesicles were extruded 30 times through 100 nm pore size polycarbonate membranes using a Mini-Extruder (Avanti Polar Lipids). We prepared the samples on #1.5 coverslips mounted on Attofluor Cell Chambers (Thermo Fisher Scientific). We acquired the data on a MicroTime 200 microscope (PicoQuant) equipped with an Olympus UPlanSApo 60× 1.2NA water immersion objective lens and a HydraHarp 400 TCSPC module (PicoQuant). Excitation was achieved with a 488 nm pulsed laser (PicoQuant) with a power of 5 mW measured at the sample plane. We used a 20 nM solution of Alexa Fluor for calibrating the correction collar. One TCSPC measurement had a length of 10 s for AF488 experiments.</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.