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.
363
datasets available to search
ShareScore release 0.9.0
Dataset results
363 results for “travel”
Raw data : Observation of two-mode squeezing in a traveling wave parametric amplifier
<p>The raw data used to generate figures presented in the articles is available as qcodes datasets.</p> <p>Fig 2<br> The 100 million quadrature points used to construct statistics in figure 2 are stored at 10 datasets with ids 1 to 10, each containing 10 million points. The data was split in multiple databases to ease storage and processing.</p> <p>Fig 3<br> The pump phase sweep in figure 2 was recorded at 25 points from 0 to pi. Each sweep step is stored as a dataset in the database starting from run id 11 to 35, corresponding to 0 to pi in order.</p> <p>Fig 4<br> The quadratures recorded at delta values 20, 50, 100, 150 and 200 are stored with run id 36 to 40, respectively.</p> <p>Fig SNTJ gain calibration<br> The noise spectrum as a function of voltage applied to SNTJ is stored for frequencies corresponding to the delta values 20, 50, 100, 150 and 200, from run id 41 to 45, respectively.</p>
TRAVEL: A Dataset with Toolchains for Test Generation and Regression Testing of Self-driving Cars Software
<p><strong>Introduction</strong></p> <p>This repository hosts the Testing Roads for Autonomous VEhicLes (TRAVEL) dataset. TRAVEL is an extensive collection of virtual roads that have been used for testing lane assist/keeping systems (i.e., driving agents) and data from their execution in state of the art, physically accurate driving simulator, called <a href="https://www.beamng.tech/">BeamNG.tech</a>. Virtual roads consist of sequences of <strong>road points</strong> interpolated using Cubic splines.</p> <p>Along with the data, this repository contains instructions on how to install the tooling necessary to generate new data (i.e., test cases) and analyze them in the context of test regression. We focus on test selection and test prioritization, given their importance for developing high-quality software following the DevOps paradigms.</p> <p>This dataset builds on top of our previous work in this area, including work on</p> <ul> <li>test generation (e.g., <a href="https://doi.org/10.1145/3293882.3330566">AsFault</a>, <a href="https://doi.org/10.1145/3368089.3409730">DeepJanus</a>, and <a href="https://doi.org/10.1145/3460319.3464811">DeepHyperion</a>) and the SBST CPS tool competition (<a href="https://doi.org/10.1109/SBST52555.2021.00011">SBST2021</a>),</li> <li>test selection: <a href="https://arxiv.org/abs/2111.04666">SDC-Scissor</a> and related <a href="https://github.com/ChristianBirchler/sdc-scissor">tool</a></li> <li>test prioritization: <a href="https://arxiv.org/abs/2107.09614">automated test cases prioritization work for SDCs</a>.</li> </ul> <p><strong>Dataset Overview</strong></p> <p>The TRAVEL dataset is available under the <code>data</code> folder and is organized as a set of <em>experiments</em> folders. Each of these folders is generated by running the <code>test-generator</code> (see below) and contains the configuration used for generating the data (<code>experiment_description.csv</code>), various statistics on generated tests (<code>generation_stats.csv</code>) and found faults (<code>oob_stats.csv</code>). Additionally, the folders contain the raw test cases generated and executed during each experiment (<code>test.<TEST_ID>.json</code>).</p> <p>The following sections describe what each of those files contains.</p> <p>Experiment Description</p> <p>The <code>experiment_description.csv</code> contains the settings used to generate the data, including:</p> <ul> <li><strong>Time budget</strong>. The overall generation budget in hours. This budget includes both the time to generate and execute the tests as driving simulations.</li> <li><strong>The size of the map</strong>. The size of the squared map defines the boundaries inside which the virtual roads develop in meters.</li> <li><strong>The test subject</strong>. The driving agent that implements the lane-keeping system under test. The TRAVEL dataset contains data generated testing the BeamNG.AI and the end-to-end Dave2 systems.</li> <li><strong>The test generator</strong>. The algorithm that generated the test cases. The TRAVEL dataset contains data obtained using various algorithms, ranging from naive and advanced random generators to complex evolutionary algorithms, for generating tests.</li> <li><strong>The speed limit</strong>. The maximum speed at which the driving agent under test can travel.</li> <li><strong>Out of Bound (OOB) tolerance</strong>. The test cases' oracle that defines the tolerable amount of the ego-car that can lie outside the lane boundaries. This parameter ranges between 0.0 and 1.0. In the former case, a test failure triggers as soon as any part of the ego-vehicle goes out of the lane boundary; in the latter case, a test failure triggers only if the entire body of the ego-car falls outside the lane.</li> </ul> <p>Experiment Statistics</p> <p>The <code>generation_stats.csv</code> contains statistics about the test generation, including:</p> <ul> <li><strong>Total number of generated tests</strong>. The number of tests generated during an experiment. This number is broken down into the number of <strong>valid tests</strong> and <strong>invalid tests</strong>. Valid tests contain virtual roads that do not self-intersect and contain turns that are not too sharp.</li> <li><strong>Test outcome</strong>. The test outcome contains the number of <strong>passed tests</strong>, <strong>failed tests</strong>, and <strong>test in error</strong>. Passed and failed tests are defined by the OOB Tolerance and an additional (implicit) oracle that checks whether the ego-car is moving or standing. Tests that did not pass because of other errors (e.g., the simulator crashed) are reported in a separated category.</li> </ul> <p>The TRAVEL dataset also contains statistics about the failed tests, including the overall number of failed tests (<strong>total oob</strong>) and its breakdown into OOB that happened while driving <strong>left</strong> or <strong>right</strong>. Further statistics about the diversity (i.e., <strong>sparseness</strong>) of the failures are also reported.</p> <p>Test Cases and Executions</p> <p>Each <code>test.<TEST_ID>.json</code> contains information about a test case and, if the test case is valid, the data observed during its execution as driving simulation.</p> <p>The data about the test case definition include:</p> <ul> <li><strong>The road points</strong>. The list of points in a 2D space that identifies the center of the virtual road, and their interpolation using cubic splines (<strong>interpolated_points</strong>)</li> <li><strong>The test ID</strong>. The unique identifier of the test in the experiment.</li> <li><strong>Validity flag and explanation</strong>. A flag that indicates whether the test is valid or not, and a brief message describing why the test is not considered valid (e.g., <code>the road contains sharp turns</code> or <code>the road self intersects</code>)</li> </ul> <p>The test data are organized according to the following JSON Schema and can be interpreted as <code>RoadTest</code> objects provided by the <a href="https://github.com/se2p/tool-competition-av/blob/main/code_pipeline/tests_generation.py">tests_generation.py</a> module.</p> <pre><code>{ "type": "object", "properties": { "id": { "type": "integer" }, "is_valid": { "type": "boolean" }, "validation_message": { "type": "string" }, "road_points": { §\label{line:road-points}§ "type": "array", "items": { "$ref": "schemas/pair" }, }, "interpolated_points": { §\label{line:interpolated-points}§ "type": "array", "items": { "$ref": "schemas/pair" }, }, "test_outcome": { "type": "string" }, §\label{line:test-outcome}§ "description": { "type": "string" }, "execution_data": { "type": "array", "items": { "$ref" : "schemas/simulationdata" } } }, "required": [ "id", "is_valid", "validation_message", "road_points", "interpolated_points" ] } </code></pre> <p>Finally, the <strong>execution data</strong> contain a list of timestamped state information recorded by the driving simulation. State information is collected at constant frequency and includes absolute position, rotation, and velocity of the ego-car, its speed in Km/h, and control inputs from the driving agent (steering, throttle, and braking). Additionally, execution data contain OOB-related data, such as the lateral distance between the car and the lane center and the OOB percentage (i.e., how much the car is outside the lane).</p> <p>The simulation data adhere to the following (simplified) JSON Schema and can be interpreted as Python objects using the <a href="https://github.com/se2p/tool-competition-av/blob/main/self_driving/simulation_data.py">simulation_data.py</a> module.</p> <pre><code>{ "$id": "schemas/simulationdata", "type": "object", "properties": { "timer" : { "type": "number" }, "pos" : { "type": "array", "items":{ "$ref" : "schemas/triple" } } "vel" : { "type": "array", "items":{ "$ref" : "schemas/triple" } } "vel_kmh" : { "type": "number" }, "steering" : { "type": "number" }, "brake" : { "type": "number" }, "throttle" : { "type": "number" }, "is_oob" : { "type": "number" }, "oob_percentage" : { "type": "number" } §\label{line:oob-percentage}§ }, "required": [ "timer", "pos", "vel", "vel_kmh", "steering", "brake", "throttle", "is_oob", "oob_percentage" ] } </code></pre> <p><strong>Dataset Content</strong></p> <p>The TRAVEL dataset is a lively initiative so the content of the dataset is subject to change. Currently, the dataset contains the data collected during the SBST CPS tool competition, and data collected in the context of our recent work on test selection (<a href="https://arxiv.org/abs/2111.04666">SDC-Scissor work</a> and <a href="https://github.com/ChristianBirchler/sdc-scissor">tool</a>) and test prioritization (<a href="https://arxiv.org/abs/2107.09614">automated test cases prioritization work for SDCs</a>).</p> <p>SBST CPS Tool Competition Data</p> <p>The data collected during the SBST CPS tool competition are stored inside <code>data/competition.tar.gz</code>. The file contains the test cases generated by <a href="https://github.com/mahshidhelali/tool-competition-av">Deeper</a>, <a href="https://github.com/ERATOMMSD/frenetic-sbst21">Frenetic</a>, <a href="https://github.com/TayYim/adafrenetic-sbst22">AdaFrenetic</a>, and <a href="https://github.com/alessiogambi/swat-sbst2021">Swat</a>, the <strong>open-source</strong> test generators submitted to the competition and executed against BeamNG.AI with an aggression factor of 0.7 (i.e., conservative driver).</p> <table> <thead> <tr> <th>Name</th> <th>Map Size (m x m)</th> <th>Max Speed (Km/h)</th> <th>Budget (h)</th> <th>OOB Tolerance (%)</th> <th>Test Subject</th> </tr> </thead> <tbody> <tr> <td>DEFAULT</td> <td>200 × 200</td> <td>120</td> <td>5 (real time)</td> <td>0.95</td> <td>BeamNG.AI - 0.7</td> </tr> <tr> <td>SBST</td> <td>200 × 200</td> <td>70</td> <td>2 (real time)</td> <td>0.5</td> <td>BeamNG.AI - 0.7</td> </tr> </tbody> </table> <p>Specifically, the TRAVEL dataset contains 8 repetitions for each of the above configurations for each test generator totaling 64 experiments.</p> <p>SDC Scissor</p> <p>With SDC-Scissor we collected data based on the <a href="https://github.com/ERATOMMSD/frenetic-sbst21">Frenetic</a> test generator. The data is stored inside <code>data/sdc-scissor.tar.gz</code>. The following table summarizes the used parameters.</p> <table> <thead> <tr> <th>Name</th> <th>Map Size (m x m)</th> <th>Max Speed (Km/h)</th> <th>Budget (h)</th> <th>OOB Tolerance (%)</th> <th>Test Subject</th> </tr> </thead> <tbody> <tr> <td>SDC-SCISSOR</td> <td>200 × 200</td> <td>120</td> <td>16 (real time)</td> <td>0.5</td> <td>BeamNG.AI - 1.5</td> </tr> </tbody> </table> <p>The dataset contains 9 experiments with the above configuration. For generating your own data with SDC-Scissor follow the instructions in its <a href="https://github.com/ChristianBirchler/sdc-scissor">repository</a>.</p> <p><strong>Dataset Statistics</strong></p> <p>Here is an overview of the TRAVEL dataset: generated tests, executed tests, and faults found by all the test generators grouped by experiment configuration. Some 25,845 test cases are generated by running 4 test generators 8 times in 2 configurations using the SBST CPS Tool Competition code pipeline (SBST in the table). We ran the test generators for 5 hours, allowing the ego-car a generous speed limit (120 Km/h) and defining a high OOB tolerance (i.e., 0.95), and we also ran the test generators using a smaller generation budget (i.e., 2 hours) and speed limit (i.e., 70 Km/h) while setting the OOB tolerance to a lower value (i.e., 0.85). We also collected some 5, 971 additional tests with SDC-Scissor (SDC-Scissor in the table) by running it 9 times for 16 hours using Frenetic as a test generator and defining a more realistic OOB tolerance (i.e., 0.50).</p> <p><strong>Generating new Data</strong></p> <p>Generating new data, i.e., test cases, can be done using the <a href="https://github.com/se2p/tool-competition-av">SBST CPS Tool Competition pipeline</a> and the driving simulator <a href="https://www.beamng.tech/">BeamNG.tech</a>.</p> <p>Extensive instructions on how to install both software are reported inside the SBST CPS Tool Competition pipeline <a href="https://github.com/se2p/tool-competition-av/blob/main/documentation/README.md">Documentation</a>; therefore, below we only summarize the overall installation process.</p> <p>Installation</p> <ol> <li> <p>Install Python 3.7. (We tested the code using 3.7.9, so we suggest to install that version of Python)</p> </li> <li> <p>Clone the <a href="https://github.com/se2p/tool-competition-av">SBST CPS Tool Competition pipeline</a></p> </li> <li> <p>Request a (free) copy of the driving simulator at <a href="https://register.beamng.tech/">https://register.beamng.tech</a> and, after receiving the registration key file (<code>tech.key</code>) and the download link, download and install the latest distribution of the software (<code>0.24</code>).</p> </li> <li> <p>Create a python virtual environment (<code>python -m venv .venv</code>) inside the root of the SBST CPS Tool Competition pipeline and activate it. Please, be sure to call the virtual environment exactly <code>.venv</code> and place it in the correct position as the scripts to collect new data assume this setup.</p> </li> <li> <p>Install inside the virtual environment all the SBST CPS Tool Competition pipeline requirements (<code>pip install -r requirements.txt</code>).</p> </li> </ol> <p>If you have successfully setup the python environment, activate the virtual environment, and run</p> <pre><code>python.exe competition.py --help </code></pre> <p>and check that the command outputs the <a href="https://github.com/se2p/tool-competition-av/blob/main/documentation/GUIDELINES.md#technical-considerations">usage</a> of the SBST CPS Tool Competition pipeline.</p> <p>Data Collection</p> <p>Collecting new data is as simple as starting the SBST CPS Tool Competition pipeline with suitable parameters for test generation (<code>--time-budget</code>, <code>--module-name</code>, <code>--module-path</code> and <code>--class-name</code>), test executor (<code>--executor</code>), and test definition (<code>--map-size</code>, <code>--speed-limit</code> and <code>--oob-tolerance</code>).</p> <p>To ease the collection of new data, we include the (PowerShell) scripts we used to create the current TRAVEL dataset. Those scripts can be found inside the <code>data-collection</code> folder and are named after the test generator and configuration they implement. For instance, <code>Frenetic-DEFAULT.ps1</code> will execute the Frenetic test generator in the DEFAULT configuration, whereas <code>Deeper-SBST.ps1</code> will execute the Deeper test generation in the SBST configuration. The description of these configurations is reported in the <a href="https://github.com/se2p/msr-travel-dataset#sbst-cps-tool-competition-data">table above</a>).</p> <p>To run those scripts, open a PowerShell, <code>cd</code> to the folder containing the script (<code>data-collection</code>), and invoke the script you want. Assuming you have configured the SBST CPS Tool Competition pipeline as described above, the scripts will start the code pipeline and the BeamNG.tech driving simulator.</p> <p>Once the run is finished, you will find the results under the <code>results</code> folder inside the SBST CPS Tool Competition pipeline project. The results of each experiment are stored in a uniquely named folder that clearly indicates the test generator used to produce them (see <a href="https://github.com/se2p/msr-travel-dataset#dataset-overview">above</a> for the detailed description of the produced results).</p> <p><strong>Data Usage</strong></p> <p>So far, the data contained in the TRAVEL dataset have been used for benchmarking test generators as well as for optimizing regression testing in the context of Self-driving car software.</p> <p>We used the TRAVEL to study the problem of test generation from different perspectives.</p> <p>In the last edition of the <a href="https://doi.org/10.1109/SBST52555.2021.00011">SBST Tool Challenge</a>, we answer the question <em>"How efficient and effective are the existing test generators for SDCs?"</em>. We assess test generation efficiency by counting how many tests are produced by each test generator within a given time budget. To assess test generation effectiveness, we count how many of the generated tests are valid and invalid.</p> <p>In a <a href="https://doi.org/10.1145/3460319.3464811">recent study</a>, we propose (along the DeepHyperion test generator) a novel approach to assess SDCs test suites adequacy by measuring the coverage of feature maps that they achieved. To do so, we extract structural and behavioral test case features from the test case descriptions and simulation data by looking at the geometrical properties describing the roads and the physical quantities describing the ego-car behavior (e.g., position, speed).</p> <p>We also answer the question <em>"How effective are the resulting tests in finding faults in SDCs?"</em>, by counting how many failures are triggered by the generated tests and how different those failures are (e.g., Left or Right OOBs). Specifically, we propose an approach to measure OOBs similarity by computing the edit distance of the road segments relevant to the corresponding failure.</p> <p><a href="https://github.com/ERATOMMSD/roadsearch">Castellano et al.</a> demonstrated that a dataset such as TRAVEL can be used to answer other interesting questions, such as <em>"Which road representation is the most suitable for generating SDCs test cases?"</em>.</p> <p>In the context of regression testing the TRAVEL dataset is also used to develop tools to select test cases that are likely to fail before executing them simulation (e.g., <a href="https://github.com/ChristianBirchler/sdc-scissor">SDC-Scissor</a>) and also to prioritize them in a single-objective and multi-objective approach by <a href="https://arxiv.org/abs/2107.09614">SDC-Prioritizer</a>.</p> <p>With SDC-Scissor we can select test cases that are more likely to fail. This allows us to answer the following research questions like "To what extent is it possible to identify safe and unsafe test scenarios for SDCs before executing them?" or "Does SDC-Scissor improve the cost-effectiveness of simulation-based testing of SDCs?" <a href="https://arxiv.org/abs/2111.04666">Khatiri et al.</a>. SDC-Scissor achieves a F1-score (between 47% and 90%) compared to a baseline in identifying failing tests and reduced the time spent running uninformative tests by 107% and 170%. <a href="https://christianbirchler.github.io/sdc_scissor_demonstration_paper.pdf">(Birchler et al.)</a></p> <p>Regarding test prioritization, the TRAVEL dataset allows us to answer the following questions: "To what extent is it possible to apply test prioritization strategies to prioritize the execution of safe and unsafe test scenarios for SDCs?", “What is the cost-effectiveness of SDC-Prioritizer compared to baseline approaches?” and “What is the overhead introduced by it?”. To address the former question, we compared the test prioritization approaches in terms of fault detection rate (i.e., how fast faults are detected during the test execution process) using Cost cognizant Average Percentage of Fault Detection (APFD𝑐) (<a href="https://doi.org/10.1145/2771783.2771788">Epitropakis et al.</a>, <a href="https://doi.org/10.1109/ICSM.1999.792604">Rothermel et al.</a>) and concluded that SDC-Prioritizer (with 82.5% APFD𝑐) significantly outperformed the baseline random and greedy test prioritization approaches <a href="https://arxiv.org/abs/2107.09614">Birchler et al.</a>. For the latter research question, we compared the time required by SDC-Prioritizer to sort tests against the time needed to run all of the tests and showed that, on average, SDC-Prioritizer needs less than 13 minutes to perform the test prioritization while running the SDC test suites takes between 16 to 106 hours. As explained in Section 3.2.3, SDC-Prioritizer uses the road features shared with TRAVEL to guide the search process towards generating test orders with the high diversity in the road shapes. The selection of best features for test prioritization was performed with the Principal component analysis (PCA) <a href="https://arxiv.org/abs/2107.09614">Birchler et al.</a>.</p>
Travel Time Statistics for Links with Locks from L&D 16 to L&D 20
<p>This is an Excel spreadsheet that contains multiple travel time performance statistics for the Upper Mississippi River from L&D 16 to L&D 20. It includes a map depicting the links in the table.</p>
Travel Time and Speed Statistics for Links Containing Locks 16 through 20
<p>This is an Excel spreadsheet that records the travel times/speeds of each trip through a lock in the range of Lock & Dam 16 through Lock & Dam 20 in the Upper Mississippi River. Each lock is part of a three sublink set: a sublink upriver from the lock, the lock itself, and a sublink downriver . A table of links used by the study, a link map, and heat maps are also included.</p>
Optimizing Nozzle Travel Time in Proton Therapy [Dataset]
<p>Dataset of instances taken into account by the paper, together with solutions and achieved computational time.</p> <p>Manuscript submitted to 2022 IEEE-CBMS.</p> <p><em>ABSTRACT - Proton therapy is an oncological therapy that is more expensive than classical radiotherapy but that is considered the gold standard in several situations. Moreover, since there is still a limited amount of delivering facilities for this techniques, it is fundamental to increase the number of treated patients over time.<br> The objective of this work is to offer an insight on the problem of the optimization of the part of the delivery time of a treatment plan that relates to the movements of the system. We denote it as the Nozzle Travel Time Problem (NTTP), in analogy with the Leaf Travel Time Problem (LTTP) in classical radiotherapy.<br> In particular this work: (i) describes a mathematical model for the delivery system and formalize the optimization problem for finding the optimal sequence of movements of the system (nozzle and bed) that satisfies the covering of the prescribed irradiation directions; (ii) provides an optimization pipeline that solves the problem for instances with an amount of irradiation directions much greater than those usually employed in the clinical practice; (iii) reports preliminary results about the effects of employing two different resolution strategies within the aforementioned pipeline, that rely on an exact Traveling Salesmna Problem (TSP) solver (Concorde) and an efficient heuristic Vehicle Routing Open-source Optimization Machine (VROOM).</em></p> <p> </p> <p>For each combination of system features (SF1, SF2, SF3) and distance metric (L1 and Linf), 50 runs (5 session by 10 runs) with prescribed fields from 5 to 100 (step 5) have been executed.</p> <p>- 'grph' folder contains GTSP and ATSP instances in GraphML and txt format.</p> <p>- 'vrinst' folder contains ATSP instances, expressed as VRP instances, in json format, to be fed into VROOM</p> <p>- 'tsps' folder contains symmetric TSP instances in TSPLIB format to be fed into Concorde</p> <p>- 'ress' folder contains result of optimizzation obtained by Concorde (.sol and .res formats) and VROOM (.json)</p> <p>all the files in these folders is named as [SF#]_[distanceMetric][[prescribedFields#]_[subrun]][Session8charsCode], so that, for example "SF3_Linf[100_9]2e275d41" represents the 100 fields result of the 9th subrun of the session with code 2e275d41, where SF3 and Linf norm have been taken into account.</p> <p>- 'resultsNPY' folder contains .npy file about computation time and computed travel time for both solvers</p> <p> </p>
Experiments with Frequency Fitness Assignment in a (1+1) EA on the Traveling Salesperson Problem
<p><strong>1. Introduction</strong></p> <p>The implementation and experimental results of the (1+1) EA with and without Frequency Fitness Assignment (FFA) to solve the <code>EUC_2D</code> Traveling Salesperson Problem (TSP) instances from <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">TSPLIB</a>.</p> <p>A TSP is defined by a fully-connected weighted graph of <code>n</code> cities. The goal is to find the overall shortest tour that visits each cities exactly once and returns to its starting point. The TSP is NP-hard. We consider 18 symmetric Euclidean instances from the well-known <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">TSPLIB</a>.</p> <p>Solutions in our work are stored in the path representation, where such a tour is encoded as a permutation <code>x</code> of the numbers <code>1</code> to <code>n</code>, each identifying a city. If a city appears at index <code>j</code> in the permutation <code>x</code>, then it will be the <code>j</code><sup>th</sup> city to be visited. This means that a tour <code>x</code> will pass the following edges: <code>(x[1], x[2])</code>, <code>(x[2], x[3])</code>, <code>(x[3], x[4])</code>, … <code>(x[n-1], x[n])</code>, <code>(x[n], x[1])</code>.</p> <p>The (1+1) EA is the most basic evolutionary algorithm and also be considered as a randomized local search. It starts with one random solution/permutation <code>xc</code> and computes its length <code>yc=f(xc)</code>. In each iteration, it applies a unary search operator <code>op</code> to obtain a new tour <code>xn=op(xc)</code> and computes its length <code>yn=f(xn)</code>. If <code>yn<=yc</code>, then it will accept the new tour and set <code>xn=xn</code> and <code>yc=yn</code>.</p> <p>FFA is a fitness assignment process that takes place before this last step in the EA. We integrate FFA into the (1+1) EA and obtain the (1+1) FEA. This algorithm uses an additional table <code>H</code> which counts, for any tour length <code>y</code>, how often it has been seen during the search so far. After the new tour <code>xn</code> is created and its objective value <code>yn</code> is computed, the (1+1) FEA sets <code>H[yc] = H[yc] + 1</code> and <code>H[yn] = H[yn] + 1</code>. It will accept <code>xn</code> if and only if <code>H[yn] <= H[yc]</code> and, only in this case, set <code>xn=xn</code> and <code>yc=yn</code>.</p> <p>We apply both EAs with two operators. <code>swap</code> exchanges two randomly chosen cities in the permutation. <code>reverse</code> reverses a randomly chosen subsequence of the tour.</p> <p><strong>2. Directory Structure</strong></p> <p>This archive contains the following directories:</p> <ul> <li><code>results_and_evaluation</code> contain the results of two experiments as well as their evaluation. <ul> <li><code>performance</code> contains the results and evaluation of the main experiment, namely the 21 runs on 18 <code>EUC_2D</code> Traveling Salesperson Problem (TSP) instances from <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">TSPLIB</a>. <ul> <li><code>results</code> is the directory with the log files</li> <li><code>evaluation</code> is a folder with the extracted evaluation and figures</li> <li><code>evaluation.py</code> is a Python script that generates all the files in <code>evaluation</code> from the data it finds in <code>results</code>. It requires the <a href="https://thomasweise.github.io/moptipy"><code>moptipy</code></a> package being installed for running.</li> </ul> </li> <li><code>H</code> contains the results of the experiment conducting single runs on the instances and gathering the data of the frequency table <code>H</code> at different objective function evaluations in the log files. <ul> <li><code>results</code> is the directory with the log files</li> <li><code>evaluation</code> is a folder with the extracted evaluation and figures</li> <li><code>evaluation.py</code> is a Python script that generates all the files in <code>evaluation</code> from the data it finds in <code>results</code>. It requires the <a href="https://thomasweise.github.io/moptipy"><code>moptipy</code></a> package being installed for running.</li> </ul> </li> </ul> </li> <li><code>source</code> contains the Python source codes needed to run the <code>performance</code> experiment. <ul> <li><code>moptipy</code> is a local copy of the <a href="https://thomasweise.github.io/moptipy"><code>moptipy</code></a> package used for our experiment.</li> <li><code>tsplib</code> contains the <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">TSPLIB</a> data. This includes the instances used in our experiments as files in text format with suffix <code>.tsp</code>. If an optimal tour is given, it is stored in a text format file with suffix <code>.opt.tour</code> and name prefix identical to the instance file. In other words, the file <code>eil51.tsp</code> contains the TSP instance <code>eil51</code> and the file <code>eil51.opt.tour</code> contains the corresponding optimal tour. Both the TSP instances and optimal tours can be downloaded from <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp/">http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp/</a>. We also include the documentation of TSPLIB in file <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp95.pdf"><code>tsp95.pdf</code></a> documenting them. We further include the <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/TSPFAQ.html">TSPLIB FAQ</a> both as HTML and PDF file (<code>tsplib_faq.html</code> and <code>tsplib_faq.pdf</code>) and the <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/STSP.html">list of known optimal tour lengths</a> as HTML and PDF file (<code>optimal_tour_lengths_of_symmetric_tsps.html</code>, <code>optimal_tour_lengths_of_symmetric_tsps.pdf</code>). Notice that, while the TSP instances we used are Euclidean, all distances are converted to integers as prescribed by the <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp95.pdf">documentation</a>.</li> </ul> </li> </ul> <p><strong>3. What algorithms are included in this experiment?</strong></p> <p>We implement the simple local search with (1+1) EA with and without Frequency Fitness Assignment. We use the common path representation for the TSP with <code>n</code> cities, which encodes each solution as a permutation of the numbers <code>1..n</code>. The value <code>i</code> at position <code>j</code>, i.e., <code>x[j] = i</code>, in such a permutation indicates that the <code>j</code><sup>th</sup> city to be visited by <code>i</code>. We implement two search operators, namely <code>reverse</code>, which reverses a subsequence of the tour, and <code>swap</code> which swaps two cities.</p> <ul> <li>(1+1) EA <ul> <li>with <code>swap</code> operator</li> <li>with <code>reverse</code> operator</li> </ul> </li> <li>(1+1) FEA, i.e., the (1+1) EA with Frequency Fitness Assignment (FFA) <ul> <li>with <code>swap</code> operator</li> <li>with <code>reverse</code> operator</li> </ul> </li> </ul> <p><strong>4. How to Run the Experiment</strong></p> <p>First, you must make sure to have all the dependencies installed that this program requires. You can do this by executing the following command in the terminal:</p> <pre><code>pip install matplotlib numba numpy pandas psutil scikit-learn</code></pre> <p>Now enter the <code>source</code> directory, i.e., the directory containing the <code>run.py</code> file, in your terminal. Depending on your system configuration and whether you run Windows or Linux, you can start the program with <em>one</em> of the commands below. (If running the first command returns with an error, just try the next one in the list.)</p> <ul> <li><code>python3 -m run</code></li> <li><code>python -m run</code></li> <li><code>python run.py</code></li> <li><code>python3 run.py</code></li> </ul> <p>Then the experiment will run. It will automatically create a sub-folder <code>results</code> in <code>source</code> and place all log files that are generated into it. Be careful: The experiment will take a long time. However, if you have multiple CPUs, you can simply start several instances of this program in independent terminals. Each instance will then conduct different runs. This also works if this folder is shared over the network, in which case you can run multiple processes on multiple PCs.</p> <p>Side note: This experiment uses the <a href="https://thomasweise.github.io/moptipy"><code>moptipy</code></a> package for implementing its algorithms, running the experiments, and gathering their results. If you want to install <code>moptipy</code> on your system instead of using the version supplied here, you can install it via <code>pip install moptipy</code>.</p> <p><strong>5. Literature</strong></p> <ul> <li>Frequency Fitness Assignment (FFA): <ol> <li>Thomas Weise, Zhize Wu, Xinlu Li, and Yan Chen. Frequency Fitness Assignment: Making Optimization Algorithms Invariant under Bijective Transformations of the Objective Function Value. <em>IEEE Transactions on Evolutionary Computation</em> 25(2):307–319. April 2021. Preprint available at <a href="http://arxiv.org/abs/2001.01416">arXiv:2001.01416v5</a> [cs.NE] 15 Oct 2020. doi:<a href="http://dx.doi.org/10.1109/TEVC.2020.3032090">10.1109/TEVC.2020.3032090</a>. Experimental results and source code are available at doi:<a href="http://doi.org/10.5281/zenodo.3899474">10.5281/zenodo.3899474</a>.</li> <li>Thomas Weise, Zhize Wu, Xinlu Li, Yan Chen, and Jörg Lässig. Frequency Fitness Assignment: Optimization without Bias for Good Solutions can be Efficient. <a href="https://arxiv.org/abs/2112.00229v4">arXiv:2112.00229v4</a> [cs.NE] 25 May 2022.</li> <li>Thomas Weise, Mingxu Wan, Ke Tang, Pu Wang, Alexandre Devert, and Xin Yao. Frequency Fitness Assignment. <em>IEEE Transactions on Evolutionary Computation (IEEE-EC)</em> 18(2):226-243, April 2014. doi:<a href="http://dx.doi.org/10.1109/TEVC.2013.2251885">10.1109/TEVC.2013.2251885</a>.</li> <li>Thomas Weise, Xinlu Li, Yan Chen, and Zhize Wu. Solving Job Shop Scheduling Problems Without Using a Bias for Good Solutions. In <em>Genetic and Evolutionary Computation Conference Companion (GECCO’21 Companion),</em> July 10-14, 2021, Lille, France. ACM, New York, NY, USA. ISBN 978-1-4503-8351-6. doi:<a href="http://doi.org/10.1145/3449726.3463124">10.1145/3449726.3463124</a>.</li> <li>Thomas Weise, Yan Chen, Xinlu Li, and Zhize Wu. Selecting a diverse set of benchmark instances from a tunable model problem for black-box discrete optimization algorithms. <em>Applied Soft Computing Journal (ASOC)</em>, 92:106269, June 2020. doi:<a href="http://dx.doi.org/10.1016/j.asoc.2020.106269">10.1016/j.asoc.2020.106269</a>.</li> <li>Thomas Weise, Mingxu Wan, Ke Tang, and Xin Yao. Evolving Exact Integer Algorithms with Genetic Programming. In <em>Proceedings of the IEEE Congress on Evolutionary Computation (CEC’14), Proceedings of the 2014 World Congress on Computational Intelligence (WCCI’14)</em>, pages 1816-1823, Beijing, China, July 6-11, 2014. Los Alamitos, CA, USA: IEEE Computer Society Press. ISBN: 978-1-4799-1488-3. doi:<a href="http://dx.doi.org/10.1109/CEC.2014.6900292">10.1109/CEC.2014.6900292</a>.</li> </ol> </li> <li>Traveling Salesperson Problem (TSP): <ol> <li>Pedro Larrañaga, Cindy M. H. Kuijpers, Roberto H. Murga, I. Inza, and S. Dizdarevic. Genetic Algorithms for the Travelling Salesman Problem: A Review of Representations and Operators. <em>Artificial Intelligence Review,</em> 13(2):129–170, April 1999. Kluwer Academic Publishers, The Netherlands. doi:<a href="https://doi.org/10.1023/A:1006529012972">10.1023/A:1006529012972</a>.</li> <li>Gerhard Reinelt. TSPLIB — A Traveling Salesman Problem Library. <em>ORSA Journal on Computing</em> 3(4):376-384. 1991. <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/</a>.</li> <li>Gerhard Reinelt. TSPLIB95. 1995. Heidelberg, Germany: Universität Heidelberg, Institut für Angewandte Mathematik. <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp95.pdf">http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/tsp95.pdf</a>.</li> <li>Thomas Weise, Raymond Chiong, Ke Tang, Jörg Lässig, Shigeyoshi Tsutsui, Wenxiang Chen, Zbigniew Michalewicz, and Xin Yao. Benchmarking Optimization Algorithms: An Open Source Framework for the Traveling Salesman Problem. <em>IEEE Computational Intelligence Magazine (CIM)</em> 9(3):40-52, August 2014. doi:<a href="http://dx.doi.org/10.1109/MCI.2014.2326101">10.1109/MCI.2014.2326101</a>.</li> <li>Eugene Leighton Lawler, Jan Karel Lenstra, Alexander Hendrik George Rinnooy Kan, and David B. Shmoys. <em>The Traveling Salesman Problem: A Guided Tour of Combinatorial Optimization.</em> Wiley Interscience. 1985.</li> <li>David Lee Applegate, Robert E. Bixby, Vasek Chvatal, and William John Cook. <em>The Traveling Salesman Problem: A Computational Study.</em> Princeton University Press. 2007.</li> <li>Gregory Z. Gutin and Abraham P. Punnen, editors. <em>The Traveling Salesman Problem and its Variations.</em> Volume 12 of Combinatorial Optimization. Kluwer Academic Publishers. 2002. doi:<a href="https://dx.doi.org/10.1007/b101971">10.1007/b101971</a>.</li> </ol> </li> <li>Software: <ol> <li>The Metaheuristic Optimization in Python Package <a href="https://thomasweise.github.io/moptipy"><code>moptipy</code></a></li> </ol> </li> </ul> <p><strong>6. License</strong></p> <p>The files in this repository are under the <a href="https://creativecommons.org/licenses/by/4.0/legalcode">Creative Commons Attribution 4.0 International</a>, with the exception of the files of <a href="http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/">TSPLIB</a> in directory <code>source/tsplib</code>, which are under copyright of their respective owner (we believe that they are in the public domain, as they are provided by many sources, included in many software packages under various open source licenses, and on many websites). The license is contained as file <code>LICENSE</code> in this archive.</p>
Successive Westward Traveling Surges Driven by Sequential Plasma-Sheet Bubble Injections
<p>The text files are RCM simulation output. The file names specify simulation time (format: hhmmss). The stored quantities are, "I","J","COLAT","ALOCT","MLT","BNDLOC","XMIN","YMIN","FTV","BMIN (northward component of magnetic field)","V (electric potential)", "BIRK_fromV(NH) (Field-aligned current)","BIRK(NH)","P(RCM),nPa", "PV_gamma (entropy)","Vtotx (the total plasma velocity included ExB drift and gradient-curvature drift)", "Vtoty","Vx_exb (ExB drift due to the electric potential)","Vy_exb","vel_x (ExB drift due to induction electric field)","vel_y","Ey","PEDLAM", "PEDPSI", "HALL", "RCM_T_p (proton temperature)","RCM_T_e (electron temperature)","RCM_N_e (electron number density)","EFLUX","EAVG","f_i_50-75","f_i_75-113","f_i_113-170","f_i_170-250","f_i_250-400","f_e_50-75","f_e_75-105","f_e_105-150","f_e_150-225","f_e_225-315","f_e_315-500","Vm"</p>
Data from: On-chip distribution of quantum information using traveling phonons
<p>Source data for Figures.</p>
Photonic integrated circuit based continuous-travelling-wave parametric amplifier
<p>Dataset for the manuscript "Photonic integrated circuit based continuous-travelling-wave parametric amplifier".</p> <p>Contains all raw data and code used to produce the Figures and Extended Data Figures in the manuscript. </p> <p> </p> <p> </p> <p> </p>
Travel chest
Travel chest, 15th century, with leather cover. Drawn from the HistoPad reconstruction of the HistoPad of the Royal castle of Blois, France. To visit Royal castle of Blois with the HistoPad, book your ticket at this link (not available today because of the sanitary situation in Europe): https://chateaublois.tickeasy.com/fr-FR/accueil Source: Objaverse 1.0 / Sketchfab
Dispersion of the folded waveguide and output power of the Travelling Wave Tube amplifier in W band.
<p>Datasets of Dispersion of the folded waveguide and beam line (Fig1) and output power (Fig 2) of the paper "Fabrication of W-band TWT for 5G small cells backhaul" for IVEC 2017.</p> <p>Both MAGIC3D and CST- Particle StudioS were used for particle in cell simulations of the whole amplifier. Both the the simulators confirmed more that than 40 W on the full band 923 – 95 GHz as shown in Fig.2 The simulations included the couplers and the RF windows. Specific simulations for the design of the electron optics, the windows and the collector were performed.</p> <p> </p> <p> </p>
Travel Times by Transportation Mode in Nairobi, Kenya
<p>This directory contains data files that describe travel times in<br> Nairobi, Kenya. Three different modes of transportation are included:</p> <p> - Walking, according to MapQuest and filled in with Google Maps where<br> MapQuest fails to find a route.</p> <p> - Driving, under normal traffic conditions.</p> <p> - Matatus, the informal public transportation network.</p> <p>The travel times are computed from a gridded origin location to a<br> collection of gridded destination locations. In the directories, each<br> file contains destination location times for a given origin location.<br> These are titled <mode>-###.csv. The CSV is organized from north to<br> south, along rows, and west to east, along columns. An additional<br> <mode>.csv file in each directory gives the organization of the<br> numbered files, again from north to south, along rows, and west to<br> east, along columns.</p> <p>There are also "extended" versions of each grid, with larger<br> destination grids for each origin point, formed by "daisy-chaining"<br> together the original destination grids.</p> <p>The directory also contains source files for working with the data:</p> <p> - calc_access.R shows how to calculate a simple mobility measure,<br> using the functions in tools_calc_access.R</p> <p> - tools_analyze.R are a more general set of functions for performing<br> arbitrary callback-based operations on the travel time data.</p> <p> - tools_calc_access.R contains underlying functions for setting up<br> access to the grids and calculating access.</p> <p> - tools_map.R contains the grid origin and destination definitions<br> and functions for plotting.</p>
Data from: Tireless travellers: Sea turtles swim continuously during long-distance movements
<p>While rest and sleep are crucial to animals, our understanding of whether and how long-distance migrants rest has been thwarted by the inability to relay high-resolution data from multi-channel loggers via satellite. We overcame these obstacles for an iconic long-distance migrator by equipping five loggerhead sea turtles (Caretta caretta) with satellite tags and data-loggers providing depth and 3-D acceleration measurements. Turtles were translocated to open-sea locations and induced to complete oceanic migrations of tens of km to return to their nesting beach performing active, oriented movements. Across a total of >600 hours of high-resolution data, we observed (i) constant flipper frequency (ca. 0.5 Hz) indicating that turtles never ceased movement, (ii) intense subsurface swimming (mostly around 1 m) for about 50% of time and (iii) deeper, less active dives up to 80 m, which were made day and night and more frequently in offshore waters. Flipper beat amplitude was much smaller in deep dives; hence the estimated energy expenditure was 37% lower on deep dives compared to subsurface swimming. These findings suggest that turtles, which can complete migrations of >2000 km, alternate between phases of intense near-surface swimming and periods of lower activity at depth, without fully resting during migration.</p>
Results of Bet-and-Run Strategies with Different Decision Makers on the Traveling Salesman Problem and the Minimum Vertex Cover Problem
<p><em><strong>Results of Bet-and-Run Strategies with Different Decision Makers on the Traveling Salesman Problem and the Minimum Vertex Cover Problem</strong></em></p> <p><strong>1. Introduction</strong></p> <p>In this repository, we provide the implementation and results of an improved generic Bet-and-Run strategy for black-box optimization.<br> The goal our new Bet-and-Run method is to obtain the best possible results within a given time budget <em>T</em> using a given black-box optimization algorithm.<br> If no prior knowledge about problem features and algorithm behavior is available, the question about how to use the time budget most efficiently arises. We propose to first start <em>n>=1</em> independent runs of the algorithm during an initialization budget <em>T1<T</em>, pausing these runs, then apply a decision maker <em>D</em> to choose <em>1<=m<n</em> runs from them (consuming <em>T2>=0</em> time units in doing so), and then continuing these runs for the remaining <em>T3=T-T1-T2</em> time units.</p> <p>In previous bet-and-run strategies, the decision maker <em>currentBest</em> would simply select the run with the best-so-far results at negligible time.<br> We propose using more advanced methods and test several different approaches, including neural networks trained or polynomials fitted on the current trace of the algorithm to predict which run may yield the best results if granted the remaining budget.<br> Applying this implementation to run "virtual experiments," one can find that this approach can yield better results than the previous methods, but also find that the `currentBest` method is a very reliable and robust baseline approach.</p> <p>Here you can find the results of such experiments on the Traveling Salesman Problem and the Minimum Vertex Cover Problem. Both betAndRun_tsp.tar.xz and betAndRun_vertex_cover.tar.xz are extracted in the scale of 30 GiB of size.</p> <p><strong>2. Copyright</strong></p> <p>The source code in this repository is under MIT License and is published in the most recent version at http://github.com/thomasWeise/betAndRun, while the results are under the Creative Commons Attribution 4.0 License.</p> <p>The code on bet-and-run (mainly under cn.edu.hfuu.iao.betAndRun) is jointly developed by Dr. Thomas Weise (http://iao.hfuu.edu.cn), tweise@hfuu.edu.cn, tweise@gmx.de) and Dr. Markus Wagner (http://cs.adelaide.edu.au/~markus/, markus.wagner@adelaide.edu.au).</p> <p>The <em>jpack</em> (http://github.com/marmakoide/jpack) code for Artificial Neural Networks, Linear Algebra, and Evolution Strategies (e.g., CMA-ES) has originally been developed by Dr. Alexandre Devert (http://www.marmakoide.org, marmakoide@hotmail.fr, and http://github.com/marmakoide), who kindly granted us the permission to include it in our repository. The code published here is a slightly modified version of his code, but the copyright and authorship remains entirely with Dr. Devert, who provides it under the MIT license at GitHub under http://github.com/marmakoide/jpack. Please contact Dr. Devert for any questions, in particular regarding licensing and (re-)distribution.</p>
Observations of low-latitude traveling ionospheric disturbances by a 630-nm airglow imager and the CHAMP satellite over Indonesia
<p>We report the first comparison of ground and satellite measurements of low-latitude traveling ionospheric disturbances (TIDs). Three TID events were simultaneously observed by a 630-nm airglow imager and the CHAMP satellite on April 30, 2006 (event 1), September 28, 2006 (event 2), and April 12, 2004 (event 3) at Kototabang, Indonesia (geographic coordinates: 0.2$^\circ$S, 100.3$^\circ$E, geomagnetic latitude: 10.6$^\circ$S). In 630-nm airglow images of all three events, there are clear southward-moving structures. Events 1 and 2 are a single pulse with horizontal scales of $\sim$500--1000 km. Event 3 shows five wave fronts with a horizontal scale size of 500--1000 km. All three TIDs are medium-scale TIDs. Horizontal wavelengths of both airglow intensity at an average emission altitude of 250 km and CHAMP neutral density variations measured at 400 km are estimated by fitting a sinusoidal function to the observed data. For events 1 and 3, estimated horizontal wavelengths are nearly equal, indicating both instruments are observing the same wave. For event 1, the CHAMP electron density mapped along the geomagnetic field line onto the airglow altitude does not show wave structure similar<br> to the airglow variation. For events 2 and 3, the relationship of electron density and airglow intensity is unclear. These results suggest that the cause of the observed TID is not caused by ionospheric plasma instability but by gravity waves in the thermosphere. According to these results, we conclude that the observed TIDs in all three cases are caused by gravity waves in the thermosphere.</p>
Helsinki Region Travel Time Matrix
<p>Helsinki Region Travel Time Matrix contains <strong>travel time and distance</strong> information for routes between all 250 m x 250 m grid cell centroids (n = 13231) in the Helsinki Region, Finland by <strong>walking</strong>, <strong>cycling,</strong> <strong>public transportation</strong> and <strong>car</strong>. The grid cells are compatible with the statistical grid cells used by Statistics Finland and the YKR (<em>yhdyskuntarakenteen seurantajärjestelmä) </em>data set. The Helsinki Region Travel Time Matrix is available for <strong>three different years</strong>:</p> <ul> <li>2018</li> <li>2015</li> <li>2013</li> </ul> <p>The data consists of travel time and distance information of the routes that have been calculated between all statistical grid cell centroids (n = 13231) by walking, cycling, public transportation and car.</p> <p>The data have been calculated for two different times of the day: 1) midday and 2) rush hour.</p> <p>The data may be used freely (under Creative Commons 4.0 licence). We do not take any responsibility for any mistakes, errors or other deficiencies in the data.</p> <p><strong>Organization of data</strong></p> <p>The data have been divided into 13231 text files according to destinations of the routes. The data files have been organized into sub-folders that contain multiple (approx. 4-150) Travel Time Matrix result files. Individual folders consist of all the Travel Time Matrices that have same first four digits in their filename (e.g. 5785xxx).</p> <p>In order to visualize the data on a map, the result tables can be joined with the MetropAccess YKR-grid shapefile (attached here). The data can be joined by using the field <strong><em>‘from_id’</em></strong> in the text files and the field <strong><em>‘YKR_ID’</em></strong> in MetropAccess-YKR-grid shapefile as a common key.</p> <p><strong>Data structure</strong></p> <p>The data have been divided into 13231 text files according to destinations of the routes. One file includes the routes from all statistical grid cells to a particular destination grid cell. All files have been named according to the destination grid cell code and each file includes 13231 rows.</p> <p>NODATA values have been stored as value -1.</p> <p>Each file consists of 17 attribute fields: 1) from_id, 2) to_id, 3) walk_t, 4) walk_d, 5) bike_f_t, 6) bike_s_t, 7) bike_d, 8) pt_r_tt, 9) pt_r_t, 10) pt_r_d, 11) pt_m_tt, 12) pt_m_t, 13) pt_m_d, 14) car_r_t, 15) car_r_d, 16) car_m_t, 17) car_m_d, 18) car_sl_t</p> <p>The fields are separated by semicolon in the text files.</p> <p><strong>Attributes</strong></p> <ul> <li><strong>from_id: </strong>ID number of the origin grid cell</li> <li><strong>to_id</strong><strong>: </strong>ID number of the destination grid cell</li> <li><strong>walk_t</strong><strong>: </strong>Travel time in minutes from origin to destination by walking</li> <li><strong>walk_d</strong><strong>: </strong>Distance in meters of the walking route</li> <li><strong>bike_f_t: </strong>Total travel time in minutes from origin to destination by fast cycling; Includes extra time (1 min) that it takes to take/return bike</li> <li><strong>bike_s_t: </strong>Total travel time in minutes from origin to destination by slow cycling; Includes extra time (1 min) that it takes to take/return bike</li> <li><strong>bike_d:</strong>Distance in meters of the cycling route</li> <li><strong>pt_r_tt</strong><strong>: </strong>Travel time in minutes from origin to destination by public transportation in rush hour traffic; whole travel chain has been taken into account including the waiting time at home</li> <li><strong>pt_r_t</strong><strong>: </strong>Travel time in minutes from origin to destination by public transportation in rush hour traffic; whole travel chain has been taken into account excluding the waiting time at home</li> <li><strong>pt_r_d</strong><strong>: </strong>Distance in meters of the public transportation route in rush hour traffic</li> <li><strong>pt_m_tt</strong><strong>: </strong>Travel time in minutes from origin to destination by public transportation in midday traffic; whole travel chain has been taken into account including the waiting time at home</li> <li><strong>pt_m_t</strong><strong>: </strong>Travel time in minutes from origin to destination by public transportation in midday traffic; whole travel chain has been taken into account excluding the waiting time at home</li> <li><strong>pt_m_d</strong><strong>: </strong>Distance in meters of the public transportation route in midday traffic</li> <li><strong>car_r_t: </strong>Travel time in minutes from origin to destination by private car in rush hour traffic; the whole travel chain has been taken into account </li> <li><strong>car_r_d</strong><strong>: </strong>Distance in meters of the private car route in rush hour traffic</li> <li><strong>car_m_t</strong><strong>: </strong>Travel time in minutes from origin to destination by private car in midday traffic; the whole travel chain has been taken into account </li> <li><strong>car_m_d</strong><strong>: </strong>Distance in meters of the private car route in midday traffic</li> <li><strong>car_sl_t: </strong>Travel time from origin to destination by private car following speed limits without any additional impedances; the whole travel chain has been taken into account </li> </ul> <p><strong>METHODS</strong></p> <p>For detailed documentation and how to reproduce the data, see <a href="https://github.com/AccessibilityRG/HelsinkiRegionTravelTimeMatrix2018">HelsinkiRegionTravelTimeMatrix2018</a> GitHub repository.</p> <p><strong>THE ROUTE BY CAR</strong> have been calculated with a dedicated open source tool called <strong>DORA</strong> (DOor-to-door Routing Analyst) developed for this project. DORA uses PostgreSQL database with PostGIS extension and is based on the pgRouting toolkit. MetropAccess-Digiroad (modified from the original Digiroad data provided by Finnish Transport Agency) has been used as a street network in which the travel times of the road segments are made more realistic by adding crossroad impedances for different road classes.</p> <p>The calculations have been repeated for two times of the day using 1) the “midday impedance” (i.e. travel times outside rush hour) and 2) the “rush hour impendance” as impedance in the calculations. Moreover, there is 3) the “speed limit impedance” calculated in the matrix (i.e. using speed limit without any additional impedances).</p> <p>The whole travel chain (“door-to-door approach”) is taken into account in the calculations:<br> 1) walking time from the real origin to the nearest network location (based on Euclidean distance),<br> 2) average walking time from the origin to the parking lot,<br> 3) travel time from parking lot to destination,<br> 4) average time for searching a parking lot,<br> 5) walking time from parking lot to nearest network location of the destination and<br> 6) walking time from network location to the real destination (based on Euclidean distance).</p> <p><strong>THE ROUTES BY PUBLIC TRANSPORTATION</strong> have been calculated by using the MetropAccess-Reititin tool which also takes into account the whole travel chains from the origin to the destination:<br> 1) possible waiting at home before leaving,<br> 2) walking from home to the transit stop,<br> 3) waiting at the transit stop,<br> 4) travel time to next transit stop,<br> 5) transport mode change,<br> 6) travel time to next transit stop and<br> 7) walking to the destination.</p> <p>Travel times by public transportation have been optimized using 10 different departure times within the calculation hour using so called Golomb ruler. The fastest route from these calculations are selected for the final travel time matrix.</p> <p><strong>THE ROUTES BY CYCLING</strong> are also calculated using the DORA tool. The network dataset underneath is MetropAccess-CyclingNetwork, which is a modified version from the original Digiroad data provided by Finnish Transport Agency. In the dataset the travel times for the road segments have been modified to be more realistic based on Strava sports application data from the Helsinki region from 2016 and the bike sharing system data from Helsinki from 2017.</p> <p>For each road segment a separate speed value was calculated for slow and fast cycling. The value for fast cycling is based on a percentual difference between segment specific Strava speed value and the average speed value for the whole Strava data. This same percentual difference has been applied to calculate the slower speed value for each road segment. The speed value is then the average speed value of bike sharing system users multiplied by the percentual difference value.</p> <p>The reference value for faster cycling has been 19km/h, which is based on the average speed of Strava sports application users in the Helsinki region. The reference value for slower cycling has been 12km/, which has been the average travel speed of bike sharing system users in Helsinki. Additional 1 minute have been added to the travel time to consider the time for taking (30s) and returning (30s) bike on the origin/destination.</p> <p>More information of the Strava dataset that was used can be found from the Cycling routes and fluency report, which was published by us and the city of Helsinki.</p> <p><strong>THE ROUTES BY WALKING</strong> were also calculated using the MetropAccess-Reititin by disabling all motorized transport modesin the calculation. Thus, all routes are based on the Open Street Map geometry.</p> <p>The walking speed has been adjusted to 70 meters per minute, which is the default speed in the HSL Journey Planner (also in the calculations by public transportation).</p> <p>All calculations were done using the computing resources of CSC-IT Center for Science (<a href="https://www.csc.fi/home">https://www.csc.fi/home</a>).</p>
Pn travel time data of Central and North China
<p>Pn travle time data of the Central and North China. The ten numbers in each line are the year, month, and day of event, the longitude, latitude, and depth of event, the longitude, latitude, and elevation of station, and Pn travle time.</p>
Code for 'Revealing the Local Time Structure of the Alfven Radius and travel times in Jupiter's magnetosphere'
Open the record for dataset details and reuse information.
Interface between Trapped-Ion Qubits and Traveling Photons with Close-to-Optimal Efficiency
<p>Datasets for the publication "Interface between Trapped-Ion Qubits and Traveling Photons with Close-to-Optimal Efficiency", PRX Quantum (2021)</p>
A Magnetospheric Driver of Westward Traveling Surge: Plasma-Sheet Bubble
<p>The text files are RCM-I simulation output. The file names specify simulation time (format: hhmmss). The stored quantities are, "I","J","COLAT","ALOCT","MLT","BNDLOC","XMIN","YMIN","FTV","BMIN (northward component of magnetic field)","V (electric potential)", "BIRK_fromV(NH) (Field-aligned current)","P(RCM),nPa", "PV_gamma (entropy)","Vtotx (the total plasma velocity included ExB drift and gradient-curvature drift)", "Vtoty","Vx_exb (ExB drift due to the electric potential)","Vy_exb","vel_x (ExB drift due to induction electric field)","vel_y","Ey","PEDLAM", "PEDPSI", "HALL", "RCM_T_p (proton temperature)","RCM_T_e (electron temperature)","RCM_N_e (electron number density)","EFLUX","EAVG","f_i_5-15","f_i_15-25","f_i_113-170","f_i_170-250","f_i_250-400","f_e_5-15","f_e_15-25","f_e_105-150","f_e_150-225","f_e_225-315","f_e_315-500","Vm"</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.