dataesr/scientific-paragraphs-categorization huggingface dataset:
Requirements Python-Microscope has simple computational requirements. It requires Python 3. 6 or later, and the Python packages NumPy  (Harris et al. , 2020) , Pillow (https://buildmedia. readthedocs. org/ media/pdf/pillow/latest/pillow. pdf ), Pyro4, hidapi (https://pypi. org/ project/hidapi/), and pySerial (https://pythonhosted. org/pyserial/). These are all free software and widely available for all operating systems, ensuring that Python-Microscope is truly cross platform. We have run Python-Microscope on different versions of Microsoft Windows, different GNU/Linux distributions and macOS, on a multitude of computers from high-end workstation computers and rack servers, to touchscreen notebooks and single-board Raspberry Pi computers. Despite the simple requirements of Python-Microscope itself, individual devices often have their own more demanding requirements.
Some devices require specific hardware connectors such as PCIe slots of a specific mode or size, which can limit the motherboard or computer chassis usedfor example, laptops and all-in-one computers very rarely contain any PCIe slots, which are required for high-speed and high-resolution cameras. Other devices may require a serial port or USB of a specific version. Similarly, use of devices at high speed will add further system requirementsfor example, acquiring many images at a fast rate will require faster data transfer and more computer memory. Finally, some of the device software development kits (SDKs) that Python-Microscope wraps are only available for one operating system, usually specific versions of Microsoft Windows. Note though that by using a network connection to the device-server, a controlling client program can be on another computer with a different operating system from the device-server.
Workflow Python-Microscope provides an application programming interface (API) to microscope devices of different types. Their documentation is included as part of the class docstrings. Although any program can easily instantiate the class of their specific hardware, our recommendation is to use the device-server program to create the devices and have programs control the devices via Pyro4 proxies. This removes the need for device specific code on the program, replacing it with configuration files that only need the device type and Pyro4 universal resource identifier (URI), both of which are strings that can be encoded on a plain text file. In the specific case of camera devices, the program needs to register the data client with a Pyro4 daemon and pass its URI to the camera device instance.
DISCUSSION Python-Microscope is a library to enable builders of custom microscope systems to fully exploit the power of the increasingly popular Python programming language. It interfaces with a growing range of hardware classes, including cameras, filter wheels, light sources, deformable mirrors and stages with defined APIs, while still allowing access to device-specific features. Python-Microscope provides simple access to complex devices for Python programs and a defined protocol for accessing devices either locally or over network connections via the device server. The device server deals transparently with hardware restarts through reinitialisation and other issues, providing a reliable and robust interface to hardware in complex systems and environments. Python is a free, modern, open-source, portable programming language.
It has wide support and a large developer community, is relatively easy to learn and has a wide ecosystem for scientific computing. However, Python is not without its drawbacks. In the context of hardware control, namely the coordination of multiple hardware devices, the most commonly mentioned issue is Python's performance and lack of 'true' multithreading due to a GIL. As mentioned in the Introduction, μManager has recently introduced a Python interface, Pycro-Manager  (Pinkard et al. , 2021). This simplifies connections between μManager-based hardware interfaces and Python-based analysis and control. Although this reduces the effort in using Python for control and online analysis compared to other approaches, it does not provide direct access to the hardware via Python and keeps the existing μManager infrastructure; as such, knowledge of both C++ and Java is still required for development and debugging.
Python has a reputation for being slow when compared to C, C++ or even Java, apparently making it an odd choice for microscope control where multiple physical devices have to be controlled at high speed in an orchestrated manner. However, multithreaded operating systems simply do not have reliable enough timing for the triggering of critical components, whichever programming language is used. For these applications, we recommend the use of hardware trigger modes that many devices have (or that are available as options). This approach was one of the main design considerations for Python-Microscope, as it makes Python's performance mostly irrelevant to the overall performance of the microscope system. Moreover, we recommend the use of Python-Microscope in a client-server model to access the different devices, each of them with a dedicated Python process, thus side stepping the GIL.
Even if hardware triggers and a client-server model are not used, our experience is that Python's reputation as being slow is unjust. At least in the case of scientific computing, the core processing steps in Python are often implemented in C or Fortran. In Python-Microscope, most of the hardware controllers are simply wrappers to vendor-provided libraries that are written in C. In addition, calls to functions in those C libraries are done with Python's ctypes library, which also releases the GIL. Python has become the de facto standard in the field of data science. CellProfiler  (McQuin et al. , 2018) , ilastik  (Berg et al. , 2019) , NumPy  (Harris et al. , 2020) , PyTorch  (Paszke et al. , 2019) , SciPy (http://www. scipy. org), and TensorFlow (https://www. tensorflow. org/) are well known examples of Python programs and libraries.
Novel advances in the field of machine learning are increasingly happening first in the Python programming language. By using the Python language, Python-Microscope can harness all of these and bring new developments into the field of microscope control more quickly and easily, accelerating the advancement of the field to what we see as the next logic step  (Waithe et al. , 2020). A further advantage of the approach provided by Python-Microscope is in increasing reproducibility in science. Scientists frequently write in their publications that LabVIEW or a specific commercial microscope acquisition software was used without any specific acquisition settings, code or macros to assist with reproduction. This is especially critical in complex experimental setups where specifics of acquisition are particularly important.
Python-Microscope has the potential to change this trend, allowing authors to freely publish simple code demonstrating exactly how their control and acquisition code operates. Additionally, the defined device interfaces allow such code to be ported to other specific hardware with minimal changes. Python-Microscope is a free and open-source project, currently being used in several labs, with an open development approach. Our aim is that the microscope development community will find Python-Microscope a useful tool and engage in this development to increase its general usefulness. With that aim in mind, we perform our development conversations and user support in the open, as GitHub issues (https://github. com/python-microscope/microscope/ issues), and the project is an image. sc community partner (https:// forum.
image. sc/). In particular, expanding the number of devices supported by Python-Microscope would be extremely beneficial. However, adding support for a device requires physical access to the device, and the current list of supported devices echoes the devices we and our collaborators have access to. This is a chicken and egg problem. Python-Microscope needs broad device support to be widely adopted by the community, but it needs contributions from the community to support those devices. We believe that Python-Microscope currently provides enough devices and infrastructure to support adoption by more developers. There are contribution guidelines within the 'Get Involved' section of the documentation, available online at https://www. python-microscope. org/doc/get-involved. In an effort to minimise duplication and increase community cooperation, we are keen to foster links and collaborations with other Python-based or Python-compatible microscope control packages, such as PYME and μManager.
We will endeavour to make bindings, when possible, that will enable interoperability of Python-Microscope with other open community-based Python software controlling microscope hardware. We have developed Python-Microscope to sit at the foundation of a microscope control software stack. The foundation is formed by abstracting the differences between individual devices, which dramatically reduces the differences in software between microscopes. By using Python, which has a large user base in the scientific community, we are able exploit the existing expertise in the field and leverage a vast range of scientific libraries for image analysis. The design and features simplify the reuse and sharing of software components between custom microscopes. We expect that Python-Microscope will ultimately accelerate and expand microscopy developments.
Acknowledgements We would like to thank members of  Micron Oxford  for helpful comments and suggestions during the development of Python-Microscope. We also thank  Dominic Waithe  from the  University of Oxford , and  Thomas Huser  and his group from the  University of Bielefeld  for their help during testing and development of more devices. We are also thankful to  David Baddeley , from the  University of Auckland , for hints from his PYME package, suggestions and discussion around hardware control from Python.
Funding This research was supported by the  Wellcome Trust  ( 091911/Z/10/Z ,  091911/Z/10 / A,  105605/Z/14/Z ,  107457/Z/15/Z  and  203141/Z/16/Z );  Medical Research Council (MRC) ,  Engineering and Physical Sciences Research Council (EPSRC)  and  Biotechnology and Biological Sciences Research Council (BBSRC) Nextgeneration Optical Microscopy  ( MR/K01577X/1 );  EPSRC/MRC  ( EP/L016052/1 ); a  BBSRC  iCASE grant with Aurox as the industrial partner ( BB/M011224/1 );  Infrastructures en Biologie Santéet Agronomie (GIS IBiSA ; # 2015-28 ); and by the  Centre National de la Recherche Scientifique MITI (Defi Imag 'In 2015). Open access funding provided by the  University of Oxford. Deposited in PMC for immediate release.
Earth system models (ESMs) participating in the Coupled Model Intercomparison Project Phase 5 (CMIP5) showed large uncertainties in simulating atmospheric CO 2 concentrations. We utilize the Earth System Model Evaluation Tool (ESMValTool) to evaluate emission-driven CMIP5 and CMIP6 simulations with satellite data of column-average CO 2 mole fractions (XCO 2 ). XCO 2 time series show a large spread among the model ensembles both in CMIP5 and CMIP6. Compared to the satellite observations, the models have a bias of +25 to -20 ppmv in CMIP5 and +20 to -15 ppmv in CMIP6, with the multi-model mean biases at +10 and +2 ppmv, respectively. The derived mean atmospheric XCO 2 growth rate (GR) of 2. 0 ppmv yr -1 is overestimated by 0. 4 ppmv yr -1 in CMIP5 and 0. 3 ppmv yr -1 in CMIP6 for the multi-model mean, with a good reproduction of the interannual variability.
strong negative trend of decreasing effective SCA with increasing XCO 2 in the northern midlatitudes, both CMIP ensembles instead show a non-significant positive trend in the multi-model mean. The negative trend is reproduced by the models when sampling them as the observations, attributing it to sampling characteristics. Applying a mask of the mean data coverage of each satellite to the models, the effective SCA is higher for the SCIAMACHY/Envisat mask than when using the TANSO-FTS/GOSAT mask. This induces an artificial negative trend when using observational sampling over the full period, as SCIAMACHY/Envisat covers the early period until 2012, with TANSO-FTS/GOSAT measurements starting in 2009. Overall, the CMIP6 ensemble shows better agreement with the satellite data than the CMIP5 ensemble in all considered quantities (XCO 2 , GR, SCA and trend in SCA).
, 2014; Hoffman et al. , 2014). The largest uncertainties are associated with the response of the land carbon cycle to changes in climate and atmospheric CO 2  (Friedlingstein et al. , 2014; Hajima et al. , 2014). The ability of ESMs to simulate the land and ocean contemporary carbon cycle has previously been investigated by  Anav et al. (2013). They showed that most models were able to correctly reproduce the main climatic variables and their seasonal evolution but found weaknesses in reproducing specific biogeochemical fields, such as a general overestimation of leaf area index and photosynthesis. However, the magnitude of the global photosynthesis is not well constrained by observations, with estimates ranging between 112 and 169 PgC yr -1  (Ryu et al. , 2019) , and the dataset used by  Anav et al.
(2013)  is on the lower end of this range. For CMIP6,  Arora et al. (2020)  analyzed simulations with a CO 2 increase of 1 % per year to quantify the carbon-climate feedbacks. They found no significant change in behavior from CMIP5 to CMIP6 but lower absolute values for models which included a nitrogen cycle. In this paper, we focus on evaluating the growth rate and the seasonal cycle amplitude of simulated CO 2 , converted to XCO 2 , from CMIP ESMs which performed emissiondriven simulations with satellite observations in CMIP5 and CMIP6. The paper is structured as follows: the data prod-ucts used in this study are introduced in Sect. 2. Section 3 describes the methods used, including the calculation of all derived quantities. A comparison between CO 2 flask measurements and XCO 2 measurements at different locations is given in Sect.
4. The evaluation of CMIP simulations with satellite data is presented in Sect. 5, divided into sections focusing on the models' ability to simulate XCO 2 time series, growth rate and seasonal cycle amplitude. A summary and conclusion are given in Sect. 6. 2 Data 2. 1 Observational datasets 2. 1. 1 Satellite XCO 2 We use the Observations for Model Intercomparisons Project (Obs4MIPs) version 3 (O4Mv3) XCO 2 satellite data  (Buchwitz et al. , 2017a (Buchwitz et al. , , 2018)). Obs4MIPs hosts observationally based datasets which have been formatted according to the CMIP model output requirements (e. g. , variable definitions, coordinates, frequencies) in order to facilitate an easier comparison between observations and models  (Ferraro et al. , 2015; Teixeira et al. , 2014; Waliser et al. , 2020).
The satellite product used here is a gridded (level-3) monthly data product with a 5 • ×5 • spatial resolution following the Obs4MIPs format, produced as part of the Copernicus Climate Change Service (C3S). The O4Mv3 product is retrieved from two satellite instruments: Scanning Imaging Absorption Spectrometer for Atmospheric Chartography/Envisat  (Bovensmann et al. , 1999; Burrows et al. , 1995)  and the Thermal And Near infrared Sensor for carbon Observation Fourier transform spectrometer/Greenhouse Gases Observing Satellite (TANSO-FTS/GOSAT)  (Kuze et al. , 2009). This monthly mean XCO 2 satellite dataset covers a 14year time span  (2003) (2004) (2005) (2006) (2007) (2008) (2009) (2010) (2011) (2012) (2013) (2014) (2015) (2016). It is obtained by gridding the level-2 product (individual soundings) generated with the ensemble median algorithm (EMMA;  Reuter et al.
While the dataset ends in 2016, our evaluation only goes up to the year 2014 because the historical simulations for CMIP6 end in 2014 and scenarios from the emission-driven simulations that could be used to extend the runs are not yet available for all considered models. The number of observations depends significantly on the location with most points over locations with low cloud cover, high surface reflectivity and (at least) moderate to high Sun elevation. Coverage over ocean is sparse as ocean retrievals are only included from GOSAT Sun-glint mode observations -outside of glint conditions, the reflectivity of water is very low in the NIR/SWIR spectral region. Figure  1  shows the mean monthly coverage of the dataset for 2003-2014. In Sect. 5, we will show that taking into account this sampling in the evaluation of ESMs is essential for a proper comparison.
Model simulations We use monthly mean output data from 10 CMIP5 and 10 CMIP6 models which performed emission-driven simulations, with three of the CMIP5 and five of the CMIP6 models including a nitrogen cycle. Tables  2  and 3  list all the CMIP5 and CMIP6 models used in this paper along with their atmosphere, land and ocean model component, respectively. Only models with an interactive carbon cycle are able to perform the emission-driven simulations, in which the emissions rather than the concentrations of the greenhouse gases are prescribed  (Taylor et al. , 2012; Eyring et al. , 2016a). This allows the carbon cycle in the models to react to changes in climate and atmospheric CO 2 by adjusting their carbon fluxes to the new climate conditions and providing the atmospheric CO 2 concentration as an output  (Friedlingstein et al.
Sampling of observations and models For comparison of model and satellite data, first the CO 2 data of the models were converted to XCO 2 data. The model data were interpolated to the grid of the satellite dataset using a bilinear interpolation scheme and grid cells with missing values in the satellite data were also set to missing values in the model fields. Further sampling considerations are discussed in more detail in Sect. 5. 3. 2 and in Appendix B. Most analysis is carried out with regional averages covering several grid cells. Unless specifically stated otherwise, these are calculated by taking the arithmetic averages over all grid cells weighted by their area for each month.
Calculation of growth rate, seasonal cycle amplitude and growing season temperature anomaly We compute the GR following the method described in  Buchwitz et al. (2018). Monthly resolved annual growth rates are calculated by subtracting the XCO 2 value 6 months in the future from the one 6 months in the past. Then these monthly resolved growth rates are averaged to a yearly GR for a calendar year, and any year with less than 7 months of data is flagged as missing. The addition of the 7-month data availability was introduced to be consistent with the constraint on SCA as explained below. We define the SCA as the peak-to-trough amplitude in a calendar year of the detrended time series. The time series is detrended with the cumulative sum of monthly growth rates, using the annual mean growth rates as substitution for missing values where necessary.
The SCA is calculated by subtracting the minimum from the maximum value for each year with a minimum data availability of 7 months. When investigating the seasonal cycle of observationally sampled simulations at higher latitudes, the maximum value of the time series was generally only accounted for if more than 7 months of data were available. We therefore introduce the cutoff of 7-month data availability to preserve as many peaks as possible without restricting the data too much. However, as peak preservation cannot be guaranteed when any missing values are present, we can only speak of an effective SCA. The absolute SCA is not as important in our comparison, because we use the same sampling for both the model and observations. The growing season temperature anomaly T is calculated from the NASA Goddard Institute for Space Studies (GISS) Surface Temperature Analysis (GISTEMP) version 4  (Hansen et al.
Earth System Model Evaluation Tool (ESMValTool) All figures in this paper were produced with the Earth System Model Evaluation Tool (ESMValTool) version 2. 0 (v2. 0)  (Righi et al. , 2020; Eyring et al. , 2020; Lauer et al. , 2020). Since its first release in 2016  (Eyring et al. , 2016b) , the ESMValTool has been further advanced, facilitating analysis of many different ESM components, providing welldocumented source code and scientific background of implemented diagnostics and metrics, and allowing for traceability and reproducibility of results (provenance). ESMVal-Tool v2. 0 has been developed as a large community effort to specifically target the increased data volume of CMIP6 and the related challenges posed by analysis and evaluation of output from multiple high-resolution and complex ESMs.
For this, the core functionalities have been completely rewritten in order to take advantage of state-of-the-art computational libraries and methods to allow for efficient and userfriendly data processing  (Righi et al. , 2020). Common operations on the input data such as regridding or computation of multi-model statistics are now centralized in a highly optimized preprocessor written in Python. ESMValTool v2. 0 includes an extended set of large-scale diagnostics for quasioperational and comprehensive evaluation of ESMs  (Eyring et al. , 2020) , new diagnostics for extreme events, regional model and impact evaluation and analysis of ESMs  (Weigel et al. , 2020) , as well as diagnostics for emergent constraints and analysis of future projections from ESMs  (Lauer et al. , 2020). For the study here, a new ESMValTool recipe has been developed that can be used to reproduce all plots of this paper.
The multi-model mean and satellite data are averaged between all grid cells covering a 5 • × 5 • radius around the stations, which results in a maximum of four grid cells to be considered. The mean and growth rate of XCO 2 and surface CO 2 are in very good agreement, while the multimodel mean overestimates both variables at all sites, with the overestimated mean XCO 2 arising from the effect of higher growth rates over time. Furthermore, the offset from the modeled surface CO 2 is higher than that of XCO 2 , while this difference is smaller for CMIP5. This might be due to the fact that the CMIP5 offset for multi-model mean XCO 2 was larger overall with approximately 10 ppmv compared to the CMIP6 offset of approximately 2 ppmv. SCA is higher at higher latitudes and also generally higher at the surface compared to the column average.
This is to be expected as the processes dominating the seasonal cycle, respiration and photosynthesis, take place at the surface, leading to the higher SCA for station data and surface CO 2 from models compared to the XCO 2 values. Mixing of air coming from lower latitudes with lower SCA dampens the SCA in the column compared to surface SCA. This is evident in the increasing SCA difference between XCO 2 and surface CO 2 going from low-latitude to high-latitude stations, with no discernible seasonal cycle in the Southern Hemisphere due to the lack of land and vegetation. The multi-model mean follows this trend in the observations, although it underestimates the higher-latitude SCA, with a larger underestimation at the surface while capturing the XCO 2 SCA relatively well. As this study aims at evaluating model simulations with satellite data, further analysis is restricted to XCO 2.