dataesr/scientific-paragraphs-categorization huggingface dataset:
5 =⇒ M = M re f • T T re f 3/3. 5 (9) Figure  10  compares the evolution of this law (Equation (  9 )) to real data from two manufactured motors: Parvex NK  [35]  and Kollmorgen RBE  [36]. It is observed that a single reference of a motor allows to rebuild the evolution of the motor mass for a broad range of torque. This is possible with less than 10% of the mean relative error. In the same way, and following the same hypothesis, the other motor characteristic laws are formulated. Table  3  presents them with their prediction level compared to the Parvex NK catalog. The prediction levels compared to the RBE catalog are presented when data are missing in the Parvex catalog. Both catalogs validate the presented laws. d i other motor dimensions [m] h convection heat exchange coef. [J • K -1 • m -2 ] J current density [A • m 2 ] L motor length [m] ρ copper resistivity [ohm • m] T electromagnetic torque [N • m] T * = d * 3.
Results In this section, some real application cases are discussed to illustrate the previously presented methodologies. The methodology mentioned in Section 2 is implemented as a graphical user interface (GUI) web application based on a Jupyter Notebook calling functions through Python scripts. The GUI is developed with a dashboard named Voila. The tools developed in Section 4 are included with an optimization algorithm (differential evolution). Different specifications from real application cases are executed into this sizing code and the output results are presented. These specifications are arbitrary or linked to redundant topologies of actuation and to two different helicopter use cases: the main rotor and the tail rotor. The considered actuator architecture is provided in Figure  20.
Public blockchains, like Ethereum, rely on an underlying peer-to-peer (P2P) network to disseminate transactions and blocks between nodes. With the rise of blockchain applications and cryptocurrencies values, they have become critical infrastructures which still lack comprehensive studies. In this paper, we propose to investigate the reliability of the Ethereum P2P network. We developed our own dependable crawler to collect information about the peers composing the network. Our data analysis regarding the geographical distribution of peers and the churn rate shows good network properties while the network can exhibit a sudden and major increase in size and peers are highly concentrated on a few ASes. In a second time, we investigate suspicious patterns that can denote a Sybil attack. We find that many nodes hold numerous identities in the network and could become a threat.
Beyond security considerations, previous studies on the Ethereum P2P network lack a well described and reproducible methodology to produce their datasets. Moreover, no study so far analyzed the network with a focus on the suspicious behaviors that can threaten the proper functioning of structured P2P networks. Producing new knowledge about the Ethereum P2P network is important as it is but not sufficient as potential weaknesses should also be mitigated. That is why we propose, in a second time, a novel architecture to prevent possible attacks caused by suspicious nodes. Our contributions are thus manifold. To begin with, we designed and implemented the first crawler for the Ethereum P2P network which code is opensource and methodology assessed. Secondly, we created two datasets containing one month of measurements conducted in September 2021 when the network was stable for several months, and between February 15th-March 7th 2022 when we observed a sudden rise in the number of nodes.
We made them publicly available, and we performed their analysis by considering a few metrics that can impact the network reliability. In particular, we are the first to consider and enumerate suspicious nodes. Our third contribution is an architecture we designed and implemented to prevent Sybil attacks by revoking suspicious nodes in a safe and distributed manner. The rest of the paper is organized as follows. Section 2 presents the background on the Ethereum P2P network and its protocols. Then, Section 3 surveys the previous work conducted on this network as well as more general questions concerning the security of similar P2P networks. In Section 4, we present and validate our crawling strategy to constitute a dataset. Its analysis is conducted in Section 5 with a special focus on high-level network properties and the detection of suspicious nodes.
To the best of our knowledge, Ethereum uses a DHT for the peer discovery process (Section 2) and this information cannot be used to infer real (TCP) connections between peers (being neighbours in the DHT does not mean that there exists an edge in the P2P network between them). Concerning the overlay topology, Li et al. [13]  gathered in 2020 a dataset based on passive monitoring of Node Discovery traffic at the border routers of an ISP (Internet Service Provider) in order to visualize the topology of the P2P network. They validate this dataset by assessing the availability of the discovered node through TCP connections. They found that the network is composed of about 10,000 nodes. They generated a topology visualization graph that shows that most of the nodes have a small degree and excellent connectivity.
From these measures, they derived features such as nodes degree and transactions broadcast latency. LocalFullNode is used to validate their methodology. They found that the average degree of Ethereum nodes is 47, but a few nodes have a degree greater than 1000. They also found that the messages within the network are broadcasted to most of the Ethereum nodes within 6 hops. This denotes that the Ethereum P2P network has the property of small-world: nodes are connected to a small subset of the entire nodes but most nodes can be reached in a few hops. Unfortunately, those previous studies did not assess their crawler accuracy nor made their crawler or dataset publicly available which make it impossible to build upon them. That is something we aim to correct in this study.
P2P Network Security P2P network security has been a vast subject a decade ago. The main well-known threat to public P2P networks is the Sybil attack  [15]  where a given entity creates many peers to gain the control over a P2P network. Several concrete applications can be performed once Sybil nodes are inserted in the network, like network partition or eclipsing data  [16]. Such attacks were successfully launched on KAD, which is another large-scale public P2P network based on Kademlia  [17, 18, 19, 20]. Steiner et al. [17]  injected 2 16 Sybils from a single computer in a small zone of the DHT, so that they were able to catch most of lookup requests for data indexed within this zone. Wang et al. [18]  managed to partition the DHT and to do massive denial of service attacks with few resources by overwriting the IP address of legitimate contacts in peers' routing table.
To summarize, previous measurement studies lack a well documented and reproducible methodology to produce their datasets. In particular, the datasets and tools they used are not available. Moreover, to the best of our knowledge, no study so far analyzed the P2P network with a focus on the suspicious peers that could threaten the proper functioning of structured P2P networks. On the opposite, the tools we developed in our work and the datasets we made are open-source and publicly available, making our results fully reproducible. Moreover, analyzing Ethereum's P2P network with a focus on suspicious peers and providing a way to revoke them is totally new.
The sender is considered verified if it has answered to a PING within the last 12 hours. So, our crawler constantly listens to PING messages and responds with the corresponding PONG. The crawling methodology of our software is depicted in Figure  2. First, Crawleth tests the connectivity of the bootstrap nodes (which IP addresses and Node IDs are retrieved from the Geth client source code where they are hardcoded) by sending a PING packet and waiting for the PONG response. Then, for each responding node, it sends a FINDNODE packet with the target parameter being the bootstrap Node ID itself. The FINDNODE requests used by our crawler are always centered on the contacted Node ID, where its routing table has the highest precision because the buckets are the deepest (more contacts are known). The recipients will answer with a NEIGHBOR packet containing sixteen close nodes to itself, in terms of Node ID XOR distance.
Technical Setup The machine we used is an Ubuntu 18. 04 LTS computer with an Intel Xeon Processor E5-2420 v2 6 cores, 16GB RAM and a 1 Gb/s network link. To handle the large number of network connections needed, we had to increase the opened files limit of our GNU/Linux system to 1,000,000. The machine operates the crawling node 24 hours a day, 7 days a week. It is worth mentioning that our infrastructure lacked an IPv6 link and TOR proxy, thus all the discovered nodes are IPv4 nodes. Nevertheless, as we will see in the Section 4. 3 other tools like Ethernodes or Etherscan NodeTracker do not integrate such nodes either. Concerning TOR, it seems impossible at first glance to find a node using the TOR network as TOR transports data over TCP and Ethereum needs UDP for node discovery. Although it is possible to manually bootstrap a node with known peers of the network and disable the discovery mechanism, it is very unlikely to happen since this workaround requires a tedious manual management of contacts to keep the node connected, what is normally devoted to the Node Discovery Protocol.
Ethereum's Network Analysis This section analyses the data gathered by our crawler during two significant periods: the month of September 2021 and between February 15th and March 7th, 2022. September 2021 is representative of the state of the network since the deployment of our crawler. And in February 2022, we observed a sudden and massive increase in the number of the nodes that deserves a particular focus. Our analyses consider network characteristics that can impact the reliability. The two datasets are publicly released  [27]  with the sole limitation that IP addresses had to be pseudo-anonymized following ICANN recommendations  [28]  that offers an acceptable compromise between utility and privacy. More precisely, a salted hash is provided and the last byte of the IP address is set to 0.
Number of Nodes and Distribution The first metric that we can derive from our datasets is the size of the network and the geolocalization of the nodes. As we can see in Figure  5 , the size of the network was quite stable for 7 months (between July 2021 and January 2022) since the deployment of the crawler with a slow but regular grow increasing the number of nodes from 16,000 to 22,000 over the period. Then, the number of nodes rapidly rose on February 23rd 2022 to an ephemeral maximum around 42,000 nodes and declined after to reach a new plateau at 32,000 nodes by early March. Some notable numerical results can also be found in Table  1. In total, when also including the unreachable nodes, Crawleth discovered approximately 30,000 nodes per crawl in September 2021 compared to the 16,000 reachable nodes.
Inventory of suspicious nodes The reliability of P2P networks is mainly based on the proper distribution of the workload on many independent peers. That is why any group of nodes that seems to tamper with the homogeneous distribution of the workload among peers might be dangerous, whether it be an abnormal usage of the network, a wrong configuration, or an intentional Sybil attack. Whatever the root cause, our goal in this section is to make the inventory of nodes that seem to concentrate too much weight in the network and therefore might be considered suspicious. We consider three categories of suspicious nodes that could be linked because they share a common IP address or a same subnetwork or very close Node IDs. More precisely, we want to identify in our datasets : -a sub-network (/24) containing more nodes than 10% of its size; -an IP address carrying more than two identities (Node IDs defined by the public keys); -Node IDs statistically too close in the distributed hash table compared to the theoretical uniform distribution.
For the whole month of September, in Figure  9  we can see that the distribution of size of the shared prefix length between two direct neighbours in the DHT is well distributed, despite irregularities at the end that are not very significant. To confirm, we show in Figure  10  the deviation between measured and theoretical data, represented by the equation that gives the mean number of peers sharing a common prefix, given the total number of peers in the network: N 2 x. Our crawler could find 439,561 unique Node ID, so N = 439561 here. We can see that there is no obvious deviation between neighbours in the DHT. We observed the same tendency in our dataset from February 2022. Nevertheless, it is possible that a few small localized attacks can occur but would not be visible in statistics calculated at the network level.
Smart Contract We designed the smart contract presented in the Listing 1 to use event logs to distribute the information about suspicious nodes. In the Ethereum blockchain, every block has a logsBloom field which allow any user to search for a specific transaction log (along with the indexed fields from the log). These logs are publicly accessible and can be regenerated from the transaction holding it. The event in our smart contract publishes the enode (NodeID@IP:Port) of the suspicious nodes but in a structured way to 1) save space in the smart contract by factorizing the information common to a group of suspicious peers, 2) make the verification process easier. Each group of suspicious peers has the data stored differently according to the threat for which they have been identified (labeled as "Subnet", "Groups" and "Aliases" in Listing 1).
It is represented in the right part in Figure  11. Any user that has deployed an Ethereum node can use this program to prevent its node to keep a connection to a suspicious node. It uses the JSON-RPC API (Remote Procedure Call protocol encoded in JSON) of the official Geth client. Specifically, it uses the "Admin. removePeer" call that is undocumented but exists since 2016  [37]. It can remove any active connection (inbound or outbound) to a specific peer. Because there is no RPC yet to enforce the blacklisting of a node, our tool must periodically check if the local Ethereum clients it protects has connections to known suspicious nodes. An implementation directly within an Ethereum client would make the revocation process more efficient by also sanitizing the routing table and by preventing the suspicious contacts to be shared among peers.
In addition, Kostamis et al. [39]  studied the cost and practicality of different storing methods in Ethereum. The facts that the event logs are immutably stored and can be replayed to retrieve ancient states make them interesting to use. All operations executed by a smart-contract have a cost in gas (which is derived from ether) but using event logs is one of the cheapest way to store data in the Ethereum blockchain. They described another way to store data, by using transaction payload. It is cheaper than event logs but it requires to store the hash of the transactions in an external database to retrieve an ancient state. It increases the complexity of the architecture and the external database may not be as immutable as the Ethereum blockchain. For the reasons mentioned above, we use the Ethereum blockchain to store and distribute the information about the suspicious nodes.
Conclusion In this article, we first presented our open source crawler for the Ethereum P2P network. We demonstrated its soundness and analyzed two one-month datasets that we also released. The results show that the Ethereum P2P network exhibits good properties like a decent geographical distribution and a moderate churn rate, but also more concerning ones like a centralization of the nodes in a few ASes. The size of the network has been stable for several months but suddenly rose to double the network size at its peak, without obvious explanation nor pattern that could characterize the newcomers. Then, we considered three categories of threats that denote a risk that a group of peers likely controlled by a single entity get too much weight in the network: a given /24 subnetwork running many peers, an IP address holding many identities, or groups of peers that are too close in the DHT address space.
Acknowledgements We thank  Christophe Belleut  and  Florent Caspar  for their initial work on Crawleth as part of an introduction to research in their school curriculum ( TELECOM Nancy, France ) which we supervised. We also thank  Ambroise Sander  for further work and improvement of Crawleth as part of his internship in our research group. This project has received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No  830927.
Tolerance modelling based on Skin Model Shapes Due to the importance of tolerancing decisions on the quality and cost of mechanical assemblies  [6] , tolerance modelling and analysis have been constant research topics during the last decades. As a result, various approaches to these issues have been elaborated and implemented in commercial computer-aided tolerancing (CAT) software tools. Due to the shortcomings of most of these methods, particularly regarding the missing consideration of form deviations and the lacking conformance to international tolerancing standards, the concept of Skin Model Shapes has been proposed  [7] , which utilizes discrete geometry representation schemes, such as point clouds and surface meshes, for the representation of variational parts and assemblies (see Fig.
Random deviations are added to these systematic patterns by a random field approach to enlarge the training pattern dataset. Pattern mapping. In the second step, the nominal CAD model of the mechanical part is considered as the input. To apply the geometrical deviation pattern on the part, a partitioning step is performed to segment the part into different surface portions such as planar and cylindrical surfaces. Then, the deviation patterns are mapped on the nominal points of the feature surfaces. The deviation patterns could be either those generated from GAN or a combination of several GAN-generated patterns. The deviation mapping process considers the different sizes, positions, and invariance classes of partitioned surfaces. Therefore, the partitioned planar surfaces are scaled, rotated, and deformed to derive the displacement value according to the generated deviation patterns.
Implementation, training, and validation The proposed workflow for the generation of Skin Model Shapes using GANs, including the deviation pattern generation method and the pattern mapping algorithm, was implemented in MATLAB. Specifically, for the deviation pattern generation, six systematic planar deviation patterns and six systematic cylindrical deviation patterns were created, which are visualized in Fig. 3  (colours indicate deviations from nominal). In this context, without losing the generality of our approach, these modes have been created by discrete cosine transform (DCT)  [15] , by natural vibrations modes Fig. 2. The GAN-based Skin Model Shape generation process. [16] , by metric modal decomposition (MMD)  [17] , and by Hermite-Fourier polynomials  [18]. This is because these systematic deviation patterns represent a large variety of realistic manufacturing errors, such as cutting force errors, spindle motion errors, or fixture errors.
While our current implementation of this approach involves a training set of 36,000 systematic and random form deviation patterns, future work will focus on the extension of the pattern database also considering surface roughness, which may lead to even more sophisticated applications of Skin Model Shapes regarding multi-scale and multi-physics tolerance analysis and pave the way to even more realistic digital twins in tolerancing. Moreover, ongoing research is focusing on further machine learning paradigms, such as transfer learning and manifold learning.
4. We update the boundary values of the potential vorticity q using Eq. (  2 ). Detailed equations and numerical routine design choices can be found in  [7]. We use a Heun-Runge-Kutta 2 time-stepping instead of the Leap-Frog time scheme used by  [7]. For sake of numerical efficiency, we follow the recommendation of  [14] : we compile computationally demanding routines and simplify finite difference calculations by reducing as much as possible the number of multiplications. We end up with a very concise code (less than 300 lines) that only depends upon Numpy and Pytorch libraries. This implementation will be open-sourced at the time of the publication.
Cisplatin and gemcitabine (C + G) corpus PubMed similarity searches of index articles (12, 13) combined with keyword searches of the Google Scholar database were used to identify articles that described either cisplatin or gemcitabine treatment of human cancer cell lines and/or cancer patients (see  the Materials and Methods section) (Fig 1   3  and S1 ). The 103 incorrect targeting sequences (Table  3 ) were claimed to interrogate 31 protein-coding genes and 16 ncRNA's (Table  S1 ). As in miR-145 articles, most incorrect sequences in problematic C + G articles represented (RT)-PCR primers (Table  3 ) and were identified once within the corpus (Fig  3 ). Almost all (50/51, 98%) problematic C + G articles were published by authors from China, where almost all (48/50, 96%) were affiliated with hospitals (Table  1  and Supplemental Data 3).
Materials and Methods Identification of literature corpora SGK corpus SGK articles were identified by combining each of 17 human gene identifiers (ADAM8, ANXA1, EAG1, GPR137, ICT1, KLF8, MACC1, MYO6, NOB1, PP4R1, PP5, PPM1D, RPS15A, TCTN1, TPD52L2, USP39, and ZFX) with the search string "cancer AND/OR knockdown AND/OR lentivirus"  (13) , to search PubMed and Google Scholar databases in June 2019 using the "allintext": function for Google Scholar searches. No publication date ranges, country-specific or journal-based search terms were used to limit search results. Articles were visually inspected to confirm that articles described gene knockdown experiments that targeted one of the 17 human genes in human cancer cell lines.
Manual verification of nucleotide sequence reagent identities Nucleotide sequence identities were manually confirmed for all sequences that were not (correctly) extracted and/or flagged as being possibly incorrect by S&B, as described (https:// www. protocols. io/view/seek-amp-blastn-standard-operatingprocedure-bjhpkj5n). For the Oncology Reports and Gene corpora, this involved checking at least 34% and 54% of all sequences, respectively. Further verification steps were performed for particular reagents, as follows: (i) For reagents that were claimed to target specific gene polymorphisms or mutant sequences and for which no sequence match could be identified by either Blastn or Blat  (28, 86) , manual sequence alignments were performed in Word with the query sequence in forward, forward complement, reverse and reverse complement orientations, against either the sequence corresponding to the accession number provided within the text, or to the most relevant genomic sequence found in NCBI GenBank, according to the text claim.