dataesr/scientific-paragraphs-categorization huggingface dataset:
We provide compositional data as well as contextual metadata for 7759 individual samples with a current focus on archaeological sites across the Pacific Islands (Fig. 1 ). Our vision is an inclusive and collaborative data resource to activate an operational framework for data sharing in archaeometry, that will progressively include more datasets, and initiate a more global project similar to other online repositories for geological materials already available through a wide geoinformatics network  [21] [22] [23] [24]. Furthermore, by using common non-proprietary file formats (CSV) and an open source system for storage and version control (Git and GitHub repository), the Pofatu Database provides an analysis-friendly environment that enables transparency and built-in reproducibility of analytical tasks  25.
Methods The data can be accessed and downloaded from the Zenodo archive (https://doi. org/10. 5281/zenodo. 3670127) and browsed in the Pofatu web application (https://pofatu. clld. org/). The database was designed to contain geochemical compositional data and extensive contextual metadata (sample identification, archaeological provenance, analytical methods, and related bibliographical references), which we compiled to ensure further reuse and reinterpretation of previous provenance analyses (Fig. 2 ). The compositional data contains all analytical values for major oxide and trace element compositions, radiogenic and stable isotope ratios, and geochronology. Sample metadata involves the creation of unique identifiers, and a description of sample condition and preparation. Archaeological metadata provides information on the geographical, cultural and stratigraphic context of the parent artefacts (name, category and attributes), the collection origin (collector, date and nature of field research, storage location), and a description of the site and stratigraphic context (name, code, context, stratigraphic position).
Data acquisition. All data and metadata in the Pofatu Database and included in this data descriptor release are linked with published resources. Geochemical datasets are extracted from peer-reviewed material, while contextual metadata include information gathered from peer-reviewed articles, monographs, book chapters, and publicly available institutional reports. Original sources are coded in the repository and available as a BibTeX database file, suitable for importing into reference management software. Geochemical datasets are associated with a method identifier, which is unique and defined based on the set of available methodological metadata for a specific set of values. The process of data acquisition includes: Data submission: Data and metadata are gathered and stored in normalized tables linked by foreign keys.
These interrelated tables each contain sets of information on (i) Data source, (ii) Sample and archaeological provenance, (iii) Compositional data, (iv) Primary analytical and method-specific metadata. The Pofatu Database is frequently curated and updated on a regular basis. New datasets and complementary information on previously documented datasets can be submitted using the Data Submission Template and Guidelines available online (https://pofatu. clld. org/about). Data validation: The content of each table is handled manually but several fields are constrained by ontologies, which are built-in form validation in the submission template. Data is also validated using functionality implemented in the Python package pypofatu, which imposes suitable constraints on data like geographic coordinates.
Data output: The manually curated "raw" data undergoes an automated processing workflow (implemented in the Python package pypofatu) to create output formats ready for distribution. For long-term accessibility, the data is converted to a set of interrelated CSV files, described by metadata encoded as JSON-LD (cf. https://www. w3. org/TR/json-ld/, accessed January 30, 2020), following the World Wide Web Consortium (W3C) recommendations  174, 175. Because the compiled data is exclusively made of line-based text files (in CSV format), it is well-suited for long-term access since it has the lowest requirements on processing software, and provides for a transparent history of changes with the version control software Git (cf. https:// git-scm. com/, accessed January 30, 2020).
technical Validation Quality control of data and editorial procedures include: Data review: Database contributors who submit a new dataset are asked to be the editor of that specific dataset and to engage in a review of potential missing or inaccurate data. The content of new datasets is systematically cross-checked with the content of original sources and with potentially related content. Authors are contacted when information is missing or when clarifications are needed. Duplicate detection: Since Pofatu assigns semantic, unique identifiers to the objects in the database, and links data from additional tables using these keys (following the recommendations by Wilson and colleagues  177  ), data consistency can be checked automatically, e. g. detecting multiple conflicting measurements of the same parameter in the same analysis, or conflicting sample metadata.
Usage Notes The Pofatu Database provides an analysis-friendly environment  178  that enables transparency and built-in reproducibility of analytical tasks that can be achieved through freely available softwares or web browsers  25. Since the metadata provided with the csv-formatted data files has information about data types as well as relations between the tables making up the dataset, it is automatically loaded into an SQLite database (cf. https:// sqlite. org/appfileformat. html, accessed January 29, 2020) for the convenience of the users. This SQLite database is contained in a single file document that can be queried with a high-level query language, has accessible content, is cross-platform, performant, and can be used with multiple programming languages. The Python package pypofatu used for curating the dataset also provides functionality (built-in SQLite driver) that enables access and queries of the data with Python programs or the pypofatu API, and facilitates running SQL queries against the SQLite database.
Complex queries can be created in various ways and with different computing environments: • using SQL command line • using SQL browsers such as SQLite manager or SQLite reader • using R, with SQL codes in a notebook or packages such as sqldf or dplyr  179, 180  • using the Datasette tool  181  Data usage instructions are provided in the GitHub repository where the dataset is curated (cf. https://github. com/pofatu/pofatu-data, accessed February 6, 2020). A "cookbook" collects shareable pieces of code and how-to instructions to query the relational database (cf. https://github. com/pofatu/pofatu-data/blob/master/doc/cookbook. md, accessed February 6, 2020), and users are invited to contribute with the "recipes" they used for "cooking" with Pofatu.
Code availability The pypofatu Python package is open-source software, maintained on GitHub and distributed via the Python Package Index (https://pypi. org/project/pypofatu), with released versions archived with Zenodo 182. The two output formats listed above are created and stored as part of the GitHub repository where the dataset is curated (https://github. com/pofatu/pofatu-data/releases/tag/v1. 0. 0), and each release of the dataset is also archived on Zenodo  176. Additionally, the dataset is loaded into a clld  183  web application, providing an online, browsable user interface for "window-shopping", before downloading and using the dataset locally. Released versions of the Pofatu dataset meet the requirements on FAIR data as laid out by Wilkinson and colleagues  177. The data is findable thanks to Zenodo's integration in the research data landscape on the web, and the metadata we provide.
The pre-conceptual design of the DEMOnstration reactors has already started and several tokamak configurations have to be tested to find the best design by exploring different design parameters. Fast simulations involving the different components behavior must be performed. Within the European framework, SYCOMORE (SYstem COde for MOdelling tokamak REactor) is developed by CEA for this purpose. The Breeding Blanket (BB) facing the plasma is a key component in DEMO ensuring tritium self-sufficiency, shielding against neutrons and heat extraction for electricity production. Several BB concepts are being studied, among which the Water Cooled Lithium Lead (WCLL) one. SYCOMORE includes several specific modules in Python linked together, one of which has been developed to define a suitable design of the WCLL Breeding Blanket and is presented in this paper.
The method to define automatically the WCLL First Wall (FW) design using analytical design formulae starting from thermo-hydraulic and thermo-mechanical considerations as well as design criteria coming from Codes & Standards (C&S) is presented. Furthermore WCLL FW design obtained with SYCOMORE is compared to Finite Elements (FE) analyses of the DEMO WCLL BB. Finally, a coupling between thermo-mechanics and neutronics is implemented, several iterations are necessary to obtain a converged design. Neutronic block evaluates the radial build, the BB tritium production, and the nuclear heating in the FW and the Breeding Zone (used by thermo-mechanical block). Thermo-mechanical module gives the design data (FW thickness, compositions, etc. )  to the neutronic block.
Introduction SYCOMORE is a modular fusion reactor system code under development at CEA  [1]  to simulate speedily various DEMO tokamak configurations in scrutinizing their key parameters. The aim of the system code is to describe a fusion power plant with all its subsystems in using simple models in an integrated approach: several modules are built as elementary calculation tools, each one treating a separate aspect such as plasma physics, engineering and costing. They are all integrated together and chained in the SYCOMORE multiphysics platform. One target of this system code is to analyze feedback between its subsystems and how each module impacts the others. In SYCOMORE, a concept of BB called Helium Cooled Lithium Lead (HCLL)  [2]  has been previously implemented and is described in  [3].
This present model has been built in taking into account the particularities of the WCLL BB for DEMO  [4]  developed within the European framework. The present article is focused on the method to define automatically the WCLL FW design via analytical design formulae starting from thermo-hydraulic and thermo-mechanical considerations: the initial HCLL BB FW design module in SYCOMORE  [3]  has been rethought and adapted for building a water BB concept. In particular, for the WCLL BB, the FW thermohydraulic limits -due to the incident Heat Flux (HF) -are taken into account to avoid any Departure from Nucleate Boiling (DNB) due to Critical Heat Flux (CHF). The structural integrity is analyzed regarding Codes & Standards (C&S). Finally, the results are compared with ones obtained on the WCLL BB module regarding neutronics  [6] , thermo-mechanics and thermohydraulics.
WCLL BB concepts in DEMO In DEMO, the BB is the component surrounding the plasma which has to withstand severe and various operating conditions while insuring tritium selfsufficiency (target: Tritium Breeding Ratio (TBR) above 1. 1), neutron shielding and coolant temperature range suitable for heat extraction in order to supply a turbine for producing electricity. Moreover, the design has to fulfil the RCC-MRx structural design criteria  [7]  in order to ensure the structural integrity of the component when it has to withstand the thermal and mechanical loads it undergoes under nominal and accidental conditions. The WCLL BB module in SYCOMORE derivates from the HCLL one. Two major options are possible for the BB global design: #1 the Single Module Segment (SMS) configuration which consists in a unique component in poloidal direction and #2 the Multi-Modules Segment configuration which postulates different elementary modules.
2  -for the water flow distribution and breeder routing through the BB. Note that these design principles are the same for the SMS configuration  [4]  which consists finally in a big module along the poloidal direction with a banana shape. The WCLL BB model in SYCOMORE derives from the HCLL BB model previously implemented, but some important modifications have been done: #1 at this stage of system code development, the water-cooled FW has been implemented which is clearly representative of the WCLL BB concept, #2 no DWTs have been inserted in the Breeding Zone (BZ) area, the previous structure (coming from the HCLL BB module in SYCOMORE) is maintained with vSPs and hSPs in flow series with Cooling Plates (CPs) in the BZ at the scale of BU. The global flow path however follows the same scheme as the reference WCLL DEMO blanket with a parallel cooling scheme between the FW and the BZ (cf.
WCLL BB design module in SYCOMORE In the SYCOMORE system code, dedicated modules calculate important reactor values using models whose level of implementation depends on the code objective: each module is composed of calculation blocks subdivided in sub-blocks -see Fig. 3. All the modules are linked together via an integrated tokamak modeling platform via SYCOMORE allowing to establish the plasma physics and to define the various reactor subsystems: thus system design workflow is creating by chaining the execution of the various sub-modules with optimization loops. Moreover a major preliminary work has been done previously to define cause-and-effect links and inputs/outputs of each module. This approach allows several advantages: • Modules describe a physic or a technology. They can be unitary replaced that makes collaborative development easier.
Moreover in a pre-design phase simple models are used to accelerate code processing. • The reactor design workflow is adapted to change: the type of constraint applied can be modified speedily as well as the way to chain modules and finally converge to a global solution. The Breeding Blanket module in SYCOMORE is constituted by several blocks (left part of Fig. 3 ) such as: • Reactor reassembly geometry block; • Neutronic block; • Reactor reassembly power block; • WCLL BB design block. The WCLL BB design block (block 4 in Fig. 3 ) uses the same global architecture than the one developed for the HCLL BB configuration (cf. [2]  to  [5] ). In this block, the different elementary analyses are segmented in subblocks in terms of geometry, mass calculation, thermic, hydraulic, pressure drops and thermo-mechanic; each one regrouping dedicated functions (see Fig.
3. After, in each part, relevant inlet/outlet temperatures are calculated via a simple enthalpy balance using as input the power deposited in various components from reactor assembly power block (block 3 in Fig. 3 ). Maximum temperatures in the FW as well in the SPs and in the CPs are estimated to check whether steel maximum temperature limit is respected. • In the hydraulic sub-block, pressure drops in the BB are estimated combining friction losses in straight channels and pressure drops in singularities such as elbows. Pressure drops will be input parameter for the energy conversion system SYCOMORE submodule which is being developed in parallel for the predesign of the primary heat transfer system and the calculation of thermo-dynamic cycle efficiency. • In the thermo-mechanical sub-block, more particularly via a Python function dedicated to the FW analyses, membrane and bending stresses are evaluated analytical formulations and compared to allowable limits for RCC-MRx  [7]  damages.
Thus in SYCOMORE, these quantities are calculated iteratively starting from the total power deposited in the WCLL BB module. • In accidental condition (D-level RCC-MRx  [7] ): a Loss Of Coolant Accident (LOCA) is supposed, all the WCLL BB is considered as over-pressurized at 186 bar on all surfaces wetted by PbLi. Concerning the design limits, the operating cases are analyzed with different stress limits  [7] , depending on the probability of the condition occurring, and the willingness to return the component to service. Moreover the temperature of the Eurofer structures shall not exceed 550°C; indeed above this value, the thermo-mechanical properties in particular decreases quickly. Furthermore the flow conditions in water has to remain below the Critical Heat Flux to not severely affect heat transfer in the FW channels.
Indeed the calculation strategy is to determine the ratio that represents the PP necessary for cooling the FW divided by the heat recovered by the FW: this ratio has to be below 5% (limit fixed in SYCOMORE). The Pressure Drops ∆ can be formulated via two different equations: in the first one, the Pressure Drops are directly obtained via this standard formula i. e. : ∆. A j. { '. | ^B 9k^B 0 2} (11) The second one is used to calculate 6 -the fraction of the thermal power used for the pumping power obtained in the configuration which has been calculated: Finally the value of 6 -is compared to the limit 6 given in the main program in SYCOMORE. Note that in the system code, other retro-action loops are present in particular concerning manufacturing aspects  [3].
Interaction with the neutronic BB module A coupling between thermo-mechanical and neutronic bocks is implemented, several iterations are necessary to obtain a converged design. Neutronic block evaluates the BB tritium production, the neutronic fluxes in the structures of the tokamak (especially magnets) and the nuclear heating in the FW and the Breeding Zone (used by thermo-mechanical block). Moreover the neutronic block calculates integral quantities such as TBR (Tritium Breeding Ratio) and Me (energy multiplication factor). Thermo-mechanical module gives the design data (FW thickness, compositions, etc. ) to the neutronic block. At first, the same calculation strategy than for the HCLL neutronic module (see  [5][6] ) has been used for the WCLL BB in SYCOMORE. The activities have been particularly focused on the development of simplified neutronic models for the WCLL concept: a new neutronic model has been developed in order to obtain faithful results via simplified 3D models of the tokamak with TRIPOLI-4®.
The simulations have been performed in coupled neutron-photon transport mode. To easily integrate this neutronic module and to propose simulation times compatible with the constraints of the system code (total SYCOMORE "run" less than one minute), Neural Network (NN) meta-models (Fig. 6 ) replicating the results have been built using the URANIE [11] platform. The selected NN have been encapsulated in a Python program allowing their exploitation quikly, it constitutes the WCLL neutronic module of SYCOMORE  [6]  and can be used for the BB design. Furthermore, the results obtained have been compared to the DEMO WCLL reactor case (2014 baseline). WCLL neutronic sub-module produces results with right orders of magnitude and shows rather small differences with the DEMO WCLL reactor case. The thermo-mechanical and thermo-hydraulic physic of the WCLL BB has been coded in SYCOMORE using Python language.
Conclusions The development of the BB module in SYCOMORE has been continued for the WCLL concept in introducing thermo-hydraulic and thermo-mechanic sub-blocks in order to define the deductive optimal design in accordance with the WCLL BB performance targets and the C&S criteria. Geometric, thermo-hydraulic and thermo-mechanical blocks coupled to the neutronic one allow a complete calculation and very encouraging results for a system code are obtained in particular concerning TBR evaluation. Indeed the WCLL BB calculation via SYCOMORE has shown that the developed methodology reproduces quite well the behavior of 3D model providing a useful automatic predesign tool to designers.
Test setup The drop hammer test procedure which has been used by Baleh et al. [14]  was employed for the dynamic testing of FRP bars. The drop hammer setup depicted in Fig. 5  has a maximum impact velocity and maximum kinetic energy of 10 m/s and 2. 5 kJ, respectively. One end of the bar was braced using artificial clay to prevent its slippage. The testing machine is equipped with a 20-ton dynamic load cell, that measures the axial load applied to the bar specimens, a 5000 g accelerometer and a laser displacement transducer to measure the deflection up to 100 mm. The load cell and displacement transducer were both connected to a rapid data acquisition unit (2. 5 MHz) monitored by a computer. The acquisition system recorded the applied load, acceleration and displacement data in a coordinated manner with the aid of photocells.
Finite element simulation of drop-hammer test The aim of the finite element (FE) simulation described in this section is to simulate the drop-hammer dynamic test and present the different aspect of material definitions for FRP bar composites. The FE modeling was conducted using ABAQUS commercial software (2018). The drop hammer tests were simulated using the aforementioned specimen dimensions, hammer weights and drop heights. The FRP specimen was modelled with axisymmetric finite element formulation due to its cylindrical shape. The specimen was also modelled as a deformable solid while the hammer was defined with a high stiffness and a density that resembles the actual falling weight. The base was modelled as rigid. All components were meshed using axisymmetric elements, though the assigned mesh configurations were different, as illustrated in Fig.
A repair is considered optimal when roughly, it allows a maximal number of interleavings. We identify a connection between this problem and conflict serializability  [37] , an atomicity condition originally introduced in the context of database transactions. In the context of concurrent programs, given a decomposition of the program's code into code blocks, an execution is conflict serializable if it is equivalent 2  to an execution in which all code blocks are executed in a sequential non-interleaved fashion. A repair that rules out a non-linearizable execution τ can be obtained using a decomposition of the set of events in τ into a set of blocks that we call intervals, such that τ is not conflict serializable with respect to this decomposition. Each interval will correspond to an atomic section in the repair (obtained by mapping events in the execution to statements in the code).
Traces are extracted as sequences of call/return events and read/write accesses to explicit memory addresses, associated to line numbers in the source code of each of the API methods. The latter is important for being able to map critical segments (which refer to events in a trace) to atomic code blocks in the source code. In Table  1 , we list some quantitative data about our benchmarks, the clients, and the non-linearizable variations identified by the line numbers of the modified atomic sections (the original libraries can be found in the Synchrobench repository). For instance, the first variation of RWLockCoarseGrainedListIntSet is obtained by shrinking the atomic section in the add method between lines  [26, 32/35]  to  [32, 32/35]  (there are two line numbers for the end of the atomic section because it ends with an if conditional).
A different group of approaches infer synchronization incrementally from traces  [43]  or generalizations of bad traces  [7, 8]. These techniques  [7, 8, 43]  also infer atomic sections but they do not focus on linearizability as the underlying correctness property but rather on assertion local violations. Several works investigate the problem of deriving an optimal lock placement given as input a program annotated with atomic sections, e. g. ,  [9, 17, 48]. Afix  [28]  and ConcurrencySwapper  [7]  automatically fix concurrency-related errors. The latter uses error invariants to generalize a linear error trace to a partially ordered trace, which is then used to synthesize a fix. Linearizability Repairs. Flint  [32]  is the only approach we know of that focuses on repairing non-linearizable libraries, but it has a very specific focus, namely fixing linearizability of composed map operations.