dataesr/scientific-paragraphs-categorization huggingface dataset:
Excessive input/output Spectral-element methods of the kind presented here have 455 excellent scalability properties in general (Fig. 6 ). The bottleneck, especially when moving to higher resolution and larger parallelization, lies in disk access which is necessary for saving wavefields and seismograms at run-time. For storage of synthetic seismic data, especially for a database of pre-460 computed waveforms (see sect. 5. 3), platform-independence of the data is needed. However, the storage format of Fortran binary files is not even compiler-independent. To ensure true platform independence, AxiSEM fully supports the widely accepted NetCDF4 (http://www. unidata. ucar. edu/ 465 netcdf/) format to store seismograms and wavefields, but users may also revert to Fortran binary if desired. A NetCDF4 file is a container, in which very large variables (e.
475 small amounts of data such as time series can be read from a (potentially very large) file, without loading the whole file into memory. The code allows to store all simulation output in one self-contained NetCDF4 file, which facilitates handling of a large number of simulation results, for example in 480 parameter studies. NetCDF4, which is based on the HDF5 format, allows for parallel writing into one file. Since this makes use of parallel file systems very efficiently, it might provide big performance gains on the next generation of supercomputers.
485 On the current generation however, the installation of parallel NetCDF4 is not generally reliable yet. Therefore and to increase compatibility with older machines, AxiSEM uses a serial round Robin-scheme for writing data to disk. All processors buffer their respective wavefield output locally. After 490 a set number of time steps, one instance spawns a new thread and transfers its wavefield buffer to it. This new thread then opens the output file and compresses and writes the buffer to disk, while the original processor continues to simulate the wavefield. This non-blocking IO scheme has been tested to 495 work well up to 224 parallel instances, in that wavefield storage marginally affects CPU time and performance.
Excessive input/output Spectral-element methods of the kind presented here have excellent scalability properties in general (Fig. 6 ). The bottleneck, especially when moving to higher resolution and larger parallelization, lies in disk access, which is necessary for saving wavefields and seismograms at run time. For storage of synthetic seismic data, especially for a database of precomputed waveforms (see Sect. 5. 3), platform independence of the data is needed. However, the storage format of Fortran binary files is not even compiler independent. To ensure true platform independence, AxiSEM fully supports the widely accepted NetCDF4 (http://www. unidata. ucar. edu/netcdf/) format to store seismograms and wavefields, but users may also revert to Fortran binary if desired. A NetCDF4 file is a container in which very large variables (e.
g. , wavefields) as well as single scalar values (e. g. , general simulation information) can be stored. The format allows transparent compression of the variables using the SZIP algorithm  (Shu Yeh et al. , 2002) , which saves around 50 % of hard drive space for a typical seismic wavefield with respect to generic binary format. The container character of a NetCDF file means that direct access to selected data is possible, i. e. , small amounts of data such as time series can be read from a (potentially very large) file, without loading the whole file into memory. The code allows the storage of all simulation output in one self-contained NetCDF4 file, which facilitates the handling of a large number of simulation results, for example in parameter studies. NetCDF4, which is based on the HDF5 format, allows for parallel writing into one file.
Since this makes use of parallel file systems very efficiently, it might provide significant performance gains in the next generation of supercomputers. In the current generation however, the installation of parallel NetCDF4 is not generally reliable yet. Therefore, and to increase compatibility with older machines, AxiSEM uses a serial round Robin scheme for writing data to disk. All processors buffer their respective wavefield output locally. After a set number of time steps, one instance spawns a new thread and transfers its wavefield buffer to it. This new thread then opens the output file and compresses and writes the buffer to disk, while the original processor continues to simulate the wavefield. This non-blocking IO scheme has been tested to work well up to 224 parallel instances, in that wavefield storage marginally affects CPU time and performance.
Implementation and availability The AxiSEM code is written in Fortran2003 combined with MPI message passing, requiring corresponding compilers. Optional additional packages are NetCDF4  (Rew and Davis, 1990)  for improved I / O, fftw3  (Frigo and Johnson, 2005)  for post-processing in the frequency domain, TauP  (Crotwell et al. , 1999)  for traveltime picks, paraview for visualization of vtk-and xdmf -based wavefields, Matlab for visualization of record sections, gnuplot for creating seismogram image files, Google Earth for visualization of source-receiver geometries and seismograms on the sphere, and python wrappers for streamlined input/output and linkage to Ob-sPy  (Beyreuther et al. , 2010). The Fortran2003 code is divided into a Mesher utilizing OpenMP, a solver utilizing the message-passing interface (MPI) for communication between separate domains, and extensive post-processing for ease of visualization, filtering, source-time functions, various receiver component systems, and moment-tensor solutions.
In light of the common problem of local minima in (non-linear) source inversions, this offers an efficient engine for performing comprehensive studies on the behavior of different fault models and methodologies  (Page et al. , 2011). The modeling of finite sources is thereby largely delegated to post-processing (see Sect. 5. 3), such that existent AxiSEM databases can simply be applied to finite sources as well, and finite faults can be naturally embedded within any application of AxiSEM with little additional computational effort.
Spherically symmetric models Spherically symmetric models such as PREM, IASP91, and ak135 are automatically incorporated into AxiSEM. The code also allows for flexible inclusion of arbitrary 1-D structures in the meshing process, such that other Earth models such as those based on mineral physics can be easily accommodated. One may also apply the methodology to other planetary bodies (e. g. , Moon, Mars, Europa; not shown here) including purely fluid media to facilitate acoustic wave propagation (a computational shortcut still popular in the exploration industry), which drastically reduces computational cost. As a curious case of extreme medium variations readily discretized by our methodology, we reach out for our central star: the Sun is a giant fluid sphere subject to turbulent redistribution of masses, magnetic field variations, and acoustic body waves  (Gizon and Birch, 2002).
The background structure of the Sun covers many orders of magnitude in density due to its huge size and gravitational force, and about two orders of magnitude in acoustic wavespeeds. Only the radial wavespeed gradient matters for meshing, thus it is easily possible to adapt the AxiSEM mesh to the Sun, as seen in Fig. 8. Surface boundary conditions for acoustic waves (i. e. , vanishing pressure) pose no technical difficulty, but are not yet included in the first code release and shall be added in a timely future version.
Finally, Born theory may be applied by assuming ellipticity (including internal interfaces) to act as a boundary perturbations to the spherical model domain. This way, entire seismograms are accounted for jointly. This approach has not been implemented or tested at this point. Rotation of the polar axis can in principle be incorporated into AxiSEM, but only for a polar source, which clearly is a rather unique case of rotation. On the scale of interest where rotation comes into play (above periods of 100 s), one could devise a torusshaped, off-axis source in case its azimuthal radiation is of lesser significance -as may be the case for free oscillations. This would be a field of further study and implementation. In summary, such effects grow into a visible and recordable first-order issue for rather specific cases of seismic data analysis concerned with pathological body-wave paths and very long-period seismology.
Queries to such databases (such as a record section of arbitrary source-receiver geometries, filters, sourcetime functions, and a range of spherically symmetric Earth models), can be completed within minutes by means of the same kind of post-processing as done upon the AxiSEM code. This can be tremendously beneficial in studies that need to sample a large range of parameters such as source inversion problems, especially in a probabilistic framework  (Stähler and Sigloch, 2013).
Tomographic models Global models derived from tomography can also be approximated by an in-plane rendition with AxiSEM, in that they usually deviate only mildly and smoothly from spherically symmetric Earth models. Just as in the previous ex-975 ample, wavefield effects captured by this methodology are those that obey forward scattering, whereas true 3D-medium effects such as off-plane scattering are neglected. Of course, this azimuthal invariance does not represent our nature's dimensionality, but mimics a substantial sub-set of those data 980 that are actually used for waveform modeling or tomography rather well and at a cost many orders of magnitude below that of simulating a 3D domain. This can be seen in Fig. 15 , a comparison between synthetic modeling through a PREM, an in-plane collapse of tomographic model S40RTS 985  (Ritsema et al.
, 2008)  and CRUST2. 0 (Bassin et al. , 2000) , which are accurate to about 17 s  (Tromp et al. , 2010). AxiSEM synthetics are based on an inverted moment tensor and depth, whereas SPECFEM synthetics are taken from the IRIS database, i. e. , calculated for GCMT. All synthetics have been convolved with an inverted source-time function. The phases have been aligned by frequency-dependent cross-correlation, forming the basis for tomographic inversions. The waveform differences between all three traces fall within a feasible range of conducting waveform tomography. 5-15 AxiSEM 2. 5 (σ 2 = 0. 99) 2. 3 (σ 2 = 0. 5) 15-45 AxiSEM 4. 0 (σ 2 = 0. 89) 3. 4 (σ 2 = 0. 3) 15-45 SPECFEM 3. 7 (σ 2 = 0. 6) 6. 0 (σ 2 = 0. 37) Such comparisons include (as per usual) inevitable differences in processing such as event origin time and location, and source time function.
axisem. info. This parameter space promises a diverse range of applications that were previously inconvenient, inexact, or unattainable due to limited computational resources or methodologies. Specifically, the main factor attributed to its efficiency in a 2-D computational domain is the availability of space-time wavefields for axisymmetric, viscoelastic anisotropic media and realistic earthquake sources. We have touched upon a few key applications, far and away from explaining or validating each one of them. Rather, the purpose of this paper is to present a new open-source methodology and scan its usability specifically in those directions that we deem most benefitting from this modeling tool. Details on specific applications and implementation are found in other publications to be submitted, and the state of reliable features in the code should always be consulted in its concurrent manual.
Acknowledgements. Review comments by  Guust Nolet  and  Nobuaki Fuji  significantly improved the manuscript. Financial support has been provided by the  EU   Framework program 7 (QUEST network ), and the " Petaquake "  HP2C  project funded by the  Swiss National Fund. Simulations were done at  ETH 's computing facilities and  CSCS in Switzerland , as well as  HECToR (UK) , whose support is appreciated. The contribution of AF is IPGP contribution 3514. SCS was funded by the  Munich Centre for Advanced Computing (MAC) ,  SH  under grant  DFG TH1530/3-1. We are indebted to  Jean-Paul Ampuero ,  Lapo Boschi ,  Emmanuel Chaljub ,  Tony Dahlen ,  Andreas Fichtner ,  Domenico Giardini ,  Heiner Igel ,  Dimitri Komatitsch ,  Guust Nolet ,  Karin Sigloch ,  Frederik Simons ,  Christine Thomas  and  Jeroen Tromp  for constructive ideas, suggestions, and support that greatly improved AxiSEM over the past years.
This system couples a mobile user device that detects tangible objects (equipped with RFID tags). The information is transmitted to the database. The steps are executed so that information is fed back to the mobile device and the main interface (PC and video projector). Melchior  14  suggests using a Multi-Agent System to distribute the user interface to multiple devices (not particularly tangible). Finally, the Ensemble architecture is suggested by Branton et al. 15  to encourage exploratory development of distributed, tangible and collaborative applications by limiting the impact of changing components. In the literature, tabletops have not really been exploited for cooking. Gaver et al. 's History Tablecloth was designed as a digital layer that sits on top of a dining table. It traces the food prints of the objects placed on it, thereby subtly revealing various social patterns within the home  16.
Proposal for a Tabletop architecture augmented for distributed surfaces This section presents a software architecture for managing distributed surfaces with agent concepts. The proposed architecture is based on a combination of a Multi-Agent System (MAS)  20  and Human-Computer Interaction (HCI)  21  concepts to adapt the user interfaces. This architecture is based on the formalisms defined in  22, 23  to design applications on interactive tabletops. These formalisms are used to define the different types of agents (virtual or tangible) and their management on an interactive tabletop surface. This architecture is composed of four layers: • The hardware layer represents the tabletop surface detection. It is used to receive the signals provided by objects identified by a barcode, an image or an RFID tag, for example.
This new architecture integrates the exchanged messages between the software entities described on Fig. 3. This figure shows the mix between different kinds of display surfaces that are not necessary on the tabletop and takes into consideration the interest in displaying information across several complementary displays. In this case, the sensor surface is similar to the display surface and the entities (e. g. , the agents of the MAS) receive the sensory inputs from the interactive tabletops. We propose an instanciation of the architecture considering multiple complementary displays dedicated to tabletops (e. g. , several displays used simultaneously). The display areas differ in size, thickness, resolution, layout (vertical or horizontal) and light source (e. g. , LED, LCD or plasma). In addition, the display is located on the tabletop or distributed surface to facilitate user interaction.
This agent will have a set of knowledge on the type of product, its position on the tabletop surface and the expiration date. After placing ingredients on the table surface, users can use an object to trigger actions. This tangible object, called the Ideas Cube, searches for and displays recipes on a screen. The sides of this object determine whether dish or dessert ideas will be displayed. The agent in charge of the Ideas Cube communicates with other agents, such as ingredients, to collect data and sort the recipes in a database by relevance. When the user changes the face of the Ideas Cube, other recipes adapted to the characteristics of the user card are displayed. When a recipe is selected, the agent transfers the information to the upper layer (the HCI layer). The HCI layer is responsible for user feedback.
Acknowledgements This research was partially financed by the  French Ministry of Education, Research & Technology , the  Nord/Pasde-Calais Region , the  CNRS , the  FEDER program ,  CISIT  ( Plaiimob  project), and the  French National Research Agency (ANR TTT  and IMAGIT projects, financial IMAGIT support:  ANR-10-CORD-017 ). The authors would like to thank the partners with whom we collaborated on the TTT and IMAGIT projects: LIG, RFIdees and the  CEA.
An early major work was KIF (Knowledge Interchange Format)  (Genesereth and Fikes, 1992) , a 1st-order logic based KRL -with a 2nd-order notationto which most KRLs could be translated to and formalized with. Many were. To ease this, the Ontolingua "ontology server or shared repository"  (Farquhar et al. , 1997)  provided a well formalized KRL model ontology. E. g. , it included a formalization of frame-based language concepts in KIF (concepts similar to those of OWL). Later, with the popularization of MOF (the Meta-Object Facility of the OMG: Object Management Group), XML and then RDF, many language models or ontologies were created in these three languages. These were often simple lists of KRL components and their structural relations. Indeed, MOF, XML and RDF do not permit to fully define KRL components and hence relate all of them as in Ontolingua.
It also proposes GRDDL for specifying where a software agent can find "algorithms (typically represented in XSLT)" to convert a structure or notation to RDF/XML. Conversely, there are some style-sheet based transformation languages and ontologies for specifying how RDF abstract structures can be presented, e. g. , in a certain order, in bold, in a pop-up window, etc. : Xenon  (Quan, 2005) , Fresnel  (Bizer et al. , 2006) , OWL-PL  (Brophy and Heflin, 2009)  and SPARQL Template  (Corby et al. , 2014). With these tools or the approach behind these tools, each modification to a notation requires a new template or style-sheet, and parsing is not addressed. Supporting knowledge import/export/translation in a generic way requires specifying KRLs with respect to a KRL model ontology and a KRL notation ontology.
Introduction In the context of the European Water Framework Directive  (DCE, 2000) , the Fresqueau project funded by the French Agency for research  ANR (2011 ANR ( -2014) )  aims to develop new methods for studying, comparing and exploiting all the available parameters concerning the status of running waters as well as the information describing uses and undertaken measures. More precisely, the project will contribute to the answer to two specific issues: (1) going farther into the understanding of running water functioning through the analysis of taxa that support biological indices, and (2) connecting the sources of pressure and the physicochemical and biological quality of running waters. The first step of the project was the definition of an integrated Database (DB), integrating data from 20 public databases related to water quality assessment.
, 2010; Boulil et al. , 2013b; McGuire et al. , 2008; Pinet and Schneider, 2010). DWs are databases dedicated to the integration and storage of large volumes of data to support the decision processes of organizations  (Inmon, 2005). DWs store decisional data at the finest granularity level and organize the data in a way that facilitates the analysis/aggregation. OLAP tools allow an interactive exploration of DW data at different levels of detail, following a multidimensional approach. These tools build multidimensional data structures having different granularities, called data cubes, by aggregating DW data and provide users with operators for rapid exploration of these data cubes. Data cubes represent the measures/metrics (e. g. , temperature) of the subjects analyzed or of the facts in a space with multiple dimensions (analysis criteria for facts such as time and geographic locations, etc.
) according to the multidimensional abstraction model. The dimensions are organized into hierarchies of aggregation levels to allow viewing analysis indicators (aggregations of measures) at different granularities. DW and OLAP data cubes are generally implemented in relational platforms consisting of four tiers  (Boulil et al. , 2013b; Malinowski and Zimányi, 2008) : the ETL that integrates data from data sources into the DW, the DW (a relational database that stores the finest data), the OLAP server that calculates the data cubes from the DW data and the OLAP client that displays the data cube information using tables and different types of statistical diagrams (pie charts, histograms, etc. ) and reports in different export formats. Unlike the OLTP tools, OLAP tools provide end users with easy to use and powerful analysis methods that enable dynamic changes of the analysis perspective and the granularity of data.
The conceptual framework is formalized as a UML profile, an extension of UML. Unlike related work, our framework particularly allows the definition of complex analysis indicators using complex and/or multiple aggregate functions. In this paper, we first show the application of the OLAP technology to the field of water quality assessment. The architecture of the OLAP system that we defined consists of two data cubes, a data cube storing data about the physicochemical water quality and another data cube concerning hydrobiological water quality data, tools that allow their periodical feeding with data from operational data sources (an integrated database and some Excel files) and tools for the OLAP analysis by water quality practitioners. This architecture is based only on free software and can easily be extended with other data cubes (e.
g. , a data cube for the analysis of morphological data on watercourses that is another important element in the water quality assessment) and software components (other data sources, other data analysis tools such as data mining, etc. ). Using some examples, we demonstrate how the OLAP technology, unlike OLTP tools such as Excel, can help water quality practitioners to increase their productivity by offering a series of intuitive interfaces that facilitate and accelerate the multidimensional analysis and understanding of water quality data. We render this possible by defining various analysis indicators and enabling simple (thematic, spatial, and temporal) and combined (spatiotemporal) analysis on multiple scales. Using our framework  (Boulil et al. , 2013a ) that we extend here by complex aggregate functions (e.
OLAP and DW: main concepts In addition to data mining tools, Data Warehouses (DWs) and On-Line Analytical Processing (OLAP) tools are main Business Intelligence (BI) technologies  (Kimball and Ross, 2002). A DW is defined as "a collection of subject-oriented, integrated, nonvolatile, and time-varying data to support the decision-making processes of an organization  (Inmon, 2005) ". A DW often integrates and stores large datasets from multiple and heterogeneous data sources, and the DW information is generally accessed in a read only way and can have different values associated with different time instants or periods. DW also organizes data according to the main analysis subjects of the organization in way that facilitates data analysis tasks. For example, a DW of a retail company should contain data about analysis subjects such as sales, purchases, inventory management, etc.
DWs are implemented mostly in terms of relational databases following the well-known star schema  (Kimball and Ross, 2002). This schema defines two main data structures: fact tables that store values of measures or metrics of the analysis subjects and dimension tables that store data related to analysis criteria. OLAP tools are a type of software allowing end users to explore DW data interactively, multidimensionally and at different levels of detail  (Codd et al. , 1993; Kimball and Ross, 2002). On the basis of some metadata (the OLAP schema), these tools transform DW data into strategic information: different data analysis indicators that can be viewed at different granularities and from different analysis perspectives. Indicators, granularities and/or analysis perspectives can be changed rapidly using OLAP operators that handle DW data in terms of data cubes.