dataesr/scientific-paragraphs-categorization huggingface dataset:
BiPSim description. BiPSim is an open-source command-line tool for the stochastic simulation of sequence-based processes based on the Gillespie algorithm. The software is implemented in C++, runs on Linux/ Mac and is licensed under the GNU GPL licence. Reactant/reaction types. BiPSim relies on a set of computer classes managing both chemical and sequence-based reactions efficiently (Fig. 1 ). In order to design the classes of BiPSim reactions and reactants, we first reviewed the molecular mechanisms that compose different cell processes. We then introduced a minimal set of reactants (e. g. chemicals, sequences, binding sites) and reactions types suitable to describe most known cell processes, especially sequence-based biochemical reactions (e. g. binding, translocation, loading). Each reaction is associated with a rate proportional to the molecule number of each reactant (see Supplementary File 1).
In all simulations, replication was simulated base per base. Moreover, the steps of initiation and termination for transcription and translation are identical in the three descriptions. Finally, both messengers and proteins are not degraded and accumulate throughout the cell cycle. We collected gene sequence features for Bacillus subtilis (DNA, 2612 transcription units, 3896 proteins, promoters, terminators, ribosome binding sequences, etc. ), realistic parameters from literature (see Methods) and generated the input files of BiPSim using scripts (see Fig. 2a ). Models ge_detailed, ge_aggregated and ge_hybrid contained 60, 12,300 and 13,034 reactions respectively. The input files containing the full list of reactions are provided with the BiPSim archive. Performance tests. In all our models, we included energetic molecules such as ATP and GTP, for example for the loading of amino acids onto tRNAs, translation initiation or ribosome translocation (Supplementary Figure  1 ).
e. , models that can be described in SBML format and can thus be simulated by numerous simulation tools. As there are no sequence-related models involved, all models have been implemented in BiPSim using the pool-based FreeChemicals and ChemicalReactions and none of the particle-based chemical entities or reactions. First, we computed BiPSim's performance on a recent benchmark  34  comparing 16 implementations of the SSA over five simulation models with increasing combinatorial complexity. In the original publications, the authors concluded that, even in datasets with high combinatorial complexity, network-based implementations (exhaustive representation of reactant states and reactions) outperformed network-free implementations (particle-based) for large numbers of molecules. We found that BiPSim performed on par with the best network-based implementations (Fig.
BiPSim implementation. BiPSim is an open-source command-line tool implemented in C++, designed to run on UNIX-based operating systems (Linux and Mac). Along with traditional chemical reactions, BiPSim defines new types of reactions and reactants that can be simulated using Gillespie's Stochastic Simulation Algorithm (SSA)  23. New types of reactions and reactants are implemented as separate C++ classes. Reaction classes inherit from a common interface which can be queried by the solver to determine reaction propensities and executing reactions, enabling seamless integration with traditional implementations of the SSA. Similarly, reactant classes share common properties, such as the possibility to add or remove instances of the reactant. While freely diffusing chemicals are simple pools of molecules, sequence-bound molecules are represented individually as particles.
The gene product is then generated in one step and the polymerase is released from its template sequence. As a result, there are two additional reactions per gene represented using the aggregated process. These reactions have been generated using a custom Python script and added to transcription. in and translation. in. All sequence annotations and other reactions in the system remained identical. Gene expression models: sequence information. Sequence information for Bacillus subtilis was taken from  53  : DNA sequences, position of promoters, transcription starting sites, terminators, ribosome binding sequences (RBS), start and stop codons. A Transcription Unit (TU) can contain several genes, rRNAs or tRNAs. Conversely, a gene can belong to several TUs. The total number of mRNAs in the cell is given by the sum of TUs carrying genes.
We then converted the SBML models to BiPSim using custom Python scripts, converting reactants from the SBML models into FreeChemicals and reactions into ChemicalReactions (pool-based reactants and reactions representing freely diffusing chemicals). We followed the original publication's methodology to generate all use cases (5 independent runs for different combinations of simulation times and initial number of molecules). We ran all |DNAP free |r recruitment = 3/4 1mM/L ≃ 10 -3. 6. 10 23. 10 -1  = 6. 10 5 molecules.
NMR spectroscopy 1 H NMR spectra were recorded on a Bruker Avance 400 MHz spectrometer (Karlsruhe, Germany) operating at 400. 13 MHz with a BBI BB-H 5 mm probe head and at a temperature of 300 K. For 1 H NMR, acquisition parameters were set to 1024 scans with 32 dummy scans, a flip angle of 30°, a spectral width of 20. 55 ppm, and a transmitter offset of 6. 175 ppm. The acquisition time was 3. 985 s followed by a relaxation delay of 1. 0 s and collecting 64,000 data points at a sample spinning frequency of 20 Hz. Data was processed with TopSpin 4. 0. 6 (Bruker BioSpin). An exponential line broadening window function of 0. 3 Hz was applied. An automatic baseline correction and manual phasing was performed. Selective NOESY NMR spectra were recorded at a temperature of 300 K on a Bruker Avance III HD 600 spectrometer operating at 600.
Molecular dynamics Molecular dynamics (MD) simulations were performed using the GROMACS 2020. 1 software package  39, 40  and the Martini force field version 2. 2. 41 The starting system was a cubic box with side lengths of 25 nm filled with non-polarizable Martini water, to which lecithin (L, i. e. 1-Palmitoyl-2linoleoylphosphatidylcholine, or PIPC), taurocholate (TC) and Perphenazine (P) were added to randomly chosen positions replacing as many water molecules as needed. Two systems were set up, the first containing 1,250 L and 185 TC molecules. Starting from a random distribution of L and TC at concentrations of ≈ 150 mM and ≈ 23 mM, respectively, the formation of mixed vesicles was followed in ten independent simulations of 10 µs length each in the first system. The concentration and number of L molecules were chosen to allow for the formation of vesicles with a radius of ca.
These demonstrated that at this wavelength Perphenazine quantification was possible over the entire drug concentration range while in presence of taurocholate and lecithin. Sedimentation velocity experiments were performed for a typical 24 h with a radial sedimentation profile scan acquired every three minutes. Sedimentation velocity data were analyzed with Sedfit using the ls-g*(s) model, i. e. by least squares boundary modeling by assuming non-diffusing species. 44 Results from this model can be considered representative of the average velocities of sedimentation boundaries, in agreement to more detailed modelling. 45.
DLS DLS experiments were performed with a DelsaNanoHC particle analyzer from Beckman Coulter with the backscattering monitored at an angle of 165°. The unfiltered samples were measured in disposable 1. 5 mL UV-Cuvettes (Brand, Wertheim, Germany) in triplicate with an accumulation of 70 scans. Data was analyzed by the CUMULANT method. 46 The Z-average hydrodynamic size was evaluated with a refractive index of 1. 333 for all samples which was determined for FaSSIF using an Abbe refractometer (Carl Zeiss, Oberkochen, Germany). The hydrodynamic diameter was calculated using a dynamic viscosity of 0. 9227 mPas for FaSSIF. Density and viscosity were determined using an Automated Microviscometer (Anton Paar, Graz, Austria). Measurements were performed at a temperature of 298 K for all experiments, i.
75 mm x 3. 75 mm pixel size. The data sets were reduced using the facility provided software LAMP, put on absolute scale using a 1 mm H 2 O cuvette as secondary calibration standard (d∑/dΩ = 0. 983 1/cm) and azimuthally averaged. The scattering curves of pure FaSSIF and of 0. 3 mM Perphenazine in FaSSIF were recorded. The solvent scattering has been measured and subtracted from the sample data. The data were fitted using the SasView software package (www. sasview. org) and the instrumental resolution has been taken into account.
1 ppmv, while the accuracy is limited by the calibration error amounting to 4 %. The typical precision in the stratosphere is 5 %-6 %, whereas the total uncertainty is less than 10 % throughout the stratosphere. During profiles, the primary measurement data (i. e. , the fluorescence signal) is reported and stored at 1 Hz, whereas housekeeping and diagnostic data are reported at 0. 1 Hz.
1 m s -1 , until the torque feedback indicates the profiler is docked. At this point the profiler offloads the approximately 200 kB of profiler data to the Zephyr, which sends them to the ground along with the reel performance data from the ascent. Once data offload is complete, power to the profiler is turned off and the battery is recharged for the next profile or for entering a daytime hibernate or charge mode if the SZA < 115 •. The mission specification for the RACHuTS flights is three to four cycles per night, yielding six to eight profiles through the TTL as data are collected both on descent and ascent. Unfortunately, due to the intermittent communications through the docking connector and a compounding software error, all the cycles during the engineering flight were commanded manually using TCs from the ground.
Reel system performance As an entirely new and complex system, validating the performance of the RACHuTS reeling system was one of the primary goals of the engineering test flight. Motor performance data for all one hundred and ten 2 km motions were consistent with pre-flight engineering analysis and laboratory tests. During the ascent portion of each cycle, reel power consumption averaged 39 W with a motor current of 2. 6 A at a nominal voltage of 15 V. During the descent phase of each cycle the reel motor acts as a retarder, counteracting the gravitational acceleration on the profiler and generating net counterelectromotive force. This generated power was shunted to a large power resistor on the electronics box housing to be dissipated as heat and to limit the increase in motor voltage. A possible concern identified before the flight was the ability to dissipate this heat in the low-pressure stratospheric environment; however the reverse current flow in flight was lower than expected (∼ 0.
TSEN performance The performance of the sensors in the profiling unit is assessed based on two criteria: the technical operation of the sensor and, where possible, a comparison of the scientific measurement with independent measurements. The profiler TSEN operated nominally throughout the flight, both during profiles and while docked. TSEN collected 3. 1 million measurements of pressure and temperature while docked and 300 000 measurements during profiles. No anomalies were identified in the instrument operation, and missing data from the flight are due to communications issues with the profiler rather than to the TSEN instrument. The measurement performance of TSEN is well characterized from prior long-duration flights. Two comparisons have been identified for the RACHuTS TSEN: comparison with the TSEN located on the Euros gondola for flight level data and comparisons with nearby radio soundings for profile data.
The offset of the RACHuTS TSEN pressure measurement is a strong function of the temperature of the pressure sensor module. After applying an empirical linear correction to the pressure sensor as a function of the temperature of the sensing element and accounting for the 7 m vertical separation between the sensors, the mean offset between the two pressure sensors was reduced to 0. 08 hPa with a 1σ variance of 0. 55 hPa. This correction was then applied to all the RACHuTS TSEN pressure measurements. Comparisons between RACHuTS profiles and radiosondes were rare due to the scarcity of radiosonde sites within the tropics. Fortuitously, two RACHuTS profiles over Brazil were within 300 km of three operational radiosonde sounding sites (Fig. 6 ). The profile collected on 3 January 2020 (Fig. 6b ) was within 300 km of two radiosonde soundings; however there was significant horizontal and temporal variability in the TTL as is evident in the difference between the RACHuTS descent and ascent profiles, which were spaced 76 km apart, and subsequent radiosonde soundings.
Acknowledgements. The authors gratefully acknowledge the support of the Stratéole 2 science teams, the LATMOS/LMD gondola engineering team, the  CNES  balloon team, and the  Seychelles Meteorological Agency. This work was funded by the  NSF  under award  1643022 , with kind support provided by  CNES  and  CNRS. Special thanks to  Philippe Cocquerez  and  Stephanie Venel  for making the flight of this unorthodox instrument possible on a CNES balloon. Financial support. This research has been supported by the  National Science Foundation, Directorate for Geosciences  (grant no. 1643022 ). Review statement. This paper was edited by  Alyn Lambert  and reviewed by  Masatomo Fujiwara  and one anonymous referee.
Multi-tenancy enables cost-effective SaaS through resource consolidation. Multiple customers, or tenants, are served by a single application instance, and isolation is enforced at the application level. Service load for different tenants can vary over time, requiring applications to scale in and out. A large class of SaaS providers operates legacy applications structured around a relational (SQL) database. These applications achieve tenant isolation through dedicated fields in their relational schema and are not designed to support scaling operations. We present a novel solution for scaling in or out such applications through the migration of a tenant's data to new application and database instances. Our solution requires no change to the application and incurs no service downtime for non-migrated tenants.
Introduction Software-as-a-Service (SaaS) is the cloud service model with the highest market size  [8]. It allows client organizations, or tenants, to benefit from turn-key applications. Multi-tenancy is the sharing application instances across multiple tenants  [9]. It enables SaaS providers to benefit from economies of scale, consolidating service load for different tenants, and reducing total cost of ownership. Multi-tenancy can be implemented by sharing computing resources (virtual machines (VM) or containers), by sharing application servers, storing data for multiple tenants in the same database or using a combination of these approaches. For instance, Rightnow, a customer relationship SaaS provider, reported millions of dollars of savings thanks to multi-tenancy  [18]. Despite the current trend towards building new applications using microservices  [5]  and using cloud-native scalable databases  [21, 24] , a large class of SaaS operators still operate applications based on tried-and-tested monolithic applications using a relational (SQL) database to store customer data.
In such legacy applications, multi-tenancy is typically implemented at the database level, either using distinct dedicated databases, dedicated tables or shared tables  [28]. We focus in this paper on shared-table multi-tenancy: Database tables are shared between tenants, and a tenant identifier enables queries to distinguish the tenants' rows (i. e. , a shared-table schema  [2] ). SaaS provider Salesforce has been, for instance, using such a shared-table architecture for over ten years  [29]. Other examples of applications using shared-table multi-tenancy include learning management such as Iomad (an evolution of Moodle), content management (e. g. , Cortex-CMS), business process modelling (e. g. , Activiti, Bonita, Camunda), or cloud billing (e. g. , CloudKitty). The application load for multi-tenant applications hosted in the cloud is dynamic.
In order to enforce the essential pay-as-you-go model of cloud computing, applications must support elastic scaling operations, whereby new resources are added and removed as the operation workload changes. Typically, scaling out requires starting new application instances and migrating data for certain tenants to this instance. In legacy shared-table multi-tenant applications, this requirement is impaired by two factors. First, there is limited support for scalability operations in traditional relational database engines  [14]  3. Second, legacy applications are generally designed on the basis that a single, centralized, and unified view of the entire database is available, which includes in particular information (tables) shared across tenants. Migrating data for a tenant to the new database instance associated with the new application server invalidates this assumption, requiring non-trivial adaptations in the legacy code.
Contributions. We present a non-intrusive and efficient methodology for stopand-copy tenant migration in legacy multi-tenant applications using the sharedtable approach. Our method enables such legacy applications to scale in and out based on tenants' requirements (e. g. , the volume of requests or data). It is adapted to the constraints of SaaS providers:  (1)  it does not require changes to the code of legacy applications, and maintain guarantees on unified views of the database and of common data;  (2)  it enables migrations of a tenant with no interruption of service for other tenants and only minimal and temporary impact for the migrated one; (3) it effectively enables the provider to scale up the number of requests that can be supported after migration and can, reversely, be used for tenant consolidation and resource savings.
Our method leverages external tables and foreign data wrappers (FDW), ISO standard features supported by major relational database engines. These features enable a unified view of the database, and unmodified queries while allowing data to be stored onto different instances of the database engine hosted by different VMs or containers. We present a SQL-based systematic process for the migration of tenants' data between these instances. We implemented our approach for two representative multi-tenant applications: (1) Iomad, a learning management system evolved from the popular Moodle system; (2) Camunda, a business process management system. These two case studies confirm the ability of our method to enable migrations with no change to the application. Our performance evaluation of the applications in a Kubernetes cluster using Post-greSQL shows the effectiveness of our approach.
Design goals In a multi-tenant application, tenants' resource requirements vary depending on clients activity. These variations are hard to predict and can bring underutilization or over-utilization of resources, resulting in additional costs for the provider or severed QoS for the customer. A possibility to address this problem is to migrate the corresponding data and software to another server. However, tenant migration in shared-table multi-tenant applications is a complicated process, due to the meddling of tenant data in different rows of common database tables. Besides, some data can be shared between tenants: For instance, global parameters such as the list of tenants cannot be separated between different tenants. This makes the task of consistently backup or export data challenging to do without changes to the application code.
We propose a method for migrating tenants in legacy applications using a relational database and the shared-table model. Its goals are as follows: -Non-intrusion: It should not require changes to the source code of the application, as these are typically expensive to implement and maintain over time. Instead, it may only apply simple transformations of the database schema. -Parsimony: Only the data relevant for a migrated tenant should be transferred between origin and target database instances, to limit the impact of migrations on resource consumption for the provider. -Transparency: Migration operations should have minimal impact on the application clients, and particularly those of the non-migrated tenants. Application or database restart is not desired to implement migration, and the slowdown imposed by a migration operation must be limited.
-Reliability: Changes to the database schema, as required by the architecture to enable migrations, should not impact data and queries consistency. We also make the following assumption of tenant isolation, that is, tenants' queries should be specific for their tenant, i. e. they should not target other tenants  [9]. In the remainder of this section, we illustrate our discussion using an example of a multi-tenant stock management application, whose schema is given by Figure  1. This example application allows different tenants (listed in table tenant) to trace the availability (association table site product) of products (table product) on different sites (table site). Tenants can only access their sites and products (e. g. , as the primary key for product is <tenant id,id> there is no sharing of product identifiers between tenants).
Overview The foundation of our method is to split the tables of the application schema between a single reference database and multiple tenant databases. Each tenant database hosts data for multiple tenants, but data for a given tenant is not split across tenant databases. All tenant databases link with the unique reference database by using foreign tables. The reference database contains data common to the whole installation. The application servers connect to the corresponding tenant databases and do not need to be aware of the existence of the reference database accessed through foreign tables. Figure  2  presents an example of deployment with two tenants databases. Foreign tables are supported by major relational databases  [30] , and are enabled by Foreign Data Wrappers (FDW), an ISO standard feature for relational databases since SQL/MED (ISO/IEC 9075-9:2003  [11] ) 4.
Foreign Data Wrappers allow accessing foreign data through virtual tables. Foreign data can be tables in a remote database instance, or other data sources accessed through a specific wrapper. Virtual tables behave like regular tables for queries and provide ACID guarantees for foreign data stored in the remote database. It is important to note, however, that foreign tables do not allow the automatic enforcement of integrity constraints (e. g. , foreign keys) between local tables and foreign tables: Such constraints can only be declared between local tables  5. The transparency of queries using foreign tables directly enables our property of non-intrusion: queries in the application do not have to be modified, and we only need to operate changes to the database schema, as we present next.
Mapping tables to tenant or reference DB Our method requires classifying which of the tables should be hosted in tenant databases and which should be kept in the reference database, and accessed, therefore, as foreign tables from the former. This classification is applicationdependent and cannot be easily automated. We discuss, therefore, guidelines to allow SaaS operators to make informed decisions, as we detail with our two use cases in Section 3. We propose to classify tables using the following categories. (1) Active tables contain tenant-specific data about currently running processes, tasks, events, users, roles, etc. (2) Temporary tables contain system-related data linked to the tenant application server, for instance, cache tables. (3) System tables contain system-related data concerning the global installation (e.