dataesr/scientific-paragraphs-categorization huggingface dataset:
( 2 ) As previously mentioned, if we find a value X such that the image of ( 0 3 X,  1 3 X, ) through  -2 rounds of Poseidon (and a linear layer) is equal to (*, *, 0), then we will always be able to deduce an input (, , 0) for -round of Poseidon that is mapped to. Therefore, we evaluate the permutation as polynomials in F  [X] starting from the state ( 3 X,  3 X, ) with , ,  satisfying System (2), and the CICO problem is equivalent to finding the root of the polynomial corresponding to the rightmost branch of the output. In practice, we use SageMath to generate the polynomial, and we compute the roots either directly from SageMath, or with an external program using NTL. The corresponding code is given in the Supplementary Material.
For all instances, the standard deviation of the memory consumption is negligible (in average 10 -5 times the average value), and the standard deviation of time stays under 3 percent of the average value. The data is represented in Figure  12 , and we performed a linear regression of the time and memory usage of random polynomials root finding. We notice that the structure of the polynomials of Feistel-MiMC and Poseidon does not offer a significant speed up to the root finding compared to random polynomials. Because the theoretical complexity is quasi-linear, the linear regression should be treated cautiously. In addition, the benchmarks apply only on 1 core and do not account for parallelization. We expect to speed up the univariate root finding with NTL parallelization (which, officially, is supported), but some tests showed that NTL CPU usage does not exceed 300%, even with more than 3 threads.
, 2020) , and other developments are underway around the world. This growth in scientific instruments has lead to a variety of implemented Supervisory Control And Data Acquisition (SCADA) systems to control the equipment. Thus, the control of technical components of accelerators is implemented with the DOOCS  (Grygiel et al. , 1996)  and TINE  (Bartkiewicz & Duval, 2007)  control systems, whereas the beamlines equipment is controlled with  TANGO (Go ¨tz et al. , 2003) , KARABO  (Hauf et al. , 2019)  or EPICS  (Dalesio et al. , 1994). Such diversity of SCADA systems requires development of complicated communication protocols when synchronization and communication between different technical components is needed, especially in the facilities where multiple SCADA systems are used. Frequently, the integration of new equipment at large-scale facilities is done by adapting the existing control software used for other devices.
Such a strategy often results in replication of large databases and huge software infrastructure. In our work, we propose a different approach based on the use of modern software solutions, with the help of which one can quickly achieve similar functionality with fewer resources. While the number of various research techniques and analytical instruments constantly grows, the idea of equipment sharing may become reasonable in the near future. Following this concept, analytical instruments for compact accelerators, when possible, should also be sufficiently compact and versatile, which includes the possibility of integration of their control system into various facilities. Good and up-to-date equipment control practice in newly developed facilities should be envisaged. The XES spectrometer was developed for the compact XFEL beamline at DESY (the AXSIS project) and can be used for the single-shot collection of XES spectra simultaneously with X-ray diffraction/X-ray scattering experiments in a hard X-ray energy range (4-12 keV) with attosecond time resolution.
Modules in turn should be easily interchangeable, pluggable and also required only 'on-demand'. For instance, as we have a multi-crystal energy-dispersive spectrometer there is no need to create and maintain a dedicated database, polling system, black-box or data archivers which are usually 'built-in' when using SCADA systems. So most of the existing solutions were with redundant functionality for our task. 2. 2. 2. Portable across different beamlines. The possibility of installing the spectrometer at different beamlines and X-ray facilities was another important task to solve. Incompatibility between different systems is the real case in this situation. Devices from one SCADA system cannot be easily connected to another one because they depend on different transport protocols which are used in each SCADA system [for example, TANGO uses CORBA  (Henning & Vinoski, 1999) , whereas DOOCS uses SUN ONC  (Srinivasan, 1995) ].
Those stand-alone device servers have general use-cases: (1) Providing a way to create a device server that can interact with several control systems. Currently, one needs to create a custom device server implementation for each platform in order to make the device pluggable into them. It requires a significant effort and limits the number of devices that could be used in a specific experiment. (2) Using device servers in a stand-alone mode, without integration with the other devices and very simple read-out and visualization. Currently, most systems do not allow running devices in this mode without setting up central naming and communication services, configuration database, storage database, etc. The first case is rather self-explanatory. Device manufacturers obviously want to write a device server once using a convenient tool-set instead of supporting a device server for each platform (usually in different languages).
For instance, in the case where we need to add more motors, devices or software components that talk to each other, the code base quickly becomes complicated with lots of if-else statements and nested loops. Summarizing, the synchronous communication scheme is easy to implement, but it has several disadvantages  (Hintjens, 2013) : (1) Synchronicity in most cases means blocking control flow, see Fig. 1(a). This leads to latency and freezes in the whole system. (2) Synchronous systems based on peer-to-peer communication do not scale well, e. g. dozens of peers talking to each other in a blocking way. (3) Finally, such systems are very hard to load balance  (Alakeel, 2009). One should note that some established systems like TANGO or DOOCS now introduce an asynchronous model on a client Application Programming Interface (API) level, which is not an asynchronous communication for data management.
Device server Microservices are independent functional units (see green, yellow or gray boxes in Figs. 3  and 4 ). In order to address the challenge of reducing proprietary third-party dependen- Figure 4 As in Fig. 3 , here Magix is a core component responsible for the message flow between counterparts. Each counterpart is a software component or a microservice. Every microservice has its own lifecycle independent from others. The only thing they have in common is that they all attach to a reactive stream produced by Magix using reactive extensions (Rx) and defining observers. Observers 'glue' Rx and microservice's logic. cies, and especially to avoid vendor lock, we have started to design a new framework which is a combination of Rx extension (gives us the possibility to connect to the data stream and get information from messages) and Rx observer (http://reactivex.
io/ documentation/observable. html) (transforms message's information in an understandable way for the recipient) which is attached to the reactive streams. The framework supports passing device property changes in and out of the device via reactive streams and Magix. By design, the solution does not require any dedicated component that will implement the name resolution service. In other words, it does not require any particular database to be running. Small installations may benefit from it as less resources are required to set up and maintain the system. However, for large-scale installations the name resolution service can be implemented. Since Magix compatible device servers do not have limitations on their own infrastructure (like timing services and local storage support), they could be easily built on top of existing vendor-provided solutions (e.
Software In this section we give an overview of the key details of the software solution's implementation. First, let us have a look at the GUI end of the system. As stated within the tasks, our GUI must provide a way for the user to adjust the position of  each crystal as a whole by changing the Bragg angle or the focus, as well as interact with every motor independently. Obviously, it also has to be able to initiate the experiment session, connecting to the upstream components, in our case Magix and software device controllers. Information from the device server is packed into a message described in Waltz-Controls RFC-1 Message (https://github. com/waltz-controls/ rfc/tree/master/1). This information can be unpacked by the control system's connector or the GUI. The software device server is running on a dedicated host, communicating with upstream hardware devices via TCP over Ethernet or directly through USB ports.
The data from devices can be visualized directly on the computer where it is acquired, see Fig. 7. The XES spectrometer GUI is implemented on the Waltz GUI platform (https://github. com/waltz-controls/waltz) (Go ¨tz et al. , 2019; Khokhriakov et al. , 2019)  as it is possible to create a user interface conforming to our needs. Moreover, it is an open source web-based solution. As a web application it does not depend on the system and can be run on Windows, Linux and mobile platforms. The XES spectrometer GUI is a typical front-end project that utilizes the ecosystem of NodeJS and JavaScript  (Brown, 2014) , i. e. dependencies management and builds are done using the npm package manager (https:// www. npmjs. com/). The XES spectrometer GUI's source code resides on GitHub (XES spectrometer GUI's source code, https://github.
com/Ingvord/axsis-xes-gui). For the graphical part we use the Webix UI library (https://webix. com) with its widgets collection (https://docs. webix. com/desktop__ components. html) that provides a huge set of predefined widgets as well as a very intuitive and straightforward way of defining custom widgets and it is also distributed under an open source license. Two points of interest within the GUI source code are asynchronous and synchronous communication with the upstream device controller. Synchronous communication with the upstream device controller is encapsulated in Pi device synchronous controller (PiAxsisController, https:// github. com/Ingvord/axsis-xes-gui/blob/master/src/controllers/ pi_controller. js), asynchronous communication in the Magix-Controller component (https://github.
com/Ingvord/axsis-xesgui/blob/master/src/controllers/magix_pi_controller. js). A part of the MagixController component code example is presented in Fig. 8  to show the reactive paradigm approach. Fig. 8  shows the code snippet responsible for updating motor positions in the GUI. An asynchronous client to Magix is implemented in the reusable plugin waltz-magix-plugin (https://github. com/waltz-controls/waltz-magix-plugin). It provides an implementation of the Magix client API specification defined in the Waltz-Controls RFC-2 (https:// github. com/waltz-controls/rfc/tree/master/2). Technically this plugin is not only bound to the GUI of this applications but can be used in any JavaScript application, as it is available in the NPM repository. We get the Magix client instance from the application's context, see line 33.
In lines 34-39 we observe incoming messages from the upstream device controller and update the GUI (40-42). The messages' specification is defined in RFC-6. The software device controller in this setup is implemented using Python 3 and Pi Python library, i. e. vendor library. The source code for this component resides in the XES device controllers' source code on GitHub (https://github. com/ Ingvord/axsis-xes). To export a synchronous communication channel, we use the Flask framework for building REST services  (Richardson et al. , 2013). This provides a very convenient way to communicate with the device controller as the HTTP eco-system, on which REST services are based, is extremely rich. For example, we can use just a plain browser to communicate with  the device. In general, REST is more preferable to conventional request-response-based solutions like CORBA, see, for example, RESTful Architectural Principles by  Burke (2009).
To export asynchronous communication, we developed a reusable Python client implementation for Magix (RxPython MagixClient, https://github. com/waltz-controls/magix-pythonclient, https://pypi. org/project/magix-client/0. 4/) and attached an observer to it (see Fig. 7 ). The observer extracts incoming messages and delegates execution. All routines are nonblocking and performed within the async. io event loop. An alternative implementation of the software device controller (Data acquisition framework based on DataForge, https://github. com/mipt-npm/controls. kt/tree/dev) is being developed in Kotlin using kotlin-multiplatform (https:// kotlinlang. org/docs/multiplatform. html)  (Nozik, 2019)  technology, which has perfect instruments for implementing asynchronous communication. It allows us to share code between the Java virtual machine (JVM), browser and native targets.
The key feature of the alternative implementation is bypassing vendor's dll and direct communication with the upstream hardware devices, thus eliminating third-party dependency and fulfilling one of our challenges. The project is developed in a JetBrains Research fellowship and currently features a library for creating asynchronous device servers of different complexity as well as communication plugins that follow the Magix specification for REST/SSE, ZMQ and RSocket transport layers. As for the Magix component, in addition to the Kotlin implementation, we developed an experimental reusable implementation based on HTTP2. 0 and SSE written in Java (source code is on Magix component's GitHub page, Source code for HTTP2. 0 and SSE written in Java, https://github. com/ waltz-controls/magix-war-plugin).
Following RFC-2, it implements two methods -'subscribe' and 'broadcast' -as REST endpoints. The implementation of the solution can be considered as a reactive system. The system has to fulfill certain requirements  (Boner et al. , 2014)  to be reactive: message driven, elastic, resilient and responsive. The implementation is naturally message driven. Synchronous HTTP communication is, in fact, message driven due to the asynchronous nature of JavaScript (https://developer. mozilla. org/en-US/docs/Web/JavaScript/ Reference/Global_Objects/Promise) (ZeoLearn, 2018). It is elastic as it is easy to imagine horizontal scalability by increasing the number of Magix instances and the balance load between them. The natural limitation for scalability is the upstream hardware devices as we have a fixed number of motors.
However, it is easy to leverage the load applying backpressure strategies (Reactive Manifesto Glossary, https:// www. reactivemanifesto. org/glossary#Back-Pressure) (Phelps, 2019)  provided by Reactive extensions. Resilience is achieved by early failure interception in the software components and emitting an 'error' message. Finally, it is responsive as there are no blocking calls in the communication channels. An important feature of our implementation is that it does not require the setup -the only thing one needs is to plug the router into the on-premise network and access the GUI using a browser. Naturally, one can switch to a different computer without stopping the measurements and restarting the acquisition. As a proof of concept of cross integration with Tango Controls we see a virtual Tango database (virtual-tango-host, https://github.
com/IK-Company/virtual-tango-host) and a dynamic Tango server that utilize dynamic attributes and commands  (Go ¨tz et al. , 2015). The idea is to have a Tango Controls API as a front-end to our system while the back-end is connected to Magix. Hence, native Tango tools and clients can be used directly with our system. Integration with DOOCS can be implemented in a similar way, e. g. doocs-json (https:// github. com/mipt-npm/doocs-json). Basically, integration with any third-party software component, which can be, for instance, a SCADA system or an archiving or a GUI, is done by defining corresponding messages' specification and implementing a simple micro-service that translates those messages into upstream API calls. The deep overview of this integration approach is the subject of a separate article.
They also demand the creation and maintenance of a database, which we would like to avoid. Our solution is transport agnostic and we foresee components implemented in other languages or technology stacks, e. g. Python and Kotlin-Native. Moreover, using Magix we can extend the capabilities of any existing SCADA, distributed control system (DCS) solution allowing easy integration of new protocols, smooth migration to new protocols, or event technology stacks. The resulting implementation is open source. Most of the components are reusable and reside under the Waltz-Controls organization on GitHub (https://github. com/waltz-controls). Magix-related components are aggregated in the Piazza project (https://github. com/waltz-controls/piazza). The software device server is implemented in both Kotlin and Python languages.
This implementation can be easily scaled to integrate more hardware and software components. In this paper, we intentionally omit the part of the system responsible for integration with, for example, Tango Controls, and present a general overview of the challenges and the solution. Being short, integration with Tango Controls is implemented by providing a virtual Tango database (virtualtango-host) and a dynamic Tango server. There is also some work done with the integration with DOOCS (doocs-json). A common solution to cross-integrate different SCADA systems is foreseen within the Piazza project. At first, it may seem that the solution is over-engineered, especially in terms of the variety of technology stacks used; this was done on purpose just to demonstrate that the solution is very flexible, lightweight, compact and modular.
Acknowledgements VM acknowledges the PAL XFEL at  Pohang Accelerator Laboratory  for providing the R&D beam time. We acknowledge  DESY (Hamburg, Germany) , a member of the  Helmholtz Association HGF , for the provision of experimental facilities. Parts of this research were carried out at  PETRA-III  and we would like to thank  Aleksandr Kalinko  and  Wolfgang Caliebe  for assistance in using P64 beamline. The authors acknowledge  Vasily Chernov  for his work on early program prototypes. Open access funding enabled and organized by Projekt DEAL.
As model solute, we investigate the case of camphor, an interesting rigid bicyclic chiral molecule possessing ten 2 H-RQCs (10 inequivalent monodeurated isotopomers per enantiomer). In order to analyse the orientational behaviour of each enantiomer in a single oriented sample, while simplifying the identification of the (D/L)-isomer signals on spectra, a D-isomer enriched scalemic mixture (ee(D) = 30%) was used. Orientational data of camphor in each mesophase were calculated for the first time using the computer program ConArch + , modified to accept 2 H-RQCs as anisotropic data input. Differences in enantiodiscriminations provided by the four aligning systems are examined and discussed in terms of structural and chemical features between polymers. The new L-MSP mesophase described in this work exhibits very promising enantiodiscrimination capacities.
Data analysis by ConArch + So far, the recent exploitation of 2 H-RQCs has been performed using the MSpin-RQC program,  51, 52  a variant of MSpin, initially able to manage RDCs or RCSAs as input data. 30, 53 In this work, another computational approach delivering orientational data   5 ) including their atomic numbering; the red and blue colors are used for identifying them. All 1 H/ 2 H NMR data related to the methyl, methylene (sp 3 ) and methine (sp 3 ) groups are identified by the green, pink and black colors, respectively. of a solute has been explored, the ConArch + (Configurational Architect) software package. 54, 55 ike MSpin, the ConArch + program computes the Saupe order parameters, S ab , (via an algorithm based on the principle of singular value decomposition (SVD)) in order to minimize the difference between the experimental values ( 2 H-RQC Exptl.
) and the backcalculated values ( 2 H-RQC Calc. ) from the order matrix for a given geometry. A schematic description of the operating principle of the ConArch + program using 2 H-RQC data is presented in Fig. S4 (ESI † ). Although not used in the current investigation, the main difference between ConArch + and MSpin is the distance geometry module of the former. 56 The determination of the alignment or the Saupe tensor from RDCs or RQCs does not differ substantially in both programs. The decisive strength of ConArch + is that it is able to let structures evolve under the influence of the NMR data. This means that ConArch + does not rely on structural comparisons between precalculated structures (from DFT, for example) and measured data; it generates structures from the data. Therefore, using a good data set, ConArch + is able to determine correct relative configurations from an input structure of arbitrary configuration.
S16  and S18, ESI †) in L-MSP, but also in the three other CLCs. Thus, the coherence between experimental RQC and RDC data enables the determination of the sign of the 2 H-RQCs. The consistency of the two (L/D)-isomer datasets with respect to the exo/endo positions in CH 2 groups as well as for CH and CH 3 groups, leading to the sign of any 2 H-RQC can be scrutinized in Tables S5, S7, S9 and S11 (ESI †). Moreover, the small Q-factors (Q o 0. 07) obtained with all the mesophases definitively validate the determined signs by correlation of the 2 H-RQCs.
4 T (100. 3 MHz for 13 C) using a Bruker Avance I (5 mm QXO NMR probe). Analysis and assignment of  13  C resonances were made using classical approaches (COSY, HSCQ, and HMBC) in combination with data from the literature. 47, 48 Evaluation of scalar couplings, 1 J CH , and total spin-spin couplings, 1 T CH , of 5 were obtained by the analysis of 1 H coupled  13  C spectra and (T CH /4)-resolved experiments (see the ESI †). All NMR 1D/2D spectra (NAD and 13 C) were recorded at 300 K and controlled with a stability of AE 0. 1 K.
The convergence of the total all-sky D factor with this procedure is, of course, present for all considered resolutions, since it should be simply proportional to the total mass within the CSIBORG volume. FIG. 1. Mollweide projection in galactic coordinates of the ensemble mean J and D factors over the CSIBORG realizations, alongside the brightest ∼6000 galaxies from the 2M++ dataset (red points). One can see that the galaxy number density is higher in the regions of large J and D factors, i. e. , at the peaks of the underlying DM distribution. We overplot the mask on completeness used in the BORG inference of the initial conditions  [63, 69]  (faded region near the galactic plane masked out).
If clump i has density profile ρ i cl , then it contributes to the total J factor value within a HEALPIX pixel, p, as J p ¼ Z p;Δ halo ρ sm ðs; ΩÞ þ X i ρ i cl ðs; ΩÞ 2 dsdΩ ¼ J sm;p þ J subs;p þ J cross;p ; ð17Þ where J sm;p ¼ Z p;Δ halo ρ 2 sm ðs; ΩÞdsdΩ; ð18Þ J subs;p ¼ Z p;Δ halo X i ρ i cl ðs; ΩÞ 2 dsdΩ; ð19Þ J cross;p ¼ 2 Z p;Δ halo ρ sm ðs; ΩÞ X i ρ i cl ðs; ΩÞ dsdΩ; ð20Þ and Δ halo represents the intersection of the halo volume with the cone spanned by the pixel p. Our task is therefore to determine the distribution of clumps for a given halo and to calculate these integrals. Here, we readily use the solution provided by the CLUMPY package and describe it briefly below. Assuming that a given halo has N tot independent clumps, we factorize the distribution for the number of clumps with some mass M, concentration c, in some region dV ¼ d 3 r as  [77, 85] dN dVdMdc ¼ N tot dP V ðrÞ dV dP M ðMÞ dM dP c ðM; cÞ dc : ð21Þ Since the clumps form before the host halos within ΛCDM, their spatial distribution will follow the host DM density profile.