dataesr/scientific-paragraphs-categorization huggingface dataset:
The code responsible for parameter parsing resides in the directory: $SCRIPTS/mcprod/alpgen/utils_alp which also contains a dictionary of unweighting and MLM matching efficiencies that enables the generation of a number of final unweighted ALPGEN + parton-shower events as specified by the user. The driver scripts for weighted and unweighted event generation reside in the directory: $SCRIPTS/mcprod/alpgen/mcrun_alp This directory also contains generator-level event filters, used by some of the analyses in order to enable efficient filling of the histograms. The files in the two directories just mentioned, utils alp/ and mcrun alp/, are used by the rungen. sh script. The script supports optional additional arguments beyond the standard $mode $conf ones (described in sections 5. 1 and 5. 2), so that extra generator-specific parameters can be included.
Steps 4. 1, 4. 2: from single run histograms to Physical Distributions After the analysis run in step 3 in figure  11 , the MCPLOTS framework merges the single run histograms with the rest of the compatible analysis runs preceding it (steps 4. 1 and 4. 2). In some cases the single run histograms already correspond to Physical Distributions and the merging is done in order to improve the statistical precision. In other cases several single run histograms need to be combined in order to obtain the Physical Distributions. For the histogram merging it is assumed that the histograms scale linearly with the number of events. The merging code is located in: $SCRIPTS/mcprod/merge. Once a new source histogram (h0, h1 or h2) in figure  11  is obtained, it should be merged to a common destination with the prior compatible histograms in the database.
The exact paths are specified in the runRivet. sh script and contain the entries of the rivet-histograms. map described in section 4. 3 as well as the generator, version, tune and any generator-specific parameters passed to the MCPLOTS scripts. The source file path and name thus provide the analysis and generator information to the merging script. This information is used in the script to decide which of the steps to perform and other merging details (detailed below). An example use-case that requires only one pass of the merging code is, the standard one of combining multiple runs with different random-number seeds but otherwise identical settings. An example use-case of the run that requires the second pass of the merging code is filling of the histograms for the production of W /Z bosons in association with jets at the LHC, in the context of multi-leg matrix-element matched samples.
) extra partons in the case of ALPGEN or MADGRAPH in which case the exclusive matching criterion must be used for all but the highest multiplicity sub-sample which is matched inclusively. Multiple sub-samples could also be produced with different phase-space cuts to enhance the number of events in the target corners of the phase-space, such as cuts on the transverse momentum of the hard process partons, such that the high-p T events can be produced with higher integrated luminosity than the low-p T events. The merging code contains a procedure to detect and correctly sum the resulting histograms as illustrated in figure  11. The correct merging procedure of the histogram data depends on the normalization already assumed in the RIVET routines. In practice all the current use-cases could be addressed by adding two merging modes ALPGEN XSECT and ALPGEN FIXED to the merging machinery.
The ALPGEN XSECT mode is used for histograms from RIVET runs, when no normalization is performed by RIVET. The ALPGEN FIXED mode is used for histograms that are normalized according to the cross-section by RIVET. The new histograms from the run with Np partons is merged with the existing histograms for the Np sub-sample. The weights for merging of all the Np samples needed to form the generator prediction for the observable are than evaluated such that all the Np sub-samples are normalized to the same integrated luminosity in ALPGEN XSECT, or with unit weights for ALPGEN FIXED mode correspondingly. The choice of the correct merging procedure is implemented in the merging script merge. sh and relies on the histogram naming conventions. In particular the entries of rivet-histograms. map, that are constituents of the histogram path, can serve to assign the correct merging mode according to the analysis and generator details.
7 LHC@home 2. 0 and the Test4Theory Project LHC@HOME started as an outreach project for CERNs 50th Anniversary in 2004. The project calculated the stability of proton orbits in the LHC ring, using a software called SIXTRACK  [63] , distributed to volunteers via the Berkeley Open Infrastructure for Network Computing (BOINC) [39], a popular middleware for volunteer computing. When MCPLOTS was initially conceived, it was clear that significant sustained computing resources would be needed, and it was natural to consider if a setup similar to that of SIXTRACK could be created to meet those needs. The three main reasons were: 1) the computing resources envisaged for MCPLOTS would have been comparable to (or larger than) the total amount of computing power then available to the CERN theory group; 2) the developers of LHC@HOME were keen to explore possibilities to expand the volunteer computing framework towards HEP physics simulations; 3) we saw event simulations as providing a natural way to involve the public in doing LHC science, without the complications that would have accompanied analysis of real data.
Acknowledgements We are indebted to many members of the  Monte Carlo community  for their feedback and help with validations of the generators and analyses included on MCPLOTS. Many short-term students, visitors, and fellows have contributed with RIVET analyses and other content to the site, in particular  D. Konstantinov  (the MCPLOTS plotting tool),  A. Pytel  (server infrastructure and the MC validation view),  S. Sen  (forward LHC analyses in RIVET and on MCPLOTS, and implementation of the EPOS and PHOJET generators), and  J. Winter  (the t t MC analyses). We thank  J. Katzy , for carefully reading this manuscript and giving feedback on the MCPLOTS site,  M. Mangano , for his strong support of this project from its inception to completion and for help with the ALPGEN implementation, and  T.
Pierog , for help with the EPOS implementation. We express our profound admiration of the teams responsible for the development of RIVET, CERNVM, and  LHC@HOME 2. 0 , without which the  TEST4THEORY  project would have been impossible. Thanks also to the many volunteers who have provided computing resources, especially to those who have taken active part in the alpha and beta testing phases of  TEST4THEORY. We also thank the  CERN PH-SFT group , in particular the Generator Services (GENSER) team, and the  CERN IT Division. This work was supported in part by the  LHC Physics Center at CERN (LPCC) , by the  Marie Curie research training network "MCnet " (contract number  MRTN-CT-2006-035606 ), and by the  National Science Foundation  under Grant No. NSF   PHY11-25915.
Yet, STICS is a generic crop model, because from a set of common equations it can describe a large number of crop species through specific parameterizations. Similarly, specific vectors of parameters define crop cultivars. STICS has been validated for a variety of cropping situations  (Brisson et al. , 2003)  ORCHIDEE  (Krinner et al. , 2005)  is a land surface model developed for global applications, standing now as the land surface model of the IPSL Earth System Model. It has been developed from the association of a surface energy and water balance scheme (SECHIBA) with a biogeochemistry module (STOMATE) and as such simulates the short timescale exchanges of water and energy between the land surface and the atmosphere, as well as the processes of the carbon cycle including photosynthesis, respiration, carbon allocation, and soil decomposition.
The results of the Morris screening algorithm can be represented by a 2-D plot of standard deviation versus mean value of the elementary effects on the output variable (here harvested biomass) of each parameter. A parameter with a high mean elementary effect (called µ, or µ * for mean of absolute values) is interpreted as a parameter with high influence on the output harvested biomass variable. A parameter with a high standard deviation of its elementary effects (σ ) is interpreted as inducing non-linearities in the model output, and/or as having interactions with other parameters. Here, we apply the Morris method as implemented in the R "sensitivity" package  (Pujol et al. , 2013)  using site-scale simulations of ORCHIDEE STICS across the seven field trial sites listed in Table  1. For each site, we identify the most influential parameters for the output variable harvested biomass.
The results for Ayr in 1991-1992 display a less clear pattern. Indeed, at the end of the cycle, the contributions of ORCHIDEE and STICS to the total uncertainty are almost equal, due to an increase in STICS contribution during the second half of the cycle. This result confirms a hypothesis made in  Valade et al. (2013)  where the difficult calibration of LAI at this site was attributed to the simulation by STICS of an important stress. Indeed if a large stress is simulated by the phenological module, this can impede ORCHIDEE processes of biomass growth and therefore increases the weight of STICS parameters with respect to ORCHIDEE ones.
We found that all these parameters together contribute to an overall uncertainty of 21 % on sugarcane biomass simulations with an agro-LSM model and that this amount is variable among sites with different climatic, edaphic and management situations. We also analyzed this uncertainty separately for each component of the model and found that whatever estimate chosen for the input parameter uncertainty, by the end of the growing season, the uncertainty propagated from the phenology module STICS decreases and the overall uncertainty is almost totally explained by the OR-CHIDEE uncertainty. The lower uncertainty from STICS parameters compared to ORCHIDEE is likely related to the lower number of processes solved by STICS in its configuration with ORCHIDEE, and to some extent to the lower number of parameters propagating their uncertainties.
This paper describes the development operated into MANY, an open source system combination software based on confusion networks developed at LIUM. The hypotheses from Chinese-English MT systems were combined with a new version of the software. MANY has been updated in order to use word confidence score and to boost n-grams occurring in input hypotheses. In this paper we propose either to use an adapted language model or adding some additional features in the decoder to boost certain n-grams probabilities. Experimental results show that the updates yielded significant improvements in terms of BLEU score.
Introduction MANY  (Barrault, 2010)  is an open source system combination software based on Confusion Networks (CN). The combination by confusion networks generates an exponential number of hypotheses. Most of these hypotheses contain ngrams do not exist in input hypotheses. Some of these new n-grams are ungrammatical, despite the presence of a language model. These novel ngrams are due to errors in hypothesis alignment and the confusion network structure. In section 3 we present two methods used to boost n-grams present in input hypotheses. Currently, decisions taken by the decoder mainly depend on the language model score, which is deemed insufficient to precisely evaluate the hypotheses. In consequence, it is interesting to estimate a score for better judging their quality. The challenge of our work is to exploit certain parameters defined by  (Almut Siljaand and Vogel, 2008)  to calculate word confidence score.
These features are detailed in section 4. The approach is evaluated on the internal data of the BOLT project. Some experiments have been performed on the Chinese-English system combination task. The experimental results are presented in section 5. Before that, a quick description of MANY, including recent developments can be found in section 2. 2 System description MANY is a system combination software (Barrault, 2010) based on the decoding of a lattice made of several Confusion Networks (CN). This is a widespread approach in MT system combination, see e. g. (Antti-Veikko I. Rosti and Schwartz, 2007; Damianos Karakos and Dreyer, 2008; Shen et al. , 2008; Antti-Veikko I. Rosti and Schw, 2009). MANY can be decomposed in two main modules. The first one is the alignment module which is a modified version of TERp  (Matthew G.
Language models Three 4-gram language models named LM-Web, LM-Tune and LM-Test, are used to interpolate the adapted LM. They were trained respectively on the English web Corpus and the system outputs : development and test sets (except their references) involved in system combination, using the SRILM Toolkit  (Stolcke, 2002). The resulting model from the interpolation of LM-Tune and LM-Test is interpolated linearly with the LM-Web to build the adapted LM. These models are tuned to minimize the perplexity on the tune reference.
Experiments During experiments, data from the BOLT project on the Chinese to English translation task are used. To explore the impact of each new feature on the results, they are tested one by one (added one by one in the decoder) then both, given that, the oldest ones are used in all cases. These tests are named respectively boost-ngram, CS-ngram and Boost-ngram+CS-ngram later. The language model is used to guide the decoding in order to improve translation quality, therefore we evaluated the baseline combination system and each test (described above) with two LMs named LM-Web and LM-ad and compared their performance in terms of BLEU. By comparing their perplexities, that are respectively 295. 43 and 169. 923, we observe a relative reduction of about 42. 5%, that results in an improvement of BLEU score.
The experiments are performed and thoroughly evaluated on three language pairs: Czech-English, German-English, and French-English. MT quality is evaluated on data sets created within the Khresmoi project and IR effectiveness is tested on the CLEF eHealth 2013 data sets. Results. The search query translation results achieved in our experiments are outstanding -our systems outperform not only our strong baselines, but also Google Translate and Microsoft Bing Translator in direct comparison carried out on all the language pairs. The baseline BLEU scores increased from 26. 59 to 41. 45 for Czech-English, from 23. 03 to 40. 82 for German-English, and from 32. 67 to 40. 82 for French-English. This is a 55% improvement on average. In terms of the IR performance on this particular test collection, a significant improvement over the baseline is achieved only for French-English.
The IR experiments are performed using the Lucene search engine 2  on the CLEF eHealth 2013 dataset for the languages specified above, directed towards retrieving English documents only. Since MT is only an intermediate component of the whole system pipeline, we proceed in two steps. We first independently tune MT to produce the best possible translations of queries (Section 2) and then use various techniques to modify and expand the translated queries for improved IR performance (Section 3). The methods applied in Section 2 include: in-domain training and tuning, intelligent training data selection, optimization of phrase table configuration, exploiting synonyms to construct translation variants, and decompounding (splitting) of complex German words on the source language side, which normally appear as unknown words.
We also find that using synonyms to enrich training data with translation variants does not improve the MT performance; however, decompounding of complex German words slightly improves the translation, at least according to BLEU. In Section 3, we evaluate query translation in a cross-lingual IR setting using standard methods on the CLEF eHealth 2013 Task 3 test collection. Here, despite achieving superior performance on the query MT task, as described in Section 2, we do not outperform the retrieval results obtained by using queries translated by Google Translate. In the last section, we perform a summary analysis of the overall results, the results of the individual techniques for improving MT performance and their integration into an IR system, and give suggestions for further work.
Machine translation for medical queries In this section, we describe the application of phrase-based statistical machine translation (SMT) to the translation of medical queries with the goal of producing accurate and fluent translations. This task differs from typical MT applications in two aspects: the domain and the genre of the input text. The domain, which reflects what the text is about, is very specific, characterized by a large and specialized vocabulary which does not occur in general texts. The genre, which indicates the general style, is also very distinctive. The input text is generally not in the traditional form of complete and coherent sentences, but rather in a form of short sequences of more or less independent terms. Such a situation requires application of special techniques to adapt the SMT system, including training data selection, model configuration, and parameter optimization.
The methods used are generally similar to domain adaptation techniques. One highly relevant study which explicitly deals with genre adaptation is by Nikoulina et al. [38]. They adapt the Moses SMT toolkit to translate queries for cross-lingual IR applied on the CLEF Ad Hoc TEL 2009 test collection of bibliography entries. They use two techniques: SMT tuning on genre-specific data and discriminative re-ranking of n-best lists optimizing retrieval effectiveness.
In automatic evaluation, their systems substantially outperform Google Translate. However, the SMT systems are specifically trained, tuned, and tested on the domain of PubMed titles, and it is not evident how they would perform on other medical texts. Costa-jussà et al. [42]  are less optimistic regarding the quality of SMT in the medical domain. They analyze and evaluate the quality of public web-based MT systems (such as Google Translate) and conclude that in both automatic and manual evaluation (reported for 7 language pairs), the performance of these systems is still not good enough to be used in daily routines of medical doctors in hospitals. Jimeno Yepes et al. [43]  propose a method for obtaining in-domain parallel corpora from titles and abstracts of publications in the MEDLINE 4 database.
We also make use of the dictionary data extracted from DBpedia and not identified as medical-domain, see Section 2. 2. 1. In addition to the resources mentioned above, we employ CzEng 1. 0 for the CS-EN experiments, a compilation of sentence-aligned parallel data from various sources: legislation, fiction, news articles, parallel web pages, movie subtitles, and technical documentation of software  [61]  (the Navajo section was excluded due to its low translation quality  corpus, sentence pairs extracted from the sections not identified as relevant to the medical domain, as described in Section 2. 2. 2, and translation pairs obtained from Linguee,  5  an online dictionary service. Additional FR-EN general-domain data comes from three sources: the Hansard Corpus extracted from proceedings of the Canadian Parliament  [12] , the MultiUN parallel corpus extracted from the United Nations website  [62] , and the COPPA corpus  [58]  -sentences from the sections not detected as medical-domain, see Section 2.
In-domain monolingual corpora Analogously to the parallel data, we also make use of monolingual data resources to train language models of English as the target language in all our experiments. The in-domain monolingual corpora include (cf. Table  2 ): the Cochrane database of reviews of primary research in human health care and health policy  [63] , DrugBank -a bioinformatics and cheminformatics resource describing drugs  [64] , Gene Regulation Event Corpus (GREC) -a semantically annotated English corpus of abstracts of biomedical texts  [65] , the GENIA corpus of biomedical literature compiled and annotated within the GENIA project  [66] , the Foundational Model of Anatomy Ontology (FMA) -a knowledge source for biomedical informatics concerned with symbolic representation of the phenotypic structure of the human body  [67] , English texts extracted from the UMLS Metathesaurus  [40] , the Patient Information Leaflet Corpus (PIL) -a collection of documents giving instructions to patients about their medication  [69] , and finally, a large set of texts extracted from HONcode-certified sites (HON) that have been identified by language-detection libraries  [70, 71]  to be English-language  [72].
Development and test data For parameter optimization and evaluation of translation quality in our experiments, we employ data sets from three sources; details are shown in Table  3. For the general domain (denoted as gen), we use the test sets provided for the WMT translation task 2012 and 2013  [14]  as development and test sets, respectively. This data contains sentences extracted from news stories in various languages (including Czech, German, English, and French) and manually translated into all other languages. For the medical domain (denoted as med), we exploit a translation memory produced by the European Centre for Disease Prevention and Control (ECDC)  6. This is a collection of sentences mostly on health-related topics and their professional translations into 25 languages. We randomly split the set of sentences having translations in the four relevant languages into development and test sets.
The primary development and test sets used in this study consist of user queries from the medical domain, referred to as query. These queries were originally in English, sampled from two sources: 50% from the general-public query logs provided by the Health On The Net (HON) Foundation  [79]  and 50% from the Trip database containing queries by medical professionals  [80]. We hired human translators (not necessarily native speakers but fluent in the relevant languages) to manually translate all the queries into Czech, German, and French, and then medical experts to verify the accuracy of the translations. The resulting sets were randomly split into development and test sets and made publicly available via the LINDAT/Clarin repository. 7 Some examples of English language general-public queries are: diabetic ulcer; cancer breast; disease; access; recuperation.
Examples of queries by medical professionals are: nsaids osteoarthritis; meningitis and penicillin; asthma children; common cold; prison dermatology. While the gen and med data sets contain complete sentences extracted from longer texts (documents), the query sets consist of short expressions used as real user search queries. This difference is evident from the average length, which is about 23 words per sentence on the English side for the gen sets, 17 for the med sets, and only slightly above 2 for the query sets -this is comparable to the observation that user queries to search engines usually consist of 2-3 words  [81]. Detailed statistics of the individual data sets are provided in Table  3.
System description Our translation system is based on Moses  [4] , an open-source phrase-based SMT project providing a complete set of tools for training, parameter optimization (tuning), and decoding (translation). In this section, we provide technical details of our setup. Word alignment is computed on pseudo-stems, words trimmed to 5 characters, using fast_align  [82] , which features competitive results of end-to-end MT evaluation and is faster compared to the traditional tools [e. g. , 8]. The resulting alignments are symmetrized by the grow-diag-final-and heuristic and phrases are extracted using the standard tools bundled with Moses, with the length limit set to 7 words. All dictionary data in our experiments is used the same way as regular parallel data (with alignment and phrase pair extraction).