dataesr/scientific-paragraphs-categorization huggingface dataset:
The control of a distributed architecture, spanning (potentially) multiple machines, is realized with Google Remote Procedure Call (gRPC) along with Google Protocol Buffer (Protobuf) serialization layer. The gRPC and ProtoBuf enable seamless integration of code written in multiple programming languages. The core of Jungfraujoch is written in C++ and short communications 228 Filip Leonarski et al. Jungfraujoch Figure 2 The Jungfraujoch data flow from the JUNGFRAU detector, via the FPGA card to the CPU buffer for compression and spot finding. interacts with beamline control applications, which are usually written in Python and JavaScript web front-end applications. Technical details are given in Appendix A.
Next, the data stream passes through an ethernet data link, internet protocol, user datagram protocol (UDP) and JUNGFRAU PSI detector header handlers, which are based on an open-source design  (Sutter et al. , 2018; Ruiz et al. , 2019). Only the receiving part of the protocol stack is implemented. The network stack ends with a finite-state machine, which makes it possible to switch between the idle state, when packets are discarded, and the receiving state, when packets are forwarded through the pipeline. As testing the FPGA pipeline with an X-ray detector at a source of high-intensity X-rays is not always convenient, Jungfraujoch has built-in functionality to internally create a flow of packets. The core has 1 MB of memory that can be preloaded from host memory, at the beginning of the operation, with data for a single detector module (512 Â 1024 pixels).
2. 1. 2. Conversion from raw readout to photon counts. As the JUNGFRAU is an adaptive gain detector it is necessary to transform raw readout values into photon counts, or accumulated energy, before data analysis. This procedure has been described in prior publications  (Redford et al. , 2018a; Leonarski et al. , 2020). It includes subtraction of dark current (pedestal), multiplication by gain factor and multiplication by 1/X-ray photon energy. All calculations are expressed in fixed-point arithmetic, which reduces both FPGA logic utilization and bit width of operands. All coefficients and photon-count results are 16-bit integers  (Leonarski et al. , 2020). Within the standard energy range of 4-20 keV for macromolecular crystallography application, this procedure gives differences of less than 0.
It also allows for flow control in case the software side of Jungfraujoch is not able to cope with incoming data from detector modules -the WR queue becomes empty and FPGA design pauses (stalls) until the software is ready to receive new packets. Incoming packets are then buffered within the FPGA, roughly up to 4 MB in size. If this capacity is exceeded, further packets are dropped, resulting in missed frames, until congestion is resolved. The advantage of our solution is a significant reduction of control overheads. For Jungfraujoch, the CPU and FPGA exchange control information per one complete detector module, i. e. 1 MB. On the other hand, a standard network card has to signal the CPU for every received ethernet packet. In the JUNGFRAU detector case, this one packet size is 8 kB, so it is 128 times higher frequency of control messages.
2. 1. 4. FPGA design tools. FPGA development has benefited from two important technologies: high-level synthesis and OpenCAPI. The smart-network-card FPGA design is written primarily in C++, which is different from standard practice in hardware design. Naturally, digital circuits are designed with hardware description languages (HDLs), like Verilog or VHDL, which make it possible to describe the inherent parallelism of hardware. While HDLs allow one to obtain the most optimal design, they are time consuming in development and require a set of skills uncommon for software developers. Therefore, FPGA vendors provide high-level synthesis tools that transcompile C++ code, with some additional directives (pragmas), into HDL. One of the advantages of high-level synthesis is to guarantee that the behavior of C++ code and resulting HDL is close enough -therefore initial testing can be performed directly on C++ code.
OpenCAPI  (Stuecheli et al. , 2018; Hoozemans et al. , 2021)  is a new-generation interconnect (see Fig. 3 ), currently only available in IBM Power architecture servers. The OpenCAPI features full memory coherence, i. e. the connected device sees memory the same way as a program running on the host CPU, making it possible to benefit from virtual addressing present in modern CPUs. The OpenCAPI relieves developers from taking care of the low-level details of memory hierarchy on the operating system level and allows them to focus on high-level productivity. A key feature of OpenCAPI is the possibility of running design simulations with both FPGA design and the actual software component via the OpenCAPI Simulation Engine. The OpenCAPI nominal throughput is 25 GB s À1 , corresponding to 2 Â 100 Gbit s À1 ethernet links.
Jungfraujoch software service The FPGA card is integrated with the beamline software stack via a Jungfraujoch software service. The software service is a multi-threaded application that handles data from the detector via FPGAs and composes full images from detector modules with optional summation. Images are then compressed and forwarded via a ZeroMQ PUSH socket to the HDF5 writer. To improve performance, it is also possible to send images over multiple PUSH sockets on a round-robin basis. The Jungfraujoch software service provides a subset of compression options to the user. Bitshuffle filter  (Masui et al. , 2015)  is always applied, however in the later stage it can be combined with the default LZ4 or an alternative Zstandard (Facebook) compressor. The latter can provide a better compression ratio for X-ray diffraction images at the cost of lower performance  (Leonarski et al.
, 2020). As a third choice, a custom experimental compressor was developed for Jungfraujoch, which limits itself to a run-length encoding of two characters, 0 and 255 (all 0 bits or all 1 bits), producing Zstandard compliant format  (Collet & Kucherawy, 2021)  output. This is based on properties of X-ray diffraction images, which after bitshuffle filtering show long sequences of zeros. To provide quick feedback, the Jungfraujoch software service also performs the following three additional operations on a subset of images: (a) Uncompressed images are published at a default rate of one image per second via a ZeroMQ PUB socket for display on a beamline console providing visual live feedback. (b) Basic image statistics, like mean count and radial integration profile within a resolution range, are calculated at a default rate of 100 images per second.
Results of the spot finding, i. e. the list of reciprocal-space points corresponding to spots, are published via a ZeroMQ PUB socket for an external indexing routine. The Jungfraujoch software service also calculates dark current (pedestal) values and root mean square deviation of the pedestal, according to a previously described procedure  (Redford et al. , 2018a; Leonarski et al. , 2020). Pedestal calculation is accelerated with a GPGPU.
Example integration applications Jungfraujoch is designed to be part of a beamline software infrastructure; therefore it has to be easily integrable into larger frameworks, such as LIMA  (Petitdemange et al. , 2018)  Figure  3  A photograph of the IC922 server (IBM). The OpenCAPI interface over a dedicated cable allows the FPGA to coherently access the memory of the host CPU. for image processing, MXCube  (Oscarsson et al. , 2019) , GDA  (Gibbons et al. , 2011) , DA+  (Wojdyla et al. , 2018) , BLISS  (Michel et al. , 2019) , Karabo  (Hauf et al. , 2019)  and Bluesky  (Allan et al. , 2019)  for control and synchronization. Below we provide a list of example applications that allow its standalone operation. Because of the modular nature of the design, these applications can be easily replaced with alternatives in accordance with synchrotron facility preferences.
(i) 'gRPC broker' is a state machine that controls the behavior of the whole environment. It presents the user with options to start, stop and cancel measurements, as well as to display the current status of services. (ii) 'HDF5 writer' receives image chunks via ZeroMQ and writes them into a data file. Given that the Jungfraujoch service already compresses the chunks, the HDF5 writer requires very little resources. The system allows multiple writers to operate in parallel, assuming that they manipulate different files. The HDF5 writer is also responsible for writing a metadata 'master' file according to the NXmx Gold Standard  (Bernstein et al. , 2020). (iii) 'Indexer application' is a wrapper over XGANDALF  (Gevorkov et al. , 2019)  or other indexing algorithms, which processes diffraction spot positions received via ZeroMQ.
Measured Jungfraujoch performance To verify the performance of the system, we prepared a routine that runs both FPGA and Jungfraujoch software routines, with data provided by the in-FPGA internal packet generator. In this way, all internal steps of the pipeline are tested, specifically the throughput of the FPGA itself, the throughput of the OpenCAPI interconnect, geometry transformation, compression and spot finding. As a sanity check, the last image is compared with the expected values. Naturally such a test excludes external communication, i. e. the FPGA receiving UDP packets from the detector and the efficiency of the HDF5 writer. The test was executed on an IBM IC922 server equipped with two 20-core POWER9 CPUs, two Alpha Data 9H3 FPGA boards and two Nvidia T4 GPUs. Eighty compression threads were conducted in parallel, while spot finding and radial integration analyzed every 20th frame.
Data-collection size was set to one million frames, ensuring that local buffering does not affect results. To ensure realistic compression factors, we loaded a typical lysozyme diffraction image to FPGA memory and simulated each card receiving data from four detector modules with the internal packet generator. Assuming that the pipeline (both FPGA and software) is paused when downstream processing is unable to match the performance speed, the frame rate will equilibrate at the rate of the slowest component. Results of the measurement are presented in Table  1  and show that the system has a significant margin over the target of 4M at 2 kHz performance, reaching above a 3 kHz frame rate. This demonstrates that the Jungfraujoch server has the potential to support even larger detector systems in the future.
Moreover, our results illustrate that handling the highest data rates requires custom compression developments, as the Jungfraujoch Zstandard implementation outperformed the standard LZ4 compressor. During this test, we monitored environmental sensors within the server. The total server power consumption during the test was $680-690 W, compared with 330 W when idle. FPGA board power consumption was in the range of 32-25 W per board, based on voltage and current sensor readout (Alpha Data Board Control Interface; sum for 3. 3 V and 12 V rails), while power consumption per GPU was in the range of 30-40 W (nvidia-smi utility).
Conclusions and outlook The Jungfraujoch system described in this article is a prime example that task-specific computing architectures can be short communications Performance results for the Jungfraujoch FPGA and software show that the system has a significant margin over 2 kHz and potentially can reach a performance above 3 kHz. Presented numbers are from test handling one million images generated with the FPGA internal packet generator, corresponding in size to a 4M detector. successfully utilized for data acquisition with high-frame-rate pixel-array detectors. Currently, the system can handle 30 GB s À1 data from JUNGFRAU detectors at the maximum frame rate of 2 kHz and is a solid basis for the future development, such as a higher-performing framework aimed at 10 kHz detectors. One of the significant achievements of our design is the compact size of the whole system.
Main components, i. e. data acquisition, compression and image analysis (e. g. spot finding), are all packed into a single two-rack-unit server system. Such design, inspired by the DECTRIS Detector Control Unit, enables easy transport or system copy. This allowed us to test and gain experience from operating the Jungfraujoch system at three synchrotron beamlines: X06SA (SLS/PSI), BL-1A (Photon Factory, Japan) and BioMAX (MAX IV Laboratory, Sweden). The results of these beam times will be published separately. Maximizing the functionality within a single server was possible thanks to the high power efficiency of task-specific accelerators (FPGAs and GPGPUs). For example, the throughput of a single FPGA board in converting JUNG-FRAU images from raw to photon count representations exceeds the performance of a four-socket CPU server used by us in a previous work  (Leonarski et al.
, 2020). This is a 30-times increase in power efficiency, given the server consumption was above 1 kW and the FPGA board was at 30 W. Yet, the power efficiency would not be enough if programming the accelerators required prohibitively high effort. FPGA high-level synthesis and OpenCAPI interconnect are two technologies that have made the Jungfraujoch system development feasible. At the initial stages of the project, the benefits of using these features were the shortening of development time and the reduction of the entry barrier for FPGAs software development. With the system's complexity growing over time, the simplicity and robustness of design verification became advantageous. To increase the accessibility of Jungfraujoch, we are currently working on a PCI Express implementation. Given most parts of the current design can be reused thanks to standard FPGA interfaces, such as the Advanced Extensible Interface (AXI), we expect the two flavors of the design to coexist.
OpenCAPI design would allow for rapid development, prototyping and handling of more advanced scenarios, while PCI Express would make deployment possible on a broader range of hardware platforms. Our results demonstrate the benefit of combining data acquisition with real-time image analysis within a single server system. If the calculations were performed on an external system, this would increase image compression, transfer and decompression overhead. It is especially the case for imageanalysis methods with a small performance footprint, like radial integration or spot finding. The current implementation can analyze only a subset of images in real time at the maximum frame rate. While this is good enough for experimental feedback, we aim to scale up analysis performance for every image without affecting the frame rate for the next iteration of the Jungfraujoch.
A2. Software requirements Building Jungfraujoch software necessitates C++17 compliant compiler (e. g. GCC 11. 2), CMake 3. 15 or newer, HDF5 library 1. 10 or newer, ZeroMQ library, Nvidia CUDA environment 11. 5, as well as gRPC. Building the FPGA design requires Xilinx Vivado 2022. 1 and Xilinx Vitis High-Level Synthesis 2022. 1. To synthesize all card features, license for the Alpha Data 9H3 reference design is necessary. Cadence Xcelium simulator 20. 09 is needed to simulate the FPGA design.
short communications A4. Source code The source is publicly available from PSI GitLab at https://gitlab. psi. ch/jungfraujoch/jungfraujoch. Software components are licensed under the GNU Public License version 3 and hardware components are licensed under the strongly reciprocal variant of CERN Open Hardware License. Synthesized FPGA bitstream for the Alpha Data 9H3 board is available from the authors upon request. The code includes external libraries, specifically: OC-Accel, OpenCAPI Simulation Engine, bitshuffle (pre-)compression  (Masui et al. , 2015) , Spdlog for logging, GEMMI  (Wojdyr, 2022) , tinycbor (Intel), C++ JSON parser  (Lohmann, 2022) , SLS Detector Package, XGANDALF indexer  (Gevorkov et al. , 2019) , Xilinx High-Level Synthesis headers (arbitrary precision numbers and AXImm burst) and Catch2 testing framework.
A5. Design verification A three-step procedure was developed to verify Jungfraujoch: two steps before deployment on the hardware platform and the last step after deployment. The first step was compiling high-level synthesis code with a standard C++ compiler and running a standard testing framework (Catch2), making it possible to verify all routines quickly. The second step was simulation with the help of the OpenCAPI Simulation Engine and Cadence Xcelium. Here, the whole FPGA design, in HDL and including the OpenCAPI interface, is simulated together with software (CPU/GPU) code running a short data collection. The speed of the hardware simulation is slow: simulating three frames of a single-module system takes roughly 2-3 h. These two tests were implemented with a continuous integration pipeline (GitLab), ensuring that bugs can be identified and fixed quickly.
Acknowledgements The authors acknowledge the staff of beamlines  X06SA  and  X06DA  ( SLS, PSI) ,  BL-1A  ( Photon Factory, Japan ), and  BioMAX  ( MAX IV Laboratory, Sweden ) for opportunities to test Jungfraujoch. FL acknowledges  Professor Kay Diederichs  ( Universitat Konstanz ) for discussions on spot finding and indexing, colleagues from  DECTRIS  for discussions on data acquisition,  Dr Lionel Clavien  ( Inno-Boost SA ) for support of POWER9 hardware, and the  Xilinx University Program  for a donation of the Auto-Negotiation/Link Training license for the Ultrascale+ 100 Gbit s À1 ethernet intellectual property core. Conflict of interest: AC and BM are employees of IBM, the manufacturer of the IC922 server.
It should be highlighted that the following weighting function could smoothly represent the solid boundary during movement of particles 𝐵 = 𝜀(𝜏-0. 5) (1-𝜀) + (𝜏-0. 5) (15) When ε = 0, B = 0; when ε = 1, B = 1. As the effective evaluation of the local solid ratio ε is very important for generating the smoothness and stability of the fluid-moving boundary calculations, for a detailed discussion on this issue can be found in Wang et al. 39  The additional collision term Ω S 𝑖 is based on the bounce-back rule for the nonequilibrium part Ω S i = 𝑓 -𝑖 (𝑥, 𝑡) -𝑓 𝑖 (𝑥, 𝑡) + 𝑓 eq 𝑖 (𝜌, 𝐔 s ) -𝑓 eq -𝑖 (𝜌, 𝐮 𝑖 ) (16) where 𝐔 s is the velocity of the particle under consideration and 𝐮 𝑖 is the velocity of the fluid at the node. The resultant hydrodynamic force (F f-d ) and torque (T f-d ) exerted on the solid particle can be evaluated by 𝐹 𝑓-𝑑 = Ch [ ∑ 𝑛 ( 𝐵 𝑛 ∑ 𝑖 Ω S 𝑖 𝐞 𝑖 )] (17) 𝑇 𝑓-𝑑 = Ch [ ∑ 𝑛 (𝑥 -𝑥 𝑝 ) ( 𝐵 𝑛 ∑ 𝑖 Ω S 𝑖 𝐞 𝑖 )] (18) Validations of our LBMDEM code can be found in our previous work.
ML classification discriminates ED-treated mDANs based on image-derived neuronal features Due to the high dimensionality of phenotypic profiles and the large number of changed features, it is not trivial to identify feature patterns that correlate with an experimental condition. Supervised ML classification algorithms are designed to learn rules from large and complex datasets and compute the probability of a new data point falling into predefined classes, such as EDC treated or untreated conditions. We exploited three "open" ML classifiers that allowed us to deduce which data features are most explanatory for the observed differences between classes and to identify generalizable rules related to the cell biological effects of EDC exposure. LDA, XGBoost and LightGBM are popular ML classification algorithms.
LDA is used for finding a linear combination of features that best separates classes, while XGBoost and LightGBM are used for creating a series of models that learn from the errors of the previous models to improve prediction accuracy. The main difference between XGBoost and LightGBM is how they build decision trees. XGBoost builds trees one level at a time, while LightGBM focuses on the leaves, or endpoints, of the tree. All three models allow the extraction of features weights. These weights can provide insights into which features are most important in the classification result, helping to interpret the model. Briefly, all the image datasets for each condition were divided into a train set (90% of the dataset) and a test set (10% of the dataset). LDA, LightGBM and XGBoost classifiers were then trained to distinguish treated from untreated phenotypic profiles using the training set.
All EDC concentrations ranging from 0. 01 to 2 μM were assigned to the treated class. The trained model was applied to the previously unseen test set phenotypic profile data to cross validate the classification performance (Fig. 4A ). Cross-validation is the application and evaluation of a trained ML model on different slices of the training dataset and is useful to prevent model overfitting when data is limited. When applying tenfold cross-validation on the training dataset both the LightGBM and XGBoost classification algorithms showed a similar performance    S3 ). (D) Dose-response graphs and statistical analysis describing the effect of treatments on the number of living cells, and αSyn intensity in TH + neurons. Data is shown as normalized single data points (black dots), mean (black lines) and 95% CI of the mean (gray area).
*p <. 05, **p <. 01, ***p <. 001 compared to methanol control. Scale bar, 20 µm. in predicting the phenotypic classes (Fig. 4E, H ). Due to the relatively small size of the dataset, both LighGBM and XGBoost showed accuracy variations during training from 0. 4 to 1. 0 (median: 0. 8) and 0. 38 to 1. 0 (median: 0. 83), respectively. The LDA classifier performed more stably and varied from 0. 7 to 1. 0 (median: 0. 88) (Fig. 4B ). Confusion matrices were plotted for all three classifiers to check for by-class errors and to calculate the accuracy exclusively to the test set. The test set contained data from 15 control and 11 chemicals treated wells across all concentrations and EDCs. LDA classification resulted in the lowest accuracy (0. 88) among the three methods used (Fig. 4C ). LightGBM classification predicted neuronal phenotypes (i.
One of the notable findings of this study is the ability of ML to accurately discriminate and classify the phenotypic profiles of mDANs treated with EDCs. Specifically, when the XGBoost algorithm was applied to our image-derived dataset, it correctly classified mDANs treated with EDCs and control cells with a high accuracy of 0. 96. (Fig. 4I ). We previously reported the effectiveness of ML in classifying normal and PD affected mDANs by applying LDA and Support Vector Machine (SVM) classifiers to image-derived datasets  27. ML can help to identify subtle phenotypic patterns that may be easily overlooked but that may be relevant representing the initial signs of cellular distress. This approach appears to be particularly important in the context of the studies on environmental chemicals' effects on human health.
Humans are chronically in contact with these biologically active substances and the consequences on the neurotransmitter systems might become evident only after a protracted exposure, making their risk assessment very challenging. By analyzing large datasets, ML algorithms can detect complex relationships and patterns that may not be immediately apparent to human observers. In this study, by means of the ML approach, EDC treated and untreated mDANs were differently classified based on relevant biological features related to PD, such as increased αSyn expression and diminished neurite network length. These data are particularly important, as we exposed human mDANs to BPs and PFs doses that resemble the real-life exposure range. We anticipate that additional applications of ML classifiers on high-content imaging data in toxicological studies in different model systems are necessary to gain further insights into their predictive power.