dataesr/scientific-paragraphs-categorization huggingface dataset:
Nan et al. [6]  simulate a drilling time of about 0. 03 s by means of Abaqus/Explicit. Abouridouane et al. performed several studies on the thrust force, the torque and the chip geometry for micro-drilling with Deform-3D  [7] [8]  [9]. They also studied a classical drilling configuration with a drill diameter of 8 mm  [10]  and the simulated time was about 80 ms, which corresponds to a small depth. A similar configuration was studied by Marusich et al. [11]  with the code Third Wave Advantedge, whereas Muhamad et al. used MSC Marc  [12]  and Deform-3D  [13]. To simulate the removal of the material, these numerical models are based on an explicit time integration leading to a very high computation time. Moreover, they use a Lagrangian description for the material movement description. Therefore, the computing time is increased because of the need for successive remeshing operations to avoid mesh distortions.
Application to the drilling of a 316L stainless steel The numerical methodology presented above is applied to a 316L drilling operation. The simulation has been performed using the computer code Sysweld ®  [19]. The drilling conditions are: • cutting velocity, 60 m/min, • feed, 0. 15 mm/rev, • drill diameter, 12 mm, • drilled length, 36 mm, • through-hole, • dry drilling, • workpiece diameter, 60 mm. In this application, the Taylor-Quinney coefficient α is taken equal to 0. 9, as proposed by Zaera et al. [20]. The thermal contact is assumed to be perfect between the drill tool and the workpiece. As far as the thermal boundary conditions are concerned (see Eq. (  7 )), θ ext and h ext are defined by considering: • convection on the surfaces located outside the hole, exchange coefficient: 40 W • m -2 • • C -1 , room temperature: 20 • C.
Acknowledgements. This study has been performed within the framework of the  Skyscanner  project supported by the  STAE foundation  and the  Micro-Aerial Vehicle Research Center. We particularly thank  Frédéric Murguet at Météo-France , and the  CNRM/GMEI/MNPCA  team for technical and organizational support. We also thank  Samuel Lauda  for preliminary studies on this project, and  Simon Lacroix  ( CNRS/LAAS ) for support on computer vision techniques. 15 Atmos. Meas. Tech. Discuss. , https://doi. org/10. 5194/amt-2017-203Manuscript under review for journal Atmos. Meas. Tech. Discussion started: 31 August 2017 c Author(s)  2017. CC BY 4. 0 License.
Membrane Characterization and Fouling Test To examine the morphology of the membrane, Field Emission-Scanning Electron Microscopy (FE-SEM) with a platinum coating on the sample surface and Transmission Electron Microscopy (TEM) can be employed. Using ImageJ software, it is possible to investigate the pore size and the pore distributions of the membranes by processing of the Image of FE-SEM  [12]. Hydrophilic property of membrane can be evaluated by WCA (goniometer) with automated dispensing system  [16] , In-air water, in-air oil, underwater oil  [44]  and under-oil WCAs  [150]  techniques can be used. The surface chemical composition of membrane can be analyzed by Fourier Transform Infrared Spectroscopy (FTIR)  [47] , Atomic Force Microscope (AFM) measure the surface morphology (roughness), the Young's modulus and the interaction force between the oil droplets and the surface of modified membranes  [18].
Data and methods Seafloor features and water column gas flares were identified using Kongsberg EM122 12-kHz multibeam echosounder data acquired in 2012-2013 (horizontal grid size 30 × 30 m), visualized using QPS Fledermaus software, including the Midwater module. Subsurface structures were examined using two sets of multichannel seismic data, acquired for hydrocarbon exploration (made available by the Brazilian National Petroleum Agency -ANP) and interpreted using IHS Kingdom Suite software: (i) ca. 20,000 km of 2D seismic profiles acquired during the 1980s and 1990s by different companies using different air-gun acquisition arrays, with Fig. 1  (a) Location map showing the upper Amazon fan study area (black polygon) and the multibeam echo sounder survey area in inset. Black hexagons show the location of (one or more) plumes; stars represent sites where gas hydrates were recovered in cores.
Acknowledgements We are grateful to SeaSeep for providing multibeam echosounder data acquired during campaigns of the R/V Teknik Perdana in 2012-2013, and cores acquired during campaigns of the R/V Inspector II in 2015. Seismic profiles were obtained from the  Brazilian National Petroleum Agency (ANP). We thank  IHS Global Inc. Educational/ Academic Grant Program  for the use of the Kingdom Software. Funding information J. M. K. , A. T. R. , and C. S. received research grant Nos. 309915/2015-5 , No. 313086/2017-6 , No. 308164/2015-6 , respectively, from the  Brazilian National Research Council (CNPq). J. M. K. , D. P. , A. T. R, and C. S. are supported by the  Brazilian Coordination for the Improvement of Higher Education Personnel (CAPES)  research grant No. 0558/2015. D. P. is supported under the  SEAGAS  project, which has received funding from the  European Union 's  Horizon 2020 research and innovation program  under  Marie Skłodowska-Curie  grant agreement No.
OCRA draws its origins from these design requirements. It stands for Optimization-based Control for Robotics Applications and consists of a set of platform-independent libraries which facilitates the development of optimization-based controllers. It builds on top of ORC which was originally a framework developed by CEA-List, 1  later used at the Institute of Intelligent Systems and Robotics (ISIR) to develop whole-body controllers with simulations on XDE  (Salini et al. , 2013). Examples of software addressing similar problems include the Stack of Tasks (SOT)  (Mansard et al. , 2009) , OpenSOT  (Rocchi et al. , 2015) , and CoDyCo 2  controllers  (Nori et al. , 2015). Nevertheless, they either lack the level of desired flexibility or do not meet the proposed design requirements. SOT and OpenSOT use strictly hiearchical methods, and while OpenSOT is intended for torque-controlled robots similar to OCRA, SOT originally targets velocity-controlled robots.
When it comes to solvers, OpenSOT relies solely on QPOases while SOT's controller and solver are tight together. Another software that has been used in the formulation of this type of controllers is  Roboptim (2016). It is, however, an optimization framework for robotics and it is up to the user to formulate the control problem, workout the prioritization strategy and address the different components to achieve a whole-body controller. CoDyCo's controllers on the other hand, although aimed at WBC, are tailored to be task-specific and do not constitute a WBC library. OCRA has been designed to exploit a client-server paradigm, where the server is responsible for running the whole-body controller, send control inputs to the robot and host user-defined tasks, while the client is built by the user according to their needs on task servoing, planning, or higher-level control.
OCRA contributes to the building of the iCub mindware through the implementation of an iCub server along with communication utilities for the construction of clients. It facilitates the creation of a vast type of whole-body behaviors, with special attention to interaction. It also addresses the needs of different types of users, from the advanced one who desires to implement particular low-level control laws, to the more practical one who prefers to state at the metatask-level. In Section 2, a generic overview of the main design requirements and features of OCRA, along with a list of software dependencies is presented. Section 3 introduces the main concepts involved in optimization-based control which allow the reader to have a deeper insight in the inner workings of the software. Concepts such as tasks, constraints, quadratic programming based control (and motivations for its use), prioritization strategies, and optimization solver are covered.
OCRA OCRA is a set of libraries and tools for the implementation of QP-based whole-body controllers for torque/force-controlled articulated robots. Robots like the humanoid iCub or the KUKA Light Weight Robot (LWR) manipulators (floating/fixed base) can be controlled using this open source software. In particular, for the iCub, the set of necessary libraries is implemented and distributed. One main design requirement from OCRA's inception is that (1) it should be heavily task-oriented. This means, that a user can specify a set of tasks to be performed by the robot, e. g. , follow a CoM trajectory, while maintaining balance and make one hand follow another trajectory and (2) the specifications of these tasks have to be easy to provide. This is achieved through an XML file that we call the tasks set.
OCRA Libraries The main concepts introduced in previous sections are materialized in the different interfaces, abstract, and concrete classes OCRA is composed of. These are encapsulated in four essential components or libraries. These are: ocra-optim, ocra-control, ocra-coms, and ocra-utils. The first of these libraries, ocra-optim, defines the lowestlevel data structures required to build an optimization problem such as variables, functions, and constraints, as well as the basic concept of a solver and prioritization strategies. Table  4  shows the main classes in this library, their type, and a brief description. The ocra-control library goes up one level of abstraction, containing all the classes necessary to build the model of a robot, implement a control law, account for the floating-base dynamics and build the different types of tasks, constraints and trajectories.
The two main prioritization techniques described in Section 3. 5 are, respectively, implemented through HOCRA and WOCRA. Again, the main classes in this library along with their brief description are collected in Table  5. The last two libraries are agnostic to the paradigm suggested by OCRA. That is, a client-server model. In order to implement it, the ocra-coms library is provided and comes with the generic classes to create a server and a client and to manage the communication between them. Table  6  lists the main classes in this library along with their description. Finally, the ocra-utils library as its name states, is a set of utilities to aid the other libraries: helpers to perform file operations, xml parsing, data structure conversions, errors descriptors, among others.
iCub Server Figure  2  depicts the sequence diagram for the ocra-icubserver. The user starts by executing the server from terminal issuing the command ocra-icub-server  [options]  (1). The default options are specified in its initialization file ocra-icub-server. ini or hardcoded in the source code. After the execution of the server, an object of type ResourceFinder is created, which is responsible for the parsing of the former options. Right after, a yarp RFModule is created (3) and started (4), whose first task will be to configure the server (6), ask the ResourceFinder to find the desired type of controller (7), i. e. , WOCRA or HOCRA, the solver to be used, i. e. , QUAD-PROG or QPOASES, the XML file with the description of the tasks that the client will manipulate, etc. At this point, a yarpWholeBodyInterface object is created (8) and initialized.
This class serves as an interface to the robot, and as such will allow us to set the control references obtained, as well as to obtain the state of the robot. the module is ready to create (12) and start (13) the main thread of the client. Before entering the main loop of the thread, however, a couple of objects of interest are created. First, an object of type IcubControllerServer (14), which during initialization (16) will create the desired controller with its internal solver. At this phase, also communication ports are opened with standardized names that will be used by the cient for future connections. IcubControllerServer is then asked by the thread to update its internal model of the robot (17) and add the tasks specified by the user via XML (18). This process involves the creation (19) of an object of type TaskConstructionManager which will create one or multiple instances (20) of TaskBuilder, one per type of task found in the XML.
CONCLUSION The development of intelligent and autonomous robots entails many challenges, one of which is robust and flexible controllers. The overall goal of any control software should be to abstract the control of redundant robots, such as the iCub, to higher and higher levels of logic in order to facilitate the generation of complex overall behaviors-behaviors, which should ultimately render the robot useful. Whole-body control was born from these requirements and lays forth the design criteria for OCRA presented in Section 1. Through its various abstract and concrete classes, and server-client structure, OCRA attempts to provide a solution which meets these needs but also balances ease of use with flexibility. The design of OCRA allows users to interact with and customize the control problem at virtually any level from the realtime computation of joint torques to high-level controller clients.
If the robot has been properly interfaced with the OCRA controller server, then clients can be developed with little effort and most of all, no deep understanding of the internals of the server side. Various examples of the different manners in which one can interact with OCRA are presented in the Supplemental Data Section and validate the variety of ways OCRA can be used to study and develop autonomy. Ultimately, OCRA should serve as the basis for increasingly complex logic, by robustly resolving progressively more complex layers of the control problem. The server-client architecture is just the beginning of this process and should be built upon by even high-levels of problem reasoning, to create greater and greater levels of robot autonomy.
DFT analysis Density functional theory (DFT) calculations were performed using the Gaussian 09 computational package  (Frisch et al. , 2009). The B3LYP functionals was used as implemented in Gaussian. Geometry and electronic structure optimizations were carried out for the functional/basis set combinations using the default optimization algorithm in Gaussian 09. Energy and frequency calculations were performed on fully optimized geometries using the 6-311++G(2d,p) basis set. B3LYP functionals showed their relevance for studying metals  (Lai et al. , 2012)  and it is widely used. Two different models have been applied to determine partial atomic charge: Mulliken  (Mulliken, 1955) , and Merz-Kollman (MK)  (Besler et al. , 1990).
New primers were designed to detect a larger spectrum of genetic diversity using NGS sequencing both for cmuA (Table  S2 ; Fig. S7 ) and mxaF / xoxF (Supplemental Information, Table  S2 , Fig  S8 ). For sequencing analysis following PCR amplification, briefly, a barcode oligonucleotide identifying sample origin was ligated to each PCR product. Equimolar pools of all libraries were assembled, and the resulting combined library was sequenced using Illumina MiSeq technology (LGC Genomics GmbH, Germany). Reads were assembled into contigs and analyzed using Mothur v. 1. 33. 2 with default parameters (http://www. mothur. org/wiki/ MiSeq_SOP)  [35]. 16S rRNA reads <420 or >460 bp were discarded. Reads were pre-clustered into groups of sequences with up to 2 nucleotide differences. Chimera sequences were removed with UCHIME  [36].
Remaining sequences were assigned by naïve Bayesian taxonomic classification using the SILVA reference database. Sequences that could not be assigned to Bacteria and Archaea were excluded from further analysis. OTUs were defined at 98% sequence similarity. Raw reads of cmuA and mxaF/xoxF amplicons with read lengths within 20 nucleotides of the expected amplicon length were clustered by USEARCH  [37]. Sequences occurring only once in all libraries were considered artefactual and removed, but singletons within individual amplicon libraries were kept. Reads were clustered iteratively at progressively lower cutoff values, and the cut-off value at which the number of retrieved OTUs stabilized was selected  [38]. These OTU sequences were compared against a gene-specific database generated from GenBank using BLAST (http://blast.
Since crosslabeling via 13 CO 2 cannot be fully ruled out in our experimental setup due to the long incubation period, further efforts will be required to confirm that this phylum indeed includes methylotrophs able to degrade CH 3 Cl. Low diversity of the cmuA biomarker and potential horizontal gene transfer of cmu genes to Beijerinckiaceae Amplicons of cmuA retrieved from 13 C-labeled DNA were most closely similar to the cmuA gene of Methylobacterium extorquens CM4 in both [ 13 C]-CH 3 Cl and [ 13 C]-CH 3 OH treatments, despite the fact that newly designed cmuA primers cover a broader diversity of known cmuA sequences than previous ones (Fig. S7 ). However, abundance of Methylobacteriaceae in 16S rRNA gene datasets was <1% (data not shown), and no OTU affiliated to this family was defined as 13 C-labeled with the applied criteria.
Acknowledgements PC was funded through a PhD grant from  Région Alsace (France)  and the  Deutsche Forschungsgemeinschaft (Germany). LB was supported by the  French Agence Nationale de la Recheche ANR  ( ANR-14-CE35-0005-01 ). MM was financed through the  Deutsche Forschungsgemeinschaft DFG  ( Ko2912/5-1  and.
Wood and MPCM Morphology The two woods species were characterized by optical microscopy (Leica, Wetzlar, Germany). Wood slices were cut using a microtome and colored with safranin. Vessels size was measured using the software Wincell. The diameter of the MPCM was also evaluated by optical microscopy. Microcapsules were dispersed in water and dropped between two glass lamellas. Mean diameter measurement was conducted over 288 microcapsules. After impregnation, microcapsules were observed within the wood by optical reflective microscopy, with an Axio Imager M. 2 (Zeiss, Oberkochen, Germany).
, the chemical composition, chemical rates of formation/destruction, temperature, density. ) is therefore stored in the tables as function of the mixture fraction f and the reaction progress variable (PV) only according to  [37, 38]. In this way, other flame thermochemical states (i. e. , fully burning state, transient solution between burned and unburned states and the unburned state) can be parameterized with the advantage that the reaction progress variable allows description of local extinction and reignition phenomena. The FPV tables are created after solving in physical space laminar counter-flow flames using the flamelet generator Flame Master code  [39]. In the present study, two definitions of the progress variable are used. In the case of the Sandia Flame-D: PV = Y H2O W H2O + Y CO W CO + Y CO 2 W CO 2 and for the Oxyfuel flame cases: PV = Y H2O W H2O.
Presumed PDF/FPV Subsequent to the implementation of the FPV chemical model within the PDF approach, the mean chemical source term and the mean density will be fed back (interpolated) to the CFD code. In practice, the numerical procedure consists of an iterative exchange of the turbulent flow and mixing field, the mean density and the chemical source term between the CFD code and the PDF sub-code. The mean values and variances of the controlling variables gained from the solution of their transport Equations (  16 )-(  18 ) are utilized as input parameters for the look-up table interpolation. This table interpolation provides, in turn, the quantities required in the transport equations of the controlling variables to be used in the next iteration step. The whole PDF integration is carried out as a pre-processing step.
Eulerian Stochastic Field/FPV New libraries were created in the open source code OpenFOAM,  [49]  in order to cope the Eulerian Monte Carlo stochastic field method with the FPV chemistry reduction technique. The solution procedure is obtained through various numerical steps. Heretofore, once the time loop starts, N number of stochastic Fields for the two controlling variables are created, which means 2*N new fields are created for both scalars: N fields for f : f n with n = {1,. , N} and N fields for PV: PV n with n = {1,. , N}. The random Wiener term is computed, at the same stage, separately for each individual stochastic field in all spatial directions: dW n j with j = {1,2,3} allowing the random procedure of these created fields for both chemical table controlling variables. In this stage, the momentum and continuity transport equations are calculated where all necessary parameters such as density, viscosity and the chemical source term for each stochastic field, are extracted from the chemical table in function of calculated f n and PV n.
Acknowledgments: The authors of this work gratefully acknowledge the financial support by the  European Union 's  Horizon 2020 research and innovation program  [CLEAN-Gas] with grant number  643134 , also the financial support by the  DFG (German Research Council) CRC/Transregio 150  "Turbulent, chemically reactive, multi-phase flows near walls" All the numerical simulations were carried out on the  Hessen High Performance Computer (HHLR) at the Technical University of Darmstadt.
Many ESSs with various power capacities can be installed into the system. The rated active and droop coefficient of the controllers are presented in Table  1. The proportional gains and the integral time constants of secondary controllers of all inverters are identical. The proposed layer structure is used to describe the test system as Figure  5. By separating the system into distinct layers, we can have a thorough overview of the system and see how data are transferred between devices, controllers and agents. For simplicity, Figure  5  only shows data flows of ESS 1 and its controller and agent. Data flows for other ESSs are identical. The controllers of inverters are decentralized as illustrated in Control layer because they only contact with local units. The system information can be obtained via agents.
Funding: This work was partly supported by: (1) the  European Community 's  Horizon 2020 Program  ( H2020/2014-2020 ) under the project " ERIGrid: European Research Infrastructure supporting Smart Grid Systems Technology Development, Validation , and  Roll Out " (Grant No. 654113 ); and (2) the  European Union Seventh Framework Programme  ( FP7)  under the project  ELECTRA IRP  (Grant No. 609687 ).
Simulation implementation and analysis In simulations, event selection was determined using a Gillespie stochastic simulation algorithm (SSA)  (39)  with a unique, randomly generated seed for each run. The order of events in each step of the model algorithm was as previously described  (25). Simulation initial conditions included two modules oriented in the +x direction and one module oriented in the -x direction (each module of length L cell ) and all clutches unbound. Individual runs represent data collected over 5-7 hours of simulated time. Simulations were run in Matlab (The MathWorks Inc. , Natick, MA) on in-house computing cores or using high performance computing cores in the Minnesota Supercomputing Institute. To quantify simulated cell migration, cell body position (x cell ) was sampled every 5 minutes of simulated time.
We excluded the first hour of simulated data from analysis and subsequent data were filtered to remove large displacements in cell position that result in velocities >1 µm s -1  (25). MSD was calculated from cell body position using the overlap method  (25, 40)  and fit to variants of the random walk model to extract parameters related to cell migration (described in the main text) using a custom Matlab analysis script. The first half of MSD versus time lag data was used for each individual cell fit.