dataesr/scientific-paragraphs-categorization huggingface dataset:
Plotting Terrestrial Data From Zenodo in Aladin Field data collected by researchers can be published on Zenodo, giving it a Digital Object Identifier. Creation of a corresponding EPN-TAP table provides an interface to VO, enabling searching this data by location and time. We have produced one such table for drone photographs collected during the 2017 ESA Planetary ANalogue Geological and Astrobiological Exercise for Astronauts campaign  (Rossi et al. , 2018). To view these photographs in Aladin (minimum version: Beta v10. 067), a user would begin by loading a terrestrial basemap by navigating in the "Available data" to the appropriate Hierarchical Progressive Survey of planet Earth. Aladin's built-in TAP access capability can be used to request data with ADQL from our server (registered with IVOA as jacobsuni).
Spectral Analysis of Mars Craters In this case study (a complimentary video tutorial to which can be found at https://www. youtube. com/ watch?v=Jlso7MkdwYs), we will be using an ADQL query to select CRISM coverages overlaying craters and access subgranule data for spectral analysis in CASSIS. The ADQL supports complex geospatial queries over these polygons, allowing, for example, to find intersections between craters and available coverages. Using ADQL to select vector features is in many ways analogous to OGC's Web Feature Service protocol, allowing for selection by geometry and attributes. Similar to cross-layer filtering capability provided by the querylayer module of the Geoserver (http://geoserver. org/), DaCHS server can do queries using complex geometrical operations on different layers, for example, selecting features on one layer that intersect features on another layer.
The ADQL geospatial operations are done in spherical geometry using the spatial SQL implementation of PostgreSQL PgSphere extension (http://pgsphere. github. io/). PgSphere is an extension of PostgreSQL similar to PostGIS extension (https://postgis. net/), they can achieve similar results but implement different indexing algorithms  (Schubert et al. , 2013). The user begins by querying the main VESPA interface for target 'Mars'. The interface will show the table usgs_wms as one of the results. The user can now start QGIS, launch the SAMP Hub and SAMP Client, and then send the table from VESPA to QGIS. The WMS will be added to the table of contents. Complex ADQL queries combining several tables cannot be run from the main VESPA interface yet and need to be executed via a direct TAP interface such as TAPHandle, TOPCAT, or the built-in ADQL form service (http://epn1.
Discussion The photographs from PANGAEA-X-2017 campaign were plotted as polygons aligned with the yaw of the camera as extracted from the EXIF tags. The field-of-view was 84 • , the aspect ratio was constant 3:4 for all images, and they were all pointing at nadir. The size of the footprint was determined from the distance to the target. This distance was computed by subtracting from the GPS altitude the Digital Terrain Model (Instituto Geográfico Nacional, 2009) altitude at location. Unfortunately, the margin of error appeared to be of a greater magnitude than the measurement, making it unreliable. In addition to high random error, a systematic error seemed to be affecting all the coverages resulting in computed distance to target being generally too low, sometimes negative. This was mitigated by adding a constant vertical adjustment when computing the footprints.
Special attention is given to the computation of the radio emission beaming at and near its source. Methods. We explain what physical information about the system can be drawn from such radio observations, and how it is obtained. These information may include the location and dynamics of the radio sources, the type of current system leading to electron acceleration and their energy and, for exoplanetary systems, the magnetic field strength, the orbital period of the emitting body and the rotation period, tilt and offset of the planetary magnetic field. Most of these parameters can be remotely measured only via radio observations. Results. The ExPRES code provides the proper framework of analysis and interpretation for past (Cassini, Voyager, Galileo. ), current (Juno, ground-based radiotelescopes) and future (BepiColombo, Juice) observations of planetary radio emissions, as well as for future detection of radio emissions from exoplanetary systems (or magnetic white dwarf-planet or white dwarf-brown dwarf systems).
Visibility modeling Implementing this forward modeling approach is the purpose of the numerical code described in the present paper, the Exoplanetary and Planetary Radio Emission Simulator (ExPRES). This code uses as inputs the geometry of the observation (observer and celestial bodies positions, sources location and magnetic field topology), the plasma parameters in the sources and their vicinity (density and temperature) as well as the characteristics of the wave-particle interaction generating the radio emissions constrained by the CMI theory. From these inputs, the code computes the beaming pattern of the radio sources, compares the direction of emissions to the direction of the observer and generates time-frequency visibility maps, that can be directly compared to observed dynamic spectra (Section 2).
ExPRES modeling The computation of a synthetic dynamic spectrum with ExPRES mostly relies on the observation geometry. An example is shown on Figure  2 , which sketches the geometry of the observation of emissions triggered by the Io-Jupiter interaction. For a given source-observer geometry (relative positions of the source and the observer at a given time and for a given emission frequency), magnetic field orientation in the source (depending on a magnetic field model), and beaming pattern (depending on electron densities and energies at the source, as discussed in Section 4), the code compares the direction of beamed RX mode waves with the source-to-observer direction. If the angle between these directions is smaller than the beam width, defined by the user, the corresponding time-frequency pixel in the synthetic dynamic spectrum is incremented by 1, otherwise it is not.
-The spatial distribution of sources, i. e, the position of the magnetic field lines carrying the current (from their footprint longitude/latitude, their equatorial longitude/distance or their attachment to a satellite) and the frequency range over which the simulation is to be performed. -The information used to calculate the opening θ of the beaming cone (the distribution function and the energy of the resonating electrons involved in the radio emission, see Section 3) and the thickness ∆θ of the beaming conical sheet. While the source-observer geometry and the magnetic field, plasma density and energy models at the sources are userdefined in ExPRES, the beaming angle θ is self-consistently computed by the code from beaming models described in Section 4 that are based on the CMI theory described in section 3.
Thus ExPRES needs to be fed with the local magnetic field strength (that defines ω c ), the local plasma density (that defines ω p ), and the mean energy of the electrons in the source (that defines v th ). Note that the modes discussed above all have pure circular polarization. Elliptically polarized waves amplified by the CMI can split in L-O and R-X modes on index gradients  (Melrose 1980; Shaposhnikov et al. 1997; Louarn & Le Quéau 1996a). However, in the following we will only consider R-X emissions, because they are the dominant ones in most auroral emissions observed, and for that reason they are the only ones simulated by the ExPRES code so far.
This refraction effect outside the source differs from that inside the source by the fact that it is not symmetrical relative to the magnetic field vector. The ExPRES code models it under the approximation of planar refraction index iso-surfaces at each point of the wave propagation, with a refraction index varying only in the local meridian plane. Thus the gradient of refraction index is assumed to be null in the longitudinal direction, so that the normal to the refraction index planes has a null longitudinal component. The modification of the beaming angle is then obtained easily from the Snell-Descartes law.
Versions of ExPRES Each version of the code has seen new modules added and minor bugs fixed. Here is given a summary of the majors evolutions. The first versions (0. 1, 0. 2 and 0. 3) of the ExPRES code were developed to predict and interpret the future observations of the NASA Juno space mission to Jupiter. Indeed, unlike previous low frequency radio astronomy experiments (such as Cassini/RPWS,  Gurnett et al. 2004) , which were able to measure the 4 Stokes parameters and the k vector of incoming waves  (Cecconi et al. 2009) , the radio experiment onboard Juno  (Matousek 2007; Bagenal et al. 2017) , named Waves  (Kurth et al. 2017) , only measures the total intensity of incoming radio waves versus time and frequency (it also performs some limited direction-finding, but that proved effective for case studies  Imai et al.
2017). The development of the ExPRES tool was therefore necessary to determine the origin of the emissions. Version 0. 4 of the code allowed a generalization to Saturn and version 0. 5 to exoplanets. For version 0. 6, the code architecture was completely redesigned and the production of 3D movies was added. The current stable version is 1. 0 and allows, from JSON formatted  (Bray 2017)  input files, to produce the simulation results in CDF (Space Physics Data Facility 2018).
ExPRES has also been used to predict and interpret radio emission from Jupiter, using a predefined dataset for the input parameters (based on a parametric study, see  Louis et al. 2017b). It allowed the authors to detect radio emissions induced by Europa and Ganymede  (Louis et al. 2017a ) and interpret the timefrequency morphology of Juno/Waves observations  (Louis et al. 2017c) , which was the initial goal of the code. ExPRES was similarly used to simulate the radio environment of the Jupiter Icy Moon Explorer (JUICE) spacecraft planned to be sent to Jupiter by ESA, in order to estimate to what extent natural radio emissions from Jupiter's magnetosphere below 40 MHz would pollute the spacecraft radar measurements in the range 5-50 MHz  (Cecconi et al. 2012). Finally,  Hess & Zarka (2011)  studied the type of information that can be deduced, using ExPRES, from the morphology of the radio emissions -still to be discovered -from exoplanetary magnetospheres or star-planet systems involving plasma or magnetic interactions.
Accessibility The ExPRES code is written in IDL 1. The code is available under MIT licence on GitHub within the MASER 2  library repository: https://github. com/maserlib/ExPRES. The current version of the ExPRES code (V1. 0) has been validated using IDL version 8. 4. Precomputed ExPRES simulation runs are available through different interfaces described on the MASER project  (Cecconi et al. 2018a,b)  website 3  : (i) a web directory listing access; (ii) a virtual observatory access using the EPN-TAP  (Erard et al. 2018) ; and (iii) a streaming access using the das2 server framework  (Piker 2017 ) through the MASER das2 Server. Table  1  provides URLs for all access interfaces. The ExPRES code is also available for run-on-demand operations at https://voparis-uws-maser. obspm. fr. This computing interface requires an ExPRES JSON input configuration file.
(Erard et al. 2018. obspm. fr:80/tableinfo/expres. epn_core VESPA or TAP client(Erard et al. 2018) Streaming access Das2 http://voparis-maser-das. obspm. fr/das2/server Autplot (Faden et al. 2010) List of access interfaces for ExPRES precomputed dataset lat (LUTh, Observatoire de Paris). The Nançay Decamater Array acknowledges the support from the Programme National de Planétologie and the Programme National Soleil-Terre of CNRS-INSU. S. L. G. Hess thanks the MOP team of the LASP (Colorado Univ. Boulder) and R. Modolo (LATMOS/CNRS) for scientific support and fruitful comments. Part of the data distribution setup has been done in the frame of the Europlanet H2020 Research Infrastructure project, which has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 654208.
Acknowledgments Version 0. 1 to 0. 5 of ExPRES have been developed as  SERPE ("Simulateur d'Émissions Radio Planétaires et Exoplanétaires ") by the  LESIA laboratory under Observatoire de Paris  and CNRS funding. Version 0. 6. 0 was developed by  S. L. G. Hess  on his own resources and with support from the  LESIA, Observatoire de Paris  for the online services. Later versions, including the current 1. 0. 0 version, were developed by the MASER team (http://maser. lesia. obspm. fr)which gathers personnel and funding from  CNRS ,  CNES  and  Observatoire de Paris. Technical support from  PADC (Paris Astronomical Data Center)  is also acknowledged, with the very helpful contribution of  P. Le Sidaner  ( DIO, Observatoire de Paris ) and M. Servil-.
Characteristic image of respective area, 10 x 10 m 2 and 50 x 50 m 2 , were acquired for each sample using a Nanoscope V (Bruker instruments, Madisson, WI, United States) in contact mode (Binnig et al. , 1986) and standard silicon probes (Bruker, DNP). Root mean square (RMS) roughness of the polymer surface was measured for each scale with Gwyddion software after subtraction of the average plane.
Cosmic Ray Energetics and Mass for the International Space Station (ISS-CREAM) is designed to directly measure the energy spectra of high-energy cosmic rays, encompassing proton to iron nuclei, over the energy range from 10 12 to 10 15 eV  [1]. The capability to measure an extended energy range enables us to probe the origin and acceleration mechanisms of cosmic rays. The ISS-CREAM instrument is configured with the balloon-borne CREAM calorimeter (CAL) for energy measurements and four layers of a finely segmented Silicon Charge Detector (SCD) for charge measurements. In addition, two new compact detectors have been developed for electron/proton separation: Top and Bottom scintillator-based counting detectors (TCD/BCD) and a boronated scintillator detector (BSD). Simulations use the GEANT3 package  [2]  with the FLUKA hadronic model  [3].
Acknowledgements This work was supported in the U. S. by  NASA  grant  NNX17AB41G , in Korea by  National Research Foundation  grants  2018R1A2A1A05022685  and  2018R1A6A1A06024970 , and their predecessor grants. It was also supported in France by  IN2P3/CNRS  and  CNES  and in Mexico by  DGAPA-UNAM  project  IN109617. The authors thank  NASA GSFC WFF  and its contractors for engineering support and project management, JSC ISS Program Office for the launch support and ISS accommodation,  MSFC  for the operational support, and  KSC and SpaceX  for the launch support.
Scalable High efficiency Video Coding (SHVC) is the scalable extension of the High Efficiency Video Coding (HEVC) standard. SHVC enables spatial, quality, bit-depth, color gamut and codec scalability. The architecture of the SHVC encoder is based on multiple instances of the HEVC encoder where each instance encodes one video layer. This architecture offers several advantages of being modular and close to the native HEVC coding block scheme. However, the close-loop SHVC architecture requires the complete decoding of the reference lower-layer frames to decode a higher quality layer, which considerably increases the complexity of both encoder and decoder processes. In this paper, we propose an end-to-end 4K real time SHVC solution, including both software encoder and decoder, for video broadcast applications.
The SHVC codec relies on low level optimizations for specific Intel x86 platform and parallel processing to speed-up the encoding and decoding processes. The proposed encoder enables a real time processing of 4Kp30 video in 2x spatial scalability on the 4x10-cores Intel Xeon processor (E5-4627V3) running at 2. 6 GHz. In addition, the SHVC decoder enables to decode, respectively, the lower quality layer in full HD (1920x1080p30) resolution, on ARM Neon mobile platform, and the enhancement layer in UHD (3840x2160p30), on a laptop fitted, with 4 cores Intel i7 processor running at 2. 7 GHz. Finally, experimental results have shown that the proposed solution can reach a high rate-distortion performance close to the reference SHVC reference software Model (SHM) with a speed-up of 37 and 66 in Intra and Inter coding configurations.
The enduser receiving the two layers decodes either the Base Layer (BL) for HD quality or both layers for UHD quality, depending on its display, energy and mobility configurations. The close-loop architecture of the SHVC extension requires the decoding of all reference layer frames to encode/decode a higher quality layer frame. This increases both encoding and decoding complexities compared to a single-layer coding A c c e p t e d M a n u s c r i p t configuration. Moreover, additional processing is introduced by the SHVC extension to rescale the reference frames used by the Enhancement Layers (EL) for inter-layer predictions. In this paper, we propose a complete solution for 4K real time SHVC codec including both SHVC encoder and decoder software. The proposed SHVC encoder, called SHVC-ATEME Encoder (SHVC-AE), is based on the professional ATEME HEVC software encoder HEVC-ATEME Encoder (HEVC-AE)  [11].
B. Real time video codecs In this section we give a brief description on the existing SVC, HEVC and SHVC encoder and decoder solutions. The software openSVC decoder  [15]  has been developed to offer an open source real time decoder solution of the SVC extension. It was developed in C language and supports the Scalable Baseline profile library offering all tools to deal with A c c e p t e d M a n u s c r i p t spatial, temporal and fidelity scalability. The openSVC decoder achieves a speed-up up to 50 times faster than the SVC reference software decoder Joint Scalable Video Model (JSVM)  [16]. Authors in  [17]  proposed a SVC video encoder dedicated to HD video conferencing applications. This encoder combines slice-level parallelism for frame encoding with block-level parallelism for the up-sampling and interpolation filter processes.
The baseline encoder is optimized in SIMD using Streaming SIMD Extensions (SSE)2 instructions. The parallel encoder enables, on a 8 cores Intel Xeon E5-2687W processor running at 3. 1 GHz, to encode a 720p30 video in real time at different bitrates. The slice partitioning introduces a slight loss in rate-distortion coding efficiency. Recently, several hardware  [18] -  [22]  and software  [12] ,  [23] -  [26]  HEVC decoders have been developed. The hardware solutions offer a fast HEVC decoder implementation enabling real time decoding of 4Kp60  [19]  and even 8Kp60  [21]  with a very low energy consumption performance  [20]. On the other hand, software HEVC decoder implementations offer flexibility, fast time-to-market and are well suited for quick adaptation to standard evolutions. In addition, software decoder can be easily optimized for several platforms, not dedicated to video processing, including Intel x86  [12]  and ARM/Neon  [26]  using SIMD instructions.
There are a number of hardware  [27]  and software  [11] ,  [28] -  [31]  implementations of the HEVC encoder. The two open source software HEVC encoders, Kvazaar and x265 , enable a real time encoding of 4K videos, with using both parallel processing (frame, tile and wavefront) and low level optimizations through SIMD instructions. In addition, these solutions use algorithmic optimizations to avoid the full ratedistortion search, especially at the level of quad-tree partitioning and intra prediction. These algorithmic optimizations enable encoding complexity reduction at the expense of bitrate increase  [32] ,  [33]. For SHVC encoder, authors in  [34]  leverage the existing correlation between layers to select the Coding Unit (CU) size at the EL by restricting the CU depth range to reduce the encoding complexity for quality scalability.
In fact, the complexity reduction opportunities offered by these solutions are around 50%, corresponding to a speedup of 2 of the reference SHVC reference software Model (SHM) encoder. However, to reach real time encoding of 4K resolution video with the SHM encoder in spatial scalability a speedup of 40 to 80 is required depending on the coding configuration (Intra/Inter). In addition, these solutions, that use coding decisions of the BL encoder at the EL encoder, can not be integrated in the context of professional encoders since as depicted in the SHVC extension only the decoded BL frame and associated MVs shall be available at the EL encoder without the coding decisions. To cope with this inconvenience, we propose an end-to-end solution that takes into account the real-time character, imperative for broadcast application.
Hence, in this paper we focus on the software implementation for real time SHVC encoder and decoder on multi-core Intel x86 platform. The SHVC encoder is based on the professional ATEME core encoder, which includes SIMD instructions for Intel x86 platform, algorithmic optimizations and parallelism. The real time SHVC decoder is based on the core HEVC decoder, openHEVC, which optimizes the most time consuming operations in SIMD for x86 platform and takes advantage of multicore processor to speed-up the decoding process through tile, wavefront and frame parallelisms. To the best of our knowledge, there is no SHVC codec, except the SHM  [39]  developed by the JCT-VC, to evaluate the proposed algorithmic contributions. In addition, this latter is not dedicated to real time processing. The SHM encoder enables a high rate-distortion performance since it relies on the full search rate-distortion optimization at the expense of coding speed.
Moreover, SHM does not include low level optimizations neither uses parallel processing. Fig. 3  illustrates the sequential architecture of the SHM encoder encoding two video layers. First, the input video is pre-processed, which corresponds to down-sampling in the spatial scalability, and then encoded with the BL encoder. The decoded BL frame is then processed by the data rescaling block to rescale BL output data. This block performs up-sampling operation of the decoded frame and MV up-scaling in spatial scalability. Finally, the EL encoder block encodes the original video with using the decoded BL input as an additional reference frame. We can notice that the SHM software performs these four main encoding operations in sequential order which would increase both the encoding time and end-to-end latency compared to a fully pipelined architecture on multi-core platform.
The OpenHEVC decoder supports the wavefront, tile and frame-based parallel processing solutions enabling to decode CTU rows, tiles and frames in parallel, respectively. The wavefront and tile parallel processing in the core OpenHEVC decoder can be activated for all SHVC layers when these two tools are enabled by the encoder, respectively. The frame based parallel decoding mechanism in the core OpenHEVC decoder has been extended to support parallel decoding of frames from different layers. Fig. 4  illustrates the frame based parallel decoding of two SHVC video layers encoded in 2× spatial scalability. In total, six frames (three at each layer) are decoded in parallel with inter and inter-layer control mechanisms to ensure that the block used as reference is available (already decoded) to perform inter and inter-layer predictions.