dataesr/scientific-paragraphs-categorization huggingface dataset:
Submit a new peptide by completing forms. MyNorine provides an interface for submitting proposals of new NRPs. The interface is composed of several forms, that roughly correspond to the different classes of annotations. These forms/classes are: (i) general information such as the name, the family, the known activities, the empirical chemical formula, the molecular weight, etc. (ii) structure features: type (cyclic, linear. ), monomeric composition, monomeric structure, 2D chemical graph and SMILES if available (iii) producing organisms and their taxonomy (iv) published references and authors associated to the peptide (v) links to other resources such as PDB, UniProt and PubChem with the associated accession numbers (vi) any complementary general information To help and guide the curators, MyNorine offers sophisticated interfaces in order to interact with them during the completion of the forms.
For example, it will automatically suggest peptide names, monomer codes, references or authors (more generally, all information stored in the database, when it matches the user entry). Furthermore, users are warned if a peptide already exists. Submission of a new peptide by curators triggers a workflow process in which validators are notified. The new peptide with all associated annotations is manually checked, eventually modified or corrected, before the acceptation of the proposal. Finally, in case of approval, the curator is notified and will be mentioned as the author of the entry in the page of the peptide entry. Alternative ways for submitting peptides. In parallel to manual input for new NRPs, MyNorine supports XML or JSON files as an alternative way to submit data. We defined a simple representation for NRPs annotations using XML/JSON notations.
The choice of these notations, and especially the JSON data-interchange format was leaded by its ability to be both comprehensive by humans and easily manipulated by computer programs, independently of the language. XML/JSON files can be automatically generated from external sources (other databases) and directly submitted to Norine. Otherwise, a curator can upload an XML or JSON file that describes partially or completely a NRP to MyNorine. Once uploaded, forms are automatically completed thanks to data extracted from the file. Benefits are manifold. Users do not need to complete the whole process at once. Indeed, users can, at any time during the process, download XML or JSON file of their current production, then work locally on it (or not) and finally upload the file to MyNorine later.
Proposal of modification for existing entries To improve quality of information stored in the Norine database and ensure its integrity, MyNorine provides a process to suggest modifications for an entry. Any annotation can be corrected or added through an icon on the peptide result page (see Figure  2 ). Users can load an entry, add or change one or more data and send a notification to the validators with a message pointing out what has been proposed to be modified. After manual check, validators accept or reject the proposal. Accepted modifications are immediately visible on peptide result pages. In this case, the curator is mentioned as the author of the modification of the peptide entry.
Manual validation. Regarding validation aspect, MyNorine offers to validators specific interfaces and two dashboards (one for new peptides, the other for modifications), as illustrated in Figure  3  for new peptides. The dashboard is divided into three tabs. The first tab lists current unprocessed submissions and allows validators to load, check, accept (or reject) them. The second tab lists submissions that are under validation process. The last one shows accepted submissions and their history (submission date, contributor. ). Validators ensure that NRPs hosted in Norine are manually extracted from scientific knowledge (literature, other databases, personal analysis). The NRPs that are predicted exclusively by bioinformatics tools are avoided. At least one of the following evidences is required for a submission to Norine: (i) experimental elucidation of the complete structure, eventually coupled with bioinformatics analysis of the corresponding NRPS gene cluster or, (ii) experimental mass determination coupled with the careful bioinformatics analysis of the corresponding NRPS gene cluster or, (iii) manually curated annotation obtained by similarity with gene clusters coding for NRP synthetases studied experimentally.
All the peptides submitted through MyNorine will be inspected by validators of the Norine team. Only the peptides matching Norine standards will be validated and incorporated into the public version of the database. If no evidence for the non-ribosomal origin is presented, the validators may assign the putative status to the submitted peptide. Semi-automatic verifications, s2m tool. Manual validation is strengthened by semi-automatic verifications. Basic checks are done automatically to ensure the consistency of the data within and among the entries. Above all, the monomeric structures are checked through s2m tool. s2m infers automatically monomeric structures from chemical structures represented by SMILES notation. Chemical structures of NRPs stored in Norine are extracted from compound databases such as PubChem  (12)  or PDB  (13).
Improved Norine user interface Access to monomers annotations. A query form enables to search for the 529 monomers constituting the NRPs stored in Norine. They are clustered by class of compounds (carbohydrates, fatty acids, chromophores, polyketides and types of amino acids). For each monomer, chemical details are provided such as: short name, IUPAC name, empirical molecular formula, molecular weight, chemical structure represented by two-dimensions chemical graphs and SMILES notation and links to PubChem  (12)  and the Chemical Component Dictionary  (14). Nucleic Acids Research, 2016, Vol. 44, Database issue D1117 Efficient structure search. The structure search query form has been simplified. The editor helping to draw monomeric structure/composition of NRPs is now coded in JavaScript. The interactivity with the user is improved with fast and simple access to the monomer list and intuitive drawing functionalities.
An icon representing a pie chart gives access to a graphical representation. Pie charts illustrate global numerical proportion of found peptides for several annotations. The slices are clickable and give access to the current peptide list limited to the selected criteria. This process allows users to filter the results by more selective criteria. Download and customize the data. Norine offers the opportunity to download all data in several formats. From a peptide or a monomer page, icons give all annotations in TXT/CSV, HTML, XML or JSON formats, as illustrated in Figure  2. From the result pages, listing a set of peptides, the user can customize the annotations that will be integrated in the output. With the HTML format, a table with all the annotations selected is provided. So, the user can compare the desired annotations of several peptides at a time.
Norine REST web services A web API to access the Norine database. We developed a web API (Application Programming Interface) to access the Norine database. This API is based on REST (Representational state transfer). REST (  19 ) is an architectural style based on web-standards and the HTTP protocol. Web APIs expose resources to computer programs. Whereas classical web approaches are mainly dedicated to humans by providing rich and interactive interfaces (such as web forms or pie diagrams) for querying the database, Norine RESTful web services enable integration with other resources, by giving access to data it contains, using simple resource URI. In most of the cases, data returned by such services are available in various formats, such as HTML, XML or JSON. Currently, Norine provides the following services: (i) retrieve NRP annotations from Norine ID or by name (ii) get list of all monomers with cluster tree (iii) get the access code of an external link, or retrieve database name (PDB, PubChem.
The path argument determines the type of service to use, format can be XML or JSON, and parameter corresponds to the user query. For example, to retrieve annotations for the vancomycin NRP, in JSON format, the URI will look like: http://. /norine/rest/json/name/vancomycin Write programs for Norine REST services. Another feature that may interest developers of other resources and databases is the ability to access Norine through programs. Developers can write client programs in any language. These programs simply consist in creating HTTP requests, with the specific URI described above, and handling the response. It is also possible to embed its own HTML form to query Norine, and receive response in XML or JSON formats.
CONCLUSION Norine (http://bioinfo. lifl. fr/NRP) is the unique platform dedicated to NRPs. A user-friendly interface eases the browsing, annotation or structure searching and downloading of the NRPs and their monomers. This interface is completed by programmatic access through a web API based on REST. Dedicated bioinformatics tools are associated with the database such as an editor and a visualizer of the monomeric structures, homemade algorithms to compare monomeric structures and s2m that infers monomeric structure from chemical structure. An important improvement is the development of MyNorine tool. This tool is an interface to simplify the entry of new peptides or modification of existing ones in Norine by biologists. The process integrates the different steps going from the completion of the annotations to the validation of the submitted data.
Breast Model Configuration One hundred andfifty patients (75 left-sided, 75 right-sided breasts), all treated for whole breast with simultaneous integrated boost with RapidArc were selected for training the DVH estimation model. All plans were approved for clinical use and details of the treatment protocol can be found in  [16]. All patient data were anonymised. No ethical committee approval was needed for this kind of investigations. All the plans selected for model training were checked for their quality prior to their inclusion in the model. Whenever a single structure of a specific patient was suggested as a potential outlier by the metrics during the model configuration phase, the case was carefully re-checked to look for possible odd anatomic or dosimetric features. They were found to be not influential for the model quality (anatomically and dosimetrically reliable plans) and therefore not considered as real outliers.
For this reason those cases were not excluded from the training dataset. Normal distribution of data was assessed and confirmed. The boost clinical target volume (CTV) was defined as 1 cm around the surgical clips placed in the lumpectomy area, while the breast CTV was defined as the entire mammary gland. The planning target volumes (PTV) were defined by adding an isotropic margin of 5mm to the corresponding CTVs (3mm for organ movement due to respiration, and 3mm for patient set-up, summed in quadrature); the breast PTV was cropped 4-5mm inside the body outline to exclude the skin and also cropped to exclude the ribs and the lung parenchyma. A total dose of 48. 0Gy in 15 fractions was prescribed to the boost volume (PTV_boost), and simultaneously 40. 5Gy to the whole breast PTV. PTV_breast volumes ranged from 116 to 2062 cm 3 (mean 648 cm 3 ), PTV_boost volumes ranged from 11 to 269 cm 3 (mean 68 cm 3 ).
Concerning the bilateral breast validation experiment (180 pass-fail tests), in only 4. 4% of the pass-fail tests did the reference plan result in better dose distribition than the RapidPlan. In all other cases Rapid-Plan based plans were superior or equivalent to the reference. Planning time was not directly part of the study design but some qualitative data were collected. The time needed to "extract" from the patient's database the data for model training and load them into the configuration workspace is limited to approximately 15-20 seconds per plan. To this should be added the time needed to identify the good candidates for training. The time spent to train a model is approximately 2-3 minutes. The time needed to validate a model prior to clinical use, cannot be easily assessed as this depends on the complexity of the problem and is not in any case part of a routine clinical activity.
In this paper we compare two simulators: ns-3 and Vienna, in the context of LTE networks, on four basic scenarios for which well-known analytical results exist. These scenarios differentiate themselves by the nature of the traffic (data or voice) and by the number of sources (infinite or finite). Our goal is twofold. First, by confronting the results of the two simulators with exact results, we can assess the accuracy of both simulators and compare their efficiency. Second, and maybe more importantly, we want to compare the ease of handling and use of both simulators, and list the difficulties encountered in the context of the four basic scenarios, that will necessarily arise in more realistic simulated scenarios, and explain how we worked around the problems. We hope this comparison will help researchers who work on LTE networks to choose the simulator that best suits their needs.
For this goal there is a strong need for testing the proposed mechanisms and algorithms by simulation. Many options of simulators were studied, among them: ns-3, Vienna, SimuLTE and home-made simulators. The project finally chose to compare ns-3 and Vienna, because they are felt as the best-suited simulators in the context of LTE networks. Indeed Vienna is purely dedicated to LTE networks, whereas ns-3 is much more general and is based on standard modules designed to simulate different technologies and scenarios. For our comparison we used the LTE module developed by the LENA Project. This module was designed following the 3GPP LTE standard specifications and is included in the main distribution of the ns-3 latest versions. In order to provide an efficient and methodic comparison of ns-3 and Vienna LTE simulators, we have chosen to consider four basic scenarios, for which exact analytical results exist.
At the UE side, the Signal-to-Interference and Noise Ratio (SINR) is calculated per received subcarrier. At the end of each time-step, link performance measurements are performed to provide the simulation output which consists of traces, containing link throughput and error ratios for each user, as well as summary measures by cell, from which statistical distributions of throughputs and errors can be extracted. The For running the simulation, one has to write a MATLAB script which must perform the following tasks: • Either loading a configuration file (in the +simulation config subfolder) which applies a specific pre-configured simulation parameters, or configuring the parameters manually. • Executing the main simulation file.
NS-3 Simulator Network Simulator 3 (ns-3) is a discrete-event network simulator, developed as a simulation environment for networking research. It counts several modules, designed to simulate different technologies and scenarios. Here we work with the LTE module developed by the LENA Project  [12]. This module was designed following the 3GPP LTE standard specifications and is included in the main distribution of the ns-3 latest versions. NS-3 was developed using the C++ programming language and is a free simulator under GPLv2 License. It can be downloaded from the ns-3 webpage  [13] , where a manual and tutorials can also be found. We used for this comparison the ns-3. 20 version. Figure  6  shows the hierarchy of the ns-3 classes. Figure  6 : Software organization of the ns-3 simulator  [13]  In ns-3 one has to write a script in C++ (or Python) with the include files, the topology of the network, the routing, the tracing and the applications.
• Vienna advances the time by time-slices (of 1ms), while ns-3 does by the date of the next event: ns-3 is a discrete event simulator. 1 all code are available upon demand to authors • Vienna is very precise on the modeling of the physical layer. At each TTI it performs many calculations at the physical layer level. These computations drastically slowdown the simulation which may make unfeasible the simulation of more realistic scenarios. On the other hand,ns-3 uses a correspondence table provided by the 3GPP LTE specifications, that directly links a certain MCS, the number of RBs the antennas are using and the transport block (TB) size  [14]. Therefore, at each transmission, the simulator just retrieves such information, instead of calculating them, which results in an substantial gain. • The code organization in ns-3 is very clear: each technology has a separate module and each class corresponds to a network real object.
In Vienna modularity is not well exploited and it is not easy to create new classes without modifying many other files. • Traces provided by Vienna are simple to treat and one can also easily add other type of traces if needed. In ns-3 traces collection and processing is cumbersome. In order to perform the simulation of our four basic scenarios, we had to overcome some intrinsic limitations of the two simulators: • Due to its lack of modularity, it is very complicated to make any code modifications in Vienna. The solution we found to improve the speed of the simulator was to perform the physical layer calculations only when an UE perceives a change in channel conditions, instead of doing them at each TTI. • Vienna requires a constant number of users deployed per cell. For the DI and VI scenarios, where the total number of UEs in the cell varies with time, we had to make changes in the code of the simulator in order to allow the creation of new users on-the-fly.
From the ns-3 side, the simulator limits to 320 the number of nodes to be created and connected to an eNodeB. We thus have to re-use nodes after a certain time of inactivity for overcoming such limitation. • To simulate the DF scenario, we had to implement the ON-OFF traffic as a new application in both simulators. Indeed, such a traffic with an ON period characterized by a downloaded size (instead of a time) was not part of existing modules. • For the voice cases (VF and VI) we had to implement a new scheduler policy in order to take into account rejection. In Vienna, the mean number of active UEs can be easily measured using the traces from traffic model type where the state (ON or OFF) of each UE is stored at each TTI. The average throughput of a user can be obtained by dividing the average downloaded size (extracted from the N used bits output), by the mean ON period.
Performance comparison In order to compare the simulation run-time, memory usage and CPU occupation we conducted simulations on a 8 cores Intel(R) Xeon(R) CPU E5-2450 v2 @ 2. 50GHz workstation with 64GB of RAM, running Ubuntu Linux 14. 04 LTS. In both ns-3 and Vienna, the run-time performance is directly provided as an output of our scripts. For the measurement of the memory and CPU occupation performance, we used the top program of Linux which provides a dynamic real-time view of the system: when a simulation is running, we periodically observed the used amount of memory and the CPU utilization and the final results were averaged over the number of observations. model VF DF VI DI ns-3 37min 27min 465min 608min Vienna 780min 390min 270min 300min.
Third, in terms of CPU and memory usage, ns-3 is much better than Vienna. While ns-3 is based on C++, Vienna is based on the MATLAB environment, which requires enormous amounts of memory to run. Fourth, concerning the ease of handling and use, the choice is somehow subjective, it depends on the skills of the programmer, in C++ or in MATLAB language. However, we find that output traces are easier to manipulate in Vienna than in ns-3. In the other hand, ns-3 is quite well documented which is not the case for Vienna. Finally, taking into account the four aforementioned points and the experience acquired with this simulation comparison, we believe that ns-3 is a better choice for simulating more complex scenarios, including different coding zones within the cell, different cells, inter-cell traffic and UE's mobility.
Inputs and outputs LIM3. 6 has been interfaced with XIOS (XML input output server; http://forge. ipsl. jussieu. fr/ioserver/), a new and innovative library developed at Institut Pierre-et-Simon Laplace (IPSL) and dedicated to climate modelling data output. XIOS combines flexibility and performance. It considerably simplifies output definition and management by outsourcing output description in an external XML file. In addition, the interface offers numerous possibilities for variables manipulations such as complex temporal operations and computations involving several variables. XIOS also achieves excellent performance on massively parallel supercomputers by using several server processes exclusively dedicated to output files. File system writing is performed concurrently with computation.
Experimental set-up and observation data sets The simulation presented here is the standard simulation that can be performed with the most recent 3. 6 version of NEMO right after downloading the code, in one of the main supported NEMO configurations (ORCA2-LIM3), and forced by the reference CORE normal year forcing directly provided with the code. This is not the best simulation that can be produced, but rather the one that a user starting with the model would perform. In ORCA2-LIM3, NEMO comprises the ocean general circulation model OPA version 3. 6  (Madec, 2008)  and LIM  (Vancoppenolle et al. , 2009a)  in its 3. 6 version presented above, running on the same 2 • -resolution grid (ORCA2). More details can be found in  Mignot et al. (2013). The atmospheric state is imposed using the CORE normal year forcing set proposed by  Large and Yeager (2009) , developed to inter-compare ice-ocean models (e.
g. Griffies et al. , 2009). It is based on a combination of NCEP/NCAR reanalyses (for wind, temperature and humidity) and various satellite products (for radiation), has a 2 • resolution and near-zero global mean heat and freshwater fluxes. The so-called normal year data set superimposes the 1995 synoptic variability on the mean 1984-2000 seasonal cycle. The simulation lasts 100 years, much longer than needed for sea ice to reach equilibrium. Most diagnostics presented hereafter are seasonal averages over the last 10 years of the simulation. The computational cost of such a simulation is about 12 h on 64 processors of an IBM Power6, with LIM3. 6 consuming less than 25 % of this time. The observed ice extent is derived from ice concentration retrievals of the EUMETSAT Ocean and Sea Ice Satellite Application Facility (OSI-SAF;  Eastwood et al.
In the Storfjorden, new ice growth in open water is nearly as large as basal growth. The entire ice production is exported out of Storfjorden annually. Production presents large inter-annual variability over the 10 years of the experiment  (1999) (2000) (2001) (2002) (2003) (2004) (2005) (2006) (2007) (2008) (2009) , with values exceeding twice the minimum. There are also ongoing and upcoming developments for LIM. 1. The compatibility between the Adaptive Grid Refinement In Fortran (AGRIF;  Debreu et al. , 2008)  and LIM3 to run global simulations is yet to be achieved and work is in progress to use LIM2-AGRIF interface  (Talandier et al. , 2014)  and apply it to LIM3. 2. The melt pond parameterization of  Flocco and Feltham (2007) , as implemented by  Lecomte et al. (2015) , exists in a branch of the code and is expected soon in the reference version.