dataesr/scientific-paragraphs-categorization huggingface dataset:
The gosia code does not provide a way to determine the error bar on the calculated population numbers. The uncertainty on the relative population that is mentioned in Table  4. 15, is determined by hand, folding in the relative error bar on the extracted matrix elements coupling to the respective state. The negative sign for the loop 0 + 1 ||E2||2 + 1 × 2 + 1 ||E2||2 + 2 × 0 + 1 ||E2||2 + 2 in solutions 3 and 4, gives a lower population of the 2 + 2 state, relative to the 2 + 1 state. In order to reproduce the experimentally observed yields, the diagonal matrix element of the 2 + 1 state has to be increased to large values, which exceed the rotational limit (1. 3 eb for solutions 3 and 4) by far. Because of this unphysically large value for 2 + 1 ||E2||2 + 1 , these two solutions are disregarded.
We describe a comparative analysis of different tools used to assess safety-critical software used in nuclear power plants. To enhance the credibility of safety assessments and to optimize safety justification costs, Electricit e de France (EDF) investigates the use of methods and tools for source code semantic analysis, to obtain indisputable evidence and help assessors focus on the most critical issues. EDF has been using the PolySpace tool for more than 10 years. Currently, new industrial tools based on the same formal approach, Abstract Interpretation, are available. Practical experimentation with these new tools shows that the precision obtained on one of our shutdown systems software packages is substantially improved. In the first part of this article, we present the analysis principles of the tools used in our experimentation.
One of the investigated approaches is the semantic analysis of source code. EDF has been using the PolySpace Verifier  [1]  tool for > 10 years to perform static analyses of protection system software  [2]. The results of the analyses are sent to the Safety Authority as are others documents, as part of the qualification process for safety critical systems. For software aspects, EDF follows the IEC 60880 standard. The static analysis complements the verification activities, mainly based on test activities, done during the software life cycle. EDF performs static analyses on refurbishment or software evolution of existing protection systems, and is currently performing theses analyses on the EPR Flamanville protection system, Areva NP, La D efense/France. Currently, new industrial tools based on the same formal approach, Abstract Interpretation, are available, such as Astr ee [3] and the plug-in Value Analysis of Frama-C  [4].
This article describes a practical experimentation with these three tools, and shows that the precision obtained on one of our shutdown systems software packages is substantially improved, compared with PolySpace Verifier. We are now able to provide formal evidence that this software, including application and system parts, is free from intrinsic run-time faults. In the first part of this article, we present the tools used in our experimentation, and Abstract Interpretation, the underlying approach used by these tools. In the second part, we present the main characteristics of protection-system software, and why these characteristics are well adapted for the new analysis tools. In the last part of this article, we present an overview of the results and limitations of the tools.
2. 3. Results given by the Frama-C tool Frama-C is a modular static analysis framework for the C language. Within this framework, a number of plug-ins offer different kinds of static analysis. For our experimentation, we mainly use the plug-in value that uses Abstract Interpretation to compute sets of possible variable values for analyzed software. Prior to analysis, the tool performs a number of local transformations in the normalization phase. These transformations aim at making further work easier for the analyzers. Analyses usually take place on the normalized version of the source code. Normalization results in a program that is semantically equivalent to the original one but that uses fewer instruction types (e. g. , all loops are transformed into while loops). The results given by Frama-C are written directly in the simplified source code as assertions generated by the analyzer, but only potential or proven errors are given (red and orange results from the PolySpace tool).
The unreachable code is highlighted in orange. In comparison with the PolySpace tool, Frama-C does not explicitly signal green diagnostics. The error types covered by Frama-C (and described in Table  1 ) are similar to those of PolySpace. In addition, Frama-C generates an assertion for pointer comparison. This assertion warns that in the C language, the comparison of variable addresses may vary from one compilation to another, such as &a < &b or &x < 0x600,000. We will detail this point later. As with PolySpace, the user can examine the sets of values for each variable at each point of the analyzed software. These sets are discrete values or intervals. However, unlike Poly-Space, Frama-C does not use sophisticated abstract domains such as polyhedra. In the objective of proving the absence of error, the user has to add specific assertions to help the analyzer to prove generated assertions, or the user has to argue that these generated assertions are due to the analyzer's overapproximation.
System architecture For our experimentation, we analyzed a prerelease version of the software of a refurbished nuclear power plant (NPP) shutdown system. This system is computer based and is one of the most critical systems in an NPP. These systems must be simple in order to obtain a high level of confidence. Rolls Royce Civil Nuclear developed the Instrumentation & Control (I&C) system and Operating System (OS) software, and AREVA NP will develop the application software. The software has no interruptions and is a sequential infinite loop composed of the following steps: (1) self-monitoring; (2) cycle time management; (3) data acquisition; (4) application processing; (5) data output; and (6) local terminal management. The system is composed of three types of electronic board. (1) One digital processing module: This card runs the OS and the application software.
Controlling abstract domain precision As introduced in the "Results given by the Frama-C tool" section, the abstract domains used by Frama-C are either sets of discrete values or intervals. An option manages the threshold at which a set of discrete values is approximated by an interval. This option could reduce the number of false assertions but needs more computer resources. Another option is used to indicate the number of array cells that the tool can distinguish. Above the user-set limit, all the cells' abstract domains are merged, causing approximation. This option was useful for our case study, as the source code uses large arrays for system configuration purposes.
Results We used the same case study, with the same code transformation just described, with three static analysis tools: PolySpace Verifier, Frama-C, and Astr ee. For Astr ee tool, the evaluation was done in the short 30-day free trial period. The versions used are as follows: PolySpace R2011a, Frama-C fluorine 3, and Astr ee Version 13. 04. The analysis time was about 1 hour on a standard workstation for the three tools. In the end, we noted the number of potential errors that have to be checked by the user. These are the number of orange diagnostics for PolySpace, assertions to prove for Frama-C, and alarms emitted for Astr ee. PolySpace gave 995 orange diagnostics and eight red diagnostics (concerning voluntary unsigned overflows), Frama-C generated 153 assertions to prove, and Astr ee emitted 127 alarms.
For Astr ee, we did not generate alarms for noninitialized variables because the evaluated version had a known "bug" which gave too imprecise results. Thus, an accurate tool will raise fewer potential false errors, as illustrated in Chapter "Analysis principles: abstract interpretation". The Abstract Interpretation theory guaranties that no real faults, of the type checked, are missed by the tool. For PolySpace, the excess of NIV and IDP checks is mainly due to the fact that the system software uses a lot of pointers to absolute addresses. For PolySpace, both reading from and writing to an absolute address leads to warning checks on the pointer dereference. An absolute address is considered a volatile variable. An in-depth analysis of the results shows that access to absolute addresses generated 129 IDP checks and 77 NIV checks.
Frama-C manages absolute addresses as global variables. The user has to specify a range of valid addresses. This is possible with the analyzed software, because we have the memory mapping of the executable code. With this information, we also guarantee that there is no interference between global C variables and access to absolute addresses. However, Frama-C cannot consider an absolute address as a volatile variable. To model access to a hardware register, we had to modify the source code. Astr ee goes further in managing absolute addresses: for each address the user can associate a C type and define if it is a volatile cell or a previously defined global variable. This information is used to detect if there is an index overflow when accessing an array defined by an absolute address, and reduces the generated alarms by Frama-C when comparing two global variables or a variable with an absolute address.
The number of diagnostics given by PolySpace and the limited means to understand where an overapproximation has been done by the analyzer prevent us from analyzing each of them. With Frama-C, we analyzed each assertion to prove. For each, we could: (1) confirm that it was a real bug; (2) justify that the tool was not able to conclude; or (3) justify that the tool made an overapproximation. For instance, a large number of invalid dereference and out-of-bounds index assertions are located in modules that manage communication between the protection system and the user console. The protection system receives messages through a serial link. The message cannot exceed 1,024 bytes. The beginning of the message packet gives its actual size in bytes, and the two last bytes store the Cyclic Redundancy Check (CRC) for integrity checking.
Upon receipt of a message, the system checks its integrity by computing the CRC and comparing the result with that of the message. After this checking, the software uses the message header to directly access arrays, without checking if the value being read exceeds 1,024 bytes. As we modeled the receiving buffer as a volatile variable, the header was overapproximated. We did not analyze each of the alarms emitted by Astr ee, because the objective was only to position this tool relative to the other tools.
Conclusion and perspectives During the analysis of the case study software, we highlighted five bugs and one robustness recommendation to the supplier. As the software was under development, the supplier confirmed the bugs. These were found independently by the supplier in testing phases. This experimentation with the Frama-C tool allowed us to justify all the remaining assertions. Up to now, with the Poly-Space tool, we could achieve this goal only in the application software. The number of orange diagnostics in the system software was too high to justify each of them. We are now able to provide formal evidence that this software, including application and system parts, is free from intrinsic run-time faults. Based on this experimentation, EDF has chosen to use the Frama-C tool to analyze the software of a refurbished protection system for the 1300 MWe NPP in France.
The Current Use of ICT in Clinical Trials Information and Communication Technologies is now widely employed in several stages of clinical trials. For instance, pharmaceutical companies and Contract Research Organizations routinely adopt E-trainings for investigators. Patients' recruitment can take advantage of the wide employ of Electronic Health Records storing health-related data  (Hsiao and Hing, 2014) , and E-recruitment methods employing social media and the Internet are also starting to emerge. Similarly, data entry is now facilitated by electronic Case Report Forms, employed in almost the totality of the clinical trials leaded by pharmaceutical companies  (Kuchinke et al. , 2010). However, ICT is still not consistently used in clinical trials at the assessment stage. ClinicalTrials.
gov -a registry and results database of publicly and privately supported clinical studies of human participants conducted around the world -contains at present (January 2015) more than 2500 clinical trials involving participants with mild cognitive impairment (MCI), AD, or other dementia types. We performed a keyword-based 2  search on these trials focusing on automated audio and video analysis techniques, actigraphy, and computerized testing. Only 16 pharmaceutical trials employing ICT for assessment purposes were retrieved: 6 employing accelerometers and 10 employing computerized testing. No study employing automated audio or video analysis techniques was found. While it is certainly possible that these numbers represent an underestimate, they suggest that more work should be done to bring the clinical domain closer to the frontiers of the clinical research.
7 As explained in the methodology section, the climate outcomes of the scenarios were calculated with the climate model MAGICC6. MAGGIC6 shows a slightly higher emissions-to-concentration response than the climate module of the original AMPERE models. Concentrations from MAGICC6 as reported in target than the optimal scenarios (Table  2 ). This corresponds to an increase in the probability of exceeding 2 °C from about 42% in the optimal scenarios to about 47% in the HST cases, which is consistent with the small but noticeable higher median warming noted further above. Perhaps most importantly, the risks to exceed the 2 °C target are by far the highest (about 84%, see Table  2 ) in scenarios of our ensemble that are characterized by a large overshoot and where emissions continue to increase even above the HST level (GCAM 450 ppm CO 2 e).
LIMITS has been conducted in parallel to AMPERE, and puts its main focus on the implications of fragmented policies to 2020. The study finds that 2020 targets have, in contrast to 2030, only limited implications for the mitigation costs (even during the medium-term transition phase). This finding is important, since it illustrates the critical role of climate 10 The peak (or maximum) costs in our study are defined as the maximum decadal mitigation costs (as % of the baseline GDP) for the timeframe 2030-2100. Fig. 5  shows the ratio between the peak costs of the LST/HST and OPT scenarios. Costs presented here differ thus from the transitional growth reduction metric (defined as the maximum reduction of decadal consumption growth) that has been used by other studies  [16]. 11 Transient costs as well as other scenario data of the AMPERE scenarios can be downloaded from the interactive AMPERE web-database at: https:// secure.
Analysis of Quasi-elastic Neutron Scattering (QENS) data of complex systems such as biological or soft matter samples in a comprehensive and explicit way often requires great efforts. Most popular software only allows to fit spectra originating from one single instrument and does not permit to extract parameters from a model that is fitted simultaneously to data taken at different instrumental resolutions. We present here a new program, mQfit (multiple QENS dataset fitting), that enables to fit QENS data taken at different spectrometers (with typical resolutions between 0. 01 and 0. 1 meV) and momentum transfer ranges. This allows drastically reducing the number of fitting parameters. The routine is implemented with a user friendly Graphical User's Interface (GUI), and freely available. As an example, we will present results obtained on E.
Program presentation Quasi-elastic scattering is described by the dynamical structure factor S(Q,ω) which can be expressed by: S(Q, ω) = A 0 (Q)δ(ω) + A i (Q)L( i , ω). ( Q stands for the momentum transfer and ω designates the energy transfer from the neutron to the sample in units of. The first term in Eq. (  1 ) describes particles that appear immobile in the time window of the instrument, while the second term is a sum of Lorentzian functions, each one representing a specific motion. The widths i and the amplitudes A i (Q) of the Lorentzians are functions of other parameters depending on the model used. The program calculates the structure factor, convolutes it with the instrumental resolution and performs a least square minimization in order to find the optimal parameters. The program is written in the language Python, which makes it portable on most of the operating systems.
Conclusion We present here a new program that can be used to analyze comprehensively QENS data taken at different instrumental energy resolutions. Its GUI makes it user friendly, while being highly flexible and transparent. The results obtained on E. coli bacterial pellets show that using data sets originating from different spectrometers to analyze the same sample presents great advantages, especially in such samples with complex dynamics spanning timescales of several orders of magnitude. More models will be added soon to the program. The source code and a short user's manual can be found on the webpage http://forge. epn-campus. fr/.
MASSIF-1 (ID30A-1) is an ESRF undulator beamline operating at a fixed wavelength of 0. 969 A ˚(12. 8 keV) that is dedicated to the completely automatic characterization of and data collection from crystals of biological macromolecules. The first of the ESRF Upgrade MASSIF beamlines to be commissioned, it has been open since September 2014, providing a unique automated data collection service to academic and industrial users. Here, the beamline characteristics and details of the new service are outlined.
Introduction MASSIF-1 is a new beamline dedicated to the fully automatic characterization of and data collection from crystals of biological macromolecules. The first beamline of the ESRF Upgrade UPBL10/MASSIF project  (Theveneau et al. , 2013)  to be commissioned, it replaces ID14-1 and is based on a similar, but greatly improved, optical setup. The highly successful ID14 complex of beamlines allowed the construction of four beamlines on a single insertion device  (Wakatsuki et al. , 1998). The 'Quadrigia' concept used synthetic diamonds (asymmetric Laue  [100] ) to produce three fixed-wavelength beamlines (ID14-1, ID14-2 and ID14-3) and a tunable high-flux MAD beamline (ID14-4;  McCarthy et al. , 2009). While highly productive, the configuration had disadvantages in that absorption from the diamonds reduced the flux available on ID14-4 at longer wavelengths and changing energy on ID14-4 affected the flux available on the other beamlines.
, 2006) , ID29 (de  Sanctis et al. , 2012) ] or microfocus (ID23-2;  Flot et al. , 2010)  ESRF MX endstations. This way of using the ESRF's MX facilities stimulated the design of a new suite of beamlines that would have the density of ID14 but with greater independence coupled to second-generation automation. The ESRF Upgrade Program Beamline UPBL10 was proposed to address the problem of crystal evaluation with the Massively Automated Sample Selection Integrated Facility (MASSIF), the replacement for ID14 located at ID30. The core of the facility is composed of three beamlines, two (MASSIF-1 and MASSIF-2) using diamond beam splitters, as on ID14, and a third microfocus beamline (MASSIF-3) using a Si  [111]  singlebounce monochromator, with the central philosophy of maximum automation  (Theveneau et al.
, 2013). In addition, a fully tunable MAD beamline to replace ID14-4, ID30B, is currently being commissioned. As ID30 has canted undulators, the MASSIF branch is independent of the tunable branch which thereby removes the disadvantages of the previous design. MASSIF-1 is the first of these beamlines to be commissioned and has been dedicated to the fully automatic evaluation and data collection from crystals of biological macromolecules. The new service is not designed to replace user visits to the synchrotron, but rather to do the hard work of screening crystals or collecting data sets through the night, freeing researchers to spend time on more challenging data collection problems and study the underlying biology.
Beamline control MASSIF-1 is the first beamline at the ESRF to use a new sequencer based on Python in place of SPEC. This opensource software project, code-named 'Khoros' (https:// github. com/mguijarr/khoros), uses the latest libraries developed within the ESRF Beamline Control Unit and is the forerunner of a new control software package that will eventually be deployed on all ESRF beamlines. The main parts of the new system are: Beacon (https://github. com/mguijarr/ beacon), a beamline configuration library; Emotion (https:// github. com/esrf-emotion/emotion), the ESRF library for motor controllers; a set of beamline components, representing real devices that can be directly manipulated from Python code; core functions to perform scanning and data acquisition and a command-line interface that is either terminal-based or via a web application shell.
The Khoros project is organized as a Python package, with well defined modules, allowing it to be used as a Python extension library and be embedded into any Python application. On MASSIF-1, Khoros is embedded within the MXCuBE graphical application  (Gabadinho et al. , 2010). Data collection routines previously written as SPEC macros are now written as Python functions. As Python is a widely used language for scientific applications, this provides access to thousands of Python modules, powerful data types (e. g. list, dict, set) and easy sharing of sequences between facilities, as is the case with the MXCuBE collaboration. Khoros relies on the latest Python extension modules from industry, notably Gevent (http://www. gevent. org) for asynchronous network communication and co-routine support.
Object recognition cameras are used at major points of the trajectories, such as the exit of the Dewar or at the beam position, for vial recognition. The information provided allows trouble-shooting and automatic recovery procedures to run. The most commonly encountered errors arise when the assistant cannot remove a vial or a vial is poorly placed on the cap for replacement in the Dewar. Error handling means that for the first case the sample is returned safely to the Dewar and the system can move to the next sample. In the latter case, the cap and vial are placed in a bin to prevent a crash in the Dewar. Occasionally, a cap is removed without a vial; in these cases the cap is placed in the bin immediately and the next sample loaded. These errors account for less than 2% of the samples processed so far and, as only one case results in a lost sample without data collection, the error rate can be regarded as lower.
Most time is spent on the mesh scan and data collection with average times of just over 100 s each  (Svensson et al. , 2015). Users upload essential information via ISPyB such as the protein being studied (required by the ESRF Safety Group), a unique sample name and other information to tailor the experiment to the sample. The workflows then use this information and users view a summary of all the results of sample processing (mesh scans, processed data etc. ) in a summary view in ISPyB (Fig. 6 ). Once data sets have been collected they are automatically processed using routines  (Monaco et al. , 2013)  based on XDS  (Kabsch, 2010)  allowing users to quickly see the essential characteristics of a particular data set. Data sets are also analysed for the presence of anomalous scattering and, if present, a structure solution pipeline is launched  (Monaco et al.