dataesr/scientific-paragraphs-categorization huggingface dataset:
We then conducted a sensitivity analysis of the material properties of the swelling layer, namely the maximum swelling pressure, Young's modulus, Poisson's ratio, overburden thickness, and the initial volumetric water content. We compiled a synthetic dataset using the heave modeling data to build a ML model, specifically a least-squares boosting ensemble. Finally, we employed the ML model to rank the relative importance of parameters influencing the HM swelling of clay-sulfate rocks.
The analysis showed that only a very small ground heave close to zero was measured at around 1400 observation points. The maximum measured heave was 0. 4106 m, and the average value was 0. 0785 m. The heave at 85 points was equal to or higher than 0. 3 m. Small subsidence at some observation points (a total of 66 points), which surround the heaved area, was also measured. The maximum measured subsidence was 0. 0038 m. The heave measurements (3431 observation points) were used to calibrate the numerical model and evaluate the accuracy of the presented modeling approach. However, in the compiled dataset  (Schweizer et al. 2018) , the number of measured heave data was limited at the start of the campaign, and more data were acquired after installing all the observation points. The analysis showed that the dataset has high variability and ambiguity for various distances from the center, indicated by the large spread of heave values (see Sect.
Least-Squares Boosting Ensemble We employed the least-squares gradient boosting (LSBoost), an ensemble of two powerful algorithms, boosting and trees  (Friedman 2001; Hastie et al. 2009  where x is the predictor variable, ȳ is the mean of y, w with (0 ≤ w ≤ 1) is the learning rate, N is the total number of learners, and n is the weight for the n th learner. The LSBoost can directly quantify the importance or relative influence of each feature/predictor from a trained model because the algorithm chooses a single feature at each level to approximate the alignment accuracy residual  (Hastie et al. 2009; Moting 2019). A high value of any feature indicates the high effect of that feature in estimating the predicted value. The LSBoost algorithm was implemented in MATLAB 2021b.
Dataset We used the obtained heave data from the sensitivity analysis to compile a synthetic dataset to build the machine learning model. The LSBoost considers Young's modulus E, Poisson's ratio , overburden thickness H o , maximum swelling pressure sw max , porosity , and initial volumetric water content i of the swelling layer as input parameters, while the corresponding maximum modeled heave observed at the ground surface is considered as the output parameter. We used k-fold cross-validation to randomly divide the dataset into k groups of roughly equal size. Then, k-1 groups of the dataset were used for the model development and the remaining group was used to validate its performance. Therefore, each data sample had a chance to contribute to both the training and validation phases  (Refaeilzadeh et al.
Relative Importance of Parameters The data obtained from the sensitivity analysis were used to build a synthetic dataset. The scatter plot (Fig. 9 ) shows that the heave determined by the ML model agrees well with the results of the HM model (data points point close to the 1:1 reference line), illustrating the good performance of the LSBoost model in predicting the maximum heave values obtained from the HM modeling. The model efficiently identifies the existing patterns in the input data to predict the The relative impact of parameters (Fig. 10 ) on the heave calculations indicates that the maximum swelling pressure and Young's modulus of the swelling layer were the most important parameters controlling the swelling; the former had a 2. 35 times higher influence than the latter. This was followed by the Poisson's ratio, the initial volumetric water content and the overburden thickness.
The Medical Informatics and Digital Health Multilingual Ontology (MIMO) currently contains 1,379 concepts. MIMO has been developed with the following process and integrated into the SaNuRN project. The MIMO team has analyzed the main controlled vocabularies in health and being a part of UMLS (Unified Medical Language System)  [11] : MeSH (Medical Subject Headings), SNOMED CT, NCIT (National Cancer Institute Thesaurus), MedDRA or ICD (International Classification of Diseases; in their ninth, 10th, and 11th revision). Based on this manual review by two medical informaticians (AB & SJD), the MeSH thesaurus was assessed as having the most comprehensive number of medical informatics concepts. Indeed, the MeSH thesaurus is the unique reference terminology, where a tree describing medical informatics and, more broadly, information science exists.
Results The Medical Informatics and Digital Health Multilingual Ontology is freely available through the HeTOP interface at the following URL: https://www. hetop. eu/hetop/rep/en/EFMIMIMO/. Figure  1  displays an example of MIMO, using the "bibliometrics" concept. It provides the translation in various languages, mainly European in this example as "bibliometrics" is a MeSH descriptor. A copy of these translations was integrated into MIMO. An added list of translations was added from the WikiMeSH algorithm  [15]  that we have recently developed to enhance the MIMO translations in European languages and above. A specific module was devoted to the manual curation of these translations because this mapping could generate false positives in case of polysemy (multiple related meanings) or ambiguous acronyms.
In May 2022, MIMO was also integrated into the information system of the Rouen DBI, to allow the manual indexing of SaNuRN digital health teaching resources by medical librarians. Currently, 345 out of 10,000 teaching resources are in the scope of digital health. These teaching resources are reindexed, using MIMO to be as precise as possible. Figure  2  displays an example (in French) of a digital health teaching resource indexed using MIMO. The following MIMO concepts were used: data annotation, data warehouse, NoSQL, search engine, semantics, SQL. A specific semantic search engine (CISMeF SaNuRN) has been deployed that only focuses on digital health teaching resources. It is available at: https://doccismef. churouen. fr/dc/#env=sanurn.
We present the EpIC Monte Carlo event generator for exclusive processes based on generalised parton distributions. EpIC utilises the PARTONS framework, which provides a flexible software architecture and a variety of modelling options for the partonic description of the nucleon. The generator offers a comprehensive set of features, including simulation of a variety of exclusive processes and radiative corrections. It may be used both in the analysis of experimental data, as well as for impact studies, especially for the future electron-ion colliders.
As part of this global effort, we have developed a Monte Carlo (MC) generator called EpIC, whose logo appears in Fig. 1. The EpIC generator features a novel architecture using a modular programming approach. In this way, the code structure is kept as simple as possible and the addition of new developments, such as new channels or algorithms to generate random numbers, is made as easy as possible. The architecture of EpIC, including the nomenclature for naming its elements, is based on the PARTONS framework  [21]. PARTONS is also used to evaluate the Born cross-section for a given process, which is used to generate MC events after the inclusion of radiative corrections (RCs). EpIC can generate events for a number of exclusive processes. The following are available at the time of writing this paper: deeply virtual Compton scattering (DVCS), time-like Compton scattering (TCS), and deeply virtual meson production (DVMP) of π 0 and π + mesons.
In this article, we choose DVCS whenever an exemplary process is needed. Adapting to other processes is straightforward and typically only requires replacing the acronym, e. g. the equivalence of DVCSGeneratorService for TCS is TCSGeneratorService. EpIC, as in the case of PAR-TONS, follows the so-called Trento convention  [22]  for the definition of e. g. scattering angles. The purpose of this article is to provide a reference and document the structure and functionality of EpIC. We will focus on the explanation of the architecture, starting with a brief description of the PARTONS framework in Sect. 2, which is crucial to understand the technical aspects of EpIC. In Sect. 3, we present the architecture of EpIC. In particular, we list all types of modules and show the relation between them.
The user interface is introduced in Sect. 4, while the generator's performance is demonstrated in Sect. 5. The sum-mary is given in Sect. 6. In the appendix (Appendix A), we review the basics of the radiative corrections and explain how to compute them in the collinear approximation. The purpose of this appendix is to help users to familiarise themselves with the parameters of radiative corrections used in EpIC. EpIC is written in the C++ programming language. The code can be accessed at the GitHub platform  [23]  and is distributed under the GPL 3. 0 licence. The project's webpage, Ref. [24], includes information such as a technical documentation of C++ classes, a guide on how to compile the code, and an example code for users.
PARTONS framework PARTONS (PARtonic Tomography Of Nucleon Software)  [21]  is a software framework for studying the 3D structure of hadrons. It provides essential tools for QCD phenomenology and allows one to compute observables from models describing non-perturbative objects. For instance, it includes various models of GPDs and methods to perform their pQCD evolution. It also includes methods to evaluate amplitudes and cross-sections for a variety of exclusive processes, such as DVCS and TCS, described at LO and NLO of pQCD precision. The framework can be used in analyses to predict observables from existing models, see e. g. Refs. [16, 17, 25] , but also to constrain new models from available experimental data  [26, 27]. Because of its versatility, the framework can also act as a laboratory for studying new concepts for phenomenology, like new ways of modelling, see e.
g. Refs. [28] [29] [30]. The architecture of PARTONS utilises a modular programming approach. The central role in this architecture, which has also been adopted in EpIC, is played by the modules. A module is a single encapsulated development of a given type, for instance a single GPD model. The only purpose of modules is to provide data for a specific input, like values of GPDs for a given GPD kinematics. The construction of modules utilises both the inheritance and polymorphism mechanisms of C++. Therefore, the development of new modules is remarkably straightforward, as developers need only to provide their code related to the developments they are interested in and adapt it to the predefined classes in the framework. We demonstrate this with the example of GPDGK11 module, which is used to implement the Goloskokov-Kroll (GK) GPD model  [31] [32] [33] , from the PAR-TONS library.
The following is an excerpt from the header file: The square of the factorisation scale μ 2 R The square of the renormalisation scale The function GPDGK11::computeH() returns a container that stores the numerical values of twist-2 GPD H , including its singlet, H (+) , and non-singlet, H (-) , combinations, as defined in Ref. [13]. The input GPD kinematics is accessible in the body of the function via the m_x, m_xi, m_t, m_MuF2 and m_MuR2 variables, which are defined in the GPDModule class. Those variables correspond to the GPD variables x, ξ , t, μ 2 F , and μ 2 R , respectively, as introduced in Table  1. They are set when one evaluates GPDs via PartonDistribution compute(const GPDKinematic& kinematic, GPDType::Type gpdType), which is also defined in GPDModule. As one may see in our example, quark flavours and GPD types are distinguished by QuarkFlavor and GPDType enums, respectively, while inputs and outputs are encapsulated in the QuarkDistribution, PartonDistribution and GPDKinematic containers.
A single instance of each module is loaded into memory at the beginning of the program execution, namely when static constant variables are initialised. The addresses of such instances are stored by the registry, which later acts as a phone book, allowing one to access the instances by either their IDs or defined names. We demonstrate this mechanism with the following example: using namespace PARTONS; const unsigned int GPDGK11::classId = BaseObjectRegistry::getInstance()-> registerBaseObject(new GPDGK11("GPDGK11")); → → → When the program starts, GPDGK11::classId is initialised with a unique ID assigned by the registry (BaseObjectRegistry class being a singleton). During this process, the registry takes and stores the address of each new instance. All modules inherit from the same basic class called BaseObject, allowing the registry to store addresses of the same type of objects.
The constructor of BaseObject requires a unique string of characters that is used as a human-readable name of the module. The registry stores addresses of single instances of preconfigured modules. Users may get copies of those instances by using the factory (also being a singleton), for instance: The registry and factory are the key architectural ingredients, which allow users to add an unlimited number of new modules in the PARTONS architecture, without having to modify existing modules. There are many types of modules, but one may configure all of them, i. e. pass additional information to the modules, in a generic way, avoiding, for instance, the static casting. This is possible thanks to the void configure(const ElemUtils::Parameters& parameters) virtual functions, which developers may use to allow transferring additional parameters to modules.
For instance: where "myKey" is the unique name of the parameter. The way of supplying modules with additional parameters pre-sented here plays a crucial role in constructing the user interface (UI). To avoid "manually" repeating some tasks, the services are used. In this way, users can perform complex tasks in a straightforward and robust manner by hiding the complexity of low-level functions. The services link such tasks as parsing input files, running many computations, employing multithreading computing, filling the database, printing the output to the screen etc. Without services, all those tasks would have to be done explicitly by users, requiring a profound knowledge of the functioning of the project. This way of working would also be time consuming and vulnerable to mistakes.
EpIC's architecture The generic architecture of the generator, including the flow of data transferred between the modules, is shown in Fig. 2. Each module takes input data, processes it according to predefined tasks, and returns the corresponding output. The actual implementation of some types of modules depends on the simulated process. For instance, RCModule is the parent class for DVCSRCModule and TCSRCModule, which are used for DVCS and TCS processes, respectively. These two types of modules process data according to the same task predefined in RCModule, but they use different inputs. It is either DVCS or TCS kinematics. Because of this difference, RCModule has been developed as a C++ template, allowing DVCSRCModule and TCSRCModule to handle input containers of various types. With those templates, the addition of new processes to the generator is as easy as possible.
DVCSRCModule and TCSRCModule are used as base classes for actual modules, where specific physics developments are encoded. In Fig. 3  we present the entire tree of inheritance for modules of RCModule type. Below, we provide a brief description of each type of module and its purpose. Additionally, we indicate whether the actual implementation of modules of a given type depends on the simulated process. This information is useful in recognising which parts of the generator need to be extended when a new process is added to the generator.
RCModule Purpose: Simulation of radiative corrections. Does it depend on the generated process? Yes. Description: In EpIC, events are generated according to the probability distribution given by: dσ (X , Z ) = dσ 0 (X ) R(Z ). ( Here, dσ 0 (X ) is the Born cross-section (given by PAR-TONS), while R(Z ) is the radiator function. The set of vari- ables that the Born cross-section depends on is denoted by X , for instance X = {x Bj , t, Q 2 , φ, φ S , E l } for DVCS, where x Bj and Q 2 are the usual DIS variables, φ is the angle between the lepton scattering plane and the production plane, φ S is the angle between the lepton scattering plane and the target spin component perpendicular to the direction of the virtual photon, and E l is the lepton energy in the fixed target frame, which is the reference frame for the evaluation of cross-section in PARTONS  [21].
Because of the radiative corrections, the values of those variables may be different from those for a generated event, X. The radiator function, on the other hand, depends on the set of variables Z. The number of variables making this set depends on the approximation one uses. For instance, if one considers the collinear approximation and only the initial and final state radiations of single photons from the incoming and scattered leptons, two variables make the set Z , namely Z = {z 1 , z 3 }, see Appendix A for more details. Taking the above into account, modules of type RCModule perform three actions: (i) they define a number of variables that the radiative corrections depend on, i. e. they define the set Z , (ii) they implement a function used for the evaluation of R(Z ), but also for the evaluation of the "true" kinematics entering the Born cross-section, X = f (X , Z ), (iii) they implement a function that stores the four-momenta of radiated photons in the final event records.
ProcessModule Purpose: Evaluation of Born cross-section. Does it depend on the generated process? Yes. Description: The Born cross-section is evaluated in EpIC using the modules of ProcessModule type, which are defined in the PARTONS library. In the most general case, when the Born cross-section is calculated directly from GPDs, the ProcessModule relies upon other modules: ConvolCoeffFunctionModule for the evaluation of the process amplitudes, GPDModule for the evaluation of GPDs at a reference scale, GPDEvolutionModule for the evolution of GPDs, XiConverterModule for the evaluation of the GPD skewness variable, ξ , from the process kinematics, and ScalesModule for the evaluation of the renormalisation and factorisation scales from the process kinematics. However, this general case can hardly be used in the Monte Carlo generation, because of the nested integrations evaluating the Born cross-section.
KinematicModule Purpose: Evaluation of four-momenta for a given kinematic configuration. Does it depend on the generated process? Yes. Description: Modules of this type are responsible for the evaluation of four-momenta for a given kinematic configuration. In addition, they implement a predefined function that determines if a given kinematic configuration is physical, i. e. if it does not break any kinematic limit. This function is utilised by GeneratorModule to probe only valid kinematics.
User interface Both compilation and linking of the project make use of the CMake tool  [34]. In the current version (1. 0. 0) EpIC requires the following external libraries: PARTONS  [21]  (providing elements of the architecture and used for the evaluation of Born cross-sections), ROOT  [35]  (used in one of the EventGeneratorModule modules), HepMC3  [36]  (used in one of the WriterModule modules), GSL  [37]  (used for the generation of random numbers). For more detailed and always up-to-date information we refer to the online documentation  [24]. The executable of the project, epic, must be invoked with two arguments, like this:. /epic --seed=SEED --scenario=SCENARIO_PATH where SEED is the random seed (unsigned integer) to be used in the initialisation of modules that deal with random numbers, and SCENARIO_PATH is the relative or absolute path to the scenario containing all options used in the generation.
The EpIC scenarios are written in XML markup language which, thanks to the usage of tags based on standard words, is an easy-to-read format for humans while being straightforward for machines to process. EpIC assumes input data to be provided in units of GeV (and its powers, whenever applicable), and radians for angles. The general structure of a single scenario is the following: <!--XML header --> <?xml version="1. 0" encoding="UTF-8" standalone="yes" ?>.
EpIC performance In the following, we demonstrate the detailed performance of EpIC by using specific components of the PARTONS framework. The demonstration is based on one million MC events generated for the DVCS sub-process, i. e. exclusive leptoproduction of a single photon without the Bethe-Heitler contribution, colliding a 10 GeV positive helicity electron with a 100 GeV unpolarized proton. The following modules are used during the generation process: DVCSCFFCMILOU3DTables for the parameterisation of the Compton Form Factors (CFFs) obtained from the GK GPD model  [31] [32] [33]  and LO coefficient functions, DVCSProcessBMJ12 for the evaluation of the DVCS cross-section based on the set of expressions published in Ref. [39] , DVCSRCNull for the simulation without radiative corrections, EventGeneratorFOAM for the generation of DVCS kinematics based on a cross-section with the FOAM algorithm  [40] , DVCSKinematicDefault for the default evaluation of the four-momenta of the DVCS kinematics, and WriterHepMC3 to save the four-momenta in the HepMC3 format.
Summary In this work, we described in detail the overall structure and essential features of the novel MC generator EpIC. This generator is based on the PARTONS framework in the model selection. It is designed to generate events for exclusive processes, such as DVCS, TCS, DVMP and more broadly for all exclusive processes implemented in the PARTONS framework. As these processes have the potential to reveal the 3D structure of the nucleon through GPDs, they have been studied extensively at facilities such as DESY, JLab, and CERN, and they will remain crucial for future EIC programmes. The EpIC MC generator stands out with its flexible architecture that utilises a modular programming paradigm. Consequently, the code is easier to understand, as each element of the architecture is designed to perform a specific task.
Acknowledgements The authors thank  Alexander Jentsch ,  Krešimir Kumerički , and  Kornelija Passek-Kumerički  for fruitful discussions. This work was supported by the Grant No. 2019/35/D/ST2/00272  of the  National Science Centre, Poland ; by the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No. 824093 ; in the framework of the  GLUODYNAMICS  project funded by the " P2IO LabEx  ( ANR-10-LABX-0038 )" in the framework " Investissements d'Avenir"  ( ANR-11-IDEX-0003-01 ) managed by the  Agence Nationale de la Recherche (ANR) , France; by the  Ile-de-France region via the Blaise Pascal Chair of International Excellence. KT was supported by  U. S. Department of Energy  under the Contract No. de-sc0012704.
Results and Discussion As a reference, Figure  4  shows a measurement with glued electrodes. Data were taken via the serial monitor while the Arduino was attached to a laptop via a docking station, i. e. , connected with the grid, in this case working at 50 Hz. At first glance, Figure  4a  shows a noisy measurement with several spikes. Zooming in, Figure  4b  reveals that the noise is a 50 Hz interference from the power grid. Apparently, the common-mode rejection-which is used to reduce mains hum-is not sufficient if the Arduino is coupled in the way described here. Further reduction of the 50 Hz noise was performed by a 45-55 Hz bandblock FFT filter applied in Origin 2021 (OriginLab, Northampton, MA, USA). Afterward, a clear ECG signal was visible, with the "spikes" depicting the QRS complexes due to the rapid depolarization of the left and right ventricles (the lower heart chambers), the small P-waves before the QRS complexes.