dataesr/scientific-paragraphs-categorization huggingface dataset:
The elements for setting the reference input (set point) and perform the comparison against the system measurements are combined in a crossed circle. This block diagram reflects the relative simplicity of the "autonomous" but independent elements used in control engineering. This simplicity hides the very specific and natural electro-mechanical properties (e. g. , resistance, capacitance, inductance) of these elements. In contrast, in the MAPE-K model the elements are interdependent and their functions are specified in a general way. Concerning the characteristics of the different control strategies, control theory takes advantage of exactly the particular complex properties of the matter that constitutes both the controller elements, as well as the system to be controlled. In the case of software artifacts, even though they lack the physical properties analyzed in control engineering, these artifacts are given particular properties of behavior by their particular design.
In addition, the entire software system would be less affected by the computational effort of each of the three subsystems. The separation of concerns made explicit by the DYNAMICO model is particularly crucial for cases such as the cloud-based e-commerce platform presented in our application example. In this example, the automatic reconfiguration of the monitoring strategy would not be feasible without having the context manager as an independent implementation of the adaptation mechanism. In the same way, the explicit control of changes in SLAs requires separate instrumentation. In the case where a dynamic adaptation mechanism is necessary, having a self-contained adaptation strategy (i. e. , planner and executor) will contribute to the preservation of desired properties. The chapter "On Patterns for Decentralized Control in Self-Adaptive Systems", by Weyns et al.
Comparing DYNAMICO to Other Self-Adaption Models With DYNAMICO we intend to provide software engineers with a simple, but useful guide to (i) identify the minimum components required for implementing highly dynamic adaptive systems (i. e. , facing highly changing contexts); and (ii) realize and control effectively the interactions among these components at runtime. Thus, our reference model aims to support software engineers in the implementation of dynamic mechanisms, by calling their attention to the necessity of reasoning about changes at the three levels of dynamics introduced by DYNAMICO. Moreover, our model constitutes a guide to analyze the effect of these changes in (a) the accomplishment of control objectives, (b) adaptation mechanisms, and (c) context relevance along the system evolution.
From the perspective of this research, highly dynamic adaptive systems are adaptive systems where changes in control objectives (adaptation goals) are supported at runtime. As a result, adaptation and monitoring mechanisms are capable of adjusting themselves, at runtime, accordingly. To address dynamics, feedback loops, their visibility, and separation of concerns among them and their components constitute key runtime drivers in DYNAMICO. Several contributions have recognized the importance of these drivers in the engineering of self-adaptive software. Feedback loop models from control theory address separation of concerns by decoupling controllers from target systems. From the perspective of adaptive software, this corresponds to a separation of concerns between adaptation mechanisms and managed systems  [9].
Our reference model characterizes the elements required to control adaptation mechanisms under highly changing execution conditions. These elements are the components of the three types of feedback loops, the control/data flow among their components, and the control/data flow among the three levels. DYNAMICO relies on the MAPE-K loop to characterize the components that define our control objectives, adaptation and monitoring feedback loops. However, DYNAMICO is independent of the particular strategies and technologies used for implementing self-adaptation. To characterize the elements of our reference model and the interactions among them, we analyzed 34 of the most representative research approaches to self-adaptation  [21]. The surveyed approaches range from control theory-based approaches to pure software-based approaches.
In control-based approaches, the managed system's structure is generally a nonmodifiable structure, and control actions are continuous signals that affect behavioral properties of the managed system. In software-based approaches, the managed system's structure is commonly a modifiable structure, and control actions are discrete operations, supported by software models and reflection, that affect the system's software architecture. We proposed DYNAMICO to guide the design and implementation of dynamic control capabilities along the whole self-adaptive systems spectrum. A software engineer can use DYNAMICO not only to instantiate, independently, each of the three feedback loops, but also to instantiate the interactions among these three feedback loops. Consequently, a DYNAMICO-based self-adaptive system can support changes in adaptation goals at runtime, as well as the use of these changes to adapt adaptation mechanisms and monitoring strategies accordingly.
Moreover, this adaptive instrumentation can keep track of changes in monitoring strategies that could indicate the necessity of revising adaptation goals. Revisiting the application example used throughout this chapter, an adaptive solution purely based on any the feedback-loop, the MAPE-K loop, or the FORMS model could not adapt automatically the monitoring strategy after re-negotiating the performance SLA, according to the new context monitoring requirements stated with the throughput SLO (cf. Sect. 2. 1). According to Bass et al. , the process of designing a concrete software architecture for a system should start either from a reference model or an architectural style, or from both  [14]. In either case, the process continues with successive refinement steps, where each step augments the previous one with additional information from further analysis of requirements in the problem domain, as well as global design decisions.
In light of this, the application of DYNAMICO must be complemented with specific design patterns, architectural styles, design profiles, frameworks, and even other more specific or domain-dependent reference models for designing self-adaptive software systems. In particular, architectural patterns for interacting control loops such as the ones described in Sect. 4 of the first chapter in this book-the roadmap-constitute a suitable approach applicable to the design and implementation of feedback loop interactions defined in our reference model. Similarly, approaches such as the MAPE-K loop extensions proposed by Vromant et al. may be applied together with DYNAMICO, and selected architectural patterns to support intra-and inter-loop coordination during the different phases of self-adaptation  [35].
Conclusions and Future Work In this chapter we have presented DYNAMICO, a reference model for engineering highly dynamic adaptive software systems. This kind of system must deal with highly dynamic contexts of execution, and effectively respond to, by evaluating their own behaviour at runtime and reconfiguring itself whenever it no longer satisfies its requirements. A highly dynamic context is characterized by (a) expected and unexpected changes in context conditions such as user location (in mobile software clients), network access point, service throughput and load (in the server side), time and calendar dates, and even user interests associated to specific locations and special dates; (b) dynamic changes in adaptation goals and user requirements, such as renegotiation of QoS levels for specific services; and (c) other sensible changes that affect the satisfaction of system requirements, such as unauthorized intrusions or faults.
As a reference model, DYNAMICO reconciles the many visions and contributions of different approaches for the development of self-adaptive software systems, whether they hide or exhibit the elements of feedback control loops. Nonetheless, our reference model emphasizes the visibility of these control elements and constitutes a guide to design self-adaptive systems in which the system goals, the target system itself, or the monitoring infrastructure must be adapted-assuming this is a crucial requirement for the system to be developed. Depending on these requirements, the model can be applied as a whole, with its three feedback loops, or partially, involving only a subset of them. We showed the applicability of DYNAMICO using a SOA governance application example based on an industrial case study.
Acknowledgments This work was funded in part by the  National Sciences and Engineering Research Council (NSERC)  of  Canada  under the  Strategic Networks Grants Program  ( NETGP 397724-10 ) and  Collaborative Research and Development program  ( CRDPJ 320529-04  and  CRDPJ 356154-07 ),  IBM Corporation ,  CA Inc. , Icesi University (Cali, Colombia ), and  Ministry of Higher Education and Research of Nord-Pas de Calais Regional Council  and  FEDER  under Contrat de Projets Etat Region (CPER) 2007-2013.
They may use elements of the current context of a given proof, as declarations, definitions, axioms, hypotheses, lemmas and already proved theorems to solve the current goal. Coq allows the integration of new tactics by two means: either by Ltac  [10] , a tactical language for Coq, or by the OCAML programming language  [14]. The first solution is less automated because of the difficulty to directly call an external program, in occurrence the Spike prover, and of file reading and writing operations. The second solution is based on an interface between Coq and OCAML which lets developers integrate their own tactics written in the fully featured OCAML language. On the other hand, no safety control mechanisms are provided. Hopefully, the proof terms built from tactics can be type-checked by the Coq kernel at the end of a proof script.
In addition, the lack of documentation and the 'not sufficiently explained' Coq source code usually make the implementation task difficult. The second solution will be detailed for proving even xx. Firstly, we present the full Coq script representing the axiomatic translation of the function-based Coq script from Section 3 and the proof of even xx : The soundness of the translation can be checked for each axiom, represented as a new theorem which is further proved. For example, the axiom even3 can be validated by the theorem: Theorem even3 soundness : ∀ x, even (S (S x )) = oeven x. intro x. simpl. trivial. Qed.
The Spike tactic comes into four variants: Spike -the ordering constraints are inferred by Spike directly from the specification. Spike equiv [ S 1 ,. , S n ] -each S i (i ∈ [1. n]) is a set of equivalent symbols. Spike greater [ S 1 ,. , S n ] -each S i (i ∈ [1. n]) is of the form {symb 1 , symb 2 ,. , symb n } such that symb 1 is greater than any of the symbols from the set {symb 2 ,. , symb n }. Spike equiv [ S 1 ,. , S n ] greater [ S 1 ,. , S n ] is the combination of the two previous cases. The tactic starts by extracting the Spike specification and the conjecture to be proved from the current section, then calls Spike to generate an implicit induction proof of the conjecture. If successful, a Coq script is generated from the Spike proof representing the Coq proof of an equivalent theorem to the current one.
The script is certified by the Coq kernel, then the equivalent theorem is applied to solve the original Coq conjecture. The proof is completed only after the Coq kernel has successfully type-checked the whole proof, i. e. , when the Qed command ending the proof is executed. We will detail each step of the tactic for the proof of even xx, schematised in Fig. 1  from the appendix. Extracting the Spike specification A Spike specification consists of two parts. The first one describes the sorts with their constructors and the defined function symbols by means of conditional equalities playing the role of axioms. The second part influences the way the proof will be performed. It includes the definition of the precedencies over the function symbols, the definition of the inference rules and the proof strategy.
It also includes the definition of the conjectures to be proved. The Spike tactic is able to extract all this information from the current Coq proof environment by the means of the "spike" OCAML module. Any Coq specification that intends to use the Spike tactic has to declare previously this module, as follows: Declare ML Module "spike". The Coq specification should define the functions axiomatically. One solution is to extract the axioms directly from the fixpoint definitions, then validate them as shown in the previous section for the axiom even3. The tactic starts by identifying the conjecture to be proved from the current goal, then translates all axioms existing in the current context, together with the sorts, function symbols and constructors. All definitions and conjectures are adapted to be accepted syntactically in Spike.
In order to ease the translation from Spike proofs to Coq scripts process, the generated Spike specifications may contain inline Coq scripts, for example declaring the signature of the function symbols using Parameter. Translating the Spike proof into Coq script The Spike prover is automatically executed on the generated specification using a mode that can produce Coq script from a proof, as shown in  [20, 22]. In the following, we only recall the key steps of the translation process. In order to reproduce the implicit induction reasoning, for each formula F a comparison weight W is associated. When F is instantiated, its weight has to be instantiated in the same way. This is achieved by factorizing variables using functionals of the form (fun x ⇒ (F,W)), where x is a vector of variables shared between F and W.
The generation of Coq script for the validation part is not fully automatisable, so it may lead to the failure of the Spike tactic. Moreover, thanks to the axiomatic representation, many of the unconditional axioms can now participate to automatize even more the translation process. Different rewriting operations have been simplified: i) unconditional rewriting of the current goal: any unconditional axiom can be added to a rewriting base. For our example, the corresponding script is: Hint Rewrite addS1 addx0 add1 add2 even1 even2 even3 oeven1 oeven2 odd1 odd2 odd3 eodd1 eodd2 : rewrite axioms. Ltac rewrite ax := autorewrite with rewrite axioms. During the translation process, any application of unconditional rewriting rule in the implicit proof will be replaced by rewrite ax. ii) conditional rewriting of the current goal: it is translated into rewrite name of conditional axiom.
iii) unconditional rewriting of a condition H of the current goal: it is translated into normalize with rewrite axioms in H, where normalize is a new Coq tactic we defined in order to rewrite H with the rewriting base rewrite axioms. The theorem equivalent to even xx is: Theorem true 91: ∀ u1, (even (add u1 u1)) = true. , excepting that it is expected to be proved in the context of the function symbols given as parameter to the Coq section including true 91. Once the Coq script has been successfully checked, it is imported into the current environment as a library. Besides that, if a theorem needs some other theorems to be proved in terms of lemmas, they should be put in the same section. Extensions. The Spike tactic can only define ordering constraints for the current proof. In order to deal with more complex proofs, two extensions are proposed: -SpikeWithFullind aug [ordering constraints] to integrate the augment technique into the proof strategy.
s. l. , and the Tirano site is located south of the western coast at an altitude of 150 m. The locations and management characteristics of the experimental sites are given in Table  2. All the sites received irrigation and fertilization inputs, so that the model could be parameterized under optimal growing conditions. For the rest of the study, each combination of site, year and treatment is called 'site' and named with a convention of 'site-year', for example, 'Ayr 92-93' for the Ayr field trial data during the 1992-1993 growing season. At each site, crop biomass and LAI were measured six to eleven times during the growing season. When replicate plots were available, we pooled the corresponding observations.
Meteorological forcing data ORCHIDEE-STICS requires hourly meteorological data that are usually interpolated from 6-hourly forcing files. We need to use the best possible meteorological forcing for the model at each site, to prevent the aliasing of climate forcing bias to parameter estimation bias. We thus gathered weather station measurements of precipitation, air temperature, and solar radiation (arguably, the best possible forcing) close to each site. For Australia, the data were downloaded from the website of the Australian Bureau of Meteorology (BOM), and for La Reunion, they were obtained from stations close to the field sites. However, these weather station data cannot be directly used to force ORCHIDEE-STICS, because (i) additional variables are required by the model (specific humidity, wind speed, pressure, and long wave downward radiation), and (ii) the station data were only available at a daily time step.
MetAmyl is based on a logistic regression model that aims at weighting predictions from a set of popular algorithms, statistically selected as being the most informative and complementary predictors. We evaluated the performances of MetAmyl through a large scale comparative study based on three independent datasets and thus demonstrated its ability to differentiate between amyloidogenic and non-amyloidogenic polypeptides. Compared to 9 other methods, MetAmyl provides significant improvement in prediction on studied datasets. We further show that MetAmyl is efficient to highlight the effect of point mutations involved in human amyloidosis, so we suggest this program should be a useful complementary tool for the diagnosis of these diseases.
However, it has been experimental demonstrated that the length of six residues, corresponding to hexapeptides, is essential and sufficient for a segment to induce amyloid conversion of an entire protein domain  [12, 13]. Understanding the role of short sequences in amyloid fibrilation is so crucial that the past few years have seen the development of a large number of methods dedicated to the prediction of amyloid hot spots in proteins. In 2011, Hamodrakas proposed an overview of the predictive methods and their related software published since 2004  [14]. The author provided a short description of different algorithms as for example: SALSA  [15] , 3D profile  [16, 17] , Pre-Amyl  [18] , PASTA  [19] , AGGRESCAN  [20, 21] , Zyggregator  [22] , TANGO  [23] , AMYLPRED  [24] , PAFIG  [25] , Net-CSSP  [26] , BETASCAN  [27] , FoldAmyloid  [28] , Waltz  [29].
The proposed approach is built on a statistical framework that aims at selecting and combining individual predictors by computing a weighted combination of predictor scores. The design of the linear combination is achieved through a logistic regression model that weights the input scores to provide the best estimate of the probability of a peptide to be an amyloidogenic segment. The estimation of our logistic model is performed on a publicy available training dataset  [16, 29]  and is decomposed into two main steps. In a first step, we automatically select the most informative and complementary set of individual predictors among the existing methods in the literature. The four selected predictors were SALSA, PAFIG, FoldAmyloid and Waltz. In our case, in a second step, weights are statistically assigned to each of the selected scores by maximizing a likelihood function.
The evaluation of MetAmyl is composed of two parts. In a first part, the training dataset is used to evaluate MetAmyl accuracy with respect to well-known predictors by estimating their capacity to correctly detect amyloid-forming hexapeptides as well as nonamyloid-forming hexapeptides. For this evaluation, cross-validation has been performed on the training dataset to accurately estimate the performances of MetAmyl. In a second part, we used two recently published dataset, one composed of 33 proteins from the amylome and the other made by randomly shuffle sequences from the the N-terminus of the Huntington's disease protein huntingtin, to investigate the predictive capacity of each compared predictor on experimentally-validated regions  [36]. Comparative analyses show that MetAmyl improves predictions on the three datasets.
MetAmyl score MetAmyl is based on a logistic regression model that aims at weighting the different input scores to provide the most relevant combination of individual predictors. In this study, we used eleven input scores in the logistic framework. These eleven scores correspond to eleven recently published predictive algorithms: PASTA, SALSA, AGGRESCAN, PAFIG, FoldAmyloid (5 tables), TANGO and Waltz. These eleven predictors were chosen as proposing either an executable code or a sufficiently detailed algorithm to be implemented. The design of our model relies on the training dataset and is composed of two main steps, both performed using the statistical software R  [37, 38]. First, we automatically select the set of individual predictors using stepwise variable selection algorithm  [39] [40] [41] [42].
This first step is common in supervised classification as variable selection generally alleviates the effect of the curse of dimensionality, enhances generalization by reducing overfitting and also improves model interpretability  [38, 42]. In our case, training the complete model, made by the 11 individual predictors, requires the estimation of 12 coefficients. With respect to the size of the training dataset (278 sequences), training of the complete model lacks in accuracy due to high variability in coefficient estimation. As a result, four individual predictors are statistically selected in MetAmyl as being the most informative and complementary set of individual prediction scores: SALSA, PAFIG, Waltz and the first table from FoldAmyloid. One can remark that the 7 other scores were removed as being correlated with the selected individual predictors.
Implementation, profile calculation and hot spot prediction MetAmyl is available online at the following url: http:// metamyl. genouest. org/. For an input amino-acid sequence, an amyloidogenic profile is computed by the use of a sliding window with a fix number of 6 amino acids. The score for each hexapeptide is obtained by applying MetAmyl score as described in Equation  1. The computation of the complete profile is performed by assigning the score of each hexapeptide to its third residue. MetAmyl has been designed to manipulate large scale datasets. We first computed the 64,000,000 hexapeptides scores corresponding to the combinatorial diversity of amino-acids and we stored them on the server. Thus, the building of the profile of an input sequence consists in uploading MetAmyl scores from the server instead of calculating it for each window, which accelerates the computation of the MetAmyl profile.
If the MetAmyl score of an hexapeptide is above the best global accuracy threshold, the hexapeptide is predicted as amyloidforming. The best global accuracy threshold is statistically obtained by maximizing a function of the sensitivity and the specificity of our meta-predictor on the training dataset. More precisely, we focused on maximizing the distance to the upper-left corner in the ROC curve, which corresponds to the cut-off that maximises the quantity (1{sensitivity) 2 z(1{specificity) 2  [43]. In our analysis, we obtained the same optimal cut-off by using Youden's J statistic that aims at maximizing SpecificityzSensitivity{1  [44]. A high specificity threshold and a high sensitivity threshold are also proposed as alternatives on the MetAmyl Website, allowing users to analyze their results in different conditions.