dataesr/scientific-paragraphs-categorization huggingface dataset:
2015) , the AfriSAR campaign allowed for extensive experiments on baseline and temporal decorrelation. Here, we were able to generate canopy height products using multiple methodologies, using the PLAnT software  (Lavalle et al. , 2018b) , the Kapok software and the Fusion approach  (Denbina et al. , 2018a)  which helped determine the limitations and strengths of each methodology and the ideal configurations for L-band multibaseline PolInSAR acquisitions in dense tropical forests. As an example, the fact that the 'fusion' approach performs better at estimating the RH100 or Top of Canopy height than the traditional PolInSAR approaches highlights the potential improvement when using SAR-Lidar fusion or other ancillary data that helps in selecting the appropriate interferometric baseline. The lower bias between the CHM Fusion products and the more traditional PolInSAR methodology highlights the importance of selecting the appropriate baseline, especially in areas like Gabon, where the range in heights is high (up to 65 + m).
Finally, while the operational repeat-pass mode of the NISAR mission does not allow for TomoSAR or multi-baseline PolInSAR acquisitions, the multi-baseline acquisitions of the ESA BIOMASS mission will provide the necessary datasets. The released UAVSAR and LVIS datasets provide a large quantity of coincident (PolIn)SAR and lidar coverage, ideal for the development and testing of algorithms which fuse the results from these sensors. While SAR data has wide spatial coverage and high resolution, it can be affected by some limitations and error sources such as temporal decorrelation and saturation in high AGBD forests. Lidar can generally estimate forest canopy height and vertical variations in canopy structure with high accuracy but is limited in terms of spatial coverage. Fusion algorithms can therefore help to mitigate the weaknesses of each sensor, combining the data into fused products which leverage the strengths of both lidar and SAR.
The released CHM Fusion fused canopy height and AGBD products help demonstrate examples of this potential, and the released L1 UAVSAR and LVIS data can be used for development and testing of other future algorithms, which can be applied to spaceborne data from GEDI, NISAR, Biomass, and other future sensors. One of the main hurdles for the uptake and use of lidar and SAR by the broader ecological and scientific community has been the lack of gridded and higher level products available from waveform Lidar and SAR data. Data from sensors with existing and well documented ARD products have much higher use than sensors without, highlighting the importance of providing not only raw data but also preprocessed datasets. As an example, the SRTM DEM, a processed and tiled product derived from C-band single pass interferometry, is one of NASA's most downloaded datasets, although it is only based on a one-time acquisition in early 2000  (Farr et al.
, 2007). As part of the AfriSAR campaign, we have produced a suite of data products from UAVSAR and LVIS that have not been available to date, such as LVIS-derived canopy cover fraction, Plant Area Index, Gridded canopy height from LVIS and UAVSAR Pol-InSAR and Tomographic SAR products, allowing the development of new scientific applications. In  Marselis et al. (2018) , for example, the LVIS canopy cover profile data products were used to predict successional vegetation types in Lopé National Park, with potential implications for the use of GEDI data for informing conservation and biodiversity studies. The dataset was also key in the development of a methodology to map tree species diversity using canopy structure data  (Marselis et al. , 2019)  using GEDI-like data. We anticipate and encourage a wide range of future applications, such as the development of new algorithms that make use of the SAR SLC stacks and associated geometric parameters (e.
g. Soja et al. , 2021). The unique combination of multi-modal remote sensing and field datasets produced by AfriSAR are also the basis of the Biomass Retrieval Inter-comparison eXperiment (BRIX-1 and BRIX-2), which will benchmark biomass retrieval algorithms using GEDI, NISAR and ESA BIOMASS data on the joint ESA-NASA Multi-mission Analysis and Algorithm Platform (MAAP;  Albinet et al. , 2019). AfriSAR was an experimental campaign for which several new SAR and Lidar algorithms were developed and implemented. Because of the limitations that arise during airborne experiments, such as time constraints and changes in flying conditions, there were flight configurations and data acquisitions that resulted in data that did not capture the entire range of forest structure conditions. An example is the vertical wavenumber configuration of the SAR experiments limiting the acquisition of the full height range in all of the imaged sites, or the presence of clouds and poor conditions in some LVIS acquisitions leading to gaps in the data.
Conclusions The airborne SAR, Lidar and field data acquired during the AfriSAR campaign constitutes a rich dataset for use not only in support of the NISAR, BIOMASS and GEDI missions, but also for improved understanding and monitoring of Central Africa's tropical forests, wetlands and savannas. We anticipate that the dataset and described data products will be of use for studies of water and carbon cycling in the Congo basin, used as input and validation for forest growth models and to evaluate conservation and forest management practices. The highresolution canopy height and vertical structure distribution data will be of direct use for studies of carbon cycling and biodiversity amongst many other applications. Spatially explicit estimates of the vertical dimension of forests are needed to characterize rapidly changing global forest cover and AGBD, monitor disturbance, and assess biodiversity  (Bergen et al.
, 2009). The suite of current and upcoming active Remote Sensing missions, including GEDI, BIOMASS, and NISAR, is expected to provide the global scale estimates of canopy height, vertical forest structure and forest density at the resolutions (1 km or better) and accuracies (20% error for 80% of the grid cells) needed to improve our understanding of the role of the land carbon sink in the global carbon cycle. Combining multiple active datasets is already of immense interest, and this is only expected to increase with the impressive amount of data promised from GEDI, NISAR and BIOMASS. The AfriSAR datasets have allowed us a snapshot of the capability of not only the individual missions' measurements, but also the exciting range of science and applications possible through Lidar and SAR data fusion.
Acknowledgements The AfriSAR campaign and data product development was supported by  NASA's Earth Science Division of the Science Mission Directorate. This work was funded by  NASA 's  Terrestrial Ecology program , the Carbon Monitoring System grant ( CMS , grant  15-CMS15-0055 ) and  NASA 's  New Investigator Program  ( NIP , grant # 80NSSC18K0708 ). This work was partly conducted by the  Jet Propulsion Laboratory, California Institute of Technology , under contract with the  National Aeronautics and Space Administration. We would like to express our gratitude to the  Gabonese Spatial Studies and Observation Agency (AGEOS, Agence Gabonaise de l'Etude et Observation Spatiale) , the  Gabon National Park Agency (ANPN, Agence Nationale des Parks Nationaux) , the  Gabon National Scientific Research Center (CENAREST ,  Centre National de la Recherche Scientifique ) and the  Gabon-Oregon Center (GOC)  for their invaluable collaboration and support of the AfriSAR airborne and field campaigns in Gabon.
As from the run 3 of CERN LHC scheduled in 2022, the upgraded ALICE experiment will use a Common Readout Unit (CRU) at the heart of the data acquisition system. The CRU, based on the PCIe40 hardware designed for LHCb, is a common interface between 3 main subsystems: the front-end, the computing system, and the trigger and timing system. The 475 CRUs will interface 10 different sub-detectors and reduce the total data throughput from 3. 5 TB/s to 635 GB/s. The ALICE common firmware framework supports data taking in continuous and triggered mode and forwards clock, trigger and slow control to the front-end electronics. In this paper, the architecture and the data-flow performance are presented.
The 13 ALICE sub-detectors read out via ≈ 10'000 readout links produce 3. 5 TB/s of data. In order to cope with the continuous readout and the resulting data throughput 10 detectors have been upgraded to use the Common Readout Unit (CRU). Faithful to the design reuse strategy for the LHC experiments, the PCIe40 electronics designed for the LHCb experiment  [2]  is used as the ALICE CRU. The CRU is a PCIe-gen3 based FPGA processor board with up to 48 bidirectional optical links (48 in, 48 out). The CRU is the interface between the front-end electronics (FEE), the Online-Offline facility (O 2 ), the Detector Control System (DCS) and the Trigger and Timing System (TTS), see Fig. 1. One CRU can interface up to 24 optical links with the front-ends, one trigger link with the TTS and one PCIe interface.
Data readout The ALICE computing upgrade concept consists of transferring all detector data unfiltered (triggerless) to the computing system. Data volume compression will be performed by processing the data on the fly and not by rejecting complete events as do the high-level triggers or event filter farms of most high-energy physics experiments. For event reconstruction at the EPN level, the continuous data stream is sliced in Time Frames (TF) of programmable length of maximum of 22 ms. The Times Frames are then divided into Heart Beat Frames (HBF) of one orbit duration (89. 4 µs). Heart Beat and Time Frame triggers indicating the boundaries between HBFs and TFs are distributed to the CRU via the PON network by the Central Trigger Processor (CTP). In this scheme, the task of the CRU is to collect the data continuously and to check the successful Heart Beat Frame transmission to each First Level Processor.
The CTP distributes Heart Beat triggers defining whether the corresponding HBF should be accepted (HBaccept -HBa) and thus forwarded to the FLP or deleted (HBreject -HBr). This scheme allows the data throughput to be adjusted to match the available bandwidth during commissioning and dedicated calibration runs. For each HBF, each CRU delivers an acknowledge (HBACK) or not acknowledge message (HBNACK) to CTP which assesses the quality of the HBF transmission of all CRUs. In the case incomplete or corrupted HBFs have been transmitted, the CTP can request the corresponding HBF or even those from a full TF to be deleted from the FLP memory. An example of two incomplete time frame transmissions is shown in Fig. 3.
TF1 @ EPN • Packet detectors can generate data formatted in packets before shipping them to the CRU. Every packet, so called GBT packets, contains the time stamp defined as orbit and bunch crossing. • Streaming detectors cannot organize the data in formatted packets, therefore they generate a stream of data, so called GBT stream, without orbit and bunch crossing information. As described before, data are transferred to the FLP memory in Heart Beat Frames (HBF). The data coming from the different detectors reach the FLP memory with an identical format.
GBT packet type The CRU expects to receive HBFs prepared in the FEE and transferred over the GBT links. The HBF consists of one or more blocks of data containing one header, called Raw Data Header (RDH) and the payload. Data coming from detectors delivering GBT packets are forwarded to the DMA engine unmodified by the CRU firmware. The CRU verifies only the correct HBF structure and formatting. For every HBF the CRU sends an acknowledge message to the CTP informing whether the corresponding HBF has been correctly received (data received properly from all links involved in the data taking) and forwarded to the FLP.
GBT stream type GBT stream type sequences do not have an HBF structure and consist of a continuous stream of detector specific raw data entries. Upon receiving HB triggers, the CRU partitions the data stream in HBFs and forwards them to the DMA engine or deletes the corresponding data packets. In this configuration each GBT link generates a data throughput of up to 4. 48 Gbps, regardless the content of the data. In normal operation the detector specific user logic of the CRU performs zero suppression in order to reduce the data throughput. For short debugging and calibration runs the data compression can be switched off to transfer sequences of uncompressed data, otherwise the amount of data would be too high to be handled by the rest of the data taking chain. For the streaming detectors to collect data in the Physics runs, it is mandatory to implement the User Logic in the CRU, as described below.
CRU firmware requirements The CRU firmware is divided into two parts. The first part is the common firmware which (i) provides the interfaces to PCIe, trigger and timing, and up to 24 front-end links via the GBT protocol, (ii) provides the possibility to read out all detectors in 'raw-mode' with no data processing in the CRU, (iii) allows reference clock and trigger signals distribution, and (iv) permits FEE configuration. The second part is the user logic which is only needed for those detector systems that need detector-specific data processing for instance baseline correction or zero suppression. An important ALICE requirement is to be able to switch between raw-mode and user-logic at any moment without reloading different firmware versions. Self-testing capabilities to ease commissioning and system maintenance are implemented.
They are detailed later in this paper. From a system point of view, the different requirements for the common firmware are due to the different GBT bus mode (packet or stream), the information it is supposed to carry, the integration of a user logic or not, and the type of slow control protocol required to configure the FEE. It is important to mention that when the data reach the DMA engine in the CRU the format is identical, regardless of the data taking configuration of the card. Having the same data format simplifies the firmware logic of the CRU as well as the software required for physics analysis. The GBT links are used to send downstream trigger messages and/or the reference clock to the FEE, while upstream they are used for data readout and optionally to acknowledge specific slow control transactions.
The CRU firmware supports operation of the GBT links in GBT-mode (80 bits of payload and 32 bits of forward error correction) or in wide-bus (112 bits of payload and no forward error correction). For almost all the GBT detectors the GBT-mode provides sufficient data bandwidth. Only the Time Projection Chamber (TPC), pushes data using the 'wide-bus' mode in order to satisfy the bandwidth requirements. As the radiation load for the TPC front-end cards is sufficiently low, the forward error correction the GBT-mode would provide is not required. The requirements of the various detectors can be summarized in table shown in table 1.
Firmware description An overview of the firmware is given in Fig. 4. The main parts are shown: the FEE interface (through GBT links), the Trigger and Timing System (TTS) interface, the board support Package (BSP), the data path and the PCIe endpoints. Starting from the front-end side on the left, the GBT_wrapper interface is shown; it is the interface with the FEE. On the downstream path (CRU to FEE), depending on the detector requirements or test requirements, several sources can be selected to supply the GBT_wrapper. These are the Trigger and Timing System interface, the Dedicated Data Generator (DDG) or the slow control.
Moreover, the GBT_wrapper permits external (with optical fibers) and internal (inside the FPGA transceivers) loop-back tests which allow the validation of the CRU-FEE communication and the CRU data path operation once installed in the system. In external loop-back the data generator enables the emission of representative data towards the FEE that can be looped back by them into the CRU; while in internal loop-back mode, this feature allows to stress the system without relying on the availability of detector FEE.
GBT wrapper The strategy used to maintain a constant latency and to avoid the phase scanning on the transmission path (CRU to FEE) is (i) to rely on the zero delay buffer provided by the hardware PLL and to feed the extracted transmission delays due to the PCB in the constraint file, and (ii) to use the 6 time faster rate to properly sample and transfer the data from one clock domain to the other (120 bits transferred at 40 MHz). On the receiving, which is used only for readout, a non constant latency can be accepted, and thus a FIFO was implemented to cope with the clock domain transfer from the recovered clock domain to the user part clock domain. This solution was extensively tested across several scenarios and proved to be reliable. The scenarios tested were: CRU reference clock switching between local and remote clock source, warm reboot (FPGA reconfiguration) and cold reboot (CRU and FLP turned off and rebooted).
Detector Data Generator (DDG) The DDG is the component in the CRU able to emulate detector behavior and data throughput. This component plays a main role during the test and validation of the CRU firmware and the readout software chain when the detector hardware is not yet widely available. The DDG has different configuration parameters and it can be dynamically configured to produce either streaming or packet type data. The data packet can be produced for different trigger types with fixed or random packet length and inter packet duration, generating a realistic detector throughput. The DDG can be used to test the firmware at any moment in time. Configuring the GBT links using the internal loop-back connection makes the injection of DDG data in the system possible without the requirement to change the physical optical connection at the card input.
Slow Control The majority of the detectors are connected to the DCS system through the CRU. In ALICE there are three configuration protocols: • GBT-EC (External Control)[6], used to send configuration data to the GBT SCA ASIC (Slow Control Adapter)  [7]  installed on the FEE. • GBT-IC (Internal Control)[6], used to configure the GBTx ASIC on the FEE. • GBT-SWT (Single Word Transfer), not using the GBT protocol. While the GBT-EC and IC protocols are part of the GBT design developed at CERN, the SWT is ALICE specific and can be used only by detectors that host an FPGA in the FEE, see Table  1. The SWT protocol has been introduced to increase the bandwidth for the slow control operation. It uses the GBT-DATA path to deliver up to 3200 Mb/s (80 bits per 40 MHz clock cycle) to the FEE whereas the GBT-EC path provides 80 Mb/s.
In practice the slow control read/write speed is limited to 36 Mb/s by the time taken for software to access the PCIe BAR. To send the detector configuration data over the GBT link using the SWT protocol, the CRU must be configured to switch to the SWT traffic with the GBT-MUX component (see Fig. 4 ). This is a static selection, as there is no dynamic packet switching for the downstream path. In the opposite direction, from the FEE towards CRU, the SWT and FEE information is interleaved within the same link. In order to distinguish GBT words that contain physics information from the control words, like the SWT, the CRU uses two types of information, the isdatasel flag decoded from the GBT header and a part of the GBT word embedded in the GBT data field. When the detector sends physics data the flag isdatasel is set to 1 and the whole 80-bit data field is used to transfer the information.
When this flag is 0 the CRU considers the GBT word a The first task of each datapath_wrapper is to receive in parallel the data either from up to 12 GBT busses, from the readout protocol component (trigger acknowledge or decision message) and/or from one user logic link. The gbt_datapathlink is compatible with stream or packet type format. When selecting the stream mode this component constructs data packets, by chopping the data stream and inserting the Raw Data Header (RDH). The RDH describes the readout packet content and contains the Heart Beat ID (HBID), the Link ID, the page counter and the stop bit as well as other information. For each Link ID the page counter gives the packet identification within the corresponding HBF transmitted and the stop bit indicates whether the last packet for this HBF is being transmitted.
The ul_datapathlink receives already correctly formatted packets, either from the User Logic or from the Readout Protocol block, i. e. Heart Beat Acknowledge and Decision Messages (HBFM). At the output of this first stage the packets have a maximum size of 8 KB. The second stage, named pktmuxfifo, performs data aggregation by scanning in a round-robin based manner possible data sources (gbt_datapathlink and ul_datapathlink) and collects data packets. At the output of this stage, the packets from the various links are interleaved. If required by the CTP, this is followed by the removal of all packets from the data flow with a HBr message (number 4 in Fig. 8 ). Then, the packets are stored in a large buffer (bigfifo, 16 kwords of 256 bits)) to be made available to the PCIe endpoint. While being stored, the packets are scrutinized and useful parameters (HBID, LINKID, FIFO status) are presented to the readout control protocol component.
PCIe DMA The main data stream flows through the DMA interface which is used to move data from the FEE to the FLP memory. The CRU communicates with the FLP server through a PCIe gen. 3x16 interface implemented in the FPGA as a dual endpoint PCIe gen3 x8. The DMA engine of the CRU is capable of sustaining a total data throughput of 110 Gb/s. In order to achieve this performance, both endpoints must work in parallel, each one handling a maximum of 55 Gb/s (Fig. 9 ). The nominal DMA throughput provides sufficient margin to collect data from the most demanding detector in ALICE, the TPC. Each of the 360 TPC CRUs receives data from 20 GBT links as input for a total throughput of roughly 89. 6 Gb/s. Unfortunately, the data must be aligned to 32 bit words boundary, and therefore the actual throughput is 102.
4 Gb/s. The incoming data are compressed by the TPC user logic before being delivered to the DMA engine. The expected output of the TPC user logic is 20 Gb/s. 3 2 K i 1 2 8 K i 5 1 2 K i 2 M i 8 M i 3 2 M i 1 2 8 M In the firmware the CRU input data stream is divided between the two PCIe endpoints in order to avoid dynamic switching of the data flow between the two PCIe endpoints. Thus, half of the GBT links implemented in the CRU are connected to one single endpoint via its datapath-wrapper instance that receives data from a maximum of 12 GBT links. In this way, the data throughput is evenly distributed between the two PCIe gen3 x8 interfaces. The communication with the software  [14]  happens through the PCIe BAR interface. There are two BAR interfaces: BAR0 and BAR2. BAR0 is dedicated to DMA operations, it passes the page descriptors and monitors the status of the data taking, while BAR2 is used to access the card configuration and to monitor the other components of the firmware.
The CRU transfers the physics data into the server memory using DMA transfers. In order to do so the CRU needs to know in which buffer data should be stored. For that, the software prepares (or allocates) the buffers in the ferent parameters depending on the sub-detector application a dedicated simulation strategy was developed. The high-speed serial interfaces were simulated and validated on their own as they required much simulation power and would delay significantly a full simulation. Dedicated simulation test-benches were developed for the PCIe DMA interface and for the modified GBT-FPGA which was simulated against the reference design in its Xilinx implementation flavor. The ONU interface was not simulated because it used an IP developed and validated by CERN. The core of the design was embedded into a dedicated test-bench.