dataesr/scientific-paragraphs-categorization huggingface dataset:
The table can be downloaded and used as input for plotXpress. To visualize the data, users can select the 'Plot' tab. First, a reference condition should be selected. This is generally a control condition, e. g. an empty vector in a reporter assay. Without selecting a reference, the firefly/renilla ratio is plotted on the y-axis. If a reference condition is selected, normalized firefly/renilla values from the other conditions are represented as fold-change relative to the reference (Figure  4A ). As an optional feature, the reference can be shown or hidden, depending on user preference. Several options are available to optimize the data visualization. The size and transparency of the datapoints can be adjusted, gridlines can be removed, summary statistics can be selected, and the font size and plot size can be changed.
Use cases The plotXpress app automatically loads an experimental dataset from a GloMax dual-luciferase reporter assay. This set contains 96 measurements acquired from different conditions. The conditions differ in the vector that is transfected (control, geneA or geneB), in the drug treatment (no drug, drug1, drug2 or drug1&drug2) and the cell type (Hek or neuron). Three measurements were done for each unique condition. The 'control' is set as a reference condition and the 'geneA' and 'geneB' condition are compared to the reference and their levels are expressed as 'Fold Change' (Figure  4A ). The resulting data visualization can be used to compare the effect of geneA and geneB relative to the empty vector control and under different conditions. The display of the actual datapoints contributes to the transparency in the communication of the results.
Conclusion Gene reporter assays are an invaluable tool for molecular biology, enabling the study of regulatory DNA sequences, transcription factors, pharmaceutical compounds, oligonucleotides and other factors that interact with DNA sequences. With each treatment or cellular context, the assay increases in complexity. PlotXpress simplifies the data analysis by bridging the gap between wet-lab standards (96-well format) and dry-lab conventions (tidy data format) that are typically used in downstream analysis of experimental biological data. The current version of plotXpress was written to analyze expression data in tidy format as well as for GloMax output data. The import of data produced by plate readers from other manufacturers is not supported at this moment, but we welcome suggestions and example data to implement import functions for other data formats.
Since plotXpress is open-source, users can modify the source code by making a fork to the GitHub repository and create a pull request to have their changes reviewed and possibly integrated. Although plotXpress was developed for the analysis and visualization of dualluciferase experiments, it can be used for other types of data that require normalization or comparison with a reference condition, such as quantitative polymerase chain reaction data. The open-source web tool is freely accessible online, democratizing the state-of-the art data visualization of reporter assay data. Moreover, the standardized data processing will contribute to transparent and reproducible science.
Extended data Zenodo: ScienceParkStudyGroup/PlotXpress: v1. 0. 1 https://doi. org/10. 5281/zenodo. 5554885  (Goedhart and Galland, 2021). This project contains the following files: -DualLuc_example_data. xlsx. Example data file -Tidy_design. csv. Example conditions file  Regarding the normalization options, It could be helpful to provide the possibility to normalize the data to the overall detected signal in the plate for each repeat. This can sometimes be more beneficial than normalization to CTRL wells alone. It would also be beneficial for the quantifications to compute the Z-score, which is often used for HTS analyses. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes.
Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Bioinformatics, R, shiny, visualization, gene regulation, I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.
We develop a novel approach for run-time global adaptation of microservice applications, based on synthesis of architecture-level reconfiguration orchestrations. More precisely, we devise an algorithm for automatic reconfiguration that reaches a target system Maximum Computational Load by performing optimal deployment orchestrations. To conceive and simulate our approach, we introduce a novel integrated timed architectural modeling/execution language based on an extension of the actor-based object-oriented Abstract Behavioral Specification (ABS) language. In particular, we realize a timed extension of SmartDeployer, whose ABS code annotations make it possible to express architectural properties. Our Timed SmartDeployer tool fully integrates time features of ABS and architectural annotations by generating timed deployment orchestrations.
In particular, we realize a timed extension of SmartDeployer  [13, 14] , whose ABS code annotations make it possible to express: architectural properties of the modeled distributed system (global architectural invariants and allowed reconfigurations), of its VMs (their characteristics and the resource they provide) and of its software components/services (their resource/functional requirements). Such annotations are read by SmartDeployer that, at compile-time, checks them for satisfiability (accounting for requirements and architectural invariants) and synthesizes deployment orchestrations that build the system architecture and each of its specified reconfigurations. SmartDeployer generates optimal deployment and undeployment code by using ABS itself as an orchestration language and by making it available via methods with conventional names.
Such methods can be invoked by the ABS code of services, thus realizing run-time adaptation. Here we introduce the Timed SmartDeployer tool that fully realizes the integration between timed ABS execution language and architectural annotations by generating timed deployment orchestrations. Such orchestrations also manage time aspects, dynamically setting VM speeds (based on virtual cpu cores that are actually being used) and overall startup time for the deployed architectural reconfiguration. One of our main motivations in having a model encompassing architectural invariants/reconfigurations is to anticipate at the modeling level deployment orchestration related issues. This indeed fosters an approach where analysis of the consequences of deployment decisions are available early on: Timed SmartDeployer checks (at compile-time) the synthesizability of deployment orchestrations that, at run-time, will ensure the system to be always capable of adapting in case of positive/negative peaks of user requests.
io  [23]. Its model is built by considering: static aspects of the architecture (annotations) and ABS code modeling the behavior of services. We simulate system execution using inbound traffic inspired to two different real datasets in  [24]  and  [29] , representing the frequency of emails entering the system. In order to show the effectiveness of our architecture-level adaptation algorithm, we compare it with traditional local scaling techniques. In particular, we produce two ABS programs: one implementing our algorithm (using 4 Timed SmartDeployer synthesized orchestrations) and one just dealing with scaling needs at the level of single microservices. Our comparison results show that our algorithm actually avoids cascading slowdowns and consequent increased message loss and latency that affect traditional local scaling.
In section 2 we briefly recall the microservice model, the ABS language and the SmartDeployer tool. Then, in Section 3 we present the Email Processing Pipeline case study, mathematical calculation of system properties like MCL, and we introduce the novel timed architectural modeling/execution language based on our Timed SmartDeployer. In section 4, we present our global scaling algorithm and its mathematical foundations. Finally, in Section 5 we present simulation of our case study, discussing comparison results, and in Section 6 we conclude the paper and discuss related work.
The two phases make it possible to manage circular dependencies among microservices. These concepts are inspired by Docker Compose  [20] , a language for defining multi-container Docker applications, that makes it possible for users to specify different relationships among microservices using, e. g. the depends on (resp. external links) modalities that impose (resp. do not impose) a specific startup order, in the same way as strong (resp. weak) dependencies. In addition  [13, 14]  consider resource/cost-aware deployments modeling the memory and computational resources: number of virtual CPU cores (vCores in Azure), sometimes simply called virtual CPUs as in Amazon EC2 and Kubernetes  [25]. In particular, both microservice specifications and VM descriptions are enriched with the amount of resources they, respectively, need and supply.
SmartDeployer SmartDeployer implements the algorithm described at the end of Section 2. 1 to perform automated deployment of microservice applications, i. e. synthesis of deployment orchestrations that reach a given target system configuration. In particular, it exploits the constraint solver Zephyrus2  [3]. The input to Smart-Deployer is expressed by means of an ABS source file from which it extracts: In output it produces the synthesized deployment orchestration: the set of orchestration language instructions (expressed as ABS code) that cause the system to reach a deployment configuration with the desired properties. It also produces the undeployment orchestration to undo such deployment operations. A description of the SmartDeployCost annotation can be found in Appendix A. 1. -ABS.
Timed Architectural Modeling/Execution Language In this section we introduce our integrated timed architectural modeling/execution language based on the novel Timed SmartDeployer tool. Our tool fully realizes the integration between timed ABS execution language and architectural annotations by generating timed deployment orchestrations. For ease of presentation, we make use of a case study: the Email Pipeline Processing System taken from Iron. io  [23]. With its help we introduce the concept of microservice Multiplicative Factor (MF) and Maximum Computational Load (MCL). We show that in our integrated timed language it is possible to model microservice MCL in a way that is consistent with timed deployment orchestrations. As we will see in Section 4, this allows us to give a mathematical foundation to the calculation of: the base system configuration and the target ones used by Timed Smart-Deployer to synthesize scaling orchestrations (global adaptation algorithm).
The case study architecture can be divided into four pipelines analyzing different parts of an email. Messages enter the system through the MessageReceiver, which forwards them to the MessageParser. This microservice, in turn, extracts data from the email and routes them to a proper sub-pipeline. Once each email component is processed, entailing a specific working time, analysis data is collected by the MessageAnalyzer that produces an analysis report. Based on system architecture, we observe that each microservice type is also characterized by: (i) a Maximum Computational Load (MCL), i. e. the maximum number of requests that a microservice instance of that type can handle within a second and (ii) a Multiplicative Factor (MF) i. e. the mean number of requests that a single email entering the system generates for that microservice type.
Timed SmartDeployer Our timed architectural modeling/execution language fully integrates timed ABS and architectural annotations thanks to the novel Timed SmartDeployer. Such a tool extends SmartDeployer  [13]  with synthesis of timed deployment orchestrations: they additionally encompass dynamic management of overall Deployment Component (DC) startup time and DC speed (computational resources per time unit, see Section 2. 2), based on the number of DC virtual cores that are actually used by some microservice after enacting the synthesized deployment sequence. As we will show, this allows us to correctly model time (microservice MCL). The original SmartDeployer implicitly handles time by simply assigning all properties of DCs, copying them from annotations. The effect of this on timed ABS was to statically assign a speed and a startup time to each DC.
Modeling Service MCL We now show how Time SmartDeployer allows us to correctly simulate the service MCL we want to model (see Section 3. 2), independently of the VM (DC) in which it is deployed. An example is considering, as we do in our case study, the ABS time unit to be 1/30 sec and setting VMs to supply 5 speed per core. In the ABS code of a service we implement its MCL by using the Cost instruction tag (see Section 2. 2). E. g. , for the ImageRecognizer, which requires 6 cores to be deployed, we obtain the MCL of 91 requests per second as follows: where the method recognizeImage(. ) is executed at each request. Due to our SmartDeployer timed extension, the of VM speed used by ImageRecognizer is always 5 • 6 (speed per core • cores required), independently of the VM in which it is deployed: i.
Simulation with ABS In this section we present simulation results obtained with our ABS programs [1] modeling local and global scaling (via Timed SmartDeployer orchestrations) for our case study. Such programs encompass, besides static aspects of the case study architecture (annotations), also the code representing service/adaptation behavior under an inboud workload: they fully implement what we explained in Sections 3 and 4. In particular, we implement by means of monitoring services: our algorithm for global adaptation (a single system monitor) and the one for local adaptation (a monitor for each load balancer) by just detecting scaling needs and enacting replications at the level of single microservices. Monitors are implemented by dedicated ABS services that run on a separate (simulated) VM.
Related Work and Conclusion We introduced an integrated timed architectural modeling/execution language that correctly deals with service Maximum Computational Load (MCL). More- over, we proposed a novel global scaling algorithm that optimally chooses deployment orchestrations, so to keep the system in a configuration that better fits the inbound workload (with the minimum number of instances). Finally, we performed a comparison between our global scaling algorithm and a classical local one by simulating, under two real workloads, a microservice application. We now discuss related literature by first comparing with our previous work. In  [13, 14]  initial ideas about applying SmartDeployer generated orchestrations to the case study of  [23]  were discussed, but (apart from annotations modeling static aspects of the architecture) no actual ABS code implementing system service execution/scaling mechanism was presented.
Similarly,  [26]  attacks the problem of defining optimal thresholds for scaling policies with a reinforcement-learning algorithm that automatically and dynamically adjusts the thresholds without user configuration. Finally,  [2]  proposes an approach that uses a predictive autoscaling model trained on a dataset generated from simulations of reactive rule-based autoscaling. W. r. t. work on workload prediction, such as  [2] , our global adaptation algorithm ability of detecting in advance service scaling needs is not based on guessing workload by means of logged data, but on mathematically calculating service MCL from system MCL (thanks to service Multiplicative Factor and current number of instances, see formula in Section 3. 1). The two approaches are, thus, orthogonal: our approach avoids the negative consequences of the scaling chain effect, but it just passively waits for the triggering event (significant increment in the inbound workload).
CB, cystoblast; NEP, nuclear envelope permeation. The average starting time of each of the events (mean±s. e. m. ) is shown. Sample sizes range from six to 14 (see the complete dataset in Fig. S4 ). Scale bar: 10 μm. a 3 µm range and that the anterior centrosome gradually restricted its movements to the GSC area facing the CpC rosette. In contrast, the posterior centrosome moved at higher speeds until it reached its final position (Fig. 7B ; Fig. S5 ; Movie 14). We concluded that GSC centrosomes are quite dynamic, even once they are placed on both sides of the nucleus before division, and that the anterior centrosome only fixes its position upon its association with the anterior spectrosome.
Acknowledgements We thank  D. St Johnston  and  N. Brown (University of Cambridge, UK) , the  BDSC , the  Vienna Drosophila Resource Center  and the  DSHB (University of Iowa, USA ) for DNAs, fly stocks and antibodies. The help of  J. Raff  and of the  Micron microscopy facility (University of Oxford, UK ; supported by the  Wellcome Strategic  Award  107457 ) with initial observations is also acknowledged. We thank  S. C. Herrera ,  J. R. Martıńez-Morales ,  J. Huertas ,  D. Even  and  Sol Sotillos  for comments on the manuscript, and members of the  Gonzaĺez-Reyes laboratories  for helpful discussions. We acknowledge core funding to the  Centro Andaluz de Biologıá del Desarrollo  from the  Junta de Andalucıá.
Funding This work was supported by the  Spanish Agencia Estatal de Investigacioń (MCUI/ AEI ; Grant numbers  PGC2018-097115-B-I00  and  MDM-2016-0687  to A. G. -R. ) and by the  European Regional Development Fund. Open  access funding provided by  Consejo Superior de Investigaciones Cientificas. Deposited in PMC for immediate release.
In order to enable the PYTHIA 8 program to simulate DIS processes, the O(α 0 s ) process together with the DIrect REsummation (DIRE) parton shower  [42]  is applied. The parton shower recoil is treated such that the kinematic variables of the DIS process (y and Q 2 ) are unchanged. The PDF CTEQ 5L  [36]  is used. DJANGOH and RAPGAP, as well as the PYTHIA 6  [43]  photoproduction events, are also used together with the H1 detector simulation in order to determine acceptance, efficiency and backgrounds. as well as to estimate systematic uncertainties associated with the measurement. DJANGOH and RAPGAP are interfaced to HERACLES  [44] [45] [46]  to simulate the QED radiative effects. The generated events are passed through a detailed simulation of the H1 detector response based on the GEANT3 simulation program  [47]  and are processed using the same reconstruction and analysis chain as used for the data.
Event selection The data set used for this analysis was collected with the H1 detector in the years 2006 and 2007 when positrons and protons were collided at energies of 27. 6 GeV and 920 GeV, respectively. The integrated luminosity of the data set is 136 pb -1  [48]. DIS events were recorded using triggers based on electromagnetic energy deposits in the SpaCal calorimeter. The trigger inefficiency is determined using independently triggered data and is negligible in the kinematic region of the analysis. The scattered positron is defined by the energy cluster in the SpaCal calorimeter with the highest transverse momentum. The energy of the cluster is further required to be larger than 12 GeV, and the radial position of the cluster is required to be between 15 and 70 cm with respect to the beam axis.
√ s = 319 GeV in ep collisions in bins of Q 2 with an additional restriction to the current hemisphere 0 < η * < 4. Further phase space restrictions are given in Table  1. The total uncertainty is denoted by the error bars. For each x bj , the multiplicity is determined in a dedicated pseudorapidity window as discussed in the text. Further phase space restrictions are given in Table  1. Predictions for S hadron from the RAPGAP model and for the entanglement entropy S gluon based on an entanglement model are shown by the dashed lines and solid lines, respectively. For each Q 2 range, the value of the lower boundary is used for predicting S gluon. The total uncertainty on the data is represented by the error bars. Here, a restriction to the current hemisphere 0 < η * < 4 is applied. Further phase space restrictions are given in Table  1.
Predictions for S hadron from the RAPGAP model and for the entanglement entropy S gluon based on an entanglement model are shown by the dashed lines and solid lines, respectively. For each Q 2 range, the value of the lower boundary is used for predicting S gluon. The total uncertainty on the data is represented by the error bars. GeV as a function of W. The measurement is repeated in four ranges of Q 2 as indicated. The phase-space is further restricted as shown in table 1. For this dataset, the track pseudorapidities in the hadronic centre-of-mass frame are restricted to the range 0 < η * < 4. The phase-space is further restricted as shown in table 1. For this dataset, the entropy is determined with the track pseudorapidities in the hadronic centre-of-mass frame are restricted to the range 0 < η * < 4 data = 72 GeV 〉 W 〈 = 101 GeV 〉 W 〈 = 141 GeV 〉 W 〈 = 205 GeV 〉 W 〈 0 2 4 〉 N 〈 z = N/ 1 - 10 10 (z) Ψ * < 4.
Mean multiplicity measured in ep DIS at √ s = 319 GeV as a function of W. The measurement is repeated in four ranges of Q 2 as indicated. The phase-space is further restricted as shown in table 1. For this dataset, the track pseudorapidities in the hadronic centre-of-mass frame are restricted to the range 0 < η * < 4. Variance of multiplicity distributions in DIS|η lab | < 1. 6 5 < Q 2 <10 GeV 2 stat. sys. tot sys. 1 sys. 2 sys. 3 sys. 4 sys. 5 sys. 6 sys. 7 sys. 8 Q 2 < 20 GeV 2 stat. sys. tot sys. 1 sys. 2 sys. 3 sys. 4 sys. 5 sys. 6 sys. 7 sys. 8.
Hadron entropy derived from multiplicity distributions measured in ep DIS at √ s = 319 GeV as a function of x bj. The measurement is repeated in four ranges of Q 2 as indicated. The phase-space is further restricted as shown in table 1. For this dataset, the entropy is determined in a sliding window in pseudorapidity as indicated in the table. Hadron entropy of multiplicity distributions in DIS0 < η * < 4 5 < Q 2 <10 GeV 2 stat. sys. tot sys. 1 sys. 2 sys. 3 sys. 4 sys. 5 sys. 6 sys. 7 sys. 8 Q 2 < 20 GeV 2 stat. sys. tot sys. 1 sys. 2 sys. 3 sys. 4 sys. 5 sys. 6 sys. 7 sys. 8 Q 2 < 40 GeV 2 stat. sys. tot sys. 1 sys. 2 sys. 3 sys. 4 sys. 5 sys. 6 sys. 7 sys. 8.
Acknowledgements We are grateful to the  HERA machine group  whose outstanding efforts have made this experiment possible. We thank the engineers and technicians for their work in constructing and maintaining the H1 detector, our funding agencies for financial support, the  DESY  technical staff for continual assistance and the  DESY  directorate for support and for the hospitality which they extend to the non-DESY members of the collaboration. We would like to give credit to all partners contributing to the  EGI computing infrastructure  for their support for the H1 Collaboration. We express our thanks to all those involved in securing not only the H1 data but also the software and working environment for long term use, allowing the unique H1 data set to continue to be explored in the coming years.