dataesr/scientific-paragraphs-categorization huggingface dataset:
To quantify water-rock interactions and forecast their spatiotemporal evolution in the shallow aquifer of Sidi El Hani located in central-eastern Tunisia, the numerical code KIRMAT was used. Based on available geological, mineralogical, thermodynamic, kinetic and hydrodynamic data, the model was built and calibrated on two transects of the aquifer oriented along the flow lines of groundwater. The numerical results show that the interactions between water and rock are responsible for groundwater salinity, which is strongly dominated by chlorides, sodium and sulphates. The variations of dissolved species in space and time are the result of halite dissolution, anhydrite and gypsum dissolution and precipitation, calcite dissolution and dolomite precipitation. The precipitation of dolomite can locally induce a reduction in permeability and further enhance an increase in leaching because the residence time between rock and water will be amplified.
Description of the numerical model KIRMAT The hydrochemical model developed in this study is based on the numerical code KIRMAT (KInetic Reaction and Mass Transport)  (Gerard, 1996) , which combines geochemical reactions and 1D mass transport equations. KIRMAT was developed from the thermokinetic section of the geochemical code KINDIS by integration of the reaction terms in an advectivedispersive scheme of mass transport in a saturated porous medium  (Madé, 1994). The purpose of KIRMAT is to contribute to the understanding of groundwater salinization  (Lucas et al. , 2010) , weathering processes  (Lucas et al, 2017; Ackerer et al. , 2018)  and hydrothermal alteration  (Ngo et al. , 2016). It can also be used to simulate the fate of clay minerals under specific environmental conditions, such as the storage of nuclear waste  (Montes et al.
Finally, the dynamic system is discretized over a time step Δt until the time t+Δt, which is equal to the simulation time requested by the user. A self-adjusting numerical time step was used during the simulations. Furthermore, the KIRMAT code can also describe the feedback effect of the chemical and mineralogical evolution of the permeability at any node of the mesh due to the dissolution and precipitation reaction, which can modify the pore geometry  (Laabidi and Bouhlila, 2015). The intrinsic permeability k (m 2 ) is updated after each time step as follows  (Gerard, 1996) : Z = 6 [ [ ϕ \ ] ^ ]$ _ ] `, (8) where C0, c, ϕ and S denote the cementing factor, an experimental constant, and the porosity of the porous medium and the grid cell surface in contact with the adjacent cell (m 2 ), respectively.
Thermodynamic and kinetic parameters The thermodynamic parameters of the minerals used in our numerical studies, at a temperature of 25°C, are summarized in Table  4  for six primary minerals and one secondary mineral. (Gérard et al. , 1998)  Note that kinetic data are less available in the literature than thermodynamic data, mainly for the precipitation of reactive minerals. Considering Equation 7, the dissolution rates of primary or secondary minerals were determined from data sets proposed by  Palandari and Kharaka (2004) , which are based on kinetic values at 25°C and an activation energy term (Table  5 ). To model dissolution kinetics at any temperature, KIRMAT code uses the following expression for mineral dissolution controlled by surface reactions  (Madé et al. , 1994) : l m,? = n o pqq 1 - r L s L t u u u v Z `w xy?m exp } ~• €bL• ‚ ƒ -`"….
The rock-water interactions and mass transport along two transects of the aquifer were simulated using the numerical hydrogeological code KIRMAT. The calibrated reactive transport model underscores the observation along the two transects: the concentrations of dissolved species such as chlorides, sodium, sulphates and calcium are highly increased from the middle of each transect compared to the concentrations at the inflow edge. However, in accordance with the field data, the calculated concentrations of magnesium decrease along the flow path. These changes are clearly the result of the waterrock interaction expressed by dissolution and precipitation. One may conclude that the groundwater composition along the first 3 km of each transect is more specifically controlled by the dissolution of halite, anhydrite, gypsum, calcite and dolomite.
Short GRACE data gaps are ignored when computing the monthly means of the AOD products, assuming that users in general do not thin out their observation database according to the availability of the GRACE observation data either. EGSIEM-combined L2 and L3 products can be downloaded from the "Data" section of the EGSIEM homepage. 6 Furthermore, mass variations derived from individual timeseries as well as from the combined gravity fields can be visualized by the EGSIEM plotter. 7  The prototype combination service continues after the completion of the EGSIEM project in the frame of the Combination Service for Time-variable Gravity field models (COST-G) as a product center of the International Gravity Field Service (IGFS) under the umbrella of the International Association of Geodesy (IAG).
The intrinsic weights of the individual NEQs are removed by a robust empirical procedure balancing the impact of the individual NEQs on the pairwise combinations. Combined gravity fields were computed from three or four ACs for the time span between 2004 and 2010. An independent evaluation of the noise levels indicates that the quality of the best individual contribution (ITSG) is achieved or even topped by the combinations in 90% of the monthly solutions. Outliers can be identified with data problems. Compared to the official GRACE SDS monthly gravity fields, the anomalies of the EGSIEM combinations that are derived to assess the noise level are smaller. The original goal to provide consistent, reliable and validated gravity fields therefore is met. The noise level differences of the individual time-series are striking.
With a more homogeneous quality of the input series, the combinations should improve substantially as well. First, experiments with the new GRACE SDS RL06 time-series indicate a big step forward in this direction. With the availability of the new GRACE L1B-RL03 observational data and the SDS RL06 gravity fields, now a final combination of all GRACE time-series becomes feasible. The EGSIEM initiative for gravity field combination is continuing with COST-G under the umbrella of the IAG. Since it cannot be expected that the GRACE SDS ACs will reprocess the whole GRACE time-series to be in accordance with the EGSIEM standards, the COST-G standards will be adapted to only specify the signal content of the monthly gravity fields which should include nontidal oceanographic, hydrological, glaciological and GIA signal to the full extent.
28 and 2. 31 µm, • The differential phase (φ diff ) which is related to the photocenter displacement at the first order  (Jankov et al. 2001 ) informs us about the asymmetry as well as the kinematic behavior of the observed upper and outer stellar layers (photosphere, MOLsphere, CSE. etc. ), • And the closure phase (Ψ) which is the sum of all the φ diff of each baseline. For a point-symmetric objects its value is always equal to zero or π. Ψ = 0 and Ψ = π means  that the object is asymmetric but the inverse is not always true. Unresolved or partially resolved object has a Ψ = 0 for example. Our AMBER data have been reduced using version 3. 0. 9 of the amdlib 2  software  (Chelli et al. 2009; Tatulli et al. 2007 ). We adopted a standard frame selection based on fringe (S/N) signal-to-noise  (Millour et al.
MODELING OF THE AMBER DATA To interpret the AMBER observations of our sample of evolved stars, we used a spectrointerferometric multilayer MOLsphere model (described below, in Sec. 4. 2), which surrounds a photosphere with Center-to-Limb intensity Variations (CLV) profiles at each wavelength that we computed by Turbospectrum software  (Alvarez & Plez 1998; Plez 2012) , from MARCS stellar atmosphere models  (Gustafsson et al. 2008)  over the observed wavelength range using the CO line list of  Goorvitch (1994). Each MARCS model 6  is specified by some stellar parameters that we should determine beforehand, namely : the effective temperature (T eff ), surface gravity (log g), micro-turbulent velocity (vmicro), chemical composition, and stellar mass (M ). The next subsection precisely describes the determination of these parameters.
B1 (appendix B). We selected stellar atmosphere models with parameters (detailed in MARCS model part of Tab. B1) as close as possible to those available from the spherical MARCS models. The chemical composition (moderately CN-cycled or heavily CN-cycled) are determined thank to 12 CO/ 13 CO ratio. Note that although asymmetries in the CO-line-forming region are clearly detected from φ diff of some stars (as for W Hya for example), we only use a spherical model as a first approximation. Over each CLV's MARCS model of each star of our sample, we add a MOLsphere thanks to a multilayer model which is described in detail in the next subsection (Sec. 4. 2). Using temperature and pressure distributions of the downloaded MARCS model  (Gustafsson et al. 2008)  with the cited parameters in Tab. B1 (appendix B), we compute the corresponding monochromatic intensity profile and then spectrum (as described in Ohnaka 2013), but this time, using Turbospectrum software  (Alvarez & Plez 1998; Plez 2012 ).
Multi-layer MOLsphere model; PAMPERO First modeling of a star surrounded by a MOLsphere was done by  Perrin et al. (2004)  on FLUOR/IOTA data of Betelgeuse (α Orionis) and Rasalgethi (α Herculis), as black-bodies, with five free parameters, namely: The stellar angular diameter / , MOLsphere angular diameter (as one layer) / layer , stellar temperature T = T eff , MOLsphere temperature T layer and optical depths τK, τL, τ11. 15µm at K, L and 11. 15µm bands respectively. Ohnaka et al. (2009 Ohnaka et al. ( , 2011 Ohnaka et al. ( , 2012)) ; Ohnaka (2013) used a more sophisticated model, thanks to MARCS models, for several different kinds of evolved stars by AMBER/VLTI on K band, where the optical depth is deduced from the column density and temperature of specific molecules (e. g. CO) over one to two MOLsphere layers.
And recently  Montargès et al. (2014)  mixed both approaches using K band AMBER/VLTI data of Betelgeuse for two molecules (CO and H2O) but with the stellar atmosphere grids of ATLAS 9  (Castelli & Kurucz 2003; Kurucz 2005). The approach that we adopt here in this paper is the same that of  Ohnaka (2013) , with stellar atmosphere grids of MARCS, using K band AMBER/VLTI data, for the CO molecule, but with continuous multilayer MOLsphere (with a path of 0. 1R ), in order to study the temperature and molecular density distributions of the different MOLspheres of our sample. We have titled our model/code PAMPERO for Physical Approach of Molecular Photospheric Ejection at highangular-Resolution for evOlved-stars. This code, which is written in Matlab 7 , computes first the stellar CLVs thanks to the preselected MARCS models (Tab.
6 -10 17. 22 mol/cm -2 ). We attribute this large difference in density, for BK Vir, to the fact that the discontinuous two-layers do not take into account the effect of a continuous MOLsphere which may overestimate the temperaturedensity parameters of a large MOLsphere area when using a single thin layer. Axial symmetry is not usual for normal K-M giant stars. We observe axisymmetrical CSEs, in general, on post-AGB stars and planetary nebulae  (Dijkstra & Speck 2006) , whereas most AGB stars shows spherically symmetric en-velopes (especially O-rich stars  Cruzalèbes et al. 2015). Famaey et al. (2009)  suspected, thanks to a Hipparcos radial velocity study of a sample of M giants, that SW Vir can be a binary system. Niyogi et al. (2011)  used Gemini/MICHELLE IR data of SW Vir and deduced recently, from the spectra, an axisymmetric dust shell which can not be attributed to a simple radial temperature variation.
ACKNOWLEDGEMENTS This research made use of the SIMBAD database, operated at the  CDS, Strasbourg, France , and of the  NASA Astrophysics Data System Abstract Service. The author,  M. Hadjara , acknowledges support from the scientific French association PSTJ 10 for its official host agreement, the  Lagrange  and  OCA  for computer server support. This research made use of the  Jean-Marie Mariotti Center SearchCal service 11.
Implementation details Kendrick is implemented on top of the Pharo  [24]  programming environment using the Moose meta-modelling platform  [25]. The numerical analysis back-end is based on the PolyMath framework  [26]  while the visualisation sub-system relies on Roassal  [27, 28]  and the UI components on GT Tools and the Moldable Inspector  [29]. In addition to that, the DSL extensively relies on Pharo's reflective sub-system  [30] , with extensions based on the PetitParser  [31]  framework and on the Helvetia parsing workbench  [32]. Kendrick supports all major desktop platforms (Gnu/Linux, MacOS and MS Windows) and adopts an open continuous integration process (based on github 1  and Travis CI 2 ). It has been extensively tested using the SUnit  [33]  framework, readily available through a dedicated website 3 and well documented through a collaborative wiki 4.
Installing & running Kendrick The easiest way to install Kendrick is to download a precompiled bundle for your platform from Github 5. After unzipping the corresponding compressed archive file, simply run one of the Kendrick launchers (KendrickUI for Mac and Linux, or KendrickWinLauncher for Windows). Alternatively, a very straight-forward method to compile Kendrick from sources is provided on all systems with a bash command-line (including Linux, Mac and Windows with Cygwin and/or the Windows 10 Bash subsystem), by issuing the following command: wget -Oh t t p s : / / goo. g l /WUQxmp | bash This command will automatically retrieve all the required dependencies, compile Kendrick from sources and set up all the execution scripts for normal or development use. Kendrick can be used in three different modes.
First, the UI mode relies on a specific IDE to edit and run Kendrick models. This UI follows the Cascading Lists 6 pattern of navigation: each selection reveals a new column of actionable information (on the right), with a horizontal bar on the bottom that controls the position and size of the viewport. This mode is launched by invoking the following command. / KendrickUI Second, Kendrick can be used from the command-line. Kendrick models are edited using any source code editor and stored in the Sources directory of the Kendrick installation, along with all the other models. A model is run using the following command and the results are then stored in the Output directory. / Kendrick myModel. k e n d r i c k Third, an advanced UI mode is available where Kendrick is run with the full development environment (allowing to use both the DSL and the Pharo API of Kendrick).
Batch analysis & integration with external tools In order to support batch exploration of epidemiological models (for sensitivity analysis for example), epidemiological experiments can be defined with different parameter values to explore a grid of the parameter space. These experiments can be defined using either (a) the dedicated Experiment entity in Kendrick Projects (as shown in the code-snippet below and in Fig. 5 ) or (b) command-line arguments. In both cases, the results of the experiments can be analysed by third-party software. In the case of the commandline experiments, the set-up allows Kendrick to be driven by and integrated with platforms such as R 9 or Open-Mole 10 for further analysis. An experiment, PopRateAnalysis is defined on the Measles model using the MeaslesDiagramViz visualization as an output template (lines 1-3).
A series of parameter intervals of the form [min, max] @ step are then introduced (lines 4-7). populationSize will thus get 2 values: 100000 and 150000, while the initial infected population as well as γ and β will get 3 values each. Finally, line 8 runs the experiment. Kendrick runs a simulation for each of the 54 (2x3x3x3) combinations. The results can then be explored and analysed as seen Fig. 5. The results are also exported automatically in the Output folder of the project for further analysis with external tools. Model fitting to observed data is possible by running a Kendrick model from the command line. An example is given on our development website 11 where a complete Kendrick model is built in Matlab/Octave 12. The space of the possible parameter values is then explored, driven by a minimization function written in Octave.
Discussion Although DSLs have been used before in the context of bioinformatics  [36] [37] [38] , only a small number of them focused on epidemiological modelling  [39, 40]. For example, Ronald  [39]  is a DSL for studying the interactions between malaria infections and drug treatments, but has unfortunately been discontinued. Schneider and al. [40]  have also proposed a DSL for epidemics, but their solution only support agent-based models. Mathematical modelling languages (MMLs) such as Scilab  [35] , Modelica  [41] , Matlab  [42]  or JSim  [43]  do allow easier definition of mathematical models as sets of ODEs, but are too broad in scope to properly cover the domain-specific needs of epidemiology. On the other hand, individual libraries targeting epidemiological modelling, such as Epipy -a visualisation data tool for epidemiology written in Python  [44] , or Gille-spieSSA -an R package for generating stochastic simulation using Gillespie's algorithms  [45] , cover only specific epidemiological needs.
Currently, our platform has nevertheless several limitations. At the moment, we only support deterministic, stochastic and individual-based simulations. More high-resolution models like agent-based simulation where agents can have complex behaviours or contact-networks will be defined in the future. Spatial-based models based on partial differential equations (PDE) are also beyond the scope of this paper. Furthermore, there is also an inherent trade-off in our pervasive use of a DSL, especially regarding simulations. While we do allow for the configuration of basic simulation parameters, there is currently no way to adapt simulations in more elaborate ways, without getting back to development in the host language (Pharo in our case). This is an acceptable limitation for a DSL in general, which aims to be user-friendly and re-usable, forfeiting the.
Acknowledgements This work was supported by  Alexandre Bergel  ( Chile University ) and his team Object Profile (http://objectprofile. com/ObjectProfile. html)with the visualisation tool ROASSAL. We would like to acknowledge the financial support from  Agence Nationale de la Recherche (ANR)   PANIC  project and  European Smalltalk User Group (ESUG). We also gratefully acknowledge the financial support from  Hanoi University of Science and Technology  through.
Availability and requirements Project name: KENDRICK Project home page: http://ummisco. github. io/kendrick/ Operating System: multi-platform (Linux/MacOS/Windows) Programming environment: Pharo 6. 1: http://www. pharo. org/ Programming language: Smalltalk Requirements: All the required tools for the installation of KENDRICK are described on the project home page License: MIT License Any restrictions to use by non-academics: no restrictions Availability of data and materials Not applicable.
The aim of this work is to present the architecture of the KardiaSoft software, a clinical decision support tool allowing the healthcare professionals to monitor patients with heart failure by providing useful information and suggestions in terms of the estimation of the presence of heart failure (heart failure diagnosis), stratification-patient profiling, long term patient condition evaluation and therapy response monitoring. KardiaSoft is based on predictive modeling techniques that analyze data that correspond to four saliva biomarkers, measured by a point-of-care device, along with other patient's data. The KardiaSoft is designed based on the results of a user requirements elicitation process. A small clinical scale study with 135 subjects and an early clinical study with 90 subjects will take place in order to build and validate the predictive models, respectively.
An extended review of these studies along with a qualitative and quantitative comparison of them is presented in  [5]. In the majority of the studies biomarkers extracted from blood, such as NT-proBNP and troponin, contribute significantly towards the HF diagnosis and prognosis. The transformation of the diagnostic and prognostic models, developed in the abovementioned studies, to decision support software tools has been achieved within the implementation of EU funded research projects like SensorArt [6], SmartTool [7], HeartMan [8] and HEARTEN  [9]. The most recent studies have revealed the strong correlation of saliva biomarkers with HF severity, progression and mortality through statistical analysis methods, as well as methods developing computational models  [9 -11]. Hart et al. [12]  point out several advantages in using saliva instead of blood.
The sign "+" in the FURPS+ model refers to constraints (design, implementation, interface and physical). Architecture design. For the documentation of the software architecture the Software Engineering Institute's (SEI) approach, called Views and Beyond or V&B  [15] , was followed. In this way the software architecture is also compliant to the ISO/IEC/IEEE 42010:2011 standard. As shown in Fig. 1 , the KardaSoft is composed of six distinct modules as follows: (i) the Patient Data Management (PDM) module, (ii) the Patient Information Visualization (PIV) module, (iii) the Clinical Decision Support Segment (CDSS) module, (iv) the Authentication module, (v) the Administration module and (vi) the KardiaSoft Graphical User Interface (KGUI). The Fast Healthcare Interoperability Resources (FHIR)  [16]  standard is followed in order to ensure the linking of the KardiaSoft to hospital/laboratory information systems.
B. Patient Information Visualization (PIV) The PIV module offers a visualization of the patient information in different ways: single or multiple patients view. Single patient view allows the user to monitor the progress of the patient's health (through specific measurements) along different time periods (through the Single Patient Information Visualization submodule), while the multiple patients view allows the comparison of different patients or patient groups (through the Multiple Patient Information submodule). In this way the user (i. e. the doctor) can have a very good view of patient measurements and their progress. Additionally, pre-defined shareable reports can be produced (using the Patient report creation submodule) summarizing patient measurements. Reports are also stored in the cloud database.
C. Clinical Decision Support Segment (CDSS) The CDSS module is responsible for processing relevant data and providing decision support for estimation of the presence of HF (HF diagnosis), stratification/patient profiling, long term patient condition evaluation and therapy response monitoring. According to the selected type of the decision support, the Inference Engine (and more specifically its model runner engine) loads the relevant model from the Model repository along with the relevant data from the cloud database. For the latter functionality, a query engine retrieves the data from the cloud database and passes it to the Information processing submodule which is responsible for data calculation and representations (according also to experts/clinical knowledge existing in the Knowledge Base).