dataesr/scientific-paragraphs-categorization huggingface dataset:
However, we are unaware of a study investigating them in depth, for example, relying on shape validation languages. Therefore, we cannot justify the compatibility more than low. (S3-S4): Although none require the annotation phase of the data sharing principles, we observe a medium interoperability level between annotation languages and tools and description vocabularies, e. g. , both VoCaLS and SAO have properties to link mapping files for provenance tracking. (S4-S5): From our analysis emerges that S4 and S5 are highly interoperable. Indeed, metadata are essential for consumers to obtain the information to access the data, which are well covered by existing vocabularies (SAO and Vocals) and APIs such as RSP4J and RSP Services. (S5-S6): The seminal works like on TripleWave granted high interoperability between serving and querying.
Indeed, querying often leads to analyses powered by sophisticated data visualization. The literature on this topic is extensive, and other surveys have discussed best practices. Thus, they are also out of scope. On the other hand, publications' best practices like those by Auer et al. [58]  stress on the "cyclic" aspect of the life cycle. Indeed, applications processing Streaming Linked Data shall also publish their analysis results. Such a vision appeared few times in the literature  [55, 66, 67]. Stuckenschmidt et al. [66]   propose, among other approaches, to push the expressivity level of SR using networks of stream reasoners. Calbimonte et al. [67]  do a step toward such an idea by leveraging Linked Data Notification as a means for P2P communication across RSP engines. Finally, Tommasini et al.
In particular, the first implementation phase of the Center of Excellence for Exascale in Solid Earth (ChEESE-1P) targeted the preparation of community flagship codes and services in the domain of Solid Earth. Solid Earth (SE) science is rich in computational challenges that embrace the different approaches to exascale, requiring large-scale computational infrastructures both to address fundamental scientific questions and to manage the occurrence of geohazards and their impacts. On the one hand, many SE problems involve multiple spatial scales spanning orders of magnitude (from local to global), time ranges, multiphysics with complex couplings, and substantial data volumes, requiring large monolithic executions that have been unaffordable by petascale systems in terms of capability. Exascale capability challenges in SE include, for example, high-frequency seismic full-waveform inversion and related high-resolution Earth's sub-surface imaging, modelling of the Earth's convective dynamo, or multiphase and multicomponent full-scale simulation of volcanic plumes.
Finally, geohazardous phenomena such as earthquakes, tsunamis or volcanic eruptions require emergency simulations that are affordable with current systems (in terms of capability) but that need to be solved under strict time constraints. In these urgent computing applications, exascale resources can reduce substantially the time to solution and hence have the potential to substantially transform the way society deals with early warning, short-term forecast, and emergency management. In the transition to exascale, scientists are becoming able to combine capability computing (higher resolution, increased degree of model sophistication, multiscale, multiphysics) and capacity computing (multiple scenarios to deal with uncertainties, data assimilation, fusion of models and observations and hybrids thereof) into emerging products and services delivering to public authorities and decision-makers high-fidelity predictions under strict time constraints, thereby helping to save lives and livelihood.
Flagship codes ChEESE-1P prepared 10 community flagship codes that are of wide use across different areas of SE including 4 codes in computational seismology, 2 codes in magnetohydrodynamics (MHD), 2 codes in volcanology, and 2 codes in tsunami modelling (see Table  3  for code list, description, and references). At the beginning of the project, the 10 flagship codes were labelled in terms of (strong) scalability as: Scalability level 1: petascale codes, good strong scalability (>90% parallel efficiency) proven up to about 10 4 -10 5 cores or above (for hybrid node architectures, core numbers can be converted to the equivalent node number depending on the case). Four codes were already at petascale level at the beginning of the project (November 2018): Salvus, SPECFEM3D, SeisSol, and xSHELLS.
Exascale code preparation strategy The code preparation strategy entailed two iterations of code audits and related audit-driven optimisation activities. At the beginning of the project, all codes were audited in collaboration with the EU Performance Optimisation and Productivity Centre of Excellence in HPC (POP CoE). Level 1 codes were evaluated with the Score-P profiling tool  [11] , which provides a deep insight in particular performance aspects such as large scale executions, whereas the evaluation of level 2 and level 3 codes relied on Extrae, a simpler profiling package that generates Paraver tracefiles for analyses and that is flexible enough to highlight potential code performance bottlenecks  [12]. Hints from the code audits were then mapped into corresponding single-node and multinode optimisation activities as shown in Table  4.
A second audit round served to better plan the optimisation tasks until the end of the project and to compare the resulting POP metrics and the test cases (code runtimes) with the first audit values, thereby providing a quantitative and objective interim monitoring of the code optimisation activities. Overall, the largest effort focussed on code acceleration using CUDA and OpenACC (including efficiency of CPU-GPU and GPU-GPU data transfer for most of the ported applications), followed by parallel and asynchronous I/O. In fact, at the end of ChEESE-1P, 8 out of 10 flagship codes had been fully or partially ported to GPU environments, and all codes initially labelled at scalability level 3 were already at level 2. Details on code optimisations and tunings can be summarised as follows: 1. Salvus.
Salvus uses the Portable, Extensible Toolkit for Scientific Computation (PETSc,  [13] ) DMPLEX class for unstructured mesh management. The first POP audit revealed that the serial mesh loading and interpolation (originally done on a single node), imposed memory limits on the maximum mesh size that Salvus could handle. Accordingly, optimisation activities on Salvus included the parallelisation of DMPLEX and the enabling of parallel  /O improvements ✓ ✓ - - ✓ - ✓ ✓ ✓ ✓ 7 Algorithmic optimisation - - - - - ✓ ✓ ✓ ✓ ✓ 5 Code vectorisation - ✓ - - - ✓ - - - ✓ 3 OpenMP parallelisation - - - ✓ ✓ - - - - ✓ 3 Load balance - - ✓ - - ✓ - ✓ ✓ - 4 Communications efficiency - ✓ - - - - ✓ - - - 2 Memory usage - - - ✓ - - - - - - 1 HDF5 I/O, resulting in a drastic reduction of the code start-up time and the extension to much larger meshes  [14] [15] [16]  (see Fig.
1a ). Improvements added to PETSc DMPLEX class were tested up to 214 billion elements (7th order, 512 grid points per element) on 3,000 nodes of MareNostrum-4 supercomputer and were distributed to the community in the PETSc 3. 13 version release. 2. SPECFEM3D. SPECFEM3D legacy performance metrics were already very good (Fig. 1b ), but the code produced several files per MPI rank leading to bottlenecks when the number of processes increased. The first POP audit also revealed that vectorisation over elements instead of vectorisation inside elements limited the code vectorisation capabilities. Dedicated optimisation activities focussed on vectorisation on CPU (with a speedup gain up to 3x) and on implementing parallel HDF5 in order to reduce the number of output files, including asynchronous I/O to overlap computation with IOs, leading to a 2x speedup gain above 5,120 processors (Fig.
4. xSHELLS. The first audit showed that the xSHELLS scalability was limited by data-dependencies between processes in the sparse linear solver, leading to latency increasing with the number of processes. In addition, xSHELLS uses the Spherical Harmonic Transform library (SHTns,  [19] ) that was not fully efficient on GPUs. Tailored optimisation activities for xSHELLS focused on the use of MPI-3 shared memory within nodes to improve parallelism and reduce explicit communication overhead and the CUDA part of the SHTns library. These resulted in a much better scaling at large node counts, the code being more than 2x faster on the 128 nodes tests, now used in production  [20, 21]. The new GPU mode is 4x to 8x faster on a node-to-node comparison on Marconi-100 machine (hybrid nodes with 4 NVIDIA V100 GPUs).
5. PARODY_PDAF. Scaling in PARODY_PDAF  [22, 23] , a code originally at scalability level 2, was largely constrained by the limited extension of the OpenMP regions and the sequential I/O. Audit-driven optimisation activities focussed on improving parallel efficiency by extending the OpenMP regions, enabling parallel I/O using MPI-IO, and a preliminary porting to GPUs using OpenACC and interfacing with the CUDA version of the SHTns library (that is shared with xSHELLS). All these activities resulted on a 1. 75x speedup gain on Joliot-Curie machine tests using 18,432 cores, already bringing the code to a scalability level close to 1 (Fig. 1c ). 6. ExaHyPE. ExaHyPE uses the Peano framework  [24]  for solvers operating on dynamically adaptive Cartesian meshes, which has a tree-oriented load balancing (coarse granular).
The first audit suggested that the tree traversal at MPI-level and the lack of code vectorisation were critical. Accordingly, dedicated activities for ExaHyPE focussed on increasing the percentage of vectorised code to nearly 100% and on starting the rewrite of Peano (4th generation) with a much improved parallelisation approach including support for GPUs  [25] [26] [27]. On the other hand, a reactive load balancing and code resilience strategy was implemented by means of task sharing, including reactive task offloading and replication-based resilience (i. e. task sharing between replicated ranks to mitigate performance pain and detection of silent data corruption via error indicators), which yielded to a 2x performance gain on several tests  [28, 29]. 7. ASHEE. The ASHEE code  [30] , based on the OpenFOAM toolkit, presented I/O issues on a few thousands of cores and memory bandwidth and MPI communications problems yielding to a poor parallel efficiency (the initial code level was of 3).
The dedicated optimisation activities focussed on implementing asynchronous I/O and on porting to GPUs the linear algebra parts using external libraries (i. e. no need to change the underlying OpenFOAM code). On the other hand, the memory usage and the intra-node scaling were improved with the use of mixed precision, yielding to a 2x faster matrix assembly (in single precision) and to a 3x gain in the linear algebra part (in double precision) using GPU offloading. Several scaling tests with mixed precision gave good parallel efficiency up to 12,000 cores, meaning the code is currently at level 2. 8/9. T-HySEA and L-HySEA. The first POP audit of the code(s), already fully ported to CUDA at the start of the project, revealed a poor load balancing, a lack of asynchronous transfers between CPU and GPU memories, and a non-optimal netCDF file output.
Audit-driven activities for T/L-HySEA focussed on implementing asynchronous transfers between CPU and GPU memories and direct GPU-to-GPU memory transfers, as well as compressing the netCDF files in single precision. These yielded to an overall improvement of 30% in code speedup and a decrease of the total time to solution by about 20%  [31]  (Fig. 2c ). 10. FALL3D. FALL3D was originally a level 3 code that presented I/O limitations and memory bottlenecks leading to an overall lack of scalability. During ChEESE-1P, the code was heavily refactored with improved communication/computation ratios, better data management, introduction of netCDF parallel I/O and, finally, fully ported to GPUs using OpenACC  [32, 33]. The overall speed-up increased by 5x (90% parallel efficiency on 64 Joliot-Curie nodes; code already at level 2) and the runtime was also reduced drastically, with the accelerated version more than 10x faster compared with the original plain MPI version on the same number of nodes (tests on Marconi-100 and CTE-Power systems, Fig.
PD2 was tested using synthetic tsunami scenarios in the Mediterranean Sea (15 arc-sec HySEA model resolution) and the Pacific Ocean (60 arc-sec resolution) with a time to solution up to 200 times FTRT. Moreover, a high-resolution inundation demonstrator was run for the Eastern Mediterranean Sea (Sicily) for an hypothetical tsunami triggered by a Mw=8 earthquake with 4 grid nesting levels down to 10 m resolution (14 times FTRT using 32 V100 GPUs at Marconi-100 machine for each single tsunami scenario). PD3  [41]  addressed Large-Eddy Simulations (LES) of multiphase volcanic plumes in a stratified multicomponent atmosphere using the ASHEE code. In addition, the resulting timeaveraged vertical profiles of mass flow rate were used to couple the local-scale ASHEE model with the regional-scale FALL3D ash transport and dispersion model  [42] , thereby increasing the coherence of the simulated data with respect to satellite-based observations.
To this purpose, the SeisSol code was extended towards fully-coupled Earth and Ocean models that combine seismic, acoustic and surface gravity wave propagation in elastic (Earth) and acoustic (Ocean) materials. PD4 was demonstrated considering different dynamic rupture and tsunami characteristics in several large megathrust tsunamigenic earthquakes, the A. D. 365 event in the Hellenic Arc, the 2004 Sumatra-Andaman earthquake and subsequent Indian Ocean tsunami  [47] , and the 2018 Palu Sulawesi earthquake-tsunami  [48]. The later example included an extreme-scale fully-coupled simulation using 3,072 nodes (147,456 cores) of the SuperMUC-NG supercomputer at LRZ, achieving more than 1 TFlop/s per node. PD5 enabled physics-based seismic hazard assessments with state-of-the-art multi-physics earthquake simulation software (SeisSol, SPECFEM3D and ExaHyPE).
This model now lays the foundation for a complete revision of the PSHA in the zone, both physics-based and conventional PSHA. In particular, the new fault system model contains three degrees of fault complexity for the Húsavík-Flatey Fault (HFF), the largest and primarily submerged strike-slip fault in Iceland that poses the greatest hazard to the coastal communities. Dynamic earthquake rupture scenarios were proposed on the HFF to explore the realistic range of ground motion amplitudes and the tsunami potential of fault rupture  [51, 52]. In Southern Iceland, CyberShake and the Anelastic Wave Propagator AWP-ODC simulator (an SCEC code not under the umbrella of ChEESE) were run assuming a subset of 17 faults for hazard calculation at selected cities and towns. Finally, SPECFEM3D was used to simulate the Mw 6.
PD7 applications focussed on the Mediterranean Sea, using tsunami source input data from a previous regional assessment produced by the TSUMAPS-NEAM (North-East Atlantic and Mediterranean) project  [58]. In particular, high-resolution (inundation modelled at 10 m model resolution) tsunami hazard maps were produced for Catania and Siracusa in Sicily by running large ensembles of scenarios, in chunks using each 32 nodes of Marconi-100 machine (i. e. 128 V100 GPUs)  [59]. Overall, the PD7 results comprised more than 2 million individual inundation simulations for 8 critical locations in the Mediterranean Sea (Heraklion, Messina, Thessaloniki and others), which will become a very valuable open dataset to benchmark other future PTHA applications within the scope of the EU Geo-INQUIRE project (see  Section 6).
PD8 was implemented in the Mediterranean Sea, with the underlying workflow using either pre-calculated tsunami scenarios (e. g. from the TSUMAPS-NEAM database) or running on-thefly a large ensemble of T-HySEA simulations with the FTRT time to solution premise. The former option is ready for operational use in a TEWS; the latter option, provided the availability of computational resources, is a potential game-changer for rapid post-event assessment, and it was successfully tested in a large-scale capacity workflow execution using 805 nodes (3,220 V100 GPUs) of Marconi-100 machine, reaching an extrapolated performance of 25. 7 PFlop/s. PD9 considered the imaging of internal structures of the Earth at different scales using Salvus and SPECFEM3D in conjunction with the Large-scale Seismic Inversion Framework (LASIF,  [62] ).
LASIF is a collaborative development between two ChEESE-1P partners (ETH Zurich and CNRS) for a data-driven workflow tool performing Full Waveform Inversions (FWIs) of continuous seismological data (waveforms) from the FDSN. For SPECFEM3D, a new code branch for efficient gradient computation and iterative model update (SPCEFEM3D_FWI) was developed  [63, 64]  in order to optimise the most costly component of the workflow (i. e. forward modelling and adjoint inversion in complex 3D media). For Salvus, relevant tools for data selection and visualisation as well as new functionalities for generating inputs files were added. PD9 was validated inverting up to 9 Hz a real dataset from exploration geophysics in the North Sea consisting on 138 Ocean Bottom Seismometers (OBS, about 70,000 shots per seismometer) and using 256 nodes of Marconi-100 (1,024 V100 GPUs) over 24 h.
A second PD9 use case focussed on the regional-scale Iberia-Pyrenees using stations in France, Spain and Morocco during the period 2011-2020 (inversion using 800 stations). PD10  [65]  implemented a scalable data-streaming workflow for automatic detection, location, and characterisation of seismic sources from continuous waveforms recorded by large seismic networks in order to improve seismic monitoring systems and enrich the seismic catalogues with previously undetected short transient signals (e. g. local earthquakes, phase arrivals from distant events). PD10 ported the BackTrackBB code  [66]  to Py-COMPSs  [67] , thereby improving efficiency, scalability, and parallel workflow task management in centralised HPC and cloud environments. PD10 was tested in two real-case datasets, the Vrancea seismic source in Romania, using continuous seismological data (waveforms) from the Romanian Seismic Network (RSN) at 46 stations spanning over a 1 month period (revealing 20 previously unregistered events), and a 4-year long continuous seismic dataset from stations in the Shikoku region, Japan  [68].
PD11  [69]  focussed on modelling the Earth's geomagnetic field, including both the simulation of past geomagnetic reversals with an unprecedented level of accuracy (using xSHELLS) and ensemble-based geomagnetic forecasts for the next few decades (using PARODY_PDAF), an aspect of particular interest when planning future space missions. In both cases, workflow tasks were orchestrated with WMS-light using archeomagnetic, volcanic and historical data from the HISTMAG database  [70]. PD11 was used to simulate with a global 3D spherical resolution of the order of 10 km during the equivalent geological time of 4 My, producing 5 geomagnetic polarity reversals and 9 so-called excursions  [71, 72]. On the other hand, ensemble forecasts considered multiple dynamo models with 512 members on 5,760 cores of Irene-Skylake machine.
Finally, PD12  [73] [74] [75]  implemented an ensemble-based data assimilation system (workflow) combining the FALL3D atmospheric dispersal model with high-resolution geostationary Infrared satellite retrievals (Meteosat -11, GOES-16, and Himawari-8 satellites). To this purpose, a parallel data assimilation system was implemented in FALL3D in order to run volcanic ash forecasts at an unprecedented resolution and over wide (continent-size) areas and driven by outputs from different meteorological datasets, including global model forecasts (GFS), global analyses and reanalyses (GDAS, ERA5), and mesoscale models (WRF/ARW). PD12 was validated against multiple past events including, e. g. the 2010 Eyjafjallajökull eruption (Iceland) or the February 2013 Etna event (Sicily), reaching a TRL of 9 (used operationally in a real case, see Section 5 for details).
Data sources Table  7  compiles the most relevant input data required to run the different PDs (see references in Section 4. 1 for details). In a broad sense, input data types in PDs can be classified as: (i) static; available from multiple external sources and typically stored and pre-processed locally before feeding the workflow, (ii) dynamic (data stream cached locally); continuously gathered from external repositories (e. g. to screen the occurrence and characteristics of a given event) and, (iii) co-located with the HPC systems (e. g. large pre-defined model inputs such as grids or configuration files). ChEESE-1P followed a Data Management Plan (DMP) to ensure that the datasets generated and post-processed during the project were managed according to the Findable, Accessible, Interoperable, and Reusable (FAIR) guiding principles  [76].
Modelling workflows and tools In parallel with the development and implementation of the different PDs, ChEESE-1P considered different heterogeneous aspects of modelling that go beyond the strict code preparation and optimisation. These included: 1. A geometric mesh partitioning library (Amik-1. 0) based on a Hilbert Space-Filling curve  [77]  that can be used either as standalone (e. g. for domain decomposition during code preprocess) or in runtime if coupled to a code-specific data redistribution library (e. g. for mesh adaptivity). With respect to other topological mesh partitioners (e. g. Zoltan,  [78] ), advantages of the geometric approach are that the domain decomposition load balance can be adjusted perfectly and that the mesh partition becomes independent of the number of CPUs, resulting in a much faster and highly-scalable partitioner.
2. Support to post-process and visualisation of large 3D and 4D datasets using the distributed data-parallel scientific visualisation in virtual reality (Vistle) software. This included coding special ChEESE extensions to import data from SeisSol and T/L-HySEA codes. 3. At the beginning of the project, some of the PDs inherited consolidated workflow frameworks (e. g. based on scripting, on LASIF  [62] , or on other diverse tailored solutions) whereas, in contrast, other PDs (e. g. PD6 or PD11) completely lacked any kind of workflow support. This deficit motivated the implementation of an HPC Workflow Management System (WMS-light,  [79] ) as a general tool to execute component-based workflows, extendible beyond the geosciences domain. WMS-light is built on a light-weight approach that reduces tailoring of the application and/or infrastructure to the absolute minimum while still meeting the major workflow execution requirements.
This showed the potential of wave propagation simulations to overcome the current data-driven sparse approaches based on Ground Motion Prediction Equations (GMPE) in case of quick post-event impact quantification. Finally, exercise 6 showcased the SeisSol code in 3D fullycoupled high-resolution (1. 5 to 5 Hz) earthquake and tsunami dynamics and the ExaHyPE code for uncertainty quantification, both simulating the 2018 Palu-Sulawesi event. The live demonstration showed how interference of seismic and acoustic waves may be dominant in data recorded by offshore instruments, which motivates fully coupled acoustic-elastic coupling with gravity solving an entirely new class of earthquake-tsunami problems. As success stories, it is worth mentioning that two services reached a TRL of 9 and became fully operational.