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.
334
datasets available to search
ShareScore release 0.7.1
Dataset results
334 results for “python”
PyQBF: A Python Framework for Solving Quantified Boolean Formulas
<h1>PyQBF: A Python Framework for Solving Quantified Boolean Formulas</h1> <h2>Introduction</h2> <p>This artifact was submitted by Mark Peyrer, Maximilian Heisinger and Martina Seidl for the iFM 2024 with the submission number 2625 aiming for Available, Functional and Reusable badges. It contains everything necessary to reproduce the experiments shown in the corresponding paper. In the following sections you will learn everything you need to know about this artifact and how to reproduce the experiments.</p> <p>In order to make this artifact as accessible as possible, we divided the experiments into three tracks:</p> <ul> <li>The <strong>small</strong> track contains only a fraction of the experiments. It requires little time and memory usage compared to the whole track, producing only a rough overview of the desired data accordingly.</li> <li>The <strong>medium</strong> track gives a good overview and trend on how the data will look while remaining somewhere reasonable with time resources.</li> <li>The <strong>all</strong> track fully reproduces the experiment as shown in the original paper. Note that this track <strong>does not include formulas which ran out of resources for both solver and pyqbf in the original experiment</strong>.</li> </ul> <p>The artifact was published under the following DOI: <a href="../qbf/pyqbf-artifact/-/blob/master/10.5281/zenodo.13341211">10.5281/zenodo.13341211</a></p> <h2>Artifact Requirements</h2> <p>The following requirements were measured on a host machine for the docker container with the following specifications:</p> <ul> <li><a href="https://www.intel.de/content/www/de/de/products/sku/232160/intel-core-i71355u-processor-12m-cache-up-to-5-00-ghz/specifications.html" target="_blank" rel="nofollow noreferrer noopener">Intel Core i7-1355U Prozessor</a></li> <li>32 GB RAM</li> <li>Intel Iris Xe GPU</li> </ul> <p>Resource consumption in the original experiment was restricted (as it also is in this artifact) on 1hr as well as 8000MB per instance.</p> <p><strong>Outer-Counter Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min30s with a maximum memory usage of 65MB</li> <li><strong>medium</strong>: Approximately 1h with a maximum memory usage of 270MB</li> <li><strong>all</strong>: Approximately 7hrs with a maximum memory usage of 425MB</li> </ul> <p><strong>Caqe Comparison Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min with a maximum memory usage of 400MB</li> <li><strong>medium</strong>: Approximately 1h15min with a maximum memory usage of 2500MB</li> <li><strong>all</strong>: Approximately 12hrs30min with a maximum memory usage of 4000MB</li> </ul> <p><strong>DepQBF Comparison Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min45s with a maximum memory usage of 500MB</li> <li><strong>medium</strong>: Approximately 40min with a maximum memory usage of 2500MB</li> <li><strong>all</strong>: Approximately 25hrs30min with a maximum memory usage of 8000MB</li> </ul> <p><strong>QFun Comparison Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min with a maximum memory usage of 325MB</li> <li><strong>medium</strong>: Approximately 1h15min with a maximum memory usage of 820MB</li> <li><strong>all</strong>: Approximately 12hrs with a maximum memory usage of 4000MB</li> </ul> <p><strong>Qute Comparison Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min with a maximum memory usage of 90MB</li> <li><strong>medium</strong>: Approximately 2hrs with a maximum memory usage of 425MB</li> <li><strong>all</strong>: Approximately 22hrs with a maximum memory usage of 3200MB</li> </ul> <p><strong>RAReQS Comparison Experiment</strong></p> <ul> <li><strong>small</strong>: Approximately 1min with a maximum memory usage of 150MB</li> <li><strong>medium</strong>: Approximately 2hrs with a maximum memory usage of 7500MB</li> <li><strong>all</strong>: Approximately 17hrs with a maximum memory usage of 8000MB</li> </ul> <h2>Structure and Content</h2> <p>For running the artifact, the following structure is relevant for the experiments:</p> <div> <pre><code>/ |-- expected |-- experiments | |-- outer-counter | |-- compare-caqe | |-- compare-depqbf | |-- compare-qfun | |-- compare-qute | |-- compare-rareqs |-- gallery23 |-- output | |-- plots |-- scripts</code></pre> </div> <ul> <li><code>expected</code> contains the runs of the experiments conducted with this artifact on our machine for reference and the long runs</li> <li><code>experiments</code> contains the scripts and runtime data when running the experiments. Each experiment has their own folder</li> <li><code>gallery23</code> contains the complete testset of our experiments, i.e. the <a href="https://qbf23.pages.sai.jku.at/gallery/" target="_blank" rel="nofollow noreferrer noopener">QBF-Gallery 2023</a> QDIMACS track. A complete list of the instances with absolute paths can be found in <code>/experiments/targets.txt</code></li> <li><code>output</code> is the target of the results from the experiments, thus containing plots and sqlite-databases once executed. Furthermore, this folder is mounted by the host machine for comfortable access</li> <li><code>scripts</code> is a collection of python-scripts used by the experiments</li> </ul> <p>Furthermore, there are folders containing the necessary tools used by the experiments. Those are not relevant when running the experiments but for extending the artifact.</p> <div> <pre><code>/ |-- executables |-- outer-count |-- pyqbf |-- runlim |-- simsala |-- solvers | |-- caqe | |-- depqbf | |-- qfun | |-- qute | |-- rareqs</code></pre> </div> <ul> <li><code>executables</code> contains the executables of the solvers used in the experiments. They were built from the sources (except caqe) during the building-step of the docker image</li> <li><code>outer-count</code> is the <a href="https://github.com/marseidl/outer-count" target="_blank" rel="nofollow noreferrer noopener">cloned repository</a> containing the outer-count tool for counting models</li> <li><code>pyqbf</code> contains all sources of our framework. Note that it is already installed into Python as a module such that <code>import pyqbf</code> is sufficient for any python script in the docker container</li> <li><code>runlim</code> is the <a href="https://github.com/arminbiere/runlim" target="_blank" rel="nofollow noreferrer noopener">cloned repository</a> containing the runlim tool for benchmarking</li> <li><code>simsala</code> is the <a href="https://gitlab.sai.jku.at/simsala/simsala">cloned repository</a> containing the perl-scripts used for working with slurm. This was used to run the original experiments of the paper.</li> <li><code>solvers</code> contains the sources of the solvers their executables are build from. You can furthermore find their licences in there</li> </ul> <h2>How to use this artifact</h2> <h3>1. Setup Docker</h3> <p>We require you to have a working docker environment installed on your machine. In order to set-up the docker container, run the following commands</p> <div> <pre><code># download pyqbf-artifact.zst from zenodo docker load < pyqbf-artifact.zst docker run -v `pwd`/output:/output -itd --network none --name pyqbf_artifact1 pyqbf-artifact docker exec -it pyqbf_artifact1 bash</code></pre> </div> <p>The first line loads the docker-image from the the export, the second will create a container using the image and the last connects your current terminal to the container.</p> <p>In order to leave the container, just execute <code>exit</code>. Furthermore, you can call</p> <div> <pre><code>docker stop pyqbf_artifact1 docker rm pyqbf_artifact1</code></pre> </div> <p>to stop and delete the running container.</p> <p><strong>Important:</strong> Please ensure to have a working docker setup, with your user added to the <code>docker</code> group. This can be verified using <code>docker ps</code>. If there are no errors, your environment should be in working order.</p> <h3>2. Run the desired experiments</h3> <p>Reproduces figure 4, partwise.</p> <p><strong>Outer Counter</strong> (right part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/outer-counter/run-outer-small-seq.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/outer-counter/run-outer-medium-seq.sh</code></li> <li><strong>all:</strong> <code>/experiments/outer-counter/run-outer-all-seq.sh</code></li> </ul> <p><strong>Comparison of Caqe executable with its PyQBF version</strong> (partial left part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/compare-caqe/run-caqe-small.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/compare-caqe/run-caqe-medium.sh</code></li> <li><strong>all:</strong> <code>/experiments/compare-caqe/run-caqe-all.sh</code></li> </ul> <p><strong>Comparison of DepQBF executable with its PyQBF version</strong> (partial left part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/compare-depqbf/run-depqbf-small.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/compare-depqbf/run-depqbf-medium.sh</code></li> <li><strong>all:</strong> <code>/experiments/compare-depqbf/run-depqbf-all.sh</code></li> </ul> <p><strong>Comparison of QFun executable with its PyQBF version</strong> (partial left part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/compare-qfun/run-qfun-small.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/compare-qfun/run-qfun-medium.sh</code></li> <li><strong>all:</strong> <code>/experiments/compare-qfun/run-qfun-all.sh</code></li> </ul> <p><strong>Comparison of Qute executable with its PyQBF version</strong> (partial left part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/compare-qute/run-qute-small.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/compare-qute/run-qute-medium.sh</code></li> <li><strong>all:</strong> <code>/experiments/compare-qute/run-qute-all.sh</code></li> </ul> <p><strong>Comparison of RAReQS executable with its PyQBF version</strong> (partial left part of figure 4)</p> <ul> <li><strong>small:</strong> <code>/experiments/compare-rareqs/run-rareqs-small.sh</code></li> <li><strong>medium:</strong>: <code>/experiments/compare-rareqs/run-rareqs-medium.sh</code></li> <li><strong>all:</strong> <code>/experiments/compare-rareqs/run-rareqs-all.sh</code></li> </ul> <p>All of the scripts will show verbose output when called.</p> <h3>3. Check the results</h3> <p>The results are copied automatically to the <code>/output</code> folder, which is mounted by a local <code>./output</code> folder, such that after running the scripts the results will be available on your host machine.</p> <p>Furthermore, the results produced by us running the artifact can be found in the <code>/expected</code> folder in the docker container.</p> <p>In <code>/output/plots</code> (or <code>/expected/plots</code> respectively) you can find a logarithmic scatter plot with a corresponding name to the experiment produced by the data retrieved from the current run.</p> <p>Using the script <code>/scripts/diff-all.sh</code> you can check all available databases in the <code>/output</code> folder for differences in the result-code.</p> <p>Also the raw data is available directly in the <code>/output</code> folder as sqlite-databases. Those can either be looked at by a tool (we recommend <a href="https://sqlitebrowser.org/dl/" target="_blank" rel="nofollow noreferrer noopener">DB Browser for sqlite</a>) or by the command <code>sqlite3 <name>.db</code>. The latter will open the database and allows queries on the data. <strong>Note:</strong> Both variants require a working sqlite installation on your host machine (e.g. <code>apt-get install sqlite3</code>)</p> <h2>Functional Badge</h2> <p>In the paper, we claimed that using our framework only comes with small overhead in comparison to using the executables. In particular, we showed a state-of-the-art implementation of an outer-model counter and compared it to a scripted version using PyQBF.</p> <p>These claims can be replicated using this artifact. The <strong>all</strong>-track of each experiment will produce the necessary data to check this claim on the current machine on the same instances as seen in the paper. The other tracks (<strong>small</strong> and <strong>medium</strong>) will show a trend by evaluating a subset. By producing a scatter plot comparing a state-of-the-art instance to a scripted instance using PyQBF, it is trivial to see whether the claim holds.</p> <p>There is no direct evaluation script as the datapoints are too dependent on external factors to produce the same results. However, the result codes of the solver can be compared using the <code>/scripts/diff-all.sh</code> script.</p> <p>In order to check the code, we refer to the verbose of each of the experiments, where it is logged which executable is compared to which script. All sources of used tools are available within the artifact. Please check the <em>Structure and Content</em> section for further details.</p> <h2>Reusable badge</h2> <p>PyQBF is released under the GPLv3 licence and can be found publicly <a href="https://gitlab.sai.jku.at/qbf/pyqbf/">here</a>. Furthermore, an extensive documentation can be found <a href="https://gitlab.sai.jku.at/qbf/pyqbf/">here</a>.</p> <p>This artifact can be used in numberous ways beyond the paper. The full potential of PyQBF is at one's disposal with a simple <code>import pyqbf</code>. Let it be a new algorithm using QBF-solvers or simple tasks like negating a QCNF formula - the framework allows easy prototyping with minimal overhead. Another example is the comparison of solvers against each other. The script <code>/scripts/produce_scatter.py</code> can be used to compare the data of any two sqlite-databases generated by such experiments and plot an overview of by linking the problems by their names. Finally, also PyQBF itself can be extended by e.g. more solvers. While this requires some particular knowledge about the architecture and building-pipeline, the already existing solvers will serve as a good example on how to implement such task - no matter if used by an interface or as a library. If just using a solver is sufficient, it can be directly bound into the PyQBF framework using <a href="https://github.com/maximaximal/QuAPI" target="_blank" rel="nofollow noreferrer noopener">QuAPI</a> without needing to extend PyQBF (this only works if the command line interface is compatible with QuAPI).</p> <p>At the current state, we support PyQBF for linux-based operating systems. Windows is not and will not be supported. Support for MacOS is currently in development.</p> <h2>Dependencies</h2> <p>The following core-dependencies are required by this artifact. Note that this is <strong>soley for information purpose, those do not have to be installed manually</strong>. For a more detailed list we want to refer to the <a href="../qbf/pyqbf-artifact/-/blob/master/Dockerfile">Dockerfile</a>, where the whole artifact can be reproduced from scratch.</p> <p><strong>PyQBF (<a href="https://gitlab.sai.jku.at/qbf/pyqbf/-/tree/6a6cd1b535597d60895efd4971c7725f16e66eef">Commit 6a6cd1b535597d60895efd4971c7725f16e66eef</a>):</strong></p> <ul> <li><a href="https://pysathq.github.io/" target="_blank" rel="nofollow noreferrer noopener">PySAT</a></li> <li><a href="https://github.com/ltentrup/caqe" target="_blank" rel="nofollow noreferrer noopener">Caqe v4.0.1</a></li> <li><a href="https://github.com/lonsing/depqbf" target="_blank" rel="nofollow noreferrer noopener">DepQBF v6.03</a></li> <li><a href="https://github.com/MikolasJanota/qfun" target="_blank" rel="nofollow noreferrer noopener">QFun v1.0</a></li> <li><a href="https://github.com/fslivovsky/qute" target="_blank" rel="nofollow noreferrer noopener">Qute v1.1</a></li> <li><a href="https://sat.inesc-id.pt/~mikolas/sw/areqs/" target="_blank" rel="nofollow noreferrer noopener">RAReQS v1.1</a></li> <li><a href="https://github.com/maximaximal/QuAPI" target="_blank" rel="nofollow noreferrer noopener">QuAPI</a></li> <li><a href="https://fmv.jku.at/bloqqer/" target="_blank" rel="nofollow noreferrer noopener">Bloqqer</a></li> </ul> <p><strong>Needed for building PyQBF:</strong></p> <ul> <li>GCC for C++ (<a href="https://gcc.gnu.org/" target="_blank" rel="nofollow noreferrer noopener">g++</a>) compiler</li> <li><a href="https://zeromq.org/" target="_blank" rel="nofollow noreferrer noopener">ZeroMQ</a></li> <li><a href="https://www.zlib.net/" target="_blank" rel="nofollow noreferrer noopener">ZLib</a></li> <li><a href="https://cmake.org/" target="_blank" rel="nofollow noreferrer noopener">CMake</a></li> <li><a href="https://www.python.org/downloads/" target="_blank" rel="nofollow noreferrer noopener">Python3</a> and Pip</li> </ul> <p><strong>Needed for the Test-Environment:</strong></p> <ul> <li><a href="https://github.com/marseidl/outer-count" target="_blank" rel="nofollow noreferrer noopener">outer-count</a></li> <li><a href="https://www.sqlite.org/" target="_blank" rel="nofollow noreferrer noopener">Sqlite3</a></li> <li><a href="https://github.com/arminbiere/runlim" target="_blank" rel="nofollow noreferrer noopener">Runlim</a></li> <li><a href="https://gitlab.sai.jku.at/simsala/simsala/-/tree/main">Simsala</a></li> <li><a href="http://www.gnuplot.info/" target="_blank" rel="nofollow noreferrer noopener">Gnuplot</a></li> <li><a href="https://qbf23.pages.sai.jku.at/gallery/" target="_blank" rel="nofollow noreferrer noopener">QBF Gallery 2023</a></li> </ul>
Network files and Python code used in "Designing a sector-coupled European energy system robust to 60 years of historical weather data"
<p><strong>Description</strong></p> <p>This repository contains data presented in the paper <a href="https://www.nature.com/articles/s41467-024-54853-3" target="_blank" rel="noopener">Designing a sector-coupled European energy system robust to 60 years of historical weather data</a>. It contains the derived metrics (.csv) files from a:</p> <ol> <li>joint capacity and dispatch optimization with weather years (design years) from 1960 to 2021 as input</li> <li>dispatch optimization of the 62 capacity layouts using weather years (operational years) different from the design year.</li> </ol> <p>All results from (1) are found in "Capacity_optimization.zip" and results from (2) are found in "Dispatch_optimization.zip".</p> <p>The resulting network files (both from the capacity and dispatch optimization) are located <a href="https://anon.erda.au.dk/cgi-sid/ls.py?share_id=DuGvDWlkeI">here</a>.</p> <p>We also provide the Python code used to derive the metrics and to create the visualizations included in the paper. This is located in "Jupyter_notebooks". The Jupyter notebooks refer to Python scripts located <a href="https://github.com/ebbekyhl/multi-weather-year-assessment">here</a>.</p> <p><strong>Revisions:</strong></p> <p>This version includes the following additions compared to the previous versions: </p> <ul> <li>Timeseries of nodal loads for all years</li> <li>Timeseries of nodal heat pump Coefficient of Performance (COP) </li> <li>Nodal capacity and hourly capacity factors </li> </ul>
Supplementary material for the paper "PyNose: A Test Smell Detector for Python"
<p>This archive contains:</p> <ol> <li>Lists of projects used in our study.</li> <li>A full list of examples of the newly introduced Suboptimal Assert test smell.</li> <li>An example of a change graph used to discover Python-specific test smells.</li> <li>The results of the small-scale mapping study: a full list of papers, a full list of test smells, and the correlation between them.</li> </ol> <p>You can find all the details in README.txt</p>
Supplementary Materials for "An Automated Detection of Confusing Variable Pairs with Highly Similar Compound Names in Java and Python Programs"
<p>This is a dataset contains the data collected through the empirical study in our paper "An Automated Detection of Confusing Variable Pairs with Highly Similar Compound Names in Java and Python Programs."</p>
PAReTT: a Python package for the Automated Retrieval and management of divergence time data from the TimeTree resource for downstream analyses (Dataset)
<p>Dataset for article by the same title submitted the the <em>Journal of Molecular Evolution</em>.</p>
Identifying serpentine minerals by their chemical compositions with machine learning (dataset and python code)
<p>The dataset and python code for the manuscript of Identifying serpentine minerals by their chemical compositions with machine learning (submitted to American Geologist)</p>
Replication package for "Method Chaining Redux: An Empirical Study of Method Chaining in Java, Kotlin, and Python"
<p>This dataset includes scripts and data files used to generate all analysis and results from the paper. A <strong>README.md</strong> file is included for details on using the scripts.</p> <p>The dataset is quite large. It is broken down into three archives. All scripts are in <strong>replication-pkg.zip</strong> and the other 2 files only contain data. So if you want to just inspect the analysis, you only need that single zip.</p> <p>If you grab the <strong>data-cached.zip</strong> file and extract it, it will need around 3GB of space. This is the processed dataset stored in Parquet files. Use this if you want to just recreate the tables/figures from the paper.</p> <p>If you want to make changes to the analyses, you will need the raw data in <strong>data-raw.zip</strong>. This will need around 29GB of space once extracted. If you then generate the CSV files from those TXT files (which you will need to do for any custom analysis), you will need an additional 22GB of space.</p>
Using the Uniqueness of Global Identifiers to Determine the Provenance of Python Software Source Code
<p>A replication package for the paper "Using the Uniqueness of Global Identifiers to Determine the Provenance of Python Software Source Code", Journal of Empirical Software Engineering.</p>
Python code generating the data of figures 2, 3, 4, 5 and 6 of the manuscript: The evolution of cooperation in the unidirectional linear division of labour of finite roles
<p>The evolution of cooperation is an unsolved mystery, which we see in many social and biological systems. In the study titled "The evolution of cooperation in the unidirectional linear division of labour of finite roles", we investigate under which sanction systems and how the evolution of cooperation happens in the linear division of labour. </p> <p>This python code has been used to produce the results of Figures 2, 3, 4, 5, and 6 of the manuscript. This code shows the evolution of cooperation among the population of various different groups which have different roles to play in the linear division of labour, on the basis of numerical analysis of a partial differential equation system, which originates from the replicator equations used in the evolutionary game theory. We find the locally stable equilibria using this code, which shows the ultimate results of the dynamics in the system under given parameters. Figures 3, 5, and 6 are direct products of the code, showing the dynamics of a system, and figures 2 and 4 are the end results of those dynamics. </p> <p>We found that in a social dilemma situation, cooperation never evolves in the system without punishment. However, with sanction systems by introducing a suitable amount of punishment, while having a suitable findability of the defector, and a suitable initial population structure, cooperation can evolve. These results can be found with this code. We have no legal or ethical concerns regarding this data as this is a numerical analysis based on theoretical equations. </p>
Defectors: A Large Scale Python Dataset for Defect Prediction
<p>Defect prediction has been a major research problem in the software engineering domain for the last five decades.<br> In recent years, large deep-learning models have shifted the performance of software engineering tasks to new limits and are gaining usage in defect prediction.<br> However, these defect prediction models are often limited by the quality of their datasets, which are not large or diverse enough.<br> In this paper, we present Defectors, a large dataset for both line-level and just-in-time defect prediction.<br> Defectors consist of $\approx$ 213K source code files ($\approx$ 93K defective and $\approx$ 120K defect-free files) from 25 popular python projects from various domains and organizations.<br> These projects come from a diverse set of domains including machine learning, automation, and internet-of-things.<br> Such a scale and diversity make Defectors a suitable dataset for deep learning models, especially transformer models that require large and diverse datasets to effectively generalize defect-inducing patterns to predict future defects.</p> <table> <caption>Dataset Description</caption> <tbody> <tr> <td>File Name</td> <td>Description</td> </tr> <tr> <td>defectors.zip</td> <td>The original Dataset. Find its description in Section II of the paper.</td> </tr> <tr> <td>bug_inducing_commits.zip</td> <td>Each yaml file contains a map of bugfix commits to bug-inducing commits.</td> </tr> <tr> <td>filtered_bug_inducing_commits.yaml</td> <td>A map in structure {repo_name: {bug_inducing_commits: [list of python files in the commit]}}. This file only contains the bug-inducing commits that match the filtering criteria from Section III.D.</td> </tr> <tr> <td>repo_links.yaml</td> <td>Links to the repositories we used to construct the dataset.</td> </tr> </tbody> </table> <p> </p>
Supporting material for PyESDv1.0.1 An open-source Python framework for empirical-statistical downscaling of climate information
<p>The nature and severity of climate change impacts varies significantly from region to region. Consequently, high-resolution climate information is needed for meaningful impact assessments and the design of mitigation strategies. This demand has led to an increase in the coupling of Empirical Statistical Downscaling (ESD) models to General Circulation Model (GCM) simulations of future climate. Here, we present a new open-source Python package (<em>pyESD; </em>github.com/Dan-Boat/PyESD) that implements several Perfect Prognosis ESD (PP-ESD) methods and the whole downscaling cycle. The latter includes routines for data preparation, predictor selection and construction, model selection and training, evaluation, utility tools for relevant statistical tests, visualization, and more. The package includes a collection of well-established Machine Learning algorithms and allows the user to choose a variety of estimators, cross-validation schemes, objective function measures, hyperparameter optimization, etc., in relatively few lines of code. The package is highly modular and flexible and allows quick and reproducible downscaling of any climate information, such as precipitation, temperature, wind speed, or even glacial retreat. The dataset presented here serves as supporting material for the package description and evaluation manuscript</p>
Computational results and python files for the work "Divergence-conforming velocity and vorticity approximations for incompressible fluids obtained with minimal facet coupling"
<p><br> This repository contains data accompanying the paper "Divergence-conforming velocity and vorticity approximations for incompressible fluids obtained with minimal facet coupling".</p> <p>The implementation is based on the python-interface of the NGSolve open source Finite Element library (ngsolve.org).</p> <p>The file solve_problem_allione.py represents a minimum working example where the proposed MCS/HDG (set the use_MCS flag) method is used to solve the problem from the numerics section of the paper.</p> <p>The files FlowTemplates.py and krylovspace_extension.py contain a somewhat larger and more modular implementation of the proposed method that also features preconditioned iterative solvers, including support for the NgsAMG NGSolve extension library as well as the NGSolve-PETSc interface.</p> <p>The files errors_hdg.pickle, errors_mcs.pickle and kappas.pickle contain the raw data the tables and pictures in the paper were generated from.</p> <p>This data was generated with the scripts conv3d_hdg.py, conv3d_mcs.py and calc_kappas.py which use the FlowTemplates.py infrastructure.</p>
FLUTE: a Python GUI for interactive phasor analysis of FLIM data
<p>This repository contains the Fluorescence lifetime imaging microscopy (FLIM) data relative to the following publication <em>"FLUTE: a Python GUI for interactive phasor analysis of FLIM data" </em>https://www.biorxiv.org/content/10.1101/2023.03.31.534529v1</p> <p><em><strong>Fluorescein.tif</strong> </em>stack contains the fluorescence intensity decay of fluorescein solution with a known lifetime of 4ns, used as calibration.</p> <p><strong><em>Embryo.tif</em></strong> file contains the fluorescence intensity decay of a zebrafish embryo at 3 days post fertilisation.</p> <p>Both files have been acquired with the following parameters:</p> <ul> <li>temporal bin number = 56</li> <li>laser repetition rates = 80 MHz</li> <li>bin width = 0.223ns</li> </ul>
Dataset for the paper "The Relationship Between Different Python Argument-Passing Mechanisms and Fixes: An Empirical Study"
<p>This is the replication package of the article</p> <p>The Relationship Between Different Python Argument-Passing Mechanisms and Fixes: An Empirical Study</p> <p> </p> <p>Abstract:</p> <p>Modern programming languages (such as Python, but not only) have introduced a variety of constructs and syntactical elements to make software development more efficient and concise. Examples include lambda functions, comprehension collections, of mechanisms to facilitate the passing of arguments to a function. While many of such constructs may, in principle, be beneficial for developers, recent studies have shown that certain programming constructs introduce atoms of confusion, and may therefore affect program understanding. Moreover, recent work has shown that changes to some constructs, namely functional constructs of Python, induce more fixes than other changes. This paper studies the effect of different Python argument-passing mechanisms to investigate their relationship with code proneness to be fixed. Specifically, we study the fix-proneness for what concerns the function definition, as well as its invocation. This is done by analyzing the evolutionary history of 200 Python projects, for a total of about 3M functions and 12M call sites. While there are varying effects for what concerns parameter declaration mechanisms, we found evidence that keyword-based argument passing is less defect prone than positional argument passing, and this is not affected by size-related confounding factors.</p>
Global trade data of highly hazardous chemicals after data treatment and Python codes used for error analysis and mirror analysis
<p>This database includes all global trade data of the three types of highly hazaroudous chemicals listed under the Rotterdam Convention after error analysis and mirror analysis. Python codes used for error analysis and mirror analysis are also available.</p> <p> </p> <p> Corresponding authors: <a href="mailto:hongyan.zou@tjnu.edu.cn">hongyan.zou@tjnu.edu.cn</a>; <a href="mailto:Zhanyun.wang@empa.ch">Zhanyun.wang@empa.ch</a></p>
200 Python selected projects for various software engineering studies
<p>History of 200 open-source Python projects hosted on GitHub - git clone at Feb 2022</p>
ASAS-SN 100 Million Variable Star Python CSV filter
<p>A subset of the ASAS-SN 100 Million Variable Star Database CSV filter</p>
PlanetProfile Python version outputs compared to models of Vance et al. (2018)
<p>Plain text outputs, associated input files, and comparison figures for hydrosphere properties for PlanetProfile models analogous to those studied by Vance et al. (2018), for Europa, Ganymede, Callisto, Enceladus, and Titan. PlanetProfile is an open-source geophysical modeling framework available at https://github.com/NASA-Planetary-Science/PlanetProfile. The inputs and outputs are from and created by the v2.3.17 release, with default settings. Output files list bulk properties in header lines at the top, then physical properties of each spherically symmetric layer along with depth and radius, beginning at the surface and continuing to the center of the body.</p> <p>Vance et al. (2018) is available at: <a href="https://doi.org/10.1002/2017JE005341">https://doi.org/10.1002/2017JE005341</a></p>
Dataset and Python Scripts used in the manuscript "Global-MHD Simulations using MagPIE : Impact of Flux Transfer Events on the Ionosphere"
<p>Dataset and Python Scripts used in the manuscript "Global-MHD Simulations using MagPIE : Impact of Flux Transfer Events on the Ionosphere".</p> <p>Authors: Arghyadeep Paul, Antoine Strugarek and Bhargav Vaidya<br> Date: 21 May, 2023</p> <p> </p> <ul> <li>Figure 1 has been plotted from two data files named Bx_By_Bz_prs_t_4783_C0.vtk and Bx_By_Bz_prs_t_4783_C1.vtk using the visualisation toolkit VisIt. Visit can be freely downloaded from https://wci.llnl.gov/simulation/computer-codes/visit</li> <li>Figure 2 has been plotted using the ipython notebook named "figure_2.ipynb" and the associated data files have been uploaded alongwith.</li> <li>Figure 3 has been plotted using the data file named "visit_prs_Bx_By_Bz_t_4964s.vtk" and the visualisation toolkit VisIt.</li> <li>Figure 4 has been plotted using the associated data files and the visualisation toolkit VisIt.</li> <li>Figures 5 and 6 has been plotted using the ipython notebook named "new_fig_5_and_6.ipynb" and the associated data files have been uploaded alongwith.</li> <li>Figure 7 has been plotted using the ipython notebook named "figure_7.ipynb" and the associated data files have been uploaded alongwith.</li> <li>Figure 8 has been plotted using the ipython notebook named "figure_8.ipynb" and the associated data files have been uploaded alongwith.</li> <li>Figure 9 has been plotted using the ipython notebook named "figure_9.ipynb" and the associated data files have been uploaded alongwith. An example swarm CSV data file is added for the python script. The original SWARM data can be downloaded from <a href="https://swarm-diss.eo.esa.int/">https://swarm-diss.eo.esa.int/</a> and the FAC data from two spacecrafts, Swarm A and C, named SW_OPER_FAC_TMS_2F has been used. This data was first published in Dong et.al. 2023 [https://doi.org/10.1029/2022GL102460].</li> </ul>
Legacy 2022 UAV REM (python) & histograms
<p>Legacy 2022 UAV REM generated using python and histograms for 2022 UAV DTM, REM (ArcMap), and REM (Python)</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.