dataesr/scientific-paragraphs-categorization huggingface dataset:
IV. THE TREXIO LIBRARY The TREXIO library is written in the C language, and is licensed under the open-source 3-clause BSD license to allow for use in all types of quantum chemistry software, whether commercial or not. The design of the library is divided into two main sections: the front-end and the back-end. The front-end serves as the interface between users and the library, while the back-end acts as the interface between the library and the physical storage. A. The front-end By using the TREXIO library, users can store and extract data in a consistent and organized manner. The library provides a user-friendly API, including functions for reading, writing, and checking for the existence of data. The functions follow the pattern trexio [has|read|write] <group> <attribute>, where the group and attribute specify the particular data being accessed.
It also includes an error handling mechanism, in which each function call returns an exit code of type trexio exit code, explaining the type of error. This can be used to catch exceptions and improve debugging in the upstream user application. Figures  1  and 2  show examples of usage of the TREXIO library in C and Python, respectively. To ensure the consistency of the data, the attributes can only be written if all the other attributes on which they explicitly depend have been written. For example, as the nucleus. coord array is dimensioned by the number of nuclei nucleus. num, the nucleus. coord attribute can only be written after nucleus. num. However, the library is not aware of non-explicit dependencies, such as the relation between the electron repulsion integrals (ERIs) and MO coefficients.
The HDF5 back-end was able to achieve a performance level close to the peak performance of the SSD, while the text back-end's performance was limited by the speed of the CPU for performing binary to ASCII conversions. In addition to the HDF5 and text back-ends, it is also possible to introduce new back-ends to the library. For example, a back-end could be created to support object storage systems, such as those used in cloud-based applications  31  or for archiving in open data repositories. To use a new back-end, only a minor modification is required in the code using TREXIO: the correct back-end argument needs to be passed to the trexio open function (see Figures  1  and 2 ).
C. Supported languages One of the main benefits of using C as the interface for a library is that it is easy to use from other programming languages. Many programming languages, such as Python or Julia, provide built-in support for calling C functions, which means that it is relatively straightforward to write a wrapper that allows a library written in C to be called from another language. In general, libraries with a C interface are the easiest to use from other programming languages, because C is widely supported and has a simple, stable application binary interface (ABI). Other languages, such as Fortran and C++, may have more complex ABIs and may require more work to interface with them. TREXIO has been employed in codes developed in various programming languages, including C, C++, Fortran, Python, OCaml, and Julia.
While Julia is designed to enable the use of C functions without the need for additional manual interfacing, the TREXIO C header file was automatically integrated into Julia programs using the CBindings. jl package. 32 In contrast, specific bindings have been provided for Fortran, Python, and OCaml to simplify the user experience. In particular, the binding for Fortran is not distributed as multiple compiled Fortran module files (. mod), but instead as a single Fortran source file (. F90). The distribution of the source file instead of the compiled module has multiple benefits. It ensures that the TREXIO module is always compiled with the same compiler as the client code, avoiding the compatibility problem of. mod files between different compiler versions and vendors. The single-file model requires very few changes in the build system of the user's codes, and it facilitates the search for the interface of a particular function.
In addition, advanced text editors can parse the TREXIO interface to propose interactive auto-completion of the TREXIO function names to the developers. Finally, the Python module, partly generated with SWIG  33  and fully compatible with NumPy,  34  allows Python users to interact with the library in a more intuitive and user-friendly way. Using the Python interface is likely the easiest way to begin using TREXIO and understanding its features. In order to help users get started with TREXIO and understand its functionality, tutorials in Jupyter notebooks are available on GitHub (https: //github. com/TREX-CoE/trexio-tutorials), and can be executed via the Binder platform.
D. Source code generation and documentation Source code generation is a valuable technique that can significantly improve the efficiency and consistency of software development. By using templates to generate code automatically, developers can avoid manual coding and reduce the risk of errors or inconsistencies. This approach is particularly useful when a large number of functions follow similar patterns, as in the case of the TREXIO library, where functions are named according to the pattern trexio [has|read|write] <group> <attribute>. By generating these functions from the format specification using templates, the developers can ensure that the resulting code follows a consistent structure and is free from errors or inconsistencies. The description of the format is written in a text file in the Org format.
35 Org is a structured plain text format, containing information expressed in a lightweight markup language similar to the popular Markdown language. 36 hile Org was introduced as a mode of the GNU Emacs text editor, its basic functionalities have been implemented in most text editors such as Vim, Atom or VS Code. There are multiple benefits in using the Org format. The first benefit is that the Org syntax is easy to learn and allows for the insertion of equations in L A T E X syntax. Additionally, Org files can be easily converted to Hyper-Text Markup Language (HTML) or Portable Document Format (PDF) for generating documentation. The second benefit is that GNU Emacs is a programmable text editor and code blocks in Org files can be executed interactively, similar to Jupyter notebooks. These code blocks can also manipulate data defined in tables and this feature is used to automatically transform tables describing groups and attributes in the documentation into a JavaScript Object Notation (JSON) file.
37, 38 This JSON file is then used by a Python script to generate the needed functions in C language, as well as header files and some files required for the Fortran, Python, and OCaml interfaces. With this approach, contributions to the development of the TREXIO library can be made simply by adding new tables to the Org file, which can be submitted as pull requests on the project's GitHub repository (https: //github. com/trex-coe/trexio). Overall, this process allows for a more efficient and consistent development process and enables contributions from a wider range of individuals, regardless of their programming skills.
E. Availability and reliability The TREXIO library is designed to be portable and easy to install on a wide range of systems. It follows the C99 standard to ensure compatibility with older systems, and can be configured with either the GNU Autotools or the CMake build systems. The only external dependency is the HDF5 library, which is widely available on HPC platforms and as packages on major Linux distributions. Note that it is possible to disable the HDF5 back-end at configuration time, allowing TREXIO to operate only with the text back-end and have zero external dependencies. This can be useful for users who may not be able to install HDF5 on certain systems. TREXIO is distributed as a tarball containing the source code, generated code, documentation, and Fortran interface. It is also available as a binary.
deb package for Debian-based Linux distributions and as packages for Guix 39 , Spack  40  and Conda. 41 The Python module can be found in the PyPI repository, the OCaml binding is available in the official OPAM repository, and the. deb packages are already available in Ubuntu 23. 04. To ensure the reliability and quality of the TREXIO library, we have adopted standard continuous integration and deployment practices. For example, we use unit tests that are executed automatically using GitHub actions whenever modifications are made to the codebase. These tests cover a wide range of functionalities and help to identify any potential issues or bugs in the code. Additionally, the TREXIO library is regularly used by the authors of the present paper, and as such, it is continuously tested and validated in the context of ongoing research activities.
F. Open-Source Governance and Sustainability Strategies Our approach to the development and governance of the TREXIO library follows the standard design of opensource projects, which typically involve a collaborative effort from a community of contributors. The TREX European Center of Excellence initiated the project and proposed the first functional version of the software. However, we consider this to be just the starting point for a larger community effort. As an open-source project, we encourage contributions from anyone interested in the development of the library. This includes not only contributions to the codebase but also contributions to the documentation, testing, and other aspects of the project. We believe that this collaborative approach is the key to the success of any opensource project.
V. EXAMPLES OF APPLICATIONS The open-source Python package trexio tools  44  has been created to enhance the use of the TREXIO library and corresponding data format. It includes converters for transforming output files from codes such as Gaussian, GAMESS,  25  or PySCF 45 into TREXIO files. However, in the future, it would be preferable if the developers of these codes were to offer the option to export data in TREXIO format in order to maintain numerical precision and ensure consistency in the stored data. In addition, the package includes utilities to convert certain data blocks from TREXIO files into FCIDUMP or Molden formats. It also has a feature that validates the consistency of a wave function by numerically calculating overlap integrals on a grid and comparing them to the overlap matrix stored in the file.
This helps to confirm that all basis set parameters are consistent with the conventions of the original program. TREXIO is currently used to exchange wave function parameters between the selected CI code Quantum Package  46  and the QMC code CHAMP. 28 The QMC codes QMC=Chem  47  and TurboRVB 48 are also able to read TREXIO files, allowing for comparison of the three QMC codes using the same wave function. TREXIO is also used to transfer integrals between Quantum Package and the FCIQMC code NECI,  49  and to read density matrices produced by Quantum Package in GammCor 50 for symmetry-adapted perturbation theory (SAPT)  51  molecular interaction calculations with near-full CI density matrices. 52 In addition, the recent development of a code for calculating electron repulsion integrals using Slatertype orbitals  53  now produces TREXIO files, enabling FCIQMC calculations using Slater-type orbitals with NECI and similar selected CI calculations with Quantum Package, which can then be used as trial wave functions for QMC calculations.
VI. CONCLUSION The TREXIO format and library offer a convenient and flexible way to store and exchange quantum chemistry data. Its open-source nature allows for easy integration into various software applications and its compatibility with multiple programming languages makes it accessible to a wide range of users. The use of the HDF5 library as the default back-end ensures efficient storage and retrieval of data, while the option to disable HDF5 and use the text back-end allows for zero external dependencies. The development of TREXIO has been driven by the need to facilitate collaboration and reproducibility in quantum chemistry research, and its adoption in various codes and projects is a testament to its usefulness in achieving these goals. We would like to emphasize that the TREXIO library is a work in progress, and we are committed to expanding its scope and functionality in future releases.
ACKNOWLEDGMENTS The authors would like to thank  Susi Lehtola  for providing valuable feedback on an earlier version of this manuscript. This work was supported by the  European Centre of Excellence in Exascale Computing TREX -Targeting Real Chemical Accuracy at the Exascale. Hence , the name of the software is TREX Input/Output (TREXIO). This project has received funding from the  European Union 's  Horizon 2020 -Research and Innovation program  -under grant agreement no. 952165. A CC-BY 4. 0  (https://creativecommons. org/licenses/by/4. 0/)public copyright license has been applied by the authors to the present document and will be applied to all subsequent versions up to the Author Accepted Manuscript arising from this submission, in accordance with the grant's open access conditions.
JHEP07(2023)138 software packages on which we depend. Individual groups or members have received support from ARC and ARDC (Australia); Minciencias (Colombia); AvH Foundation (Germany); EPLANET, Marie Skłodowska-Curie Actions and ERC (European Union); A*MIDEX, ANR, IPhU and Labex P2IO, and Région Auvergne-Rhône-Alpes (France); Key Research Program of Frontier Sciences of CAS, CAS PIFI, CAS CCEPP, Fundamental Research Funds for the Central Universities, and Sci. & Tech. Program of Guangzhou (China); GVA, XuntaGal, GENCAT and Prog. Atracción Talento, CM (Spain); SRC (Sweden); the Leverhulme Trust, the Royal Society and UKRI (United Kingdom).
Ground-state geometry optimizations All the geometry optimizations have been performed with the Gaussian 16 program package. 17  2. 1. 1 Gas phase structures. Because these complexes correlate with the ground state of the closed-shell Po 4+ ion, the ground states of Po IV systems are generally also closed-shell ones. Therefore, any single-reference method such as Møller-Plesset perturbation theory at second order (MP2),  [18] [19] [20] [21] [22]  coupled cluster with single, double and perturbative triple excitations (CCSD(T))  23, 24  or restricted Kohn-Sham density functional theory (DFT) with an appropriate exchange-correlation functional such as the almighty B3LYP  [25] [26] [27] [28]  one should in principle be capable of converging on the right ground state and on qualitatively correct molecular structures by optimisation.
Note that for computing the energy levels with EPCISO, the SA-CASSCF, SC-NEVPT2 and FIC-NEVPT2 electronic energies have been stored. 2. 2. 2 Spin-orbit energy levels. All the computations of the energy levels, i. e. all the SOC calculations, have been performed with EPCISO. 16  This code starts over MOLCAS  35  which is used to compute both the integrals and also the SA-CASSCF orbitals. Unlike ORCA, MOLCAS uses a different set of SA orbitals for each block. In this work, we have used the SA-CASSCF orbitals of the S = 1 block. EPCISO performs a configuration interaction (CI) (it can also add some perturbation theory), which can be done at both the spin-orbit free or at the SOCI level. In all the reported SOC calculations, the diagonal of the CI matrix was dressed with the previous ORCA energies, be them the SA-CASSCF, SC-NEVPT2 or the FIC-NEVPT2 ones.
Acknowledgements This work has been supported by the  MITI of CNRS  ( 80|Prime  project  MSM4Po ). HPC resources from the  CCIPL  ('' Centre de calcul intensif   des Pays de la Loire '') have been used. FR and VV acknowledge support from the  PIA   ANR  project  CaPPA  ( ANR-11-LABX-0005-01 ),  I-SITE ULNE  projects  OVERSEE and MESONM International Associated Laboratory (LAI )  ( ANR-16-IDEX-0004 ), and the  French Ministry of Higher Education and Research, region Hauts de France council  and  European Regional Development Fund (ERDF)  projects  CPER CLIMIBIO  and  WaveTech.
2011) , then reported as a massive brown dwarf adding absolute astrometry  (Feng et al. 2022) , and finally identified as a low-mass star by adding relative astrometry data  (Philipot et al. 2023). In this paper, we study the proper motion anomalies of the stars observed with the HARPS/ESO spectrograph, with the aim of detecting new substellar companions. We also combine the available RV data and absolute astrometry with HIPPARCOS.
Selection of systems with a substellar companion For the selected sample of stars, we then retrieved all the RV measurements available in the public archives of 12 different spectrographs (see below) and analyzed them to identify the presence of companion(s). For this step, we used the DPASS genetic algorithm 1  (Lagrange et al. 2019)  to detect periodicity in the data and make a rapid estimate of the orbital properties and the minimum mass of the companion(s). We thus find 20 multiple systems (two or more companions) and 80 single systems (one companion). Then, we selected the systems for which the orbital parameters of the companion are properly determined and the mass is lower than about 80 M Jup , corresponding to substellar companions. To do so, we combined the RV data with astrometry to determine the orbital inclination of the companion and obtain its 1 DPASS uses an evolutionary algorithm to fit RV data with one or more Keplerian orbits.
This algorithm converges to the solution corresponding to the smallest root-mean-square (hereafter rms) of the RV residuals. true mass. We used a Markov chain Monte Carlo (MCMC) algorithm to estimate the uncertainties of the different parameters. In the first step, we used the orvara (Orbits Using Radial Velocity, Absolute, and/or Relative Astrometry) algorithm  (Brandt et al. 2021d) , which enables the RV data to be combined with the absolute astrometry and the available HCI data. Orvara converges faster than most other algorithms  (Brandt et al. 2021c ) and enables us to quickly estimate the orbital parameters and mass of the companion and exclude stellar companions. However,  Lagrange et al. (2023)  have shown that, when the orbital period is not well covered by the RV data points, MCMC algorithms have difficulties exploring very eccentric solutions.
Radial velocity data We used the archival data obtained with the HARPS spectrograph available in the European Southern Observatory (ESO) archives 2. To characterize as well as possible the different systems, we combined the HARPS data with all other publicly available RV data points. We retrieved from the literature the data obtained with the University College London Echelle Spectrograph  (UCLES, Diego et al. 1990 ), the Lick Observatory Hamilton Echelle Spectrometer  (Lick, Vogt 1987) , the Automated Planet Finder (APF,  Vogt et al. 2014) , the Coudé Echelle Spectrometer  (CES, Enard 1982)  long camera (LC) and very long camera (VLC), the Magellan Inamori Kyocera Echelle spectrograph (MIKE,  Bernstein et al. 2003) , the Carnegie Planet Finder Spectrograph (PFS,  Crane et al. 2010) , the High-Resolution Spectrograph (HRS,  Tull 1998) , and the High-Resolution Echelle Spectrometer (HIRES,  Vogt et al.
1994). We retrieved from the DACE archive 3  the data obtained with the CORALIE echelle spectrograph  (Queloz et al. 1999 ) and from the Observatoire de Haute-Provence (OHP) archive 4  the data obtained with the ELODIE  (Baranne et al. 1996)  and SOPHIE  (Perruchot et al. 2008)  spectrographs. For the 53 systems with a characterized companion, the considered RV datasets are listed in Appendix B (Table  B. 1). Due to a major optical fiber upgrade in 2015  (Lo Curto et al. 2015) , an RV offset may be present between HARPS data obtained before and after this upgrade. We, therefore, separated these data into two different sets as if they were obtained from two different instruments. We labeled the datasets obtained before May 19, 2015 "H03" and the datasets obtained after June 3, 2015 "H15". As for HARPS, a major upgrade has been performed on the HIRES  (Tal-Or et al.
2019 ) and SOPHIE  (Bouchy et al. 2013 ) spectrographs and two major upgrades have been performed on the CORALIE spectrograph  (Ségransan et al. 2010). We labeled the HIRES datasets obtained A107, page 2 of 71  Philipot, F. , et al. : A&A, 678, A107 (2023)  Table  1. Characteristics of the reduced HCI observations.
Star Date obs. Instrument Filter NDIT×DIT(s)×Nframe ( * ) Seeing ( ′′ ) Airmass τ 0 (ms) (a)  Notes. ( * ) NDIT is the number of sub-integration within a DIT. DIT is the detector integration time per frame. τ 0 corresponds to the coherence time. before and after August 7, 2004 "Hir94" and "Hir04", respectively, the SOPHIE datasets obtained before and after June 17, 2011 "SOPHIE" and "SOPHIE+", respectively, and the CORALIE datasets obtained before June 2007, between June 2007 and November 2014, and after November 2014 "C98", "C07", and "C14", respectively.
2017 ) using tools provided in the ESO data reduction and handling pipeline  (Pavlov et al. 2008). Due to the stellar nature of the companion, its point spread function (PSF) on the residual image provided by angular differential imaging (ADI) based algorithms using the science sequence is completely saturated and prevents any fitting of it. We thus chose to extract the astrometry of the companion using the off-axis unsaturated PSF frames of the primary star taken before and after the coronographic sequence. We created a 4D dataset containing only the PSF frames. We used a simple No-ADI algorithm embedded into the SPHERE speckle calibration tool (SPECAL) software Notes. Since the companion of HD 93351 is binary, we considered the average separation in RA and Dec of the two companions. (Galicher et al.
2018 ) installed in the SPHERE data center. The astrometry and photometry were extracted by SPECAL from the residual stack produced by the No-ADI reduction, taking into account the neutral density filter used during the off-axis calibration frames (ND_3. 5). The separations and position angles (hereafter SEP and PA) found for the new detections can be retrieved in Table  2. For GJ 680, HD 101198, HD 111031, HD 195564, HD 221146, and HIP 113201 , we used the separations and position angles published in the literature. All considered relative astrometry values are summarized in Table  B. 2.
Orbit fitting We used our MCMC algorithm presented in  Philipot et al. (2023)  to fit the RV and/or relative astrometry and/or absolute astrometry data, assuming Keplerian orbits. Our tool is based on the emcee 3. 0 Python package  (Foreman-Mackey et al. 2013). We used the HTOF package  (Brandt et al. 2021d)   + ∆ 2 pa σ 2 pa (1 -ρ 2 sep,pa ) + 2ρ sep,pa * ∆ sep * ∆ pa σ sep σ pa (1 -ρ 2 sep,pa ) (1) LLH 2 RV = -0. 5 *        ∆ 2 RV σ 2 RV + jitter 2 + log(σ 2 err + jitter 2 )        (2) LLH 2 HG = (µ H,o -μ -pµ H ) T C -1 H (µ H,o -μ -pµ H ) + (µ HG,o -μ -pµ HG ) T C -1 HG (µ HG,o -μ -pµ HG ) + (µ G,o -μ -pµ G ) T C -1 G (µ G,o -μ -pµ G ), (3) where ∆ sep , ∆ pa , and ∆ RV are the difference between the measured and predicted separations, the position angle, and the RV. ρ sep,pa is the correlation coefficient between the separation and the position angle measurement.
σ sep , σ pa , and σ err correspond to the uncertainty on the measured separation, the PA, and the RV, respectively. σ RV is the variance in the RV, and jitter is the stellar jitter measured. For the likelihood of the proper motions measurements, µ x,o and µ x correspond to the predicted and observed proper motion, p is the parallax, C -1 x is the inverse of the covariance matrix, and μ corresponds to the center-of-mass motion of the system's barycenter. Unlike orvara or other similar packages, our code uses modular arithmetic computations for angles, wherever appropriate, to alleviate artifacts at the range boundaries. To minimize multimodality effects, the MCMC code uses a mix of move functions, in particular the Differential Evolution (DE) move function suggested in the Emcee package documentation for these situations  (Foreman-Mackey et al.