dataesr/scientific-paragraphs-categorization huggingface dataset:
Hence, how a method such as the soundwalk can be experienced and enriched through a virtual three-dimensional model? The current three-dimensional modeling software are not suitable for creating simulation enriched by auditory components or to provide interactive solutions, therefore, new kinds of tools are needed to manage this sensory complexity and the data that we want to incorporate and communicate. Two different products were tested for this purpose, Google Earth 14 and Unity ®15. Google Earth is a well-known software, provided by Google, that allows the users to interactively visualize satellite images of the globe surface with a high level of details and with a user friendly and intuitive interface. During the last years this product has been enriched with various data such as textured three-dimensional models of several cities, included the vegetation, digital models of the terrain, various information layers such as historical maps, multimedia objects etc.
Moreover, Google Earth is not just a passive tool: it allows the users to draw points, lines and areas on the maps, to insert three-dimensional models realized with various modeling software in order to enrich the base model provided (even if the complexity of the models imported, in terms of number of geometries, should be carefully evaluated in order to ensure an adequate fruition of the simulation); it allows to embed data obtained from GPS tracking or dataset employed in Geographic Information System; it is possible to include animated data, interactive interfaces and multimedia elements. Finally, the software has another useful tool that permits to create virtual tours along a predetermined path  (Kim, Oh, Lee et al. , 2011). The other software considered in the research is the game engine Unity ®.
The soundwalks were recorded using a Roland R-05 digital audio recorder with the inbuilt stereo microphones and saved as a Wave 24bit file format at 48. 0 kHz. The path followed, in terms of starting point, end point, direction and walking speed, was the same for all the recordings. These elements were collected and employed as input data to develop the soundwalk in the virtual environment. The digital recorder was facing the path, parallel to the ground, at 1. 5 meters height. Through this method it was possible to collect also the sound events not directly visible and located in the surroundings of the chosen street (within the limits of the equipment used). Besides the soundwalks in the same days were individually recorded also other sound sources in order to provide a collection of audio samples to be used in the virtual environment.
In the first simulation a virtual tour, based on data collected during the survey (length, position and direction of the path), has been generated using the inbuilt tool of Google Earth. The height of the camera and the point of view were also defined. Then, the soundwalk recordings have been added. This is a task that cannot be implemented directly within the software environment. The tour created has to be exported in Keyhole Markup Language (KML) file format then, using a text editor, it is possible to modify the tour by adding the information needed for playing the sounds. Once the KML file has been modified, and the audio file connected, it is possible to display the simulation in Google Earth (Video 1). This media file cannot be displayed. Please refer to the online document http:// journals.
Wired Approach Our first approach was based on a previous study  (Hernandez et al. , 2014)  which presented an instrumented glove used for the capture of hand gestures for a surgical application. We propose another application in sports by firstly developing a wired system monitoring the hand positions of a swimmer. We used an inertial measurement unit (IMU MPU9150, InvenSense), which uses Inter-Integrated Circuit (I2C) communication standard. The MPU9150 includes a 3-axis gyroscope with a full-scale range of ±250, ±500, ±1000, and ±2000 °/sec, a 3-axis accelerometer with a full-scale range of ±2, ±4, ±8, and ±16 g, and a 3-axis magnetometer with a full scale range of ±1200 µT. The gyroscope and the accelerometer are in 16-bit resolution, and the magnetometer is in 13-bit resolution. This IMU was connected via wires to a microcontroller on a Tiva C Series EK-TM4C123GXL launchpad (Figure  1 ) which sent the data at 50Hz.
Distributed Approach Our second approach was to propose a distributed processing (called AREM Gateway, or Gateway) (Figure  2 ), where a sensor is connected to a microcontroller (with embedded computing algorithms) and equipped with a battery and a wireless communication module. We made our study with only one sensor, but our aim was to use additional sensors. Thanks to this wireless architecture, the Gateway would give two feedback possibilities: -a feedback at the end of a series of laps, with a data post-processing, -a direct feedback, as the data can be processed in real-time by an algorithm embedded into the microcontroller. We used another IMU, a ST iNemo-M1, which includes a 6-axis IMU (consisting on a 3-axis accelerometer and a 3-axis magnetometer), a 3-axis gyroscope and an ARM STM32 microcontroller.
The wireless transmission of the processed data is done using an ESP8266 WiFi module working in a station mode and connecting to a standard WiFi Access-Point. We also added a USB connector for the microcontroller, in order to communicate with a computer and to charge the battery, and a Serial-ATA connector connected to a Serial Peripheral Interface (SPI) bus to enable extension capabilities (with a SD card for example). Finally, the Gateway is 31 mm wide, 44 mm long, 13 mm high (with the battery and connectors), and weights 15 g with a 300 mAh battery, which has been tested and supply power for 2h30 in normal operation mode.
Laboratory Tests During the development of our systems, our first aim was to validate the hand swimming kinematics thanks to the IMU. In view of this, we compared pitch, roll and yaw angles provided both by the IMU of the wired system and the Gateway and a Vicon system (using Nexus 1. 7. 1 software), a marker-based motion capture system acknowledged as a reference. This motion capture system carries 12 MX3+ cameras with a frequency of 200 Hz, a millimeter accuracy and a resolution of 659 × 494 pixels each. We set up two trials in order to compare the IMU with the Vicon system. Each trial was filmed and recorded with both systems (wired and distributed). For the first, the IMU was surrounded with three reflective passive markers (Figure  3 ) and controlled by software (sample code from Texas Instruments, and TeraTerm for the TIVA and a Python script for the Gateway as computer softwares).
We put it on a table at the center of a room equipped with the Vicon system, and we collected data with the IMU and the Vicon system simultaneously during a rotation about a spatial axis. We made these rotations successively around the three axes in order to obtain the roll, pitch and yaw movements. For the second trial, we put the IMU on the hand of a swimmer (Figure  4 ) and we asked him to simulate a crawl movement while collecting data with both the IMU and the Vicon system. To compare the data collected with the IMU and the Vicon system, we first had to convert the coordinates provided by the Vicon cameras into angles. To do so, we used an algorithm with a simple angular projection leading to a coherent result for simple rotations around X, Y or Z axis. Finally, we were able to compare the data collected by both systems (Figure  5 ).
Preliminary Field Tests After the lab tests, we wanted to carry out field validation tests. Ensuring waterproofness appeared more difficult with the wired version, because we hadn't any glove prototype available yet. Consequently, we decided to do the trials in pool only with the Gateway. Firstly, we tested the WiFi communication provided by the ESP8266 WiFi module (2,4 GHz) in a swimming pool in order to establish if the communication was possible in such an environment (water surrounding, metallic structure), and if it was possible under water. To do so, we attached the Gateway to the hand of a swimmer and we asked her to put gradually her hand in the water until the loss of the communication (Figure  6 ). The orientation of the IMU is presented in Figure  7. We noted that the depth limit was about one centimeter (under this depth, the WiFi signal was lost), but that the communication was very good on the surface of the water despite the environment quite unfavorable to the correct travel of electromagnetic waves.
Secondly, we decided to test the range of the WiFi signal next to and in the swimming pool. We noticed that the distance between the Gateway and the surface of the water didn't change the range of the signal, and we determined it at about sixty meters. Thirdly, we tested data recording with the Gateway during a fifty meters swim by two swimmers. Because of the impossibility to communicate underwater, we chose to record the data when the WiFi signal was lost and to send them at the end of each lap (at the communication restoration). We managed to retrieve the data corresponding to five crawl movements of each swimmer.
Swimming Evaluation In order to get preliminary data related to the movement of a swimmer, we will work in collaboration with recreational and elite athletes. We supposed that elite swimmers would have a hand trajectory which permit them to be more effective, that's why it could be interesting to compare hand kinematics of both groups in order to assess differences between elite and recreational swimmers. Athletes will be asked to do a self-determined warm-up before being equipped with the Gateway on the left hand. Then they will have to perform crawl during fifty meters, without a diving start, in a fifty meters swimming pool. In order to standardize the measurements, the swimmers will be asked to put their hand at the surface of the water, in the direction of the pool, before beginning to swim.
CONCLUSIONS The preliminary interpretation seems to show that the Euler's angles variation would be a first interesting parameter to quantify the swimming technique. Indeed, the correlation between the curves and the movements would enable to provide to the swimmer certain necessary adjustments without a video recording or the observation of his coach. But the understanding of the curves obtained implies a correction of the data collected, because the curves seem to contain some aberrant points. A more common analysis, according to literature, shows a difference in patterns between elite and recreational swimmers. More than recognizing the swimming style, the next step will be to extract a quality stroke index by style and perform fatigue analysis on swimmers. This study represents a step forward in the development of a wearable motion capture system to monitor swimming performances.
ACKNOWLEDGEMENTS This research project is partially supported by  TE Connectivity and Compressport International. The authors would like to thank  Mrs. Marie Percebois ,  Mr. Manuel Roux ,  Mr. Louis Cupillard , and others coaches and athletes from  Besançon Triathlon  and  Toulouse Université Club  ( TUC Triathlon ), for their assistance in swimming tests. The authors would also like to gratefully acknowledge  Mrs. Kris Martinez ,  Mr. Xavi Carabi  and  Mr. Sylvain Laur , from  Compressport Int , for their help in glove design and first prototypes of wearable devices.
IMPLEMENTATION IN MATLAB The model presented in section 2 was implemented in MATLAB. The program, called (HTS_Analysis), uses a step-by-step analysis. At each step, we impose the curvature increment Δk. The values of the neutral axis (z n ), axial stress (σ) and axial stain (ε) are determined by the resolution of the nonlinear system of equations (  4 )-(  6 ) and (  9 ) to (12). The shear stress (τ) is computed from equation (  7 ), while the corresponding bending moment is determined from equation (  14 ). The program provides for the different values of the curvature (k) the corresponding values of the neutral axis (z n ), the axial stress (σ), the axial stain (ε), the shear stress (τ) and the bending moment (M).
VALIDATION 3. 2. 1. Presentation of the validation example The program (HTS_Analysis) was checked by its confrontation to finite element analyses conducted by COMSOL Multiphysics software. Figure  3  shows the cantilever beam used in the analysis. Its length is equal to 300 μm, while its width is equal to 20 μm. The beam is composed of 4 layers. The beam is submitted to an increasing uniform pressure at the upper surface (q). Figure  4  shows the distribution of the normal stress in the section x = 35 μm for two levels of the pressure q = 300 and 500 N/m. At q = 300 N/m, we observe a linear variation of the normal stress in each layer. The stress remains in the elastic area. The results of the two  programs agree well. At q = 500 N/m, the two programs show a linear variation of the normal stress in the second and third layers and plasticity in the 1 st and 4 th layers.
D. Simulation We set up a multiparticle simulation model in MATLAB  [15]  in order to numerically verify the equations and test the procedure. The simulation model consisted of a simple particle tracking code that transported particles from a defined 4D distribution through a thin octupole followed by a drift. We simulated for similar parameters to those in the CLIC Test Facility 3 setup: integrated octupole strength of 15 kTm=m 3 , beam energy of 190 MeV, distance from octupole to screen 5. 5 m. We simulated for a distribution of 10 5 number of particles generated from given beam matrices. In Appendix B we present a parametrization, inspired by  [7]  and  [16] , of the beam matrix that we will use throughout the paper. This parametrization uses the regular Twiss parameters for the horizontal and vertical 2 × 2 blocks and parameters r; κ; ψ; ϕ to describe the correlation terms.
IV. CONCLUSIONS Performing transverse position scans, parallel to the beam axis, inside an electric or magnetic octupole field results in both position shifts and position-dependent focusing providing information similar to that of a quadrupole scan, i. e. , the transverse beam matrix. We were able to test this method utilizing the octupole component of the rf fields in a CLIC accelerating structure and we could determine the integrated octupole strength and reconstruct the beam matrix including all correlations. The benefit of this method is that all the information comes from one scan. Although the data processing and fitting procedure is not trivial, the necessary data can be retrieved quickly. The data for our scan was acquired in about 8 minutes and the image processing could be done online and then about 5 minutes for the rest of the analysis.
Terms and Particular Statements Defining the functions ξ, ¬ξ and ζ ⇒ ξ has required to appeal to the natural language endowed with some appropriate symbols used for brevity. This having been done, we are now ready to fix the language of FGGPL R. We shall do it by steps. To begin, let L AT [FGGPL R ] be the language {Γ, ∆, Θ, Λ, Ξ, Π, Σ,. , --}, in which 'Γ', '∆', 'Θ', 'Λ', 'Ξ', 'Π', 'Σ',. have arity 0 and are called 'FGGPL R object-letters', while ' --' has arity 1, and behaves in agreement with the definition of the function ξ. Here the ellipses are intended to remain for the same letters 'Γ', '∆', 'Θ', 'Λ', 'Ξ', 'Π', 'Σ' endowed with appropriate indexes, so as to form a potentially infinite collection of symbols, all having arity 0. This simple language is used to form FGGPL R atomic terms, according to the following stipulations: St AT [FGGPL R ].
e. that, whatever these objects might be, it is not the case that the former is T and the latter is not T-which certainly does not happen. Insofar as this stipulation is the only one we make about the meaning to be ascribed to lower-case Roman letters within FGGPL R , it follows that these letters are only licensed to enter FGGPL R statements, namely general such statements, but not FGGPL R terms, or any other sort of well-formed strings of symbols that one might form within FGGPL R. This makes any FGGPL R term a particular term: a term referring to a particular object, though unspecified, which agrees with Frege's views expounded in 2. 5 while speaking of free variables (cf. , in particular, the passage quoted in footnote 24). These views are in line with Frege's admission of no propositional particular statement within FGGBS, that is, with the idea that propositional particular statements have their place only within the expository language of this system, whereas the system itself only includes general such statements.
Formal Treatment All this being said in the guise of preliminary explanations, let us consider the matter formally. Let L GS [FGGPL R ] be the language a, b, c, d,. , --, ¬ --, --⇒ --, obtained from L PS [FGGPL R ] by replacing its object-letters with the Ro-man letters 'a', 'b', 'c', 'd',. , called 'FGGPL R general letters for objects', also with arity 0. Here the ellipses are intended to stay for the same letters 'a', 'b', 'c ', 'd' endowed with appropriate indexes, so as to form a potentially infinite collection of symbols, all having arity 0. This language is used to form FGGPL R general statements (which explains our using the acronym 'GS' in 'L GS [FGGPL R ] '), according to the following stipulations: St GS [FGGPL R ]. i If θ is a FGGPL R particular statement and |θ| results from it by replacing each distinct FGGPL R object-letter in it with a distinct FGGPL R general letter for objects (so that any occurrence of the same FGGPL R object-letter is replaced by an occurrence of the same FGGPL R general letter for objects), then the latter is a FGGPL R general statement.
Still, if, despite all of that, we would like to integrate, the identity function within FGGPL R , we could certainly do it, by adding to the languages L T This would allow to render Basic Law IV with a FGGPL R general statement, to be added to Ax [FGGPL R ]. I as a new axiom of FGGPL R : [FGGPL] , L PS [FGGPL R ] , Ax [FGGPL R ]. IV ' ¬a = ¬b ⇒ a = b'. It is clear both that this statement holds, and that it cannot be deduced in FGGPL R from Ax [FGGPL R ]. I, since none of the rules Rl GS [FGGPL R ]. iviii allow one to introduce the symbol '='. It is also clear that, once this axiom is admitted, these last rules allow to deduce other statements from it, either alone or together with Ax [FGGPL R ]. I, all including this symbol, and, then, all non-deductible from this last axiom alone. In a sense, adding Ax [FGGPL R ].
Frege's Second-Order System Reconstructed 4. 1 From FGGPL R to FGGL2 R Though our presentation of FGGPL R as an autonomous system collides with Frege's avoiding a clear separation of the propositional fragment of FGGBS from the other parts of this system, we partially reflect Frege's attitude on this matter by rooting FGGL2 R in FGGPL R. This is made particularly clear by our incorporating FGGPL R basic functions into FGGL2 R , by also considering the function ξ = ζ with its two facets, respectively appearing when its arguments are truth-values or objects in general. This is not the same, however, as merely coming to FGGL2 R by extending FGGPL R. The reason is that the generation of terms in the former system proceeds in a quite different way than in the latter. As a matter of fact, Frege did not rigourously expose the way in which terms are generated in FGGBS, but rather used natural language to suggest the way in which they can be obtained from each other.
It is then natural to shape FGGL2 R so as to avoid having recourse both to FGGPL R object-letters and to analogous function-letters-that is, letters to be used to form indeterminate function-names-, in order to generate terms 46 , and, then, using the upper-case Greek letters 'Γ', '∆', 'Θ', 'Λ', 'Ξ', 'Π', 'Σ', together with other such letters, like 'Φ', 'Ψ', 'Ω' and 'Υ'-used, indeed, to form indeterminate function-names-only informally, and in the definition of the basic functions to be added to those involved in FGGPL R. This requires, however, to emphasize a feature of Frege's formal language that is somehow kept out of sight in the way terms are generated in FGGPL R. We refer to the impossibility, in this language, of getting a term by direct composition of two other terms: to get a term by composing two other terms, one is to pass through a desaturation of one of the latter, and, then, through a function-name.
Terms and Particular Statements All this being said, it is now time to leave any preliminary apart and proceed to fix the system FGGL2 R , by beginning with fixing its terms. The best way to do it is not by stating the clauses according to which the elements of a certain formal language, intended as a collection of atomic symbols having a certain arity, can be composed with each others so as to get such a term, as we have done for FGGPL R terms. It is much more appropriate to identify these terms with the elements of a stratified family T of strings of symbols generated step by step according to a codified procedure involving six other stratified families F  [i,j]  (i = 1, 2; j = 1, 2, 3) of strings of symbols, also generated step by step according to this same procedure, which are intended to include, in turn, names of functions respectively belonging to F  [i,j].
Moreover, using SysML improves the communication since it eases the interaction between different teams of multidomain engineers. But SysML is not executable: there is neither an action language nor a simulation framework to evaluate SysML models containing equations. To overcome this issue, we propose a tooled approach to automatically generate Modelica 1  simulation code from SysML models. The contributions of this paper are threefold. First, it relies on the SysML-Modelica Transformation specification  [3] , provided by the Object Management Group (OMG), to integrate Modelica concepts in SysML models. Second, we propose a Model-Driven Engineering (MDE) approach to automatically translate such high-level SysML models into executable Modelica code. The obtained simulation results are then compared with the initial system requirements to assess them.
Thirdly, to evaluate this whole process, experiments have been conducted within the Smart Blocks project in the mechatronic domain. The paper is structured as follows. Section 2 introduces the integration of Modelica constructs into SysML models and describes the process of Modelica code generation from such models. Section 3 discusses the relevance of the tooled approach. Finally, after surveying related work in Sect. 4, we conclude and outline the future work in Sect. 5.
From SysML Models to Modelica Code SysML and Modelica are two complementary languages: their joint use enables the integration of Modelica simulation constructs to complete architectural SysML models. This integration, based on existing recommendations provided by the OMG, has been implemented as the SysML4Modelica profile, which defines the practical contribution of the present paper. Then, we describe the process of Modelica code generation from SysML models using model-driven engineering techniques. The implementation of this whole process is available to the community 2  (demos, examples and source code).
The Gap between SysML and Modelica To support MBSE principles, OMG has developed and promotes the System Modeling Language (SysML) that enables systems engineers to specify all aspects of a complex system using graphical constructs. SysML is built on the well-known Unified Modeling Language (UML) by bringing adapted semantics to the system engineering field: SysML is implemented as a UML profile. Using SysML enables the adoption of a Model-Based approach to represent, specify and manage knowledge at the early stage of the design. However, SysML is a semi-formal language and it lacks of structures for requirements and model validation. To tackle this issue, the Modelica language is a convincing candidate: it is a non-proprietary, object-oriented and equation-based language for complex physical systems simulation.