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.
26
datasets available to search
ShareScore release 0.9.0
Dataset results
26 results for “Fault localization”
Evaluating data-flow coverage in spectrum-based fault localization
<p>This release contains files with the results of the experiment comparing the use of data- and control-flow spectra for Spectrum-based Fault Localization. It also has instructions to run Jaguar to perform experiments. The subject programs used in the experiment are public available in our GitHub repository.</p>
Measurement Dataset of Thermal Fault Emulation of a 46Ah High-Power Kokam Nano Pouch Cell via Uniform and Local Heating
<h1>Preface</h1> <p>This dataset contains experimental data that supplement the article <em>Thermal fault detection by changes in electrical behaviour in lithium-ion cells </em>(<a href="https://doi.org/10.1016/j.jpowsour.2021.229572" target="_blank" rel="noopener">10.1016/j.jpowsour.2021.229572</a>) in the Journal of Power Sources. This dataset extends the already published cell characteristics (see <a href="https://doi.org/10.17632/g443f7cn7p.2" target="_blank" rel="noopener">10.17632/g443f7cn7p.2</a>) by all measured quantities associated with the conducted study. Therefore, the dataset includes sensor readings that have not been described in the before mentioned documents due to space limitations. <em><br></em></p> <p>The published data belongs to the master thesis <em>Development of a model-based method for the early detection of safety-critical heating of lithium-ion cells (transl.), Klink</em> <em>(2020), TU Clausthal</em> that is connected to a study thankfully funded by the European Automobile Manufacturers' Association (ACEA).</p> <h1>Structure</h1> <p>The repository is subdivided in four directories (.zip) based on the content. Within these directories, the individual datasets can be found. While every dataset contains three different file types, the corresponding files can be identified based on the identical filenames. The following file types are provided:</p> <table> <tbody> <tr> <td><strong>File type</strong></td> <td><strong>Content</strong></td> <td><strong>Comment</strong></td> </tr> <tr> <td>*.png</td> <td>Simple graph of the provided data.</td> <td>Missing values are interpolated.</td> </tr> <tr> <td>*.csv</td> <td>Tabular data of the dataset.</td> <td>Columns are separated by ";", the decimal point is ".".</td> </tr> <tr> <td>*.pickle</td> <td>Pickled object of a <a href="https://pandas.pydata.org/docs/index.html" target="_blank" rel="noopener">pandas</a> dataframe (Python) of the data. Preserve index and data types.</td> <td>Pickled with pandas version 2.2.2 using the pickle protocol 5</td> </tr> </tbody> </table> <p>The index and column names of the tabular time series have the following name scheme: X_Y_Z </p> <table> <tbody> <tr> <td><strong>Placeholder</strong></td> <td><strong>Description</strong></td> <td><strong>Example</strong></td> </tr> <tr> <td>X</td> <td>Quantity symbol</td> <td>U for voltage, I for current</td> </tr> <tr> <td>Y</td> <td>[optional] Additional index</td> <td><em>meas </em>for measured quantities</td> </tr> <tr> <td>Z</td> <td>Unit</td> <td>s for seconds, V for volt</td> </tr> </tbody> </table> <h1>Content</h1> <p>The dataset contains the data of both experiments for validation and for investigation of the fault characteristics of the conducted thermal abuse test. While the electrical quantities have been recorded using a battery test stand from Keysight/Scienlab (SL60/200/12BT4C) the temperature readings have been measured by type K thermocouples and recorded with data logger from PCE instruments. For all tests, the temperature sample rate has been set to 1 Hz. Please refer to the attached schematics in <em>SensorPositions.zip</em> for the placement of the individual thermocouples. In addition, T_5 represents the surrounding and T_2 is on the backside of T_1. The sensor positions T_7 and T_8 are added only for the uniform heating where T_7 is located between heating element and cell and T_8 central at the heating plate. Within the referenced article, only T_1 has been used. </p> <p>For details on the experimental setup, please refer to the method section of the linked article. </p> <h2>1. Validation</h2> <table> <tbody> <tr> <td><strong>Description</strong></td> <td> </td> <td>The data contains the electrical load of the cell with an extended WLTC driving cycle that has been scaled to approx. 400 A as well as the corresponding temperature at T_1. The test was conducted within a climatic chamber at 20°C. This data can be used to either parameterize a model of the cell or to validate a model based on other parameter such as the linked parameter set.</td> </tr> <tr> <td><strong>Columns</strong></td> <td>t_s</td> <td>Test time in seconds</td> </tr> <tr> <td> </td> <td>I_meas_A</td> <td>Applied current for WLTC emulation</td> </tr> <tr> <td> </td> <td>U_meas_V</td> <td>Voltage response of cell</td> </tr> <tr> <td> </td> <td>T_meas_C</td> <td>Cell surface temperature</td> </tr> </tbody> </table> <h2>2. ThermalCalibration</h2> <table> <tbody> <tr> <td><strong>Description</strong></td> <td> </td> <td>For each heating setup (uniform, local) this directory contains one data set. Within this experiment, the cell was pulsed with short high current (150 A) pulses to achieve a constant thermal heating power without changing the SOC. Based on the temperature response, a thermal model can be parameterized for both heating setups. Please note, that the electrical sample rate was higher and no interpolation was conducted. </td> </tr> <tr> <td><strong>Columns</strong></td> <td>t_s</td> <td>Test time in seconds</td> </tr> <tr> <td> </td> <td>I_meas_A</td> <td>Applied current</td> </tr> <tr> <td> </td> <td>U_meas_V</td> <td>Voltage response of cell</td> </tr> <tr> <td> </td> <td>T_?_C</td> <td>Temperature reading of sensor ?. See above for description of the individual sensor positions. </td> </tr> </tbody> </table> <h2>3. UniformThermalFault</h2> <table> <tbody> <tr> <td><strong>Description</strong></td> <td> </td> <td>During cycling the cell with a continuous WLTC cycle, the thermal fault was induced by activation of the heating element. After multiple cycles, the cell went into thermal runaway during a charging procedure. Please note, that in the end, the test was disrupted multiple times due to problems induced by the high temperatures. Temperature readings of 9999°C (Upper range) due to sensor failure have been replaced by NaN. Since the heating is started delayed into the second WLTC cycle, the first cycle can be used as reference for normal operation.</td> </tr> <tr> <td><strong>Columns</strong></td> <td>t_s</td> <td>Test time in seconds</td> </tr> <tr> <td> </td> <td>I_meas_A</td> <td>Applied current</td> </tr> <tr> <td> </td> <td>U_meas_V</td> <td>Voltage response of cell</td> </tr> <tr> <td> </td> <td>T_?_C</td> <td>Temperature reading of sensor ?. See above for description of the individual sensor positions. </td> </tr> </tbody> </table> <h2>4. LocalThermalFault</h2> <table> <tbody> <tr> <td><strong>Description</strong></td> <td> </td> <td> <p>During cycling the cell with a continuous WLTC cycle, the thermal fault was induced by activation of the heating element. After multiple cycles, a charging process and observation, no thermal runaway occurred. Please note, that in the end, the test was disrupted multiple times due to problems induced by the high temperatures. It seems that the heat transfer into the cell could have been optimized, as shown by the relatively low cell temperature despite the hot heating element. Nevertheless, this experiment can be used to investigate online detection of small cell changes due to local heating - even without thermal runaway. Since the heating is started delayed into the second WLTC cycle, the first cycle can be used as reference for normal operation.</p> </td> </tr> <tr> <td><strong>Columns</strong></td> <td>t_s</td> <td>Test time in seconds</td> </tr> <tr> <td> </td> <td>I_meas_A</td> <td>Applied current</td> </tr> <tr> <td> </td> <td>U_meas_V</td> <td>Voltage response of cell</td> </tr> <tr> <td> </td> <td>T_?_C</td> <td>Temperature reading of sensor ?. See above for description of the individual sensor positions. </td> </tr> </tbody> </table>
Supplementary Data for Progressive Strain Localization with Structural Evolution of Faults and Implications for Earthquake Characteristics
<p>Fault slip measurements from geodetic imaging data (pixel offsets and InSAR) for 16 strike-slip earthquakes. </p> <p>Data columns are: Longitude, Latitude, Fault Slip (meters), 1-sigma uncertainty (meters)</p>
Text-fig. 1. Ohře rift fault zone with location of our localities (adapted Rapprich et al. 2007). a – Vrbice, b – Nechranice, c – Bečov, d – Divoká rokle. in New Fossil Woods From The Paleogene Of Doupovské Hory And České Středohoří Mts. (Bohemian Massif, Czech Republic)
Text-fig. 1. Ohře rift fault zone with location of our localities (adapted Rapprich et al. 2007). a – Vrbice, b – Nechranice, c – Bečov, d – Divoká rokle.
Strain localization in sandstone-derived fault gouges under conditions relevant to earthquake nucleation
<p>Constraining strain localization and the growth of shear fabrics within brittle fault zones at sub-seismic slip rates are important for understanding fault strength and frictional stability. We conducted direct shear experiments on simulated sandstone-derived fault gouges at an effective normal stress of 40 MPa, pore fluid pressure of 15 MPa, and temperature of 100°C. Using a passive strain marker and X-ray Computed Tomography (XCT), we analyzed the spatial deformation of the gouge samples obtained from the strain-hardening stage to strain-softening stage to steady-state at shearing velocities of 1, 30, and 1000 µm/s. We developed a machine-learning-based automatic boundary detection method to recognize the shear zone fabrics and quantify the slip partitioning between each fabric element. Our results show that R1 and Y (or boundary) shears are the two major shear zone fabrics. At velocities of 1 and 30 µm/s, the relative amount of slip on R1 shears is displacement dependent and increases to ~20% at the strain-softening stage and then decreases to ~10–18% at steady-state. This trend is absent at high velocity with an amount of ~18% through all investigated stages. At all velocities, the relative amount of slip on Y and boundary shears increases linearly with displacement to a total of more than 50% at steady-state. Our study provides constraints for the development of the active slip zone, which is an important input parameter for the heat budget for small-magnitude earthquakes with limited slip (mm-dm), such as those occurring in induced seismicity.</p>
The effect of shear strain and shear localization on fault healing
<p>This is the ReadMe file corresponding to the study entitled:<br> "The effect of shear strain and shear localization on fault healing"<br> By Noël C., Giorgetti C., Collettini C. and Marone C.</p> <p>This Read-Me file has been last edited in August 2023</p> <p>This readme file describes the data repository and supplementary files accompanying the above publication. <br> For any further queries please contact corentin.noel@geoazur.unice.fr</p>
Strain localization in sandstone-derived fault gouges under conditions relevant to earthquake nucleation
Open the record for dataset details and reuse information.
Supplementary Data for Study on Strain Localization of Strike-Slip Fault Systems
<p>Point displacement measurements of fault slip from geodetic imaging and field surveying used to estimate off-fault deformation. </p>
Input and Output Data for local earthquake tomography in the central Dead Sea Fault using PyVoroTomo
<p>Data to reproduce wave velocity models for the central DSF.</p> <p>eventsAndArrivals.h5 - 2 csv files (keys: events, arrivals)</p> <p>stations_sub.h5 - csv file containing station data</p> <p>gitter.csv - 1D velocity model by Gitterman et al. (2002)</p> <p>3d_Vp_Vs_VpVs_models.nc - velocity models for vp, vs, and vp/vs and their uncertainty.</p> <p>relocated seismicity.h5 - relocated seismicity, arrivals used, and stations used (keys: events, arrivals, stations)</p>
Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems
<p>These are the datasets for our ESEC/FSE'22 paper "Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems." In each dataset, <code>graph.yml </code>or <code>graphs/*.yml</code> are FDGs, <code>metrics.csv</code> is metrics, and <code>faults.csv</code> is failures (including ground truths).<code>FDG.pkl</code> is a pickle of the FDG object, which contains all the above data. Note that the pickle files are not compatible in different Python and Pandas versions. So if you cannot load the pickles, just ignore and delete them. They are only used to speed up data load.</p> <p>See more at https://github.com/NetManAIOps/DejaVu</p>
Comparing developer-provided to user-provided tests for fault localization and automated program repair: Artifacts
<p>Artifacts for the paper <em>Comparing developer-provided to user-provided tests for fault localization and automated program repair.</em></p> <p>Note that the artifacts are maintained in the following repositories:</p> <ul> <li>https://github.com/rjust/defects4j</li> <li>https://bitbucket.org/rjust/tests-tested-data</li> <li>https://bitbucket.org/rjust/fault-localization-data</li> </ul>
Data in support of : Volumetric Deformation Feedback on Fault Stability and Strain Localization Precursor to Stick-Slip Behavior in Laboratory Earthquakes.
<p>This folder contains 3 .txt files:</p> <p> </p> <p>LP1 — low pressure data set.</p> <p>HP1 — High confining pressure experiement.</p> <p>HP2 — High cinfining pressure repeat experiment.</p> <p> </p> <p>The .txt files contain the following columns: Time (s), Pc (bar), VerticalLoad (kN), Horizontalload (kN), DisplacementOE (mm), StrainSG_xx, StrainSG_yy, StrainSG_xy.</p> <p>Strain gauge data are pre-filtered. All other data are raw.</p>
Supplementary material for 'The MAP metric in Information Retrieval Fault Localization'
<pre># map_bench4bl This is the supplementary material, data, and evaluation source code for the paper "The MAP metric in Information Retrieval Fault Localization" by Thomas Hirsch and Birgit Hofer. ## Preliminaries ### Python environment - Python 3.8 - pandas - numpy - matplotlib ## Datasets The [Bench4BL](<em>https://github.com/exatoa/Bench4BL</em>) dataset has been used in this evaluation, with the addition of intermediate files taken from the [SABL](<em>http://dx.doi.org/10.5281/zenodo.4681242</em>) experiment performed on this Bench4BL dataset. All data used in our evaluation is included in this repository. However, if the data is to be re-imported directly from these benchmark and datasets they have to be downloaded first and their local paths have to be set in [paths.py](<em>paths.py</em>). ### Bench4BL The Bench4BL dataset was published with the paper "Bench4BL: Reproducibility study on the performance of IR-based bug localization" by Lee, J., Kim, D., Bissyandé, T.F., Jung, W. and Le Traon, Y.. The dataset can be obtained [here](<em>https://github.com/exatoa/Bench4BL</em>). Follow the steps described in the corresponding [README](<em>https://github.com/exatoa/Bench4BL/blob/master/README.md</em>) to set up the dataset. The Bench4BL dataset contains the _old subjects_ subdataset, containing 558 bugs from AspectJ, JDT, PDE, SWT, and ZXing that have been widely used in older IRFL studies. This _old subjects_ subdataset was used in answering our RQ1, as discussed below, the corresponding scripts use _old subjects_ in their name to highlight this. #### SABL The SABL dataset is the online appendix of the paper "An Extensive Study of Smell-Aware Bug Localization" by TTakahashi, A., Sae-Lim, N., Hayashi, S. and Saeki, M.. The dataset can be downloaded [here](<em>http://dx.doi.org/10.5281/zenodo.4681242</em>). The experiments in this dataset build on top of Bench4BL and intermediate files are provided in the datapackage. #### Rankings Rankings for BLIA, BRTracer, and BugLocator were produced by running these tools on Bench4BL locally. Rankings for AmaLgam and BLUiR were taken from the SABL experiment dataset. ## Structure ### Folders Bench4BL ground truths: - bench4bl_old_subjects_summary - bench4bl_summary Localization results of the included tools in Bench4BL: - bench4bl_localization_results - bench4bl_localization_results_sabl Target projects size metrics: - cloc_results - cloc_results_old_subjects Utility functions: - utils Output folders containing results, generated figures and tables: - results - results_old_subjects ### Scripts Scripts for re-importing data from Bench4BL and SABL datasets: - data_preparation_step_1_cloc_bench4bl.py - data_preparation_step_1_cloc_old_subjects_bench4bl.py - data_preparation_step_2_import_ground_truth_from_bench4bl.py - data_preparation_step_2_import_ground_truth_from_old_subjects_bench4bl.py - data_preparation_step_3_import_bench4bl_ranking_results.py - data_preparation_step_3_import_sabl_ranking_results.py Utilities: - paths.py - utils/bench4bl_utils.py - utils/Logger.py ### Evaluation scripts for the corresponding research questions: **Dataset analysis:** - rq_0_dataset_analysis_bench4bl_issues.py **RQ1: How big is the average ground truth in Bench4BL datasets, and what proportion of bugs have a ground truth containing multiple files?** - rq_1_bench4bl_ground_truth_size.py - rq_1_old_subjects_bench4bl_ground_truth_size.py RQ2: Do the IRFL tools included in Bench4BL truncate their results? - rq_2_ranking_lengths.py **RQ3: How strong is $AP_{asrd}$ overestimating $AP_{mb}$ for truncated BugLocator retrieval results on the Bench4BL dataset? RQ3a: How strong is $AP_{asrd}$ overestimating $AP_{mb}$ for truncated BugLocator retrieval results when considering the bloated ground truth issue found in Bench4BL?** - rq_3_truncating_BugLocator_rankings_bench4bl.py **RQ3b: How strong is $AP_{asrd}$ overestimating $AP_{mb}$ for truncated BugLocator retrieval results when undefined $AP$ values are simply ignored?** - rq_3b_undefined_ap_BugLocator_rankings_bench4bl.py ## Licence All code and results are licensed under [CCA v4](<em>https://creativecommons.org/licenses/by/4.0/</em>), according to LICENSE file. Other licences may apply for some tools and datasets contained in this repo: [cloc-1.92.pl](<em>https://github.com/AlDanial/cloc</em>) under GPL v2, [Bench4BL](<em>https://github.com/exatoa/Bench4BL</em>) and [SABL](<em>http://dx.doi.org/10.5281/zenodo.4681242</em>) under CCA 4.0.</pre>
Online repository for Paper "AgentFL: Scaling LLM-based Fault Localization to Project-Level Context"
<h3>Summary</h3> <p>This is the online repository for the arXiv paper "AgentFL: Scaling LLM-based Fault Localization to Project-Level Context".</p> <p>We also provide the results for the TSE'25 paper "SOAPFL: A Standard Operating Procedure for LLM-based Method-Level Fault Localization".</p> <h3>Environment</h3> <ul> <li><a href="https://github.com/rjust/defects4j/tree/v1.4.0">Defects4J-V1.4.0</a> (Note that the buggy items in V1.4.0 is identical with V1.2.0, we use V1.4.0 to avoid some problems in V1.2.0)</li> <li><a href="https://github.com/rjust/defects4j/tree/v2.0.0">Defects4J-V2.0.0</a></li> <li>Python version >= 3.8.5</li> </ul> <h3>Defects4J Mod</h3> <p>Before running AgentFL, please apply the files under the <code>AgentFL/Defects4J_mod</code> directory to modify your Defects4J V1.4.0/V2.0.0.</p> <h3>Run AgentFL</h3> <p>Set your own OpenAI API key in <code>AgentFL/camel/model_backend.py</code></p> <p>It's easy to run AgentFL for localizing a bug with the following command:</p> <p><code>python3 run.py --config <CONFIG_DIR> --version <D4J_VERSION> --project <PROJECT> --bugID <BUG_ID> --model <GPT_MODEL_NAME></code></p> <p>For example:</p> <p><code>python3 run.py --config Default --version 1.4.0 --project Closure --bugID 26 --model GPT_3_5_TURBO</code></p> <p>More configs can be seen under the directory <code>AgentFL/Config</code></p> <h3>Results</h3> <p>We release all of the results of AgentFL in the <code>AgentFL/Results</code> directory, including the evaluation results on Defects4J V1.4.0/V2.0.0 and the ablation study result.</p> <p>For each bug, we record all of the prompts, responses, and intermediate outputs.</p> <blockquote> <p>NEW: We have released the newest results for TSE'25 paper "SOAPFL: A Standard Operating Procedure for LLM-based Method-Level Fault Localization". The results can be found in the `<a href="https://zenodo.org/api/records/16938304/draft/files/SoapFL_results.zip/content" target="_blank" rel="noopener noreferrer">SoapFL_results.zip</a>` file!</p> </blockquote> <h3>Human Evaluation Results</h3> <p>The human evaluation results can be found in the file <code>AgentFL/EvaluationResult/DebugResult_d4j140_GPT35_human.xlsx</code></p> <h3>System Messages for Agents</h3> <ul> <li>Test Code Reviewer:</li> </ul> <blockquote> <p>You are a Test Code Reviewer. We share a common interest in collaborating to successfully locate the buggy code that cause the test suite to fail. You can examine the test code and the initialized classes to analyze the similar behavior of the failed tests within the test suite. To locate the bug, you must write a response that appropriately solves the requested instruction based on your expertise.</p> </blockquote> <ul> <li>Source Code Reviewer</li> </ul> <blockquote> <p>You are a Source Code Reviewer. we are both working at DebugDev. We share a common interest in collaborating to successfully locate the buggy code that cause the test suite to fail. Your main responsibilities is to generate a comment for each covered method base on the method call relationship. To locate the bug, you must write a response that appropriately solves the requested instruction based on your expertise.</p> </blockquote> <ul> <li>Software Test Engineer</li> </ul> <blockquote> <p>You are a Software Test Engineer. We share a common interest in collaborating to successfully locate the buggy code that cause the test suite to fail. You main responsibilities include examining the information of the failed tests to analyze the possible causes of the test failures, and determining the method that need to be fixed. To locate the bug, you must write a response that appropriately solves the requested instruction based on your expertise.</p> </blockquote> <ul> <li>Software Architect</li> </ul> <blockquote> <p>You are a Software Architect. We share a common interest in collaborating to successfully locate the buggy code that cause the test suite to fail. You are very familiar with the architecture of the software, the functions of each class and method in the software. You main responsibilities include examining the given information to locate the possible buggy classes and buggy methods. To locate the bug, you must write a response that appropriately solves the requested instruction based on your expertise.</p> </blockquote>
Reproduction Package for Article `Fault Localization on Witnesses'
<h2>Fault Localization on Witnesses</h2> <h2>Article Abstract</h2> <p>When verifiers report an alarm, they export a violation witness (exchangeable counterexample)<br>that helps validate the reachability of that alarm.<br>Conventional wisdom says that this violation witness should be very precise:<br>the ideal witness describes a single error path for the validator to check.<br>But we claim that verifiers overshoot and produce large witnesses<br>with information that makes validation unnecessarily difficult.<br>To check our hypothesis, we reduce violation witnesses to that information<br>that automated fault-localization approaches deem relevant for triggering the reported alarm in the program.<br>We perform a large experimental evaluation on the witnesses<br>produced in the International Competition on Software Verification (SV-COMP 2023).<br>It shows that our reduction shrinks the witnesses considerably<br>and enables the confirmation of verification results that were not confirmable before.</p> <h2>VM</h2> <p>The username for the VM is `vagrant`.<br>The password for the VM is `vagrant`.</p> <h2>System Requirements</h2> <p>The artifact requires 4 CPU cores and 8 GB of RAM.</p> <p>To inspect the data, we require at least 150GB of empty disk space to run the VM.<br>To reproduce the results, we require 155GB.<br>To run the full reproduction, we require 300GB.</p> <p>The VM was tested on Ubuntu with Virtual Box Version 7.0.10 r158379 (Qt5.15.3).</p> <h2>Reproduction</h2> <p>Import the VM to VirtualBox and start it.<br>We provide symbolic links to the reproduction directory on the Desktop.<br>Please follow the instructions in the `ReadMe.md` inside the VM (located at `~/fault-localization-witnesses/ReadMe.md`).<br>The upcoming three subsections serve as a quick-start guide for our artifact.</p> <h3>Reproduce the Example</h3> <p>To reproduce the example in our paper, navigate to `~/fault-localization-witnesses` and execute `./example.sh`.</p> <h3>Reproduce the Plots</h3> <p>Execute `./reproduce.sh` from `~/fault-localization-witnesses/` to reproduce our experiments.</p>
Replication package for the paper: Harnessing Test Call Structures for Improved Fault Localization Effectiveness
<p>This repository contains the replication package for the paper <strong>"Harnessing Test Call Structures for Improved Fault Localization Effectiveness"</strong>. The package includes the necessary scripts, data, and instructions to reproduce the results presented in the study, focusing on the effectiveness of Spectrum-Based Fault Localization (SBFL) using the Barinel algorithm.</p> <h3>Description of Folders and Files:</h3> <ul> <li><strong>algorithms/</strong>: Contains the SBFL algorithms implemented for this study. Note that only the Barinel algorithm was used in the presented results.</li> <li><strong>base/</strong>: Contains the scripts needed for calculating spectra for SBFL.</li> <li><strong>D4J/</strong>: Contains the Defects4J projects. These need to be unpacked using the appropriate scripts provided in this folder.</li> <li><strong>changeset.json</strong>: Contains metadata about changesets for the projects analyzed in this study.</li> <li><strong>main.py</strong>: The main script for calculating ranks and metrics for the selected projects and heuristics.</li> <li><strong>SBFL ranks.csv</strong>: Contains the SBFL ranks calculated from the analysis.</li> </ul> <h2>Requirements</h2> <p>To run the scripts, you will need:</p> <ul> <li><strong>Python 3.9</strong></li> <li><strong>Defects4J</strong>: The <code>D4J</code> folder should contain unpacked Defects4J projects. Please ensure you have followed the instructions in the <code>D4J</code> folder to unpack the projects accordingly.</li> <li><strong>Required Python packages</strong> (install using <code><a href="http://localhost:63343/markdownPreview/1636345610/markdown-preview-index-2076127249.html?_ijt=mqjd55qrfb1m1q15g8bm74pk1u#"></a>pip</code>): <code><a href="http://localhost:63343/markdownPreview/1636345610/markdown-preview-index-2076127249.html?_ijt=mqjd55qrfb1m1q15g8bm74pk1u#"></a>pip install -r requirements.txt</code></li> <li><strong>Prepare the Defects4J Projects</strong>: <ul> <li>Navigate to the <code>D4J</code> directory.</li> <li>Run the provided scripts to unpack the necessary Defects4J projects.</li> <li>Ensure that each project folder is structured properly to be used by the <code>main.py</code> script.</li> </ul> </li> </ul> <h2>Running the Main Script</h2> <p>The main analysis script is <code>main.py</code>, which calculates the SBFL ranks using the Barinel algorithm based on the selected heuristics.</p> <h3>Usage</h3> <p>To run the main script:</p> <div></div> <pre><code><a href="http://localhost:63343/markdownPreview/1636345610/markdown-preview-index-2076127249.html?_ijt=mqjd55qrfb1m1q15g8bm74pk1u#"></a>python main.py </code></pre> <h3>Parameters and Settings:</h3> <ul> <li><strong>Projects and Ranges</strong>: The projects are defined in the <code>projects</code> list, with their respective bug ranges in the <code>ranges</code> list. The script iterates over these projects and bug IDs to calculate SBFL ranks.</li> </ul> <h3>Outputs:</h3> <ul> <li>The script outputs the ranks and coverage metrics directly to the console. Results can be redirected or saved as needed.</li> <li>It uses the <code>Ranks.RankContainer</code> class to calculate and print the minimum suspiciousness ranks for the selected metrics.</li> </ul>
Data for Using Contextual Knowledge in Interactive Fault Localization
<p>Data used for the experiments in the paper.</p>
Foreshock Activity Promoted by Locally Elevated Loading Rate on a 4-meter-long Laboratory Fault
<p>Experimental data and event catalog used for the study "Foreshock Activity Promoted by Locally Elevated Loading Rate on a 4-meter-long Laboratory Fault"</p>
Supplemental Material for Context Switch Sensitive Fault Localization
Open the record for dataset details and reuse information.
This repository serves as a replication package for the research paper titled "Typestate-based Fault Localization of API Usage Violations in a Deep Learning Program"
<h2>Overview</h2> <p>This repository serves as a replication package for the research paper titled "An Approach to Detecting Usage Protocol Violations in Deep Learning Programs."</p> <h2>Benchmarks</h2> <p>Two benchmarks were utilized in the research:</p> <ol> <li> <p>Benchmark1 from NeuraLint:</p> <ul> <li>Location: <code>NLBench/SOSamples</code></li> </ul> </li> <li> <p>Benchmark2 from Humbatova et al.:</p> <ul> <li>Location: <code>HumbatovaBench/SOSamples</code></li> </ul> </li> </ol> <h2>Reproducing Results</h2> <p>To replicate the results presented in the paper, follow these steps:</p> <ol> <li>Download the NeuralStateAnalysis Zip file.</li> <li>Extract the file and navigate to the NeuralStateAnlaysis directory.</li> <li>(Optional) Install the necessary requirements by executing <code>pip install requirements.txt</code>. Note: The requirements.txt file is already available in this repository.</li> </ol> <h3>Running NeuralState on <code>NLBench</code>:</h3> <ol> <li>Navigate to the <code>NLBench</code><code>/SOSamples</code> directory.</li> <li>Open any of the programs you wish to execute.</li> <li>Set the path to the NeuralStateAnalysis directory: <code>Path-to-folder/NeuralStateAnalysis/</code></li> <li>Run the program using the command <code>python program_id</code>. Since the 'NeuralStateAnalysis(model).debug()' call is already present in all programs, you will be able to reproduce the results.</li> </ol> <h3>Running NeuralState on <code>HumbatovaBench</code>:</h3> <ol> <li>Navigate to the <code>HumbatovaBench</code><code>/SOSamples</code> directory.</li> <li>Open any of the programs you wish to execute.</li> <li>Set the path to the NeuralStateAnalysis directory: <code>Path-to-folder/NeuralStateAnalysis/</code></li> <li>Run the program using the command <code>python program_id</code>. Since the 'NeuralStateAnalysis(model).debug()' call is already present in all programs, you will be able to reproduce the results.</li> </ol>
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.