dataesr/scientific-paragraphs-categorization huggingface dataset:
Connections are not managed by the user but by a central authority, called ROS Master, which also checks if publishers and receivers comply on the same data format. Indeed, ROS communication is strongly typed and it employs a set of standard formats defined in message (. msg) files. The possibility to communicate natively with ROS has been recently integrated into YARP. Special classes such as yarp::os::Node, yarp::os::Publisher, and yarp::os::Subscriber have been introduced to allow a user to handle ROS topics. Additionally, a specialized converter, namely yarpidl_rosmsg, was developed to automatically generate C++ header files from ROS. msg files and to allow the usage of ROS data types inside YARP. An example of a YARP module directly publishing data onto a ROS topic, without linking any external ROS library, is shown in Section I in Supplementary Material.
TransformServer and TransformClient Tf is a ROS package which allows a distributed system to keep track of multiple coordinate frames over time. For example, a module may be able to compute and publish the transformation from reference frame /a to reference frame /b while a different module may be able to publish the transformation from frame /b to frame /c. By subscribing to the /tf topic, a third module can retrieve the broadcasted transforms and compute the resulting transformation from /a to /c. This mechanism is pervasive in all ROS. Remarkable application examples are move-it (a motion planning framework for mobile manipulation), Rviz (a 3D visualization tool), and the ROS navigation stack. In this latter case, tf is typically used to keep track of the estimated robot position with respect to an odometry reference frame or to a map origin.
Thus, it is clear that it is not possible to obtain a complete YARP-ROS integration without implementing a mechanism that is able to handle ROS frame transforms in YARP. To overcome this limitation, we developed a YARP device called transformServer. TransformServer collects and stores frame transforms by subscribing to /tf and /tf_static topics and makes these information available to a YARP transformClient instance inside a user module (Figure  1 ). TransformClient is an entity which implements the yarp::dev::IFrameTransform interface (see Sections II and III in Supplementary Material). Available methods allow the user to query the server about the registered YARP and ROS transforms, to perform kinematic computations, and to register on the server new transforms computed by YARP modules.
INavigation2d yarp::dev::INavigation2D is a pure virtual interface shared between all client/server modules, which performs navigation tasks. The most classical usage in a user application requires the instantiation of a yarp::dev::INaviga tion2DClient to send navigation commands to the robot (e. g. , "go to the entrance room"). On the other side, the server counterpart, which can be any module implementing the same yarp::dev::INavigation2D interface (e. g. , robot-PathPlanner, see Section 4. 6), receives the goal command and computes the path required by the robot to reach the goal. INavigation2D contains methods to start, pause, and resume navigation tasks, both in absolute (with respect to the map reference frame) or in relative coordinates (with respect to the robot reference frame) (Section VII Supplementary Material).
Map2dServer Map2DServer implements the methods of the YARP interface yarp::dev::IMap2D, and it allows a client application (such as the navigation module) to store and retrieve maps (yarp::dev::MapGrid2D) from memory. It can be initialized at startup by a map collection file which contains an index of all map files to be used in the session. It must be noticed that this module only behaves as a storage, and it contains neither information about the current robot position nor the name of the map in which the robot finds itself. These tasks are performed by other modules (e. g. , localizationServer, Section 4. 4) which interact with the map2Dserver when they need to obtain map data. Finally, this module implements some methods of the yarp::dev::INavigation2D interface, allowing to store/retrieve user notable locations (yarp::dev::Map2DLocation) on a map.
BaseControl BaseControl is the core YARP module used to control a mobile robot. It receives cartesian velocity commands (  x,  y,  θ) either from a navigation module or from a joystick device, and it computes the corresponding actuators actions required to achieve them. BaseControl is also responsible for computing robot odometry, i. e. , estimating the robot position in the world using measured motions of robot actuators. Computed data are published on a YARP port both as a vector (x,y,θ) and, via transformClient, as a transform between the origin of the odometry system (/odom) and the robot (/mobile_base). This allows a ROS module to interface with the robot by subscribing to the /tf topic.
Mapper2d Mapper2D is a simple YARP module which registers laser scans to build an occupancy-based map. The module is not equipped with a loop closure detector, nor with an internal localization algorithm; thus, it is not suitable to perform stand-alone SLAM tasks. Instead, it is designed to receive accurate localization data from an external source (e. g. , a Google Tango device) either via YARP port or via transformClient.
Robotgoto This module computes the cartesian velocities (  x,  y,  θ) of the mobile base required to reach the commanded goal, given the current robot position (provided through a transformClient) and a set of parameters that controls the trajectory generation (e. g. , differential drive or holonomic robot kinematics, heading and goal tolerance, etc. ). RobotGoto does not use any map information, except for the local occupancy grid which is continuously updated according to sensor data. An artificial potential field algorithm is employed to allow the robot to avoid obstacles obstructing the path to the goal. Depending on the configuration parameters, if a deadlock is detected, navigation may be paused (waiting a human to remove the obstacle) or aborted. In this latter case, the high-level path planner is notified by a specific yarp::dev::INavigation 2D::NavigationStatusEnum, as shown in Section VIII and Figure  S1  in Supplementary Material.
RobotPathPlanner This module is responsible for generating the navigation waypoints to be pursued by a local navigation module (e. g. , robotGoto). By implementing the INavigation2D interface, robotPath-Planner acts as the server counterpart of a Navigation2DClient instantiated by a user module. For example, when the user calls the INavigation2D::gotoAbsolutePosition() method to command the robot to reach a new goal, robotPath-Planner becomes in charge of performing the navigation task, notifying the user about its current status (e. g. , in progress, goal reached, etc. ). The algorithm acts as follows. RobotPathPlanner retrieves from a Map2DServer instance the current map of the area. A valid path from the current robot location to the goal is computed using A* algorithm. If the path does not exists, navigation is aborted.
Otherwise the path, initially defined as a vector of map cells, is transformed into a sequence of navigation waypoints. To be accepted, these waypoints must satisfy some user-defined parameters (e. g. , minimum distance between the cells etc. ). Waypoints are then put in a queue and sent one by one to a local navigation algorithms (such as robotGoto) which will pursue them. RobotPathPlanner is also responsible for processing the YARP flags assigned to particular areas of the map. These flags may belong to two different categories. Those which alter the navigation trajectory (such as keep-out areas) are directly processed by the module during the trajectory generation phase. Instead, flags which alter the robot behavior (e. g. , areas in which the robot must proceed at a different speed or interrupt the navigation if an obstacle is detected on the path) are not directly processed.
NAVIgATIoN INTegRATIoN ANd eXAMPLeS YARP and ROS may inter-operate in several ways to attain a navigation task. Different possibilities range from using a full YARP-based framework to using the complete ROS navigation stack. In between there exist a number of possible combinations: as shown in previous sections, most of the YARP components can be replaced by a ROS equivalent or vice versa, depending on the user needs and preferences. Figure  2  shows two illustrative scenarios. The first example refers to a simulated wheeled robot in Gazebo, a generic, multirobot, physics simulator. The navigation task is carried out by robotGoto/robotPathPlanner modules. Since ROS map_server is used, robotPathPlanner employs only the occupancy grid information and no YARP map flags are available. The second example refers to a real wheeled robot (i.
e. R1  (Parmiggiani et al. , 2017) ) controlled by yarpRobotInterface, the core YARP application which manages the low-level hardware control. In this case, navigation task is carried out by ROS navigation stack encapsulated inside move_base node. It must be noticed that, in both scenarios, the final end-user is a YARP application which instantiate a yarp::dev::INa vigation2DClient. Section IX in Supplementary Material shows a simple application which controls the robot to reach a location stored into the map server, unaware of which framework and control modules are employed underneath. The included sequence diagram (Figure  S2  in Section X in Supplementary Material) shows the timing and the messages exchanged between the clients opened by the example and the connected external modules (i.
Antichains and Interpolants for Emptiness The emptiness problem for ADA is undecidable, even in very simple cases. For instance, if Data I is the set of positive integers, an ADA can simulate an Alternating Vector Addition System with States (AVASS) using only atoms x ≥ k and x = x+k, for k ∈ Z, with the classical interpretation of the function symbols on integers. Since reachability of a control state is undecidable for AVASS  [15] , ADA emptiness is undecidable. Consequently, we give up on the guarantee for termination and build semialgorithms that meet the requirements below: (i) given an automaton A, if L(A) = ∅, the procedure will terminate and return a word w ∈ L(A), and (ii) if the procedure terminates without returning such a word, then L(A) = ∅. Let us fix an automaton A = x, Q, ι, F, Δ whose (finite) input event alphabet is Σ, for the rest of this section.
g. q ∧ x ≈ 0, q ∧ x ≈ 1,. for Data I = N. A safety invariant for A is a function I : (Q → B) → 2 x →Data I such that, for every Boolean valuation β : Q → B, every valuation ν : x → Data I of the data variables and every finite sequence u ∈ Σ * of input events, the following hold: 1. I, β ∪ ν |= Post A (ι, u) ⇒ ν ∈ I(β), and 2. ν ∈ I(β) ⇒ I, β ∪ ν |= Acc A (u). If I satisfies only the first point above, we call it an invariant. Intuitively, a safety invariant maps every Boolean valuation into a set of data valuations, that contains the initial configuration ι ≡ Post A (ι, ε), whose data variables are unconstrained, over-approximates the set of reachable valuations (point 1) and excludes the valuations satisfying the acceptance condition (point 2). A formula φ(Q, x) is said to define I iff for all β : Q → B and ν : x → Data I , we have I, β ∪ ν |= φ iff ν ∈ I(β).
Experimental Evaluation We have implemented both Algorithms 1 and 2 in a prototype tool 6  that uses the MathSAT5 SMT solver 7  via the Java SMT interface 8  for the satisfiability queries and interpolant generation, in the theory of linear integer arithmetic with uninterpreted Boolean functions (UFLIA). We compared both algorithms with a previous implementation of a trace inclusion procedure, called Includer 9  , that uses on-the-fly determinisation and lazy predicate abstraction with interpolant-based refinement  [11]  in the LIA theory. The datasets generated during and/or analysed during the current study are available in the figshare repository: https:// doi. org/10. 6084/m9. figshare. 5925472. v1 [12]. The results of the experiments are given in Table  1. We applied the tool first to several array logic entailments, which occur as verification conditions for imperative programs with arrays  [2]  (array shift, array simple, array rotation1+2) available online  [19].
Next, we applied it on proving safety properties of hardware circuits (hw1+2)  [22]. Finally, we considered two timed communication protocols, consisting of systems that are asynchronous compositions of timed automata, whom correctness specifications are given by timed automata monitors: a timed version of the Alternating Bit Protocol (abp)  [25]  and a controller of a railroad crossing (train)  [9]. All results were obtained on x86 64 Linux Ubuntu virtual machine with 8 GB of RAM running on an Intel(R) Xeon(R) CPU E5-2683 v3 @ 2. 00 GHz. The automata sizes are given in bytes needed to store their ASCII description on file and the execution times are in seconds. As in the case of non-alternating nondeterministic integer programs  [17] , the alternating version of Impact (Algorithm 2) outperforms lazy predicate abstraction for checking emptiness by at least one order of magnitude.
g. ,  Murphy et al. , 2014; Silver et al. , 2015) , as well as east-west extension within southern Tibet  (Armijo et al. , 1986). We therefore constructed a 3D backslip model using the Blocks software  (Meade & Loveless, 2009) , which estimates best-fitting fault slip rates and resulting rigid block motions simultaneously. We used several blocks in southern Tibet to account for the observed east-west extension and modeled the MHT with a locking depth of 15 km and a dip of 8°so that the locking line falls in approximately the same place as inferred from the 2D models. We found that the best-fitting convergence rates for the MHT across Nepal are 15. 4 ± 1. 2 mm/year, indistinguishable from our 2D results (Figure  5 ). We computed the best-fitting rates for three different data sets  (Kreemer et al.
Acknowledgments This research was supported by the  National Research Foundation Singapore  under its  Singapore NRF Fellowship scheme (NRF awards   NRF-NRFF2010-064  and  NRF-NRFF2013-06 ), by the  Earth Observatory of Singapore (EOS) , by the  Singapore Ministry of Education (MOE)  under the  Research Centers of Excellence initiative , and by a  Nanyang Technological University   Startup grant. All GPS data used in the models presented here have been previously published and are listed in supporting information Table  S1. This is EOS contribution number  190. We are grateful to  V. Stevens  for helpful reviews and to two reviewers of a previous version of this manuscript, to  P. Tapponnier  and  J. -P. Avouac  for helpful discussions, and to  P. Adamek  for linguistic advice, which significantly improved the structure of this paper.
Applying this parameterization to the BC and OC column amounts simulated using the CHIMERE chemistry transport model, we optimize the parameters of the BB emission model based on MODIS measurements of the fire radiative power (FRP); we then obtain top-down optimized estimates of the total monthly BB BC amounts emitted from intense Siberian fires that occurred from May to September 2012. The top-down estimates are compared to the corresponding values obtained using the Global Fire Emissions Database (GFED4) and the Fire Emission Inventorynorthern Eurasia (FEI-NE). Our simulations using the optimized BB aerosol emissions are verified against AAOD and AOD data that were withheld from the estimation procedure. The simulations are further evaluated against in situ EC and OC measurements at the Zotino Tall Tower Observatory (ZOTTO) and also against aircraft aerosol measurement data collected in the framework of the Airborne Extensive Regional Observations in SIBeria (YAK-AEROSIB) Published by Copernicus Publications on behalf of the European Geosciences Union.
experiments. We conclude that our BC and OC emission estimates, considered with their confidence intervals, are consistent with the ensemble of the measurement data analyzed in this study. Siberian fires are found to emit 0. 41 ± 0. 14 Tg of BC over the whole 5-month period considered; this estimate is a factor of 2 larger and a factor of 1. 5 smaller than the corresponding estimates based on the GFED4 (0. 20 Tg) and FEI-NE (0. 61 Tg) data, respectively. Our estimates of monthly BC emissions are also found to be larger than the BC amounts calculated using the GFED4 data and smaller than those calculated using the FEI-NE data for any of the 5 months. Particularly large positive differences of our monthly BC emission estimates with respect to the GFED4 data are found in May and September. This finding indicates that the GFED4 database is likely to strongly underestimate BC emissions from agricultural burns and grass fires in Siberia.
, 2015). This indicates that to correctly evaluate the effects of BC on the Arctic climate it is critical to know its concentration not only in the Arctic but also in the atmosphere over adjacent regions such as Siberia. Additionally, the deposition of BC on ice and snow has been found to strongly contribute to Arctic warming by decreasing surface albedo and promoting ice/snow melting which, in turn, may result in further surface darkening and provide a positive feedback on the increase of the surface temperature in the Arctic  (Hansen and Nazarenko, 2004; Flanner et al. , 2009; Flanner, 2013). The effects of biomass burning on atmospheric composition and climate are commonly evaluated using chemistry transport and climate models relying on data from BB emission inventories, such as the Global Fire Emissions Database (GFED)  (van der Werf et al.
, 2017) , the Global Fire Assimilation System (GFAS) emission dataset  (Kaiser et al. , 2012) , the Emissions for Atmospheric Chemistry and Climate Model Intercomparison Project (ACCMIP) inventory  (Lamarque et al. , 2010) , the Fire Inventory from NCAR (FINN)  (Wiedinmyer et al. , 2011) , and the Quick Fire Emissions Dataset (QFED)  (Darmenov and da Silva, 2015) , which are widely used in atmospheric and climate studies. However, emission inventory data are likely to be affected by considerable uncertainties due to a limited knowledge of spatiotemporal characteristics and temperature regimes of fires, as well as due to the lack of reliable estimates of emission factors for a variety of ecosystems and environmental conditions. These uncertainties lead to large discrepancies between emission estimates provided by different inventories.
, 2013). Second, the algorithm is sensitive to assumptions about the altitude of the aerosol center mass. To address this sensitivity, the AAOD data are retrieved for a set of five different aerosol center mass locations: at the surface and 1. 5, 3. 0, 6. 0, and 10 km above the surface. The "final" AAOD product derived by OMAERUV is referenced to the monthly climatology aerosol layer height as given by the OMI-CALIOP (Cloud-Aerosol Lidar with Orthogonal Polarization) joint dataset  (Torres et al. , 2013). Third, the major factor affecting the quality of the aerosol retrievals provided by OMAERUV is sub-pixel cloud contamination. However, compared to AOD and SSA retrievals, AAOD is less affected by cloud contamination due to the partial cancellation of errors in AOD and SSA. OMAERUV reports AOD/SSA/AAOD with the associated quality flags "0" and "1".
03 in OMI and AERONET inversions. Since AAOD can be expressed through SSA and AOD, these comparisons indicate that the OMI AAOD retrievals are also realistic. In this study, we made use of the reliable AAOD retrievals corresponding only to the BB type of aerosol. The quality assured values of AAOD at 388 nm for the period from 1 May to 30 September 2012 were projected onto a rectangular 1 • × 1 • grid with an hourly temporal resolution. Different values falling into the same grid cell within an hourly period were averaged. We used both the AAOD datasets corresponding to the predefined altitudes of the aerosol layer and the "final" AAOD product.
Considering the experimental analysis by  Wooster et al. (2005) , we assumed α to be 3. 68 × 10 -4 g s -1 W -1. The vegetation land cover fractions, ρ l , were evaluated with the initial resolution of 0. 2 • × 0. 1 • using the NCAR USGS land use dataset  (Homer et al. , 2004) , which was also used to specify the land use data in the CHIMERE model. Consistent with the land use categories defined in CHIMERE, our BB emission model given by Eq. (  2 ) formally takes five vegetation cover types (needleleaf forest, broadleaf forest, shrubs, Table  1. Emission factors (g kg -1 ) for the carbonaceous components of BB aerosol. The numbers are adopted from the GFED4 inventory (van der  Werf et al. , 2017)  and are based on  Akagi et al. (2011)  and  Andreae and Merlet (2001)   1 ) were chosen to be the same as those in the GFED4 inventory; this choice simplifies the comparison of the results of our analysis with the GFED4 data.
To take possible spatial and temporal covariances of the model and/or measurement errors into account, we ensured that the size of any sampled dataset is not larger than the number of the available (in the optimization subset) data points, for which the distances between them (both in space and time) are larger than the corresponding de-correlation length/time scales (which were evaluated separately both for AAOD and AOD). As a result of this limitation, the size of any sampled monthly dataset was several times smaller than the size of the original optimization dataset for a given month. In each iteration of the bootstrapping procedure, we randomly changed the parameters of the AAOD parameterization given by Eq. (  6 ) by sampling them from a Gaussian distribution with the standard deviations evaluated above (see Sect.
The uncertainties are largest in the estimates of F BC and F OC for September (45 % and 47 %, respectively). This is not surprising considering that the fires were relatively small in this month (see Fig. 3 ), and so the number of available observation data points in the optimization dataset is many times lower for September (58 data points) than, e. g. , for July (3017 data points). The monthly variations in both the correction factors and their ratios exhibit a rather pronounced seasonal pattern. Specifically, the values of F OC are smaller in May and September than in the summer months. In contrast, the values of F BC and the F BC /F OC ratio are much smaller in the summer months than in May and September. Although the differences between the correction factors for different months are mostly not statistically significant, a more than twofold decrease in the F BC /F OC ratio in June and July is statistically significant with respect to both May and September.
The correlation coefficient values were considerably smaller and biases were much larger when the model used the "initial-guess" BB emissions calculated with the correction factors equal unity. These findings indicate that the inversion of the AAOD and AOD observations results in major improvements in the model performance. Figure  7  compares the relationships between AAOD and AOD according to the satellite observations and our simulations. The relationships include all of the gridded daily data points selected for the validation dataset. As follows from Eq. (  4 ), the relationship between AAOD and AOD is indicative of the EC/OC ratio in BB aerosol particles. Therefore, the adequacy of the relationship between the modeled AAOD and AOD values is an important prerequisite for accurate estimations of the EC/OC ratio in the BB aerosol emissions.