dataesr/scientific-paragraphs-categorization huggingface dataset:
In the framework of the COmbination Service for Time-variable Gravity fields (COST-G) gravity field solutions from different analysis centres are combined to provide a consolidated solution of improved quality and robustness to the user. As in many other satellite-related sciences, the correct application of background models plays a crucial role in gravity field determination. Therefore, we publish a set of data of various commonly used forces in orbit and gravity field modelling (Earth's gravity field, tides etc. ) evaluated along a one day orbit arc of GRACE, together with auxiliary data to enable easy comparisons. The benchmark data is compiled with the GROOPS software by the Institute of Geodesy (IfG) at Graz University of Technology. It is intended to be used as a reference data set and provides the opportunity to test the implementation of these models at various institutions involved in orbit and gravity field determination from satellite tracking data.
In view of the COST-G GRACE and GRACE Follow-On gravity field combinations, we document the outcome of the comparison of the background force models for the Bernese GNSS software from AIUB (Astronomical Institute, University of Bern), the EPOS software of the German Research Centre for Geosciences (GFZ), the GINS software, developed and maintained by the Groupe de Recherche de Géodésie Spatiale (GRGS), the GRACE-SIGMA software of the Leibniz University of Hannover (LUH) and the GRASP software also developed at LUH. We consider differences in the force modelling for GRACE (-FO) which are one order of magnitude smaller than the accelerometer noise of about 10 -10 m s -2 to be negligible and formulate this as a benchmark for new analysis centres, which are interested to contribute to the COST-G initiative.
Introduction The correct application of background models plays a crucial role in many satellite-related sciences, such as orbit and gravity field determination. Nowadays not only one software is used to perform such tasks but various institutions around the world have set up their own processing schemes based on their in-house developed software packages. In order to minimise systematic differences caused by a diverse handling of well established models, for example, background force models, the effort of comparing software implementations is picked up regularly. Software comparisons are always a useful tool for detecting inconsistencies or even bugs in software implementations. In the framework of the COST-G  (Jäggi et al. , 2020)  gravity field solutions from different analysis centres (ACs) are combined to offer a consolidated solution of improved quality, robustness and reliability to the user.
As the example of several services, like the International GNSS Service  (Johnston et al. , 2017)  and the International Laser Ranging Service  (Pearlman et al. , 2002) , showed, combining solutions from various institutions, which are computed by different and independent software packages, leads to improved results. The COST-G initiative was formally established in 2019 and op-Published by Copernicus Publications on behalf of the European Geosciences Union. erationally provides state-of-the-art monthly global gravity models from the Gravity Recovery And Climate Experiment (GRACE,  Tapley et al. , 2004) , GRACE Follow-On  (Landerer et al. , 2020)  and Swarm  (Friis-Christensen et al. , 2006). COST-G is a product centre of the International Gravity Field Service (IGFS) under the umbrella of the International Association of Geodesy  (IAG).
Modelling background forces is vital to gravity field determination, especially when the time variable part is considered. Therefore, we publish a set of data of various commonly used forces in orbit and gravity field modelling evaluated along a one day orbit arc of GRACE, together with auxiliary data to enable easy comparisons. This data set is intended to be used as a reference data set and provides the opportunity to test the implementation of these models in various software packages. The COST-G consortium consists at the time of writing of ACs and further candidate ACs. Thus, we took the opportunity to test several software packages available within the COST-G consortium, which are the Bernese GNSS software  (Dach et al. , 2015)  from AIUB (Astronomical Institute, University of Bern), EPOS  (Zhu et al.
, 2004)  of the German Research Centre for Geosciences (GFZ), the GINS software, developed and maintained by the Groupe de Recherche de Géodésie Spatiale (GRGS), the GRACE-SIGMA  (Koch et al. , 2020)  software of the Leibniz University of Hannover (LUH) and the GRASP software  (Weigelt et al. , 2013)  from LUH. Furthermore, we use this reference data to set a benchmark for new analysis centres, which are interested to contribute to the COST-G initiative. The paper is organised in five sections, where Sect. 2 introduces the data set used and published in this study. Section 3 summarises the evaluation of each force model, intended to be easily comprehensible for programming. We discuss the result of a force comparison for one software package in more detail in Sect. 4 and give the summarised outcome of the comparisons for all COST-G ACs and candidate ACs.
Benchmark data set The benchmark data set was compiled at the Institute of Geodesy (IfG) at Graz University of Technology. It consists of several accelerations a spacecraft experiences, evaluated along a given orbit, which are commonly used in orbit and gravity field determination. The models that describe the accelerations are evaluated along a one day GRACE orbit arc (integrated for 3 July 2008 using Encke's method, see  Ellmer and Mayer-Gürr (2017)  for more information on the integration) using the GROOPS software. The orbit has a 30 s sampling and is given in cartesian coordinates expressed in both Terrestrial Reference Frame (TRF), where ITRF2014  (Altamimi et al. , 2016)  is used, and the Celestial Reference Frame (CRF), where ICRF2  (Fey et al. , 2009)  is taken. The evaluations yield three dimensional accelerations for each sampling point at the location of the spacecraft.
These accelerations are the main product of the benchmark data set. The underlying models are listed in Table  1. All resulting accelerations are expressed in the CRF, the gravity field is additionally given in TRF. For each acceleration one file is provided. Accelerations consisting of several components, such as ocean tides, are provided in separate files for the largest constituents. Each file provides time stamps in GPS time (expressed in Modified Julian Date  [MJD] ) and the respective x, y, z-accelerations. As the definition of frames may vary between different software packages (J2000, true system of epoch), the orbit is given in the terrestrial and the celestial reference frame, and additionally, the rotation between the two underlying frames is provided as quaternions and rotation matrices.
Summary of each force In this section we give a few notes on each force in the benchmark data set. All formulae correspond with the IERS 2010 conventions  (Petit and Luzum, 2010) , however, they are provided in the way they are coded in the Bernese GNSS software. All constants can be found in the IERS 2010 conventions and the corresponding model descriptions. When referring to the equations from the IERS 2010 conventions we use the notation Eq. IERS (n. n) to provide good reading flow.
The point of calculating the potential is defined by the spherical coordinates with the radius r, the co-latitude ϑ and the geographical longitude λ. a E defines the reference radius of the Earth, GM E the gravitational constant multiplied with the mass of the Earth. Both are associated with the gravity field model and can be found in the header of EIGEN-6C4 data file. Equation 3 corresponds to Eq. IERS (6. 1). The accelerations and the potential are related by a r,λ,ϑ = ∇V , (4) with ∇ being the gradient operator. The accelerations in cartesian coordinates can be obtained by a transformation of Earth-fixed (r, λ, ϑ)-frame to (x, y, z)-frame. We refer to  Heiskanen and Moritz (1967)  for a detailed derivation of the expression of the Earth's gravity field in spherical harmonics.
Ocean tides Two different models are provided for the ocean tides: EOT11a  (Savcenko and Bosch, 2011 ) and FES2014b (Carrere et al. , 2016). Both are based on IfG's conversion of the corresponding grids to spherical harmonic coefficients. EOT11a is evaluated from degree 2 to 120, FES2014b from degree 2 to 180. EOT11a consists of 18 tidal frequencies, FES2014b of 34. Furthermore, the data set provides linear admittances, a short description and a MATLAB routine of their application. The spherical harmonics coefficients can be computed from the given prograde (c cos nm,f , s cos nm,f ) and retrograde (c sin nm,f , s sin nm,f ) coefficients in a sum over all tidal frequencies f using c nm = f cos(θ f )c cos nm,f + sin(θ f )c sin nm,f s nm = f cos(θ f )s cos nm,f + sin(θ f )s sin nm,f , (17) In this representation the Doodson-Warburg correction (see Table  IERS  6.
The relativistic accelerations in the benchmark data are the sum of the three components a relativistic = a Schwarzschild + a Lense Thirring + a de Sitter. ( ) 22 3. 6 Dealiasing AOD1B RL06  (Dobslaw et al. , 2017)  is used as dealiasing product. The "glo" dataset, which is the sum of the atmospheric and oceanic contribution, is evaluated in the benchmark data. The degree one coefficients are not taken into account, it is evaluated from degree 2 to 180. The spherical harmonic synthesis of the dealiasing model follows Eqs. 3 and 4, additionally, as the data set is given in three hour sets, a linear interpolation between the neighbouring sets at time t 1 and t 2 is performed on the level of spherical harmonic coefficients to obtain the spherical harmonic coefficients at time. 23). t i (t 1 ≤ t i ≤ t 2 ) (Eq c nm = c nm (t 1 ) t 2 -t i t 2 -t 1 + c nm (t 2 ) t i -t 1 t 2 -t 1 s nm = s nm (t 1 ) t 2 -t i t 2 -t 1 + s nm (t 2 ) t i -t 1 t 2 -t 1 (23).
Comparisons within COST-G The benchmark data set was created, used and examined within the COST-G initiative, where AIUB, GFZ, GRGS and IfG are currently acting as COST-G ACs. LUH is a candidate AC. To augment the combination effort and in particular to rule out large systematic differences in the implementation of background force models, all contributing groups performed a comparison with the benchmark data using their own software packages. This includes the Bernese GNSS software (AIUB), EPOS (GFZ), GINS (GRGS), GROOPS (IfG), GRACE-SIGMA (LUH) and GRASP (LUH). The intention of this comparison is to test the implementation and handling of the background models in each software package. Every software tries to reproduce the reference accelerations as closely as possible by employing the provided rotation between TRF and CRF.
Bernese GNSS software The Bernese GNSS software is a scientific software package, used by more than 700 institutions around the world. It features space geodetic applications, mainly high-precision, multi-GNSS data processing for ground networks (e. g. ,  Prange et al. , 2017)  as well as precise satellite orbit determination and thereof deriving gravity field solutions (e. g. ,  Meyer et al. , 2016). The software is developed, maintained and distributed at AIUB. In its core it employs the Celestial Mechanics Approach of orbit determination, be it for high or low flying Earth orbiting satellites or planetary geodetic applications  (Arnold et al. , 2015). The software is written in Fortran.
EPOS The Earth Parameter and Orbit System (EPOS 2  ) is a software package designed and used for operational Precise Orbit Determination (POD). It consists of tools for data orbit analysis, orbit integration, orbit improvement, orbit predictions, normal equation handling and simulation of observations, as well as for gravity field computation. It served and serves numerous satellite missions, such as Mir, Space Shuttle, LAGEOS, CHAMP, GRACE, GOCE, GRACE-FO, Swarm, TerraSAR-X, TanDEM-X, Envisat or Jason, being able to deal with SLR, GPS, DORIS, radar altimeter or GRACE K-Band-Ranging data. EPOS is based on the dynamic approach of orbit modelling and EPOS is one of the software of the current COST-G ACs that is written in Fortran. EPOS is developed, maintained and used at GFZ, and has also been installed at a few other institutions around Europe.
GRACE-SIGMA The GRACE-SIGMA (GRACE-Satellite orbit Integration and Gravity field analysis in MAtlab) software is a recent development specifically designed for the processing of GRACE and GRACE-FO data. The software is developed at Institut für Erdmessung (IfE) of LUH. It is written entirely in MATLAB and uses strongly vectorised modules for modelling of disturbing forces, orbit propagation and orbit improvement. The integration of satellite ephemerides and state and sensitivity matrices is performed using an efficient in-house developed numerical integration approach  (Naeimi, 2018). The gravity field estimation is based on a generalized dynamic orbit determination using variational equations. The software is applied for the computation of monthly GRACE and GRACE-FO gravity field solutions  (Koch et al.
GRASP The GRAvity Satellite Processing engine (GRASP) software is dedicated to gravity field recovery from kinematic positions of satellites  (Weigelt et al. , 2013). It uses the acceleration approach of orbit modelling, thus, the kinematic positions are numerically differentiated twice in order to make them express a quantity directly related to the force field that is acting on the satellite. GRASP is developed at LUH and written in MATLAB.
GROOPS The Gravity Recovery Object Oriented Programming System (GROOPS) used at IfG is a software suite for geodetic applications. Its feature set includes the determination of GNSS orbits, clocks and ground station networks  (Strasser et al. , 2019) , static and time-variable gravity field solutions from satellite data, and regional gravity field modeling with terrestrial data. GROOPS is written in C++ and makes heavy use of low level Basic Linear Algebra Subprograms (BLAS) and LAPACK (Linear Algebra PACKage) subroutines. It uses the Message Passing Interface (MPI) communication protocol for parallelization and is therefore capable to run on large distributed systems. GROOPS software serves as a reference within these software comparisons as the benchmark data set was compiled using the capabilities of GROOPS.
Example results using the Bernese GNSS Software To show the results of the software comparison for all provided force models, we evaluate all force models with the Bernese GNSS software and compute the norm of the difference vector between the benchmark accelerations and the accelerations from Bernese. We expect the magnitude of the differences to be small as the handling of the background forces is supposed to be generally compatible. Figure  2  shows that the largest differences result for the solid Earth tides, the smallest for the relativistic effects. Generally, the magnitude of differences is close to the numerical precision of 64 bit arithmetic of about 16 decimal places  (IEEE-754, 1985).
Results from COST-G Each of the above mentioned institutions performed the software comparison with the benchmark data. EPOS and GINS currently contribute only with a subset of forces, whereas all others accomplished the comparison for all accelerations provided in the reference data set. The limit for the difference in evaluating the models along the reference orbit was set to 10 -11 m s -2 , thus, at least one order of magnitude lower than the accelerometer noise in the high-precision axes of GRACE  (Touboul et al. , 1999). As an absolute threshold, this limit does not take into account that the different forces influence orbit and gravity field solutions in a different way. Thus, for instance, a relatively large difference does not necessarily map to a final solution. Furthermore, we formulate this data set and a threshold of 10 -11 m s -2 as a benchmark for new analysis centres which are interested to contribute to the COST-G initiative.
The performance is shown in Fig. 3 , the dashed black line marks the threshold. A result below that line is considered to agree with the benchmark data sufficiently well. All COST-G ACs and candidate ACs fulfill the requirement of 10 -11 m s -2 for the tested accelerations. Consequently, we consider systematic errors related to the application of background forces to be eliminated to the extent possible when compared to the GRACE observation precision. The solid Earth tides, due to its complexity, turned out to be the most challenging acceleration of the benchmark data set. Every software in the comparison delivers differences slightly above the numerical precision.
Conclusions We test and publish benchmark data of forces commonly used for gravity field and orbit determination purposes. The data set consists of orbital positions and accelerations evaluated along a one-day GRACE orbital arc. It is intended to enable fundamental software comparisons and bug detection and shall serve as a valuable contribution to the community. It is potentially interesting to any user of space geodetic software but especially to those groups where a solution is created from individual software packages by combination. The benchmark data was examined with the software packages currently used in the COST-G service. These packages agree with each other in the usage of the background models at a level of less than 10 -11 m s -2. Further influences, such as the use of a set of different Earth rotation parameters, on the accelerations are scheduled for further investigations.
Acknowledgements. The study was performed in the framework of  COST-G  and the corresponding international team that is receiving support from the  International Space Science Institute (ISSI) in Bern, Switzerland. Financial support. This research has been supported by the  Swiss National Science Foundation (SNSF)  (grant no. 200021_175942 ). Review statement. This paper was edited by  Katrin Bentel  and reviewed by two anonymous referees.
This paper introduces Pyjamask, a new block cipher family and authenticated encryption proposal submitted to the NIST lightweight cryptography standardization process. Pyjamask targets side-channel resistance as one of its main goal. More precisely, it strongly minimizes the number of nonlinear gates used in its internal primitive in order to allow efficient masked implementations, especially for high-order masking in software. Compared to other block ciphers, our proposal has thus among the smallest number of binary AND computations per input bit at the time of writing. Even though Pyjamask minimizes such an important criterion, it remains rather lightweight and efficient, thanks to a general bitslice construction that enables to computation of all nonlinear gates in parallel. For authenticated encryption, we adopt the provably secure AEAD mode OCB which has been extensively studied and has the benefit to offer full parallelization.
Of course, other block cipher-based modes can be considered as well if other performance profiles are to be targeted. The paper first gives the specification of the Pyjamask block cipher and the associated AEAD proposal. We also provide a detailed design rationale for the block cipher which is guided by our aim of software efficiency in the presence of high-order masking. The security of the design is analyzed against most commonly known cryptanalysis techniques. We finally describe efficient (masked) implementations in software and provide implementation results with aggressive performances for masking of very high orders (up to 128). We also provide a rough estimation of the hardware performances which remain much better than those of an AES round-based implementation.
Pseudo-code We give hereafter some high-level pseudo-code for the encryption, decryption and key schedule algorithms. The Load primitive loads a 4r-byte input (plaintext or ciphertext) into an r-row state as described above, with r ∈ {3, 4}. The Unload primitive consists in the inverse operation. The KeySchedule algorithm takes a 16-byte key (denoted key) and produces a table of 15 round keys (denoted roundkey[0 : 14]), each round key being made of r rows of the key state. The AddRoundKey, SubBytes and MixRows primitives are the round transformations as defined above. The inverse of the two latter transformations are further denoted InvSubBytes and InvMixRows. The Pyjamask-96 and Pyjamask-128 encryption of plaintext under key proceeds as follows (Algorithm 1): Key State M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M M.
Choice of the Diffusion Matrices To choose the diffusion matrices, we have run a probabilistic search in a particular subspace fitting the constraints of the ciphers, and simply picked five matrices that ranked best in terms of implementation sizes. To elaborate on the actual subspace, we first recall the constraints imposed by the design (refer to Subsection 2. 1). The matrices have to be defined over F 2 and must be of dimension 32. In terms of security, we would like them to achieve the best possible branch number  [Dae95]. Looking at the best known linear codes of these dimensions, one knows that the best theoretically achievable minimum distance is 16  [Gra07, Bro98]. However, one does not know any linear code that reaches that bound: the best achievable one has minimum distance 12. Consequently, in the choice of the diffusion matrices for the Pyjamask block cipher, we looked for 32 × 32 binary diffusion matrices with branch number 12.
• M 1 , M 0 , and M 2 when the input difference of all active Sboxes in Round 1 is 0x2. • M 0 , M 2 , and M 1 when the input difference of all active Sboxes in Round 1 is 0x4. In the end, MiniPyjamask-96 is a 32-bit linear code and the most efficient differential characteristic can be found by searching for the propagation with the lowest Hamming weight. Because the input size is only 32 bits, exhaustive search is feasible. As a result, we found a 5-round propagation with weight 43, which is shown below. 00a04e67 (wt11) M1 -→ a900010a (wt7) M0 -→ 2040b886 (wt9) M2 -→ 04010c62 (wt7) M1 -→ 0a3a0841 (wt9) M0 -→ d22a6797 This corresponds to the differential characteristic with probability 2 -2×43 = 2 -86 of Pyjamask-96. To be precise, the corresponding differential characteristic for Pyjamask-96 is given in Table  7.
Implementation This section focuses on the implementation aspects of Pyjamask. We describe efficient implementations in software based on a bitslice strategy and in the presence of masking. We also provide implementation results on a Cortex-M4 processor and compare the masking performance of Pyjamask to AES-128. We finally give some estimations of the performances in hardware which show that, although optimized for (masked) software implementation, Pyjamask is still fairly lightweight in hardware.
In the speed-optimized setting (variant v2) the iteration of the main loop are processed by pairs (i, i + 1). The shares A i , B i , C i , A i+1 , B i+1 , C i+1 are kept in CPU registers during the whole pair of iterations (i, i + 1). This is made possible by only keeping the address of the state and by hardcoding the mapping between the indexes of the state rows and the operands A, B and C. We hence need one instance of the ISW MACC per MACC instruction in the Sbox (i. e. 3 for Pyjamask-96 and 4 for Pyjamask-128). This variant (v2) is hence faster but slightly heavier in code size. Source Code. The software source code of Pyjamask block cipher is available at: https://github. com/pyjamask-cipher.