dataesr/scientific-paragraphs-categorization huggingface dataset:
e. 2σ below φ Bayes d and φ FRAC d. We attribute this discrepancy to the inherent bias of ellipse-fitting techniques (see Appendix A), which increases with the level of offset noise or differential phase noise in either interferometer. We emphasize that a crucial input parameter for the Bayesian analysis is the common phase range. We use the accelerometer data to estimate this range once the experiment is complete: φ c ∈ [min(φ vib Rb ), max(φ vib Rb )]. However, if an accelerometer is not available, it is also possible to estimate this range using the raw data from a single interferometer. For example, one can reduce the interrogation time until the sensitivity to vibrations reaches a point where interference fringes are clearly visible. By measuring the rms scatter of the phase about a reference sinusoid, one can estimate the level of vibration noise via the relation a vib rms = φ vib rms /S.
05 rad was used for the differential phase noise of all data sets. The range of common phase noise was estimated from accelerometer measurements. In contrast, for Bayesian estimation, an increase in uncorrelated phase noise is problematic. When the "common phase" becomes largely uncorrelated, the Bayesian method can converge on multiple possible φ d , or may not converge at all. For these data, we find that by T K = 9 ms the Bayesian estimate of φ d is not consistent with the FRAC estimate, and for T K 8 ms the analysis is not able to converge on a unique value. We note that these particular results are strongly dependent on the level of phase noise, the degree of temporal overlap, the value of φ d and the scale factor of each interferometer. In the following section, we study some of these dependencies more quantitatively.
Examples of such regions include φ d = π/2 in the case of ellipse-fitting methods, and φ d = 0 or π for the FRAC technique  [71]. Both the FRAC and Bayesian methods also eliminate the systematic shift introduced on the measurement of ∆a when using dual-species interferometers with κ = 1-making them well-suited for upcoming WEP tests on ground  [43, 44, 45, 46] , in microgravity  [41, 47, 48, 49, 50] , and in Space  [7, 51, 52, 53, 54]. his assistance with the "Cicero Word Generator" control software.
Acknowledgements This work is supported by the  French national agencies CNES  ( Centre National d'Etudes Spatiales ), l' Agence Nationale pour la Recherche , the  Délégation Générale de l'Armement , the  European Space Agency ,  IFRAF  ( Institut Francilien de Recherche sur les Atomes Froids ), action spécifique GRAM ( Gravitation, Relativité, Astronomie et Métrologie ) and  RTRA "Triangle de la Physique". B. Barrett  and  L. Antoni-Micollier  thank  CNES  and  IOGS  for financial support. P. Bouyer  thanks  Conseil Régional d'Aquitaine for the Excellence Chair. Finally , the  ICE  team would like to thank the following people:  F. Pereira Dos Santos  of the laboratory SYRTE and  V. Ménoret of MuQuans  for helpful discussions;  D. Holleville ,  B. Venon ,  F. Cornu  of  SYRTE and J. -P. Aoustin of the laboratory GEPI  for their technical assistance building vacuum and optical components, and  T.
Section 3 shows how the possible plans to satisfy the intentions of the agent can be expressed compactly with the AgLOTOS specification language. From such an expression, the derived CPS structure is built automatically to process the agent guidance. Section 4 details the acquisition of past-experiences and their exploitation. In Section 5, the spatio-temporal guidance mechanism is presented, based on the CPS information enriched by the past-experiences of actions. Section 6 presents related work, then Section 7 concludes our paper. The overall agent architecture, we deal with, is standardly based on several processes. Triggered by some events expressing the context changes, the mental process is assumed to be highly deductive and rational, based on BDI structures (Beliefs, Desires and Intentions).
The plan structure is formally captured by using a formal description language, namely AgLOTOS. It introduces modularity and concurrency aspects to compose and schedule different sub-plans, viewed as processes  [1]. Let us now briefly recall the AgLOTOS-based specifications for plans. I = {i w 0 , i w 1 ,. , i w j } ⊙ E 0,1 E 0,k Agent plan level. The set of intention plans can be globally handled by using the concurrent ||| or sequential operators between intention plans, leading to the specification of an agent plan. Let P be the set of names qualifying the possible agent plans with P ∈ P and P be the set of names used to identify the possible intention plans with P ∈ P, such that P is any agent plan defined by: P ::= P | P ||| P | P P Intention plan level. An intention plan can be expressed by alternative elementary plans (P ), such that each one can be executed to achieve the corresponding intention.
Let Act = O ∪{τ }, be the set of actions, where τ is the internal action. In the context of this paper, the internal actions mainly correspond to the information related to the termination of a plan. The AgLOTOS language specifies pairs for each elementary plan composed of an identifier and an AgLOTOS expression to specify its behavior. The syntax of an elementary plan P is inductively defined as follows: P ::= E E ::= exit | a; E (a ∈ O) In this syntax, P ::= E represents an elementary plan identified by P , such that its behavior expression is E. The expression a; E denotes an action a prefixing E, and the elementary expression exit expresses the successful termination of some plan. For sake of concision, the other operators defined in AgLOTOS are not detailed in this paper. Please refer to  [1]  for more details, however, let us note that elementary plans do not generate new intentions, as it is the case for some other BDI approaches.
Data Acquisition The performance of an action a is evaluated w. r. t. a given context, however we focus on location. Each concrete performance of a in some location is considered as an (action) experience. -outcome ∈ {-1, 1} , is the result of the run performing a, respectively a failure or a success, -start ∈ R + , is the start date for the run of a, -duration ∈ R + , is the action duration which provides that a was successfully terminated, undefined otherwise. The structure represented in Figure  4  is generically called the Learned Contextual Experiences (LCE ). Regarding to the action a, LCE a shows different FIFO queues of experiences of a, distinguishing the different locations where the action was performed. The queue LCE a ( ) is ordered by the start date of the runs, so that the last recorded experience is at the top of the queue.
Introduction Like any other modern particle physics experiment, LHCb  [1]  faces multiple challenges when it comes to the data management aspect. The amount of data produced by the detector is such that a naive approach to storage is not enough, and one needs well defined policies for data handling, complex systems replicating the data all over the world, keeping a clear track of each individual file, guaranteeing the highest availability possible, but also allowing physicists to forget about the files themselves to focus only on the dataset that they want to analyze. In order to face these challenges, LHCb uses and develops the DIRAC interware  [2]. DIRAC is an integrated Data and Workload management system. This paper presents the various components of the Data Management system of DIRAC and how it tackles the problems mentioned earlier.
• etc The Bookkeeping is also used to group files in datasets that correspond to specific conditions and periods of data taking (or simulation conditions), and that have been processed in similar conditions. It is this dataset description which is used by physicists for selecting the set of files they want to analyze. A dataset is identified by a Bookkeeping path containing the origin of the data, the conditions (beam energy, magnetic field polarity, detector configuration, etc), the processing chains (reconstruction applications, physics selections, etc), the event type and the file type. Each dataset consists of a set of LFNs whose path is not related to the dataset path. Only the dataset path has a meaning for physicists.
DIRAC Data Management System All the complexity related to this dual aspect of files (logical vs physical) is hidden from the users and internals of DIRAC by the Data Management System. This system offers to the outside a simple interface which corresponds to all the traditional data management related activities, such as adding, replicating or removing files or replicas. The input parameters to these methods are always from the logical namespace, and the physical namespace is only used internally by this system. The Data Management implementation described in Fig. 1  offers several layers of abstraction that allow to: • Seamlessly replace the catalog we are using, or use multiple catalogs at the same time. • Transparently and with very limited changes support more access or transport protocols.
The FileCatalog object abstracts all the interactions with any catalog, the StorageElement object abstracts all the communications with the storage endpoints, and the DataManager object contains the logic of operations that require to interact with catalogs and SEs (e. g. replicating a file means to physically copy it and then register the new replica in the catalog). While simple and small data operations can be achieved using a set of scripts provided with DIRAC and its LHCb-specific extension LHCbDIRAC, production level activities need some more powerful tools, described in the following sections.
Transformation System The Transformation System  [4]  (TS) pictured in Fig. 2  is used to automate common tasks related to the production activity, be it related to data processing or data management. For data processing, the production manager uses a web application and predefined templates to describe the processing to be performed and the datasets, expressed as Bookkeeping queries (see subsection 2. 3), on which the processing should be applied. These descriptions are stored in a database table, the 'Input Data Query Table '. The datasets are then resolved and transformed into a list of LFNs that will fill the 'Production Input Files Table '. Similarly the data manager can create a Data Management transformation, specifying the input dataset and the operation to be performed. Based on this information, each transformation is creating a set of Tasks to be performed in order to achieve the result.
The Request object contains meta information about the action to perform, such as the Distinguish Name (DN) to be used or the component requesting the action. The actual tasks to be performed are described by the list of Operation objects. Each Operation has a Type and all the necessary data it needs to be executed. Examples of Operation Types are 'ReplicateAndRegister', 'ForwardDISET', 'UploadLog', 'RegisterFile', etc. Finally, if the Operation Type is a data management activity, a list of File objects is associated to the Operation. The RequestExecutingAgent will pick up Requests in the database and execute them in parallel. The code is very generic and easily modular: adding a new Type of Operation simply means adding a new plugin and declaring it in the DIRAC Configuration System. When the Operation consists in replicating a file, another DIRAC system is used: the DIRAC File Transfer system (FTS system), also visible in Fig.
DIRAC File Catalog The LFC service as currently existing is coming to an end of life. Thus, LHCb had to find a replacement for it, and an obvious option was the catalog integrated to DIRAC: the DIRAC The DFC was first presented at CHEP 2012  [6]. It was designed using the practical experience of the LHCb Data Management System and the use of the LFC, and was optimized for bulk operations. The DFC is fully integrated into DIRAC and uses its framework protocol called DISET. It aims at being a replica catalog together with a provenance catalog (see Fig. 4 ). Among its interesting features, one can mention: • User defined metadata: possibility for users to define their own metadata to be associated with their files. • Storage usage reports: the DFC keeps an accounting of the number of files and their size per storage and per directory, which is useful for strict quota enforcement.
5. Thanks to the AOP approach followed by the DFC, the developments needed by LHCb were relatively limited: • New aspects only for the directories and the files management, without having to touch anything related to the other aspects. • Introduction of Foreign Keys in the database. This strongly couples the different aspects at the database level, however this is a price that we were willing to pay in order to ensure the consistency of the data. • Usage of stored procedures for performing the actions. One advantage of this is the small gain in performance one can obtain, since the procedures are compiled 'once' only, contrary to SQL statements started from the code. But the main advantage is that manual interventions on the database, if necessary, become much easier since adding/removing directories or files require interactions with several tables.
We ran extensive testing campaigns against the DFC. The tests consisted in running for a long period against the DFC at least the peak load observed against our LFC, with an activity shape similar to the real one. Also the spreading of files in directories and depths of paths was inspired by the production system. The conditions were as follows: • Access pattern -Read: 90% -Write: 5% -Delete: 5% • Bulk operations: between 1 and 1000 files The tests were run on a standard 12 core machine with 48Gb of memory and local disk without RAID setup. Since the production instance is hosted on the CERN Database On Demand instance for which we have no control on the hardware, the raw performance numbers coming out of these tests have little importance, but we were interested in seeing their evolution as the amount of data increases.
LFC to DFC migration Thanks to the abstraction layers in DIRAC presented in subsection 2. 5, switching from the LFC to the DFC is not an issue from the code perspective. However, migrating the existing data from one to the other represents a major operational challenge. This operation cannot be performed in one go and required several steps: • Cleanup of the LFC. A careful analysis of its content showed that many data were obsolete, but more importantly that there were inconsistencies. Since the DFC ensures the consistency, the data could not be migrated as such and required a cleanup first. • Perform the actual migration, which will be described further in this subsection. • Keep the synchronization between the LFC and the DFC for a few months. One interest of this is that in case we notice a major problem with the DFC, we could always just fallback on the LFC and reattempt the migration later.
The second interest is that we have a comparison model, and we can check whether the DFC properly executes the operations. Keeping the synchronization is technically simple, again thanks to the design of the DIRAC DMS. • Totally retire the LFC. Various scenarios were considered to perform the actual migration from the LFC to the DFC. The criteria taken into account in order to make a choice include the time it would take, the consequence of an error, the impact on the rest of the system and the complexity and reproducibility of the procedure. The approach we decided to take is described in Fig. 9. • Stop all the writes. This allows to "freeze" the LFC database for the time of the migration. • Keep the LFC in read mode. Read operations do not harm the migration procedure, and allow users and jobs to still perform some work.
• Copy the data from the Oracle LFC schema to the MySQL DFC schema. This is done using a tailored Python and SQL script that performs all the necessary schema conversions. • Reopen the LFC and the DFC in write. Any item inserted is present in both catalogs. • Open the DFC and close the in read. In this way, we are sure to notice problems if the write operations were not executed properly against the DFC. From the operational point of view, we could have left the system running. Indeed, at no point in the procedure are the read operations disturbed; For the write operations, the job have failover capabilities, and they would simply have created a Registration request (see section 4) when failing to register their output data, that would have been executed later, since the RMS was stopped during the migration.
LHCb Dataset federation The aim of a dataset federation is to present a unified view of all the files and allow access to any replica of a file in a seamless manner, including failover strategies. This strategy is praiseworthy, especially in our grid context where experiments tend to broker the jobs where the data required by a job is parked. Typically, the jobs are brokered using the information contained in the replica catalog. The advantage of a dataset federation is that in case the local replica is not available (either due to temporary problems on disk server or service overload), the job could fallback on another replica. One method to achieve this result that seems to be popular lately is to have a central service such as the xrootd or the HTTP federation. Basically, when the job fails to open the replica, it will ask this central service for an alternative one.
The central service will query all the storage element endpoints to see if another replica is available at this very moment. Once a proper replica is found, redirection occurs such that the job can keep running on the remote file. The drawback of this method is the need of a central service, that represents a single point of failure, and could become resource hungry depending on the scale of the experiment. LHCb decided to go for an alternative approach. Since all the required information concerning all the replicas of a file can be obtained from the various tools presented in this paper, we decided to provide the job with all the data location information. This takes the form of an XML file which contains the URLs for all the replicas of the files required by the job, starting with the local URL.
All the LHCb software stack relies on a common framework, Gaudi, which actually takes care of opening the files. Ten lines of code were sufficient so that Gaudi uses the XML file and loops over all the replicas until one is successfully opened. This naturally achieves the aim of a data federation, without the need of a heavy central infrastructure with the risk of the single point of failure, with very little development and no maintenance effort. We have been successfully running this in production for more than six months now.
Conclusion Data management concepts are by definition simple: replicate, add, remove, etc. The DIRAC Data Management System and the whole LHCb data management policy aims at bringing this simplicity down to the logic and the core of the system. This is reflected by the single system we have for handling both productions and bulk data management operations, the very generic approach taken by the Request Management System that serves as a failover solution for jobs and as an asynchronous executor for any operation, or the dataset federation achieved with only ten lines of code. Keeping the logic simple is also what allows LHCb to run with a very limited amount of manpower: two developers and one part time operational role for what concerns the data management. A simple logic does not translate into simple code.
Lots of effort is put into the data management code in order to provide enough abstraction layers so that the users and the rest of the DIRAC systems are totally agnostic to any change that could happen in the underlying services used by LHCb: storage access protocol, FTS servers, etc. The best illustration of this decoupling is certainly the recent and very successful migration of the LHCb replica catalog from the LCG File Catalog to the DIRAC File Catalog. There was hardly any change needed in the code to prepare the transition, and users would probably not have realized the change if we did not announce a downtime for performing the migration. The DIRAC and LHCb Data Management Systems keep evolving in order to stick with the latest services provided such as new FTS3 features, direct XROOT or HTTP storage accesses or underlying library changes like GFAL.
21st International Conference on Computing in High Energy and Nuclear Physics (CHEP2015) IOP Publishing Journal of Physics: Conference Series 664 (2015) 042025 doi:10. 1088/1742-6596/664/4/042025 • Load at the end of Run 2 : 20M directories, 100M files, 200M replicas. • Strong consistency between the entities guaranteed (e. g. no file can belong to a non-existing user). • Hosted on MySQL, preferably the CERN MySQL Database on Demand service.
Search of systematic reviews with MAs of aggregated data assessing orthopaedic surgical procedures On 6 April 2014, we searched MEDLINE via PubMed for systematic reviews published between 1 January 2013 and 31 December 2013, using the search equation reported in Additional file 1. This search equation combined MESH terms related to: orthopaedics and free-text words corresponding to the main orthopaedic surgical procedures; publication type and free-text words corresponding tosystematic reviews and MAs; and a modified version of the Cochrane Highly Sensitive Search Strategy to identify RCTs. In addition, we performed a search of the Cochrane Database of Systematic Reviews (Orthopaedics and Trauma and Rheumatology) to identify Cochrane systematic reviews assessing an orthopaedic surgical procedure and published in 2013.
Selection of systematic reviews The title, abstract and full text, when necessary, of all identified references were screened by two authors (BV and PB). We included systematic reviews written in English or French and published in 2013 that assessed an orthopaedic surgical procedure, with no restriction on comparator (usual care, placebo, conservative intervention, pharmacological treatment or other surgical implant or procedure), and including an MA of aggregated data based on two or more RCTs. Systematic reviews and MAs that were withdrawn were excluded, as were those for which the full text was not available.
Identification of RCTs relevant to the clinical research questions We identified all RCTs included in the systematic reviews with MA of aggregated data for the clinical research questions. All RCTs were selected provided they were written in English or French and results were published since 2000, because for trials with results published before 2000, we anticipated difficulties in contacting corresponding authors and obtaining IPD from these trials. Non-randomized studies and quasi-RCTs were excluded, as were RCTs not indexed in MEDLINE. If corresponding authors were involved in several RCTs corresponding to different clinical research questions, we contacted them for only one clinical question chosen at random. Only the RCTs corresponding to this clinical question were selected.
The geographic location of the corresponding author's affiliated institution was used to define the location of the study when the study location was not reported or when the RCT was an international multicentre study. We also extracted the number of patients randomized in each RCT. Characteristics of the journal in which the RCT was published: name of the journal, whether it was specialized or general and its impact factor. We classified journals according to whether they were in the 10 highest impact factors for a medical condition according to the Journal Citation Reports. We also recorded whether the journal had a data sharing policy and, if so, whether data sharing was a mandatory condition to publish.