dataesr/scientific-paragraphs-categorization huggingface dataset:
) which is a more evaluation oriented result. In other words, the Cross Section model level will count and classify everything that is related to the handling of quantum numbers J, π, s, and the connections between entrance and exit channels. A major difference between the AbstractModel interface and the Cross Section interface resides in the Physics content of the Cross Section implementation. Furthermore, as previously stated, a lot of nuclear reaction models exists for various incident particle energy and for various channels. Nevertheless, this variety can be driven by a proper interface. Figure  3  shows the result of the previous discussion in term of code implementation general philosophy for the CONRAD cross section model description (CrossSectionModel). A new nuclear reaction model implementation (called MyNucle-arReactionModel in the figure) should respect the nuclear reaction model interface and the rest is handled by the upper level (CrossSectionModel).
Experimental modules The first version of CONRAD, CONRAD V0  [3] , contains many C++ modules devoted to time-of-flight experiments: target description (isotopic contents, geometry), experimental parameters definition such as normalization and background related parameters. To allow a proper theoretical/experimental comparison, one has to know exactly the relationship between the theoretical cross sections and what is measured. The relationship between cross section and measurement is called a functional, named t in this document. All kinds of functional were proposed in CONRAD from the simplest one, macroscopic cross section ( t ∼ σ), to transmission (example given in Fig. 4  where what is measured is something close to t ∼ e -σtotn ) or capture yield measurements which exhibit a more complicated form (see  [11, 12]  for some description of this experimental functional).
Cross section in the fast energy range The main evolution in the last CONRAD version is related to a philosophy change: from a resolved resonance range analysis code to a platform for nuclear data modeling. As a result, nuclear reaction models calculation capabilities were extended to the continuum region. One should notice that for fast energy range (from several tenths of keV up to several tenths of MeV), several possibilities are offered by CONRAD: an encapsulation of TALYS  [25]  and/or ECIS  [26]  as well as a new optical model called CCCP. The CCCP module is a new C++ implementation for the resolution of the coupled-channel equations in the case of the symmetric rigid rotor model. The numerical resolution is based on the same Numerov or modified-Numerov that is used in the reference ECIS code.
This new implementation is easier to maintain, it is free from numerical fix-ups necessary in single-precision computations and benefits from the use of the modern Eigen algebra library  [27]  allowing fast computations with a code written in a compact from. An exhaustive validation of this new optical model calculation was performed. Especially, one major point focusing on all the physical and numerical problems was the proper behaviour of CONRAD/CCCP coupled channels models for deformed nuclei (such as 157 Gd). Figure  6  shows a comparison for this isotope between this new C++ optical model calculation with the ECIS06 reference results based on the same optical potential and using the related optical potential parameters retrieved from the RIPL database  [28]. Other cross sections such as shape elastic and reaction cross sections were validated as well.
CONRAD by having the whole nuclear reaction models in the same tool allows the evaluation of cross section over the entire energy range of interest with an experiment having measures on a broad energy range. The example of the new JEFF-3. 2 (and JEFF-3. 3 [34] ) sodium evaluation is given in Figure  8. One can see the cross correlation between the resonance (below 2 MeV) and the continuum energy range (above 2 MeV). It comes from the analysis of the new JRC-Geel experiment with both a Reich-Moore model and an optical model. The correlation is created first because CONRAD provides the framework to handle several nuclear reaction models (or codes) but from a more fundamental point of view because, the code gives the possibility of treating experimental systematic uncertainties (such as normalization).
Miscellaneous model implementations Allowing any kind of model to connect with the code via a definite C++ interface (see Fig. 1 ) opens the range of various additional nuclear data analysis. So far, the following models were also implemented or interfaced: -models for thermal data calculation  [7] ; -DPA cross sections models  [44] ; -expression-based model: description given with standard mathematical functions in the input file. In addition, a Miscellaneous analysis mode has been developed for testing new nuclear data models before their implementations in the CONRAD code. This mode allows to explore a large variety of analysis by using the full Bayesian capabilities of CONRAD without specific C++ development nor model description in the input file. One of the latest applications of the Miscellaneous mode was the production of covariance matrices between the model parameters involved in the description of the Thermal Scattering Laws (TSL), which are needed to describe the neutron scattering process when energies lie below a few eV.
can be treated that way. Multi-model calculations where a given observable, such as a cross section, can be modeled on different energy ranges by different nuclear reaction models can be performed. Analysis devoted to diagnosed the input data such as sensitivity calculations, which gives the normalized derivatives of a model related to an observable to its parameters (numerically or analytically) and statistical analysis of resonances  [49]  are available. In the next chapters, two kind of analysis will be detailed (in particular the files description). The first one is a standard evaluation analysis of neutron induced cross section of 239 Pu. This analysis makes use of implemented nuclear reaction models in the code. The second analysis related to delayed neutron takes advantage of a very new CONRAD feature: the expression based model where the model is not directly implemented in the CON-RAD code but described in the input file with simple mathematical functions.
Towards a new version 4. 1 Simplification and re-engineering of the code The CONRAD code was initiated more than ten years ago with original ideas related to resolved resonance range analysis. The increase of code functionalities (new models, Monte Carlo algorithms) led to a code harder to maintain and sometimes difficult to understand for new developers. It was thus decided to redevelop and simplify a lot what was formerly done with a special emphasize on the ExperimentalModel API as well as model implementation capabilities. In addition, efforts are put on accelerating calculations with optimizations, new numerical methods and a better design of parallelism. Speed is still an issue to allow good and comprehensive full range evaluation (resonance of actinides or iron for example), uncertainty evaluation, high energy range data assimilation (with uncertainties) etc.
Charged particles and compound nucleus representation of nuclear reactions The historical way of supplying evaluated cross section in the resolved resonance range for actinides consists in providing resonance parameters. These latter are associated to the laboratory framework of the incident particle. For lighter nuclei, more sophisticated resonances parameters needs to be evaluated. Former limitations of the ENDF format used to prevent the supply of resonance parameters for light nuclei. This limitation being now removed, the new code will aim at evaluating such lighter isotopes. In Figure  12  inspired by E. Vogt in  [51] , one can see how the 7 Be compound nucleus can be formed/decay through various channels. The idea, recently developed in the CONRAD code, is to work with parameters defined in the center of mass of the system and analyze measurements of various cross sections yielding the same compound nucleus with different target/projectile.
The interpretation of this formulae is quite obvious: it is a competition between an initial guess of the complexity represented by N param and a penalty relying on the deviance between the prior and the posterior (M -1 prior × M posterior ). With these indicators a common framework is proposed for addressing general questions such as, model complexity, over-fitting and comparison of complex models to infer a possible best choice. The use of Monte Carlo Bayesian inference (in complement or instead of traditional generalized least square) implemented in the CONRAD code is a suitable mathematical framework for calculating these indicators. Some first attempts are given in  [58, 59].
Towards microscopic calculation ingredients The new CONRAD code is designed to allow a lot of innovative developments for nuclear physics models. The ultimate goal of nuclear physics modeling could be thought as the removal of some free (adjusted) parameters in nuclear reaction models as well as in fission models. This path may lead to more consistency from the physics point of view on nuclear models, give information/evaluation for isotopes difficult to measure (such as fission products) and reduce compensation effects. Following what was exposed in  [62] , fission barrier calculations are a real room for improvement in nuclear data evaluation, namely in the resonance range, where for instance no energy-dependence is used in practice for the penetration factor used for fission channels. Reduction of arbitrariness of the adjusted parameters can also be an intermediate goal.
Conclusions CONRAD after more than ten years of developments is a code mature for nuclear data evaluation with any kind of nuclear models. The major functionalities of this code are Bayesian inference modules, possibilities of calculation of cross sections with several models to cover the whole energy range of interest (from 0 eV to 20 MeV) and an exhaustive treatment of all uncertainties coming from experiments. These developments were constantly tested, verified and validated against other nuclear reaction codes. In addition, pragmatic choices were made to use existing codes such as ECIS or TALYS with a proper C++ encapsulation allowing to use these tools in the same way than in-house developments. The strategy was then to rewrite some of them in C++, for a better use of additional modern features such as parallelization (on PC's) or for high performance computing on large calculators.
The distribution of data contributed to the Coupled Model Intercomparison Project Phase 6 (CMIP6) is via the Earth System Grid Federation (ESGF). The ESGF is a network of internationally distributed sites that together work as a federated data archive. Data records from climate modelling institutes are published to the ESGF and then shared around the world. It is anticipated that CMIP6 will produce approximately 20 PB of data to be published and distributed via the ESGF. In addition to this large volume of data a number of value-added CMIP6 services are required to interact with the ESGF; for example the citation and errata services both interact with the ESGF but are not a core part of its infrastructure. With a number of interacting services and a large volume of data anticipated for CMIP6, the CMIP Data Node Operations Team (CDNOT) was formed.
Introduction This paper describes the collaborative effort to publish and distribute the extensive archive of climate model output generated by the Coupled Model Intercomparison Project Phase 6 (CMIP6). CMIP6 data form a central component of the global scientific effort to update our understanding of the extent of anthropogenic climate change and the hazards associated with that change. Peer-reviewed publications based on analyses of these data are used to inform the Intergovernmental Panel on Climate Change (IPCC) assessment reports. CMIP data and the underlying data distribution infrastructures are also being exploited by climate data service providers, such as the European Copernicus Climate Change Service (C3S;  Thépaut et al. , 2018). Eyring et al. (2016)  describe the overall scientific objectives of CMIP6 and the organizational structures put in place by the World Climate Research Programme's (WCRP) Working Group on Coupled Modelling (WGCM).
Several innovations were introduced in CMIP6, including the establishment of the WGCM Infrastructure Panel (WIP) to oversee the specification, deployment and operation of the technical infrastructure needed to support the CMIP6 archive. Balaji et al. (2018)  describe the work of the WIP and the components of the infrastructure that it oversees. CMIP6 is expected to produce substantially more data than CMIP5; it is estimated that approximately 20 PB of CMIP6 data will be produced  (Balaji et al. , 2018) , compared to 2 PB of data for CMIP5 and 40 TB for CMIP3. The large increases in volume from CMIP3 to CMIP5 to CMIP6 are due to a number of factors: the increases in model resolution; an increase in the number of participating modelling centres; an increased number of experiments from 11 in CMIP3 to 97 in CMIP5 and now to 312 experiments in CMIP6; and the overall complexity of CMIP6, where an increased number of variables are required by each experiment (for full details see the discussion on the CMIP6 data request;  Juckes et al.
, 2020). From an infrastructure view, the petabyte (PB) scale of CMIP5 necessitated a federated data archive system, which was achieved through the development of the global Earth System Grid Federation (ESGF;  Williams et al. , 2011 Williams et al. , , 2016;; Cinquini et al. , 2014). The ESGF is a global federation of sites providing data search and download services. In 2013 the WCRP Joint Scientific Committee recommended the ESGF infrastructure as the primary platform for its data archiving and dissemination across the programme, including for CMIP data distribution  (Balaji et al. , 2018). Timely distribution of CMIP6 data is key in ensuring that the most recent research is available for consideration for inclusion in the upcoming IPCC Sixth Assessment Report (AR6). Ensuring the timely availability of CMIP6 data raised many challenges and involved a broad network of collaborating service providers.
Given the large volume of data anticipated for CMIP6, a number of new related value-added services entering into production (see  Sect. 3. 3 ) and the requirement for timely distribution of the data, in 2016 the WIP requested the establishment of the CMIP Data Node Operations Team (CDNOT) with representatives from all ESGF sites invited to attend. The objective of the CDNOT  (WIP, 2016)  was to ensure the implementation of a federation of ESGF nodes that would distribute CMIP6 data in a flexible way such that it could be responsive to evolving requirements of the CMIP process. The remit of the CDNOT described in WIP (  2016 ) is the oversight of all the participating ESGF sites ensuring that all sites adhere to the recommended ESGF software stack security policies of ESGF (https://esgf. llnl.
The WIP is responsible for ensuring that all the components are working and available so that the data from the climate modelling centres can be distributed to the data users. The WIP and CMIP Panel liaise to ensure that CMIP needs are met and that any technical limitations are clearly communicated. In 2016 the WIP commissioned the CDNOT to have oversight over all participating ESGF sites. Typically an ESGF site will have a data node manager that work closely with the data engineers at the modelling centres to ensure that CMIP data that are produced are of a suitable quality (see Sect. 3. 2. 2) to be published to the ESGF. At each site ESGF software maintainers/developers work to ensure that the software is working at their local site and often work collaboratively with the wider ESGF community of software developers to develop the core ESGF software and how it interacts with the value-added services.
The development of the ESGF software is overseen by the ESGF Executive Committee. Finally, the ESGF network provides the data access services that make the data available to climate researchers; the researchers may sit within the climate modelling centres, universities or industry. The aim of this paper is not to discuss in detail all of the infrastructure and different components supporting CMIP6, much of this is discussed elsewhere, such as  Balaji et al. (2018) ;  Williams et al. (2016) ; rather the focus of this paper is to describe the work of the CDNOT and the work done to prepare the ESGF infrastructure for CMIP6 data distribution. The remainder of the paper is organized as follows. Section 2 briefly describes the ESGF as this is central to the data distribution and the work of the CDNOT.
Note that it is not uncommon for the terms sites and nodes to be used somewhat interchangeably, although they are not strictly identical. At each site there are both hardware and software components which need to be maintained. Sites are typically located at large national-level governmental facilities as they require robust computing infrastructure and experienced personnel to operate and maintain the services. The sites interoperate using a peer-to-peer (P2P) paradigm over fast research network links spanning countries and continents. Each site that runs an index (search) node publishes metadata records that adhere to a standardized terminology (https://github. com/WCRP-CMIP/CMIP6_CVs/, last access: 11 September 2020), allowing data search and download to appear the same irrespective of where the search is initiated.
The subsets will be determined by the individual centres and their local user community priorities. The ESGF user interface shown in Fig. 3  allows end users to search for data that they wish to download from across the federation. Typically users narrow their search using the dataset facets as displayed on the left-hand side of the ESGF web page screen shown in Fig. 3. Each dataset that matches a given set of criteria is displayed. Users can further interrogate the metadata of the dataset or continue filtering until they have found the data that they wish to download. Download can be via a single file, a dataset or a basket of different data to be downloaded. In each case the search (index) node communicates with the data server (an ESGF data node), which in turn communicates with the data archive where the data are actually stored; once located, these data are then transferred to the user.
CDNOT: the CMIP6 software infrastructure The CDNOT utilizes and interacts with a number of software components that make up the CMIP6 ecosystem as shown in Fig. 4. Some of these are core components of the ESGF, and the ESGF Executive Committee has oversight of their development and evolution, such as the ESGF software stack and quality control software. Other software components in the ecosystem are integral to the delivery of CMIP6 data but are overseen by the WIP, such as the data request, the Earth system documentation (ES-DOC) service and the citation service. The CDNOT had the remit of ensuring that all these components were able to interact where necessary and acted to facilitate communication between the different software development groups. Additionally, the CDNOT was responsible for the working implementation of these interacting components for CMIP6, i.
In many cases, MIPs request data not only from experiments that they are proposing themselves but also from experiments proposed by other MIPs, so that there is substantial scientific and operational overlap between the different MIPs. The combined proposals of all the MIPs, after a wideranging review and consultation process, are combined into the CMIP6 data request (DREQ:  Juckes et al. , 2020). The DREQ includes an XML (Extensible Markup Language) database and a tool available for modelling centres (and others) to determine which variables at what frequencies should be written out by the models during the run. It relies heavily on the CVs and also on the CF Standard Name table (http://cfconventions. org/standard-names. html, last access: 4 May 2020), which was extended with hundreds of new terms to support CMIP6.
The data challenges, as described in Sect. 5, utilize new esgf-installer versions at each stage; the evolution of the installer is tracked in the related project on GitHub (https://github. com/ESGF/esgf-installer/, last access: 4 May 2020). The ESGF software stack includes many components, such as the publishing software, node management software, index search software and security software. Given the difficulties experienced while installing the various software packages and managing their dependencies, the ESGF community has moved toward a new deployment approach based on Ansible, an open-source software application-deployment tool. This solution ensures that the installation performs more robustly and reliably than the bash-shell-based one by using a set of repeatable (idempotent) instructions that perform the ESGF node deployment.
Quality control Once all the underlying software required to publish data to ESGF is in place, the next step is to begin the publication process using the "esg-publisher" package that is installed with the ESGF software stack. Before running the publication, the data must be quality-controlled. This is an essential part of this process and is meant to ensure that both the data and the file metadata meet a set of required standards before the data are published. This is done through a tool called PrePARE, developed at the Program for Climate Model Diagnosis and Intercomparison (PCMDI)/LLNL (https://github. com/ESGF/esgf-prepare/, last access: 4 May 2020). The PrePARE tool checks for conformance with the community-agreed common baseline metadata standards for publication to the ESGF. Data providers can use the Climate Model Output Rewriter (https://cmor.
Dataset versioning Each ESGF dataset is allocated a version number in the format "vYYYYMMDD". This version number can be set before publication or allocated during the publication process. The version number forms a part of the dataset identifier, which is a ". "-separated list of CMIP6 controlled vocabulary terms that uniquely describe each dataset. This allows any dataset to be uniquely referenced. Versioning allows modelling centres to retract any data that may have errors and replace them with a new version by simply applying a new version number. This method of versioning allows all end users to know which dataset version was used in their analysis, making data versioning critical for reproducibility.
wdc-climate. de/, last access: 4 May 2020) issues DataCite (https://datacite. org/, last access: 4 May 2020) digital object identifiers (DOIs) and uses Dat-aCite vocabulary and metadata schema as international standards. The service is integrated into the project infrastructure and exchanges information via international data citation infrastructure hubs. Thus, CMIP6 data citation information is not only visible from the ESGF web front end and on the "further_info_url" page of ES-DOC (see Sect. 3. 3. 3), but it is also visible in the Google Dataset Search and external metadata catalogues. The Scholarly Link Exchange (http://www. scholix. org/, last access: 4 May 2020) allows in-formation on data usage in literature to be accessed and integrated. The data citations are provided at different levels of granularities of data aggregations to meet different citation requirements within the literature.