dataesr/scientific-paragraphs-categorization huggingface dataset:
FUNDING This work was supported with a grant to LO-S by the  Spanish Ministry of Science and Universities of Spain  ( BIO2016-77840-R ) and to MP by  FP7. FACCE-JPI-ERA-NET+ CLIMATE SMART AGRICULTURE  ( ERA46-SYBRACLYM ). RS acknowledges funding from  BMBF  grants  031A549  (SYBRACLIM) and 0315910 (CONVIGOUR). NN, AB, LL, and GB acknowledge funding from the transnational PLANT-KBBE cooperation project CONVIGOUR with funding from  ANR (France). MB was supported by a postdoctoral research fellowship and JC-C by a PhD contract (FPI), both funded by grant  SEV-2016-0672  to the  CBGP (Centre of Excellence Severo Ochoa Program of the Agencia Estatal de Investigación, Spain ). GC-C was supported by a PhD contract by  Universidad Politécnica de Madrid  (UPM; programa propio).
Version 1. 1 of the editorial of Geoscientific Model Development (GMD), published in 2015 (GMD Executive  Editors, 2015), introduced clarifications to the policy on publication of source code and input data for papers published in the journal. Three years of working with this policy has revealed that it is necessary to be more precise in the requirements of the policy and in the narrowness of its exceptions. Furthermore, the previous policy was not specific in the requirements for suitable archival locations. Best practice in code and data archiving continues to develop and is far from universal among scientists. This has resulted in many manuscripts requiring improvement in code and data availability practice during the peer-review process. New researchers continually start their professional lives, and it remains the case that not all authors fully appreciate why code and data publication is necessary.
This editorial provides an opportunity to explain this in the context of GMD. The changes in the code and data policy are summarised as follows: -The requirement for authors to publish source code, unless this is impossible for reasons beyond their control, is clarified. The minimum requirements are strengthened such that all model code must be made accessible during the review process to the editor and to potentially anonymous reviewers. Source code that can be made public must be made public, and embargoes are not permitted. Identical requirements exist for input data and model evaluation data sets in the model experiment descriptions. -The scope of the code and data required to be published is described. In accordance with Copernicus' own data policy, we now specifically strongly encourage all code and data used in any analyses be made available.
2016 ). Here we focus on the particular issues that arise when the data are predominantly model code. The short version of the argument is given by the motto of the Royal Society: "nullius in verba" ("take nobody's word for it"). Scientists who publish a result without publishing the calculations undertaken to achieve that result are requiring the world to take them at their word, which is inimical to the scientific method, and the only really effective way to publish the calculations behind a computer model is to publish the source code  (Añel, 2011). Thus, for those GMD papers focussed on the development of models or on development of model analysis methods, the descriptive text part of the manuscript is incomplete if not partnered by source code. Throughout this editorial, "must" means that the stated practice is required and that manuscripts which fail to comply will be rejected; "should" means that the practice is strongly encouraged, and authors will need to provide defensible reasons in cases where manuscripts do not comply.
Establishing this places strong demands on the modelling process. In particular there must be sufficient evidence to demonstrate the following: 1. The model code faithfully represents the mathematical and theoretical specification of the model. 2. The computation that was conducted used the code, input data and configuration as intended. 3. The analysis of the model output was appropriate and performed correctly. Publication of source code most directly addresses the first of these, whilst the second and third can be greatly aided by properly specifying precise versions of code and input data in GMD manuscripts. For example, suppose a scientist develops a new advection scheme and implements it in an atmospheric dynamics model. They publish a paper describing the new scheme and present the results of both idealised verification experiments and realistic simulations showing an improvement in forecast skill, but the code is not released.
With the source code, however, readers can gain much deeper knowledge of the model than can ever be described in the paper. The hypothesis highlighted above is easily adapted to all the other forms of coded products described in GMD papers, such as data assimilation systems, frameworks, databases and model evaluation tools. Although not always emulating a physical system, in these products there is an underlying mathematical structure that is realised in code, and it must be demonstrated to work as intended in just the same way as a model. For model experiment descriptions, the situation is very simple. The primary purpose of these papers is to enable modelling communities to perform the same experiments. Therefore, everything required to run the experiment must be provided, apart from the model itself.
This presents a challenge: should GMD insist on publication of source code and data and therefore not publish papers about some of the most important models in the geosciences, or should it accept such papers even though the rigour of those papers is compromised by the lack of code? At the time of writing, the GMD editors considered that the balance falls on the side of allowing publication. However this does compromise the scientific standards of the journal, so the circumstances in which source code publication will not be required must be drawn as narrowly as is feasible. All manuscripts must at a minimum provide confidential access to the code and data developed in the manuscript for the editor and reviewers in order to enable peer review (see Appendix A1). This position is broadly consistent with the American Geophysical Union publications data policy 1  though less strict than, for example, Computers and Geosciences, who now have an open-source-only policy 2.
In the case where the new code and data described in the paper are not restricted but are part of a larger code and data structure that has other restricted elements, it is still possible to satisfy the GMD requirements by making the new parts of the code and data available. As the result is usually not a coherent model which can be expected to compile, authors sometimes prefer to upload these code fragments to the supplement rather than to a repository. Authors may have to remove restricted elements from their model code base, but in the meantime this remains an acceptable if somewhat unsatisfactory solution.
Archive on submission A related issue to embargoing is raised by manuscripts which point to code located on a website, accompanied by a promise in the cover letter that the code will be properly archived when the final paper is accepted. This approach compromises the review process for two reasons. First, at the core of the open review process of European Geosciences Union journals is the idea that the submitted manuscript and the review process are openly and persistently available to scrutiny. The version of the code which matches the submitted manuscript directly influences that process, so it must remain available to anyone who wishes to examine the review of the manuscript. Second, the whole review process, including initial editor review, external referees and executive editor intervention when needed, is in essence a protracted quality control process for the scientific content of the manuscript but also for the technical requirements such as code and data archiving.
Zenodo Zenodo is a scientific data archive funded by the European Union and hosted by CERN. It has an institutional guarantee of at least 20 years of future support and has policies restricting withdrawal of deposited data 3. Zenodo issues DOIs for all deposits and supports DOI versioning to connect together successive versions of a data set 4. A feature of Zenodo which makes it particularly easy to use for many GMD authors is its integration with GitHub 5. It is straightforward for the owner of a GitHub repository to link their GitHub and Zenodo accounts and have a Zenodo archive created automatically for every GitHub release 6.
arXiv On occasion, GMD requires authors to archive grey literature, for example, technical reports about a previous model version. Where these are simply a single document, Zenodo may not be the most convenient archival system. In these cases the arXiv preprint server is a good choice 7. The arXiv has a long track record dating back to 1991, institutional support from Cornell University and financial backing from a large worldwide consortium of research institutions. The arXiv has very strict policies against removal of articles 8. DOIs are not issued, but there is a system of arXiv identifiers which fulfil a technically equivalent role of providing a persistent, location-independent reference for an arXiv document 9.
National or discipline-specific data archives At the time of writing, Zenodo had an upload limit of 50 GB. This is more than enough for source code and indeed for the input data for many GMD papers. However some papers, especially evaluation papers for complex models, may require much more than this. Because the archival of large data sets is expensive, there is no generic free solution to this case: the appropriate repository may depend on the application area of the model in question, the source of funding for the research or the location of the authors' institutions. The requirements of Sect. 4. 1 still apply and must be assessed in each case. Useful guidance may be drawn from the lists of recommended repositories provided by Springer Nature 10  , PLOS 11  and ESSD 12.
Institutional websites Hosting source code and other data on the authors' institutions' websites fails to satisfy the requirements for irrevocability and persistence of reference. Even large institutions periodically refresh their web presence with the result that URLs change, and data from long-finished projects may not be preserved. Of course data archives also have web interfaces, and some authors work for institutions that host suitable data archives. Authors are not debarred from using a data archive which complies with GMD policy simply because they are affiliated with the archive's host organisation. However by the same token, the fact that an organisation hosts a suitable archive does not mean that organisation's entire web presence can be considered an archival location.
GitHub and other online revision control systems In the last few years, many authors have submitted manuscripts whose code availability sections consist of direct links to online revision control systems, either institutionally hosted or online services such as GitHub 13  , GitLab 14  or Bitbucket 15. These services are excellent platforms for developing models. They provide revision control and support code review, distribution and integration with continuous testing systems. Authors are encouraged to use such platforms for code development. They are, however, insufficient for publication as they lack the required persistence and irrevocability: if the project ends or decides to move to a different hosting platform, the data will disappear from the location given in the paper. In addition, if the project moves to a different revision control system, the version indicators provided may well cease to be valid.
Many GMD authors find Zenodo 20 a suitable archival location. Zenodo's GitHub integration 21 makes archiving particularly easy for the large proportion of authors who manage their code using Git. Authors who need to archive a single documentation file, such as a technical report, may find the arXiv suitable 22. Authors whose data are too large to be archived at Zenodo will need to identify a suitable alternative. Appropriate choices may depend on the topic of the paper, the funder of the research, and the country where the research was conducted. One of the repositories listed by Springer Nature 23  , PLOS 24  or ESSD 25  may be suitable. In any case, the requirements above must be satisfied. Project or institution websites and online revision control sites such as GitHub 26  , GitLab 27  or Bitbucket 28  are made for code development but not suitable for archiving frozen code versions.
A4 Template for code and data availability section The following code and data availability section meets the requirements of this policy for papers focussed on development of models or development of methods for assessment of models. Other wordings are, of course, possible so long as the required information is all present. For larger models it is very helpful if authors can identify the location of the main parts of the code that are discussed in the manuscript. For experiment description papers, evaluation papers, and some technical and development papers where details for a variety of different data sets or models are required, the section will be considerably longer. The current version of model is available from the project website: url under the licence name licence. The exact version of the model used to produce the results used in this paper is archived on Zenodo (citation), as are input data and scripts to run the model and produce the plots for all the simulations presented in this paper (citation).
For more details refer to the code and data policy. There are seven different manuscript types accepted at GMD. During the submission process, authors will need to select the type which most closely matches the aims of their manuscript. The types are as follows: model description papers Updates: Minor version updates or correction of actual errors in a model, model development or experiment protocol should be submitted as a regular submission within one of the standard manuscript types. Authors may request that these form part of a model special issue including the previously published papers.
B1 Model description papers Model description papers are comprehensive descriptions of numerical models which fall within the scope of GMD. The papers should be detailed, complete, rigorous, and accessible to a wide community of geoscientists. In addition to complete models, this type of paper may also describe model components and modules, as well as frameworks and utility tools used to build practical modelling systems, such as coupling frameworks or other software toolboxes with a geoscientific application. The GMD definition of a numerical model is generous, including statistical models, models derived from data (whether model output or observational data), spreadsheet-based models, box models, 1-dimensional models, through to multi-dimension mechanistic models. -The main paper must give the model name and version number (or other unique identifier) in the title.
For model experiment description papers, similar version control criteria apply as to model description papers: the experiment protocol should be given a version number; boundary conditions should be given a version number; a data availability paragraph must be included in the manuscript; and links to the GMD paper should be included on the experiment website. Since the primary purpose of these papers is to make experiments accessible to the community, all input data required to perform the experiments must be made publicly available. Papers describing data sets designed for the support and evaluation of model simulations are within scope and included in this paper type. These data sets may be syntheses of data which have been published elsewhere. The data sets must also be made available, and any code used to create the syntheses should also be made available.
If the description is in GMD, then there is the possibility of linking the papers, either in the form of a companion paper (e. g. Part 1 and Part 2) or as part of a special issue devoted to a particular model or experiment. Preprocessing, run control and postprocessing scripts covering every data processing action for all the results reported in the paper should be provided for evaluation papers. It is, however, common for pure evaluation papers to contain substantial conclusions about geoscience rather than about models, and such papers are not suitable for submission to GMD. These are more likely to reach the appropriate audience in those EGU journals which publish scientific results related to the GMD subject areas.
Acknowledgements. The GMD executive editors gratefully acknowledge the GMD topical editors for their hard work, support and helpful comments on the manuscript. David A. Ham  was supported by a  United Kingdom Natural Environment Research Council   Independent Research Fellowship  [grant no. NE/K008951/1 ]. Didier Roche  was supported by the  Centre national de la recherche scientifique (CNRS)  and by the  Vrije Universiteit Amsterdam.
Partially Deuterated Co-Polymers After studying the effect of different levels of deuteration of the monomers, we synthesized co-polymer microgels of H-pNIPMAM and D7-pNIPMAM. We choose H-and D7-pNIPMAM for the co-polymer microgels because the difference in the VPTT is the largest for these two species. In addition to the already studied homo-polymer particles (0 mol% D7 and 100 mol% D7), we decided to analyze three further intermediate ratios of H-pNIPMAM and D7-pNIPMAM co-polymer microgels (25, 50, and 75 mol% D7). The upper part of Figure  5  shows the normalized size transition with the temperature for H-pNIPMAM and D7-pNIPMAM co-polymer microgels with the co-polymer content of D7-pNIPMAM indicated in the legend. The lower part shows the derivative of a fit representing the experimental data in the upper part of the figure.
In Figure  8  we display again the normalized size as a function of the temperature in the upper part and the derivative of the fits of the experimental data in the lower part. First of all, the effect in terms of VPTT shift is minor when changing the solvent as compared to modifying the monomers. For all three samples the VPTT decreases when the solvent is changed from H 2 O to D 2 O. For D7-pNIPMAM, the VPTT decreases by 1. 2 K, for D12-pNIPMAM by 0. 8 K, and for H-pNIPMAM by 0. 3 K. Thus, while the (partial) deuteration of the monomer itself and of H/D7 co-polymers shifts the VPTT towards higher temperatures, the deuteration of the solvent shifts the VPTT to lower temperatures. This can be attributed to the strength of the hydrogen bonding. As the phase transition temperature is dependent on both the polymer-polymer interaction and the polymer-solvent interaction, the influence of the hydrogen bonding from deuteration of both polymer and solvent can alter the VPTT.
Supplementary Materials: The following are available online at http://www. mdpi. com/2073-4360/11/4/620/s1, Figure  S1 : Left: hydrodynamic radius as a function of the temperate for H-pNIPMAM, D7-pNIPMAM, and D12-pNIPMAM. Right: Hydrodynamic radius normalized to 0-1 as mentioned in the main article. The measurement at 13 • C for H-pNIPMAM and at 55 • C for D12-pNIPMAM failed. Figure  S2 : FTIR-spectroscopy measurement of H/D7-pNIPMAM co-polymer microgels with the D7 content indicated in the legend. Left: Wavenumber of the d (ND) vibration as a function of the temperature. Right: Normalized wavenumber (with Equation S2) as a function of the temperature. The experimental data were fitted with Equation S1. Figure  S1 : Γ q -2 vs. q 2 of an angle dependent PCS measurement in water from 30  Funding: This research was funded by the ANF and DFG joint CoreShellGel project, Grant ANR-14-CE35-0008-01 of the French Agence Nationale de la Recherche, and Grant HE2995/5-1 by Deutsche Forschungsgemeinschaft.
Acknowledgments: The authors thank the  ANF  and  DFG  for the support with the  joint CoreShellGel  project, Grant  ANR-14-CE35-0008-01  of the  French Agence Nationale de la Recherche , and Grant  HE2995/5-1  by  Deutsche Forschungsgemeinschaft. We thank  Matthieu George  ( L2C Montpellier ) for the help with AFM measurements,  Ina Ehring  ( Bielefeld ) for the help with the syntheses, and  Oliver Wrede  for the fruitful discussions.
Access to these data is provided by the Gravitational Wave Open Science Center (GWOSC)  [4]  in the website gw-openscience. org along with documentation, tutorials, and online tools for finding and viewing data. GWOSC reflects the growing awareness for the importance of open data in science. Sharing the data allows reproducibility of scientific results and discoveries made from the data. It maximises the experiment's discovery potential by allowing anyone to perform their own analysis. In the present case, it also enables multi-messenger astronomy, i. e. , joint analysis with other astronomical observation channels. Finally, it is possible to involve a wider community, not only professional scientists but also students, amateur astronomers and artists. Many projects 1  have already been possible through the LIGO and Virgo public data release, including about 60 scientific papers so far and also student projects, online courses, an iPhone App and art installations.
Methods The Laser Interferometer Gravitational-Wave Observatory (LIGO) includes two identical 4km arm interferometers situated in Hanford in Washington State and Livingston in Louisiana. The Advanced Virgo detector is an interferometer with 3 km arms located in Italy, near Pisa. Those detectors measure the strain that gravitational waves (GW) exert on space-time. The GW strain is the main science output of the detectors and it is measured through the difference in phase of the light travelling in the arms of the interferometers. The data are repackaged and resampled by GWOSC to make it more accessible to casual users both within the LIGO Scientific Collaboration and Virgo Collaboration and outside. More specifically the strain channel is sampled in LIGO and Virgo data at 16384 Hz (2 14 Hz), while GWOSC data are made available both at 4096 and 16384 Hz.
Events releases consist of data segments centred at the time of each event provided in two durations: 32 s and 4096 s. Strain data taken during a whole observation run are divided into many files of length 4096 s. Additional data are essential to qualify the reliability of the strain measurement, including the status of the detectors, the sub-systems, and the environment, all of which are continuously monitored with hundreds of thousands of auxiliary channels. From these auxiliary channels a handful of "Data Quality" channels are extracted and released in addition to the strain by the GWOSC. Further technical details are given in the GWOSC webpages  2. For each run GWOSC also provides a representative power spectral density (PSD) of the background noise from the entire frequency range, along with a list of spectral lines obtained from a highly-resolved PSD estimate.
Data Records Gravitational wave open data are hosted in the GWOSC webpages  3. The files can be directly downloaded one by one from this webpage. However, to download large amounts of data (as in the case of a whole observing run) it is suggested to use the distributed filesystem CernVM-FS that, once installed, allows the users to access GWOSC data as files in a directory tree mounted on their local computer. GWOSC data are available in 3 files format: "GWF", which is a specialized format of GW detectors; "HDF5" that is readable with many coding languages (python, MATLAB, C/C++, IDL,. ); simple ASCII file format containing two columns, one with the time and the other with the corresponding strain values (only for the events release). The HDF5 files contain: • Metadata: Description of the data, URL of the GWOSC website, detector and observatory concerned, duration of the segment of data, starting time both in GPS and UTC.