dataesr/scientific-paragraphs-categorization huggingface dataset:
Molecular dynamics simulations of human isoforms. The 3D coordinates of the human JNK1 isoforms JNK1α (369 res. , containing exon 6 ), JNK1β (369 res. , containing exon 7 ) and JNK1δ (304 res. , containing neither exon 6 nor exon 7 ) were predicted by PhyloSofS pipeline. The 3 systems were prepared with the LEAP module of AMBER 12  14  , using the ff12SB forcefield parameter set: (i) hydrogen atoms were added, (ii) the protein was hydrated with a cuboid box of explicit TIP3P water molecules with a buffering distance up to 10 Å, (iii) Na + and Cl -counter-ions were added to neutralize the protein. The systems were minimized, thermalized and equilibrated using the SANDER module of AMBER 12. The following minimization procedure was applied: (i) 10,000 steps of minimization of the water molecules keeping protein atoms fixed, (ii) 10,000 steps of minimization keeping only protein backbone fixed to allow protein side chains to relax, (iii) 10,000 steps of minimization without any constraint on the system.
Heating of the system to the target temperature of 310 K was performed at constant volume using the Berendsen thermostat 6 and while restraining the solute C α atoms with a force constant of 10 kcal/mol/ Å2. Thereafter, the system was equilibrated for 100 ps at constant volume (NVT) and for further 100 ps using a Langevin piston (NPT)  45  to maintain the pressure. Finally the restraints were removed and the system was equilibrated for a final 100 ps run. Each system was simulated during 250 ns (5 replicates of 50 ns, starting from different initial velocities) in the NPT ensemble using the PMEMD module of AMBER 12. The temperature was kept at 310 K and pressure at 1 bar using the Langevin piston coupling algorithm. The SHAKE algorithm was used to freeze bonds involving hydrogen atoms, allowing for an integration time step of 2.
0 fs. The Particle Mesh Ewald (PME) method  18  was employed to treat long-range electrostatics. The coordinates of the system were written every ps. Standard analyses of the MD trajectories were performed with the ptraj module of AMBER 12. The calculation of the root mean square deviation (RMSD) over all atoms indicated that it took between 5 and 20 ns for the systems to relax. Consequently, the last 30 ns of each replicate were retained for further analysis, totaling 150 000 snapshots for each system. The fluctuations of the C-α atoms were recorded along each replicate. For each residue or each system, we report the value averaged over the 5 replicates and the standard deviation (see Fig. 4a ). The secondary structures were assigned by DSSP algorithm over the whole conformational ensembles.
RNA-Seq Data integration To obtain additional support for transcript isoform expression, we queried the Bgee database (v. 14) 4 for a list of all RNA-Seq experiments related to the selected species. Using SRA tools, we downloaded raw sequences from H. sapiens (224 samples), M. musculus (155 samples), Xenopus tropicalis (69 samples) and D. rerio (67 samples) and then aligned the reads using STAR v. 2. 5. 3a 20 with default parameters. T. rubripes is not annotated in Bgee and was not integrated in this part of the analysis. Reads overlapping exon-exon boundaries (e. g. splice-junction reads) next to alternative splicing events provide direct evidence for the expression of specific transcripts isoforms. Combined with sample annotation, they could also inform on tissue specific isoform expression.
(a) search for homologous sequences and building of a multiple sequence alignment (MSA), by using HHblits 55 , (b) addition of secondary structure predictions, obtained by PSIPRED 34 , to the MSA, (c) generation of a profile hidden markov model (HMM) from the MSA, (d) search of a database of profile HMMs for homologous proteins, using HHsearch 63. Step 3 is performed by Modeller 47 with default options. Step 5 consists in: (a) inserting the numbers of the exons in the β-factor column of the PDB file of the 3D model, (b) computing the proportion of residues predicted in well-defined secondary structures by PSIPRED 34 , (c) assessing the quality of the model with Procheck 42 and with the normalized DOPE score from Modeller, (d) determining the by-residue solvent accessible surface areas with Naccess 31 and computing the proportions of surface residues and of hydrophobic surface residues.
Pauline Traynard 1,*, † , Géraldine Ayral 1, † , Monika Twarogowska 1 and Jonathan Chauvin  1  MonolixSuite is a software widely used for model-based drug development. It contains interconnected applications for data visualization, noncompartmental analysis, nonlinear mixed effect modeling, and clinical trial simulations. Its main assets are ease of use via an interactive graphical interface, computation speed, and efficient parameter estimation even for complex models. This tutorial presents a step-by-step pharmacokinetic (PK) modeling workflow using MonolixSuite, including how to visualize the data, set up a population PK model, estimate parameters, and diagnose and improve the model incrementally. Drug development is increasingly supported by mathematical models that allow one to better understand the drug's behavior and to optimize the next development steps, for example, during clinical trials.
Together with the measurement error model (also called residual error), this constitutes the statistical part of the NLME model. The NLME framework is a rigorous environment to model and simulate different types of data, but it requires (i) efficient algorithms to fit possibly complex models to large data sets and (ii) a user-friendly way to define and interpret the models. Monolix (Lixoft, Antony, France) was developed after a 7-year research program to meet both requirements. It incorporates many innovations, such as the stochastic approximation expectation-maximization (SAEM) estimation algorithm  1  and its extension to censored data, 2 numerous diagnostic tools,  3  and automatic model-building procedures. The combination of quick and efficient algorithms with a clear and interactive interface leads to a particularly fast learning curve for the user.
Monolix is now part of MonolixSuite-a set of interconnected software applications that covers all stages of drug development. These applications help in data visualization (Datxplore), noncompartmental analysis of the data (PKanalix), NLME model development and parameter estimation (Monolix), simulations of new situations (Simulx), and workflow management (Sycomore). Moreover, MonolixSuite satisfies regulatory requirements and it has been routinely and successfully used for regulatory submissions. The aim of this tutorial is to show step-by-step a modeling workflow using MonolixSuite on a typical PK data set. We assume that the reader has no familiarity with the software, but we recommend basic knowledge of population PK/PD modeling. For a didactic and comprehensive introduction to this topic, we refer the reader to previous tutorials presented in this journal.
OUTLINE This tutorial is structured in four sections. We first give a brief introduction of the software applications of MonolixSuite. Then we show step by step how to develop a model on a typical PK data set. This includes the structural model definition, its diagnosis, and a covariate search. More advanced features, not directly used in this tutorial, are also briefly reviewed. All the material necessary to reproduce the results from this tutorial is available as Supplementary Material: data set, step-by-step instructions with numerous screenshots, all Monolix runs and the Sycomore project, as well as a video showing the main modeling steps.
Monolix Monolix is dedicated to NLME modeling. Its graphical user interface, large library of built-in models, and robust and fast parameter estimation make it an easy to use and efficient application. Moreover, it includes automated generation of diagnostic plots, statistical tests to guide the model development, and automatic model-building procedures. Monolix also comes with an R API (http://monol ix. lixoft. com/monol ix-api/) and thus can be used via R scripts. In addition, the R package Rsmlx (R Speaks Monolix; http:// rsmlx. webpo pix. org) provides further methods for model building and evaluation, such as bootstrap and likelihood profiling.
Data set visualization with Datxplore As a first step of this tutorial, Datxplore is used to display a graphical representation of the data set. After opening Datxplore, the data set must first be loaded (menu: Project > New > Browse). The data set table is displayed in the interface and drop-down menus allow to tag each column from a predefined set of column types. Columns with standard header names are automatically tagged. In this example, it is the case for the following columns: ID tagged as ID, TIME as TIME, AMT as AMOUNT, RATE as INFUSION RATE, DV as OBSERVATION, AGE as CONTINUOUS COVARIATE, and SEX as CATEGORICAL COVARIATE. The LBM and TINFCAT (infusion duration) columns can be manually tagged as CONTINUOUS COVARIATE and CATEGORICAL COVARIATE, respectively. MonolixSuite allows the user to specify and save (menu: Settings > Preferences) data set header names that should be automatically associated with given column types.
The subplots on the diagonal show the distribution of each covariate. The off-diagonal subplots are useful to identify correlations between covariates, such as between LBM and AGE, and LBM and SEX. Upon saving the Datxplore project, all settings, preferences, and stratifications options are stored and can be retrieved by loading the saved. datxplore file into Datxplore. In summary, the data exploration in Datxplore has revealed the following insights: • A model with several compartments is probably necessary to describe this data set. • LBM might influence the PK. • LBM and AGE are negatively correlated, and males have higher LBM values than females. These insights will guide the model-building process detailed in the next sections.
Model development and diagnosis using Monolix Monolix run setup. The Monolix interface is organized in successive tabs that guide the user to define a run. Definition of the data. The Datxplore project can be directly exported into Monolix with "Export > Export to Monolix. " This opens Monolix and transfers the data set information (i. e. , path to data set file and column tagging) from Datxplore to Monolix. Clicking on "Next" leads the user to the next Monolix tab "Structural model. " Alternatively, the user could open Monolix, start a new project, load the data set, and tag the column as described for Datxplore. For data visualization, it is also possible to open Datxplore from Monolix using the "Data Viewer" button. Definition of the structural model. In Monolix, the structural model is defined in a separate text file.
It is possible to write a new model file from scratch or pick a model file from the wide collection of predefined models, which are available in the following seven model libraries: PK, PD, joint PKPD, PK with double absorptions (with any combination of absorption types), target-mediated drug disposition, time-to-event, and count models. Each library can be easily browsed using filters. For this tutorial data set, a two-compartment model is chosen as a first try because data visualization in Datxplore suggested a model with several compartments. This model is available under the name infusion_2cpt_ClV1QV2. txt in the Monolix PK library via "Load from library" and selecting the following filters: "infusion," "2 compartments," and "linear elimination. " Once the model is selected, it is displayed within the interface in the tab "Structural model": [LONGITUDINAL] input = {Cl, V1, Q, V2} EQUATION: ; Parameter transformations V = V1 k = Cl/V1 k12 = Q/V1 k21 = Q/V2 ; PK model definition Cc = pkmodel(V, k, k12, k21) OUTPUT: output = Cc Library and user-defined models are written using the Mlxtran language, which has been developed to ease the definition of pharmacometric models.
This Mlxtran dedicated editor allows to check the model consistency by clicking on the button "compile. " Syntax errors prompt clear messages to help the user identify the mistakes. A comprehensive documentation of the Mlxtran language with numerous examples is available online (http:// mlxtr an. lixoft. com/). When a model contains several outputs, the mapping panel on the right-hand side of the "structural model" tab allows to flexibly map the model outputs to the several observation types present in the data set. Finally, it has to be noted that the model file contains only the structural model. The statistical part of the model, which includes the error model and parameter distributions, is defined via the interface at next steps. Moreover, the likelihood objective function is always inferred by Monolix automatically, for any type of data (continuous, time to event, count, categorical, and any combination of those).
In Monolix, they are determined via the calculation of the Fisher Information Matrix. To calculate the standard errors using bootstrap instead, a function is provided in the R package Rsmlx (for "R speaks Monolix") to generate case-resampled data sets and run Monolix on each. When clicking on the task "standard errors" (link to docum entation), the Fisher Information Matrix is calculated either via a linear approximation based on the Taylor expansion around the EBEs (if the option "use linearization method" is checked) or via a stochastic approximation using the exact model. The linearization method is usually faster but can be less accurate than the stochastic approximation. After running the task, the standard errors and relative standard errors associated with each parameter are displayed in the table of population parameters in the tab "Results.
CONCLUSION In this tutorial, MonolixSuite has been used to build a population model for remifentanil's PK. With Datxplore, the data have been visualized to identify their key properties. With Monolix, a model has been developed stepwise: First the structural model and then the covariates and correlations between random effects. Each model modification was guided by the diagnostic plots and statistical tests to assess the performance of the model and the improvement compared with the previous runs. The successive steps were tracked with Sycomore for a clear overview. Population models provide a summary of the PK of a molecule (typical half-life, variability from individual to individual, etc. ). They can be used to explore new situations via simulations. Examples of applications include clinical trial simulations to determine the best dosing protocol or assessing the uncertainty of an end point depending on the number of individuals per arm.
For this purpose, the MonolixSuite includes the simulation application Simulx. Monolix runs can be imported into Simulx, and the simulation definition can efficiently reuse its elements. The user can also specify new elements, such as different treatments, number of subjects, or covariate values representing different populations. MonolixSuite provides a unified suite of applications for the analysis, modeling, and simulation of pharmacometric data. Its ease of use through a clear graphical user interface and its efficient solvers and algorithms makes it a powerful software for both beginner and advanced users. Supporting Information. Supplementary information accompanies this paper on the CPT: Pharmacometrics & Systems Pharmacology website (www. psp-journal. com).
Low-cost sensors are increasingly being applied in the water sector. For example, low-cost sensors have been used for water quality  (Lambrou et al. 2014)  and turbidity measurements in drinking water  (Leeuw & Boss 2018; Kitchener et al. 2019). Parra et al. (2018)  have developed a turbidity sensor for fish farms. Assendelft & van Meerveld (2019)  have used a low-cost flow measurement system in streams. Montserrat et al. (2013)  used temperature to monitor combined sewer overflows. Placencia et al. (2019)  have developed system to measure rainfall intensity. Ruano et al. (2009)  have developed on-line nitrogen analysers for wastewater treatment plants. We are likely to see the use of these sensors expand and the creation of systems to translate data capture and interpretation into management action.
Description of the testing protocol The platform automatically adjusts water levels such that all sensors can complete measurements at the desired frequency before each change in water level. The parameters of each experiment are controlled by an Arduino Uno board programmed with the Arduino IDE (arduino. cc). The Arduino board communicates directly with all the sensors and controls the pump direction and functioning with three relays. The board sends all data in real time to a computer via serial cable using the Processing software (processing. org). The Processing software collects all data and saves two files at the end of the experiment: a comma-separated values (CSV) file containing all measures timestamped, and a text file containing details describing the experimental parameters, and pump operation.
The code for the Arduino board and Processing are available on the Github platform: https://github. com/fcherqui/ Mind4stormwater/tree/master/Testing-platform. Each experiment consisted of a single complete cycle of emptying the testing platform to minimum height (lower limit) followed by complete filling (upper limit). At the beginning of each experiment, the reference sensor was used to fill the column until the water level reached the upper limit (1. 850 m). Once that water level was achieved, the system was idle for 15 seconds (default) to allow the water level to stabilise. For each level, by default 1,000 low-cost measures were made, 10 reference measures (1 every 100 low-cost measures), and 100 measures with the DHT22 sensor (1 every 10 low-cost measures). When all the measurements were finished for a level, the pump started for five seconds to decrease the water level.
With the default parameters, each experiment lasted between 5 and 12 hours, depending on the low-cost measurement time, which facilitated measurements at 130 discrete water levels. At the start of each experiment, the program estimated the total duration based on the parameters chosen. When selecting the default parameters used here, because the reference sensor required up to two seconds to take a measurement, we set 10 reference measures per level in order to have enough redundancy to control the precision of the reference sensor without substantially increasing the time to complete the experiment. Similar reasoning was applied for the air temperature and relative humidity measures. As the platform and protocol were fully automated, we included several safeguards in the code. The experiment would automatically stop and trigger an alert if: (1) for any given water level, the difference between the first and last measure from the reference sensor exceeded 2 mm, (2) the water level exceeded safety upper and lower limits, and (3) the pump was active but the water level did not change.
85 m by at least 50 mm. The median errors are almost never below +20 mm. The plot shows an important variability of the 1,000 measures per measurement step: the precision of this sensor is 50 mm. We do not present further detailed results for this sensor because it is not compatible with our expectations (an accuracy of +20 mm). The data and associated plots are provided in the dataset. The accuracy of the ultrasonic sensor is better (Figure  2(b) ) than the laser-ranging sensor. The ultrasonic sensor has a limited range and cannot correctly measure the distance at closer range, i. e. blanking distance (high water level, around 1. 780 m) and longer range (low water level around 0. 050 m). The accuracy of the low-cost pressure transducer is also better than the low-cost laser-ranging sensor (Figure  2(c) ).
If necessary, other sensors can be added and connected to the acquisition system (Arduino board): for example, light, water turbidity or parasite capacitances (for example generated by power lines). We built an open-source code where most of the experimental parameters are adjustable such as: water level range, number of reference measures or low-cost measures, environmental condition measures, or number of measurement steps. The whole experiment is also automated because its duration is at least ten hours even with low-cost measures of less than 0. 5 seconds. The long duration of the experiment is explained by the high number of measures, the reference sensor measurement time (around two seconds), the time to change the measurement level (pumping water) and for the water level to stabilise.
ACKNOWLEDGEMENT This research received financial support from  Melbourne Water , through the  Melbourne Waterway Research-Practice Partnership  (http://mwrpp. org), from the  European Union 's  Horizon 2020 research and innovation programme  under Grant Agreement no. 786566  (https://mind4stormwater. org), and from the  Rhone Mediterranean Corsica Water Management Agency  under the  Cheap ' Eau  project. This research was performed within the framework of the  OTHU (Field Observatory for Urban Water Management)  and the  EUR H2O ' Lyon  ( ANR-17-EURE-0018 ).
Acknowledgments J. B. M. thanks  Christophe Genthon ,  Laurent Li , and  Jean Jouhaud  for useful discussions;  Julie Celton-Madeleine  for proofreading the manuscript; and  Jérôme Servonnat  and  Karine Marquois  for technical assistance. This study benefited from the  IPSL mesocenter ESPRI  facility which is supported by  CNRS ,  Sorbonne University , Labex LIPSL, CNES, and  Ecole Polytechnique. It was supported by  CNRS  and by  CNES  and granted access to the HPC resources of IDRIS under Allocation 0292 made by  GENCI. It was also supported by the  DEPHY2  project funded by the  French national program LEFE/INSU. We finally thank the JAMES editorial team and two anonymous referees for their thoughtful comments, which very much improved the quality of the manuscript.
Data Availability Statement The last version of the LMDZ source code can be downloaded freely on the LMDZ website (https://lmdz. lmd. jussieu. fr). The version used for the specific simulation runs of this paper is the svn release 3404 from 16 October 2018 which can be downloaded and installed on a Linux computer by running the install_lmdz. sh script available online on the LMDZ website. A large part of the outputs is available on the CMIP5 and CMIP6 archives, distributed through the Earth System Grid Federation (ESGF) and freely accessible through the ESGF data portals after registration. Details about ESGF are presented on the CMIP Panel website (at https://www. wcrp-climate. org/index. php/wgcm-cmip/about-cmip). Lighter postprocessed files together with the scripts used to generate the figures are registered under https://doi.
Atmospheric boundary layer height (BLH) is a key parameter for several meteorological applications, for example air quality forecast. To measure it, a common practice is to use aerosol lidars: a strong decrease in the backscatter signal indicates the top of the boundary layer. This paper describes and compares two methods of machine learning to derive the BLH from backscatter profiles: the K-means algorithm and the AdaBoost algorithm. Their codes are available under a fully open access, with the name KABL (K-means for Atmospheric Boundary Layer) and ADABL (AdaBoost for Atmospheric Boundary Layer). Both methods are compared to the lidar manufacturer's software and to reference BLH derived from collocated radiosondes. The radiosondes are taken as the reference for all other methods. The comparison is carried out on a two-year long period (2017-2018) on 2 Meteo-France's operational network sites (Trappes and Brest).