dataesr/scientific-paragraphs-categorization huggingface dataset:
Fatigue simulation The aim of this step simulation is to get the asymptotic response of the axle. Based on this stabilized response a fatigue criterion will be used into the axle design. For the non-axisymmetric character of the fatigue phenomenon, an implicit quasi-three-dimensional model based on the precedent axisymmetric assembly simulation is developed (Fig. 12 ). A Python program is developed to ensure the results transfers in terms of stress and plastic strain tensor between the axisymmetric model to the quasi-3D CAXARN elements model. CAXA Elements type. The choice of such elements is based on their ability to accurately predict the response bending load. They are used to give a simulated three-dimensional response by revolving a two-dimensional surface around the centerline of symmetry.
Acknowledgements. This work is supported by the NERC National Capability in Modelling programme at the National Oceanography Centre and the Plymouth Marine Laboratory, and Theme 6 of the EC seventh framework program through the Marine Ecosystem Evolution in a Changing Environment (MEECE No. 212085) Collaborative Project. Wakelin is also supported by the NERC National Centre for Earth Observation. Schrum, Daewel and Pushpadas are also supported by the Senter for klimadynamikk projects RegScen and IPCC Task Force, and Daewel is also supported by the SEAMAN project. HADCM3 data was supplied by the Met Office Introduction Res. , 117, C05020, doi:10. 1029/2011JC007402, 2012. Watson, R. and Pauly, D. : Systematic distortions in world fisheries catch trends, Nature, 414, 534-536, 2001. Wohlers, J.
It is rational. Semiotic Web is more generic and living. It complements the Semantic Web (form and sense) with the referents (content) that are observed data (interpretations) geo-referenced in a 3D information world (Immersive Web) as Web Services by subjects pertaining to communities of practice (Social Web 2. 0). This makes our Sign management ecosystem a tetrahedron model (Figure  3 ) that is more involved in concrete life with end-users on a specific territory such as Reunion Island. The Web of Signs combines: 1. The Web of Data and Objects, i. e. the flow of raw and digital contents produced by specialists (teachers) and transmitted by engineers in databases and knowledge bases in the frame of an Information System (one-way flow), but progressively becoming interoperable through Web services with other Information Systems, 2.
e. know-how rather than knowledge in sign bases with multimedia annotations for helping them to define terms, model their domain, and allow end-users to interpret correctly the objects. As computer scientists and knowledge engineers, we want to design a new Iterative Sign Base System (ISBS) that will be the kernel of our Information Service for defining ontologies and terms, describing pieces work, classifying them with machine learning techniques, and identifying the name through a multimedia interactive questionnaire. The objective of such a tool is to become an instrument in users' hands for monitoring biodiversity in the fields with the National Park of Reunion Island, and music at home with the Regional Music Conservatory. For achieving this, we stressed on the importance of reducing the gap between interpretations of teachers (specialists) and learners (amateurs) to get the right identification name and then access to information in databases, or to get the correct gesture that gives the right sound for playing music.
Acknowledgments We would like to thank the  French National Government , the  Regional Council of Reunion Island  and the  European Union  for supporting this research in the frame of the PO-FEDER 2-06 ICT measure: http://www. reunioneurope. org/UE_PO-FEDER. asp. We are also grateful to the  FP7   Vibrant  project (www. vbrant. eu)contract no. RI-261532. Period, Dec. 2010 to Nov. 2013: they give us the opportunity to develop our vision of sign management for biodiversity monitoring. This paper was presented at the  ECAI/IFIP Artificial Intelligence for Knowledge Management Workshop  ( AI4KM ) of ECAI'2012 (http://www2. lirmm. fr/ecai2012/)on the 28 th of August 2012 in Montpellier, France.
To make the picture complete however, real-world controllers actually also feature state variables, leading to infinite (often uncountable) hybrid state ma-chines. Nevertheless, the state-and-transition view is still the preferred one in most situations: this observation motivated the introduction of a new user interface feature in AMESim, allowing users to define controllers by means of a finite set of states and transitions, yet offering state variables and equations as a means to specify not only actions to be performed during state transition but also constraints to be verified in a given state. Figure  1  shows a simple counter model expressed in the new state-and-transition view, which has been highly inspired by Harel's statechart language [1]. The corresponding user interface has been built on top of AMESim's Modelica translation chain to benefit from its automatic code generation feature.
A variant of the statechart language The graphical language implemented in AMESim is very similar to the original statechart language: a statechart is essentially a set of states represented with rectangular boxes (labelled count and reset in the example of Figure  1 ) and a set of possible state transitions represented with labelled arrows. A transition can be associated with a trigger, a guard and actions. A transition is taken when an event corresponding to its trigger occurs if its guard evaluates to true. In that case, the actions-which are state variable assignments-are executed. For instance, the transition from count to reset in Figure  1   means that when an event associated with e occurs while count is active and the state variable counter is equal 10, a transition from count to reset is taken, counter is set to 0 and reset_count is incremented.
7  But, given a common model description language like Modelica, any implementation is supposed to follow the same operational semantics which state how to compute the solutionnot an approximation-of any well-behaved program: this is somewhat the "reference implementation"although a "virtual" one 8 -of a correct interpreter of the modeling language. Unfortunately, in practice, defining sound operational semantics for a physical system modeling language is such a huge work that, for most languages available today (including Modelica), only informal semantics (i. e. , given in written human language) are available. Consequently, many inconsistencies simply cannot be spotted, because, contrary to formal descriptions, informal descriptions do not easily allow reasoning about the semantic model itself.
This clearly contradicts the assumptions stated above. In Modelica, for instance, something like the partial Modelica code in Listing 1 would need to be written, which is invalid as the second when clause introduces an algebraic loop involving s1 and because s1 and o are potentially constrained by two equations at once when e occurs. Listing 1: Invalid Modelica code for the statechart of  9  The values of certain states can actually be changed by a Modelica simulator as part of a solving process, but these intermediate values should never be relied upon in a model. This is valid Modelica, but the behavior is not exactly the expected one. Indeed, from an external point of view, o jumps from 0. 0 to 2. 0 directly without ever taking the 1. 0 value. This may seem harmless for one used to physical continuous-time modeling, but what if this output was fed to another discrete part, e.
Design choices When designing the statechart extension to AMESim, the main focus was placed on the robustness, reliability and usability of the solution. That is why special care was taken to avoid as much as possible the issues presented above. This necessarily lead to additional rules in our variant of the statechart language that will be justified in this section. First, it was decided to avoid the simultaneity issues described in Subsection 4. 1 altogether by making sure that the execution of a statechart is always independent of the interpretation given to simultaneous events. This means that if any two events occur at the same time, assuming that they are synchronous or asynchronous should not change the upcoming computation. In the language described in this paper, events triggering a statechart simultaneously are simply forbidden.
Conclusion and perspectives In this paper, a few challenging issues associated with modeling and simulating hybrid models in an asynchronous environment are discussed. A practical solution implemented in AMESim to avoid those issues and to offer a reliable and usable user interface is presented. This solution is built on top of the AMESim Modelica tool chain and demonstrates how a specific language can be implemented in terms of a more general language. The condition is, of course, that any model expressed in the specific language can somehow also be expressed without loss of meaning in the base language, which demands special care. However, the advantages of this approach are appealing as it is then possible to combine the convenience associated with a user friendly dedicated language with the power of a more general underlying language allowing to connect models expressed using different paradigms together.
Moreover, larger flowcells decrease the flow speed and pressure gradients that induce mechanical stresses for cells, while being closer in terms of volume to classic growth conditions (several ml). In cells and bacteria experiments, we use a 1. 5-mm-high silicon ring which corresponds to a flowcell volume of ≈220 µl. The flow rate within the fluidic device is controlled by a homemade LabVIEW program 2  that sends orders of "step frequency" to the syringe pusher (RS-232 protocol). This program enables to set constant flow rates between 0. 10 to 16. 6 µl/s using a 1 µl syringe. It can also "agitate" the flow by performing successive forward and backward movements. Depending on respective volumes, the average flow can be positive, null or negative. This method is used to improve the cell capture by increasing their probability of contact with the functionalized areas when they arrive into the flowcell.
| Thermal regulation and instrumentation The LabVIEW program that drives the thermal regulation is mainly composed of a PID controller  4. The PID aims to reduce the difference ∆T between the setpoint temperature T c and T IT O by adjusting the voltage V c from 0 to 5 V at the output of the LabJack. Because thermal variations are relatively slow (in the order of a few seconds) due to the thermal inertia, derivative and integral gains are not indispensable, and only the proportional gain can be used. But in the case of a purely proportional gain, when ∆T → 0 • C, V c should also tend to zero, resulting in a decrease of T IT O (t) and a permanent error that makes T IT O < T c. Thus, to be accurate, the PID needs an additional constant term so that V c = K p × ∆T + constant, where K p is the proportional gain.
| LabVIEW acquisition program To perform a classic SPR experiment, the only device that needs to be automatically controlled is the camera in order to capture images at a constant rate. However, it is also practical to control the angle of illumination to automatically acquire images at different angles, and trace the plasmon curve of the areas of interest in order to choose the working angle. Moreover, in line-scan imaging mode, the focus of the SPR imaging system has to be set for each image. These three operations have been implemented in a homemade LabVIEW program divided into 4 steps, as shown in the synoptic of Figure  3. 13. The first step consists in setting the camera exposure time, and eventually binning (concatenation of 2×2, 4×4 or 8×8 pixels), to use the full dynamic of the sensor.
R ′ T E (θ ext ) is calculated by a homemade Mathematica program and is used as a reference since it is supposed to be independent of small refractive index changes occurring in the dielectric at angle greater than the critical angle glass/dielectric. Once the working angle is calculated, it is entered in the program which moves the illumination motor to the corresponding position. The third step is equivalent to the first one. The camera setting is set to use the full dynamic range of the camera, but in TM mode. The area of interest is set to a mean gray-level value of 70% × 65, 535 ≈ 45, 800, so large intensity shifts can still be measured. At this step, if the experiment has to be performed in line-scan imaging mode, the position of the motor that controls the focus of the SPR imaging system, and thus the clear line position, has to be measured for both top and bottom focus of the image.
| Images and sequences processing To reconstruct a single final image from a sequence of intermediate images acquired in linecan imaging mode, first, all the intermediate images are realigned by ImageJ using the plugin Stackreg→Translation  [143]. Note that this step is optional, but very useful to correct small imperfections of the optical alignment and obtain a better recomposed final image. If the clear stripe is not perfectly horizontal, the entire sequence can be tilted consequently. The final image is finally recomposed by a homemade Mathematica program which imports and crops the intermediate images before reassembling all the clear stripes together. Once the sequence imported, the program asks for the position of the clear stripe (in pixel position) on the first and the last images.
All the cropped stripes are of equal width. An optional parameter allows to take into account the eventual non-linearity of the stripe position with respect to the image number. To process an entire experiment taken in line-can imaging mode, another Mathematica program automatically performs the reconstruction on each sequence of intermediate images, and stored all the final images in a new folder. ImageJ does not provide any automatic realignment process, and the one implemented in Mathematica is too slow to be used (more than a hour for a single sequence of intermediate images). As a consequence, in the final images, small movements between stripes remain. They are barely observable at first glance, but strongly degrade the differential images. These final images are useful to observe phenomena such as cell movements, or intensity shifts on relatively large areas, but cannot be used for individual cell monitoring.
Technical achievements in SPR microscopy At last but not least, this work has also led to a significant improvement on the design of prismbased SPR microscopes, as well as on their instrumentation and the required image processing when using the line-scan imaging mode. A program coded in Mathematica has been developed to calculate and optimize the most important properties of prism-based SPR microscopy, such as the optimized apex angles of the prisms, the anamorphose, the geometric aberrations, the propagation length and the optimal metal thicknesses and wavelengths for sensitivity or resolution. It is also able to fit experimental plasmon curves and point-spread-functions. A entirely new SPR microscope has been fabricated and automated in order to perform biological experiments over several hours.
Its coupling with a conventional optical microscope has been made possible by designing a thermally regulated transparent and thin fluidic device. Its thermal properties have been evaluated both experimentally and by finite-element simulations. Moreover, all the homemade mechanical components of the final set-up, as well as the structure necessary to integrate the prism SPR chip, have been designed by a CAD software, which allows fast and efficient future improvements. Furthermore, the optimal parameters that have guided our choice of camera sensor have been identified. Finally, the image processing steps by the use of both ImageJ and homemade Mathematica programs have been validated and give fast and efficient results. As the author of the manuscript, and main contributor to this work, I emphasize that a PhD thesis, despite its inherent individual aspect, is never a one man work, but rather a team project, especially for this one at the interface between physics and biology.
The features are not limited to traffic analysis -the security manager can host additional security functions such as a configuration checker capable of controlling the proper configuration of the mobile devices. Using our approach, most of the security intelligence will be moved at the security manager level, potentially minimizing users involvement. We have worked on the implementation of a first security function for our outsourcing architecture. The objective of this security function is to analyze in the cloud the configuration of mobile devices in order to identify their potential vulnerabilities. The assessments are performed using the Open Vulnerability and Assessment Language (OVAL)  [3] , which is an XML-based language widely used to standardize the way to represent vulnerable states and to perform associated assessments.
Model validations against data can be done at the individual level; matching the observational approach. Moreover, models based on individuals benefit from having the same basic unit as natural selection. This makes IBMs appealing for addressing behavioural and life history tradeoffs and therefore for studying higher trophic levels, which can have a great behavioural repertoire, in particular in relation to motility. Consequently individual based modelling is used extensively for modelling higher trophic levels in EURO-BASIN. There have been several applications of IBMs to zooplankton in the North Atlantic. Early studies focused on simulating drift trajectories of individual plankton and their growth, survival and reproduction  (Carlotti and Wolf, 1998; Miller et al. , 1998). Models have subsequently been fitted with adaptive traits in order to investigate the consequences for adaptation and population dynamics of different levels of environmental forcing  (Fiksen, 2000; Huse, 2005).
org/10. 1016/j. pocean. 2014. 04. 024 AMDO, with correlations at around the 90% significant level out to 9 years lead time  (Kim et al. , 2012) , but beyond this scenario forcing becomes increasingly important  (Branstator and Teng, 2012). For EURO-BASIN, we adopt two approaches. First, the conventional approach and conduct a series of simulations forced by a small number of free-running CMIP5 AOGCM simulations, accepting that the phase of variability will not be coincident with reality; the simulations will be long enough to average out some of this (e. g. the North Atlantic Oscillation). The second approach also uses the CMIP5 outputs, but aims to correct the biases by perturbing a reanalysis based hindcast forcing set (DFS5; an update on  Brodeau et al. , 2010). The DFS5 atmospheric data is decomposed into realistic weather regimes, and analogs of these are defined in the AOGCM simulations of the present-day period.
The evolution of these analogs is then statistically followed in future scenario IPCC simulations, and a forcing data for future simulations is constructed with these time evolutions, using the realistic weather regime previously defined  (Cassou et al. , 2011; Minvielle et al. , 2011). Hence, the realism of the spatial structure of the future forcing is maintained and the evolution of the future forcing is given by statistics from the IPCC runs. Moreover, there is continuity and consistency between the (realistic) hindcast and forecast forcing. Concluding remarks: integrating the EURO-BASIN models EURO-BASIN is focused on creating predictive understanding of key species and the emergent ecosystem and biogeochemical features of the North Atlantic basin in order to further the abilities to understand, predict and contribute to the development and implementations of the ecosystem approach to resource management.
Acknowledgements This review was funded by  EC 7th Framework Programme  through the  EURO-BASIN Integrated Project on Basin-Scale Analysis, Synthesis and INtegration  (Contract  264933 ). This work was also supported by the  UK Natural Environment Research Council National Capability Program in Ocean Modelling at NOC  and PML. Altimetry data used in this study were developed, validated, and distributed by the  CTOH/LEGOS, France.
SOFTWARE The LAD on-board software runs on a LEON-3 processor and its main functions are instrument control and monitoring and science data processing and formatting. Software is designed to allow the instrument to have the complex functionality that is necessary to allow itself to be updated and work around problems automatically and with input from the ground. Instrument control will be possible through the software via telecommands from the ground (e. g. , power on & off, set-up of ASICs and FPGAs, loading parameters for processing/on-board calibration, investigations) and autonomously on-board (e. g. , mode switching, FDIR and diagnostic data collection). The software implements the standard ECSS-style PUS service telecommand packets for housekeeping, memory maintenance, monitoring, etc.
, and some standard telemetry packets for command acceptance, housekeeping, event reporting, memory management, time management, science data etc. The software needs to be able to send set-up information to the hierarchy of processing elements and receive and process the housekeeping data coming back, simplifying these data in a configurable way for a lower rate transmission to the ground. The software will be written in C using RTEMS, the real-time executive, which will schedule the software tasks, each at different priorities, communicating with each other with messages and events. The software package will consist of two separate sub-systems. "Basic" software, stored in a very reliable PROM(s), would have enough functionality to perform basic health management and memory management: to receive, store and execute patches or new software.
"Operational" software, stored in EEPROM, would have the functionality of the "Basic" software and also the full science capabilities. In this way new software can be loaded to the instrument without overwriting or corrupting the original PROM code. If there is any problem with the software interface to the spacecraft, a reboot or power off/on of the instrument will reset the software into the well-tested "Basic" mode which does not produce science data, thereby initialising the instrument back to a well-defined mode. As the software has to operate in a remote space environment, it will be written to be robust against errors, to report as much information as possible on any problems encountered and progress made (to help investigations) and perform any operations required by EDAC/memory scrubbing.
Error messages will be carefully controlled so that the Spacecraft is not flooded with messages that may have a common cause. A software-controlled hardware watchdog will be implemented. The interfaces between the software and the rest of the instrument/satellite will be as clean as possible with the processor and software taking over the processing of the events and diagnostic data at the point where the data streams from the panels are joined. Interaction with the Spacecraft will be through SpaceWire (with the option of CAN). Time information will be received from the GPS and distributed via the PBEEs to the MBEEs. The MBEEs will be monitored in case re-synchronisation is needed. The DHU will collect data from housekeeping sensors in order to monitor configuration status and instrument health.