dataesr/scientific-paragraphs-categorization huggingface dataset:
Conclusion In this work, we showed that sharing data generated from MD simulations is now a common practice. From Zenodo, Figshare and OSF alone, we indexed about 250,000 files from 2,000 datasets, and we showed that this trend is increasing. This data brings incentive and opportunities at different levels. First, for researchers who cannot access high-performance computing (HPC) facilities, or do not want to rerun a costly simulation to save time and energy, simulations of many systems are already available. These simulations could be useful to reanalyze existing trajectories, to extend simulations with already equilibrated systems or to compare simulations of a dedicated molecular system modelled with different settings. Second, building annotated and highly curated datasets for artificial intelligence will be invaluable to develop dynamic generative deep-learning models.
Initial data collection We searched for MD-related files in the data repositories Zenodo, Figshare and Open Science Framework (OSF). Queries were designed with a combination of file types and optionally keywords, depending on how a given file type was solely associated to MD simulations. We therefore built a list of manually We made the assumption that files deposited by researchers in data repositories were coherent and all related to a same research project. Therefore, when an MD-related file was found in a dataset, all files belonging to this dataset were indexed, regardless of whether their file types were actually identified as MD simulation files. This is the core of the Explore and Expand strategy (𝐸𝑥 2 ) we applied in this work and illustrated in Fig 1.
When a zip file was found in a dataset, its content was extracted from a preview provided by Zenodo and Figshare. This preview was not provided through APIs, but as HTML code, which we parsed using the Beautiful Soup library (version 4. 11. 2). Note that the zip file preview for Zenodo was limited to the first 1,000 files. To avoid false-positive files collected from zip archives, a final cleaning step was performed to remove all datasets that did not share at least one file type with the file type list mentioned above. In the case of OSF, there was no preview for zip files, so their content has not been retrieved.
Gromacs files After the initial data collection, Gromacs. mdp and. gro files were downloaded with the Pooch library (version 1. 6. 0). When a. mdp or. gro file was found to be in a zip archive, the latter was downloaded and the targeted. mdp or. gro file was selectively extracted from the archive. The same procedure was applied for a subset of. xtc files that consisted of about one. xtc file per Gromacs datasets. Once downloaded,. mdp files were parsed to extract the following parameters: integrator, time step, number of steps, temperature, thermostat, and barostat. Values for thermostat and barostat were normalized according to values provided by the Gromacs documentation. For the simulation time analysis, we selected. mdp files with the md or sd integrator and with simulation time above 1 ns to exclude most minimization and equilibrating simulations.
For the thermostat and barostat analysis, only files with non-missing values and with values listed in the Gromacs documentation were considered. The. gro files were parsed with the MDAnalysis library  (Michaud-Agrawal et al. , 2011)  to extract the number of particles of the system. Values found in the residue name column were also extracted and compared to a list of residues we manually associated to the following categories: protein, lipid, nucleic acid, glucid and water or ions (https://github. com/MDverse/mdws/blob/main/ params/residue_names. yml). The. xtc files were analyzed using the gmxcheck command (https://manual. gromacs. org/current/ onlinehelp/gmx-check. html) to extract the number of particles and the number of frames.
System visualization and molecular graphics Molecular graphics were performed with VMD  (Humphrey et al. , 1996)  and Chimera  (Pettersen et al. , 2004). For all visualizations,. gro files containing molecular structure were used. In the case of the two structures in Fig. 3-B ,. xtc files were manually assigned to their corresponding. gro (for the TonB protein) or. tpr (for the T4 Lysozyme) files based on their names in their datasets. Origin of the structures displayed in this work:.
Acknowledgments We thank  Lauri Mesilaakso ,  Bryan White ,  Jorge Hernansanz Biel ,  Zihwei Li  and  Kirill Baranov  for their participation in the Copenhagen BioHackathon 2020, whose results showcased the need for a more advanced search strategy. We acknowledge  Massimiliano Bonomi ,  Giovanni Bussi ,  Patrick Fuchs  and  Elise Lehoux  for helpful discussions and suggestions. We also thank the  Zenodo, Figshare  and OSF support teams for providing figures on the content of their respective data repository and for their help in using APIs. This work was supported by  Institut français du Danemark  ( Blåtand program , 2021), the  Data Intelligence Institute of Paris  (diiP,  IdEx Université Paris Cité ,  ANR-18-IDEX-0001 , 2023). JKST and KL-L acknowledge funding by the  Novo Nordisk Foundation  [ NNF18OC0033950  to KL-L], and workshops funded by  The   BioExcel   Center-of-Excellence  (grant agreements  823830 ,  101093290 ).
Data and code availability Data files produced from the data collection and processing are shared in Parquet format in the Zenodo repository: https://zenodo. org/record/7856806 Python scripts to search and index MD files, and to download and parse. mdp and. gro files are open-source, freely available on GitHub (https://github. com/MDverse/mdws) and archived in Software Heritage (swh:1:dir:4d30b00345a732dcf9f79d3c8bfae38b35b8f2c4). A detailed documentation is provided along the scripts to easily reproduce the data collection and processing. Jupyter notebooks used to analyze results and create the figures of this paper are open-source, freely available on GitHub (https://github. com/MDverse/mdda) and archived in Software Heritage (swh:1:dir:1f8497f72134cef0a9724c955bb03c751f52cccd). The code of the MDverse data explorer web application is open-source, freely available on GitHub (https://github.
related to protein structures (MoDEL: Meyer et al. (2010)), membrane proteins in general (Mem-ProtMD: Stansfeld et al. (2015); Newport et al. (2018)), G-protein coupled receptors in particular (GPCRmd: Rodríguez-Espigares et al. (2020)), or lipids (Lipidbook:Domański et al. (2010), NMRLipids Databank: Kiirikki et al. (2023)).
repository datasets first dataset latest dataset files total size (GB) zip files files within zip total files Zenodo 1,011 19/11/2014 05/03/2023 20,250 12,851 1,780 141,304 161,554 Figshare 913 20/08/2012 03/03/2023 3,336 736 590 74,720 78,056 OSF 55 24/05/2017 05/02/2023 6,146 495 14 0 6,146 Total 1,979 - - 29,732 14,082 2,384 216,024 245,756 Figure 1. (A) Explore and Expand (𝐸𝑥 2.
Dataset URL: https://figshare. com/articles/dataset/PTEG-1_PP_and_N-DMBI_atomistic_force_fields/ 5458144 Publication (DOI): https://doi. org/10. 1039/C7TA06609K Publication (DOI): https://doi. org/10. 1021/acs. cgd. 2c00832 PTEG-1 (coarse-grain) Dataset URL: https://figshare. com/articles/dataset/Neat_and_P3HT-Based_Blend_Morphologies_for_ PCBM_and_PTEG-1/12338633 Publication (DOI): https://doi. org/10. 1002/adfm. 202004799 Theophylline Dataset URL: https://figshare. com/articles/dataset/A_Comparison_of_Methods_for_Computing_Relative_ Anhydrous_Hydrate_Stability_with_Molecular_Simulation/21644393 TonB Dataset URL: https://zenodo. org/record/3756664 Publication (DOI): https://doi. org/10. 1039/D0CP03473H T4 Lyzozyme Dataset URL: https://zenodo. org/record/3989044 Publication (DOI): https://doi.
Artificial Intelligence (AI) approaches have emerged as powerful tools to improve traffic analysis for network monitoring and management. However, the lack of large labeled datasets and the ever-changing networking scenarios make a fundamental difference compared to other domains where AI is thriving. We believe the ability to transfer the specific knowledge acquired in one network (or dataset) to a different network (or dataset) would be fundamental to speed up the adoption of AI-based solutions for traffic analysis and other networking applications (e. g. , cybersecurity). We here propose and evaluate different options to transfer the knowledge built from a provider network, owning data and labels, to a customer network that desires to label its traffic but lacks labels. We formulate this problem as a domain adaptation problem that we solve with embedding alignment techniques and canonical transfer learning approaches.
A. Use of word embeddings in communication networks Recent efforts have noted the similarities between sequences of events observed in network data and of words in natural languages  [13] ,  [14] ,  [16] -  [19]. Following this intuition, they leverage a two-step pipeline in which embeddings are first learned using techniques like Word2Vec  [20] , then used in downstream machine learning tasks. Authors of  [19]  leverage Word2Vec to learn vector representations of bash commands observed in honeypot logs. Authors of  [18]  follow a similar idea to learn representations for router configuration commands for the purpose of synthesis, verification, and translation. Close to our work, IP2Vec  [13] , DANTE  [14]  and DarkVec  [16]  first learn host embeddings leveraging the sequence of packets observed in network logs.
It uses a neural network model that is trained to predict which host (word) will appear in the context of a trace (document). In our case, given the i-th host in a sequence of packets, we train the neural network to predict the probability of occurrence of the (i -c w ) and the (i + c w ) hosts, being c w the context window. Formally, given a sequence {s 1 , s 2 , s 3 ,. } of host observations, we map each entity s j ∈ W → u j ∈ R e where W is the set of hosts and u j is the embedding of s j in the e dimension space. The function g : W → R e is the embedding function, which is a neural network. Given g, let Y = [g(w)] w∈W be the matrix of embeddings for all hosts in W , i. e. , Y ∈ R |W |×e. Similarly to the natural language case, Word2Vec learns host embeddings that encode the co-occurrences of hosts (words), mapping those hosts performing similar (different) activities in the same (different) region of the embedding space.
B. Darknet datasets and ground truth We rely on two datasets to explore domain adaptation in darknets. Each dataset has been captured in a /24 darknet for 43 days. We use each as the provider and customer networks, respectively, and they are deployed in different geographical locations and ASes. Both darknets observe millions of packets on a daily basis, coming from tens of thousands of remote hosts. Here we rely on the packet level trace collected from the 1st of Dec 2022 to the 11th of Jan 2023. We follow the process as done in  [16] : we consider batches of data collected every ∆T = 1 day so that at the end of each day, the processing pipeline sketched in Figure  1  can be executed. For each day, we consider only hosts that sent at least 5 packets, i. e. , the most active hosts. Here we formulate a supervised learning use case.
We next use the per-packet fingerprint of well-known botnets  [51]  to identify some hosts and label them as zombies. These are typically bots that continuously perform large-scale scans of the IP address space in search of possible victims. We use the 31 days of Dec 2022 to build the host embeddings  [16]. Then we use each day of Jan 2023 to train and test the downstream classifier performance. Specifically, we train it on the provider data and test it on the customer data with different domain adaptation options. For comparison, we consider the (unrealistic) case where the customer also owns the GT data, and thus can train the classifier independently. We focus our manual effort on building the GT on hosts active on Jan 1st, 2023. For completeness, Table I details the number of active hosts for each ground truth class.
B. Unconstrained case: The customer has more days of traffic In this case, the customer has been running its darknet for a long time, 32 days in our case. Hence it can create embeddings in these 32 days. As in the case of 1-day embeddings, we compare the following alternatives: • Independent (reference): The customer owns the GT and works independently. It builds host embeddings on 32 days, trains the classifier, and tests it on the last day. • Collaborative: provider creates its embedding on 32 days, then it trains the classifier on the last day (Jan 1st). In all cases, the provider classifies the customer host embeddings using the provider classifier. -No adaptation: customer creates host embeddings using 32 days of data and sends them to the provider. -Canonical transfer: same as before.
VII. HONEYPOT USE CASE: SCENARIO We now consider a more challenging scenario for the application of domain adaptation for traffic analysis: we transfer knowledge from a provider running honeypots to a customer running darknets. Honeypots offer a richer view than darkness: they mimic the functioning of a real system and engage with the attackers producing rich application logs that support the security analyst in understanding the attacks. It is possible then to detect attacks that would be impossible to classify using darknet traffic alone. Using the hosts in common between the darknet and honeypot datasets, we first compare our domain adaption options by facing a supervised downstream task (Section VII-C). We then present an unsupervised downstream task use case (Section VIII), in which the customer leverages the knowledge from the honeypot to shed light on the activity of hosts observed in its darknets.
B. Honeypot dataset and extended ground truth We rely on a dataset obtained from a honeypot infrastructure deployed in a /24 network of our university network. The infrastructure relies on the TPOT honeypots  [64] , which offers a collection of third-party low-interaction honeypots, i. e. , simple scripts built to simulate a vulnerable service communicating over a given protocol. Most of the honeypots we deploy simulate services such as SSH, RDP, POP3, IMAP, and MySQL. We include Cowrie  [65] , a sophisticated honeypot that simulates a vulnerable server accessible via SSH/Telnet. It allows attackers to go further in their attempts, from discovery, SSH channel negotiation, brute-force login attempts, and initial shell access, up to the download and execution of malware binaries and scripts.
As input, we consider the sequence of TCP-SYN packets sent by hosts contacting any honeypots. In total, we observe more than 18 000 active hosts for which we can build an embedding. The provider creates its embedding on 32 days of honeypot traffic and trains the classifier on the last day (Jan. 1st) with the extended GT. Then, the provider and the customer perform the domain adaptation (either with canonical transfer and Jan. 1st data or with explicit alignment) between the customer and provider host embeddings. Finally, the provider classifies the adapted customer embeddings and we extract the performance as previously (5-fold average over Jan. 1st). According to the larger amount of packets collected by the honeypot with respect to the darknet case, the training and update of i-DarkVec requires on average 23s for each day.
A. Methodology We take as provider the same honeypot infrastructure used in Section VII-B and as the customer, the darknet. The provider learns embeddings using the complete 32-day dataset, and the customer uses them to either transfer or align its host embeddings. It then performs clustering on such host embeddings. As a baseline, we consider the case in which the customer performs clustering directly with its independently build host embeddings. This allows us to assess the knowledge gains when using domain adaptation. We test multiple algorithms, such as k-means, DBSCAN  [67] , HDBSCAN  [68] , and the Louvain-based approach used in  [16] , noticing minor differences. We present results using the HDBSCAN algorithm because it is an almost parameter-free algorithm and has proven to deliver good qualitative results.
ACKNOWLEDGEMENT The research leading to these results has been partly funded by the  Huawei R&D Center (France) , by the project  SERICS  ( PE00000014 ) under the  MUR National Recovery and Resilience Plan  funded by the  European Union -NextGenerationEU  and the  PRIN 2022 Projects xInternet  ( eXplainable Internet   -20225CETN9 ) and  ACRE  ( AI-Based Causality and Reasoning for Deceptive Assets   -2022EP2L7H ).
ACKNOWLEDGMENTS This work was partly funded by the  French Innovation Agency for Defense (Agence de l'Innovation de Défense, AID). N. Leoni  would also like to thank  Ravikishore Kommajosyula  for providing the boiling model, and  Kathryn Maupin  for helpful discussions. This project was partly funded from the  Clean Sky 2 Joint Undertaking (JU)  under grant agreement No  101008257.
Proof. Since Total(z, u) = F (u) + G(u) + H(u), the first two equalities are immediately deduced from the previous results. The third equality is obtained using the Mathematica package Guess. m (written by Manuel Kauers  [6] ) for guessing recurrence relations. After this, it suffices to check algebraically: Total(z, u) = (u + z -u 2 z -z 2 -uz 2 )Total(z, u) -u + (z 2 -z + 1)(1 + rs -z) r. Now, let us prove the last equality. Any length n MAP of the first kind is of the form (i) HP , or (ii) U DP , or (iii) U P HDQ where P, Q are some MAP so that the length k of P lies into [0, n -3], and the length of Q is n -k -3, or (iv) P ♯ Q where P ♯ = U P ′ D ℓ , ℓ ⩾ 1, and P ′ is a PMAP such that P ′ D ℓ-1 is a MAP of length k lying into [2, n -1], and the length of Q is n -k -1. Taking into account all these cases, we obtain the result.
Finally, setting t(n, k) = [z n ][u k ]Total(z, u), we have for n ⩾ 2, k ⩾ 1, t(n, k) = t(n, k -1) + t(n -1, k -1) -t(n -1, k -2) -t(n -2, k -2), and setting t n := t(n, 0), we have t 0 = 1, and for n ⩾ 1, t n = t n-1 + n-2 k=1 t k t n-1-k. Proof. The first two equalities are immediately deduced from the previous results. The third equality is obtained using the Mathematica package Guess. m ([6]) for guessing recurrence relations. After this, it suffices to check algebraically: Total(z, u) = (u + uz -u 2 z -u 2 z 2 )Total(z, u) -u(1 + z) + 1 zr. For the last equality, it suffices to remark that the generating function of the sequence (t n ) n⩾0 , that is 1/(zr), generates a shift of the well known Motzkin sequence A001006 in in  [13]. Let T be the infinite matrix T := [t(n, k)] n⩾0,k⩾0. The first few rows of the matrix T are  T =                     1 0 0 0 0 0 0 0 • • • 1 1 0 0 0 0 0 0 • • • 1 2 1 0 0 0 0 0 • • • 2 3 3 1 0 0 0 0 • • •                    .
We proceed as follows: • We first explain informally how one can program with capabilities and use capabilities to enforce memory compartmentalization (Section 2). • We then introduce the formal operational semantics of a simple capability machine with sentry capabilities (Section 3). • We define the Cerise program logic which can be used to formally verify the correctness of programs running on the capability machine. Our program logic is defined by instantiating the Iris framework  [Jung et al. 2018] , which provides an expressive separation logic with powerful reasoning principles, including, in particular, the notion of a logical invariant (Section 4). • We define, using our program logic, the specification of what a "safe" capability and a "safe" program is. Intuitively, a capability (respectively, a program) is "safe" if it cannot be used to invalidate an invariant.
2017]. The last piece of the puzzle is then a so-called Adequacy theorem (Section 4), which relates invariants established in the program logic to the operational semantics of the machine. Given a concrete scenario (typically, a complete system mixing known verified code with unknown untrusted code), this makes it possible to obtain a theorem about the execution of the system which only depends on the operational semantics of the machine (not on the program logic). • In Section 6 we then return to the examples from Section 2 and show how to use Cerise to formally prove that the desired memory compartmentalization results really do hold. • In Section 7 we consider more sophisticated examples, which involve dynamic memory allocation. We focus on the low-level implementation of ML-like programs, and introduce a heap-based calling convention for closures implementing ML functions.
We extend the earlier Adequacy theorem to account for dynamically allocated memory. • In Section 8 we demonstrate how to use our methodology to establish correctness of object capability patterns (OCPs) from the literature. In particular, we consider the OCP of dynamic sealing, as presented by  [Swasey et al. 2017]  in the context of a high-level language and we demonstrate that Cerise can be used to prove similar results about a low-level implementation of their example. • Section 9 offers some perspectives on the relevance of our technical contributions and how we envision them being used in the development of secure systems. • Finally, we discuss related work in Section 10. This paper pedagogically introduces and explains the methodology underlying a sequence of recent research papers  [Georges et al.
2021; Skorstengaard et al. 2018 Skorstengaard et al. , 2019a;; Van Strydonck et al. 2022] , in the form of the Cerise program logic, but also contributes new material. The operational semantics, program logic and logical relation discussed in Sections 3, 4 and 5 are based on those used by Georges et al. [2021]  (but we have removed local and uninitialized capabilities as well as Kripke indexing for simplicity and instead added much more extensive explanations and proofs). Sections 2 and 6 are new; they provide a clear and accessible introduction to capability machine programming and our reasoning tools. The examples in Sections 7-8 are also new and represent a non-trivial verification effort. The results and examples presented here have been fully formalized in Coq, and are available online: https://github.
PROGRAM LOGIC The operational semantics presented in the previous section formally define the behavior of our machine when it runs and executes code. Based on that, we expect to be able to formally verify concrete programs running on the machine. The most direct approach would be to manually establish properties of sequences of reduction steps, based solely on the definition of the operational semantics. We do not follow this approach, because it would quickly become very tedious even for simple programs. Instead, we draw from previous research in program logics and separation logic, and define Cerise: a program logic which provides a convenient framework in which to modularly reason about programs running on our machine. Indeed: • It is typically more convenient to devise a system of proof rules for programs, rather than work directly at the level of abstraction provided by the bare operational semantics.
Here, the machine state consists of both the machine memory and the machine registers. Indeed, it is useful to modularly reason about programs operating on both a subset of memory and a subset of the available registers. Technically speaking, we build the Cerise program logic on top of the Iris framework  [Jung et al. 2018] , which provides us with additional useful features, such as invariants. In the following we introduce both the basic separation logic assertions describing the machine state and additional features inherited from Iris (Section 4. 1). Then, we describe the rules that are used to specify the execution of machine instructions and programs (Section 4. 2). Note that the program logic is, in a sense, only a technical device. The end goal is to obtain theorems that only refer to reductions in the operational semantics of our machine.