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.
76
datasets available to search
ShareScore release 0.9.0
Dataset results
76 results for “test network”
Developing a deep Learning network to retrieve ocean hydrographic profiles in the North Atlantic from combined satellite and in situ measurements: test datasets.
<p>We provide here the datasets used for the test and assessment of a deep learning algorithm which is presently candidate for the development of a daily 3D ocean product covering the North Atlantic at 1/10° resolution, over the 2010-2018 period, as part of the European Space Agency World Ocean Circulation project (ESA-WOC). The method is based on a stacked Long Short-Term Memory neural network, coupled to a Monte-Carlo dropout approach, and allows to project satellite-derived sea surface temperature, sea surface salinity and absolute dynamic topography data at depth after training with sparse co-located in situ vertical hydrographic profiles (Buongiorno Nardelli, 2020, doi:<a href="https://www.researchgate.net/deref/http%3A%2F%2Fdx.doi.org%2F10.3390%2Frs12193151?_sg%5B0%5D=0xE-347r7Hvb80klJcEo811AhUiXq-twG_E6l4yB-BfIKkVtW-lVLGcO02mTFkUczvozYYI0WCPyUBFR3kzWNGGZKg.ftvLheFrzHIJriO4qW2bdxalvR_TWt3MpwUfvto3EemhRgvDRGwJ9Mdy4Xr0IcGCfICivf4j-VqTgKxVvXRogA">10.3390/rs12193151</a>). </p> <p>The test dataset presented here includes different sets of co-located temperature and salinity vertical profiles: </p> <ul> <li>in situ observations extracted from the quality controlled Argo and CTD profiles produced by Copernicus Marine Environment Monitoring Service CORA 5.2 (<a href="http://marine.copernicus.eu/services-portfolio/access-to-products/">http://marine.copernicus.eu/services-portfolio/access-to-products/</a>, product_id: INSITU_GLO_TS_REP_OBSERVATIONS_013_001_b, doi: 10.17882/46219TS1, Szekely et al., 2019) and interpolated through a spline on a regularly spaced vertical grid (with 10 m intervals);</li> <li>climatological profiles extracted from World Ocean Atlas 2013 optimally interpolated monthly fields (Locarnini et al., 2013; Zweng et al., 2013), interpolated through a spline on a regularly spaced vertical grid (with 10 m intervals), upsized to a 1/10° horizontal grid through a cubic spline and linearly interpolated in time between the central day of each month;</li> <li>synthetic profiles obtained through three different techniques: multivariate EOF reconstruction, a 2 layer feed-forward network (with 1000 units in each hidden layer) and a stacked LSTM network (with 2 LSTM layers and 35 hidden units)</li> </ul> <p><em>References:</em></p> <p>Buongiorno Nardelli, B.: A Deep Learning network to retrieve ocean hydrographic profiles from combined satellite and in situ measurements, 2020, <em>submitted</em>.</p> <p>Locarnini, R. A., Mishonov, A. V., Antonov, J. I., Boyer, T. P., Garcia, H. E., Baranova, O. K., Zweng, M. M., Paver, C. R., Reagan, J. R., Johnson, D. R., Hamilton, M. and Seidov, D.: World Ocean Atlas 2013. Vol. 1: Temperature., S. Levitus, Ed.; A. Mishonov, Tech. Ed.; NOAA Atlas NESDIS, 73(September), 40, doi:10.1182/blood-2011-06-357442, 2013.</p> <p>Szekely, T., Gourrion, J., Pouliquen, S. and Reverdin, G.: The CORA 5.2 dataset for global in situ temperature and salinity measurements: Data description and validation, Ocean Sci., 15(6), 1601–1614, doi:10.5194/os-15-1601-2019, 2019.</p> <p>Zweng, M. M., Reagan, J. R., Antonov, J. I., Mishonov, A. V., Boyer, T. P., Garcia, H. E., Baranova, O. K., Johnson, D. R., Seidov, D. and Bidlle, M. M.: World Ocean Atlas 2013, Volume 2: Salinity, NOAA Atlas NESDIS, 119(1), 227–237, doi:10.1182/blood-2011-06-357442, 2013.</p> <p> </p>
Future Blood Testing Network+ Overview and Recap - Dr Weizi (Vicky) Li
<p>This video is the first talk from our Future of Healthcare: Remote Blood Testing, Monitoring & AI Meeting that took place on 07-08/11/2023. </p><p>Future Blood Testing Network+ Overview and Recap - Dr Weizi (Vicky) Li (Henley Business School, University of Reading). </p><p>Bio: Weizi (Vicky) Li is a Professor of Informatics and Digital Health, Deputy Director in Informatics Research Centre, Henley Business School, University of Reading. She is a Fellow of Charted Institute of IT (British Computer Society). She is an interdisciplinary researcher focusing on using informatics, data science, machine learning, and digital information systems to solve real-world healthcare challenges. She is currently the Principal Investigator and Director of EPSRC Future Blood Testing for Inclusive Monitoring and Personalised Analytics NetworkPlus; and EPSRC AI for Health project: Advancing machine learning to achieve real-world early detection and personalised disease outcome prediction of inflammatory arthritis. She is the academic lead of a large collaborative project of Improving the Quality of Healthcare through an Integrated Clinical Pathway Management Approach and Cloud-based Digital Data Integration Platform, which was awarded ESRC O2RB Excellence in Impact Award in 2018 and 4*/3* impact case study in REF 2021 for her research impact on healthcare quality improvement. She is the academic lead of a machine learning-based decision support system for outpatient management which has successfully been implemented in Royal Berkshire NHS Foundation Trust and has received the Research Engagement and Impact award in 2020, shortlisted for 2022 impact award and Health Service Journal (HSJ) patient safety award. </p><p>Further details on this event can be found at: https://www.futurebloodtesting.org/fbtn2023 </p><p>This video is an output from the Future Blood Testing Network which is funded by EPSRC under Grant Number EP/W000652/1</p><p>YouTube Link: https://youtu.be/Fqqekmhg79Q?si=l74rXxTFMx42mEsV</p>
Sevilleta Field Station Meteorological Network (SevMET): High frequency measurements from the Test Well Meteorological Station (TSWL), Sevilleta National Wildlife Refuge, NM, USA, 2024-ongoing.
The Sevilleta Field Station Meteorological Network (SevMET) is a spatially distributed, long-term climate monitoring network established to enhance and expand climate monitoring across a variety of dryland ecosystems (e.g., grasslands, shrublands, woodlands) within the Sevilleta National Wildlife Refuge in central New Mexico. Ecosystem processes in drylands are strongly regulated by climatic drivers that are highly variable in space and time, both within and among years. Therefore, accurate measurement of environmental variables at high spatial and temporal resolution is fundamental to understanding biophysical processes in these ecosystems. SevMET consists of fifteen standardized research-grade weather stations located across multiple dryland ecosystem types (e.g., grasslands, shrublands, woodlands) representative of the southwestern US. Stations continuously measure a standard suite of meteorological variables at five-minute intervals, including air temperature, relative humidity, precipitation, photosynthetically active radiation, incoming shortwave radiation, wind speed and direction, dew point, vapor pressure, and, at a subset of stations, barometric pressure. Stations also measure a suite of soil parameters (bulk electrical conductivity, dielectric permittivity, temperature, and volumetric water content) at six depths (5, 10, 20, 30, 40, and 50 cm) below the ground surface using 1-2 integrated soil profilers. Additionally, phenocams at each station capture images at thirty-minute intervals during daylight hours. This data package contains high-frequency meteorological measurements from the Test Well Meteorological Station (TSWL). Phenocam images can be accessed through the PhenoCam Network at: https://phenocam.nau.edu/webcam/sites/sevmettswl/. These data complement and extend meteorological data recorded by an adjacent station (Met52b), accessible at: https://portal.edirepository.org/nis/mapbrowse?scope=knb-lter-sev&identifier=1.
Train and Evaluation Code, Road Classification Models and Test set of the paper "Impact of Image Resolution and Image Overlap on the Prediction Performance of Convolutional Neural Networks Trained for Road Classification"
<p>This repository contains the Python scripts built for training and evaluation of the implementation, together with the test data and the resulting road classification models corresponding to the paper "Impact of Image Resolution and Image Overlap on the Prediction Performance of Convolutional Neural Networks Trained for Road Classification". The scripts make use of the Tensorflow with Keras framework and the additional required dependencies.</p> <p>The training and validation set is based on the binary SROADEX dataset (https://zenodo.org/records/6482346) that was re-split into tiles that feature the image resolutions (256 x 256, 512 x 512, and 1024 x 1024 pixels) and image overlaps (0% and 12.5%) considered in this study. The data have been generated using scripts developed in Python using Open Source libraries (GDAL/OGR and MapScript) for rasterization of vector cartography that represents the axes of the different types of roads (urban, interurban and rural). This binary road data contains information from 16 full orthoimages (28.5 km * 18.5 km) with spatial resolution of 0.5 m/pixel from the insular and peninsular Spanish territory. Due to the size on disk of approximately 546 gigabytes, this training and validation data is only available upon request from the corresponding author. The test set has been generated from a novel area of 28.5 km * 18.5 km and features binary road labels. The test sets are provided in the repository for each resolution (with no overlap), so that additional DL models can be evaluated on the same data and compared with the results achieved in this study.</p> <p>The structure of the information shared in this repository is as follows:<br>The scripts have been grouped by tile resolution (256, 512 and 1024). First, the test set and the evaluation script can be found. For each tile resolution, there are two subfolders (corresponding to the "no overlap" and "12.5% overlap"). In each case, the Python scripts for training the models in the three repetitions are shared, and the trained models (H5 format) are shared in compressed form. Finally, for each resolution we also share the testing dataset which consists of two folders.</p> <p>The material is distributed under a CC-BY 4.0 license.</p>
Introduction to the Future Blood Testing Network Plus - Dr Weizi (Vicky) Li (Henley Business School, University of Reading)
<p>This video is the first talk from our Future Blood Testing Network Plus Launch that took place on the 23/11/2021.</p> <p>Network Introduction - Dr Weizi (Vicky) Li (Henley Business School, University of Reading).</p> <p>Bio: Dr Weizi (Vicky) Li is the PI of the Future Blood Testing Network, an Associate Professor of Informatics and Digital Health, Deputy Director in Informatics Research Centre, Henley Business School, University of Reading. She is an interdisciplinary researcher focusing on using informatics, data science, machine learning, and digital information systems to solve real-world healthcare challenges. She is the academic lead of a large collaborative project of Improving the Quality of Healthcare through an Integrated Clinical Pathway Management Approach and Cloud based Digital Data Integration Platform, which was awarded ESRC O2RB Excellence in Impact Award in 2018 for her research impact on healthcare quality improvement. She is the academic lead of machine learning based decision support system for outpatient management which has successfully been implemented in Royal Berkshire NHS Foundation Trust and has received Research Engagement and Impact award in 2020. She has been PI on projects funded by ESRC, EPSRC, The Health Foundation, NHS and companies, working on data-driven decision support systems that use real-world data (under privacy preserving framework) from multiple sources including Electronic Patient Record in acute, community hospital and primary care settings, remote health monitoring and patient reported outcomes to develop novel technologies (including AI based methods) to support clinical and operational decision makings in patient pathway.</p> <p>Further details on this event can be found at: https://futurebloodtesting.org/event/23-11-21-future-blood-testing-network-launch/ </p> <p>This video is an output from the Future Blood Testing Network which is funded by EPSRC under Grant Number EP/W000652/1</p> <p>YouTube Link: https://youtu.be/YuBsU3NDdB0</p>
Future Blood Testing Network+ Overview - Dr Weizi (Vicky) Li (Henley Business School, University of Reading).
<p>This video is the first talk from our two day Future Blood Testing: Challenges & Opportunities Event that took place on the 13/09/2022.</p> <p>Future Blood Testing Network+ Overview - Dr Weizi (Vicky) Li (Henley Business School, University of Reading).</p> <p>Bio: Dr Weizi (Vicky) Li is the PI of the Future Blood Testing Network, an Associate Professor of Informatics and Digital Health, Deputy Director in Informatics Research Centre, Henley Business School, University of Reading. She is an interdisciplinary researcher focusing on using informatics, data science, machine learning, and digital information systems to solve real-world healthcare challenges. She is the academic lead of a large collaborative project of Improving the Quality of Healthcare through an Integrated Clinical Pathway Management Approach and Cloud based Digital Data Integration Platform, which was awarded ESRC O2RB Excellence in Impact Award in 2018 for her research impact on healthcare quality improvement. She is the academic lead of machine learning based decision support system for outpatient management which has successfully been implemented in Royal Berkshire NHS Foundation Trust and has received Research Engagement and Impact award in 2020. She has been PI on projects funded by ESRC, EPSRC, The Health Foundation, NHS and companies, working on data-driven decision support systems that use real-world data (under privacy preserving framework) from multiple sources including Electronic Patient Record in acute, community hospital and primary care settings, remote health monitoring and patient reported outcomes to develop novel technologies (including AI based methods) to support clinical and operational decision makings in patient pathway.</p> <p>Further details on this event can be found at: https://futurebloodtesting.org/event/13-14-09-2022/</p> <p>This video is an output from the Future Blood Testing Network which is funded by EPSRC under Grant Number EP/W000652/1</p> <p>YouTube Link: https://youtu.be/I1xsig9C8w0</p>
Train and test datasets used for the paper "Neural network time-series classifiers for gravitational-wave searches in single-detector periods"
<p>This repository contains the datasets used for training and testing during the work discussed in the paper "<a href="https://iopscience.iop.org/article/10.1088/1361-6382/ad40f0" target="_blank" rel="noopener">Neural network time-series classifiers for gravitational-wave searches in single-detector periods</a>". Please refer to this paper for more details on how the dataset was produced and cite it if you use these data:</p> <p><em>A. Trovato et al "Neural network time-series classifiers for gravitational-wave searches in single-detector periods", Class. Quant. Grav. 2024 DOI 10.1088/1361-6382/ad40f0.</em></p> <p>In this repository you will find six files in format npz, three of which refer to the test dataset and three to the train dataset. Each file name is of the type {label}_{train or test}.npz where "label" can be "glitch", "noise" or "signal", while the second part of the name indicates whether the file was used for training or testing.</p> <p>Each file is a collection of numpy arrays so it should be read with python. It contains 3 numpy arrays: 'X', 'Y' and 'metadata'. 'X' is a matrix containing 1-second segments of data sampled at 2048 Hz of the LIGO-Livingston detector, so it has shape: (number of samples, 2048). 'Y' contains the label for each segment, which is 0 for noise, 1 for signal and 2 for glitch, so it has shape: (number of samples,). In this case, the information on 'Y' is redundant since it's given directly by the filename. The 'metadata' matrix contains 17 metadata for each sample only for the case of signals, for glitch or noise it contains just 17 zeros for each sample. The shape of 'metadata' is thus: (number of samples, 17). For the signal files, for each sample the metadata is an array with these components:</p> <ol> <li>GPS start of the file from which this segment comes</li> <li>starting GPS time of this segment</li> <li>duration of the segment [s]</li> <li>mass1 [solar masses]</li> <li>mass2 [solar masses]</li> <li>spin1z</li> <li>spin2z</li> <li>inclination [radians]</li> <li>coalescence phase [radians]</li> <li>distance [Mpc]</li> <li>right_ascension [radians]</li> <li>declination [radians]</li> <li>polarization [radians]</li> <li>SNR (signal to noise ratio)</li> <li>shift of the signal w.r.t. the timeseries [s]</li> <li>length of the signal [s]</li> <li>fraction of the signal contained in the time window</li> </ol> <p>Number of samples:</p> <ul> <li>80000 for the file glitch_test.npz</li> <li>69998 for the file glitch_train.npz</li> <li>500000 for the file noise_test.npz</li> <li>250000 for the file noise_train.npz</li> <li>500000 for the file signal_test.npz</li> <li>250000 for the file signal_train.npz</li> </ul> <p>An example of few lines of python code to read each file is:</p> <pre><code>import numpy as np f = np.load("filename.npz") X = f['X'] Y = f['Y'] m = f['metadata'] </code></pre> <p>For the preparation of these data, we acknowledge the use of the following software packages: GWpy [1], PyCBC [2] and LALSuite [3]. </p> <p>This research has made use of data or software obtained from the Gravitational Wave Open Science Center (<a href="https://gwosc.org/" target="_blank" rel="noopener">gwosc.org</a>), a service of the LIGO Scientific Collaboration, the Virgo Collaboration, and KAGRA. This material is based upon work supported by NSF's LIGO Laboratory which is a major facility fully funded by the National Science Foundation, as well as the Science and Technology Facilities Council (STFC) of the United Kingdom, the Max-Planck-Society (MPS), and the State of Niedersachsen/Germany for support of the construction of Advanced LIGO and construction and operation of the GEO600 detector. Additional support for Advanced LIGO was provided by the Australian Research Council. Virgo is funded, through the European Gravitational Observatory (EGO), by the French Centre National de Recherche Scientifique (CNRS), the Italian Istituto Nazionale di Fisica Nucleare (INFN) and the Dutch Nikhef, with contributions by institutions from Belgium, Germany, Greece, Hungary, Ireland, Japan, Monaco, Poland, Portugal, Spain. KAGRA is supported by Ministry of Education, Culture, Sports, Science and Technology (MEXT), Japan Society for the Promotion of Science (JSPS) in Japan; National Research Foundation (NRF) and Ministry of Science and ICT (MSIT) in Korea; Academia Sinica (AS) and National Science and Technology Council (NSTC) in Taiwan.</p> <p>[1] https://gwpy.github.io<br>[2] https://pycbc.org<br>[3] https://lscsoft.docs.ligo.org/lalsuite</p>
Fig. 1 in Testing the robustness of transmission network models to predict ectoparasite loads. One lizard, two ticks and four years
Fig. 1. Transmission networks generated with (a) a short time window of infection; and (b) a long time window of infection, from the GPS location data of the lizards in the study population in 2010. Nodes represent individual lizards and edges between nodes are directed towards the lizard that is at risk of infection. The edges are weighted as described in the main text and the thicker the line the more weight is associated with that edge.
BRAIN Journal-High Performance Data mining by Genetic Neural Network-Figure 7 . Test Accuracy with prograess generation
<p>In the training phase, the neural network weights errors are minimized and network design<br> problem which the objective function to an acceptable level. In test step we have better results<br> because weights of neural network are adjusted by genetic algorithm and back propagation method.<br> Of course achievement to accuracy with 83.5% is reason using of good feature with minimum error.</p>
Agronomic performance of cultivar mixtures of winter wheat varieties, obtained from mixture field trials at 5 locations in Switzerland from 2019 to 2020, together with yield data from the varieties in pure stand obtained from the national variety testing trial network
<p>This dataset contains agronomic parameters of 32 winter wheat variety mixtures tested during 2 growing seasons (2019-2020) at 5 locations in Switzerland, as well as yield data of these varieties in pure stands originating from the Swiss national variety testing network. The dataset has been used to investigate the links between asynchrony and yield stability, published in <a href="https://doi.org/10.1002/csc2.21151">https://doi.org/10.1002/csc2.21151</a>. </p> <p>The field trials were performed under the Swiss Extenso (low input) conditions, conducted by Agroscope and DSP. </p> <h2>Methods </h2> <p><em>Field trials </em></p> <p>The experiment took place in five sites across Switzerland, in 2019 and 2020. The sites were located in Nyon (1260), Delley (1567), Utzenstorf (3428), Zurich (8046), and Ellighausen (8566).</p> <p>Experimental communities consisted of 32 different two-variety mixtures grown in 7.1-m<sup>2</sup> plots (1.5 × 4.7 m). We replicated the mixture experiment three times per site with the exact same variety composition. We used a randomized block design, with plots being randomized at each site within each block. Density of sowing was 350 seeds/m<sup>2</sup>, and seeds were mixed beforehand at a 50:50 ratio in terms of mass. We used the 50:50 mass ratio as this is what is generally done in practice by farmers and seed suppliers. Plots were sown mechanically each autumn. The plots were mechanically fertilized according to the Principles of Agricultural Crop Fertilisation in Switzerland (Federal Office for Agriculture) with an average of 140 kg N/ha (ammonium nitrate), applied in three splits (40 at the tillering stage—60 at stem elongation stage—40 when the flag leaf is visible). The experimental trials were conducted following the extenso Swiss scheme, which means that there was no application of any fungicide, insecticide, or plant growth regulator. </p> <p>The performances of single varieties were obtained by going through the trials of the national variety testing program. We gathered the data for the years 2018/2019 and 2019/2020. The data regarding single varieties could be obtained for three out of the five sites used for the mixtures: 1260, 1567, and 8566. Because there were no national variety trials at the two other sites (8046, 3428), we could not get any data for single varieties in these sites. Thus, all further analyses including single variety data were only done for the three sites mentioned above. At each of these sites, the variety trials were located on the same plot as the mixture trials, even though a little further apart. Therefore, soil parameters and crop precedents were the same between the mixture and variety testing trials. Furthermore, we only selected the national variety testing trials that respected the <em>extenso</em> conditions, that is, no fungicide, pesticide, or growth regulator application, and that received the same amount of fertilization as the mixture trials. In 8566 and 1567, sowing and harvesting dates were identical between the two trials; in 1260, sowing and harvesting dates could vary but remained within a week of each other.</p> <p> </p> <p><em>Data collection </em></p> <p>For each plot, heading dates were monitored, and average height at BBCH 59–75 was measured.</p> <p>The prevalence of diseases was scored twice in the growing season. Specifically, the severity of brown rust, yellow rust, powdery mildew, and Septoria tritici blotch was assessed. This was performed by grading each individual plot from 1 to 9 for each disease, with 1 representing no disease and 9 a complete infection. The scoring scale follows a logistic progression based on the symptoms of the top three leaves. We used the data from the final scoring for statistical analysis, as the disease severity was usually more important then.</p> <p>At maturity, we harvested each plot with a combine harvester. The harvested grains were dried when needed, weighed a first time, then sorted and cleaned by air and with a sieve cleaner, and subsequently weighted again. We measured specific weight and water content at the plot level using a Dickey-John machine (GAC 2100). Grain yield was subsequently standardized to 15% of humidity. Protein content was measured at the site level with a near-infrared instrument (ProxiMate; Büchi instruments).</p>
Multichannel Displacement measurement via self mixing interferometry and neural network : training and test datasets
<p>Self mixing interferometry is a simple and robust sensing method which can be used (among other things) to measure the displacement of a target along the light propagation axis. While conceptually simple, the actual use of this method is less straightforward than originally envisioned because reconstructing the target displacement from the interferometric signal is often tricky. A small neural network can do this task very well after proper training, as described in [10.1364/OE.419844], with dataset [10.5281/zenodo.7303745]. </p> <p>Here, the dataset is composed by a training set and a test set, in a specific configuration in which 3 self-mixing sensors measure simultaneously the same target displacement. Both datasets contain the displacement itself and the 3 interferometric signals (1 per sensing channel)</p> <p><strong>The training set </strong>relies on two python/numpy data files corresponding to <strong>harmonic displacements</strong> for different frequencies ranging from 53 and 93 Hz and amplitudes from 3.5 to 7.5 µm : </p> <ul> <li>Training_set_2_lostchannel_displacement.npy : 93744-elements long numpy array containing the target's displacement in units of µm/ms with a 1.024 ms time step. </li> <li>Training_set_2_lostchannel_signal.npy : numpy array of shape (3, 93744, 256, 1) containing the interferometric signals. The first dimension refers to the channel (1, 2 or 3), the second dimension is the number of segments of 256 points. Each segment of 256 points correspond to a 1.024 ms window of signal, matching one element of the displacement. For instance, the displacement value in `displacement[416]` corresponds to the interferometric signal segment `signal[0,416,:,0]` for channel 1, `signal[1,416,:,0]` for channel 2 and `signal[2,416,:,0]` for channel 3. </li> </ul> <p><strong>The test </strong>set follows the same architecture and format as the training set, but contains only <strong>random displacements </strong>generated by a delta-correlated signal, which we Fourier filter with a fifth order Butterworth filter between 10 and 100 Hz :</p> <ul> <li>"Displacement_test.npy" : with shape (246078, 1)</li> <li>"Signal_test.npy" : with shape (3, 246078, 256, 1)</li> <li>Only the displacement type has changed from harmonic to random, from the training to the test datasets.</li> </ul> <p>These datasets have been used to train and test a 3 channel neural network (after data augmentation) in order to emphasize the high availability potential of multichannel schemes, against backscattered power fluctuations. </p>
UKESM1.0-ice simulation output used as test data in Burgard et al., Emulating present and future simulations of melt rates at the base of Antarctic ice shelves with neural networks
<p>These files contain NEMO ocean model output and domain definitions for the Southern Ocean from UKESM1.0-ice simulations described in section 6.3.2 of Smith et al. "Coupling the U.K. Earth System Model to Dynamic Models of the Greenland and Antarctic Ice Sheets" , Journal of Advances in Modeling Earth Systems, 2021</p> <p>Files labelled "bf663" are the UKESM simulation referred to in that section as "constant 1970 greenhouse gas and other forcings". Files labelled bi646 are the UKESM simulation referred to in that section as "instantaneously quadrupled 1970 CO<sub>2</sub> concentrations".</p> <p>They were used as test data for the performance of neural networks in Burgard et al., "Emulating present and future simulations of melt rates at the base of Antarctic ice shelves with neural networks", Journal of Advances in Modeling Earth Systems 2023.</p>
Whole-brain mapping in adult zebrafish and identification of the functional brain network underlying the novel tank test
Open the record for dataset details and reuse information.
Data from: Does biological intimacy shape ecological network structure? A test using a brood pollination mutualism on continental and oceanic islands
Biological intimacy—the degree of physical proximity or integration of partner taxa during their life cycles—is thought to promote the evolution of reciprocal specialization and modularity in the networks formed by co‐occurring mutualistic species, but this hypothesis has rarely been tested. Here, we test this "biological intimacy hypothesis" by comparing the network architecture of brood pollination mutualisms, in which specialized insects are simultaneously parasites (as larvae) and pollinators (as adults) of their host plants to that of other mutualisms which vary in their biological intimacy (including ant‐myrmecophyte, ant‐extrafloral nectary, plant‐pollinator and plant‐seed disperser assemblages). We use a novel dataset sampled from leafflower trees (Phyllanthaceae: Phyllanthus s. l. [Glochidion]) and their pollinating leafflower moths (Lepidoptera: Epicephala) on three oceanic islands (French Polynesia) and compare it to equivalent published data from congeners on continental islands (Japan). We infer taxonomic diversity of leafflower moths using multilocus molecular phylogenetic analysis and examine several network structural properties: modularity (compartmentalization), reciprocality (symmetry) of specialization and algebraic connectivity. We find that most leafflower‐moth networks are reciprocally specialized and modular, as hypothesized. However, we also find that two oceanic island networks differ in their modularity and reciprocal specialization from the others, as a result of a supergeneralist moth taxon which interacts with nine of 10 available hosts. Our results generally support the biological intimacy hypothesis, finding that leafflower‐moth networks (usually) share a reciprocally specialized and modular structure with other intimate mutualisms such as ant‐myrmecophyte symbioses, but unlike nonintimate mutualisms such as seed dispersal and nonintimate pollination. Additionally, we show that generalists—common in nonintimate mutualisms—can also evolve in intimate mutualisms, and that their effect is similar in both types of assemblages: once generalists emerge they reshape the network organization by connecting otherwise isolated modules.
Supplementary material 3: List of tested and analyzed data sharing tools (non-exhaustive) from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
List of tested and analyzed data sharing tools (non-exhaustive)
Part 2 of real-time testing data for: "Identifying data sources and physical strategies used by neural networks to predict TC rapid intensification"
<p>Each file in the dataset contains machine-learning-ready data for one unique tropical cyclone (TC) from the real-time testing dataset. "Machine-learning-ready" means that all data-processing methods described in the journal paper have already been applied. This includes cropping satellite images to make them TC-centered; rotating satellite images to align them with TC motion (TC motion is always towards the +x-direction, or in the direction of increasing column number); flipping satellite images in the southern hemisphere upside-down; and normalizing data via the two-step procedure.</p> <p>The file name gives you the unique identifier of the TC -- e.g., "learning_examples_2010AL01.nc.gz" contains data for storm 2010AL01, or the first North Atlantic storm of the 2010 season. Each file can be read with the method `example_io.read_file` in the ml4tc Python library (https://zenodo.org/doi/10.5281/zenodo.10268620). However, since `example_io.read_file` is a lightweight wrapper for `xarray.open_dataset`, you can equivalently just use `xarray.open_dataset`. Variables in the table are listed below (the same printout produced by `print(xarray_table)`):</p> <p>Dimensions: (<br> satellite_valid_time_unix_sec: 289,<br> satellite_grid_row: 380,<br> satellite_grid_column: 540,<br> satellite_predictor_name_gridded: 1,<br> satellite_predictor_name_ungridded: 16,<br> ships_valid_time_unix_sec: 19,<br> ships_storm_object_index: 19,<br> ships_forecast_hour: 23,<br> ships_intensity_threshold_m_s01: 21,<br> ships_lag_time_hours: 5,<br> ships_predictor_name_lagged: 17,<br> ships_predictor_name_forecast: 129)<br>Coordinates:<br> * satellite_grid_row (satellite_grid_row) int32 2kB ...<br> * satellite_grid_column (satellite_grid_column) int32 2kB ...<br> * satellite_valid_time_unix_sec (satellite_valid_time_unix_sec) int32 1kB ...<br> * ships_lag_time_hours (ships_lag_time_hours) float64 40B ...<br> * ships_intensity_threshold_m_s01 (ships_intensity_threshold_m_s01) float64 168B ...<br> * ships_forecast_hour (ships_forecast_hour) int32 92B ...<br> * satellite_predictor_name_gridded (satellite_predictor_name_gridded) object 8B ...<br> * satellite_predictor_name_ungridded (satellite_predictor_name_ungridded) object 128B ...<br> * ships_valid_time_unix_sec (ships_valid_time_unix_sec) int32 76B ...<br> * ships_predictor_name_lagged (ships_predictor_name_lagged) object 136B ...<br> * ships_predictor_name_forecast (ships_predictor_name_forecast) object 1kB ...<br>Dimensions without coordinates: ships_storm_object_index<br>Data variables:<br> satellite_number (satellite_valid_time_unix_sec) int32 1kB ...<br> satellite_band_number (satellite_valid_time_unix_sec) int32 1kB ...<br> satellite_band_wavelength_micrometres (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_longitude_deg_e (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_cyclone_id_string (satellite_valid_time_unix_sec) |S8 2kB ...<br> satellite_storm_type_string (satellite_valid_time_unix_sec) |S2 578B ...<br> satellite_storm_name (satellite_valid_time_unix_sec) |S10 3kB ...<br> satellite_storm_latitude_deg_n (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_longitude_deg_e (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_intensity_number (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_u_motion_m_s01 (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_v_motion_m_s01 (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_predictors_gridded (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column, satellite_predictor_name_gridded) float64 474MB ...<br> satellite_grid_latitude_deg_n (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column) float64 474MB ...<br> satellite_grid_longitude_deg_e (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column) float64 474MB ...<br> satellite_predictors_ungridded (satellite_valid_time_unix_sec, satellite_predictor_name_ungridded) float64 37kB ...<br> ships_storm_intensity_m_s01 (ships_valid_time_unix_sec) float64 152B ...<br> ships_storm_type_enum (ships_storm_object_index, ships_forecast_hour) int32 2kB ...<br> ships_forecast_latitude_deg_n (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_forecast_longitude_deg_e (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_v_wind_200mb_0to500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vorticity_850mb_0to1000km_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vortex_latitude_deg_n (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vortex_longitude_deg_e (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_850mb_0to600km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_max_tangential_wind_850mb_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_1000mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_850mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_500mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_300mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_srh_1000to700mb_200to800km_j_kg01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_srh_1000to500mb_200to800km_j_kg01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_threshold_exceedance_num_6hour_periods (ships_storm_object_index, ships_intensity_threshold_m_s01) int32 2kB ...<br> ships_v_motion_observed_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_v_motion_1000to100mb_flow_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_v_motion_optimal_flow_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_cyclone_id_string (ships_storm_object_index) object 152B ...<br> ships_storm_latitude_deg_n (ships_storm_object_index) float64 152B ...<br> ships_storm_longitude_deg_e (ships_storm_object_index) float64 152B ...<br> ships_predictors_lagged (ships_valid_time_unix_sec, ships_lag_time_hours, ships_predictor_name_lagged) float64 13kB ...<br> ships_predictors_forecast (ships_valid_time_unix_sec, ships_forecast_hour, ships_predictor_name_forecast) float64 451kB ...</p> <p>Variable names are meant to be as self-explanatory as possible. Potentially confusing ones are listed below.</p> <ul> <li>The dimension ships_storm_object_index is redundant with the dimension ships_valid_time_unix_sec and can be ignored.</li> <li>ships_forecast_hour ranges up to values that we do not actually use in the paper. Keep in mind that our max forecast hour used in machine learning is 24.</li> <li>The dimension ships_intensity_threshold_m_s01 (and any variable including this dimension) can be ignored.</li> <li>ships_lag_time_hours corresponds to lag times for the SHIPS satellite-based predictors. The only lag time we use in machine learning is "NaN", which is a stand-in for the best available of all lag times. See the discussion of the "priority list" in the paper for more details.</li> <li>Most of the data variables can be ignored, unless you're doing a deep dive into storm properties. The important variables are satellite_predictors_gridded (full satellite images), ships_predictors_lagged (satellite-based SHIPS predictors), and ships_predictors_forecast (environmental and storm-history-based SHIPS predictors). These variables are all discussed in the paper.</li> <li>Every variable name (including elements of the coordinate lists ships_predictor_name_lagged and ships_predictor_name_forecast) includes units at the end. For example, "m_s01" = metres per second; "deg_n" = degrees north; "deg_e" = degrees east; "j_kg01" = Joules per kilogram; ...; etc.</li> </ul>
Real-time testing data for: "Identifying data sources and physical strategies used by neural networks to predict TC rapid intensification"
<p>Each file in the dataset contains machine-learning-ready data for one unique tropical cyclone (TC) from the real-time testing dataset. "Machine-learning-ready" means that all data-processing methods described in the journal paper have already been applied. This includes cropping satellite images to make them TC-centered; rotating satellite images to align them with TC motion (TC motion is always towards the +x-direction, or in the direction of increasing column number); flipping satellite images in the southern hemisphere upside-down; and normalizing data via the two-step procedure.</p> <p>The file name gives you the unique identifier of the TC -- e.g., "learning_examples_2010AL01.nc.gz" contains data for storm 2010AL01, or the first North Atlantic storm of the 2010 season. Each file can be read with the method `example_io.read_file` in the ml4tc Python library (https://zenodo.org/doi/10.5281/zenodo.10268620). However, since `example_io.read_file` is a lightweight wrapper for `xarray.open_dataset`, you can equivalently just use `xarray.open_dataset`. Variables in the table are listed below (the same printout produced by `print(xarray_table)`):</p> <p>Dimensions: (<br> satellite_valid_time_unix_sec: 289,<br> satellite_grid_row: 380,<br> satellite_grid_column: 540,<br> satellite_predictor_name_gridded: 1,<br> satellite_predictor_name_ungridded: 16,<br> ships_valid_time_unix_sec: 19,<br> ships_storm_object_index: 19,<br> ships_forecast_hour: 23,<br> ships_intensity_threshold_m_s01: 21,<br> ships_lag_time_hours: 5,<br> ships_predictor_name_lagged: 17,<br> ships_predictor_name_forecast: 129)<br>Coordinates:<br> * satellite_grid_row (satellite_grid_row) int32 2kB ...<br> * satellite_grid_column (satellite_grid_column) int32 2kB ...<br> * satellite_valid_time_unix_sec (satellite_valid_time_unix_sec) int32 1kB ...<br> * ships_lag_time_hours (ships_lag_time_hours) float64 40B ...<br> * ships_intensity_threshold_m_s01 (ships_intensity_threshold_m_s01) float64 168B ...<br> * ships_forecast_hour (ships_forecast_hour) int32 92B ...<br> * satellite_predictor_name_gridded (satellite_predictor_name_gridded) object 8B ...<br> * satellite_predictor_name_ungridded (satellite_predictor_name_ungridded) object 128B ...<br> * ships_valid_time_unix_sec (ships_valid_time_unix_sec) int32 76B ...<br> * ships_predictor_name_lagged (ships_predictor_name_lagged) object 136B ...<br> * ships_predictor_name_forecast (ships_predictor_name_forecast) object 1kB ...<br>Dimensions without coordinates: ships_storm_object_index<br>Data variables:<br> satellite_number (satellite_valid_time_unix_sec) int32 1kB ...<br> satellite_band_number (satellite_valid_time_unix_sec) int32 1kB ...<br> satellite_band_wavelength_micrometres (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_longitude_deg_e (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_cyclone_id_string (satellite_valid_time_unix_sec) |S8 2kB ...<br> satellite_storm_type_string (satellite_valid_time_unix_sec) |S2 578B ...<br> satellite_storm_name (satellite_valid_time_unix_sec) |S10 3kB ...<br> satellite_storm_latitude_deg_n (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_longitude_deg_e (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_intensity_number (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_u_motion_m_s01 (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_storm_v_motion_m_s01 (satellite_valid_time_unix_sec) float64 2kB ...<br> satellite_predictors_gridded (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column, satellite_predictor_name_gridded) float64 474MB ...<br> satellite_grid_latitude_deg_n (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column) float64 474MB ...<br> satellite_grid_longitude_deg_e (satellite_valid_time_unix_sec, satellite_grid_row, satellite_grid_column) float64 474MB ...<br> satellite_predictors_ungridded (satellite_valid_time_unix_sec, satellite_predictor_name_ungridded) float64 37kB ...<br> ships_storm_intensity_m_s01 (ships_valid_time_unix_sec) float64 152B ...<br> ships_storm_type_enum (ships_storm_object_index, ships_forecast_hour) int32 2kB ...<br> ships_forecast_latitude_deg_n (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_forecast_longitude_deg_e (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_v_wind_200mb_0to500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vorticity_850mb_0to1000km_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vortex_latitude_deg_n (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_vortex_longitude_deg_e (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_850mb_0to600km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_max_tangential_wind_850mb_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_1000mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_850mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_500mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_mean_tangential_wind_300mb_at500km_m_s01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_srh_1000to700mb_200to800km_j_kg01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_srh_1000to500mb_200to800km_j_kg01 (ships_storm_object_index, ships_forecast_hour) float64 3kB ...<br> ships_threshold_exceedance_num_6hour_periods (ships_storm_object_index, ships_intensity_threshold_m_s01) int32 2kB ...<br> ships_v_motion_observed_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_v_motion_1000to100mb_flow_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_v_motion_optimal_flow_m_s01 (ships_storm_object_index) float64 152B ...<br> ships_cyclone_id_string (ships_storm_object_index) object 152B ...<br> ships_storm_latitude_deg_n (ships_storm_object_index) float64 152B ...<br> ships_storm_longitude_deg_e (ships_storm_object_index) float64 152B ...<br> ships_predictors_lagged (ships_valid_time_unix_sec, ships_lag_time_hours, ships_predictor_name_lagged) float64 13kB ...<br> ships_predictors_forecast (ships_valid_time_unix_sec, ships_forecast_hour, ships_predictor_name_forecast) float64 451kB ...</p> <p>Variable names are meant to be as self-explanatory as possible. Potentially confusing ones are listed below.</p> <ul> <li>The dimension ships_storm_object_index is redundant with the dimension ships_valid_time_unix_sec and can be ignored.</li> <li>ships_forecast_hour ranges up to values that we do not actually use in the paper. Keep in mind that our max forecast hour used in machine learning is 24.</li> <li>The dimension ships_intensity_threshold_m_s01 (and any variable including this dimension) can be ignored.</li> <li>ships_lag_time_hours corresponds to lag times for the SHIPS satellite-based predictors. The only lag time we use in machine learning is "NaN", which is a stand-in for the best available of all lag times. See the discussion of the "priority list" in the paper for more details.</li> <li>Most of the data variables can be ignored, unless you're doing a deep dive into storm properties. The important variables are satellite_predictors_gridded (full satellite images), ships_predictors_lagged (satellite-based SHIPS predictors), and ships_predictors_forecast (environmental and storm-history-based SHIPS predictors). These variables are all discussed in the paper.</li> <li>Every variable name (including elements of the coordinate lists ships_predictor_name_lagged and ships_predictor_name_forecast) includes units at the end. For example, "m_s01" = metres per second; "deg_n" = degrees north; "deg_e" = degrees east; "j_kg01" = Joules per kilogram; ...; etc.</li> </ul>
Surfaces/regoliths used in the training and testing of the deep neural network for surface reconstruction from simulated exospheric measurements
<p>This dataset contains the surfaces/regoliths in terms of elemental surface composition used in v2.0 - v2.5 of the paper collection: "Conceptual framework for the application of deep neural networks to surface composition reconstruction from Mercury’s exosphere".</p>
Inputs and outputs for the training and testing of a deep neural network for surface reconstruction from simulated exospheric measurements
<p>This dataset contains inputs (datasets) and outputs (trainings and tests) used in v2.0 - v2.5 of the paper collection: "Conceptual framework for the application of deep neural networks to surface composition reconstruction from Mercury’s exosphere".</p>
Data for "Information sharing within a social network is key to behavioral flexibility – lessons from mice tested under semi-naturalistic conditions"
<p>Data for "Information sharing within a social network is key to behavioral flexibility – lessons from mice tested under semi-naturalistic conditions", currently under review in Science Advances. </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.