dataesr/scientific-paragraphs-categorization huggingface dataset:
Models of the rotor-stator contact problem in an industrial code Few results in the literature deal with 3D rotor-stator contact problems. This may well be due to the somehow high computational cost engendered by such models. To reduce this computational cost, the 1D and 3D dynamical model coupling was the main concern in Tannous et al. [35]  but no 3D contact modeling was addressed at that time. This paper proposes a first 3D contact model between the rotor and the stator, implemented within an industrial FE code, namely Code Aster, whose features have been enhanced to address a complex 3D rotor-stator problem, consistent with the previous 1D contact model.
Contact model suited to the 1D geometry description: the impact law The penalty approach is used for both the 1D and the 3D contact problems in the scope of this paper. In this section, we present the geometric approach that is available for 1D contact problems in Code Aster. It is a simple and efficient 1D modeling approach (cf. [36] ), based on a node-to-node contact formulation. The equations of motion that take into account the gyroscopic effects are settled in the 1D model rotating frame. The involved impact law has been improved recently to take into account the computation of the frictional torque between the rotor and the stator. Dedicated to the 1D problem, this model is presently one of the best 1D contact approaches, due to its computational efficiency and accuracy. It is illustrated in Fig.
Conclusions This paper aimed to compare 3D and 1D models of rotor to stator contact. The 1D model obviously relies on more restrictive assumptions than the 3D model, mainly because of the use of a beam model which is based on a rigid-body kinematics for the cross-section. Therefore, the 3D results can be considered as reference results which provide a mean to assess the validity of the 1D model. Simulation examples were carried out on industrial turbines inspired from the TAG of EDF nuclear parks and on the industrial finite element code Code Aster. The main conclusions are recalled in the following. In a 3D model, the rotor cross-section deformation leads to a narrower rotor to stator contact interface, and thus leading to local deformations and a stator behavior that is explicitly different between a 1D and a 3D model.
What it does contain is method signatures and, crucially, a session type definition which specifies the availability of methods. We will refer to a skeleton class definition of this kind as an interface, using the term informally to mean that method definitions are omitted. The figure shows the method signatures in the session type and not as part of the method definitions as is normal in many programming languages. This style is closer to the formal language that we define in Section 3. Line 3 declares the initial session type Init for the class. This and other session types are defined on lines 4-7. We will explain them in detail; they are types of objects, indicating which methods are available at a given point and which is the type after calling a method. In a session type, the constructor {.
Methods open and hasNext return a constant from an enumeration: OK or ERROR for method open, and TRUE or FALSE for method hasNext. Enumerations are simply sets of labels, and do not need to be declared with names. Figure  3  defines the class FileReader, which uses an object of class File. FileReader has a session type of its own, defined on lines 2-3. It specifies that methods must be called in the sequence init , read, toString, toString,. Line 5 defines the fields of FileReader. The formal language does not require a type declaration for fields, since fields always start with type Null, and are initialised to value null. Fields are always private to a class, even if we do not use a corresponding keyword. Lines 7-10 define the method init , which has initialisation behaviour typical of a constructor.
Lines 12-19 illustrate the switch construct. In this particular case the switch is on the result of a method call. One of the distinctive features of our language is that it is possible, instead, to store the result of the method call in a field and later switch on the field; we will explain this in detail later. This contrasts with, for example, Sing#  [31] , in which the call/switch idiom is the only possibility. The while loop (lines 16-17) is similar in the sense that the result of file. hasNext must be tested in order to find out whether the loop can continue, calling file. read, or must terminate. Line 21 defines the method toString which simply accesses a field. Typechecking the class FileReader according to our type system detects many common mistakes. Each of the following code fragments contains a type error.
The only available method is open. • f i l e. c l o s e ( ) ; i f ( f i l e. hasNext ( ) ). After calling close, the file is in state Init , so the method hasNext is not available. Only open is available. Clearly, correctness of the code in Figure  3  requires that the sequence of method calls on field file within class FileReader matches the available methods in the session type of class File, and that the appropriate switch or while loops are performed when prescribed by session types of the form. in class File. Our static type system, defined in Section 3, enables this consistency to be checked at compile-time. A distinctive feature of our type system is that methods are checked in a precise order: that prescribed by the session type ( init , read, toString in class FileReader, Figure  3 ).
In general, those types are two separate things. However, when the subsequent behaviour of the object depends on the returned value, like the case of Open in type Init on line 3 of Fig. 1 , the return type is an enumerated set of labels and the subsequent session type is a variant which must provide cases for exactly these labels. To simplify definitions, we avoid this redundant specification in the formal language, and when the subsequent session type is a variant, the return type of the method is always the special type variant-tag, which indicates that the method will return a label from the variant. Contexts E ::= [_] | E; e | switch (E) {l : e l } l∈E | return E | f ↔ E | f. m(E) The productions for types, values and expressions extend those in Figure  5. Session types may never contain types of the form link f , even in the extended syntax.
A Distributed Example We now present an example of a distributed system, illustrating the way in which our language unifies session-typed channels and more general typestate. Recall that our programming model is based on communication over TCP/IP-style socket connections, which we refer to as channels. The scenario is a file server, which clients can communicate with via a channel. The file server uses a local file, represented by a File object as defined in Section 2, and responds to requests such as OPEN and HASNEXT on the channel. On the client side, the remote file is represented by an object of class RemoteFile, whose interface is similar to File. In this "stub" object, methods such as open are implemented by communicating with the file server. The channel between the client and the server has a session type in the standard sense  [70] , which defines a communication protocol.
In our language, each endpoint of the channel is represented by an object of class Chan, with a class session type derived from the channel session type. This class session type also expresses the definition of the communication protocol, by specifying when the methods send and receive are available. For the purpose of this example, we imagine that the communication protocol (channel session type) is defined by the provider of the file server, while the class session type of RemoteFile is defined by the implementor of a file system API. We therefore present two versions of the example: one in which the channel session type, and the class session type of RemoteFile, have the same structure; and one in which they have different structures. Figure  16  defines a channel session type for interaction between a file server and a client.
Distributed Example Version 2. This version has a different channel session type, FileChannel, defined in Figure  20 , which does not match the class session type FileRead. The difference is that there is no HASNEXT option; instead, the READ option is always available. If there is no more data then EOF is returned in response to READ; alternatively, DATA is returned, followed by the desired data. The corresponding class session types for the client and server endpoints are defined in Figure  21. The implementation of RemoteFile must now mediate between the different structures of the class session type FileRead and the channel session type FileChannel. The new definition is in Figure  22. The main point is that the definition of the close method must depend on the state of the channel. For example, if close is called immediately after a call of hasNext that returns TRUE, then the channel session type requires data to be read before CLOSE can be sent.
The syntax extensions do not include request, accept, send and receive, as they are treated as method names. 6. 2. Semantics. Figure  25  defines the reduction rules for the distributed language, as well as the top-level typing rules. The reduction rules make use of a pi-calculus style structural congruence relation, again following Gay and Vasconcelos  [39]. It is the smallest congruence (with respect to parallel and binding) that is also closed under the given rules. Rule R-Init defines interaction between accept and request, which creates a fresh channel c and substitutes one endpoint into each expression. There are two rules for communication, involving interaction between send and receive. Rule R-ComBase is for communication of non-objects and rule R-ComObj is for communication of objects.
Plural is a prototype language implementation that embodies this approach, providing automated static analysis in a concurrent object-oriented language  [9]. To evaluate their approach they annotated and verified several standard Java APIs  [10]. Militão et al. [54]  develop a new aliasing control mechanism, finer and more expressive than previous proposals, based on defining object views according to specific access constraints. The discipline is implemented in a type system combining views and a typestate approach, checking user defined aliasing patterns. Sing#  [31]  is an extension of C# which has been used to implement Singularity, an operating system based on message-passing. It incorporates session types to specify protocols for communication channels, and introduces typestate-like contracts.
Bono et al. [12]  have formalised a core calculus based on Sing# and proved type safety. A technical point is that Sing# uses a single construct switch receive to combine receiving an enumeration value and doing a case-analysis, whereas our system allows a switch on an enumeration value to be separated from the method call that produces it. Aldrich et al. [1]  have proposed typestate-oriented programming. The aim is to integrate typestate into language design from the beginning, instead of adding typestate constraints to an existing language. Their prototype language is called Plaid. Instead of class definitions, a program consists of state definitions; each state has methods which cause transitions to other states when they are called. Like classes, states are organised into an inheritance hierarchy.
With respect to technical differences, the main ones are: (a) session types unify types and typestates in a single class type as a global behavioural specification; (b) our subtyping relation is structural, while the typestates refinement relation is nominal; (c) Plural uses a software transactional model as concurrency control mechanism (thus, shared memory), which is lighter and easier than locks, but one has to mark atomic blocks in the code, whereas our communication-centric model (using channels) is simpler and allows us to use the same type abstraction (session types) instead of a new programming construct; moreover, channel-based communication also allows us to specify the client-server communication protocol as the channel session type, and to implement it modularly, in several methods which may even be in different classes; (d) typestate approaches allow flexible aliasing control, whereas our approach uses only linear objects (to add better alias/access control is simple and an orthogonal issue).
Affine types. Tov and Pucella  [71]  have developed Alms, a language in the style of OCaml with an affine type system as a generalisation of linear typing. Alms is a general-purpose programming language, in which the affine type system provides an infrastructure suitable for defining a variety of type-based resource control patterns including alias control, session types and typestate. It has been implemented, and type safety has been proved for a formal calculus. Representing a particular approach to typestate, such as our specifications of allowed sequences of method calls, would require an encoding; in contrast, our language aims to provide a convenient high-level programming style. Static verification of protocols. Cyclone  [40]  and CQual  [34]  are systems based on the C programming language that allow protocols to be statically enforced by a compiler.
Acknowledgements We thank  Jonathan Aldrich  and  Luís Caires  for helpful discussions. Gay was partially supported by the  UK EPSRC  ( EP/E065708/1  " Engineering Foundations of Web Services ",  EP/F037368/1  " Behavioural Types for Object-Oriented Languages ",  EP/K034413/1  " From Data Types to Session Types: A Basis for Concurrency and Distribution " and  EP/L00058X/1  " Exploiting Parallelism through Type Transformations for Hybrid Manycore Systems "). He thanks the  University of Glasgow  for the sabbatical leave during which part of this research was done. Gay and Ravara were partially supported by the Security and  Quantum Information Group at Instituto de Telecomunicações, Portugal. Vasconcelos was partially supported by the  Large-Scale Informatics Systems Laboratory, Portugal. Ravara was partially supported the  Portuguese Fundação para a Ciência e a Tecnologia FCT  ( SFRH/BSAB/757/2007 ), and by the  UK EPSRC  ( EP/F037368/1 ).
S I M U L AT I O N S We use the tree-based Eulerian AMR hydrodynamics code, RAM- SES  (Teyssier 2002) , to study the impact of SN feedback on the evolution of a Milky Way (MW)-type galaxy. The initial conditions for the simulations are identical to those used for the NUT suite presented in  Powell, Slyz & Devriendt (2011) and Geen, Slyz & Devriendt (2013) , which were generated using the MPGRAFIC software  (Prunet et al. 2008; Bertschinger 2001)  with Wilkinson Microwave Anisotropy Probe 5 cosmological parameters ( m = 0. 258, = 0. 742, b = 0. 045, σ 8 = 0. 8, H 0 = 72 km s - 1  Mpc -1 ;  Dunkley et al. 2009). The computational domain represents a periodic box of 9 h -1 Mpc on a side, covered with 128 3 cells. Within this volume, three nested grids are placed in a spherical region of radius 2 Mpc (comoving) encompassing a dark matter halo of M vir = 5.
g. Governato et al. 2007; Brook et al. 2011 ), but consistent with recent high-resolution simulations by  Roškar et al. (2014)  and  Hopkins et al. (2014). Using the same grid-based code as ours (RAMSES),  Roškar et al. (2014)  performed idealized simulations varying the optical depth to IR photons to investigate the impact of radiation pressure on galaxy properties. They find that the model with strong stellar feedback, which matches the empirical stellar-to-halo mass relation, leads to the formation of a spheroidal galaxy. Hopkins et al. (2014)  perform cosmological simulations to study the formation of disc galaxies with a sophisticated stellar feedback model, including radiation pressure and SN feedback. They show that the morphology of the MW progenitor at z = 3. 4 is irregular due to strong outflows (see their fig.
(2012b). In a subsequent paper,  Hopkins et al. (2014)  incorporate the final momentum from the SN blast wave in a dense medium, in a very similar spirit to our MFB scheme, and concluded that both SNe and radiation pressure are essential for reproducing the observed relations, such as M star -M halo relation or  Kennicutt-Schmidt law (Kennicutt 1998; Bigiel et al. 2008). By including SN, stellar winds, and momentum transfer from radiation in the RAMSES code  (Teyssier 2002) ,  Agertz et al. (2013)  systematically examined their relative importance in an isolated cloud of 10 6 M and a disc galaxy embedded in a halo of mass 10 12 M. Because of their finite resolution, they used the local size and mass relation of cluster/clumps to estimate the surface density, which is distinct from  Hopkins et al.
AC K N OW L E D G E M E N T S We are grateful to  Sam Geen ,  Chang-Goo Kim , and  Eve Ostriker  for fruitful discussions, and  Romain Teyssier  for making his code RAMSES publicly available. We also thank the anonymous referee for suggestions, which improved the clarity of the paper. Computing resources were provided by the  NASA   High-End Computing (HEC) Program  through the  NASA Advanced Supercomputing (NAS) Division at Ames Research Center , the  DiRAC  facility jointly funded by  STFC  and the  Large Facilities Capital Fund of BIS , and the  Horizon-UK  programme through DiRAC-2 facilities. The research is supported in part by  NSF  grant  AST-1108700  and  NASA  grant  NNX12AF91G  and in part by grant  Spin(e)   ANR-13-BS05-0005  of the french ANR. JD and AS's research is supported by funding from  Adrian Beecroft , the  Oxford Martin School  and the  STFC.
Background: Systems immunology approaches have proven invaluable in translational research settings. The current rate at which large-scale datasets are generated presents unique challenges and opportunities. Mining aggregates of these datasets could accelerate the pace of discovery, but new solutions are needed to integrate the heterogeneous data types with the contextual information that is necessary for interpretation. In addition, enabling tools and technologies facilitating investigators' interaction with large-scale datasets must be developed in order to promote insight and foster knowledge discovery. Methods: State of the art application programming was employed to develop an interactive web application for browsing and visualizing large and complex datasets. A collection of human immune transcriptome datasets were loaded alongside contextual information about the samples.
Results: We provide a resource enabling interactive query and navigation of transcriptome datasets relevant to human immunology research. Detailed information about studies and samples are displayed dynamically; if desired the associated data can be downloaded. Custom interactive visualizations of the data can be shared via email or social media. This application can be used to browse context-rich systems-scale data within and across systems immunology studies. This resource is publicly available online at [Gene Expression Browser Landing Page (https://gxb. benaroyaresearch. org/dm3/landing. gsp)]. The source code is also available openly [Gene Expression Browser Source Code (https:.
The data associated with each study, which tend to be underutilized beyond publication of primary results, potentially constitutes an invaluable resource when reinterpreted alongside other related datasets. It can provide context for the interpretation of newly generated data, and when analyzed collectively can yield insights that could not otherwise be obtained from the analysis of individual datasets. We have developed an interactive data browsing application to promote the integration and dissemination of immunologically relevant transcriptome data. Rich contextual information is provided to support data interpretation and foster novel immunological insights. The Gene Expression Browser (GXB) platform leverages social media such as Google+ to provide users with the ability to gather, prioritize, and share findings that arise while browsing large scale profiling data.
Such a framework was used previously to promote the dissemination of clinical and transcriptomic data generated in the course of a systems immunology study, thereby promoting exploration and discovery of novel knowledge by readers as well as increasing transparency of the data included in this publication  [13]. Here we make a compendium of curated public domain datasets accessible via a web portal as a resource for the community, at  [14]. In addition the source code for this software is released and made available for reuse by others at  [15].
Methods The web application supporting the sample set storage was written in Grails  [16] , a web application extension of the Groovy programming language  [17]. Jquery  [18]  and Asynchronous JavaScript and XML (AJAX) technologies were used to provide dynamic responses to user driven changes in the interface views. The web application runs in an Apache Tomcat application server  [19] , under the Ubuntu Linux operating system. MySQL  [20]  is used for the relational database back-end storage, and mongo  [21]  is used for NoSQL style data management where flexible schema are required. The web application supports the importation of GEO data from. soft and. family style files, as well as Illumina BeadStudio standard output format. Authenticated users may upload data and add annotations using standard spreadsheet tools via comma-separated value (.
csv) files. Microarray chip probe mapping definitions were downloaded from Affymetrix and Illumina user support websites, and imported into the web application. In all, twenty different microarray chip types are currently supported by the application. The R statistical computational language  [22]  was used in conjunction with the limma  [23]  package to calculate the rank order of genes based on their differential expression patterns ("rank lists"). Source code and instructions are available at  [15]. Necessary R scripts are available at  [24] , and starter databases referenced in the GitHub instructions are available at  [25].
Assembly of a collection of curated datasets We have assembled and curated a collection of 169 datasets that are relevant to human immunology, representing a total of 13,089 unique transcriptome profiles. These sets were selected from studies currently available in NCBI's Gene Expression Omnibus (GEO)  [26]. We queried GEO for all datasets related to any of the following search terms: "monocyte", "neutrophil", "CD4", "CD8", "B cell", "NK", "Natural Killer", "Plasma cell", "CD19", and "CD20". The query list was filtered to select microarray datasets generated from human samples, with a sample count greater than 10. The selection was further refined to include datasets generated using Affymetrix or Illumina chips, the two most commonly used commercial microarray platforms; a few datasets from other platforms were also incorporated.
In addition, relevance to human immunology research was assessed for each sampleset. Datasets were removed from the tool if they could not be appropriately displayed; most commonly, this happened when authors deposited normalized data into GEO but did not provide information on the type of normalization performed, which resulted in a very limited range of values detected in the dataset. Log2 normalization, which is applied to the majority of Affymetrix data, is automatically detected and addressed at loading. Separately, we queried GEO for whole-blood microarray datasets containing both disease case and control samples. The whole-blood data and cell-type specific data were all loaded into the web tool. Annotation data supplied with each dataset in GEO are stored in the tool. Annotations available from GEO sometimes provide substantial contextual information  [9, 13, 27] , but in most cases annotations are quite limited  [28].