dataesr/scientific-paragraphs-categorization huggingface dataset:
A Scratch program was written to control the GPIO pins connected to the power relay channels and enable the user to create the various light/magnetic field cycle patterns. In addition, a MAX31856 T-type thermocouple board was connected to GPIO pins on the Raspberry Pi and a T-type thermocouple was connected to this board to monitor temperature during the growth process. The MAX31856 board has an open-source python library that was leveraged to record the data from the thermocouple and save it to the raspberry throughout the course of the experiment in real time. The programmable switch could, therefore, be set to control the current to the LEDs as well as to the MF coils to automatically and continuously generate the alternating pulses of blue light and MF exposure used in this study. Photon fluence of light intensity for the experiment was detected by a Quantum light meter (LI-185B, Li-Cor, Lincoln, NE, USA).
Anti-cry1 antibody and detection procedure were as described previously  (Ahmad et al. 2002; Bouly et al. 2007). The detected cry1 antibody-specific bands were analyzed by the ImageJ 1. 50i software (NIH) to obtain digital values for signal intensities of the slower migrating (phosphorylated) and faster migrating (non-phosphorylated) bands as described previously  (Shalitin et al. 2003; Xu et al. 2014 ). The extent of phosphorylation is expressed as the signal intensities of the slow-migrating bands normalized to the signal intensities of total cryptochrome protein (unphosphorylated plus phosphorylated cry1) in the same gel lane and represented numerically as a ration (cry1(Pi)/cry1). Each experimental sample plate was harvested in triplicate to obtain three separate readings per sample plate per experimental condition.
All experiments were performed double blind, such that the person measuring the seedlings did not know from under which condition they were taken. Hypocotyl lengths of 15 seedlings were measured per plate using the ImageJ 1. 50i software (NIH). For each experiment, the mean seedling length in the test condition (+MF) was expressed as a percentage of the mean seedling length of the local field (-MF) condition. Five independent biological repeats were performed under each condition to generate the average value presented in Fig. 3  for statistical analysis. In addition to the comparison between seedlings with and without exposure to 500 µT MF, we performed a control group experiment (Fig. 1 ), as for the phosphorylation experiments described above. For the control group, we performed the five replicate biological repeats, using two groups of plates grown under the same Helmholz coils as for the test hypocotyl growth experiments.
The data obtained from the MF group and control group were also subjected to the same analysis. The five or six independent values were then subject to statistical analysis (see below) and the average plotted on the graphs ± SE. The schematic of this experimental design is shown in Fig. 1. For statistical analysis, all data were analyzed by the SPSS Statistics program software IBM SPSS Statistics 23 (IBM). Data were analyzed for normality with the Shapiro-Wilk test (P < 0. 05) and homogeneity of variances with Levene (P < 0. 05). Results were expressed as mean ± standard error of the mean (SE). The differences between the MF group and the control group were compared using Anova analysis. Differences were considered statistically significant with a P value < 0. 05 (*), < 0. 01 (**), and < 0.
3a ). Quantitation of the phosphorylation was performed by the imaging software to determine the ratio of phosphorylated (upper band) to unphosphorylated (lower band) cry1 protein in each lane; then, the three independently determined values were averaged to obtain a numerical value for the phosphorylation under this condition. The effect of the MF for this single experiment was then expressed as the percentage change in phosphorylation between the MF exposed (average of 3 sample readings) as compared to the unexposed or 'mock exposed' samples (also averaged from 3 sample readings). The experiments were subsequently repeated in full at least five times. The data presented in Fig. 3b  represent the average of all of the six independent biological repeats, comparing the increase in phosphorylation after exposure to a 500 μT MF (MF, grey squares) at the indicated blue-light intensities.
Acknowledgements We are indebted to  Adam Purvis ,  Dorothy Engle  and  Haider Raad  for valuable technical assistance and support at many stages of the project. Support was from  NSF  (# 1658640 ),  AFOSR  ( FA9550-14-0-0409 ) and  AFOSR  ( FA9550-17-1-0458 ). Open Access This article is distributed under the terms of the Creative Commons Attribution 4. 0 International License (http://creat iveco mmons. org/licenses/by/4. 0/),which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
coli DH10β using an existing limonene-production pathway  9  (Figure  1B ) and TB media and compared to the performance in 5 mL shake cultures. In this system, a previously described IPTG-inducible MVA pathway  31  was encoded on one plasmid (pMVA), while the aTet-inducible trAg-gpps and trMs-limS genes (Table  S1 ) were on a second plasmid driven, allowing differential regulation of the two modules. Increased throughput allowed screening of multiple inducer concentrations (25 conditions) with 3 biological replicates in a single plate (75 wells). There was a clear differentiation of limonene titers between induction conditions (Figure  S2 ), with production up to 8. 0 (± 0. 2SD) mg/L org compared with 350 (± 7. 6SD) mg/L org observed at the 5 mL scale as seen previously. Testing the pathway (pJBEI6410) and conditions employed by Alonso-Gutierrez and colleagues  31  (E.
The new pMVA2lib2 library displayed a clear enrichment for high producers, with all functional clones displaying improved limonene production relative to pMVA2 (Figure  3B ). In the highest producers, up to double the limonene production compared to that from pMVA2 was observed and included clones with higher production than the best members of pMVA2lib1. Plasmid DNA from the top 23 producers from pMVA2lib2, plus the top producer from the first library (pMVA2RBS041), were reintroduced to fresh cells. Triplicate screening confirmed their high production levels, with over 3-fold higher production relative to pMVA2 (Figure  S10 ). However, pMVA2RBS041 was the second highest producer in this rescreening. This data clearly shows that the "machine learnt" library was successfully enriched in high producers of limonene but did not allow the discovery of any significantly higher producers than observed during screening of library pMVA2lib1, suggesting that a good representation of the whole library was observed.
Q-TOF vendor binary files were converted to open source mzXML data format 42 using ProteoWizard msConvert. 43 , Automated limonene quantitation was conducted using inhouse scripts written in R to automatically extract relevant peak areas. Quantification of limonene was conducted by extrapolating the limonene/sec-butylbenzene peak area against the generated standard curve. Reported titers are shown as either "fold-change" (FC) relative to a control, or as an absolute concentration in the organic phase (mg/L org ). Machine Learning. RBS sequences for each ORF in a plasmid and their associated titers were compiled and used as a training set for machine learning. To that end, we used one-hot encoding of DNA sequences to form the input feature training set,  44  where each component in the vector corresponds to a different nucleotide base at a specific position in the RBS site with at least two variants in the training set.
Model-Driven Engineering (MDE) is widely applied in the industry to develop new software functions and integrate them into the existing run-time environment of a Cyber-Physical System (CPS). The design of a software component involves designers from various viewpoints such as control theory, software engineering, safety, etc. In practice, while a designer from one discipline focuses on the core aspects of his field (for instance, a control engineer concentrates on designing a stable controller), he neglects or considers less importantly the other engineering aspects (for instance, real-time software engineering or energy efficiency). This may cause some of the functional and non-functional requirements not to be met satisfactorily. In this work, we present a co-design framework based on timing tolerance contract to address such design gaps between control and real-time software engineering.
These jitters directly impact the quality of control functions, and, in the worst-case, they might jeopardize the safety of the system. Hence, it is important to consider these delays during the design phase of the control software. This work addresses the case where the input data acquisition is done locally on one node. It can be extended like in TrueTime  [2]  to cover the case of networked control systems, including "Industrial Internet of Things" (IIoT) applications, where data are transmitted over a network, which would increase the input jitters, as well as the input-to-output delays.
The benefits are reduced development time and avoidance of distortions (i. e. , semantic gaps) between the simulated and executed control programs. On the other hand, TrueTime and T-Res are essentially simulation environments that involve a step of model-to-code transformation (typically code generation), which may risk widening the semantic gap between model and executable code, requiring additional development effort. Generally speaking, the existing co-design simulation techniques are mainly concerned with enabling the study of the effect of timing variabilities on control performance, rather than addressing the design gaps between control and software viewpoints. Other works  [1, 6]  present co-engineering techniques where the initial controller is integrated in a virtual ECU. The behavior of the controller is then assessed through timing analysis tools whose results are injected into the controller model.
The co-design framework presented in this work encompasses three steps of the development cycle: (i) controller design; (ii) software scheduling and execution platform configuration; and (iii) run-time monitoring. Firstly, we discuss scheduling and stability viewpoint analyses supporting the proposed co-design and simulation environment. We rely on our timing-aware model-driven environment called Cyber-Physical Action Language (CPAL) for co-design in Simulink. We then present the CPAL constructs and timing annotations, central to our approach, which enable us to reproduce the timing irregularities of interest, such as jitters and varying input-to-output delays. CPAL provides the timing dimension to the controller design, which acts on the plant model in Simulink. We provide the CPAL execution platform for Simulink as open access for experimentation.
Along with existing jitter analysis tools, the proposed co-design platform helps designing stability guaranteed controller models by integrating the target-platform timing behavior. Furthermore, it provides software engineering with the control information needed to bound the space of feasible software design solutions. The stability verification itself is done with the help of the jitter margin concept and the co-simulation of CPAL execution in the Simulink environment. The second contribution is the verification of the timing tolerance contract assumptions made during controller design. The verification is specifically useful when a new control function is integrated into an existing stable and functioning ECU. How can we analytically validate whether the system maintains the desired performance (stable and schedulable) after integration? To this end, we propose a novel schedulability analysis for a certain class of task and execution models in real-time scheduling.
Framework Steps To bridge the control-computing gap, we propose a framework that fuses the control and scheduling viewpoints in the context of model-based system design. Figure  1  shows the overall step-by-step flow of the framework. Step 1: Controller Design Based on the functional and non-functional requirements, the first stage of the framework is the control study, that determines the control equations that will potentially allow the system to achieve the required control performances. This control study relies on the designer's expertise with the help of control-system simulators like MATLAB/Simulink, which include the plant model. We note that at this stage the timing issues are not considered, and in particular the implementation delays are ignored, which may require to revisit the choice of the control law later in the design flow.
The simulation mode CPAL interpreter is an execution engine hosted by an operating system. The simulation execution can be carried out in a stand-alone built-in simulation environment  [18]  or it can be used in co-simulation environments, for instance as in this work integrated in MATLAB/Simulink as an S-function. CPAL aims to achieve the same temporal behavior in simulation mode and real-time mode on the target. This property is referred to as timing equivalence. It can be achieved through timing annotations to inject delays in the simulation model. Figure  2  illustrates the CPAL timing annotations to inject input and output jitters in a control model. Like other modeling environments for control programs such as StateFlow, CPAL provides support for Finite State Machines (FSMs) with conditional and timed transitions.
As can be seen in Figure  3 , transitions can happen either when a boolean condition is true, after a certain time duration is spent in the active state, or the conjunction of both. A distinctive feature of CPAL is that it relies on model interpretation: a CPAL model verified by simulation can be executed directly on an embedded target such as ARM Cortex -M4 (FRDM K64F) and ARM Cortex -A7 (Raspberry Pi). Model-interpretation is well suited for rapid-prototyping  [19]  and prevents any distortion between models and code that could be introduced during code generation. A disadvantage of model interpretation is that it is slower than compiled code. For that reason, it is not always a practical solution for on-target execution. For the purpose of simulation on desktop machines, the execution time of the control part is however not an issue, especially in a co-simulation environment where simulating the plant is by far the most time-consuming task.
Co-simulation in MATLAB/Simulink In our proposed co-simulation approach, a controller model is designed in CPAL, and the plant model in Simulink. Controllers can easily be designed in Simulink too. However, Simulink out-of-the-box is not offering possibilities to study the performance of control loops subject to scheduling and networking delays. Indeed, varying execution times, preemption delays, blocking delays, kernel overheads cannot be captured in the standard Simulink environment. This can be done only with TrueTime  [2] , which, to the best of our knowledge, is the most widely used tool in the real-time and control communities to study control performance subject to timing irregularities. One should also cite T-Res  [4] , a more recent and modular version of TrueTime. In  [5] , we have discussed how to integrate the timing behaviour of the controller into Simulink models.
In this work, we have studied how CPAL timing-accurate interpretation in Simulink compares against TrueTime and T-Res. The important difference, and also the advantage of our co-modelling approach is that the same model used during simulation can be used on target, whereas TrueTime and T-Res are simulation environments. Also, like Simulink, CPAL is a high-level embedded systems specific language which favors productivity and correctness by providing domain-specific constructs and abstractions  [20]. In the case of the co-simulation of CPAL within MLSL, Simulink acts as the primary simulator while CPAL executes the controller model as an S-function, and is being called by the Simulink engine. The S-functions (system-functions) are high-level programming language description of a Simulink block written in C, C++ etc.
The CPAL control library is implemented as a mex (Matlab Executable) file, which executes the CPAL controller model. This CPAL controller is a generic execution engine that can run any CPAL model. Before execution, the CPAL source model is converted into a binary-equivalent representation (an Abstract Syntax Tree, shortly ast file format) using the CPAL parser. The Simulink engine interacts with the CPAL model through data flows and control flows. Data flow, for instance force_ out in Figure  4 , are used for the exchange of information between the Simulink engine and the CPAL controller, while the control flows define when Simulink invokes the CPAL S-function. The implementation is discrete-event-based simulation using Simulink built-in zero-crossing detection. The concept of tasks and real-time schedulers are available natively in CPAL.
Worst-Case Execution Time (WCET) Measurement The CPAL controller model which we executed earlier in the co-simulation environment is now uploaded to the target platform to estimate the WCET by measurements. The CPAL model-interpretation engine is specific to a target platform, it can be executed on top of an Operating System (OS) or without an OS, the latter being called Bare-Metal Model Interpretation (BMMI). There are two ways to estimate the WCETs: using a logic analyzer or taking advantage of CPAL in-built execution-time measurement feature. The latter possibility is only available when CPAL is hosted by an OS, as freeRTOS, embedded Linux or Raspbian. It does not require connecting the target to an external measurement device and instrumenting the code, and thus provides a quick method to estimate the WCET.
It is, however, less accurate than measurements using logic analyzer, since it involves additional run-time overhead in the interpretation engine. For the discrete-time PID controller used in Section 5, the measured WCET of the CPAL controller task using logic analyzer is 34. 4 µs on a Raspberry Pi2 model B. This can also be obtained using the in-built feature of CPAL --stats, a command-line option to be used when we execute the model on target. When we remove the code of the actual control algorithm, leaving just the skeleton of the tasks, we can observe the scheduler overhead, which amounts to 155 µs. When we execute the model as it is, we observe the scheduler overhead plus the execution time of the task to be 189 µs. The difference between these two values would then provide the execution time of the task, 34 µs, which is indeed observed also on the logic analyzer.
Using this algorithm, we can derive the worst-case response times of all task. To check schedulability, we verify that these response times are less than or equal to the fine-tuned deadlines, which we have obtained from the previous step. To achieve transparency and to ease the reproduction of the results, the source code of the programs used in our experiments, including the schedulability test, is available online (https://www. designcps. com/ wp-content/uploads/cpal_codesign_framework. zip). The source code enables the reproduction of the experiments presented in this paper, as well as evaluation for different parameters settings. The tool cpal2x (see  [17]  for usage), which is available in the CPAL distribution, extracts the timing information (timing and scheduling annotations) from the controller function designed at Step 1.
The two latter works did not apply directly to our task model, i. e. , periodic task with release offsets. Sangiovanni-Vincentelli et al. discussed various methodologies to address the system design challenges in  [31]. This work highlights the importance of Assume/Guarantee contracts during component design and explains how a contract can be applied to the design of a water flow control system. Derler et al. proposed in  [7]  that implicit timing assumptions are made explicit using design contracts to facilitate the interaction and communication between control and software domains. The authors discussed the support for timing-contracts-based designs using Ptolemy and Simulink. Benveniste et al. proposed in [32]  to apply contracts to design methodologies. Importantly, the authors explained the mathematical concepts and operations necessary for the contract framework.
All these works mentioned in this paragraph focused on the fundamental framework for design contracts, such as contract algebra applied in system design, and timing contract visualization in modeling environment. In this work, we are concerned with the application of timing tolerance contract in our Model-Based Design flow used to develop control software, thus focusing on scheduling and implementation issues. In terms of related design environments, we identify two approaches with associated tools aiming to support control system design considering the influence of scheduling strategies: • TrueTime: this MATLAB/Simulink-based tool  [2]  enables the simulation of the temporal behavior of controller tasks executed on a multitasking real-time kernel. In TrueTime, it is possible to evaluate the performance of control loops subject to the latencies of the implementation.
TrueTime offers a configurable kernel block, network blocks, protocol-independent send and receive blocks and a battery block. These blocks are Simulink S-functions written in C++. TrueTime is an event-based simulation using zero-crossing functions. The tasks are used to model the execution of user code and are written as code segments in a MATLAB script or in C++. It models a number of code statements that are executed sequentially. • T-Res: this more recent tool  [4]  is also developed using a set of custom Simulink blocks created to simulate timing delays dependent on code execution, scheduling of tasks and communication latencies, and verifying their impact on the performance of control software. T-Res is inspired from TrueTime and provides a more modular approach to the design of controller models enabling to define the controller code independently from the model of the task.
These tools and methods focus on simulation and analysis. They both help the designer to study the control system performance under the effects of timing delays. The system designer then takes simulation analysis results into account to develop the embedded control algorithms in the next steps. This increases the possibility of distortions between the simulation model and the implementation. An advantage of our co-simulation modelling approach is that the same controller model used to evaluate the control performance during design phase can be re-used directly on the target hardware (in the coding and testing phase) to implement the system. As discussed in our previous work  [5, 19] , the reduced development cycle favors efficient interactions between control and software engineers. The reader is referred to  [5]  for a review of CPAL in Simulink, TrueTime and T-Res development environments.
Background: Multiple RNA samples are frequently processed together and often mixed before multiplex sequencing in the same sequencing run. While different samples can be separated post sequencing using sample barcodes, the possibility of cross contamination between biological samples from different species that have been processed or sequenced in parallel has the potential to be extremely deleterious for downstream analyses. Results: We present CroCo, a software package for identifying and removing such cross contaminants from assembled transcriptomes. Using multiple, recently published sequence datasets, we show that cross contamination is consistently present at varying levels in real data. Using real and simulated data, we demonstrate that CroCo detects contaminants efficiently and correctly.