dataesr/scientific-paragraphs-categorization huggingface dataset:
The total latency of the algorithm was therefore the sum of the processing module latencies and processing time, as well as inter-board data transmission latency, of all the processing steps. The latency of the hardware demonstrator also included the data transmission latency for receiving stubs from and sending final tracks back to the data source/sink blade. A summary of the estimated latency is shown in Table  1. With a 240 MHz clock and a time-multiplex factor of six, the total estimated latency is 3345. 8 ns. The total latency of the demonstrator was also measured with a clock counter on the data source/sink blade. We started the counter when sending out stubs, and record the counter outputs when receiving valid tracks. The actual measurement was done with 240 MHz processing clock. The measured latency was 3333 ns, which agrees within three clock cycles (0.
4%) with the model. 2 For the tracklet 2. 0 release, we are implementing the algorithm in C/C++ using the Xilinx Vivado HLS tools  [15]. We believe HLS will produce code that will be easier to maintain and provide a lower barrier for entry of new people to contribute to the development of the project. Tracklet 2. 0 provides several improvements over the algorithm as implemented for the demonstrator. The algorithmic improvements from using the "long virtual modules" reduce the effects of truncation and the new sector definitions remove the need for nearest neighbor communication. One significant change is that the TMUX factor is now 18, which results in 450 ns of processing time. This time increase is offset by the reduction in the number of processing steps achieved removing the steps Table  1.
Demonstrator latency model using the tracklet 1. 0 configuration. For each step, the processing time and latency is given. For steps involving data transfers, the link latency is given. The model and measured latency agree within 0. 4% (three clock cycles). Step Proc. Step The half-sector project included seeding in multiple layer and disk combinations (L1+L2, L3+L4, D1+D2, and D3+D4). This project consisted of the following processing modules: 12 LayerRouters, 22 VMRouters, 126 TrackletEngines, 8 TrackletCalculators, 22 ProjectionRouters, 156 MatchEngines, 22 MatchCalculators, 4 TrackFits, and one PurgeDuplicate. The resources used in the demonstrator project are shown in Table  3. The resource usage from the V synthesis for the full sector project is summarized in Table  4. The most heavily used resource was BRAMs.
Cabling The baseline strategy for the project assumes a tilted barrel geometry  [4] , 9 φ-sectors for track finding and a time-multiplex factor of 18 for the tracklet 2. 0 configuration. The DTC layout assumed here is as follows: a total of 108 DTCs for a half-detector (+ and -z); 54 for the PS modules, connected to the inner three layers of the half-barrel and the inner seven rings of the endcap, and 54 for the 2S modules, connected to the outer three layers of the half-barrel and the outer five rings of the endcap. The DTCs are arranged such that they cover "nonants" in φ (nonants is referring to the currently proposed division of the readout of the outer tracker in a nine-fold symmetry) over a half-length of the tracker, and so each track finder φ nonant and half-length connects to 12 DTCs (that is, 108 DTCs per half-length in z split into nine in φ).
If the nine sector processors were aligned with the DTC φ-nonants, the overlap regions on either side of a sector would require each DTC to in our qualification process. The precision of the calculations used in the emulator is tuned to ensure sufficient accuracy to meet the required physics performance goals in the trigger. The demonstrator setup for tracklet 1. 0 shows excellent agreement between the actual firmware results and the integer-based C++ emulation of the system. For single object events, the output tracks from the firmware have 100% bitwise compatibility with the integer-based emulation. For busier events, for example t t with an average pileup of 200, the emulation and firmware tracks agree to better than 99%, as was shown in Figure  11. These tests validate the use of the integer-based emulation code for extrapolating to future performance improvements.
Final tracking performance The estimated performance of the tracklet algorithm is studied with the integer-based emulation of the algorithm. The L1 tracking efficiency as a function of p T and η for single muons or electrons (generated with a uniform p T distribution) in events without pileup is shown in Figure  16. Electrons have a lower efficiency compared to muons due to their higher interaction rate with the detector material at the momenta in question. Similarly in Figure  17 , the L1 tracking efficiency as a function of p T and η is shown for charged particles from t t production, in events with an average pileup of 0, 140, or 200. The efficiency is computed as implemented in the demonstrator, i. e. , it includes the effects of truncating data. These effects are minimal, for two main reasons, (i) because of the large parallelization of the system, most of the modules are sparsely populated, (ii) the different seeding combinations provide additional redundancy that can recover tracks that may otherwise be lost.
The detector is largely symmetric in ±z, so the addition of the -z side only results in increased occupancy, which is handled by more instances of already-existing HDL modules. Since more data are coming into the sector processor, about a factor of two, the total I/O requirements will increase by roughly a factor of three, taking into account both the increase of the total data rate and the cabling scheme of the new detector. These I/O requirements are within the capabilities of the specifications of the Xilinx Virtex UltraScale+ family of FPGAs. None of these changes represent more than an evolution of the demonstrator. The demonstrator has been used to validate the algorithm and board-to-board communication, to measure timing and latency, and to 0 0. 2 0. 4 0. 6 0. 8 1 1. 2 1. 4      Track rate for t t events with an average of 200 pileup interactions.
Acknowledgments The authors would like to thank the  Wisconsin CMS group  for their support of the CTP7 platform. We are grateful to the  CMS Collaboration  for use of their detector simulation software. This work was supported by the  U. S. National Science Foundation  through the grants  NSF-PHY-1607096 ,  NSF   PHY-1312842 ,  NSF-PHY-1307256 ,  NSF-PHY-1120138  and the  U. S. Department of Energy Office of Science   DE-SC0011726  and  DE-SC0015973.
3. Security and cyber resilience: including risk mitigation related to malicious or accidental takeovers of datalinks leading to accidents, theft or deliberate use of drones to damage infrastructures. 4. Human factors and training: including situation awareness, transition to more automated drones, contingency and failure management. 5. Validation and demonstration: risk-based logic would enable the collection of data and observations to further refine concepts, while increasing public acceptance. 6. Air Traffic Management (ATM): to integrate drones in all classes of airspace. The focus of COMP4DRONES complements SESAR JU efforts in regards to areas 1 to 5 with particular emphasis on software and hardware architecture of drone systems. The project is in its first year of solutions; technical work started on October 1, 2019 and will last 36 months.
Thus, developing this latter may represent a significant cost since they do not have the financial capacity to recruit security and/or certification experts. Furthermore, lack of tools and normative constraints lengthen deadlines, increase development costs, and generally hinder innovation (new manipulator arms, new sensors or actuators, new types of mission, etc. ) that drones' manufacturers would like to integrate into their platforms. There is no standard autopilot, however, there are many open source ones, like Paparazzi, ArduPilot or PX4, supported by many hardware platforms. These autopilots provide several versions depending on the type of underlying drone structure: rover, helicopter, quadcopter, hexa-copter, plane, vertical takeoff plane, etc. The software architecture of ArduPilot, programmed in C ++ is designed to be portable, however, still very complex to adapt.
Given its size and versatility, it is very unlikely that the code can be certified according to avionics standards. In addition, to maintain its compatibility with versions running on architectures that do not support multithreading, ArduPilot uses a cyclic execution model that can only run on a one computing core. The interest of open source autopilots is their versatility and their speed of adaptation to be supported by new hardware platforms thanks to the developers' community. Indeed, they are characterized by a layered architecture. The physical layer, device drivers' layer, and device driver glue layer (which is hardware platform dependent), but the autopilot software layers are almost independent, and require few or no adaptation for new platforms hardware. However, these architectures focus only on minimalist activities such as missions based on drone movements, integrating commands flight and navigation.
That is the use of external software components with the fast loop is impossible since that requires a deep code modification of this loop. Many autopilots use the MAVLink communication protocol, which is not a standard, but it can be considered as de-facto standard for drone-to-drone or ground station to drone communication. It allows in particular the use of different ground stations for the same drone. In the early 1990s, basic internal architectures of large and medium-sized aircraft avionics were based on federated architectures, where each functionality of the aircraft, for instance flight control or navigation, was implemented by dedicated hardware and software. This was the easiest solution to isolate any potential failure, so as not to affect other features  [23]. However, with the increase in the number of functions required for aircraft, the federated architectures presented scalability problems  [24] , which triggered a shift towards integrated modular architectures (IMA).
However, this degree of predictability must not only be present at the communications but also at the software level. Another challenge we are tackling is the integration of this architecture with robotic software development frameworks such as the Robot Operating System (ROS), promoting software and tool re-use. ROS  [27] , maintained by Willow Garage  [28]  and Open Source Robotics Foundation (OSRF)  [29]  since 2007, is an open-source middleware that has undergone rapid development  [30]  and has been widely used to design robotics applications. ROS aims at easing the development process by providing multiple libraries (e. g. , OpenCV and the Point Cloud Library (PCL)  [31] ), tools and algorithms, and a practical publish/subscribe transport mechanism. Importantly, an effort is being made to avoid sources of non-determinism, towards supporting real-time safe memory allocation and synchronization, and an adequate communication middleware that is able to cope with real-time QoS requirements.
The currently available implementation (actively developed and maintained by a strong community) in the open source networking community is Multipath-TCP (MPTCP)  [54]. This system is currently at version 0. 94, and slowly gaining foothold in the commercial world. Alternative systems (for instance based on UDP) exist, but have not reached maturity and are not being actively maintained. MPTCP includes a standard path manager for the monitoring and management of the underlying links, which is implemented at the kernel level, as a more or less integral part of the MPTCP-extended TCP stack of the operating system (Linux-based in the latest releases). The ambition within COMP4DRONES is to develop an improved path manager for use in communication with (unmanned) aircraft, and enable it for multiple, heterogeneous communications technologies at OSI level 4 (see Figure  4 ).
To enhance the possibility of more reproducible validation of connection metadata, COMP4DRONES will develop models to associate obtainable metadata from wireless connections (including radio connection quality, packet delays and packet delay variation, etc. ) with values of transport-and application-level connectivity quality. The project will further implement and demonstrate technology to validate the model via automated systems to run test suites and data collection for the validation in laboratory settings and controlled test flights. To enhance the possibility of more reproducible validation of path management of multipath communication for drones, COMP4DRONES will implement and demonstrate technology to validate the path manager's ability to direct communication packets over the most reliable path under constraints of desired packet delay times for the connection.
Both inspective missions (i. e. digitized data about leaf chlorophyll used on the go to apply fertilizer-N using variablerate techniques or to decide on soil and crop management strategies), and precise spraying is enabled by drone usage (see Biermacher et al. (  2006 )). Digital and/or spectral information, (i. e. indices obtained in real time or with short time postprocessing), acquired by RGB and Near Infra-Red (NIR) camera, mounted on unmanned aerial systems or vehicle (UAS and UAV) linked to unmanned ground vehicle (UGV) vehicle, in vineyard, horticultural crops and in olive trees determine best management practice (BMP) in field. Data will be used to: detect the status of health of fields and plants (i. e. early pests detection using image processing and computational intelligence); compare the data collected periodically with (i.
VI. POTENTIAL IMPACTS The integration of the professional drones into the airspace, especially for operations beyond visual line of sight, may influence all classes of airspace and have a much greater impact on the airspace than leisure drones. This is expected to be especially true in the long-term for delivery and public safety & security drones operating in urban environments. Professional drone operators will need to safely operate alongside manned aviation and delivery drones in dynamically changing environments. With particular emphasis on software and hardware architecture of UAV systems, COMP4DRONES is in line with ECSEL JU R&D priorities and complements SESAR JU efforts in regards to the following drone's awaited features: detect & avoid, datacom & spectrum, security & cyber resilience, human factor and training, and validation & demonstration.
ACKNOWLEDGEMENT This work was financially supported by European commission through ECSEL-JU 2018 program under grant agreement N° 826610, and it get national financing from France, Spain, Italy, Netherlands, Austria, Czech, Belgium and Latvia. As shown in Figure  6 , the COMP4DRONES partners cover important geographical areas in Europe and ensure that project outcomes will have lasting impact on European Drones Technology Industry. The total project budget is 28,590,748. 75 EUR (excluding ESIF partners) while the requested grant is 7,983,731. 61 EUR to ECSEL JU, and 8,874,523. 84 EUR of National and ESIF Funding. The European and national grant agreements have been signed and technical work has start on 1 st of October 2019.
Data are taken from the Human Mortality Database (HMD 2019). We assume that the number of deaths at age x and year t is a random variable D x,t that follows a Poisson process  (Brillinger 1986 ): D x,t ∼ P(e x,t μ x,t ) (6. 5) where the force of mortality μ x,t is assumed to be constant over each year of age (i. e. from age x to x + 1) and over each calendar year (i. e. from year t to t + 1). This assumption implies that μ x,t approximates the force of mortality at exact age x + 1 2 and exact time t + 1 2  (Cairns et al. 2009). Note that the notation μ x,t is the discrete counterpart of the continuous notation μ(x, t) employed in Sect. 6. 2. 1. Moreover, death rates m x,t = d x,t /e x,t are the maximum likelihood estimators of the force of mortality μ x,t , if no structure is enforced over age and/or time.
Out-of-Sample Validation Here, we assess the predictive performance of the 3C-STAD model using out-ofsample validation. Specifically, we employ data of the Human Mortality Database (2019) for the female and male populations of Sweden and Switzerland for the period 1950-2016. For each population, we perform three exercises, corresponding to validation periods of 10 years  (training period 1950-2006), 20 years (training period 1950-1996)  and 30 years  (training period 1950-1986). The common starting year of analysis, 1950, was chosen in order to have training periods longer than validation horizons for each exercise. To assess the performance of our forecasts, we employ the standard life-table functions: life expectancy at birth (e 0 ) as measure of population's longevity, and age-specific mortality rates (in log scale, ln(m x,t )), which measure the age-pattern and intensity of mortality.
We have applied the 3C-STAD model to the female and male populations of Sweden and Switzerland using data retrieved from the Human Mortality Database (2019). First, we assessed the point and interval forecast accuracy of the model by performing three out-of sample validation exercises. We have then forecast mortality for each population until 2050. In both cases, we compared the 3C-STAD projections with those of three well-known and employed methodologies: the Lee-Carter (LC,  Lee and Carter 1992) , the CODA  (Oeppen 2008 ) and the Hyndman-Ullah (HU, Hyndman and Ullah 2007) models. We compare forecasts of summary measures, such as life expectancy as birth (e 0 ) and lifespan inequality (as measured by the Gini coefficient, G 0 ), as well as age-specific functions, such as death rates or age-at-death distributions.
) ibrate models and the difficulty of incorporating fluid flow and igneous events in basin models  (Gardiner et al. , 2019). Here we report new thermal maturity data from two holes located at the SE China COT, where petrophysical data, heat-flow measurements and thermal maturity observations better constrain the thermal evolution. The intent is that future work can compare the SCS rifted margin to others in order to construct better thermal models for COT. Sites U1499 and U1502 were drilled during IODP Expeditions 367-368 on the SE China COT. Holes at these sites penetrate sedimentary, magmatic and hydrothermally altered sediments and rocks located at the most distal SE China continental margin (a location with extreme lithospheric thinning and crustal thickness <10 km). This unique dataset permits the investigation and modelling of the in situ thermal history of pre-syn-and post-rift sediments and from this can be deduced the thermal effects of the rifting processes that formed the South China Sea.
Sampling strategy Sampling was guided by total organic carbon content (see  Sun et al. , 2018 and supplementary information) , with preference given to organic matter rich intervals most likely to yield high quality data (e. g. those with a TOC > 0. 5%, SI 1). The deepest units at the base of U1499 were sampled at a greater frequency because of their importance for capturing syn-rift thermal history), with both the matrix and the clasts of the pre-to syn-rift breccias sampled.
Raman spectroscopy Raman spectra of carbonaceous matter provide a geothermometer across both metamorphic (T > 200 • C)  (Beyssac et al. , 2002; Lahfid et al. , 2010)  and diagenetic temperature conditions (50-200 • C)  (Lünsdorf and Lünsdorf, 2016; Schito et al. , 2017; Schmidt Mumm and Inan, 2016; Wilkins et al. , 2014) , as well as within the thermal aureoles of magmatic intrusions  (Muirhead et al. , 2017). Micro-Raman spectroscopy was carried out using a Jobin Yvon LabRam system in a backscattering geometry. Data were collected in the first order Raman spectrum over the range 1000-2000 cm -1 using a 600 grooves mm -1 spectrometer grating and CCD detector and Neodimium-Yag green laser (532 nm) as a light source. Laser-induced degradation of kerogen and fluorescence-background signals were minimised by maintaining laser power below 0.
Modelling To determine the thermal evolution of the SE China COT at ridge A, 1D basin models were produced using BasinMod 2D (Fig. 6 ). Basin models integrated porosity and thermal conductivity data measured for U1499 and U1502  (Larsen et al. , 2018b). Different heat-flow scenarios were investigated. The first scenario used a constant heat-flow through time (Fig. 6 ). Temperature measurements acquired during piston coring at site U1499 give a presentday geothermal gradient of 93 • C/km and an estimated heat flow of 110 mW m -2 calculated using measured thermal conductivities of the sampled-sediments  (Sun et al. , 2018). The constant heat-flow model has a good correlation with the late post-rift section (above Tg) at both sites although it is unable to match the higher thermal maturity values in the earliest post-rift and in the gravel unit at Site U1499 (Fig.
To test if the high thermal maturity gradient recorded in the gravel unit can be recreated by heating within the aureole of a magmatic body we combined the results of the Basinmod 2D software with predictions made by the SILLi 1. 0 software  (Iyer et al. , 2018). The SILLi software is designed to predict the effect of magmatic sills on the thermal maturity of a stratigraphic succession. In this case we assume that beneath the pre-/syn-rift gravel unit or nearby is a magmatic body. The intrusion was assumed to have been emplaced during the early Oligocene, during breakup. A set of models was performed to test the depth and size of the intrusion that could best recreate measured thermal maturities. The best fit was obtained by a body 200 m thick located at 1150 mbsf (or 70 m beneath the TD of hole U1499B).
In contrast to the SE-China COT, the Pyrenean fossil hyper-extended rift basin is characterized by prerift evaporites, massive syn-rift and early post-rift sedimentation, that blanket and bury sediment leading to the recording of high thermal maturities in organic matter  (Clerc and Lagabrielle, 2014). Without significant burial (∼3-6 km in the Pyrenean case study  (Clerc and Lagabrielle, 2014) ), the temperature at the base of a sedimentary succession would never be great enough even were a geothermal gradient high (>80 • C km -1 ). Late post-rift magmatism is not indicated by our dataset while it is inferred in other localities of the SE China margin and clearly mapped in the oceanic domain of the SCS as shown by occurrence of several seamounts  (Sibuet et al. , 2016). Post-rift volcanism at a COT modifies the thermal regime in a way similar to that seen in the high local heat-flows in places such as the Gulf of Aden  (Lucazeau et al.
Acknowledgements This research used data provided by the  International Ocean Discovery Program (IODP). We thank the participants to IODP Expedition  367-368  as well as the captains and crew of the Joides Resolution. Seismic sections originate from the IODP Expedition 367/368/368X proceeding volume. Platte River Associates, Inc is thanked for providing an academic licence of BasinMod  2D. We acknowledge  IODP France and ECORD  for the support. Funding for this research was provided by  Total SA R&D  (J. N. Ferry). SAB gratefully acknowledges  NERC  award  NE/R002576/1 ;  Measuring Rates  of  Weathered Petroleum Accumulation, South China Sea.