dataesr/scientific-paragraphs-categorization huggingface dataset:
Sensible values for the parameters are v = 5M B/s and δ = 10h. Early Stuck Then we can consider block transfers that begin with serious performance issues and start flowing properly only after some time, presumably once such issues have been fixed. We may call such transfers "early stuck". To find this type of latency we can select transfers in which the time for the first replica is larger than a given threshold δ. An offset which depends from the average size of the files and the reference rate parameter v will prevent blocks with very big files to show up even if they have no latency issues. In formulas ∆T 1st > δ + S v (6) where ∆T 1st is the time of the first replica and S the average file size in the datablock. We can use again the values above as good estimations of v and δ. Many Small Blocks If we take large datasets with many small (few files) blocks, we can consider the latency caused, at the dataset level, by some stuck blocks.
This is much like the latency tails discussed above but replacing files by blocks and blocks by datasets. This is another important latency type that we will not be able to analyze since it affects blocks of a type that we ruled out of our sample (they are below the size limit). Despite this list of data types is clearly incomplete, we will see that it covers most of the real-life cases. In what follows we will in fact proceed in a more detailed analysis of the transfers affected by the latency types defined in this section. We will see which are their causes and their consequences on the CMS operations.
Latency of big blocks with long tails The extended CMS data production and processing tasks that run over the distributed infrastructure may occasionally produce corrupted outputs. That is, one or few files in a datablock which are missing -resulting from a non-handled failure in the stageout to grid storage -or have wrong size/checksum. PhEDEx has been designed to deal with such data corruption events and is able to detect the corrupted files -relying on FTS internal checking mechanisms and on pre/post validation scripts -and tag the corresponding transfers as failing. Moreover PhEDEx tries to minimize the impact of the corrupted files on the data placement operations -and in particular on the transfers throughput -by re-queuing such files with low rank while it keeps on transferring the rest of the data.
As the transfers of the corrupted files keep on failing systematically, PhEDEx suspends them for a longer time. Thus the effect of file corruption during data production is observed, at data placement level, as a latency tail issue in PhEDEx transfers. The impact of these missing/corrupt files can only be seen in the last few percentages of the transfer of the whole block. Hence, while transfer rates in the first 95% have higher values, rate in the last 5% drops off to quite low values as shown in fig. 1. In a similar way, RSkewLast 5 values (see eq. 4) are much lower than Skew 95 values (see eq. 1) in fig. 2. The underlying reasons for file production failures have been extensively investigated by the CMS PhEDEx team. It was observed that they are mostly due to transient storage problems, which explains why only a few files are affected from this issue.
Latency of datasets with many small blocks In all CMS processing activities, datasets -to be intended as collections of files with specific physics content -are produced via the contribution of multiple WLCG sites supporting the CMS workflows. In most cases, the contributing sites are not the final destination where the dataset is supposed to be stored. Hence, a PhEDEx subscription is made to ship all data to a tape endpoint -and possibly to some disk endpoints -chosen according to CMS policies. However, some of the blocks might be located at sites having temporary network or storage problems which can cause a latency in the overall data placement task. Big datasets composed of many small blocks (few files per block) are particularly exposed to For transfers tagged as having latency tails according to eq.
5. Figure  3. Block transfers counting, grouped by source and destination Tier type. For all transfers (left) and for transfers tagged as having latency tails according to eq. 5 (right). We can see that the contribution of Tier-0/1 sources is much lower in the sample with latency issues. this kind of issues as the sources of blocks are multiple and may be particularly heterogeneous. This is much similar to the latency issues described in sec. 5 but on dataset/fileblock level rather than on fileblock/file level. As we said in sec. 4, the way our final set of latency data was selected does not allow us to study this kind of latencies. However, one way to detect these kind of latencies among the raw latency data provided by PhEDEx may be to select small group, aggregate information by dataset, calculate the transfer rate distribution of bocks within a dataset and look at the slow tails of such distributions.
Conclusions PhEDEx is one of the crucial components of the CMS Computing system. Profiting of data collection and filtering since Run-1, the CMS Computing project has a large set of data concerning the latencies as observed in all transfers happening between all Tiers. The study of this data set has just started, but it is already allowing a categorisation of the different root sources of such latencies and shaping different strategies to attach the observed problem, and this increase the overall performance of the PhEDEx system for CMS. Figure  5. Skew 25 versus SkewLast 75 as defined in eq. 1 and eq. 2. For transfers tagged as being "early-stuck" according to eq. 6.
To this aim, we first define a sequence-based representation of networks, combining temporal information, community structure, topological measures, and nodal attributes. We then describe how to identify the most emerging sequential patterns of this dataset, and use them to characterize the communities. We study the performance of our method on artificially generated dynamic attributed networks. We also empirically validate our framework on real-world systems: a DBLP network of scientific collaborations, and a LastFM network of social and musical interactions.
We have u(v) = (l 11 , • • • , l k1 ) • • • (l 1θ , • • • , l kθ ) , where l it is the item containing the value of descriptor D i for v at time t. A node sequence u(v) includes θ itemsets, i. e. it represents all time slices. Each one of these itemsets contains all k descriptor values for the considered node at the considered time. In other words, u(v) contains all the available descriptorrelated data for node v. We build the enlarged node sequence u enl (v) of a node v by adding a community-related item to each itemset of its node sequence: u enl (v) = (l 11 , • • • , l k1 ,C 1 (v)) • • • (l 1θ , • • • , l kθ ,C θ (v)). The sequence database M can then be obtained by collecting the enlarged node sequences u enl (v) of all nodes in the considered network. The set of supporting nodes S(s) of a sequence s is defined as S(s) = {v ∈ V : u(v) s}.
In the context of community interpretation, the problem of finding an appropriate community representation, for a dynamic attributed network and its community structure, is equivalent to that of encoding all information describing the evolution of each node from each community. This encoding should be compact enough to avoid redundancies, but complete enough to describe the evolution of the community. To fulfill these constraints, we propose to represent each node using the sequence of its attributes and topological measures, taken at different discrete times of the system evolution. To our knowledge, such a sequential representation was never used for networks before. We could use the database M described in the previous section, which is the collection of enlarged node sequences u enl (v) (∀v ∈ V ).
However, this representation would not be very compact, because several nodes could be described (totally or partially) by similar sequences. To avoid this, we instead represent a community through the sequential patterns present among the sequences describing the nodes it contains. For a node v, we note P v the set of all possible subsequences of its enlarged node sequence, i. e. P v = {s u enl (v)}. Let P be the union of all the P v over all nodes, i. e. P = v∈V P v , and B be the subset of its community sequences. Let m i denote such a community sequence and µ be the cardinality of B, then we have B = {m 1 , • • • , m µ }. We state the problem of community representation is finding a set Γ = {γ 1 , • • • , γ µ } such that γ i = {s ∈ P : s m i } with 1 ≤ i ≤ µ. In other words, for each community sequence m i found in the database, we want to identify the set γ i of all its super-sequences present in the same database.
Identifying Characteristic Features Let us now turn to the second problem: finding, in an objective way, which parts of the community description are characteristic. The criteria used to identify this relevance must be compatible with our representation of a community, which takes the form of sets of sequential patterns. In the context of community interpretation, the problem of identifying characteristic features among the sequences representing a community consists in selecting some objective criteria to assess the representative power of these sequences, and a method to select the most representative ones. The representation defined in the previous section takes the form of a set Γ = {γ 1 , • • • , γ µ }, where each γ i represents the set of community-related super-sequences of a community sequence m i (as of the considered database).
Overview of our Evolution-Based Approach Our approach is based on the representation of dynamic attributed networks under the form of sequences. One sequence represents a node and its behavior: it contains the topological, attribute and community-related information describing it for each time slice of the studied period. Let us illustrate our approach on a small network of Jazz listeners, extracted from the data analyzed in Section 7. 2. This network includes 7 nodes whose connections are changing over 3 time slices. Each node corresponds to a user of the LastFM service, i. e. a listener, and each link represents a friendship relation between two users. We consider two nodal attributes: number of times a user listens to Miles Davis (a 1 ) and to Chet Baker (a 2 ) in the considered time slice.
Creating the Sequence Database As explained in Section 3. 1. 1, a sequence database is the collection of enlarged node sequences u enl (v) for all nodes in the network. Creating this database thus requires first calculating the topological measures and identifying the communities. Moreover, all real-valued nodal descriptors must be discretized to allow sequential pattern mining. Data preparation may also include some additional preprocessing, such as the binning of discrete descriptors or the combination of topological measures, in order to improve the readability of the obtained patterns, or to lighten the computational load.
Data Preparation As explained in Section 3. 1. 2, the descriptors used to fill our sequence database are either nodal attributes or topological measures. All the measures we selected are numerical, whereas the attributes can be of any data type, including categorical and numerical values. However, it is not possible to directly use real values as items for sequential pattern mining, because this method handles only discrete data. So, it is necessary to first discretize this type of descriptor. Moreover, even for integer descriptors, it can be interesting to bin their domains for several reasons. First, having too many distinct values in the domain of a descriptor tends to significantly increase the number of detected patterns while decreasing their support, thereby preventing to uncover results which would be sufficiently general to be informative.
Here, the corresponding sequences of a sequence s refer to all sequences with prefix s, i. e. the members of its projected database (c. f. [35]  for the explanation and formalization of this notion of projected database of a sequence). In  [38] , the authors claim the time complexity of the last step of CloSpan (pruning prefix sequence lattice, the most demanding step) is in O(n 2 ), where n is the size of the data (in our case: the number of nodes), if the maximum length of the frequent sequences is constrained by a constant.
Identifying the Emerging Patterns The emergence is assessed by processing the growth rates of the sequences, as described in Algorithm 1. CloSpan outputs all the CFS related to the considered database, as well as their support, and these data constitute the input of our algorithm, together with the database M itself. Each sequence is processed separately. The first step consists in determining if the sequence is relevant. Indeed, CloSpan identifies both the sequences showing general trends over the whole network (i. e. community-independent CFS) and those relative to community sequences (i. e. community-related CFS). In our situation, we need to focus only on the latter, so it is necessary to first separate them from the former. This is done through the function isCommunityRelated, whose complexity is in O(θ ), where θ is the size of the longest possible sequence.
To this aim, we need to retrieve the supports of both these sub-sequences. We use the function processSup to process the growth rate of a given sequence s. It first looks s up in the CFS outputted by CloSpan: if the sequence is closed, then its support is directly available. Otherwise, it must be processed. This requires considering each node sequence from the database M (O(n) operations in the worst case), and checking if it is a super-sequence of s (O(θ 2 ) operations in the worst case). The total complexity of the function is therefore in O(θ 2 n). Using the supports, the growth rate can be processed in constant time thanks to the function processGr. It can then be used to discard non-emerging sequences according to our min gr threshold. On the contrary, emerging sequences are added to Γ.
The attribute values are generated so that they are completely homogeneous inside each community (degenerate distribution). Moreover, these values are not affected by time. In the second experiment, our aim was to see how our framework is affected by changes in the evolution percentage of attributes q. For this reason, we fixed |A| = 3, again with a degenerate distribution, and modified only q. Finally, in the third experiment, we changed the distribution type h, whereas the number of attributes and the attribute evolution percentage were fixed at 3 and 5, respectively. For each experiment, we extracted the node sequences, added the LFR-generated community to get the enlarged node sequences, and built a sequence database. We then applied CloSpan with min sup = 10 nodes, and processed the growth rates of the identified CFS.
The preparation of the attributes is system-dependent, and is therefore described later. We built the sequence database M from the resulting descriptors and communities, and applied the process described in Section 5. 2. We interpreted all the identified characteristic patterns, but it is obviously not possible to present them all in this article. We therefore focus on the most representative, interesting and/or relevant ones, in terms of interpretation of the communities, in order to give an example of how our method can be used and how to comment its outputs.
Data and Preprocessing DBLP is a bibliographic Website focusing on Computer Science works. We selected the dynamic co-authorship network of Desmier et al. [14] , extracted from the DBLP database. Each one of the 2145 nodes represents an author. Two nodes are connected if the corresponding authors published an article together. Each time slice corresponds to a period of five years. There are 10 time slices in total, ranging from 1990 to 2012. The consecutive periods have a three year overlap for the sake of stability. For each author, at each time slice, the database provides the number of publications in 43 conferences and journals. We used this information to define 43 nodal attributes corresponding directly to the individual conferences and journals, and 2 additional ones representing the total number of conference and journal publications, respectively.
We consequently have a total of 45 nodal attributes. The conference/journals we selected are related to the subjects of database, data mining, knowledge discovery, information retrieval or artificial intelligence. To lighten the computational load, we decided to bin their values. For a journal/conference publication, we determined 5 categories, corresponding to the number of publications 1, 2, 3, 4 and greater or equal to 5. For both attributes representing the total conference and journal publications, we defined 5 categories as well, but they correspond to different ranges: [1; 5], ]5; 10], ]10; 20], ]20; 50] and ]50; ∞[. These thresholds were determined according to our knowledge of the domain. For the mining step, we used min sup = 21 nodes, min gr = 1. 00 and max seq = 5. We obtained 1106108 closed frequent sequences with these parameter values, 19922 of which ( 1%) were community-related.
Data and Preprocessing LastFM is a music Website that allows its members to register and listen to music online. It is also a social network platform, because the members can declare friendship relationships. In LastFM, members can join predefined groups related to their music tastes, and declare their participation to music-related events such as concerts. We extracted a network by focusing on the members of the Jazz group, which is supposed to include users appreciating this type of music. We took advantage of the LastFM API and of the Jazz group statistics provided by LastFM to retrieve its members and identify the highest rated artists and event types for this group. It is interesting to notice that, although all the members we are interested in are from the Jazz group, the selection of the most popular artists include acts from music types which are very different from Jazz, such as the Beatles or Pink Floyd.
Interpretation The evolution of the LastFM communities is generally smoother than for DBLP. We observe relatively large communities at t = 1 and 2, and communities tend to evolve most of all through small-scale events (by opposition to largescale events such as split or merge). We want to remind the reader that this LastFM network describes an evolution over one year, while the DBLP network represents a 18 years period. So not only the systems, but also the temporal scales are different. Table  4  shows the characteristic patterns ob-tained for three communities, which we use in the rest of this section to answer three questions regarding these data. Like for DBLP, we identified many community sequences and their characteristic patterns. We focus our comments on a few of them, in order to illustrate how our tool can be useful, through three questions the end user interested with these data is likely to ask himself.
However, note the term homogeneous applies here to the descriptors constituting the patterns: different descriptors, especially nodal attributes, can actually have very close meanings. For instance, we showed a community of DBLP was characterized by several distinct patterns all related to journals and conferences from the Data Mining filed, i. e. thematically very similar. The existence of several trends for the same communities means we have distinct subgroups of nodes supporting them. These subgroups are mobile, in the sense they switch from one community to the other. This is related to our previous remark regarding the fact the community structures of these networks are significantly changing from one time slice to the other. This can be a feature of the studied system, but it can also be an artifact of the community detection method, so this point should be considered carefully when applying our method.
We also used two real-world networks to validate our method. The first is a DBLP network showing the evolution of co-authorship connections over 18 years. We identified the presence of several trends in most communities, corresponding to subgroups focusing on different journals and conferences. These scientific platforms are connected to the same field, though (e. g. Data Mining, Artificial Intelligence, etc. ), which reveals a certain thematic homogeneity in a community. The second network is extracted from LastFM, and represents the evolution of Jazz listeners, their friendship relations and listening habits for the year 2013. For this network, we also characterized thematically certain communities, depending on their favorite artists. We also identified a group of users which actually do not listen to Jazz.
We also ran the single-point method REAP  12  on each simulated sample. REAP has been developed to estimate kinship and inbreeding coefficients in admixed samples using individual allele frequencies, i. e. allele frequencies weighted by the genomic proportion of the different ancestries estimated by Admixture 16 software. Figure  1  shows the difference between FSuite estimates and true f value (Δ f) against the true genomic proportion of European ancestry (ADM CEU ) of the individual, for first-cousin offspring (1C), second-cousin offspring (2C), and offspring of unrelated parents (OUT, as outbred) (see Figure  S1  for more remote inbreeding). For FSuite, the quality of estimation was measured by a Q-score (see Methods). Based on simulations, estimation was defined as low quality if the Q-score was less than or equal to 50, this threshold being adequate to check whether the allelic frequencies were adapted for the f estimation (Table  S1 ).
The choice of RELPAIR was motivated by our previous conclusion that multi-point methods are robust for admixed individuals. We detected 15 unreported relationships closer than first-cousins: 8 parent/offspring relationships (including one trio), 3 full-sibs, 1 half-sib, 3 avuncular relationships (Table  S3 ). We thus excluded 14 individuals to estimate population allele frequencies. FSuite was then run independently on individuals from each of the 26 TGP populations totaling 2,504 individuals. Only 7 individuals coming from 3 populations (ASW, PEL and ITU) had a low-quality estimate (Q-score ≤ 50). Among the 2,497 remaining individuals, 595 individuals were inferred as inbred, which represents nearly a quarter of the panel (Tables  1  and S4 , and Fig. 2 ). These individuals were mainly of SAS and AMR super-populations, with 45% and 41% of inbred individuals, respectively.
Methods Inbreeding estimation and detection with FSuite. FSuite is a pipeline that allows running FEstim software  22  on multiple submaps minimizing LD of the data  23. To model the HBD process of an individual, FEstim uses a hidden Markov model (HMM) in which the emission probabilities depend on allele frequencies. Its Markov chain depends on two parameters f and a, defining f as the individual inbreeding coefficient and 1/(a(1f)) as the expected length of HBD segments (here cM), that are estimated by maximum likelihood. FSuite estimates f as the median value of the estimates obtained on the different submaps after removing the ones with a > 1, and thus calculates a quality Q-score of each estimate as the number of submaps that have not been removed. FSuite also uses FEstim likelihood computed on the different submaps to estimate whether an individual is inbred or not by a likelihood ratio test testing if f is significantly different from 0.