dataesr/scientific-paragraphs-categorization huggingface dataset:
Discussion We assessed the stability and the precision of the estimated network metrics with the bootstrap method we propose here. Only for the smallest network (with 17 interaction events) the bootstrap confidence limits did not reach stability, but for the others (more than 100 interaction events) the confidence limits reached stability. The method is general enough to be applied to different types of metrics and networks. However, the type of network metric has to provide a single value at the end of the analysis. For example, modularity involved an optimization method, but we could use it because it gives a modularity Q value  (Dormann and Strauss 2013). Further, since the aim is to evaluate sampling sufficiency of network metrics, the network must be a quantitative one because data containing the frequency of interactions is necessary for the resampling procedure (interaction events or captured individuals in the test cases).
In seed dispersal networks between plants and birds, e. g. , the sampling hours or number of observed plant individuals as sample size (through transect or focal-plant methodologies) can be compared with the number of bird individuals captured (with mist net) that need to be sampled in order to reach stability for each network metric. We assessed sampling sufficiency with the bootstrap method using interaction events as sampling units with three mutualistic networks that differed regarding sampling techniques. In addition, we used the captured bird individuals as sampling units to assess sufficiency for the networks we have collected. The potential advantage of using individual data over interaction events is that the first is more independent in comparison to the latter. Independence between sampling units is often an important assumption in data analysis, and the accuracy of the bootstrap method may be affected by lack of independence  (Efron and Tibshirani 1993).
However, in spite of the advantage of using individuals as sampling units, the data available for most networks in literature and online databanks unfortunately only allow the extraction of interactions events. In our study, we observed a variation of the median value of the metric generated by bootstrap resampling, mainly in small samples. We expected that the median would remain stable throughout the process, and only the confidence interval would change with increasing sample size. Since most network metrics are sensitive to sampling effort and network size  (Dormann et al. 2009) , probably these metrics are biased, causing this variation in the median value of the metric. Further research, using simulated networks with known properties and dimensions, is needed to evaluate how accurate these network metrics are.
Our results suggest an important point: sampling sufficiency can be reached at different sample sizes for the same dataset depending on the metric of interest. Nielsen and Bascompte (2007) , analyzing the sensitivity of connectance and nestedness metrics to variation in sampling effort, also suggested that sampling intensity does not affect all network metrics in the same way, and that nestedness tends to stabilize rapidly with increasing sampling effort. Some confidence limits generated by the bootstrap reached stability with less than 100 interaction events, meaning that sampling more interaction events probably would have not significantly affected the estimation of this network pattern. However, it has been pointed out that studies of interactions should come from a robust and well-designed sampling procedure, mainly due to the influence of limited sampling effort in network properties  (Dormann et al.
Acknowledgements We thank  Programa de Pós-Graduação em Ecologia -Universidade Federal do Rio Grande do Sul  and the  Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq)  for funding received. This work is part of the project  Biodiversity of grasslands and grassland-forest ecotones in Southern Brazil: ecological basis for conservation and sustainable use  (SISBIOTA-Federal funding:  MCT/CNPq/MEC/CAPES/FNDCT , grant  563271/2010-8 ). GC thanks  CAPES  for a scholarship and for the sandwich internship ( Ministry of Education of Brazil, Brasília -DF 70. 40-020 , Brazil), conducted on  Pacific Ecoinformatics and Computational Ecology Lab , coordinated by  Dr. Neo Martinez , where the first discussion of sampling sufficiency started. VDP has been supported by a  CNPq fellowship  (grant  307689/2014-0 ).
Docking of arbitrary peptide probes The protein submitted to the ArDock server is docked against 25 molecular probes. Each probe is docked independently by the Hex software  (22). The 10 best computed protein-probe conformations, as scored by the Hex energy function, are used to count the number of times that each surface residue of the protein is found at a protein-probe interface. The protein residues are considered to form the interface when their solvent accessibility changes from the initial to the probe-bound conformation. The solvent accessibility of the amino acids is computed with NACCESS  (23). The surface amino acids are finally assigned a normalized score: S = x - x σ Where x is the number of protein-probe interface in which the amino acid is found, x is the averaged value of x over all the surface amino acids and the estimated standard deviation.
Input A protein structure file complying with the Protein Data Bank  (26)  format can be submitted to the server. Only natural amino acids are currently supported, any other molecular component will be discarded. The submitted coordinates are processed in the navigator by two JavaScript com-ponents: a parser (https://github. com/glaunay/pdb-lib) and the NGL  (27, 28)  webGL renderer. This allows the user to interactively select amino acid chains before their analysis by the server. It is important to note that different combinations of protein chains can lead to distinct results because the ArDock method is sensitive to the overall shape of the protein. Additionally, different protein structures can be submitted to the same session. We plan to extend the treatment to nucleic acids and to modified protein residues.
Server implementation The protein coordinates with the desired set of chains are sent to the server backend, on which 25 docking simulations are performed in parallel by our NodeJS cluster scheduler (https://github. com/glaunay/nslurm). The docking software is the version 8. 0. 0 of the HeX program (hex. loria. fr/). Computations use the shape complementarity scoring function with a ligand-receptor maximum range of 40 Å and scan steps of 0. 75 Å, the complete list of parameters can be found in a previous publication  (5). All the tasks required by the ArDock procedure are organized in an asynchronous pipeline. When a task is finished, its results are streamed in the pipeline but can also be captured immediately by the application server. Thus, full completion of the pipeline is not required to begin visualization and any relevant intermediate results can be passed to the web client.
Resuming analysis and interoperability Upon job submission, a center console dedicated to data saving and export appears. The right-end button of the console displays a personal key that allows future access to the job results. If the user is forced to quit at this stage, the computations will be carried out and remain accessible. To resume the analysis the user will paste his personal key into the restore procedure accessible from the welcome page. The client will then fetch all relevant data from the server and restore the proper 3D rendering and the tabular results. The left-hand button of the console will establish a communication with the ENDscript (29) server (http:// endscript. ibcp. fr). The structure file annotated with the Ar-Dock result will be passed to the ENDscript server and a dedicated tab will open in the browser.
The ENDscript server will provide the user with additional tools to study protein sequences and structures. Hence, the user can automatically generate a multiple sequence alignment from the query, which is colored according to residue conservation and adorned with secondary structure elements of each homologous protein of known structure. Potential interaction regions identified by ArDock are shown with colored bars at the bottom of sequence blocks. The user can also generate an interactive 3D PyMOL representation of the query, whose main chain is depicted as a tube whose radius is proportional to the differences in C␣ between the query and all homologous proteins of known structures. Potential interaction areas will be highlighted anew with colored meshes.
Prediction performances The predictive performance of arbitrary docking was explored in our previous studies  (5, 30). Here, we present the performance of the ArDock server on the protein benchmark created for the critical assessment of on-line resources for the prediction of protein interface residue  (31). The dataset is made of 90 target proteins crystal complexes, which were obtained from the Protein Docking Benchmark Set 4. 0 (32) the following way : (i) excluding complexes for which the receptor (i. e. longer chain) is shorter than 50 or longer than 600 residues; (ii) discarding complexes with more than two chains, and interfaces smaller than 20 residues; (iii) interface residues were defined using a 5 Å distance cutoff. Accessible residues (relative accessibility greater than 5%) were classified as interface or non-interface depending on their arbitrary docking score.
Buttons (left to right): communication of the results to the ENDscript server, download of the results as a PDB file and copying of the job-specific key for later reload. (D) In order to easily inspect an amino acid in the structure, the whole structure transparency is increased and only the inspected amino acid remains fully opaque (in this case, threonine 105 of chain A). ArDock does not require any training or prior knowledge. More importantly, ArDock identifies interface residues using a structural information which is not taken into account by any other available method. The information provided by ArDock is hence orthogonal to the one provided by other comparable web services. This makes of ArDock an accurate tool on its own but also a significant addition to the current set of on-line resources for the detection of protein interaction site.
Experimental interface detection examples In addition, to these global performance indicators, the use of ArDock can be illustrated on specific examples. Here, two complexes were taken from the aforementioned benchmark and only one partner in each complex was processed by the ArDock server. We now present the accuracy of Ar-Dock at detecting the interaction surface of these partners that form the interface in their corresponding complexes. The first case is the human cell division control protein 42 (CDC42). This protein is a small GTPase of the Rho family. In the crystal structure of the benchmark (PDB code: 1GRN) a monomer of CDC42 forms a complex with a domain of its specific GTPase-activating protein. Their surface of interaction is 2332. 2 Å2 for a total of 65 interchain residue contacts.
A set of 22 residues from CDC42 participates in the experimental interface. As it can be seen in Figure  3 , ArDock analyzed the surface of the CDC42 monomer and predicted 21 of these 22 residues as interacting residues. The second case is a hydrolase/inhibitor complex. The enzyme is a yellow meal worm ␣-amylase. The experimen- ArDock interface prediction of a glycosylase, the yellow meal worm ␣-amylase (PDB code: 1TMQ). In this case, the experimental interface is larger and a similar color code is used. The experimental interface residues are colored in green if they are also predicted as interface residue by ArDock and colored in orange if they were not predicted as interface residue by ArDock. tal structure (PDB code: 1TMQ) displays an interface of 2401. 0 Å2. A total of 32 enzyme residues participates in 70 interchain residue contacts.
ACKNOWLEDGEMENTS The authors thank  R. Lavery  for his advice at the origin of the web service initiative and for his help with the manuscript. We thank  M. Brylinski  for providing the BM90 dataset. We thank  Alexis Michon  and  Samuel Bosquin  ( UMS 3760 ,  Institut de Biologie et Chimie des Protéines, Lyon, France ) for helpful discussions, technical assistance and hardware support. FUNDING European Union's  Horizon 2020 Framework Programme for Research and  ( Human Brain  Project  SGA1 ) [720270]. Funding for open access charge: European Union's  Horizon 2020 Framework Programme for Research and Innovation  ( Human Brain  Project  SGA1 ) [720270].
Data managing and statistical analysis Study data were collected and managed using REDCap electronic data capture tools hosted at Clermont-Ferrand University Hospital  [46]. REDCap (Research Electronic Data Capture) is a secure, web-based application designed to support data capture for research studies, providing (1) an intuitive interface for validated data entry; (2) audit trails for tracking data manipulation and export procedures; (3) automated export procedures for seamless data downloads to common statistical packages; and (4) procedures for importing data from external sources. Statistical analyses were performed using Stata software (version 13, StataCorp, College Station, United States). The tests were two-sided, with a type I error set at α = 0. 05. Baseline characteristics were presented as mean ± SD or median (interquartile range) according to statistical distribution (assumption of normality assessed using the Shapiro-Wilk test) for continuous data and as the number of patients and associated percentages for categorical parameters.
DISCUSSION In this prospective study, we showed, for the first time in the same cohort that faecal calprotectin and MRI are two reliable alternative tools to detect endoscopic POR with CD. In addition, MRI parameters including Clermont score, MaRIA and MR scoring system demonstrated substantial inter-reader agreement. As surgery is not curative in CD and the rate of endoscopic POR can reach more than 75% within the first year after the surgery in some referral centers  [4]  , the prevention of POR remains a major concern for the IBD physicians. Recently, the data retrieved from the POCER trial confirmed the positive impact of a tailored therapeutic management based on the early endoscopic findings (within the first year following the intestinal resection) compared to a monitoring based on clinical activity  [6].
Moreover, when one considers the computational performance of the algorithm, the proposed modifications also allows for faster computation. Before, each gray-level had its one hierarchical queue in Salembier's original algorithm formulation or a singular in Carlinet's non-recursive reformulation. This approach scales logarithmically with both, the number of gray-levels as well as the number of pixels per channel. In the proposed variant the gray-levels are keys to a map, called stacks, that has vectors for the corresponding pixels as keys. Then, insertions only scale logarithmically with the number of gray-levels, for locating the respective vector in the map, but the actual push operation happens in constant Algorithm 3 Pseudo-code of the modified version of Salembier's depth-first, flooding-based max-tree algorithm.
Distributed Tuple Resolution The resolution of the tuples happens essentially in the same mode as the generation of tuples. First, the area tuples are resolved, which requires the iterative resolution of the weakly connected area components into strong ones, and then, second, the resolution of the edges for the normalized components. The respective high-level pseudo-code is displayed in Algorithm 4. It makes use of the distributed communication primitive ALLREDUCE several times. In line with this text it should be understood as a function that reduces, i. e. combines, vector of values with the same length and arbitrary, but consistent data types, element-wise using an operator given as second parameter. The single, final result vector is broadcast to all participating distributed compute nodes.
3 : Toy example demonstrating the tuple resolution of the distributed max-tree algorithm. (k × d × w d × log(w × d) × log(p)) O(w × d) O(k × d × log(p)) Redistribution O(w × d) O(w × d) O(log(p)) Application O(w × d + n p × log(w × d))) O(w × d) - Algorithm 6 Pseudo-code of the distributed resolution of the root tuples. 1: function RESOLVE-ROOTS(grayv, area, roots) 2: combined ← CONCAT(area(grayv), roots(grayv)) 3: GLOBAL-SORT(combined) LEFT-PREFIX-SUM(ends, Min) return tuples.
IMPLEMENTATION The proposed parallel algorithm has been implemented in C++ and is available on the open-source code repository Github  [48]. The coarse-grained parallelization across multiple nodes has been realized using the Message Passing Interface (MPI)  [49]. For the shared-memory implementation C++11 native threads have been used. The algorithm accepts data loaded from files in the Hierarchical Data Format 5 (HDF5) format  [50] , which it will also store the resulting parent image to.
Algorithm 7 Pseudo-code of a thread-safe, stateful MPI reduction operation and subsequent usage by a prefix-sum. In this case, though, the whole distributed max-tree implementation effectively also becomes a singleton and may not be used in multi-threaded environments, which is suboptimal for a number of analysis uses cases. Therefore, it has been chosen an approach as sketched in Algorithm 7. A set of potential remapping data-structures from different threads is stored in a global associative container, here rules, guarded by a mutex. Before calling an MPI_Scan the remapping data-structure must be stored and during the custom reduction operation retrieved. In order to be able to correctly retrieve the remapping data-structure a unique, shared key must be chosen, for example the current thread identifier.
Environment The experiments have been performed on the JURECA system  [52]  at the Juelich Supercomputing Centre. The system consists of 1884 compute nodes with each having two Intel R Xeon R E5-2680 v3 Haswell CPUs with 12 cores at 2,5 GHz and Hyperthreading. 1604 compute nodes have 128 GiB, 128 nodes 256 GiB, 74 node 512 GiB and two nodes 1024 GiB DDR5 RAM. For our experimental evaluation the following software libraries have been used-HDF5 1. 8. 18 parallel and ParaStation MPI 5. 1. 9. Source code has been compiled with g++ 5. 4. 0 optimization level 03. The available benchmark for the experiments relies on a maximum of 32 nodes and 24 threads.
Datasets As for the used data, the tests have been performed on two real-world images depicted in Figure  4. The first dataset is a Pléiades Ortho Product 1 that was acquired over the Naples metropolitan area (Italy) in 2013. It includes four Pansharpened images with spatial and radiometric resolution of 0. 5m and 8 bpp, respectively. This dataset was selected due to its free availability, its sufficient size and spatial resolution, are relevant to the needs of the remote sensing community for scalable and accurate methods that allow to classify rapidly and accurately objects of interest over vast areas, as was discussed in Section 1 (e. g. , produce very high resolution land cover mapping at the European scale). The second dataset is an image that was taken at the ESO Paranal Observatory in Chile by the Visible and Infrared Survey Telescope for Astronomy (VISTA).
It portraits more than 84 million stars in the central regions of the Milky Way  [53]. The Figure  4a  and Figure  4b  show the true-color image of both datasets. For the Naples dataset, experiments are performed only using the first channel  [54]. For the ESO, the RGB image is simplified to a singular luminance channel, similarly to how it was done by Moschini et al. [37]  in order to obtain similar conditions for benchmarking the proposed algorithm. The luminance image is obtained through weighing and summing the channels, so that L = 0. 2126R + 0. 7152G + 0. 0722B. However, in order to show that the algorithm scales regardless of the domain size of the gray-levels, three different quantization levels are derived from the luminance channel: 8-uint bpp, 16-uint bpp and 32-float bpp  [55].
Experimental Setup As discussed in Section 3 there are a number of other serial and parallel versions of the algorithm. Most of them report 1. http://www. intelligence-airbusds. com/en/23-sample-imagery different value permutations for the computation time, memory consumption, speed-up and scalability of their implementations. Carlinet et al. [39]  provide their used benchmarks, datasets and the source codes in C++ for many different serial and parallel algorithms 2. In order to compare results achievable by using serial and parallel computing, the Berger et al. [16]  algorithm has been selected. Moschini et al. [37]  proved that Berger is the fastest sequential algorithm for images with high quantization values and even floating. However the algorithms depend on the MILENA image processing library  [56]  (i.
e. , provide fundamental image types and I/O functionality) which was not designed to handle very large images and floating values. For these reasons it was necessary to re-write a new C++ implementation of the algorithm which is library independent. For the parallel processing case, the hybrid shared-memory parallel max-tree algorithm developed by Moschini et al. [37]  was considered. The algorithm has been implemented in C using POSIX threads and the source code is available publicly 3. Contrary to the MILENA library, this algorithm has been proposed with the purpose of dealing with large-scale and high-dynamic range images, and was therefore ready to be used out-of-the-box. It may be argued that the comparison is not entirely fair due to the different nature of the algorithms-i. e. , shared-memory and distributed-memory-but can very well be investigated for the same number of utilized cores.
The expectation naturally is that distributed memory implementation, as the one proposed here, are naturally going to have more overhead compared to shared-memory versions. To the best of our knowledge the only distributed max-tree algorithm has been proposed recently by Kazemier et al. [38] , but the source code was not obtainable at the time of writing as it is not yet released. The performance assessment of the algorithms proposed by Berger and Moschini against the algorithm proposed in this paper is conducted with two kinds of benchmarks. The first type is focused on the computation time and speedup, while the second measures memory consumption. Each benchmark configuration, meaning a particular node and core count, is executed five times and the following statistics are reported: mean µ, standard deviation σ, minimum, maximum, and coefficient of variation (CV ), defined as ν = σ µ  [57].
Speed-up and Memory Consumption The Figure  5  depicts the experimental results related to the processing time. For each dataset, the plot of the mean execution time and the plot of the speed-up for increasing number of cores is reported. In order to make a fair comparison with the state-of-the-art results (i. e. , the shared-memory algorithm  [37] ), the proposed algorithm is first run on a single node. The algorithm's execution time measures the beginning and end of the main() function of the process with the MPI 0 and the thread number 0. The speedup coefficient is computed as t p = t 1 /t c. the fraction of the execution time with a single core and the execution time with multiple processing cores. Generally it can be said that the proposed algorithm is able to gain a substantial speed-up for both data sets and the different gray-levels quantizations.