dataesr/scientific-paragraphs-categorization huggingface dataset:
ACKNOWLEDGMENTS Gene cloning, protein expression, and purification of the M protein and sfGFP were performed at the  Lund Protein Production Platform  ( LP3 ),  Lund University, Sweden  (www. lu. se/lp3). We highly acknowledge  Daniel Hatlem  from  D. L. 's lab  for his guidance during recombinant protein purification. We thank  Oonagh Shannon  for access to the different S. pyogenes serotypes. We gratefully acknowledge support from the  Swedish National Infrastructure for Biological Mass Spectrometry (BioMS). This research was supported by the  Viral and Bacterial Adhesin Network Training (ViBrANT) Program  funded by the  European Union 's  Horizon 2020 Research and Innovation Program  under  Marie Sklodowska-Curie  grant agreement number  765042  to J. M. and D. L. ; the  Swedish Research Council  ( 2019-01646 ) to J.
For example, the data transfer to a remote facility may induce non-negligible delays and slow down data processing and decision-making. For this reason, next-generation telecommunication networks such as 5G rely on services running at the very antenna stations to provide very low latency applications to the final users  [4]. Hence, Edge computing is a paradigm in which substantial computing and storage resources are placed at the Internet's edge in close proximity to mobile devices or sensors  [5]. Applications that rely on distant services may also freeze or fail if the network connection is unstable or faulty. Placing such applications on edge devices may allow at least a partial operation even in cases of network failure, enough to respect SLA (Service-Level Agreement) commitments. By using resources at the edge of the network, edge computing also promotes the idea of exploiting resources near to data production devices, reducing amounts of data transferred between IoT devices and cloud platforms.
Therefore, this paper explores these questions by performing practical experiments on a real edge platform, introduced in previous works  [10]. This experimental platform allows us to set very heterogeneous environments, connecting HPC (High-Performance Computing) servers and cloud nodes to small nanocomputers, allowing us to investigate the heterogeneity impact in communications, data storage, and service execution. Hence, the current paper uses that platform to develop the preliminary ideas for data locality control in P2P (Peer-to-Peer) networks initially presented in  [11, 12]. Thanks to the data locality control, we are able to evaluate the performance of uplink and downlink communications involved in a DHT (Distributed Hash Table ) storage process, and at several degrees (from the local network to the cloud).
To prevent such drawbacks, P2P-based platforms can be seen as interesting alternatives for the interconnection, deployment and management of edge computing devices, as their loose coupling brings the flexibility, scalability, and fault tolerance required on edge environments  [39, 40, 38]. In spite of a rich literature on fog and edge computing proposing infrastructures and platforms, a reduced number of works are dedicated to Edge computing benchmarking. Indeed, a recent survey 1  from  [41]  tries to identify these works and classify their contributions. It obseves that several works focus on developing benchmark tools that are widely inspired by other grid or cloud benchmark tools. In other cases, some works "rely on either trace data obtained from simulators or simulators for evaluation (which is contrary to the classic definition of benchmarking)"  [41].
This model corresponds to the BSP (Bulk-Synchronous Parallel) programming model  [45] , which is based on the succession of supersteps synchronized with a barrier. In the case of CloudFIT, if no assumption is made on the execution order of the tasks, the only constraint is that the data necessary for the next superstep is available at the time of the synchronization. • Task Synchronisation This fine-grain synchronization provides dependency between tasks, like a Directed Acyclic Graph (DAG). To do this, we simply modify the task scheduler to take into account the status of the tasks and a list of dependencies: a task will only be started if the tasks on which it depends have already been completed. Although this violates the first property of the FIIT model (independence between tasks), its implementation is simple and allows the deployment of other types of applications.
Architecture The CloudFIT architecture was designed as a software stack, inspired by the TCP/IP and OSI (Open Systems Interconnection) network models. Thus, we defined four layers representing the different functionalities of the platform, Network, Protocol, Service and Application. Despite its name, the Network layer is responsible for all interactions with third-party systems on which CloudFIT relies(P2P overlays, operating system, storage systems). For example, the Network Adapter class performs the basic encapsulation and decapsulation of messages, using primitives designed according to the capabilities of the subordinated P2P overlays (send,sendAll,receive, and so on). The same principle applies to the Storage Adapter class, where primitives like read,write, delete, lookup interface with different possible storage solutions (local files, DHTs, databases, cloud storage).
In this case, it is sufficient to provide access to a CloudFIT node through a REST (Representational State Transfer) or JSON (JavaScript Object Notation) interface for application triggering or data storage. Finally, the Application layer contains the elements needed to execute the application, especially the application interface that must be implemented by the user. The application interface is quite simple and intuitive, following the principles of the FIIT paradigm. Thus, the developer only needs to write the following methods: • numberOfBlocks() -method that returns the number of tasks to launch. This method is called during the configuration of the Task Scheduler; • executeBlock(taskID, required[]) -method that starts the actual execution of a task, delegated to one of the Workers. The taskID allows the task to customize its execution, and the required [taskID] element indicates any dependencies for this task, a parameter used by the Task Scheduler to manage the execution order to respect the dependencies; • finalizeApplication() -optional method that is executed by the Task Scheduler once the task set is completed.
Execution Model and Scheduling Multiple applications can be concurrently executed over the CloudFIT network, according to the available resources and application requirements. Both regular applications (mono-server) and distributed applications can be submitted, as CloudFIT coordinated the deployment and communication in the network. To do so, an application must be expressed as a finite set of independent irregular tasks that share the same execution code but work on different data segments, just like an MPI (Message Passing Interface) application. Please note that this strategy can be extended by adding dependencies between applications (like in the BSP programming model) or tasks (like in a Directed Acyclic Graph -DAG), allowing for example the implementation of map-reduce applications.
By distributing jobs according to the nodes' current execution context, i. e. , if two communities match the minimal requirements, the scheduler will deploy the job on the community that is less overloaded even if it is not the "most powerful" community. On the second layer, we found the "tasks" scheduler, a per-job sched-  uler that coordinates the execution of the tasks on each node. The basic scheduler algorithm in CloudFIT considers tasks as fully independent, so each node randomly starts a task and then diffuses the status of the tasks to the other nodes (in execution, completed ), updating the list of tasks still available for execution. However, as this scheduler is inherent to each job, it can be extended in several ways and applied according to the job's requirements. Therefore, to implement a data-locality aware scheduling, the presence of a data resource in the local storage is used as a factor to determine the tasks' execution order.
By assigning dependencies between tasks and data resources, we instrument the scheduler to prioritize tasks that have the required datasets already at hand. As shown in Fig. 4 , both layers base their scheduling decisions on data locality and context information, which are constantly updated according to the nodes' conditions. Additional context elements such as the currently available memory, CPU load, and disk space also permit the task scheduler to decide at runtime if a task can be started, avoiding penalizing an application because of an overloaded node. This context information is collected by a context collector like the one presented in Fig. 5 , which is integrated into the CloudFIT stack. This collector is based on the standard Java monitoring API, which allows us to easily access the real characteristics of a node.
Distributed Coordination The previous section illustrates the structuring and interaction of modules within a CloudFIT instance. However, a distributed computing platform must guarantee exchanges between the different nodes on the network. In the case of CloudFIT, the choice to use a third-party P2P overlay simplifies peer discovery operations, network management (inputs, outputs), message routing, etc. This allows us to focus on intrinsic platform communication, such as application deployment, execution progress monitoring, and result distribution/retrieval. Everything starts with the submission of a job, carried out directly by a node already connected to the network or through a submission interface. This submission contains the application code, the target community, and a list of properties required for the job to run properly.
A message containing the parameters and properties of the submission is broadcasted over the network, thanks to the P2P overlay communication mechanisms. To automatically deploy the application on the executing nodes, we chose to use the DHT storage associated with the P2P overlay. Indeed, DHT provides an access to objects and files, from the moment the nodes know the DHT key to these resources. Thus, submitting a job involves saving a jar file containing the application code and its storage key. When the job is launched, the JobScheduler retrieves the file and extracts its classes, which will be loaded using a classloader. DHT storage can also be used to provide input data for the applications, especially when a large set of data needs to be made available to the applications. This is not mandatory, since applications also can obtain the data from external services (Uniform Resource Locators -URLs, cloud storage, databases).
Data Locality in a P2P overlay When handling data on the edge, the first factor to consider is where data lies (the data locality). For any advanced application, edge nodes are not only gateways to the cloud but, instead, play an active role in data sharing, replication, and load balancing  [48]. To reduce the dependency on cloud storage services, P2P overlays can be used to provide decentralized data management  [40]  with the help of a Distributed Hash Table (DHT). DHTs use cryptographic hashing functions such as Message-Digest 5 (MD5) or Secure Hash Algorithm (SHA), providing a lookup service in which any node can efficiently retrieve the value associated with a given key. In the case of DHT storage, hashing is used to assign resources (data) to nodes that will hold a copy of this data.
Most DHT overlays use plain hashing functions that uniformly distribute and replicate their data across the network. Uniform hashing allows load balancing among the nodes and, in most cases, helps to prevent data losses when clients disconnect. However, it makes data transfer optimization harder since data locality information is lost  [49, 43]. While some non-uniform hashing functions exist  [50] , basic DHT storage is insufficient for data management in edge platforms, as we seek to control where data is stored. In recent years, the development of geographical databases and NoSQL boosted the research for performance improvement through co-located data  [51]. Most of these works concern specific data types like those found on geographical databases, whose queries can benefit from grouping data in a given area.
Hence, one can express the data location as a set of coordinates, used to generate a geohash key  [52] , or to identify zones like in CAN (Content Addressable Network)  [53] , quad-tree hashing  [54]  or in a Voronoi overlay network  [55]. [43]  propose the use of external storage services such as Cassandra (a P2P database), which can be configured to segment the network in data centers. In all these works, the network partition scheme is often predefined, which created a strong dependency between the partition, the nodes, and the applications that can be executed on these nodes. As none of the cited works efficiently deal with dynamic environments and ephemeral applications deployment, we proposed in  [11]  a pure P2P solution that ensures that data segments for the application are distributed preferentially among the nodes that will execute that application, all in a dynamic environment where nodes can join or leave the network.
Round 1: Local vs Cloud Storage While Big data strongly relies on data locality to improve its performance, it usually considers quasi-homogeneous networks with high-performance interconnections. When dealing with edge computing, however, data locality has a potentially higher impact as not only communications and data transfers can span from the local network to the cloud, but also because devices are inherently heterogeneous. We present here different experiments to evaluate the impact of network latency on the performance of a DHT. By default, CloudFIT (the fog/edge platform used for the benchmarks) supports a robust distributed scheduling based on work-stealing, allowing nodes to execute different tasks in parallel when they can communicate to each other or, in the worst case, to complete all the computation by itself.
This original scheduling was modified to include the possibility to reinforce data locality, as proposed in Section 4. 1, for better control on the data storage and retrieval operations. In a first experiment, we used the CloudFIT platform to interconnect nodes in a local cluster and nodes in the Google Cloud Platform (GCP). The local machines are identical (AMD Opteron 6164 HE, 12 cores, 48 GB RAM) and interconnected by a Fast Ethernet network. GCP machines are of type n1-standard-2 (2vCPU, 7. 5 GB RAM) and located at the us-central1-c zone. Three situations were considered: data storage/access in the same machine, in a close node (same LAN or enterprise network), and over distant nodes lying in the cloud. The first case represents the situations where the application can obtain data directly from its own DHT instance, or when it wishes to store data locally to favor a subsequent task (therefore, using data locality).
The same network situation represents an intermediate case where the data is located in a nearby server (perhaps a node that has more storage capabilities and serves other nodes in the network). Finally, the last situation represents the cases where the data lies far from the node, like when data-locality techniques were not used. The experiments performed write and read operations on the DHT, with file sizes of 1 kB, 10 kB, 100 kB, 1 MB, 10 MB, and 100 MB. These file sizes cover the typical Big data storage block sizes: for example, Hadoop HDFS uses 64 MB or 128 MB data blocks. At each run, the CloudFIT platform was shut down and the files were removed. Also, the order of the files was shuffled to prevent pipeline effects on the network, and at least 10 runs were executed for each situation.
Also, communication policies for small messages (buffering, Nagle's algorithm, TCP NODELAY option, etc. ) may delay transmission is some cases and not in others. Even the cloud seems more efficient when writing small messages (less than 10kB), but latency and throughput rapidly increase the cost of cloud operations. As such discrepancy only is observed on really small filesizes, we believe that its impact on applications that rely on DHT data storage is limited. Both read and write observations encourage the use of data locality to improve the performance of edge applications. Indeed, if we can control the community boundaries, it is possible to finely adjust the distribution pattern according to in/out performances and data sizes.
0 hard disk, and memory-only storage. The comparison between the MicroSD and the external USB disk drive is motivated by their relative performance differences: a class 10 MicroSD should support at least at 10 MB/s when writing (with a reading speed depending on the constructor), while a USB external disk on a Raspberry Pi 3 can reach at most 20 MB/s. Further, as both methods suffer from bottlenecks due to the Raspberry Pi chipset configuration, we also included memory-only storage tests in our experiments. This latter option could benefit volatile datasets that will be discarded after being processed, like in the example of "gateway" nodes that store intermediate data and preprocess it before sending it to other nodes. The experiment protocol (number of runs, DHT reset, etc. ) is similar to the previous benchmark.
This means that, at least for 100 MB of data, the DHT storage caused no bottleneck on the disk access. This scenario is quite different in the opposite direction (Figure  15 ), where the cost of storing data in the Raspberry Pi is much higher if it involves persistent storage. Knowing this information is useful as it can help identify the best role for SoC devices in the edge network. This asymmetrical performance is also seen in the read benchmark. While the reading performance is similar whether we use disk or memory storage, the absolute values are several orders different according to the direction of the operation (PC → Pi or Pi → PC). Hence, the cost for a Raspberry Pi to read 100 MB from an external node is almost three times higher than when reading from the Raspberry Pi. As this difference disappears for data smaller than 1 MB, we suspect that the overhead is related to the buffering and serialization/deserialization operations on the receiver node.
Furthermore, data size is a key aspect to consider, and the experiments point that, at least with the TomP2P DHT, data chunks should not exceed 10 MB as all scenarios exhibit substantial cost overheads when manipulating large datasets. To conclude this section, these experiments demonstrate that edge computing should not only be concerned by the latency impact on the services but also on the capability of each computing node to perform its tasks efficiently. Choosing whether to deploy an application is a complex task, with several strategies and optimization heuristics to consider  [56]. Hence, as artificial intelligence applications become faster and less demanding in resources, IoT, mobile, and edge devices are now in the front line. Similarly to the work of  [57]  on energy-awareness, intelligent planning on the data flow in edge environments can lead to significant improvements in the data storage, transfer, and processing performances, benefiting both the users and the service providers.
For doing so, we also base our experiments on the CloudFIT platform. As detailed in section 3. 2, Context-awareness is achieved by allowing nodes to decide by themselves about their capability to execute a task. By exchanging information with other nodes, they can drive the placement of replicas and tasks, resulting in a distributed architecture in which nodes collaborate to satisfy the user's demands. The scheduling mechanism we use was initially proposed in  [12]  and is structured in two layers that observe both the execution and the data locality contexts. We call "job" the application to be executed, which in turn describes its needs and may split its execution into several "tasks" that may be carried independently by the platform nodes. Hence, in the first layer of the scheduling mechanism, a "job" scheduler observes the execution context of the node, verifying whether current conditions allow a job (and its tasks) to be run w.
To overload the machines, we use the stress-ng tool 3  and the parameters stress-ng -c 0 -l 50 to occupy 50% of the available CPU utilization. The metric used in the experiment is the CPU system load average over the last minute, a popular metric from Linux systems, being present in tools such as top. This metric represents the number of processes being or waiting to be executed over the covered period. In a single (virtual) processor node, any value above 1 indicates a high concurrency for the CPU, which may delay the execution of the applications. In the first experiment, we execute the set of 50 tasks in a network where two machines (nodes m3 and m4 ) are overloaded, and no context-awareness is in use. The Figure  17  represents in a Gantt chart this execution. The lines represent the current load average (in solid red) and the 100% threshold (in dashed blue).
MDS is an efficient gap-filling method that supplements the look-up tables with diurnal cycle interpolation, allowing it to function when there are gaps in predictors. However, MDS performance can be limited by the number of permissible predictors and current predictor choices are optimized for CO 2 , not CH 4 fluxes  (Falge et al. 2001). Moreover, unlike CO 2 fluxes, CH 4 fluxes at many sites appear to lack a consistent diel cycle and display different diel patterns  (Bansal et al. 2018). In contrast, ML is well suited to high-dimensional datasets and can capture nonlinear relationships between predictors and fluxes  (Tramontana et al. 2016; Bodesheim et al. 2018 ) albeit they generally need more time to train and evaluate. A summary of some of the methodological considerations for MDS and four different ML algorithms considered in this study are shown in Table  1.
g. , ebullition events) may also be less easy to capture in training and test data  (Ueyama et al. 2020b; Taoka et al. 2020). In sum, the combination of high temporal variability of CH 4 flux within and across sites  (Knox et al. 2019) , high spatial variation of fluxes in some wetlands  (Morin et al. 2017) , and the sensitivity of fluxes to a suite of drivers at different timescales  (Sturtevant et al. 2016) , requires a thorough evaluation of CH 4 flux gap-filling models across a broad range of possible gap lengths. This study provides a systematic evaluation of MDS and four ML algorithms for gap-filling CH 4 fluxes at 17 FLUXNET-CH4 sites. The sites cover a wide range of wetland types, and climate and gap conditions (i. e. , length and distribution). Collectively, these sites provide a large and fairly standard set of predictors, allowing for a robust acrosssite comparison of model performance and predictor importance.
The overall ML workflow from artificial gap generation, to cross validation and testing, and to prediction uncertainty estimation, is robust and reproducible  (Pastorello et al. 2020; Nemitz et al. 2018 ) and designed to be general and applicable to a wide range of gap-filling scenarios across terrestrial wetland ecosystems. The data and code are made public [https://github. com/stanfordmlgroup/methane-gapfill-ml].
Site Data Seventeen managed agricultural (i. e. , rice paddies) and natural wetlands were selected from Version 1 of the FLUXNET-CH4 database  (Delwiche et al. 2021)  for the comparison of gap-filling methods (Table  2 ). Selection criteria of the sites included: 1) at least one calendar year of measured fluxes; and 2) a complete set of measured physical and biological predictors, including soil temperature and water-table depth (Table  A. 1). Although FLUXNET-CH4 contains other ecosystem classes, including several upland cover types, lakes, and mangroves, these ecosystems were beyond the scope of the present study. The 17 sites span tropical to boreal climates and diverse and representative wetland types (Figure  1 ), including bogs (5), marshes (5), fens (4), a tropical swamp (1), and rice paddies (2).