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.

datasets available to search

ShareScore release 0.9.0

Dataset results

78 results for “trips”

Learn how ShareScore rates datasets ↗

zenodo52/100

Microscopic trip chains for Brunswick (Germany) region

The data set contains microscopic trip chains for the Brunswick (Braunschweig) area in Germany on an average day. All synthetic persons within Braunschweig are shown, as well as all households outside Braunschweig where at least one synthetic person had an activity in Braunschweig. The generation of this data set is based on a two-stage process. The starting point is the macroscopic transport demand model DEMO (Winkler and Mocanu, 2020: https://doi.org/10.1016/j.trd.2020.102476) and a population upscaled from the MiD 2017 ("Mobilität in Deutschland") for Germany, which was spatially distributed according to the BKG household dataset (households, inhabitants, federal government). In the first step of the process, the trip chains between the DEMO traffic cells were generated based on the daily schedules of the MiD population (Mocanu and Joshi, 2022: https://elib.dlr.de/188443/). In the second step of the process, corresponding locations were assigned within the target traffic cells. The locations were previously extracted from OpenStreeMap and attributed with activities according to their attributes/metadata (key/value pairs) (Malkus et al., 2024: https://doi.org/10.1016/j.procs.2024.06.043).

opencc-by-4.0Aug 2024View details →

zenodo48/100

Public charging requirements for battery electric long-haul trucks in Europe: a trip chain approach

Contact details: wasim.shoman at chalmers.se  waahh7 at gmail com Abstract of the research: Heavy-duty vehicles (HDV) account for less than 2-5% of the vehicles on the road in Europe but contribute to 15-22% of CO2 emissions from road transport. Battery electric trucks (BETs) could be deployed on a large scale to reduce greenhouse gas emissions. However, they require sufficient charging infrastructure to support long-haul operations. Therefore, assessing the required charging locations, energy, and power requirements is critical. We use a trip-chain-based model to derive charging requirements for BETs in long-haul operation (travel times over 4.5 hours or over 360 km distance traveled) for Europe in 2030. We convert an origin-destination (OD) matrix into trip chains combined with European truck driving regulations to derive break and rest stops. We show that an average charging area (defined as a 25´25 km2 square with each square that could include multiple charging stations and parking lots of multiple charging points) needs to have four to five times more overnight than megawatt charging points. We estimate that about 40,000 overnight charging points (50-100 kW, combined charging system, CCS) and about 9,000 megawatt charging system (MCS, 0.7 – 1.2 MW) points are required for 15% of trucks as BETs in long-haul operation. On average, 8 and 2 CCS and MCS chargers are required per charging area, and each MCS and CCS serve, on average, 11 and 2 BETs daily, respectively. Public charging entails about 110 GWh daily electricity demand in each charging area. The model can be applied to any region with similar data. Future work can consider improving the queuing model, assumptions regarding regional differences of BET penetration, and heterogeneity of truck sizes and utilization. The methodology: We develop a method to place charger locations in Europe that meets the demand of goods movements between regions while following EU driving regulations. The spatial resolution of regions is based on the Nomenclature of Territorial Units for Statistics (NUTS)-3 regions. The annual flow of goods transported by HDV is identified using the ETISplus dataset. We develop a travel pattern for the HDV to convert flows into trip chains with the traversed LHT number. The traveled routes between the regions are mapped. Locations of short period stops, i.e., breaks, and long period stops, i.e., rests, are allocated/assigned along traveled routes to construct a trip chain for each moving HDV. Break and rest locations for all moving HDVs are aggregated to suggest energy requirements if assuming these HDVs are BETs. The aggregated energy to charge stopped BETs is used to identify the number and type of chargers within each suggested charging station. Datasets details The presented datasets contain spatial information for generating charger stations with specifications according to charging needs. The datasets contain information about: Transport network model and edges, Transported flows, routes and flow center information data, region centers, and Planned transport infrastructure.  The first dataset titled 'ChargerLocations' contains information about the locations of suggested charging stations, the number and type of chargers, and the number of visited electrified trucks in 2030. It is a shapefile with the following details for its fields: <table> <tbody> <tr> <td>Name</td> <td>Description</td> <td>Data Type</td> <td>Unit</td> </tr> <tr> <td>DTN30/MainDTN</td> <td> number of electrified trucks in 2030</td> <td>integer </td> <td>number</td> </tr> <tr> <td>ChE30</td> <td> charged energy in Mega watt-hour from all charging (fast and slow)</td> <td>float</td> <td> Mega watt-hour</td> </tr> <tr> <td>ChERM</td> <td> charged energy in Megawatt hour with slow charging only (rest)</td> <td>float</td> <td> Mega watt-hour</td> </tr> <tr> <td>MDTN_R</td> <td> number of electrified trucks using slow chargers (rest)</td> <td>integer </td> <td>number</td> </tr> <tr> <td>ChEBM</td> <td> charged energy in Megawatt hour with fast charging only (break)</td> <td>float</td> <td> Mega watt-hour</td> </tr> <tr> <td>MDTN_B</td> <td> number of electrified trucks using fast chargers (break)</td> <td>integer </td> <td>number</td> </tr> <tr> <td>NSCh2pD</td> <td> number of slow chargers</td> <td>integer </td> <td>number</td> </tr> <tr> <td>NFCh30m</td> <td> number of fast chargers</td> <td>integer </td> <td>number</td> </tr> <tr> <td>TotCha</td> <td> Total number of chargers</td> <td>integer </td> <td>number</td> </tr> </tbody> </table>   The second dataset titled (RestandBreaksPoints.shp) with information about the rest and break point locations. The dataset includes detailes about stop type, number of stopped trucks, and required charged energy. The dataset is a shapefile with "shp" format.  <table> <tbody> <tr> <td> Name </td> <td> Description </td> <td> Data Type </td> <td> Unit </td> </tr> <tr> <td> ID_origin_region </td> <td> Unique record ID with 9 digits decoding NUTS-3 region of origin. First 3 digits decode NUTS-0, first 5 decode NUTS-1, first 7 decode NUTS-3 </td> <td> Integer (9digits) </td> <td> - </td> </tr> <tr> <td> Name_origin_region </td> <td> National name of NUTS-3 region of origin </td> <td> String </td> <td> - </td> </tr> <tr> <td> ID_destination_region </td> <td> Unique record ID with 9 digits decoding NUTS-3 code of destination region. First 3 digits decode NUTS-0, first 5 decode NUTS-1, first 7 decode NUTS-3 </td> <td> Integer (9digits) </td> <td> - </td> </tr> <tr> <td> Name_destination_ region </td> <td> National name of NUTS-3 destination region </td> <td> String </td> <td> - </td> </tr> <tr> <td> Rest </td> <td> A value of ”1” indicates a rest stop </td> <td> Boolean </td> <td> - </td> </tr> <tr> <td> Break </td> <td> A value of ”1” indicates a break stop </td> <td> Boolean </td> <td> - </td> </tr> <tr> <td> ChaDisKM </td> <td> Charged range within a trip for stopped the truck </td> <td> Float </td> <td> km </td> </tr> <tr> <td> ChaEnekWh </td> <td> Charged energy within a trip for stopped the truck </td> <td> Float </td> <td> KWh </td> </tr> <tr> <td> MainDTN </td> <td> Number of stopped trucks for the main electrification scenario (15%) </td> <td> Float </td> <td> number </td> </tr> <tr> <td> ChE30M </td> <td> Charged energy for all stopped trucks </td> <td> Float </td> <td> MWh </td> </tr> <tr> <td> ChERM </td> <td> Charged energy for the trucks stopping for rest </td> <td> Float </td> <td> MWh </td> </tr> <tr> <td> MDTN_R </td> <td> Number of trucks stopping for rest </td> <td> Float </td> <td> number </td> </tr> <tr> <td> ChEBM </td> <td> Charged energy for the trucks stopping for break </td> <td> Float </td> <td> MWh </td> </tr> <tr> <td> MDTN_B </td> <td> Number of trucks stopping for break </td> <td> Float </td> <td> number </td> </tr> <tr> <td> geometry </td> <td> X, Y coordinates </td> <td> geometry </td> <td> - </td> </tr> </tbody> </table>     The following dataset titled 'flowFile' with information about the transported flow between regions and the transported routes. The dataset is in "CSV" format. Details for its fields are explained as follows (source: https://www.sciencedirect.com/science/article/pii/S235234092101060X): <table> <tbody><tr> <th> Name </th> <th> Description </th> <th> Data Type </th> <th> Unit </th> </tr> </tbody><tbody> <tr> <td> ID_origin_region </td> <td> Unique record ID with 9 digits decoding NUTS-3 region of origin. First 3 digits decode NUTS-0, first 5 decode NUTS-1, first 7 decode NUTS-3 </td> <td> Integer (9digits) </td> <td> - </td> </tr> <tr> <td> Name_origin_region </td> <td> National name of NUTS-3 region of origin </td> <td> String </td> <td> - </td> </tr> <tr> <td> ID_destination_region </td> <td> Unique record ID with 9 digits decoding NUTS-3 code of destination region. First 3 digits decode NUTS-0, first 5 decode NUTS-1, first 7 decode NUTS-3 </td> <td> Integer (9digits) </td> <td> - </td> </tr> <tr> <td> Name_destination_ region </td> <td> National name of NUTS-3 destination region </td> <td> String </td> <td> - </td> </tr> <tr> <td> Edge_path_E_road </td> <td> List of the network edge IDs of the shortest path between the O-D pair, determined with Dijkstra's algorithm </td> <td> String </td> <td> - </td> </tr> <tr> <td> Distance_from_origin_ region_to_E_road </td> <td> Distance from the geometric centre of the origin region to the closest network node </td> <td> Float </td> <td> Kilometres [km] </td> </tr> <tr> <td> Distance_within_E_ road </td> <td> Distance of the shortest edge path between the O-D pair </td> <td> Float </td> <td> Kilometres [km] </td> </tr> <tr> <td> Distance_from_E_ road_to_destination_ region </td> <td> Distance from the geometric centre of the destination region to the closest network node </td> <td> Float </td> <td> Kilometres [km] </td> </tr> <tr> <td> Total_distance </td> <td> Sum of Distance_from_origin_region_to_E_road, Distance_within_E_road and Distance_from_E_road_to_destination_region </td> <td> Float </td> <td> Kilometres [km] </td> </tr> <tr> <td> Traffic_flow_trucks_ 2010 </td> <td> Number of trucks that drive between the O-D pair in 2010 </td> <td> Float </td> <td> Number of trucks </td> </tr> <tr> <td> Traffic_flow_trucks_ 2019 </td> <td> Number of trucks that drive between the O-D pair after they had been scaled to 2019 </td> <td> Float </td> <td> Number of trucks </td> </tr> <tr> <td> Traffic_flow_trucks_ 2030 </td> <td> Number of trucks that drive between the O-D pair according to the forecast for 2030 </td> <td> Float </td> <td> Number of trucks </td> </tr> <tr> <td> Traffic_flow_tons_ 2010 </td> <td> Number of tons that are transported between the O-D pair in 2010 according to ETISplus </td> <td> Integer </td> <td> Tons [t] </td> </tr> <tr> <td> Traffic_flow_tons_ 2019 </td> <td> Number of tons that are transported between the O-D pair after they had been scaled to 2019 </td> <td> Integer </td> <td> Tons [t] </td> </tr> <tr> <td> Traffic_flow_tons_ 2030 </td> <td> Number of tons that are transported between the O-D pair according to the forecast for 2030 </td> <td> Integer </td> <td> Tons [t] </td> </tr> </tbody> </table> Description of variables used in the NUTS-3 regions dataset (02_NUTS-3-Regions). The dataset is in "CSV" format. (source: https://www.sciencedirect.com/science/article/pii/S235234092101060X)) <table> <tbody><tr> <th> Name </th> <th> Description </th> <th> Data Type </th> <th> Unit </th> </tr> </tbody><tbody> <tr> <td> Network_Node_ID </td> <td> Unique network node ID </td> <td> Integer (6 digits) </td> <td> - </td> </tr> <tr> <td> Network_Node_X </td> <td> Longitude of the location of network node </td> <td> Float </td> <td> Degrees </td> </tr> <tr> <td> Network_Node_Y </td> <td> Latitude of the location of network node </td> <td> Float </td> <td> Degrees </td> </tr> <tr> <td> ETISplus_Zone_ID </td> <td> ID of the NUTS-3 region in which the network node is located </td> <td> Integer </td> <td> - </td> </tr> <tr> <td> Country </td> <td> Unique country code of the country in which the network node is located (country codes are defined by ETISplus) </td> <td> String </td> <td> - </td> </tr> </tbody> </table> Description of variables used in the network edges list (Updated_04_network-edges). The dataset is in "CSV" format. (source: https://www.sciencedirect.com/science/article/pii/S235234092101060X)) <table> <tbody><tr> <th> Name </th> <th> Description </th> <th> Data Type </th> <th> Unit </th> </tr> </tbody><tbody> <tr> <td> Network_Edge_ID </td> <td> Unique edge ID </td> <td> Integer (7 digits) </td> <td> - </td> </tr> <tr> <td> Manually_Added </td> <td> Determines whether an edge had been manually added to the network (1) or not (0) </td> <td> Binary-integer </td> <td> - </td> </tr> <tr> <td> Distance </td> <td> Length of the network edge </td> <td> Float </td> <td> Kilometres [km] </td> </tr> <tr> <td> Network_Node_A_ID </td> <td> Unique ID of the network node that defines one end point of the network edge </td> <td> Integer </td> <td> - </td> </tr> <tr> <td> Network_Node_B_ID </td> <td> Unique ID of the network node that defines one end point of the network edge </td> <td> Integer </td> <td> - </td> </tr> <tr> <td> Traffic_flow_trucks_2019 </td> <td> Number of trucks that drive on the edge in 2019 (both highway directions combined) </td> <td> Float </td> <td> Number of trucks </td> </tr> <tr> <td> Traffic_flow_trucks_2030 </td> <td> Number of trucks that drive on the edge in 2030 (both highway directions combined) </td> <td> Float </td> <td> Number of trucks </td> </tr> </tbody> </table>

opencc-by-4.0Oct 2022View details →

zenodo48/100

Bicycle trips collected using Cyclists Geo-C geo-game

This is an experimental dataset for the bicycle trips recorded using and geo-game called "Cyclist Geo-C". It contains the geometry of the trips recorded by 60 participants from three European Cities: Münster, Germany; Castelló, Spain; Valletta, Malta. This dataset was collected and analysed for the PhD Thesis "Mobile Services for Green Living" part of the European Joint Doctorate in Geoinformatics and the <a href="http://geo-c.eu/">Geo-C </a>Project.  The dataset is composed of three subsets. <ol> <li>There is a point dataset called "trips_od.geojson" which contained the point geometries where each trip started and ended with attributes for latitude, longitude, altitude, and precision coordinates. Each point also had the timestamp which indicates the time when the user started or ended the trip.</li> <li>There is a line dataset called "segments.geojson" which contained the geometries of the straight lines connecting two locations of the participant. Each segment started from an initial point "pi" recorded at a "ti” and ended at the next point recorded by the user "pf” at time “tf”. The time difference between "ti” and “tf” was at most five minutes while the length of the segment was at most one kilometre. Each segment also had the participant and trip identifier, and the segment's sequence number within the trip For each of the trip segments, we calculated the distance and speed using the recorded coordinates and timestamps from "pi" and "pf" points. \(trip\_segment = f(p_i,p_f)\) and \(segment\_speed = \frac{distance(p_i,p_f)}{\Delta time(p_i,p_f)}\). Then we classified the segments according to the calculated distance as: “walking segment” when the calculated speed was less than 5 km/h;  “cycling segment” when the calculated speed was between 5 and 50 km/h; or “non-cycling segment” when the calculated speed was more than 50 Km/h.</li> <li>There was another line dataset called “trips_tags.geojson ” which contained the geometries of each of the trip paths. A trip was a line (also called polyline by GIS users) defined by the ordered sequence of trip segments. It started from origin point "pi" of the trip’s first segment and ended at the destination point "pf" of the trip's last segment. Each trip also had the participant's identification, trip's identification, the number of segments, start and end times.</li> </ol> In addition to the experimental dataset recorded by participants, our analysis used a secondary dataset to define a comparable framework for the three cities. The secondary dataset consisted of the existing bicycle paths in the cities of Münster and Castelló as well as the planned bicycle paths around Valletta. For the city of Münster, the source of the bicycle paths was the <a href="http://www.openstreetmap.org">OpenStreetMap</a> (we downloaded the line elements with the tags “bicycle=yes” and "cycleway=yes”). For the city of Castelló, we obtained the bicycle paths from the city transport authority, including the city of Valletta, we created a digital version of the national bicycle network plan. We estimated the number of trips "bikepaths_trips.geojson" and the number of segments "bikepaths_segments.geojson" at each bike path. Also, we provide the areas where participants faced frictions during the experiment which corresponded to low cycling speeds "frictions.geojson". Finally, we provide a visual reference of the dataset in "frictions_cities.pdf".

opencc-by-4.0Sep 2018View details →

edi48/100

H.J. Andrews Forest Discovery Trail: An interpretation of place based on curriculum of interpretive learning trail and field trip support, 2016

The H.J. Andrews Experimental Forest (HJA) in the Oregon Cascades is one of 24 sites in the Long-Term Ecological Research (LTER) Network. It supports research on forests, streams, and watersheds, and fosters collaborations between ecosystem science, education, natural resource management, and the humanities. The site currently hosts 85 interdisciplinary research projects, as well as experiential training for undergraduate and graduate students. In addition, the HJA runs a vibrant professional development program for teachers. Because much of the HJA’s terrain is steep and occupied with sensitive research materials, middle and high school visits are limited to tours in designated areas. The Discovery Trail was developed in 2011 as a place for visitors (~1800 in 2014) to explore the forest and site research themes from HJA headquarters, but it is not yet amenable to unguided educational exploration. We have designed an interpretive learning trail and field trip support framework for the Discovery Trail. Our primary objective is to educate students about place while guiding them to reflect upon their own relationships with place and personal responsibility for stewardship behavior. Long-term place-based conservation research is woven with creative writing from the HJA writer’s residency program and paired with reflection and creative inquiry. Interactive trail stops enable students to engage the forest from multiple perspectives. The Discovery Trail is wired for intranet wifi and content and assessment will be delivered by digital media (i.e. iPads). We will evaluate conceptual learning according to the Framework for the Next Generation Science Standards, as well as observe affective changes in sense of place, empowerment, and expressions of care or empathy through analysis of student responses to the trail activities. Because conservation attitudes require not just knowledge about systems, but also emotional connections to the material, our learning experience will in

openCC (other)Oct 2016View details →

zenodo44/100

Vehicle Trips Dataset without Missing Values

This dataset contains 329 daily time series representing the number of trips and vehicles belonging to a set of for-hire vehicle (FHV) companies. The dataset was originally extracted from https://github.com/fivethirtyeight/uber-tlc-foil-response. The original dataset contains missing values and they have been replaced by carrying forward the corresponding last seen observations (LOCF method).

opencc-by-4.0Jul 2021View details →

zenodo44/100

Vehicle Trips Dataset with Missing Values

opencc-by-4.0Jul 2021View details →

zenodo44/100

Replication package for "Assessing the Latent Automated Program Repair Capabilities of Large Language Models using Round-Trip Translation"

This repository contains the replication package for the paper "Assessing the Latent Automated Program Repair Capabilities of Large Language Models using Round-Trip Translation" by Fernando Vallecillos Ruiz, Anastasiia Grishina, Max Hort and Leon Moonen, accepted for publication in ACM Transactions on Software Engineering and Methodology on 2025-10-09. A preprint is deposited on arXiv with DOI: <a href="https://doi.org/10.48550/arXiv.2401.07994">10.48550/arXiv.2401.07994</a>. The replication package is archived on Zenodo with DOI: <a href="https://doi.org/10.5281/zenodo.10500593">10.5281/zenodo.10500593</a>. It is maintained on GitHub at <a href="https://github.com/secureIT-project/RTT_for_APR">https://github.com/secureIT-project/RTT_for_APR</a>. This project builds on code from the <a href="https://github.com/lin-tan/clm/">clm</a> project, which is (c) 2023, The ASSET research group led by Lin Tan, Purdue University, licensed under the BSD 3-Clause License (see jasper/LICENSE.BSD). All modifications and new contributions are (c) 2025 by the authors of this replication package and distributed under the MIT License (see LICENSE.MIT). The data, models and preprint are distributed under the CC BY 4.0 license. <h2>Citation<code> </code></h2> If you build on this data or code, please cite this work by referring to the paper: <div> <pre><code>@article{ruiz2025:rtt, title = {Assessing the Latent Automated Program Repair Capabilities of Large Language Models using Round-Trip Translation}, author = {Vallecillos Ruiz, Fernando and Anastasiia Grishina and Max Hort and Leon Moonen}, journal = {ACM Transactions on Software Engineering and Methodology (TOSEM)}, year = {2025}, publisher = {{ACM}} }</code></pre> </div> <h2>Organization</h2> The replication package is organized as follows: <ul> <li>clm-apr <ul> <li>plbart: code to generate patches with PLBART models.</li> <li>codet5: code to generate patches with CodeT5 models.</li> <li>transcoder: code to generate patches with the TransCoder model.</li> <li>incoder: code to generate patches with InCoder models.</li> <li>santacoder: code to generate patches with the SantaCoder model.</li> <li>starcoder: code to generate patches with the StarCoderBase model.</li> <li>quixbugs: code to validate patches generated for the QuixBugs benchmark.</li> <li>defects4j: code to validate patches generated for any of the Defects4J benchmarks.</li> <li>humaneval: code to validate patches generated for the HumanEval-Java benchmark.</li> </ul> </li> <li>humaneval-java: the HumanEval-Java benchmark proposed by Jiang et al. 2023</li> <li>jasper: a Java tool to parse Java programs needed to preprocess input.</li> <li>model: folder to download the language models.</li> <li>analysis_wandb: data from WandB and Jupyter notebook to create graphs.</li> <li>tmp_benchmarks: folder for temporary files used in patch validation. The folder may contain pairs of `paralell’ folders src and src_org for each benchmark, used to replace buggy code with candidate patches.</li> </ul> <h2>Replication</h2> <h3>Prerequisites</h3> <ul> <li>Python version: 3.8—3.10.</li> <li><a href="https://git-lfs.com/">Git LFS</a> is required for model downloading.</li> </ul> <h4>Weight and Biases (WandB)</h4> <ol> <li>Create an account on <a href="https://wandb.ai/">Weights and Biases</a></li> <li>Install the <a href="https://docs.wandb.ai/ref/python">Weights and Biases</a> library</li> <li>Run <code>wandb login</code> and follow the instructions</li> </ol> <h4>Set up OpenAI access</h4> OpenAI account is needed with access to <code>gpt-3.5-turbo</code> and <code>gpt-4</code> . The <code>OPENAI_API_KEY</code> environment variable should be set to your OpenAI API access token. <h3>Dependencies</h3> <ul> <li><a href="https://github.com/rjust/defects4j">Defects4J</a> - To generate inputs for the Defects4J datasets or to validate them, you need to have installed <a href="https://github.com/rjust/defects4j">their tool</a>.</li> <li>Java 8</li> <li>Apache Maven</li> </ul> <h3>Setup</h3> We recommend the use of the setup script: <pre><code>setup.sh </code></pre> which performs the following: <ol> <li>Creates a virtual environment for Python and activate it.</li> <li>Install the packages in <code>requirements.txt</code>.</li> <li>Compiles Jasper.</li> <li>Downloads parsers.</li> <li>Check if the Defects4J installation is correct.</li> </ol> <h3>Download models</h3> The following bash script contains the code to download all of the models used: <pre><code>models/download_models.sh </code></pre> We recommend downloading only the models you are going to use due to their size <pre><code>cd models chmod +x download_models.sh ./download_models.sh </code></pre> To run one specific model, for example, PLBART (C#), use the following commands: <pre><code>cd models git lfs install git clone https://huggingface.co/uclanlp/plbart-java-cs git clone https://huggingface.co/uclanlp/plbart-cs-java cd ../.. </code></pre> <h3>Step 1: Preprocessing and Prompting:</h3> Each script in each <code>clm-apr/[model]</code> folder connects one or more models with one dataset. These scripts follow the template: [benchmark]_[model]_[technique].py. The scripts first create an <code>[model]_input.json</code> file with the preprocessed input. Then generate outputs based on that file with one or more models. For example: <pre><code>cd clm-apr/plbart python quixbugs_plbart_round.py # Generates input for QuixBugs and generate patches using Java<->C# RTT. python quixbugs_plbart_round_nl.py # Generates input for QuixBugs and generate patches using Java<->NL RTT. </code></pre> Optionally, use argument <code>--device_map cpu</code> if you wish to run the script on CPU, for example: <pre><code>python quixbugs_plbart_round.py --device_map cpu </code></pre> Otherwise, the script will be run on all available CUDA GPU’s. We have commented the generation of inputs in the scripts. Users are free to uncomment this method and try for themselves. It is easily recognizable by their name template <code>[model]_[benchmark]_input()</code>. In the previous case: <pre><code>quixbugs_plbart_input() </code></pre> <h3>Step 2 and 3: Round Trip Translation and Postprocessing</h3> These steps are also included in the [benchmark]_[model]_[technique].py script mentioned above. They are modularized in the method recognizable by their name template [model]_[benchmark]_output(). For example: <pre><code>quixbugs_incoder_output() </code></pre> This method: <ol> <li>Reads the input json file.</li> <li>Generates outputs through the LLM.</li> <li>Postprocess the output (extract the patch, clean up extra token, etc.).</li> <li>Creates [model]_output_[technique]_[extra].json.</li> </ol> The last 3 steps are repeated according to the number of runs set to performed (10 in our experiments). Each run will produce a different file with the seed used in its generation. For example, <code>quixbugs\_plbart\_round.py</code> and <code>quixbugs\_plbart\_round_nl.py</code> scripts create: <pre><code>clm-apr/quixbugs/plbart_results/run_0/plbart_java_cs_java_output_round_csharp_batch.json clm-apr/quixbugs/plbart_results/run_0/plbart_java_nl_java_output_round_nl_batch.json </code></pre> <h3>Step 4: Evaluation of RTT Results:</h3> The last step evaluates the generated outputs against the test-suites of each benchmark. This script reads the previous outputs files and generates a new one with the results of the test for one model. Furthermore, it connects with the WandB tool to calculate metrics and send them to analyze. Following the previous examples, to validate the results previously obtained, we execute the following: <pre><code>cd clm-apr/quixbugs python validate_quixbugs_parallel.py </code></pre> Given the included JSON, this script would create: <pre><code>clm-apr/quixbugs/plbart_results/run_0/plbart_java_cs_java_validate_round_csharp_batch.json </code></pre> We have disabled WandB in the script to allow users to try the script first. However, it can be easily activated by changing the parameter <code>mode="disabled"</code> to <code>mode="online"</code>. We have set the variable <code>total_runs = 1</code>, as well as <code>input_file</code> and <code>output_file</code> to the results included. They should be modified accordingly to validate more runs or to validate other files/models. <h3>Included Results</h3> We include two CSV files obtained through WandB. <pre><code>'data_cleaned_grouped.csv': Aggregated metrics of the 25 outputs for all runs. 'full_data_all_runs.csv': All metrics for all outputs on all runs. </code></pre> <h2>Changelog</h2> <ul> <li>v1.0 - updates corresponding to the accepted version of the manuscript in TOSEM</li> <li>v0.1 - initial replication package corresponding to v1 of arXiv deposit: includes raw data, code, and example outputs.</li> </ul> <h2>References</h2> Jiang, N.; Liu, K.; Lutellier, T.; and Tan, L. 2023. Impact of Code Language Models on Automated Program Repair. In 45th International Conference on Software Engineering (ICSE), 1430–1442. IEEE. ISBN 978-1-66545-701-9. <div> </div>

opencc-by-4.0Jan 2024View details →

zenodo44/100

TRANSIT long-distance multimodal trips model results - a Spanish case study

The files downloaded present the results per scenario considered obtained with the agent-based model developed for the assessment of the Intermodal Timetable Synchronisation solution proposed in the scope of the TRANSIT project (<a href="https://www.transit-h2020.eu/">https://www.transit-h2020.eu/</a>). An agent-based modelling framework called <a href="https://github.com/StefanoPenazzi/jtap/tree/main">J-TAP</a> has been developed and put at work to implement a Spanish long-distance multimodal trips model. The enhanced version of J-TAP used in this work can be found on a <a href="https://github.com/NommonSolutionsAndTechnologies/jtap">github repository</a>. The case study is focused on modelling the long-distance travel patterns of the residents in the Valencia (Spain) area. The destinations considered include the whole of Spain. The period under study is a full year from March 2019 to February 2020 (both inclusive).The files are structured in three different scenarios: <ol> <li>CS01 - Baseline. The current state of the network is considered and the actual long-distance travel patterns are obtained.</li> <li>CS02 - HSR connection with Madrid-Barajas airport. The long-distance travel patterns are modelled with hard measures, the high-speed rail is connected to Madrid-Barajas airport.</li> <li>CS03 - HSR connection with Madrid-Barajas airport and timetable synchronisation. The effects of the timetable synchronisation are modelled.</li> </ol> Each scenario includes the following files: <ul> <li>ctapModelParameters. A folder containing all the information extracted from the <a href="https://neo4j.com/product/graph-data-science/?utm_program=emea-prospecting&utm_source=google&utm_medium=cpc&utm_campaign=emea-search-offers&utm_adgroup=dynamic&utm_content=dynamic&utm_placement=&utm_network=g&gclid=Cj0KCQiAwJWdBhCYARIsAJc4idAo4CEi9lU8TXwmBym8MNHpEIZHPBs3x_4phxbu76y1XKbYlFoZCjIaAiGhEALw_wcB">neo4j</a> graph database created to model the multimodal network and the agents. J-TAP contains packages that simplify network creation in the graph database. This information is stored in .json files (e.g., "Os2DsTravelCostParameter.json" contains the generalised cost for each OD pair and transport mode, "AttractivenessParameter.json" contains the attractiveness by destination, activity, time of the year and agent, etc.). The solver included in the J-TAP framework uses this information to calculate the agents plans.</li> <li>population.json. The result of the J-TAP optimisation. It includes the fitness value for each agent plan evaluated during the J-TAP execution. The best plan for each agent is selected as the plan performed by the agent. An agent plan includes: <ul> <li>activities - Sequence of activities.</li> <li>locations - Sequence of locations</li> <li>ts - Initial time of the activity</li> <li>te - Final time of the activity</li> </ul> </li> <li>LinkTimeFlow.csv. It is obtained after processing the previous file. It contains the number of agents using each link in the network (i.e., road, rail, air and cross links) in each time interval. The first column represents the link id and the rest of columns indicates the number of agents in each interval.</li> </ul> The J-TAP simulation framework is explained in detail in TRANSIT's deliverable <a href="http://www.nommon-files.es/transit/TRANSIT-D5.1_Modelling_Framework_v02.00.00.pdf">D5.1. TRANSIT Modelling and Simulation Framework</a> and the complete description of the case studies and scenarios tested is included in TRANSIT's deliverable <a href="http://www.nommon-files.es/transit/TRANSIT-D6.1_Assessment_of_Intermodal_Concepts_00.02.00.pdf">D6.1. Impact Assessment of New Intermodal Concepts and Passenger Information Services: Conclusions and Recommendations</a>. Thank you for downloading the dataset! It would be very helpful if you share your view on the data show with us.

opencc-by-4.0Dec 2022View details →

zenodo44/100

CSV Trip Advisor restaurant NYC test

The CSV distribution of the Trip Advisor Newyork City restaurants Dataset used in the NeIC spring 2023 FAIR training.

opencc-byJun 2023View details →

edi44/100

Ecology and Evolutionary Biology Field Trip at the Coweeta Hydrologic Laboratory (Watershed 18) in 2004: Aquatic Invertebrates (Adult) data

As part of an educational project, we intend to conduct a short "bioblitz" that will focus on 4 major groups of organisms: (1) vertebrates, especially birds and salamanders; (2) the local flora, especially fungi, trees, and any herbaceous species present this early; (3) aquatic invertebrates; (4) terrestrial invertebrates. Data will be compared to available lists of taxa from Coweeta and Great Smoky Mountains National Park.

openCustomJan 2020View details →

zenodo40/100

Рис. 1. 1, 2 — Отчет А. А. ЕмеΛьянова о поезΑке по рекам Ботчи и Коппи в 1925 гоΑу, разΑеΛ Lepidoptera. ОпреΑеΛения А. К. МоΛьтрехта Fig. 1. 1, 2 — A. A. Yemelyanov's report about the trip along the rivers Botchi and Koppi in 1925, Section: Lepidoptera. Definitions by A. K. Moltrecht in Hesperioidea And Papilionoidea (Lepidoptera) Of Coniferous Forests From The Nature Reserve Botchinskii

Рис. 1. 1, 2 — Отчет А. А. ЕмеΛьянова о поезΑке по рекам Ботчи и Коппи в 1925 гоΑу, разΑеΛ Lepidoptera. ОпреΑеΛения А. К. МоΛьтрехта Fig. 1. 1, 2 — A. A. Yemelyanov's report about the trip along the rivers Botchi and Koppi in 1925, Section: Lepidoptera. Definitions by A. K. Moltrecht

opencc-by-4.0Jul 2019View details →

zenodo40/100

Road distances and trip duration matrix for Brazilian municipalities

This dataset presents a matrix with road distance and travel duration estimates for all the trips combination among the Brazilian municipalities. More details about the methodology are available <a href="https://rfsaldanha.github.io/data-projects/brazil_road_distances.html" target="_blank" rel="noopener">here</a>. This version was generated considering the road network at the OSRM project  on May 2024. Variable dictionary <ul> <li>orig: Code of the municipality of origin (IBGE 7-digits) </li> <li>dest: Code of the municipality of destiny (IBGE 7-digits) </li> <li>dist: Road distance of the shortest route, in meters</li> <li>dur: Travel time estimation, in minutes.</li> </ul> Files <ul> <li>dist_brasil.rds : R serialized object</li> <li>dist_brasil.parquet : Parquet format</li> <li>dist_brasil.zip : Compressed CSV file. Semi-colon ( ; ) field delimiter and point ( . ) as decimal separator</li> </ul>

opencc-by-4.0May 2024View details →

zenodo40/100

Dataset: Tripadvisor, Inc. (TRIP) Stock Performance

This dataset provides historical stock market performance data for specific companies. It enables users to analyze and understand the past trends and fluctuations in stock prices over time. This information can be utilized for various purposes such as investment analysis, financial research, and market trend forecasting.

opencc-zeroJun 2024View details →

zenodo40/100

SUMO intersection model and vehicle trip data

There are two parts of the data: 1) a SUMO model of a typical intersection that consists of 4 approaches, each of which consists of 3 movements (left turn, right turn, and straight); 2) the vehicle trip information data generated by SUMO under different volume files, which is used to train the intersection signal control algorithm. The SUMO model contains five ".xml" files (node, edge, connection, net, and additional files) which are used to construct and configure the model. One can refer to the official SUMO tutorial for the format and functions of these files: (<a href="https://sumo.dlr.de/wiki/Tutorials/Hello_Sumo">https://sumo.dlr.de/wiki/Tutorials/Hello_Sumo</a>)  The vehicle trip data is generated by SUMO as an output (which is specified in ".sumocfg" file). One can refer to the official tutorial (<a href="https://sumo.dlr.de/wiki/Simulation/Output/TripInfo">https://sumo.dlr.de/wiki/Simulation/Output/TripInfo</a>) to understand the data format. Note that readers capable to read ".xml" files like Notepad++ are required to read the SUMO model and vehicle trip data.

opencc-by-4.0Jul 2019View details →

dryad40/100

Partner intrinsic characteristics influence foraging trip duration, but not coordination of care in wandering albatrosses Diomedea exulans

1. Long-lived monogamous species gain long-term fitness benefits by equalising effort during bi-parental care. For example, many seabird species coordinate care by matching foraging trip durations within pairs. 2. Age affects coordination in some seabird species; however, the impact of other intrinsic traits, including personality, on potential intraspecific variation in coordination strength is less well understood. 3. The impacts of pair members' intrinsic traits on trip duration and coordination strength were investigated using data from saltwater immersion loggers deployed on 71 pairs of wandering albatrosses Diomedea exulans. These were modelled against pair members' age, boldness and their partner's previous trip duration. 4. At the population level, the birds exhibited some coordination of parental care that was of equal strength during incubation and chick-brooding. However, there was low variation in coordination between pairs and coordination strength was unaffected by the birds' boldness or age in either breeding stage. Surprisingly, during incubation, foraging trip duration was mainly driven by partner traits, as birds that were paired to older and bolder partners took shorter trips. During chick-brooding, shorter foraging trips were associated with greater boldness in focal birds and their partners, but age had no effect. 5. These results suggest that an individual's assessment of their partner's capacity or willingness to provide care may be a major driver of trip duration, thereby highlighting the importance of accounting for pair behaviour when studying parental care strategies.

opencc-zeroNov 2022View details →

zenodo40/100

Dataset for: "Reducing OpenMP to FPGA Round-trip Times with Predictive Modelling"

This archive contains the samples generated for the conference paper "Reducing OpenMP to FPGA Round-trip Times with Predictive Modelling" (In Proc. 18th Intl. Workshop on OpenMP (IWOMP), Chattanooga, TN, Sept. 2022, Springer LNCS vol. 13527, pp. 94–108, <a href="https://doi.org/10.1007/978-3-031-15922-0_7">https://doi.org/10.1007/978-3-031-15922-0_7</a>). Abstract: Recent works aimed at expanding the target offloading capabilities of OpenMP to FPGA platforms. While enabling the easy construction of heterogeneous systems, the approach has to face a major hurdle: by blurring the line between software and hardware development, it forces software developers to consider hardware limitations. This can be difficult through the abstractions that OpenMP introduces over the generated hardware. The high level synthesis tools used by OpenMP compilers to generate hardware already offer predictions on hardware usage. Their value for OpenMP offloading however is questionable. This paper is based on the data mining we conducted on thousands of kernel variations. It demonstrates and proofs under which circumstances these predictions can be trusted in the context of OpenMP to FPGA offloading and concludes by showing how to derive runtime performance predictions from them. The model we present can be used without experience in hardware development and quickly predicts runtime on our benchmarks with an average Pearson correlation of 0.897. This knowledge allows developers to make fast, informed design decisions.

openother-openSep 2022View details →

zenodo40/100

Data and code from: Three decades of wildlife-vehicle collisions in a protected area: main roads and long-distance commuting trips to migratory prey increase spotted hyena roadkills in the Serengeti

This is the first release. Potential updates will be available on GitHub: <a href="https://github.com/MarwanNaciri/Three_decades_of_spotted_hyena_roadkill_in_a_protected_area">https://github.com/MarwanNaciri/Three_decades_of_spotted_hyena_roadkill_in_a_protected_area</a>

openother-openFeb 2023View details →

zenodo40/100

Estimation of Freight Trip Produced and Attracted in NYC.

This dataset is part of a project under the US DOT (No. 69A3551747124) titled "Quantifying and visualizing city truck route network efficiency using a virtual test bed." The file fta_equi_gateways_3_dig_naics.csv yields the number of freight trips attracted at the equity zone level (gateways included) and at 3-digit NAICS disaggregation for the city of New York. The file ftp_equi_gateways_3_dig_naics.csv yields the number of freight trips produced at the equity zone level (gateways included) and at 3-digit NAICS disaggregation for the city of New York. The file ct2010_ct2020_equi_zone.csv gives the equivalencies between the census tracts 2010, the census tracts 2020, and the New York City equitable zoning (more information available <a href="https://zenodo.org/record/7699609#.ZAaKaHbMKUk">here</a>).

opencc-by-4.0Mar 2023View details →

zenodo40/100

RDF Turtle Trip Advisor restaurant NYC test

The RDF Turtle distribution of the Trip Advisor Newyork City restaurants Dataset used in the NeIC spring 2023 FAIR training.

opencc-by-4.0Jun 2023View details →

zenodo40/100

"The sound comes from a meadow in the Sierra Nevada Mountains in California. The meadow is at an elevation of 2400 meters near a mountain named Olancha Peak, which is 3700 meters in altitude. Ihave a group of friends with which Ibackpack (trek) into the mountains. Our goal was to spend some time in the mountains and hike to the top of Olancha Peak (…) By the time we reached the meadow, we were in a forest and there was still snow on the ground in some places. We took the trip in June of 2006. The Sierra Nevada Mountains are a large mountain range. Much of the range is protected by national parks or preserved areas we call 'wilderness areas' (…) Ihave been backpacking for nearly 40 years and Iwill hopefully continue with this challenging activity for 40 years more! Many of my friends are much younger than Iam and it gives me much satisfaction to be able to have as much or more stamina for this activity than they have! When we are on these trips, we hike up peaks, catch fish, drink some whiskey around campfires and enjoy our time in the beautiful solitude. My memories of this trip were of the steep, hot hike from the desert to the cool meadow; the overall beauty of the nature, the absolute solitude of our campsite near the meadow; the strenuous hike to the top of Olancha Peak; the camaraderie of my friends; and, of course the sound of the frogs in the meadow. The frog sounds were astounding to me and Iwould listen in awe of the creature's instinctual desire to reproduce and continue the existence of their kind. Surely there were different species in the meadow for some of the frog sounds were different than others. The sounds only occurred after the Sun went down for the evening. Istood next to the creek in the meadow and recorded the sounds using my digital camera." [Peter/plentz1960]16 in Collecting Sounds. Online Sharing of Field Recordings as Cultural Practice

"The sound comes from a meadow in the Sierra Nevada Mountains in California. The meadow is at an elevation of 2400 meters near a mountain named Olancha Peak, which is 3700 meters in altitude. Ihave a group of friends with which Ibackpack (trek) into the mountains. Our goal was to spend some time in the mountains and hike to the top of Olancha Peak (…) By the time we reached the meadow, we were in a forest and there was still snow on the ground in some places. We took the trip in June of 2006. The Sierra Nevada Mountains are a large mountain range. Much of the range is protected by national parks or preserved areas we call 'wilderness areas' (…) Ihave been backpacking for nearly 40 years and Iwill hopefully continue with this challenging activity for 40 years more! Many of my friends are much younger than Iam and it gives me much satisfaction to be able to have as much or more stamina for this activity than they have! When we are on these trips, we hike up peaks, catch fish, drink some whiskey around campfires and enjoy our time in the beautiful solitude. My memories of this trip were of the steep, hot hike from the desert to the cool meadow; the overall beauty of the nature, the absolute solitude of our campsite near the meadow; the strenuous hike to the top of Olancha Peak; the camaraderie of my friends; and, of course the sound of the frogs in the meadow. The frog sounds were astounding to me and Iwould listen in awe of the creature's instinctual desire to reproduce and continue the existence of their kind. Surely there were different species in the meadow for some of the frog sounds were different than others. The sounds only occurred after the Sun went down for the evening. Istood next to the creek in the meadow and recorded the sounds using my digital camera." [Peter/plentz1960]16

opencc-by-4.0Dec 2019View details →

ScienceDex guides

Understand access before you commit

These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.

Compare curated 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.

allen-brain-atlas

neuroscienceopenDocumentation, web resources, and API references are available online.

Last verified 2026-04-30Open record

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.

abode-home-cage

behavioral-neuroscienceopenThe DataShare record exposes download links for annotations, documentation, license text, and the zipped per-snippet data directory.

Last verified 2026-04-30Open record

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.

dandi-nwb

electrophysiologyopenPublished Dandiset metadata and archive endpoints are available through the production DANDI API.

Last verified 2026-04-30Open record

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.

ibl

behavioral-neuroscienceopenPublic sessions can be searched and loaded from the IBL public data server through ONE.

Last verified 2026-04-29Open record

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.

openneuro

neuroscienceopenPublished datasets are available on demand over the internet.

Last verified 2026-04-29Open record