dataesr/scientific-paragraphs-categorization huggingface dataset:
The Galactic Center (GC) region has been extensively studied with XMM-Newton and Chandra and several mega-seconds of raw exposure have been accumulated to date. Three recent studies  [608] [609] [610]  argued that this line may be a potassium K XVIII transition (as it is difficult to put an upper bound on the potassium abundance in the GC). However, as was argued in ref. [608] , the correct question is: Are the observations of the Galactic Center consistent with the Dark Matter interpretation of the 3. 55 keV line of ref. [190, 191] ? This is a non-trivial question, as the DM interpretation of the 3. 55 keV line in M31 and the Perseus cluster puts a lower limit on the flux expected from the GC. On the other hand, the non-detection of any signal in the off-center observations of the Milky Way halo (the blank sky dataset of ref.
[191] ) provides an upper limit on the possible flux from the GC, given observational constraints on the DM distribution in the Galaxy. ref. [608]  argued that the flux from the GC falls into this range, while a consistent interpretation of the line in all the datasets as an atomic transition is problematic  [624, 625]. Even though the recent studies of stacked spectra of dwarf spheroidal satellites of the Milky Way by ref. [596] , and galaxy clusters with Suzaku by ref. [612]  and ref. [614]  are in tension with the initial value of the DM lifetime from ref. [190]  (which is based on their estimates of the DM content of their galaxy clusters), all of this work still leaves parameter-space for a common interpretation of all detections and non-detections in terms of DM. An overview of the detections and how they relate to each other and to the Dark Matter interpretation can be found in figure  34.
It also confirmed that 10 other as well as the 2σ upper bound from the blank sky dataset (from ref. [191] ) as a function of the expected DM signal; see also Ref. [313]  which provides one of the strongest constraints on the line from the Chandra of M31. The results from ref. [190]  are shown as the diagonal shaded strip (width ±1σ). The vertical sizes of the boxes are ±1σ statistical error on the line's flux. The horizontal sizes of the boxes represent systematic errors in mass modeling: the projected mass density calculated using different literature models of the DM distribution. Diagonal lines correspond to different lifetimes of DM particles, assuming a decaying DM interpretation of the signal. Blue shaded regions give an example of the relation between the projected DM mass densities in the GC and in the blank-sky dataset based on the Milky Way mass model of ref.
The ECHo program to investigate the effect of keV sterile neutrino on the 163 Ho EC spectrum can be divided into two parts: • assess systematic effects and analysis of high statistics 163 Ho EC spectra searching for a kink at Q ECm 4 • develop efficient methods to acquire and store large number of events The first part of this investigation will be carried on during the first stage of the ECHo experiment, ECHo-1k. The assess of systematic effects due to the not precise knowledge of the calorimetrically measured spectrum of 163 Ho is a fundamental milestone to reach the sub-eV sensitivity. The precise knowledge of the Q EC is of outmost importance not only for the investigation of the "standard" effective electron neutrino mass, but also to define with high precision the value of the heavy neutrino mass m 4 through the difference between the position of the possible kink and the endpoint of the spectrum.
Acknowledgments The work of  C. Giunti  was partially supported by the research grant Theoretical Astroparticle Physics number  2012CPPYP7  under the program PRIN 2012 funded by the  Ministero dell'Istruzione, Università e della Ricerca (MIUR). The authors of Section 2 would like to thank  A. Vincent  for discussion and comments. The work of  A. Mirizzi  is supported by the  Italian Ministero dell'Istruzione, Università e Ricerca (MIUR)  and  Istituto Nazionale di Fisica Nucleare (INFN)  through the " Theoretical Astroparticle Physics " projects. The work of A. Ibarra was supported in part by the  DFG cluster of excellence "Origin and Structure of the Universe " and by the  ERC Advanced Grant  project  "FLAVOUR" (267104 ). M. Viel is supported by the  ERC StG  "cosmoIGM". The work of O. Dragoun was supported by the  GACR  (contract  P203/12/1896 ) and the  ASCR  (contract  IRP AV02 10480585 ).
This work was supported in part by the  Gottfried Wilhelm Leibniz Programme of the Deutsche Forschungsgemeinschaft (DFG)  and the  NSF  grant  PHY-1307372  at  UCSD. M. Laine was supported in part by the  Swiss National Science Foundation (SNF)  under grant  200020-155935. A. Merle  acknowledges partial support by the  Micron Technology Foundation, Inc. V. Niro acknowledges support by  Spanish MINECO  through project  FPA2012-31880 , by  Spanish MINECO (Centro de excelencia Severo Ochoa Program)  under grant  SEV-2012-0249  as well as the Spanish grants FPA2014-58183-P, Multidark  CSD2009-00064  and  SEV-2014-0398  (MINECO) and by the  PROMETEOII/2014/084  grant from  Generalitat Valenciana ; the work of  V. Niro  was also supported by the  Deutsche Forschungsgemeinschaft (DFG)  through the  Collaborative Research Centre SFB 676 "Particles, Strings and the Early Universe " (through an  SFB fellowship ).
HARDWARE PLATFORM As mentioned earlier, we use an embedded system platform for our implementation. Being increasingly available and cheap, we choose the popular Raspberry Pi c (RPi) as main processing unit of our platform, which is a credit-card size ARM architecture based computer running Rasbain c , a Linux variant operating system. Having 1. 2 GHz 64-bit quad-core CPU and 1GB of memory allows to run smoothly most of image processing and computer vision techniques. A description of the built system is shown in Figure  2 , which is composed of two RPi's computers each is connected to one camera module to form a stereo pair. The cameras are synchronized using a hardware trigger. Both computers are connected to one more powerful computer that can be either within the same enclosure or on-board in our case.
ACKNOWLEDGEMENTS This work has been partially supported by both a public grant overseen by the  French National Research Agency (ANR)  as part of the program Contenus numériques et interactions (CONTINT) 2013 (reference:  ANR-13-CORD-0014 ),  GROPLAN  project  (Ontology and Photogrammetry; Generalizing Surveys in Underwater and Nautical Archaeology ) 3 , and by the  French Armaments Procurement Agency (DGA) ,  DGA   RAPID LORI project (LOcalisation et Reconnaissance d'objets Immergés ).
When a replica generates an operation, it increments its local counter. However, when the add is delivered, the element should have an effect only if it has not been previously delivered. Otherwise, it updates the counter of the remote replica and deletes the previous tags of the same element delivered from the same replica. OptORSet reduces the memory requirement by keeping only the last tag of the element peer replica. A Framework for Performance Evaluation of Decentralized Eventual Consistency Algorithms Text Data Type. For text data type, the framework supports two approaches that ensure the eventual consistency: Operational Transformation (OT) approach  [8, 12, 27]  and Commutative Replicated Data Types (CRDT) approach  [24, 31]. Operational Transformation (OT) Algorithms: The Operational Transformation approach was introduced to overcome the problem of divergent copies in synchronous collaborative editors by serializing concurrent operations  [8, 27, 34, 46].
All commits (diffs and merge states) and their vector clocks, are stored in Apache CouchDB database  [9]  in order to be used by all the runs of the different algorithms. In DVCSs, merging is not a fully automated process. When a user merges, it obtains a besteffort result -computed using three-way-merge techniques. The user must change this result in case of conflicts. He may also change the result, if, for instance, the merged source code does not compile. The stored merge state is the result of the whole process. Our framework simulate the same behavior during collaborative editing algorithm evaluation. A best-effort merge is obtained using the evaluated algorithm and a "correction" is computed on-the-fly to obtain the result intended by the real user that done the merge. In addition, an algorithm that requires more corrections will loss in performances since it will have more operations to treat.
Synchronous Experiment Results In the following, we present the experimental results retrieved through our framework, by using synchronous corpus. Firstly, we present the different corpus obtained and some experiments made as an example. Secondly, we present a performance evaluation of some algorithms for different data types. The experiments were performed on virtual machines of Amazon Elastic Compute Cloud (EC2). We run each experiment a virtual machine with Intel(R) Xeon(R) 5160 one-core processor (4096K Cache, 2. 27GHz, 2266. 746 MHz FSB, 3. 75 GiB of memory), that has installed GNU/Linux ubuntu 12. 04.
Performance in Set Data Type Algorithms The performance of different algorithms designed for set data type are presented in this section. Even if the framework supports CvRDT and CmRDT (Section ), we present as an example in this paper only results of CmRDT. Since the different algorithms have different semantics, we run each algorithm one hundred time and each time in different simulated data (except for OR-set and OptORSet in the same data since they have the same semantics). In the following, we present the results of two experiments: by changing the size of the data set and the percentage of insertions. In Figure  4 (a) and 4(b) we present respectively the average execution time for each algorithm during the generation and integration of operations. The results of execution time indicate that: • OptORSet and ORSet algorithms are the worst in execution time.
Performance in Text Data Type Algorithms In  [1] , we evaluated through our framework different collaborative editing algorithms in real traces described  above. However, in this paper we extend the performance evaluation with two other algorithms that we did not in  [1]. In addition, we perform another kind of performance evaluation such as memory requirements and size of messages in different large corpus. In this section, we present the results of two experiments: i) the performance of algorithms on simulated data inspired from collecting synchronous real traces, ii) algorithm's performance in a real asynchronous traces Mehdi Ahmed-Nacer and Pascal Urso obtained from github. As an example, we measured the performances of six algorithms: SOCT2/TTF, WOOTH, RGA, TreeDoc, Logoot, and LogootSplit.
As shown by our experimental results, the choice of the best algorithm depends highly on the application and user context. For the set data type algorithms, CounterSet is the best choice in execution time and for application with a large dataset. While, LWWSet algorithm is good for applications that require low memory. We found also, OptORSet algorithm designed to reduce the memory requirement does not. Indeed, the vector used to detect the partial order of elements hide the memory saved. For text data type algorithms, TreeDoc is a very good generic algorithm. It performs the best or among the best for almost all experiment. However, we cannot recommend it for every usage. For collaborative activities with a very large number of participants, RGA and WOOTH are more suitable. Indeed, their remote execution times are the best.
Memory requirement Table  10  presents the total memory occupied by the algorithms during the experiments and their average message size. We also present the space occupied by the git software in its. git directory. The obtained results are consistent with the synchronous experiment. The ranking between the algorithm is respect except than Logoot performs relatively better in the asynchronous one. The algorithms based on tombstones -SOCT2/TTF, RGA and WOOTH in this order -have the worst performances since they do not delete the elements. TreeDoc and LogootSplit obtain the best performances. CRDT algorithms memory is lower or comparable to the corresponding. git directory size despite the poor performances of the Java serialization mechanism and the compression made by the git software. 9 owever, git software is able to retrieve any past states of the document.
In this experiment we did not assess the memory space required and messages size produced. In  [19] , we evaluated also through our framework the performance of the different tree data type. However, we presented just the results without explaining in detail what the framework provides. At this time, the framework was not able to use an asynchronous traces. In  [2] , we evaluated the text data type in asynchronous traces. We used the framework to observe the cases where the conflict occurs and after we proposed a methodology to evaluate the algorithms in merge quality. For the set data types, in  [7]  the authors improved OR-Set algorithm and presented the result of its performance. The authors implemented a Java client library and perform the experiment in the real database, but the tool used remains private.
The framework provides also a mechanism to extract the DVCS history to simulate an editing session. Moreover, the framework gives to the user the entire control of different parameters during the simulation. Depending of these factors, the framework allows to detect which factor most affects the algorithms performances. It helps to select which algorithm is the most suitable for which situation. We found out that CRDT algorithms are suitable for synchronous and asynchronous application. Moreover, they outperform some representative operational transformation approaches that were well established for real-time collaboration. However, We found that the choice of algorithms depends on the target of the application and the type of collaboration. For the set data type algorithms, CounterSet is the best choice in execution time and for application with a large dataset.
While, LWWSet algorithm is good for applications that require low memory. We found also, OptORSet algorithm designed to reduce the memory requirement does not. Indeed, the vector used to detect the partial order of elements hide the memory saved. However, for text data type algorithms, we found that the major factor that affects the algorithms based on tombstones are the size of insertions and number of operations in addition to the number of replicas for OT algorithms. We found also that the algorithms based on blocks are more suitable for state-based approaches than operation-based approaches. indeed, in state-based approaches, the operations are composed of commit and merge operations (treated by lines), Whereas operation-based approaches are based on characters granularity. On memory, LogootSplit and Treedoc are the most appropriate for the both approaches.
Acknowledgment This work is partially supported by the  ANR  project  Concordant   ANR-10-BLAN 0208. The authors would like to thanks following people for their contributions to the algorithms implementation :  L. André  ( Logoot-Split ),  G. Oster  ( SOCT2 ),  H. -G. Roh  (RGA),  M. Zawirski  (TreeDoc) and  S. Martin  (measurements).
PoS(ICRC2017)449 First results from AugerPrime Zizhao Zong local station and sent to the central data acquisition system (CDAS) every 6 minutes. The signals of shower events from the detectors are calibrated based on the real-time muon spectra. The average signal shapes of background muons from WCDs and SSDs are also recorded and sent to CDAS (see Fig. 3 ). Various quantities to evaluate the detector performance can be parameterized from the digitized average signal shapes. The PMTs have a fast response to a single muon, dominated by the Cherenkov light reflected only once at the tank liner. After reaching the peak, the signal exponentially decays due to the losses in consecutive multiple reflections and absorption in water, since the decay time of the muon signals in WCDs is related to the reflection coefficient of the liner and to the transparency of the water in each WCD.
Summary The AugerPrime engineering array has been taking data since October 2016. Detectors are calibrated with the charge of single VEM for S WCD and single MIP for S SSD. The upgraded stations with WCDs and newly deployed SSDs operate with good stability at the Auger site under a harsh environment with a day-to-night temperature fluctuation of >20 • C. Signals from EA stations are in a good agreement with the LDF curve fitted with signals from the existing stations. The global LDF for S WCD from the upgrade stations, normalized by the shower size, agrees well with the results of the LDF fitted to the existing stations. Furthermore, the global LDF of S SSD shows the SSD sensitivity to the EM components of the EAS as expected. The signals from doublet stations are well correlated and the measured signal accuracy for the WCDs of the upgraded stations is around 10%.
The Mizar system is one of the pioneering systems aimed at supporting mathematical proof development on a computer that have laid the groundwork for and eventually have evolved into modern interactive proof assistants. We claim that an important milestone in the development of these systems was the creation of organized libraries accumulating all previously available formalized knowledge in such a way that new works could effectively re-use all previously collected notions. In the case of Mizar, the turning point of its development was the decision to start building the Mizar Mathematical Library as a centrally-managed knowledge base maintained together with the formalization language and the verification system. In this paper we show the process of forming this library, the evolution of its design B.
The use of special vocabulary files for symbols together with infix, prefix, postfix notation and their combinations resulted in greater closeness to mathematical texts. In 1986, Mizar-4 was ported to the IBM PC platform running MS-DOS and later became PC-Mizar in 1988. In the years 1987-1991 the Mizar system and language played an important role in a Polish state research grant programme of the Polish Ministry of Science and Higher Education RPBP III. 24 "Logical systems and algorithms for computerized checking of proof correctness". It was this project that significantly boosted the development of Mizar articles by numerous authors (about 100 researchers and students from a dozen of scientific institutions from all over Poland), whose efforts resulted in almost 250 Mizar articles. Some of the articles were quite advanced.
This approach, however, turned out to be inefficient for bigger formalizations, which subsequently gave rise to developing methods of exporting only selected items from an article supported by corresponding changes in the Mizar language to facilitate both exporting and importing required notions. Later these concepts evolved into current forms used for importing theorems, definitions and other items from various articles. The functions of the librarian utility were superseded by extractor and accommodator, for extracting semantic information from an article into a database and including this information into a new formalization, respectively. From that time comes the conventional distinction between the library of Mizar articles (as a collection of user-written files in the Mizar language) and the database consisting of the exported semantic information stored in dedicated machinereadable and optimized data formats.
It was intended to avoid declaring ad-hoc axiomatics required for proving facts in each article, to help establish "a minimal axiomatization" for a particular article, to reduce the risk of introducing contradictory axioms and repetitions of already proved facts. January 1st, 1989 symbolically marks the date when the current Mizar library-Mizar Mathematical Library (MML) was born as the implementation of that proposal. The (still on-going) process of building one common framework for verifying various branches of mathematics gave rise to a number of subsequent fundamental questions, e. g. : -should various axiomatizations be allowed or not (and if only one, then which one should be chosen); -how to build the knowledge database and what information should be stored in it; -how to organize, manage and ensure the integrity of the database.
In particular this concerned the arithmetic of complex numbers, so that the users could decide whether they want the arithmetic facts to be obvious for the Mizar checker  [63, 68]. At the same time, the automatically obvious facts found their justification in corresponding ordinary Mizar articles to 123 enable their cross-verification and allow switching off the automation in special contexts, e. g. for educational purposes or for experimenting with axiomatic systems  [6]. The separation and consequent use of the minimal axiomatization was an important landmark and since then has been the main approach taken in developing the current MML. This allows to shift the focus in extending the proof checking mechanisms from implementing hard-coded system procedures towards language extensions like registrations  [62] , properties  [49, 60] , or reductions  [51].
MML Information Storage The way in which the information is stored in the MML is a key property of the library. The basic library import/export unit is an article, resembling the conventional publication practice of mathematical papers. Initially, the article's authors decide which definitions and statements they would like to export and make available to other formalizations, and which should be considered local only. In the process of peer review coordinated by the Library Committee 6   [30] , all exportable items are finally selected and extracted to form the, so called, abstract, which contains the bare statements of definitions, theorems, schemes and registrations stripped of all their corresponding proof parts. This public interface information is subsequently stored in the database in dedicated XML-based internal data formats.
For any definition, theorem, scheme, or registration, the database contains the corresponding formula represented using constructors  7. Different kinds of constructors are used to refer to different classes of defined notions, see Table  1  for the use of constructors and their notations in the current MML. The information stored in the database which corresponds to a definition, similarly holds a formula (the definiens), but also the definition's notation which consists of its format and type information of its arguments, as well as the result type for functor definitions and the mother type for mode definitions. The format of a given definition contains the corresponding symbol (string of characters) together with the information on the arity and position of visible arguments in the text representation.
The symbols grouped according to constructor kinds, possibly with additional priority declarations, are stored in, so called, vocabularies. Table  2  shows the number of symbols in each category. The separation of vocabularies from the articles that first introduce given symbols facilitates the use of symbols for multiple, sometimes completely unrelated, notations. Table  3  presents the number of notations for most popular symbols. The same format can also be used for arguments with different types, most importantly in the case of the redefinitions of previously defined notions with more specific type restrictions, see Table  4. It should also be noted that selected definitions declare special properties of the defined notions to enable further automation in the proof checking software. The information stored in the current database with respect to these properties of predicates, functors and modes is shown in Table  5.