dataesr/scientific-paragraphs-categorization huggingface dataset:
On the origin of the CHEOPS single transit event In all of the above, we assumed that the single transit event caught by CHEOPS was caused by ν 2 Lupi d. However, one might ask whether this transit may instead be caused by an additional yet-unknown planet in the system. The single transit event that we detected in the fifth CHEOPS visit is partial (i. e. the observations did not cover the end of the transit), hence its duration is not well constrained. Additionally, the observations also did not cover the ingress which occurred during an Earth occultation. Because of that, the impact parameter and orbital period are very poorly constrained. Some more constraints on the orbital period may come from the other photometric observations, especially the 28-day long TESS observations. A ∼9hr-long transit with a ∼500 ppm depth would have been very clearly detected in these data (see for example how the transit of ν 2 Lupi c, which has a similar depth, appears clearly in Supplementary Figure  4 ), meaning they can be used to exclude some orbital periods.
To assess the constraints brought by the photometry on the orbital period of the transiting object, we performed a combined fit of all the CHEOPS and TESS data with juliet. We assumed the same normal priors as previously for the stellar density and nuisance parameters and wide uniform priors for the planet parameters (see Supplementary Table  3 ). For the third transiting planet corresponding to the CHEOPS single transit event, we assumed a uniform prior between 30 and 1000 d for the orbital period, and a uniform prior between 2,459,009. 6 and 2,459,010. 0 BJD for the mid-transit time. The posterior distributions of the fitted parameters for the third planet are shown in Supplementary Figure  8. A wide range of orbital periods are compatible with the photometry, with a 3-σ upper limit of 624 d.
The few blank vertical stripes seen in the corner plot for some orbital periods (e. g. around 185 d and 370 d) correspond to periods that can be excluded based on the TESS data. To assess the possibility of a fourth unknown planet in the system, we also searched for some additional signals in the HARPS radial velocities. We computed the 1 periodogram  85  , which searches for several periodic signals simultaneously and thus is less prone to show spurious peaks due to aliasing than a regular periodogram. The 1 periodogram (see Supplementary Figure  9, top)  shows two possible peaks around 123 and 485 d, but with high false-alarm probabilities of 14. 5% and 9. 6%, respectively. We note that the signal at 123 d was already discussed by ref. 1  , who came to the conclusion that it was more likely an artifact induced by noise in the data or interaction with the window function (period ∼1/3 of a year) rather than an additional planet in the system.
This candidate signal at 123 d can thus be discarded. For the 485 d signal, we find that 0. 02% of the derived P (481. 72 +17. 35 14. 88 d) and T 0 (2, 455, 727. 22 +20. 63 18. 89 BJD) posterior samples are compatible with the photometry. By way of comparison, this is 20 times less than the corresponding percentage of 0. 4% obtained for ν 2 Lupi d. As a complementary check, we performed two more global analyses of all the data (CHEOPS, TESS, HARPS) assuming a fourth planet with a period of 485 d (planet e). For one of these analyses, we assumed that planet e is responsible for the CHEOPS single transit event ("4 planets -e transiting" model) and that planet d was thus not detected in transit in the photometry. For the second one, we assumed the opposite, i. e. that planet d is responsible for the CHEOPS single transit event and that planet e is not detected in the photometry ("4 planets -d transiting" model).
Our simpler reference model is thus the best model given the data at hand. Finally, we also assessed the possibility that the CHEOPS single transit is caused by a fourth planet that is completely undetected in the HARPS RVs. A detailed computation of RV detection limits, via injection and recovery tests, is beyond the scope of this paper. To estimate the detection limits of the HARPS dataset, we instead used the results of the radial-velocity fitting challenge reported by ref. 86. They showed that signals with a semi-amplitude K ≥ 7. 5 RV rms / √ N obs , with N obs the number of data points and RV rms their RMS, are typically confidently detected in RV time series. For our HARPS dataset, we have N obs =246 and RV rms =1. 37 m/s after removing the signals of the three known planets, yielding a detection threshold K=0.
This is not the case of ν 2 Lupi c and d, whose lower densities suggest that they are likely volatile-rich and have small gaseous envelopes (see the 'Internal planetary structures' Section). Hence, we assumed a tidal dissipation factor similar to Jupiter's value  102  , k 2 ∆τ ∼ 2. 5 × 10 -2 s, and explored a range of 1 -100 times this value  103. We then performed a suite of simulations with the N-body code POSIDONIUS  104  , which includes the effects of tides, rotational flattening, and general relativity, using the same prescriptions given by ref. 105. We found that the innermost planet b evolved into a pseudo-rotational state rapidly; that is, into a tidally locked configuration where its orbital and rotational periods became synchronized, and its obliquity close to zero, so that its orbital axis became aligned with the spin axis of the star.
Since planet d has an equilibrium temperature above 400 K, hypothetical rings should be water-free and presumably silicate-rich, with ρ r 3 g/cm  3. With the parameters in Table  1 , we get R r = 2. 4 R p which leaves open the possibility for planet d to have enough space for rings in its Roche zone. Either the rings could be faint and dusty (with optical depth 1, like those of Jupiter), in which case their presence would not affect the measurement of the planet's radius, or they could be dense and opaque (with optical depth > 1), which would then lead to an overestimate of the planet's radius. Rings can be detected in transit mostly during the ingress and egress phases, which were unfortunately not covered in the CHEOPS dataset presented here. If the planet is tidally locked, the rings may be torqued toward the planet's orbital plane beyond about 1 R p making their detection in transit difficult as they would then be seen edge-on  144, 145.
A bigger satellite with a 3000 km radius may survive only if it orbits at > 30 R p. On the other hand, satellites smaller than 100 km may survive even as close as a few R p and if Q > 1. However, Q is a poorly constrained quantity. It may be in the range of 1-10 for terrestrial planets and > 1000 for gas giant planets. For a low-density super-Earth like ν 2 Lupi d, Q is unknown, but presumably between the terrestrial and gas-giant values. Based on the exquisite photometric precision of the current dataset, observing the transit of the whole planet's Hill sphere with CHEOPS could allow the detection of satellites down to the Mars-size regime.
Acknowledgments CHEOPS is an ESA mission in partnership with Switzerland with important contributions to the payload and the ground segment from  Austria, Belgium, France, Germany, Hungary, Italy, Portugal, Spain, Sweden , and the  United Kingdom. The Swiss participation to CHEOPS has been supported by the  Swiss Space Office (SSO)  in the framework of the  Prodex Programme  and the  Activités Nationales Complémentaires (ANC) , the  Universities of Bern and Geneva as well as of the NCCR Plan-etS  and the  Swiss National Science Foundation. The MOC activities have been supported by the  ESA  contract No. 4000124370. S. C. acknowledges the financial support by  LabEx UnivEarthS  ( ANR-10-LABX-0023  and  ANR-18-IDEX-0001 ). This work was supported by  FCT -Fundac  ¸ão para a Ciência e a Tecnologia through national funds and by  FEDER  ( Fundo Europeu de Desenvolvimento Regional)  through  COMPETE2020 -Programa Operacional Competitividade e Internacionalizac  ¸ão by these grants:  UID/FIS/04434/2019 ;  UIDB/04434/2020 ;  UIDP/04434/2020; PTDC/FIS-AST/32113/2017 & POCI-01-0145-FEDER-032113; PTDC/FIS-AST/28953/2017 & POCI-01-0145-FEDER-028953; PTDC/FIS-AST/ 28987/2017 & POCI-01-0145-FEDER-028987.
S. C. C. B. , S. G. S. , and V. A. acknowledge support from  FCT  through FCT contracts nr. IF/01312/2014/CP1215/CT0004  and  CEECIND/00826/2018  and  POPH/FSE (EC)  and  IF/00650/2015/CP1273/CT0001. O. D. S. D. is supported in the form of work contract ( DL 57/2016/ CP1364/CT0004 ) funded by national funds through FCT. M. J. H. acknowledges the support of the  Swiss National Fund  under grant  200020 172746. A. D. and D. E. acknowledge support from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation programme  (project  FOUR ACES ; grant agreement No  724427 ). S. H. acknowledges CNES funding through the grant  837319. The Spanish scientific participation in CHEOPS has been supported by the  Spanish Ministry of Science and Innovation  and the  European Regional Development Fund  through grants  ESP2016-80435-C2-1-R ,  ESP2016-80435-C2-2-R ,  ESP2017-87676-C5-1-R ,  PGC2018-098153-B-C31 ,  PGC2018-098153-B-C33 , and MDM-2017-0737  Unidad de Excelencia María de Maeztu-Centro de Astrobiología (INTA-CSIC) , as well as by the  Generalitat de Catalunya/CERCA  programme.
Code availability The CHEOPS DRP is built over several public python libraries, such as astropy  148, 149  , numpy  150  , and scipy 151. The TESS light curve was extracted using the lightkurve 32 open-source python package. The data analysis was performed using the juliet python library, which is also publicly available. The figures were produced using the matplotlib  152  and corner 153 open-source python modules. The codes used in this work are available upon reasonable request from the corresponding author.
Methods and LabVIEW implementation The method implemented in the current work is based on that originally presented by Kasteren et al. in Refs  [29, 31]. We have adapted and developed it to be implemented under LabVIEW environment. This choice of LabVIEW environment was done as it provides efficient software analysis and user-friendly interactive tools in the form of a GUI. Within these specific developments and from inputs based on experimental data sets, it can provide various and easy possibilities for processing these data, for the extraction of HMM parameters, their validation then the application to the prediction in real-time. Thus, as it is requested in a LabVIEW program, we have developed a Virtual Instrument, VI, consisting in two main parts being the block-diagram and the GUI  [3].
Graphical user interface The current human daily living activities recognition application was developed taking into account the user-friendly possibilities offer through the GUI by LabVIEW to provide a simple and convivial interface dedicated to the final user. In the startup session of the program, the interactive graphical user interface (GUI) is displayed and during all the process, the full background software development is hidden for the user. The GUI consists of two main pages accessible by direct activation with a pointing device as a mouse pointer. The first page is associated to the inputs. In this page, the user enters the experimental learning data by uploading measurement files and the set of activities considered by selecting the labels in the dedicated list. The second page is associated to the results.
Validation and discussion Among the above-presented example, the developed tool has been applied for validation to several sets of experimental data found in the literature. Especially, we applied our model on input data series providing by Van Kasteren et al. [31] r e c o r d e di nt h eh o u s en a m e db yt h e authors "Home A" and, providing by Ordóñez et al. [21] , on a second one named by the authors "Set A". These two series of data are named Dwelling-A and Dwelling-B, respectively,inth ecurre ntcont ribu tion. As explained above ( § II. E), using the "leave-one-day" method, the activities of each tested day are inferred by the HMM model for which the set of parameters is learned with the experimental data providing from the other studied days of the chosen panel. Each inferred activity sequence is compared with the real activity sequence of the corresponding tested day.
Moreover, our results are quite close to those initially obtained by the authors with their original experimental data, as in the case of Van Kasteren et al. [31]  who performed their analysis with a method developed under Matlab. Thus, the tool can be used as a functional, or even industrial and commercial product, thus considered as a black box in future projects in a smart home energy management system. For a complete study of the energy consumption of his home, an inhabitant or an energy manager simply needs to enter the experimental data recorded on several days. Then, considering the activity labels in terms of electrical power needs by their relative loads, the user will obtain as outputs, the load profiles corresponding to each test day and a prediction of the energy consumption. For a specific and real-time prediction, he can choose as inputs, a single set of parameters.
Conclusion The present manuscript outlined the development of an original and interactive graphical tool allowing the modeling, test, and user-friendly prediction of human daily living activities in a smart home. This tool was developed under LabVIEW. The inputs of the application are two Fig. 11  View of the "Real Time Inference" subpage of the "Result" page of the GUI time series data obtained from a ubiquitous sensor network for the features and by annotations for the activity labels. The procedure is based on a Hidden Markov Model due to its time modeling abilities. Experimental results are presented in a graphical user interface using LabVIEW. The results obtained from true input data provided by literature are closer to those provided by similar studies. Among the validation of our application, it proves the efficiency of the chosen approach, as compare for example to the pure sequential approach currently used in recognition process.
From the validation results, we noted that the choice of the feature representation procedure depends on the experiment itself, hence the need to apply the three procedures, i. e. the Row, Last fired, and ChangePoint procedures to a set of experimental data to be able to choose the proper one for each data set. One of the originalities of our tool is its development under LabVIEW environment, thus offering interactivity and friendliness to the user thanks to the GUI. The obtained results, associated with interactive graphical tools demonstrate the possibility to integrate such tools in a smart-home for either the prediction or the management of the energy consumption as function of the human activities, based on experimental datasets of human activities recorded off-line in the considered environment.
In accordance with their formulation, they proposed a new algorithm by applying Lyapunov optimization techniques in dynamic fog networks. Random scheduling and Least Busy Scheduling are used as comparison algorithms. Wang et al. [30]  proposed an efficient cooperating multi-tasks scheduling algorithm focused on ACO approach in fog environments. The proposed algorithm experimented for various tasks from 40 to 100 on 20 fog nodes. It proved to outperform minmin, improved max-min, and FCFS algorithm in terms of energy consumption, total completion task, and resource consumption. Task scheduling problem in cloud-fog context is described by Nguyen et al. [31]  with two objectives: execution time and operating costs. Their proposed algorithm named TCaS is based on GA and is evaluated on 11 datasets of different sizes.
In fact, IoT devices are frequently mobile (e. g smartphones, embedded IoT devices on vehicles,. ) and it introduces new problems such as disconnections, changes on gateways, task migration. Mobi-IoST (Mobility-aware Internet of Spatial Things)  [39]  considers time-critical applications such as health care applications. In such applications, disconnections may increase delay in processing and delivering information. Mobi-IoST proposes a Cloud-Fog-Edge based collaborative framework for the processing of IoT data and delivering the result based on user mobility prediction to reduce the delay and the power consumption of the IoT device. Spatio-temporal trajectories of end-users (GPS traces) are stored at the cloud level. These trajectories are semantically enriched using external information such as points of interest, road network.
In this case, the fog cluster manager should assign the smart parking task to a fog node that is located in the vicinity of the citizen and is closed to the needed data. Another type of smart service is a video surveillance system. Based on a specific demand (including location and time criteria), this system analyses videos acquired from several video cameras deployed within different parking slots in the region. The application requires an object recognition task which is very intensive in computation requirements, but is not sensitive in delay. In this case, the fog cluster manager should allocate the resources of a cloud node for executing the object recognition task. This implies the transfer of video data from video devices or fog nodes to the cloud. The IoT layer is composed of a massive number of IoT devices that are widely distributed within areas such as cities, factories, hospitals, homes, libraries, museums, etc.
Experiment results To validate the efficiency of the proposed OppoCWOA from different perspectives, extensive experimentation studies are conducted considering the evaluation metrics (Time, energy and time-energy balance) presented in "Proposed system model and formulation for the task scheduling problem" section. The fog environment is composed of twenty fog nodes with different characteristics such as computing capacity, bandwidth, distance from the manager within the cluster, computing energy. Furthermore, six datasets of different number of tasks (from 50 to 300) are created to participate in the experimentations. Table  3  shows the parameter values considered in our settings. In order to provide different scenarios, many types of tasks are created with various amounts of processing power, bandwidth, and data usage.
2C  and supplementary fig. S4A , Supplementary Material online). We then built a linear model based on the relationship between the fraction of very similar proteins (>80% identity) and the fraction of homologous proteins between temperate and virulent genomes (fig. 2A , blue line). We limited this data set to pairs of phages with at least 50% of homologous proteins, where the influence of outliers that are associated with recent genetic transfers is expected to be weaker. The linear model fitted to the temperate-virulent data set represents a conservative model of the null hypothesis that the relationship between these two parameters is mostly due to ancestry. It fits well the major group of comparisons between virulent and temperate phages across almost all the range of the regression (fig.
Both variables contributed significantly to explain the variation in the frequency of genetic transfers (supplementary table  S2 , Supplementary Material online). The contrast between pairs of temperate phages and the remaining pairs had the highest contribution to the logistic regression, followed by the wGRR. This analysis shows that the frequency of recent genetic transfers is dependent on the lifestyle, even when accounting for genetic distances between phages. We then investigated whether genomes classed as HGCF drive the genetic exchanges between dissimilar phages. We matched our database with that of  Mavrich and Hatfull (2017)  and classified 283 phages as HGCF and 737 as LGCF (ca. 43% of our data set). Pairs of HGCF phages had more cases of recent genetic transfers (8%) than pairs of LGCF phages (4%) (P < 0.
We thus searched if genes identified as genetic transfers were associated with some specific bacterial functions. We removed from the bacteria nonsupervised orthologous groups (bactNOG) profiles database the functions associated with phages by removing profiles matching pVOG profiles with a viral quotient (VQ) higher than 80%. We then used the remaining bactNOG profiles to annotate the transferred genes (fig. 4B  and supplementary fig. S12 , table  S4 , and file S2, Supplementary Material online). The vast majority of these genes have no defined function. Some of the remaining might be typical phage genes that were missed by the filter using the pVOG profiles. Yet, other genes matched profiles whose functions are related to carbohydrate or nucleotide transport and metabolism, DNA related functions, or energy production and conservation.
Data We retrieved the complete genomes of 13,513 bacteria and 2,502 phages from NCBI nonredundant RefSeq database (ftp://ftp. ncbi. nlm. nih. gov/genomes/refseq/, last accessed May 2019). Five phage genomes were excluded because their annotation lacked the gene identification, resulting in a data set with 2,487 phage genomes. The lifestyle of these phages was predicted using PHACTS v. 0. 3  (McNair et al. 2012). Predictions were considered as confident if the average probability score of the predicted lifestyle was at least two standard deviations (SD) away from the average probability score of the other lifestyle, which leads a precision rate in lifestyle identification of 99%  (McNair et al. 2012). Using these criteria, we classified as confident 54% of the phages into 571 virulent and 780 temperate phages.
Alternatively, we used BACPHLIP version 0. 9. 3 (Hockenberry and Wilke 2020) (default parameters) to predict the lifestyle of each phage, for almost all (>99%) of the genomes. Data for the HGCF and LGCF phages were taken from  (Mavrich and Hatfull 2017 ) by matching the NCBI identifiers. We retrieved information (when available) on the phage hosts from the GenBank files of the phages or from the Virus-Host DB  (Mihara et al. 2016 ) (https://www. genome. jp/virushostdb/, last accessed February 2020). A few phages ($2%) have no identified host, since they were collected from environmental (soil, sea, etc. ) or feces samples. In this data set, the phage hosts belong to 332 species and 145 genera. Most of these species (69%) have at least one complete genome sequenced and available in NCBI RefSeq.
In the absence of a complete genome of the same species (31%, indicated as "manually annotated" in supplementary file S1, Supplementary Material online), we used another genome from the same genus as a proxy for the species. Some analyses were repeated by excluding these phages with manually annotated (nonconfident) host species, in order to provide a conservative control for these assignments. Bacteriophage Diversification via Genetic Exchanges. doi:10. 1093/molbev/msab044 MBE Prophages (integrated temperate phages) were predicted using VirSorter v. 1. 0. 3  (Roux et al. 2015)  with the RefSeqABVir database from the bacterial genomes (corresponding to the host species/genus of the prophages). The least confident predictions, that is, categories 3 and 6, which may be prophage remnants or erroneous assignments, were excluded from the analyses.
wGRR is the fraction of bidirectional best hits between two genomes weighted by the sequence identity of the homologs. It varies between zero (no bidirectional best hits) and one (all genes of the smallest genome have an identical homolog in the largest genome). wGRR integrates information on the frequency of homologs and sequence identity. Hence, when the smallest genome is 100 proteins long, a wGRR of 0. 03 can result from three pairs of identical homologs or six pairs of homologs with 50% identity. Similarity Networks, Community Detection, and Calculation of Entropy The phage network was built based on the filtered wGRR values, using the networkx and graphviz Python (v2. 7) packages, and the neato algorithm. The Louvain community clusters  (Blondel et al. 2008)  were calculated using the best_partition function from the community package in Python (v2.