dataesr/scientific-paragraphs-categorization huggingface dataset:
Computational details The computations were carried out relying on density functional theory with the Vienna ab initio simulation package (VASP)  [55]. We adopted the PBE-dDsC  [56, 57]  density functional, which belongs to the family of the Generalized Gradient Approximation and is supplemented with a densitydependent dispersion correction. [58]  The projector augmented wave method  [59]  is used to treat the ion-electron interaction. The electronic density was calculated with a 500 eV cutoff energy. Due to the size of the super cells, Γ point sampling of the Brillouin zone was found to be sufficient. The precision setting of VASP is set to "accurate". The convergence criterion for the self-consistency process is set to 10 -5 eV for the optimization of the wave function. The maximum forces are converged to 0.
Acknowledgements This work was financially supported by  Région Auvergne Rhône-Alpes  through the project  Pack Ambition Recherche 2018 MoSHi. We are very grateful to  IFP Energies nouvelles  for supporting the  MoSHy  project ( N o 1801167601 ) and to the  IFP Energies nouvelles  team,  Mona Marie Obadia  and  Quentin Cacciuttolo , for fruitful discussions. The authors thank the  SYSPROD  project and  AXELERA Pôle de Compétitivité  for financial support ( PSMN Data Center ).
In a previous publication, we presented CRAPPY, a Python module designed for researchers wishing to easily develop code for driving complex experimental setups. In a complemented version, now targeting a broader audience, we extended the framework to include low-cost sensors, actuators, and cameras. Using such devices, it is now possible to set up tests with CRAPPY in a more cost-effective and flexible way. This can be achieved from embedded computers like the Raspberry Pi, on which the module is now fully functional. Alternatively, we introduce a solution for driving embedded sensors and actuators directly from a regular PC. Other enhancements for the integration of microcontrollers and remote equipment are also described. Based on examples of existing tests driven using CRAPPY, we demonstrate in this paper the feasibility of including low-cost equipment in experimental setups to obtain relevant results.
As most of the complexity is not exposed to the user, it allows writing advanced test scripts in usually less than 100 lines. The block-wise organization of the software makes it easy to handle even for beginners in Python. CRAPPY comes with a wide collection of readily-available tools and hardware, that can be simply extended with basic Python knowledge to meet users' particular needs. Although it was originally designed for experimental mechanics, its versatility makes it suitable for driving tests in almost any field as long as the hardware is properly added to the framework. For an extensive description of CRAPPY's functionalities and interface please refer to our first article and the documentation. CRAPPY was initially written and used for interfacing with laboratory equipment like acquisition boards and cameras, or industrial hardware like tensile test machines.
To our knowledge, very few software solutions exist for integrating low-cost sensors and actuators into experimental setups as CRAPPY does. First, some software solutions focus on managing entire tests. National Instrument's LabView  [6]  or FlowStone  [7]  offer the possibility to interface with embedded systems, but are closed-source, not free, and have their own graphical programming language. MyOpenLab  [8]  presents the advantage of being free and open-source, but also relies on a graphical programming language. Qudi  [9]  and Itom  [10]  are written in Python and can run on Raspberry Pi, even though they are not explicitly intended for interfacing with embedded hardware. However, they leave the parallelization and synchronization of processes up to the user, when CRAPPY handles it automatically.
Then, other software programs focus on driving low-cost hardware or microcontrollers but do not integrate any test-management aspect. The general-purpose interfaces Electric UI  [11]  and Flow-Code [12] can drive sensors, actuators and microcontrollers, but Electric UI can only handle C++ code and FlowCode uses a graphical programming language. Adafruit's Blinka [13] enables driving most of Adafruit's hardware from Python in a simple way, while SparkFun [14] and MikroE  [15]  provide respectively Arduino and C code for part of their equipment. In all three cases, the provided code only allows driving components individually, and test-management is left up to the user. Only Phidgets' API  [16]  provides an extensive solution in Python, with a wide collection of pre-integrated hardware and built-in management of multiprocessing.
Its scope is however limited to Phidgets modules, whereas CRAPPY can be used for driving hardware from a variety of suppliers. To our knowledge, CRAPPY is currently the only free and open-source software for both interfacing with embedded devices regardless of their manufacturer and managing entire tests. In the present article, we will demonstrate the feasibility of acquiring reliable and relevant data with CRAPPY using equipment from the embedded-electronics field. We do believe that the recent additions to CRAPPY will provide a robust and helpful framework for researchers wishing to work with those low-cost and versatile devices.
Short presentation of CRAPPY In this section, the additions that were brought to CRAPPY will be detailed along with the needs they meet. A summary of the main additions can be found in Fig. 1. Please refer to our first article for the detail of CRAPPY's nomenclature, internal functioning, and basic use cases. Shortly, CRAPPY is a Python module designed for driving complex experimental setups in an accessible way. It is free, opensource, and runs on Windows, MacOS and Linux. It provides a number of Python objects, which the user instantiates and links together in a block-wise arrangement. Although this design is ideal for integration into a graphical interface, we chose not to provide one. This way, users can make full use of Python's versatility and are not limited by the implementation of the interface.
The Python programming language was chosen for CRAPPY because it is popular in the scientific community, accessible to programming beginners, and highly flexible. A typical Python script using CRAPPY consists in several Block objects, linked together by Link objects that allow data to be exchanged. Each Block has a specific function, like acquiring data, plotting curves, driving a motor, etc. Blocks may rely on Camera, Actuator, Tool, or InOut objects to achieve their task. However, unlike these helper objects that are simple Python classes, each Block is a Python multiprocessing. Process. CRAPPY manages the initialization, synchronization, and termination of all the Blocks, the user only has to instantiate the Blocks with their arguments and link them as desired. The use of processes ensures that the needed computing power is distributed on all the CPU cores, but also requires a complex module architecture and additional efforts to ensure cross-platform compatibility.
CRAPPY's strength resides in the automatic parallelization and synchronization of the Block objects, which proves difficult to achieve properly without an advanced level in Python. It also resides in the simplicity with which new hardware can be added to the framework to fit users' needs. As a consequence of our design choices, however, it has notable limitations. First, it requires a basic knowledge of Python for writing the test scripts. Then, depending on the availability of a dedicated Python library or a detailed datasheet, not all hardware can be integrated into CRAPPY's framework. Because it is written in pure Python, CRAPPY might also prove slower at performing certain tasks than equivalent solutions written in C++ for example. And finally, in the general case, CRAPPY cannot achieve a deterministic sampling at frequencies higher than a few dozen Hz.
They also include the RPi. GPIO  [19] , smbus2  [20] , and spidev  [21]  Python libraries used in CRAPPY, respectively for controlling GPIOs, I2C, and SPI. To further expand the possibilities of CRAPPY on RPi, a Camera object relying on the picamera  [22]  Python module was added for controlling the PiCamera 1, 2  [23] , and HQ  [24]  models. Using the latter we were able to capture images in HD quality at close to 50 Frames Per Second (FPS) in CRAPPY. Note that as a Python module, CRAPPY should be able to run on SBCs other than RPi, although that was not tested. The main drawback of using SBCs for driving tests is their lack of computing capacity for a majority of models, with the notable exception of Nvidia's Jetson series  [25]. While SBCs can perfectly handle simple tests, they show strong limitations when running tests featuring many blocks or involving image processing.
Internally, we had to overcome a limitation of the USB library, pyusb  [28] , that prohibits its use in multiple processes. Instead, a server managing all requests to pyusb was developed, and Blocks wishing to communicate using an FT232H simply send and receive requests to/from this server. As speed was also critical and USB commands cannot always be pickled, efforts were made to limit the communications between the USB server and its clients to a simple binary communication through temporary files. The use of files was chosen as we encountered bugs with the advanced tools provided by Python's multiprocessing  [29]  module. The overall architecture for communicating with the FT232H is summarized in Fig. 2. This architecture limits the computing power of the server to one CPU core only. Based on the features developed for interfacing over SPI and I2C, either from a RPi or a PC, many InOut and Actuator objects were added to the framework according to our needs.
Consequently, a variety of embedded sensors and actuators can now be accessed over SPI or I2C through CRAPPY, including a pressure sensor (MPRLS [30]), a DC motor driver (TB6612  [31] ), a load cell conditioner (NAU7802  [32] ), analog to digital converters (HX711, ADS1262  [33] ), a thermocouple amplifier (MCP9600  [34] ), etc. In CRAPPY's nomenclature, adding these devices to the framework was achieved by creating dedicated Actuator or InOut objects. For each object, an effort of integration was made so that it can be used either from a RPi or with an FT232H. Moreover, we ensured that Adafruit's hardware can be used calling only Blinka methods for communication, as Blinka ensures compatibility with a wide range of SBCs and microcontrollers. Switching between these three ways of interfacing with hardware still remains straightforward to the user, who simply has to set a different 'backend' argument in his Python test script.
The integration of embedded devices into CRAPPY was not much different from that of industrial ones in terms of code length, complexity, and required skills. It was most of the time even easier, as user-friendly libraries were often provided by manufacturers, like Adafruit's Blinka. In some rare cases, however, no code was available and the integration of components required a thorough reading of hundred-pages long datasheets. This constitutes a limitation to the implementation of embedded hardware in CRAPPY, of which users should be aware.
Fast decision-making using microcontrollers SBCs include various options for interfacing with hardware, and regular PCs display high computing capabilities, but both of them, however, present a strong limitation when fast decisionmaking is required. PCs and SBCs manage numerous processes running concurrently, including the processes started by the OS itself. These processes are constantly being stopped and resumed by a scheduler, so that they can all appear to run simultaneously. CRAPPY's processes are no exceptions, and can get frequently interrupted up to a few milliseconds as we measured on midrange laptops. These jitters prohibit the use of CRAPPY on PCs or SBCs for some applications where responsiveness is critical, like fast camera triggering, or precise signal generation. A possible workaround to this limitation is the use of modified OS versions specifically designed for achieving deterministic response times, like the Linux PREEMPT_RT patch  [35].
MCUs are therefore ideally suited for addressing the jitter limitation of CRAPPY. To take full advantage of the capabilities of MCUs, a UController Block was introduced along with a MicroPython [38] and an Arduino  [39]  template to upload to the MCU. MicroPython is a lightweight version of Python and Arduino is an extension of C++, they are both compatible with use on a wide range of MCUs. Used in combination with either template, the UController block allows communicating with a MCU by starting and stopping data acquisition, sending commands, and receiving data. Using this block, we were successfully able to delegate decision-making to a MCU driven from CRAPPY, with a response time predictable and much lower than a millisecond. Practically, the communication between the PC and the MCU occurs over the standard serial connection that most MCUs possess.
Remote communication over a network Some of the best-seller MCUs like the Raspberry Pi Pico W  [40]  or the Espressif ESP32  [41]  include a WiFi module, paving the way for remote data acquisition. While most setups can run using only wired connections, specific cases require wireless data transfer, e. g. tests in fully enclosed areas or data acquisition on rotating parts. To add these use cases to CRAPPY's possibilities, a Client_server block was developed. It uses the lightweight MQTT network protocol and works in combination with an MQTT broker, usually running on the main PC. The Client_server block allows subscribing to and publishing on MQTT topics, i. e. receiving and uploading data over the network. This new addition to CRAPPY, even though it is not a major one, further improves the software's versatility and flexibility for interfacing with low-cost equipment.
The laptop communicates with both the camera and the motor driver over USB. The load cell conditioner interfaces over I2C with a microcontroller (Adafruit Feather HUZ-ZAH ESP32  [41] ), that sends the force data over a local WiFi network using the MQTT protocol. The force data is then received on the laptop, connected to the same network. A schematic of the components and the wiring can be found in Fig. 4. Tests were run successively on both setups, using two image processing techniques for calculating the strain in real-time. These techniques are: (i) Digital Image Correlation (DIC), based on OpenCV DISOpticalFlow library  [45] , and very computationallyintensive (ii) Video-Extensometry (VE), relying on spot-tracking to estimate the strain, and much lighter on the CPU. Additionally, a configuration without image acquisition was tested, with strain estimated based on the measured position of the motor.
For each test, the motor position, force readout, and strain were recorded and saved to. csv files. A schematic representation of the CRAPPY blocks used for driving the test and of the Links between them can be found in Fig. 5. The full Python scripts for driving the tests are too long to be presented here, but an example is available in Appendix B (only the version acquiring strain via VE on the RPi). We would like to emphasize the fact that even on such complex setups, the Python code remains relatively short for the user to write. The scripts presented here display no additional complexity compared with codes driving industrial equipment, presented in our previous article.
We also demonstrated the possibility to acquire data from embedded sensors using a laptop-driven setup running CRAPPY. The Python scripts and the wiring remain simple, in line with what was already described in a previous article. After comparing the costs, data rate, and compliance with the requirements of both setups, it appears that the low-cost setup is sufficient for running simple tensile tests at low stretch speed. The higher performance obtained with the laptop-driven setup is not necessary for the described test, and the gain in data rate remains low compared with the rise in cost. Through this example, we illustrate the relevance of integrating low-cost embedded hardware on experimental setups where high performance is not required, and the possibility to use CRAPPY for driving such setups in a simple yet powerful way.
Use of the FT232H for data acquisition In addition to the two main setups previously described, another configuration driven from a laptop was also tried out. In this configuration, an FT232H is used for interfacing with the load cell conditioner over I2C, and also communicates with the computer over USB. A schematic of the wiring and the components can be found in Appendix D. Unfortunately, interferences between the Ximea camera and the FT232H on the USB signal prevented the simultaneous use of both devices. We were still able to run a test with only the position and force being recorded. Just like for the two previous setups, the raw data can be found at  [46] , the stress-strain curves in Appendix C, and the achieved frame rate in Table  2. The recorded values and the data rates are similar to those of the previously presented laptop-driven setup.
Instead, the use of a microcontroller is here a good alternative, since the required computing power for calculating the delay between trigs is low. Adjusting the delay depending on the mounted camera is however not straightforward on microcontrollers, because they execute compiled code that cannot be modified. A user input is thus necessary, which entails additional effort in the design of the setup. Using CRAPPY, driving a microcontroller meeting the aforementioned requirements proved extremely simple. Since speed is key here, CRAPPY's Arduino template for interfacing with MCUs was preferred, rather than the MicroPython template. On this template, only a few dozen lines had to be added for generating the trigs and calculating the delays. The template already contained the complex code managing the communication with CRAPPY.
The chosen MCU for the setup was the Arduino Mega  [48]. Using the developed code, the delay specific to each camera could be sent from the PC driving the test to the MCU. The looping frequency of the MCU (not precisely measured) also proved satisfying, as the MCU was fully able to fulfill its task. On the PC side, only one UController block had to be added to the Python script driving the test. This short example illustrates the simplicity with which microcontrollers can be added to setups driven with CRAPPY, to reliably perform fast decision-making.
Impact The new features recently added to CRAPPY add even more versatility to the module, and come in addition to the many features already presented in a previous article. These enhancements aim at making sensors and actuators from the embedded electronics field easily accessible to experimental researchers. Using such equipment, CRAPPY now allows setting up flexible and cost-effective tests with limited knowledge in electronics. For greater adaptability, we made it possible to interface embedded devices with CRAPPY either from a regular PC, an SBC, or a microcontroller. With the new features, we explicitly target an audience of researchers having experience in development and electronics, although beginners may also be able to manage simple setups. As illustrated in the previous section, CRAPPY's last release has proven helpful in many different ways for driving tests in experimental mechanics.
Conclusions The present paper introduced the latest release of the Python module CRAPPY. Following up on the work presented in a previous article, we extended the module's framework to allow interfacing with low-cost hardware. The most significant improvements are (i) the compatibility of CRAPPY with SBCs like the Raspberry Pi, (ii) the addition of various embedded sensors and actuators into the built-in library, (iii) the possibility to simply interface with MCUs like the ESP32 and to use them for deterministic sampling, (iv) the capacity to acquire data and to control actuators remotely over a network. The implementation of these features into the software and the choices that we made were described and explained. Presenting detailed examples of experimental setups, we then demonstrated the capacity of CRAPPY to drive complex test featuring both low-cost embedded equipment and standard industrial hardware.
Acknowledgments We would like to thank the interns who actively contributed to the implementation of embedded hardware into CRAPPY, namely  Emmanuel Berthe ,  André Auilo Martins ,  Antoine Hochard , and  Pierre Margotin. Also, we would like to acknowledge  Annie Morch  who prepared the silicone samples for the tensile tests. This work has been financially supported by the  AID (Agence Innovation Défense) , the  Région Hauts-de-France, France  and the  I-SITE ULNE.
The missing data mechanism is a relevant problem in Machine Learning (ML) and biomedical informatics communities. Real-world Electronic Health Record (EHR) datasets comprise several missing values, thus revealing a high level of spatiotemporal sparsity in the predictors' matrix. Several approaches in the stateof-the-art tried to deal with this problem by proposing different data imputation strategies that (i) are often unrelated to the ML model, (ii) are not conceived for EHR data where laboratory exams are not prescribed uniformly over time and percentage of missing values is high (iii) exploit only univariate and linear information on the observed features. Our paper proposes a data imputation strategy based on a clinical conditional Generative Adversarial Network (ccGAN) capable of imputing missing values by exploiting non-linear and multivariate information across patients.
Unlike other GAN data imputation-based approaches, our method deals explicitly with the high level of missingness of routine EHR data by conditioning the imputing strategy to the observable values and those fully-annotated. We demonstrated the statistical significance of the ccGAN to other state-of-the-art approaches in terms of imputation (around 19. 79% of gain to the best competitor) and predictive performance (up to 1. 60% of gain to the best competitor) on a real multi-diabetic centers dataset. We also demonstrated its robustness across different missingness rates (up to 1. 61% of gain to the best competitor in the highest missingness rates condition) on an additional benchmark EHR dataset.
An adequate and effective missing data imputation stage is crucial in This study seeks to offer a data imputation technique based on a clinical conditional Generative Adversarial Network (ccGAN) capable of imputing missing values of observed characteristics conditioned by fully-available characteristics values to be then employed for predicting the probable diabetes complication. We investigated our proposed strategy via the lens of a specific clinical use case (i. e. , diabetic retinopathy (DR) prediction) of diabetes complications by using a real EHR multi-diabetic centers (MDC) dataset. We evaluated the performance comparison of commonly used imputation algorithms for the MDC dataset to accommodate high missingness rates (up to 80% for the whole MDC dataset and up to 40% per patient). DR caused by chronically high or variable blood sugar is the most typical and insidious diabetes microvascular complication.