dataesr/scientific-paragraphs-categorization huggingface dataset:
The availability of raw data makes it also possible to engage a community effort to assess the impact of different methodological choices on the very same dataset. We analysed all 1112 subjects from ABIDE using validated automatic computational neuroanatomy tools. After quality control and additional inclusion criteria we retained a group of 681 subjects. We had 85% power to detect the Cohen's d=0. 23 effect obtained from our meta-analysis of the literature (2-sided t-test, alpha=0. 05). We did not find any statistically significant result, neither for mean total volumes, interaction with age or IQ. Our statistical analysis here was a linear model including group, age, sex, IQ and site as main effects, or additionally the interaction between group and the other covariates. Although the absence of group effect was clear, we repeated our analyses using the same metaanalytical procedure used to study the literature to rule out an eventual methodological artefact.
Every ABIDE site was considered as a different source of data and we computed a meta-analytical effect size using a random effects model weighting of each site's estimations by the inverse of the variance (thus giving more weight to sites with larger sample sizes, as in the case of the literature meta-analysis). Our meta-analysis was in agreement with the results of our linear models: a clear absence of group differences. We can also use the ABIDE results to better understand publication bias in the literature. Figure  9  shows a funnel plot combining the results for total cerebellar volume in the literature and the different ABIDE centres. Egger's test for funnel plot asymmetry provides again a suggestion of publication bias (p=0. 0478). More research, probably expanding the scope of our analyses to encompass more brain regions, would be required to better understand the underlying reasons of the excess of significant reports in the literature.
Interestingly, and although the site effect was substantial, the estimations from the ABIDE data were more precise than those from the literature (tighter confidence intervals), less heterogeneous. One reason for the lack of power in the literature (in addition to the small sample sizes) could stem from the significant heterogeneity across studies. This may be an important source of discordant reports, and makes it more difficult to draw conclusions from the literature. The public availability of raw data should greatly enhance our ability to understand neuroanatomical variability and increase our chances of detecting reliable neuroimaging phenotypes for neurodevelopmental disorders such as autism. Towards this aim, all our analysis scripts, our software for quality control, and the list of subjects we included have been made openly available on the Web, to facilitate the replication, critical appraisal and extension of our current results: https://github.
Acknowledgements The research leading to these results has received funding from the  Fondation de France  project " Développement du plissement cortical dans les troubles du spectre autistique : caractérisation morphométrique et génétique", ERA-Net NEURON Cofund Programme  under " Horizon 2020 " ( SynPathy  project),  Institut Pasteur ,  Bettencourt-Schueller Foundation ,  Centre National de la Recherche Scientifique, University Paris Diderot ,  Agence Nationale de la Recherche  programme  "Investissements d'avenir", Labex BioPsy ,  ANR-10-LABX-BioPsy ,  ANR-11-IDEX-0004-02 ,  Labex  GenMed,  ANR SynDiv, Conny-Maeva Charitable Foundation ,  Cognacq Jay Foundation ,  Orange Foundation ,  Fondamental Foundation. The group of LRR is member of the  Labex BioPsy and ENP Foundation.
There, it can be noticed how the agent has three main components: The generic component contains the control logic and all supporting functionality which is independent of the target diagnosis and load testing tools (e. g. , the analysis and planning tasks of the policies). Regarding the logic that interfaces with the target tools, it needs to be customised per tool. Therefore, this logic is encapsulated in their respective components to minimise the required code changes. To complement this design strategy, the components are only accessed through interfaces. This is exemplified in Figure  6 , which presents the high-level structure of the diagnosis tool component. It contains a main interface IDiagnosisTool to expose all required actions and an abstract class for all the common functionality.
Once the reports have been updated, the similarity of the new results is evaluated. This is done to further consolidate the results (as the outputs of a diagnosis tool tend to overlap when monitoring multiple nodes during extended periods of time). The rules to evaluate the similarity are retrieved from the knowledge database (as they will depend on the diagnosis tool). A set of standard statistic metrics (i. e. average, standard deviation and coefficient of variation  [71] ) is also calculated to gradually build an historical trend per report type. Next, a severity assessment is performed. This is done with the aim of helping a tester to concentrate on the set of performance issues worth exploring (as a diagnosis tool might produce a considerable amount of outputs and normally only a subset is truly relevant).
1 was enough to identify similar issues. 4. 6. 2. Severity Styles. As discussed in Section 4. 5, a severity style defines the set of severity categories in which a performance issue can be classified. This type of supporting logic is captured as a data analytics helper within PHOEBE. Furthermore, a severity style can be used within an assessment to customise its behaviour (e. g. , the Go No-Go assessment discussed in Section 4. 6. 3). Among the alternative strategies to develop severity styles for PHOEBE, we have initially concentrated on implementing the following two: • A five-level severity style based on the well-known (and commonly used in the industry) severity categories suggested by the International Software Testing Qualifications Board (ISTQB)  [73] : Critical, major, moderate, minor, and cosmetic  [74].
Finally, as the UI is not involved in the data gathering process, a constant value of 30 minutes was used. Environment. All the experiments were performed in an isolated test environment, so that the entire load was controlled. This environment was composed of eight VMs: A cluster of five application nodes with one load balancer, one diagnosis tool server, and one load tester node (as shown in Figure  11 ). All the VMs had the following characteristics: 4 virtual CPUs at 2. 20GHz, 3GB of RAM, and 50GB of HD; running Linux Ubuntu 12. 04L 64-bit, and OpenJDK JVM 7u25-2. 3. 10 with a 1. 6GB heap. The load tester node also used an Apache JMeter 2. 9  [14]  (a leading open source tool used for application performance testing), and the application nodes ran an Apache Tomcat 6. 0. 35  [76]  (a popular open source Web Application Server for Java).
The VMs were located on a Dell PowerEdge T420 server  [77]  equipped with 2 Intel Xeon CPUs at 2. 20Ghz (12 cores/24 threads), running Linux Ubuntu 12. 04L 64-bit, 96 GB of RAM, 2TB of HD, and using KVM  [78]  for virtualisation. Diagnosis Tools. The five performance diagnosis tools discussed in Section 2. 2 were used: Eclipse Memory Analyser (EMAT), IBM Garbage Collection Lite (GCLITE), IBM Garbage Collection and Memory Visualiser (GCMV), IBM Health Center (HC), and IBM Whole Analysis Idle Time (WAIT). This decision was taken to diversify more the evaluated behaviours. Benchmarks. One of the Java benchmarks most widely-used in the literature (DaCapo 9. 12  [79] ) was chosen because it offers a wide range of different program behaviours to test. Unlike other benchmarks (which are synthetically generated), these are real-life programs from different business domains and which are widely-used in the industry.
Experiment #5: Testing Productivity Assessment Here the objective was to further assess the benefits that PHOEBE brings to a performance tester (in terms of reduced effort and time) by comparing the automated usage of a diagnosis tool through PHOEBE against a purely manual usage of a diagnosis tool. The following sections describe this experiment and its results. 5. 5. 1. Experimental Set-up. The experimental set-up was similar to that used in the experiment #4 (presented in Section 5. 4. 1), with the following differences: First, the iBatis JPetStore 4. 0  [84]  application was used (with a workload of 2,000 concurrent users). JPetStore was selected because it is a well-documented open source application which is also easy to use. Second, the source code of JPetStore was modified to inject five performance issues (two lock contentions, two deadlocks and one I/O latency bug).
Discussion for Practitioners The presented experimental results have demonstrated how automating the configuration and usage of a diagnosis tool can significantly improve the performance testing process. In the following paragraphs, we provide guidelines for practitioners to indicate the conditions under which PHOEBE can yield improvements and discuss the wider applicability of the technique. • As discussed in Section 2. 1, performance testing is usually performed multiple times during a software project (i. e. , it is normally executed after a new version of the software is built). As there are usually budget or schedule constraints in such projects, using PHOEBE with a Go No-Go assessment (like the one discussed in Section 4. 6. 3) can be useful in the early phases of a project to make the most out of the performance testing, without the need of (necessarily) executing the test for its whole planned duration (e.
Likewise, an adaptive UI is suitable for enabling shared services (i. e. diagnosis tool servers which are shared across different testing teams or projects). This is because, as there are usually budget or schedule constraints in software projects, the amount of available licenses for a diagnosis tool is normally limited. Under these conditions, the capability of PHOEBE to efficiently enable a diagnosis tool as a shared service is highly desirable. • In the experimental evaluation, we selected five of the most widely-used Java diagnosis tools in the industry. As the results have shown, the achieved time/effort savings are evident for all the tested diagnosis tools, and so it is expected that PHOEBE can yield similar results when using other Java diagnosis tools (especially those using the same type of inputs -i.
e. heapdumps, javacores or GC verbose -). Likewise, it is expected that PHOEBE should be applicable to diagnosis tools used in other object-oriented languages (e. g. , Python or C#) as long as the appropriate data analytics helpers are developed to interface with those tools. • In the experimental evaluation, the participant testers were experienced ones. As the results have shown, the achieved time/effort savings are evident, and so it is expected that PHOEBE can yield better results when used by more inexperienced testers (i. e. undergraduates or postgraduates with little or no working experience in software development or testing). Likewise, a simplified two-level severity classification was used in the experimental evaluation. It is expected that PHOEBE can save more analysis effort whenever a more granular severity classification is used (e.
DaCapo Programs Name Description avrora A program that simulates a set of programs running on a grid of microcontrollers. batik A program that processes a set of vector-based images. eclipse A program that executes a set of performance tests in an eclipse development environment. fop A program that generates PDF files based on a set of XSL-FO files that are parsed and formatted. h2 A program that executes a set of banking transactions against a database-centric application. jython A program that executes a set of python scripts in Java. luindex A program that indexes a set of documents. lusearch A program that performs a set of keyword searchs over a corpus of data. pmd A program that reviews a set of Java classes, looking for bugs in their source code. sunflow A program that renders a set of images.
SVEP Unity 3D client In order to speed up the implementation of a client for a given device, we have developed a package for the Unity 3D game engine. This package makes it possible to disregard the network connection with the SVEP platform during the development of a client. Moreover, it allows to pool the architecture of all clients using Unity (Figure  6 ). A SVEP client is made of 5 modules: 4. 2. 1 SVEP Core. The SVEP Core module is in charge of the communication between the clients and the hosted 3D environments (Figure  7 ). It also deserializes messages sent by SVEP into standard objects and it controls the other modules.
Tested devices In order to evaluate the portability of 3D environments developed according to our model, we implemented three clients (Figure  1 ) for the SVEP platform and could verify that the development of a single application allows the portage of all the 3D environments on a new device. The main stages of the implementation are summarized below and in Table  1. 5. 1. 1 Scene. Since the computing power and the graphic capabilities are similar, all the tested devices share the same implementation of the Scene module. [4]  to perform, in real time, the tracking with markers using the ARToolKit.
System overview Our system consists of several strategies, summarized in Figure  1 : depending on the treebank size, we build and compare several parsers with various designs, and finally submit the parser or parsers combination performing best on development data. For a few languages, we also improve preprocessing by correcting errors in the tokenization predicted by UDPipe  (Straka et al. , 2016). Most of the parsers we consider are based on the literature or our previous works, but for some languages, we also experiment with a new method for combining base parsers. This method is designed to better leverage each available resource in a lowresource context. Indeed, state-of-the-art methods for low-resourced parsing generally focus on exploiting one type of resource (e. g. parallel data) to build a model, neglecting the others.
We experiment with three heuristics to reduce the source set: retaining only treebanks over 2,000 sentences, treebanks that minimize the number of rewrite rules, and the top 5 treebanks according to the KL cpos 3 metric; the best heuristic depends on the language and is tuned on target data. Most base parsers are trained in a few hours on CPU, using a single thread (excluding hyperparameter tuning); exceptions are for instance Czech and Russian-SynTagRus, whose treebanks are notably large, and parser projection to Hungarian, due to parallel data much larger than other pairs. Hence, each component parser is retrained 5  both to specialize on its competence region, and to take into account the knowledge provided by the previous components. To ensure that the final output is complete, the last component trains on full parses and annotates any remaining token.
Model selection For each treebank, we compare all base and cascade parsers, and retain the parser yielding the best LAS on the provided development set (using gold tokenization). However, in some languages this dataset was particularly small and consequently biased, which often led to selecting the wrong model, as will be seen in §4. For the PUD treebanks, i. e. extra test sets of a UD language but which do not correspond to a given UD treebank, when there are several UD treebanks for the same language, we choose the model whose LAS on own development data is the highest. This corresponds in practice to choosing the largest treebank (in number of sentences), except for Swedish-LinES. This choice is analyzed in detail in §4. 5.
When two consecutive (orthographic) tokens have a very high (resp. low) PMI, they are joined into a single word (resp. split, if UDPipe had joined them). We do not allow words with more than 2 orthographic tokens; in case of conflict the pair with highest PMI is joined. PMI values are computed using the unigram and bigram counts of orthographic tokens in the crawled monolingual data (after UDPipe tokenization, to segment punctuation); in case of OOV the pair remains unchanged. We set the PMI lowerand upperbounds to log 5 and log 400. Chinese and Japanese We rely on UDPipe for sentence segmentation, and then use KyTea  (Neubig et al. , 2011)  to tokenize each sentence. KyTea models are trained on UD Chinese and Japanese training treebanks. For all three languages, the newly tokenized input is then morphologically annotated by UDPipe.
Overall results As part of the CoNLL 2017 UD Shared Task, we evaluated our system on the TIRA platform  (Potthast et al. , 2014). Evaluation runs on the virtual machine took 10. 5 hours on a single thread, using up to 6GB RAM. Table  1  presents our overall results as published by the organizers, compared to the UDPipe 1. 1 baseline. Results rank our model first in tokenization and second in morphological tagging, although these improvements are due to our tokenization improvements on only 3 languages. Regarding LAS, and according to the various strategies that were adopted, our system presents various behaviors depending on the treebank group, and sometimes even among treebanks of the same group, e. g. surprise languages (see §4. 4). However, the publication of the results, and careful comparison with the baseline UDPipe submission, revealed huge unexpected drops on the PUD treebanks, associated to differences in model selection.
Analysis In this section, we present the strategy that was adopted for each treebank, along with detailed analysis on the results. The analysis is conducted separately for the treebanks with custom tokenization, the large (over 10,000 training sentences), medium and small (under 1,000 sentences) UD treebanks, and for PUD treebanks. Throughout the section, we report both official results from the TIRA platform, and our own measures using the official evaluation script on the released test files  (Nivre et al. , 2017b). The latter are displayed in italics. Table  4 : LAS results on the medium treebanks. The models selected on development data are underlined. For pt, ro, sl, id, ur, sl sst and en partut, we rather selected UDPipe+PanParser. In most cases, our submission is simply the baseline UDPipe, as we did not focus on improving the system for large treebanks.
For these, the only difference with the base-line is that we selected different treebanks. In order to understand these drops, we performed a systematic evaluation of various preprocessing and parser choices, comparing the same system with different training data. Table  6  reports, for each PUD treebank, the results when applying each UDPipe pipeline on gold segmentation, and when combining each UD-Pipe preprocesser (segmentation and tagging) with each UDPipe parser. Experiments with PanParser yield consistent results. In some cases, important drops seem due to incompatible preprocessing between treebanks of the same language: in English, Portuguese and Swedish, the 'main' scores are much lower and 'variant 1' scores much higher when replacing 'main' preprocessing by 'variant 1'. As the preprocessing provided by the organizers was systematically produced by the 'main' UDPipe model, this certainly affected our submission, which used the provided preprocessing even when not using the 'main' parser.
Conclusion Our submission to the CoNLL 2017 UD Shared Task focuses on low-resourced dependency parsing. Our system is built upon base parsers, and combines them using a cascading algorithm, in order to leverage small and incomplete data. This shared task was an opportunity to experiment with this new cascading method in realistic conditions; this is particularly interesting, since this method addresses precisely realistic scenar-ios where available data does not consist in either large monolingual data or large parallel data, but in various amounts of each resource type. The method has proved useful in many cases, with sometimes large improvements, but the gains are not consistent enough to be reliable and still require further work. The shared task conditions have indeed uncovered several challenges faced by the method: it lacks confidence mechanisms, delexicalized models are too unreliable, and the lack of development data hinders accurate estimation of competence regions for the components of the cascade.
INTRODUCTION SiC MOSFET devices have a wide operation ranges in voltage, current and temperatures, then the knowledge of their characteristics and disposal of a good model become necessary. As wide as is the model validity domain, more and more high can be the control precision to achieve a high efficiency  (Maxim and Maxim, 1999; Pushpakaran et al. , 2015). A simple analytical PSpice model for SiCMOSFET have been proposed for high power modules in  (Johannesson and Nawaz, 2016). In this paper we are interested by the SiC MOSFET C2M0025120D CREE (1200V, 90A), when operating at very high frequencies. The MOSFET device characteristics can be extracted from manufacturer's experimental curves (data sheets). Simulations are very important in electric systems design as well as for mechatronics case study.
Prototyping is necessary for the optimization of power electronic circuits. To get realistic simulations and accurate results, we need good and precise models for an operating domain as wide as possible  (Leonardi et al. , 1997). The models proposed in the well known simulation softwares like Psim, Pspice, LMS AMESIM, Saber and other are often limited in their precision, field of application or complexity. The most of them are piece-wise linear. They are very, often valid only in a restricted area and must be completed using the components Data Sheet. To get reliable re-sults based on simulations, we need accurate models, with acceptable precision. The precision of these models are very often limited to some operational points or region. The devices may be, in some applications, used in very wide operation ranges  (Bejoy et al.
SiC MOSFET Electric Model In figure  3. 1, we present the model we have developed for and implemented under Pspice, to simulate the the SiC MOSFET C2M0025120D proposed by CREE. Note that this model is more precise, with regard to the LTspice model proposed by the manufacturer CREE  (Bejoy et al. , 2015b)   (Bejoy et al. , 2015a) , as it is composed by 2 switched current sources. In addition it takes into account package parasitic inductances (L G , L D , L S ) connected to the gate, drain, source and resistances (R G , R DSon ). The inductances and resistances allow description of power losses in commutations. The resistance R G describes the Gate power losses in high frequencies operation. α and n define the triode région and λ is the length of the MOSFET conduction channel. The gate threshold voltage is noted V th.
The PV control System simulation The PV system, described in section 2, plus the estimation and control circuits of section 4, are simulated under the physical modeling oriented software Pspice. The irradiation is considered, for the first simulation, fixed at 100W /m 2 with the temperature T j = 25°C. The proposed control generates a good PWM signal with as duty factor 0. 7. In the same figure 4. 3-F1 and F2 show the voltage and current of the PV panel in green (V pv , I pv ) and the outputs of the DC/DC converter (V s , I s ). The PV output voltage is V pv = 13. 36V. The DC/DC output voltage is V s =49V>V pv , and the current is I s = 0. 99A < I PV = 4. 05A. The figure 4. 3-F3 shows that the PV output power P pv = 54, 6W (in green) is practically completely transmitted by the DC/DC converter to the load P s = 50, 43W (in red).