dataesr/scientific-paragraphs-categorization huggingface dataset:
The top ten most intense ions were selected for fragmentation in the linear ion trap using Collision Induced Dissociation (CID) using a maximum injection time of 25 ms or a target value of 5000 ions. MS data were acquired using the XCalibur software (Thermo Fisher Scientific). Raw data obtained were processed with MaxQuant version 1. 5. 5. 1  20  and Andromeda peak list files (. apl) generated were converted to Mascot generic files (. mgf) using APL to MGF Converter [http://www. wehi. edu. au/people/andrewwebb/1298/apl-mgf-converter. ]. Generated MGF files were searched using Mascot (Matrix Science, version 2. 4. 1), querying dictyBase  21, 22  (12,764 entries) plus an in-house database containing common proteomic contaminants and the sequence of GFP-NAP1. The common contaminant and reverse hits (as defined in MaxQuant output) were removed.
Mascot was searched assuming trypsin digestion allowing for two miscleavages with a fragment ion mass tolerance of 0. 6 Da and a parent ion tolerance of 15 ppm. The iodoacetamide derivative of cysteine was specified in Mascot as a fixed modification, and oxidation of methionine and phosphorylation of serine, threonine and tyrosine were specified in Mascot as variable modifications. Scaffold (version 4. 3. 2, Proteome Software) was used to validate MS/MS based peptide and protein identifications. Peptide identifications were accepted if they could be established at greater than 95. 0% probability as specified by the Peptide Prophet algorithm, resulting in a peptide false discovery rate (FDR) of 0. 63%  23. For label-free quantification, proteins were quantified according to the label-free quantification algorithm available in MaxQuant  23.
Imaging was controlled through the μManager 1. 4. 9 software. All microscopy was carried out at room temperature and images were analysed with ImageJ/Fiji 1. 49i. Pseudopod rate and split frequency was analysed from the DIC movies and manually quantified frame by frame. For analysis of cell Circularity, speed and migration parameters automated tracking plugins were developed for ImageJ. More information will be supplied upon reasonable request, but the code used was as follows: run("Convert to Mask", "method=IsoData background=Dark calculate black"); run("Invert", "stack"); run("Analyze Particles. ", "size=400-Infinity pixel circularity=0. 00-1. 00 show=Masks in_situ stack"); run("Fill Holes", "stack"); run("Set Measurements. ", "area centroid shape stack redirect=None decimal=3"); run("Analyze Particles.
Acknowledgements We thank  Margaret O'Prey  and the  BAIR imaging facility  for help with microscopy,  Chloe Tesniere  for careful work with CYRI overexpression plasmids,  Michael Mcilwraith  for help with protein purification,  Luke Tweedy  for helpful advice on quantification and image analysis,  Benjamin Tyrell  for isolation of the inducible Rac fl/fl fibroblasts and  David Bryant  for advice and constructs. We thank  CRUK  for core funding to L. M. M. (grant  A15673 ),  R. H. I. (grant  A19257 ) and S. Z. ( C596/A12935 ), and  BBSRC  for funding to L. H. C and N. C. O. T ( BB/L022087/1 ). D. discoideum L. gigantea H. robusta C. capitata C. elegans* T. castaneum D. melanogaster H. sapiens M. musculus B. taurus X. tropicalus D. rerio T. rubripes B. floridiae S. purpuratus C. intestinalis T.
Each supergroup was assigned to a specific background color: Unikonts (yellow), Chromalveolates (pink), Excavates (blue) and Plants (green). Branch length does not reflect evolutionary distances. For C. elegans and R. allomycis, * and red highlight around circle denotes lack of putative N-terminal myristoylation site on CYRI. Different coloured branches in Unikonts represent amoebazoa (yellow branches), metazoan (purple branches), fungi (brown branches) and Rozella allomycis, the earliest diverged of the fungi (blue branch). C) Alignment of Dictyostelium discoideum and Homo sapiens CYFIP and CYRI (FAM49) sequences. UniProt accession numbers are reported. Color code represents the number of entries with identical amino acid at this position.
However, they all suffer from one or several of the following drawbacks: (i) the program is not publicly available; (ii) obtaining a good segmentation needs fine-tuning of--sometime numerous--parameters that could be challenging for non-expert user; (iii) the method is computationally time demanding; (iv) prediction robustness is not estimated; (v) the method infers TAD positions but not the higher-order organization or vice-versa. Here, we introduce IC-Finder, a robust computationallyefficient algorithm to segment Hi-C maps into interaction compartments (IC) like TADs. The method is based on a hierarchical clustering-like approach that depends on only two intuitive parameters which do not need to be tuned and whose default values have been learned in order to give optimal results on a large variety of experimental Hi-C data.
Based on statistical resampling of the investigated map, IC-Finder allows to quantify the reliability of the predicted compartmentalization of genome. Moreover, the program offers the option to infer higher-order levels of chromatin organization. The source code is open-access, user-friendly and is available at http://membres-timc. imag. fr/Daniel. Jost/DJ-TIMC/Software. html. In order to validate our approach and to compare IC-Finder with other existing methods, we build a controlled benchmark of Hi-C maps whose segmentation is known. We show that IC-Finder is top-ranked with high sensitivity and specificity. As illustrations of the method, we use IC-Finder to investigate the effect of normalization schemes on the predicted segmentation, and to quantify the correlation between epigenomic information and spatial chromatin compartmentalization at different organizational levels in human and fly.
e. before any normalization process that might have reshaped the Hi-C data). If unknown, by default, we assume e81 Nucleic Acids Research, 2017, Vol. 45, No. 10 PAGE 4 OF 11 N c = 904 that represents the typical number obtained in recent Hi-C experiments at a 10-kb binning  (3, 10). This step is crucial to renormalize the data in terms of real counts. Then, we model the contact frequencies of this modified matrix as independent Poisson processes and for each pair (i, j) of loci, we randomly generate a new contact frequency from a Poisson distribution of average f C(i, j). Hierarchical organization. Investigation of the hierarchical organization is performed by imposing -= + ≡ o and by running the constrained hierarchical algorithm described above for incremental o -values (by default o = 5) (Figure  1C ).
A robust algorithm to partition Hi-C maps Description of the method. IC-Finder is a program that allows to segment Hi-C maps into interaction compartments (IC) (Figure  1A , see Material and Methods for details on the algorithm). Given a matrix of interaction frequencies extracted from a Hi-C experiment, IC-Finder infers the boundaries between consecutive IC along the genome. The algorithm is based on three statements: (i) the 3D chromatin organization is hierarchical; (ii) genomic loci belonging to the same IC should have similar patterns of interactions with the rest of the genome; and (iii) due to the intrinsic polymeric nature of chromatin, intra-IC interactions should be homogeneous in a polymer sense, meaning the contact frequency between two intra-IC loci should depend only on the genomic distance between them.
Threshold values that define this buffer zone have been learned from various manually-annotated experimental Hi-C maps (Supplementary Figure  S3 ) to optimally improve the predictions of IC-Finder. While with the default threshold values IC-Finder gives excellent results for all sort of Hi-C maps (see below), IC-Finder offers the option to manually tune these parameters to eventually optimize the segmentation based on a user-defined criterion. A Matlab/GNU Octave routine for IC-Finder is available at http://membres-timc. imag. fr/Daniel. Jost/DJ-TIMC/Software. html and in the Supplemental Data. Test of reliability and comparison with other methods. We test the reliability of IC-Finder on a controlled benchmark of 100 simulated Hi-C maps that we designed to have the same properties of real Hi-C maps and for which we know the target segmentations (Supplementary Figure  S4 , see Materials and Methods).
Locally, all the methods show significant inconsistency between them (Figure  3A  and Supplementary Figure  S7 ). IC-Finder is closer to TopDom with a better correspondence at the domain scale than at the boundary scale. This is a consequence of the important noise present in the studied maps (see below) that leads to a fuzzier definition of boundaries (on less noisy data like the benchmark dataset, both methods have a very good correspondence). At the global scale, IC-Finder and TopDom give also similar results with comparable domain size distributions (Supplementary Figure  S6B  and D ), while Armatus has the tendency to find lots of small domains and the Directionality Index to segment maps into bigger domains (see examples on Supplementary Figure  S6A  and C ). As a final test, we evaluate the consistency of the predicted TADs on biological Hi-C replicates.
We use data from Ulianov et al. (6)  where two replicates have been produced for each of four different drosophila cell lines (S2, KC, BG3 and OSC). For a given method (IC-Finder, Top-Dom, Armatus or DI), in each cell line, we compare the predictions obtained for the two replicates by computing the TPR/FDR between the two segmentations (Figure  3B ). We find that IC-Finder, TopDom and Armatus give strongly consistent predictions with high TPR and low FDR in all the cell lines (see examples on Supplementary Figure  S8A ). The directionality index leads to more replicate-dependent partitions, suggesting that DI is more sensitive to noise than the other methods. Predicted domain sizes distributions are also very similar between the two replicates for all investigated methods except for DI (see examples on Supplementary Figure  S8B ).
Improvement of the IC-Finder approach would thus require to also account for this active folding mechanism. More gener-ally, it is likely that the progresses in experimental Hi-C techniques would reveal higher-complexities at smaller scales in the organization of the--putatively assumed--irreducible ICs. This will prompt us to renew our parameter learning process and as mentioned just before probably complement our strategy of segmentation based on a refined theoretical chromatin folding prior. In conclusion, IC-Finder, based on mechanistic--polymeric--folding principles, is the first IC calling method to allow within the same, user-friendly, publicly-available and numerically-efficient software, to infer robustly the elementary segmentation of a Hi-C map without the need of parameter tuning, to investigate the different degrees of chromatin organization, and to estimate the prediction robustness regarding experimental errors.
Introduction Volunteer computing is the concept of using spare computing cycles on computers when they are not in use to perform a computational task for someone else. People typically "volunteer" their computers for public scientific projects in order to contribute to the greater good (such as searching for extra-terrestrial life or large prime numbers). The first big volunteer computing project was SETI@Home  [1] , where a program installed on volunteers' computers searched for evidence of extra-terrestrial life in radio signals from telescopes. Since then the volunteer community has grown to over 50 recognised scientific projects and hundreds of thousands of volunteers around the globe. The majority of volunteer computing projects use software called BOINC (Berkeley Open Infrastructure for Network Computing)  [2].
For example, even if a volunteer host allocates 4 CPU cores to the project, but it has only 8GB RAM, given the memory requirement from the ATLAS task, it can only use 3 CPU cores from this host. Also, running multiple virtual machines on a single host requires using more hard disk space for storing both the virtual machine images and the extra hard disk attached to the individual virtual machine. In general, each ATLAS@Home virtual machine uses around 10GB hard disk from the volunteer host. Inside the image, it uses the CERNVM File System (CVMFS)  [7]  to distribute the ATLAS software, and even though most of the software is already cached in the virtual machine image, each ATLAS task still needs to download files from the CVMFS servers while it is running. As the CVMFS cache cannot currently be shared among different virtual machines running on the same host, each virtual machine has to download the necessary files separately, increasing the network usage.
In BOINC, there is a piece of software named vboxwrapper which runs on the BOINC client side to control the creation of virtual machines, and it supports allocating multiple cores to a single virtual machine. As shown in figure  1 , on the BOINC server side, there is already a mechanism called plan-class, in which the project can define different plan-class tags and attributes, then associate the attributes with different application directories via tags. Attributes include the range of CPU cores and memory size for the virtual machine, and minimum and maximum VirtualBox versions required on the volunteer hosts. All the attributes are passed to the BOINC scheduler which does match-making between the required resources of the task associated to the application and the available resources reported by the client request.
The interface is built on javascript, mainly through the P5. js library [8], a sister project of the well known programming language, Processing. Within the interface the users can access, through visual and interactive animations, information about high energy physics in general, the ATLAS experiment and the ATLAS@Home project itself. Since the interface runs inside the same virtual machine as the ATLAS@Home task, it can present task-and volunteer-specific information in a highly personalised way. The welcome screen is shown in figure  5. It greets the volunteer by name and provides a menu of links to further information including: a brief explanation of the motivations behind ATLAS@Home; numbers showing the volunteer's contribution to the project; basic physics information on particles and forces in the Standard Model with links to ATLAS outreach web pages for further information; and links to the ATLAS@Home message boards for help and interacting with the community.
Integration with ATLAS Event Display In order to show more information to volunteers on what exactly is being processed on their PC, there is work on-going to integrate the ATLAS 3D event display, VP1  [9]. Being part of the experiment software framework, VP1 is able to access all the experiment data, and for that reason, it can be used to provide the volunteers with detailed visualizations of the processed data. Different new packages have been developed extending the event display capabilities, to access event data as soon as it has been processed on the volunteer's host and to produce on-the-fly visualizations. Also, a new mechanism has been developed to randomly pick a configuration file from a provided set, while producing the visualizations: the goal is to provide a quite different image for each event processed on the remote host, letting the volunteers see a different picture each time.
A key part of the project's success is that many of these volunteers are willing to help others in case of problems. The main communication channel with the volunteers is the ATLAS@Home message boards, which is an online forum provided by BOINC software. At the time of writing, there have been more than 5000 posts, mainly concerned with technical issues or questions. More often than not, a problem reported on the message boards will be answered by another volunteer rather than a member of the ATLAS@Home team. Some of these volunteers have much more experience of BOINC projects and provide generous assistance when needed. The project has grown steadily since the beginning and now on average roughly 2% of all ATLAS simulation events are generated on ATLAS@Home. Compared to an equivalent Grid site the manpower costs or running ATLAS@Home are negligible and the hardware comes for free.
The former finer HWHM binning was adopted for the subsequent spectral fitting as well as for obtaining velocity profiles of the lines, while the latter more coarsely binned spectra (FWHM or twice FWHM) were used for an initial inspection of the data and for some of the spectral plots. The MEG and HEG spectra were analyzed over the energy ranges of 0. 8-5. 0 keV and 1. 2-9. 0 keV respectively. Below 0. 8 keV, the signal to noise of the MEG data was low due to the build up of contamination over time on the ACIS-S CCDs and was excluded from the subsequent fitting. A cross normalization constant between the MEG and HEG spectra has been included in all the subsequent fits, however in each case it is consistent with 1. 0. Note the overall fluxes, obtained against an absorbed power-law, correspond to F 0.
Acknowledgements We thank the anonymous referee for their positive and constructive comments. J. N. Reeves acknowledges Chandra grant number  GO3-14123X , as well as  NASA  grant numbers  NNX16AE11G  and  NNX15AF12G. T. J. Turner  acknowledges  NASA  grant number  NNH13CH63C. Both J. N. Reeves  and  A. Lobban  acknowedge support from  STFC , via the consolidated grants  ST/M001040/1  and  ST/K001000/1. D. Porquet  acknowledges financial support from the  European Union   Seventh Framework Program  ( FP7/2007-2013)  under grant agreement number  312789. E. Behar  is supported by the the European Unions  Horizon 2020 research and innovation programme  under the  Marie Sklodowska-Curie  grant agreement no. 655324  and by the  I-CORE program of the Planning and Budgeting Committee  (grant number  1937/12 ).
Numerous contributions have been made for some years to allow users to exchange formal proofs between different provers. The main propositions consist in ad hoc pointwise translations, e. g. between HOL Light and Isabelle in the Flyspeck project or uses of more or less complete certificates. We propose in this paper a methodology to combine proofs coming from different theorem provers. This methodology relies on the Dedukti logical framework as a common formalism in which proofs can be translated and combined. To relate the independently developed mathematical libraries used in proof assistants, we rely on the structuring features offered by FoCaLiZe, in particular parameterized modules and inheritance to build a formal library of transfer theorems called MathTransfer. We finally illustrate this methodology on the Sieve of Eratosthenes, which we prove correct using HOL and Coq in combination.
Introduction According to the IEEE Standards Glossary, interoperability can be considered as the ability of computer systems or software to exchange and make use of information. Prover interoperability as a way for exchanging formal proofs between different theorem provers is a research topic that received many contributions along years. The most successful approach is probably the integration of automatic theorems provers (ATP) in interactive proof assistants (ITP) like Coq  [1]  or Isabelle  [6]. In that case more or less detailed witnesses are provided and proofs can be imported or re-built. Furthermore many ad hoc pairwise translations have been proposed e. g. between HOL Light and Isabelle in the Flyspeck project  [18] , between HOL Light and Coq  [12, 25, 19]  or between HOL and Nuprl  [15].
This proof illustrates our methodology. The paper is structured as follows. In Sections 2, 3, and 4 we present very briefly resp. the Dedukti logical framework, the FoCaLiZe system, and the Math-Transfer library. These tools form the basis of our approach to interoperability presented in Section 5. Sections 6 and 7 are devoted to a case study illustrating it on a correctness proof of the Sieve of Eratosthenes. Finally, we conclude and discuss in Section 8 the generality and reusability of our development. The MathTransfer library and our interoperability case study are distributed together at the following URL: https://gitlab. math. univ-paris-diderot. fr/cauderlier/math_transfer.
A proof in this language consists of intermediate lemmas and hints to the prover. When a proof is out of scope of the prover, a manual proof expressed in the backend language, Coq or Dedukti, is required. A FoCaLiZe unit, named a species, is made of signatures, properties, definitions of functions and types and also proofs of user-defined properties. A species mearly defines a set of values and functions manipulating them where the meaning of the functions are given by properties. Inside a species, the type Self denotes the type of these values, it is usually abstract early in the development and made concrete later. When a species is complete, that is every function is definied and every property is proven, it can be turned into a collection which is close to an abstract data type. FoCaLiZe features modularity, more precisely multiple inheritance.
Thus a species can be defined by inheriting from some others, allowing the reuse of all the signatures, definitions and proofs coming from them. When the definition of a function is inherited, it is possible to give it a new definition overriding the inherited one. This feature is not used here. A FoCaLiZe development appears as a hierarchy of species linked by inheritance, such as the one described in Fig. 1. Moreover species can be parameterized by collections. In that case, inside a species, the user is allowed to use functions and properties as black boxes as in a functor. In the following, we say a species is instanciated when it is applied to a particular collection. Similarly to the possibility to prove directly a theorem in one of the target logical languages, FoCaLiZe allows the definition of global symbols by custom external expressions of the target languages (OCaml, Coq, and Dedukti).
It is, with modularity, a key feature for our interoperability application. For example, addition of integers is defined in FoCaLiZe standard library as follows. It is declared with its type in the FoCaLiZe side, each branch in the definition maps + to a function written in the corresponding target language: let ( + ) = internal int -> int -> int external | caml -> {* Ml_builtins. bi__int_plus *} | coq -> {* coq_builtins. bi__int_plus *} | dedukti -> {* dk_int. plus *} ;; In this article, we use FoCaLiZe as an interoperability framework to provide the features missing in Dedukti for this task: modularity offered by FoCaLiZe inheritance, and proof automation provided by Zenon Modulo.
We decompose this task in three: we have to program the sieve in Coq, to specify its correctness, and to prove it. In Section 6. 1, we program the sieve in Coq and in Section 6. 2 we specify it and sketch a proof of the correctness of the algorithm. We highlight the mathematical theorems on which this proof relies. In order to experiment with interoperability, we will not prove these mathematical results in Coq but import them from the OpenTheory libraries 3.
Once translated in Dedukti by Focalide, this theorem matches the assumption of the correctness proof of the Sieve of Eratosthenes translated from Coq so we obtain a Dedukti proof of the correctness of the Sieve of Eratosthenes (item number 8 of our methodology). Quantitatively, the size of the various parts of this development are given in Fig. 4. The HOL part of the development consists in a fragment of the OpenTheory library that was developed independently and contains thousands of theorems irrelevant to our case study. The Coq development however is of reasonable size and was specifically developed for this case study. In the case of FoCaLiZe, more than half of the generated code is produced by Zenon Modulo; this shows how useful proof automation has been in this development. Finally, the small Dedukti development is taken from the merging of Coq and HOL logics in  [5].