dataesr/scientific-paragraphs-categorization huggingface dataset:
This framework further allows us to connect the surface fields of sea surface salinity (SSS) and SST to changes in the stratification of the upper layers above the main pycnocline in the oceans. The remainder of the paper is organized as follows. Section 2 provides a description of the reanalyzed vertical profiles of temperature and salinity used as the data source, and the formal definition of the ocean salinity stratification (OSS). Section 3 presents the results, which include the main patterns of the seasonal cycle of the OSS in the Tropics (30 N-30 S). The paper concludes with discussion and conclusions in the sections 4 and 5.
The Ocean Model Configuration Our model is based on the Australian Community Climate Earth System Simulator-Ocean (ACCESS-O) configuration of the GFDL MOM4p1 ocean-ice code  [Delworth et al. , 2006]. A volume conserving approach based on the Boussinesq z* coordinates scaled with height along the vertical is used. The horizontal resolution is nominally 1 with equatorial refinement to 1/3 in the tropical band between 10 S and 10 N and a Mercator (cosine dependent) implementation for the Southern Hemisphere applied, ranging from 1/4 at 78 S to 1 at 30 S. In the vertical, ACCESS-O implements the z* coordinate available in MOM4p1, with 50 model levels covering 0-6000 m with a resolution ranging from 10 m in the upper layers (0-200 m) to about 333 m for the abyssal ocean. A detailed description of the model and physics can be found in O'  Kane et al.
Prior to January 1998, in situ profiles of temperature and salinity are assimilated from hydrographic data from World Ocean Circulation Experiment (WOCE) Hydrographic Program (WHP), World Ocean Database 2005 (WOD05)  [Boyer et al. , 2006] , and the Quality controlled Ocean Temperature Archive (QuOTA)  [Gronell and Wijffels, 2008] , which contains all XBT data in the Indian and South-West Pacific. After January 1998, we assimilate the WOCE Upper Ocean Thermal (UOT) database that includes global XBT data, except in the Indian Ocean where we use QuOTA for XBTs. Temperature and salinity are assimilated from Argo profiles and from the Tropical Atmosphere Ocean (TAO) array  [Oke et al. , 2013]. Standard deviations of T and S analysis increments (supporting information Figure  S1 ) averaged over the upper 350 m are largest in the western boundary current regions.
5 C and S to within 0. 2 psu in the upper 300 m (supporting information Figure  S3 ). The background innovations in the Pacific averaged over 630 latitude (supporting information Figure  S3 ) show that the largest background errors at 2 weeks lead time occur about the thermocline. The standard deviations of the background errors dramatically decrease over the period 2001-2004 as progressively more vertical profiles from the Argo data set become available for assimilation and the model upper ocean is constrained. For salinity, the background innovations show largest errors at the surface and at about 200 m with some evidence of a seasonal effect. Analysis innovations show the fit to the observations. For SST (supporting information Figure  S4 ), there is a marked reduction in both the analysis and background innovation errors of 0.
Discussion Maes  [2008]  initially defined the OSS to better characterize the eastern edge of the Western Pacific Warm Pool (WPWP) where the haline stratification exhibits a permanent east-west gradient. The importance of such stratification in a region where the ocean and the atmosphere are tightly coupled and where these interactions would drive the ENSO variability has been previously revealed by the concept of the barrier layer. The recently available Aquarius and Argo data for salinity reveals the close relationship and variability of the barrier layer and WPWP displacements  [Qu et al. , 2014]. Obviously, both the OSS and the BLT share some features in common, the main one being the representation of the stabilizing effect of the water column due to the salinity field. The shallow halocline that would mark the bottom of the upper mixed layer and the top of the thermocline has been named the barrier layer to highlight its role on the vertical turbulent mixing [e.
During the last decade, the key development of the ocean observing system has been the continued expansion of the Argo float network. Concomitant with temperature profiles, reliable in situ observations of salinity at depth are now available permanently at the global scales. Numerical systems developed for seasonal prediction and employing data assimilation could be utilized to investigate the impact of the salinity on climate variability. Recent results based on the state-of-the-art of prediction systems indicate that salinity is important for representing the state evolution of the equatorial thermocline  [Yang et al. , 2010; Zhao et al. , 2013]. More recently, two satellite missions, the Soil Moisture and Ocean Salinity (SMOS) mission, which is part of the ESA's Earth Explorer Missions, and the Aquarius mission, which is a joint project of the United States and the Argentine SAC-D observatory, have begun to produce global maps of SSS  [Lagerloef et al.
Acknowledgments The Argo data are collected and made freely available by the  International Argo Project  and the national programmes that contribute to it (http:// www. argo. net). C. M. appreciates the support of an  E. Frohlich Fellowship  and thanks  J. Brown  for hosting his recent visit to  CSIRO Marine and Atmospheric Research-Hobart  in 2013. T. J. O. is funded by an  Australian Research Council Future Fellowship  and the  Australian Climate Change Science Program. We would also like to thank the three anonymous reviewers for their comments on the original manuscript. Journal of Geophysical Research: Oceans.
8 ms. 15 healthy volunteers were recruited for the validation study and underwent Doppler echo and both our real-time PCMR sequence and a conventional high temporal resolution (≈10 ms) gated PCMR. Ten volunteers were recruited for the exercise study, in which subjects were imaged prone to facilitate the alternating weighted knee flexion exercise. Mean-velocity data at the MV and LVOT were extracted and used to calculate ejection time, isovolumic contraction time, isovolumic relaxation time (Figure  1 ).
Introduction Graph NoSQL engines such as Neo4J are now taking more and more importance in the applications. Their capacity to scale to large databases and complex treatments are well-suited for many applications having intensive needs for graph-oriented applications, such as in chemistry, biology, social networks, etc. Studies have shown that these technologies present good performances, much better than classical relational databases  (Board, 2013)  for representing and querying such large graph databases, especially for connected data. Retrieving relevant information from such graphs in an efficient manner is a key feature. In this perspective, retrieving decisional information, as done in the OLAP framework, appears to be a promising area. OLAP allows to represent key indicators as measures (e.
g. , number of sales) defined over dimensions (e. g. , product, time, location) and to query this information by selecting releveant pieces of information (e. g. , slice and dice) or by navigating through hierarchies (e. g. , from years to decades, from regions to countries), thus helping decision makers to retrieve relevant information. We thus consider adding OLAP features to NoSQL graph databases. In the literature, works have considered coupling graph and OLAP. Models have been proposed and have been implemented. OLAP queries have been translated to the graph framework. However, as far as we know, no work has addressed the exploitation of NoSQL graph databases for this purpose. In this paper, we thus propose to study how NoSQL databases can help retrieving relevant information from data using the OLAP paradigms.
We ad-dress both the representation of data cubes through NoSQL databases and the query processing. In our work, we consider the Neo4j engine and the declarative Cypher language. The paper is organised as follows. Section 2 reviews the related work, namely NoSQL databases and graph OLAP databases. Section 3 introduces our proposition for modeling NoSQL graph databases while Section 4 presents the extension of Cypher queries to OLAP NoSQL data cubes.
Definition 1 (Graph). A graph G is defined as a pair (V, E) where V is a set of nodes and E is a set of relations, with E ⊆ (V ×V ). Most of databases consider oriented graphs  (Angles and Gutiérrez, 2008; Reutter and Tan, 2011; Robinson et al. , 2013)  and contain elements (nodes and relations) together with properties on these elements. These properties are represented through (key, value) pairs. These concepts are often used in NoSQL databases  (Han et al. , 2011). Graphs are often represented graphically and are powerful for visualising and analysing data. On the one hand, they benefit from an easy human understanding. On the other hand, they offer excellent per- formances thanks to their data structures and query tools which are very relevant for many real-world contexts  (Rodriguez and Neubauer, 2010).
Fig. 2  shows a graph and its structure in (key, values) pairs. Their exist several NoSQL graph database engines (OrientDB, Neo4J,HyperGraphDB, etc. ). Neo4J is recognised as being one of the top ones regarding performance  (Board, 2013). (Chen et al. , 2009)  has proposed to couple graphs with OLAP in 2008. This approach consists in studying how a set of several graphs can be aggregated into a single summary graph. (Zhao et al. , 2011)  has introduced the concept of Graph Cube. This concept stands for a modelization of data cubes from graphs where dimensions are based on node attributes (e. g. , age, sex, city of birth for a people) and where facts are based on countings. Fig. 3  shows the cube from the paper example considering a low level of granularity and aggregations with OLAP operators.
Unfortunately, the paper does not demonstrate in details how to express OLAP queries and how queries are processed. (Petermann et al. , 2014)  discusses the concept of Business Intelligence in the context of graphs (storing information on commercial processes in this case, within Business Transaction Graphs). (Bachman, 2013)  addresses the implementation of precomputation componants over Neo4j databases and also addresses efficient computation of node arity. This work is very important for OLAP features as many operations rely on counting incoming and outgoing relations, as for instance for counting the number of friends in a social network. However, this work is a low level implementation and does not detail how OLAP queries can be written. Our proposition in this paper is quite different from the literature as we propose to use the graph structure as a basis for OLAP analysis.
This original contribution relies on the use of the performances and efficiency of NoSQL graph databases engines to store and query OLAP data. We first show how such NoSQL Graph OLAP data can be modelised and we then address OLAP queries over such data structures. (Zhao et al. , 2011)  3 NoSQL Graph OLAP Databases In this section, we present our contribution for modelising cubes in NoSQL graph databases. The case below serves as a running example. Example 1. We consider a classical database describing sales of products in cities at given dates. The dimensions are: the products described by their ProductId regrouped into Categories, the cities organised along a hierarchy City-Region-Country and the days organised along a hierarchy Day-Month-Year.
NoSQL Graph Cubes Our model relies on the modelisation of dimensions and facts with typed nodes. These types represent the granularity levels of the dimension, taking advantage from the best practices from NoSQL graph databases experts 1. It should be noted that OLAP theoretical models consider such granularity levels in the literature  (Gyssens and Lakshmanan, 1997). Nodes are linked by relations describing: • links of type hierarchy (HIER) in the case of dimensions, • links or type fact (FACT ) in the case of a link from a dimension to a fact. Our solution presents many advantages : • Multidimensionsal data are easily ploted on the user's screen, as demonstrated by Fig. 5. Every dimension can be colored so as to ease the user visualization. • The nodes can be adjusted (enlarged or reduced) according to their value.
It should be noted that the value in the node is valid only if it is considered in relation with all the dimensions. For instance, as stated above, Fig. 5  shows that there have been 5 units of Sales of Canoes in New York City on March 3, 2014. This value of 5 must be associated with all these three dimension values, i. e. Canoes, NYC, March3, 2014. If a dimension is omitted, then the value must be re-computed. In such a case where one (or several) dimension is omitted, a roll up operator has been ap- plied. In the OLAP framework, data analysis are indeed performed regarding dimensions in a so-called data cube. Sales can be analysed with respect with the three dimensions, or with respect with two dimensions out of these three, or with respect with one dimension out of the three dimensions.
Definitions Definition 2 (NoSQL Graph -Dimension Level). Let G be a NoSQL graph database. A dimension level of G is defined as a possible value associated with the property key Type. For instance, we consider the dimension level City. Definition 3 (NoSQL Graph -Dimension Node). Let G be a NoSQL graph database and L a set of associ-ated dimension levels. A dimension node n is defined as a node such as n. type ∈ L. We consider for instance the set of levels {City} and NYC as a node, with NYC. type = City.
Definition 4 (NoSQL Graph -Dimension Relation). Let G be a NoSQL graph database and N a set of dimension nodes. A dimension relation r is defined as a pair (n 1 , n 2 ) ∈ N 2 such that: • r. type=HIER • n 1. type = n 2. type. We consider for instance: • the set of levels {City, Region}, • the nodes NYC, East, • the types NYC. type = City and East. type = Region, and • the hierarchical relation (NYC) -[: HIER]-> (East). Definition 5 (NoSQL Graph -Dimension). A NoSQL graph dimension D is defined as a triplet (L, N, R) with L a set of dimension levels, N a set of dimension nodes defined over L and R a set of dimension relations defined over N. Definition 6 (NoSQL Graph -Type of Fact). Let G be a NoSQL graph database. A type of fact is defined as a possible value on the key T Fact. For example, we consider the type of fact Sales which records the number of sales.
We indeed claim that the performances of NoSQL databases allow for reconsidering MOLAP models. This model has proven his capacity to scale to very large volumes of data. As a MOLAP model, our contribution is thus very suitable for navigating through data and hierarchies. The computation of such NoSQL graph cubes is meant to be performed by importing source data within the model. Hypergraphs may be built if the data are already in NoSQL graph databases. Due to lack of space, OLAP graph-ETL tools are not explored in this paper.
Extension of the Cypher Language to OLAP queries The model of OLAP cubes in NoSQL graph databases proposed above allows us to define how to navigate through such data structures in an OLAP manner. OLAP has defined several operators, the most common ones being Slice, Dice, Roll Up  (Cabibbo and Torlone, 1997). Many works have addressed how to query graphs  (Wood, 2012). In this paper, we consider the Cypher syntax, Cypher being the declarative query language over Neo4J.
Slice In OLAP, the slice operator allows to select the data with respect to a condition on the dimension values. It is for instance used to reduce the data to the information related to one city (e. g. , New York) or to one region (e. g. , East). Note that the Cypher queries we propose below in Listings 1 and 2 return the cell with all its dimensional context. Listing 1: Slice -Selecting Sales Results from the New York City 1 MATCH ( n ) -[ r1 : FACT ] -> ( x ) , ( n ) -[ r2 : FACT ] -> ( y ) 2 WHERE x. name = ' NYC ' 3 RETURN n , r1 , r2 , x , y Listing 2: Slice -Selecting Sales Results from the East 1 MATCH ( n ) -[ r1 : FACT ] -> ( x ) -[ h : HIER * ] -> ( e ) , ( n ) -[ r2← : FACT ] -> ( y ) 2 WHERE e. name = ' East ' 3 RETURN n , r1 , r2 , x , e , y.
Implementation Issues The model we propose can be implemented in the Neo4j graph engine. As depicted by Fig. 8  and discussed in (Castelltort and Laurent, 2014), regarding queries, there exist several ways to implement the extension of Cypher: 1. Creating a specific language (Cypher OLAP) extending the Cypher syntax and rewriting these queries into well-formatted Cypher queries; 2. Extending the Cypher syntax and rewriting the queries using the low level API which can interact with the Neo4j engine; 3. Extending the API with advanced querying features and proposing this extension to developers; 4. Combining the above-mentioned options for developing an OLAP extensions based on the OLAP API. Whatever the choice may be, the type of rewriting is similar. This is the reason why we do not address this topic in this paper.
Conclusion and Further Work In this paper, we address the topic of coupling NoSQL graph databases and OLAP. These two scientific domains are very active and important in many real-worl applications. We claim that NoSQL graph databases are a perfect candidate for supporting OLAP features, as they are both efficient and suitable for representing data in a very intuitive manner for decisional purposes. Analysing data and retrieving relevant information indeed rely on the capacity to deal with big data and the capacity to help the decision makers. For this purpose, we propose an OLAP data structure based on NoSQL graph databases and we introduce OLAP queries based on the Cypher declarative language. Some tests have been performed with the Neo4j engine, showing the feasability of our proposition.
Further work will help us strengthening the implementation and tests over large databases and complex OLAP queries. Both incoming processes and queries will be enhanced, by defining specific ETL componants and by implementing the of the Cypher language. We also aim at exploiting the NoSQL graph databases and the attributes on relationships in order to better represent and manage fuzzy hierarchies  (Rogova et al. , 2007; Laurent, 2003)  that are very difficult to deal with in existing engines.
org) scales with the seismic period to the fourth power, whereas the axisymmetric method (AxiSEM) scales to the third power. We calculate the cost estimation upon saving 10 6 spatial points, a moderate task to compute wavefields. This is especially noteworthy for the mode solution, whose cost scales directly with the number of saved spatial points. tention for achieving realistic wave propagation simulations towards: -feasible choices for source and structure, -usability of the method, -availability of computational resources. While all of these issues are common to any numerical method and not easily resolvable, the latter point is especially stringent. Worse still, for global seismology the prohibitive cost will remain a dominant limitation on the maximally resolved frequencies and a exponentially increasing number of usable data with millions of recorded waveforms (IRIS annual report 2011, www.
1 ) offers both a wealth of seismic data and a resolution harboring many open geophysical questions. The plot in Fig. 1  is an approximate, order-of-magnitude estimation of computational cost, and minor algorithmic optimization does not affect this overarching trend drastically. The slightly increased cost for AxiSEM above 10 s represents the fact that the thin crustal layers at these long periods start to dominate the smallest element size and thus increase the relative cost due to this geometric constraint on the global time step. This is not seen in SPECFEM, since intra-crustal layers are not explicitly meshed. Further commentary on Fig. 1  is given in Sect. 2. 7. Considering desirable features for the inversion such as comprehensive model sampling, uncertainty analysis, or probabilistic approaches, this represents not only a formidable challenge, but is essentially not computable even with most optimistic estimates of the evolution of computation on a decadal timescale, especially in 3-D.
, 2008)  may accommodate this effectively, but suffer various shortcomings such as approxi-mate sources, lack of fluid domains and anisotropy  (Jahnke et al. , 2008) , and high dispersion errors for large propagation distances of interface-sensitive phases such as surface or diffracted waves. However, recent advances include a full moment tensor, attenuation, and the Earth's center  (Toyokuni and Takenaka, 2012). The purpose of this paper is to introduce the axisymmetric spectral-element method for global wave propagation and the corresponding publicly available, production-ready code AxiSEM, which taps into parameter regimes that have been previously unavailable at similar computational cost. We motivate the relevance of these parameter regimes by various examples and present ideas for further extensions and applications.
This paper is organized as follows. A methodological chapter briefly summarizes the mathematical background of our approach, delegating more details to previous publications, and focusing instead on practical matters such as scalability, runtime requirements, I / O, and code availability. Chapter 3 describes those source types that may be simulated with AxiSEM, ranging from moment tensors, single forces, to finite faults and stochastic sources. Chapter 4 similarly describes a range of background models to be discretized in AxiSEM, including anisotropy, intrinsic attenuation, classical 1-D Earth models, solar models, small-scale 2. 5-D heterogeneities and tomographic cross sections, random media and explicit mesh representations of the crust and oceans (oceans are not part of the current code as of April 2014).
Chapter 5 shows simulation results for a selection of the previously mentioned ranges of applicability, covering the entire seismic frequency spectrum, 3-D wavefield visualization, lowermost mantle structures, simulations for 2. 5-D slices through a tomography model, comparison with observed data from lowermost mantle and core phases, and sensitivity kernels. A concluding chapter discusses the general applicability, limitations and an outlook for future developments. AxiSEM is a mature methodology and code, able to address a number of intriguing scientific questions. As should be commonly known from any software implementation, the level of automatism for the applications listed here is diverse, and readers should refer to the manual of the most recent release version for up-to-date features of the code.
2. Radiation patterns for monopole (top), dipole (middle), and quadrupole angular orders of the respective moment tensor elements. The azimuthal radiation patterns encapsulated by f l depend on multipole order m as well as component l, that is, no summation is implied by the above products. waves. However, recent advances include a full moment tensor, attenuation, and the Earth's center  (Toyokuni & Takenaka, 2012). The purpose of this paper is to introduce the axisymmetric spectral-element implementation AxiSEM as a new and 190 publicly available, production-ready method and code for global wave propagation, which taps into parameter regimes that have been previously unavailable at similar computational cost. We motivate the relevance of these parameter regimes by various examples and present ideas for further 195 extensions and applications.