# Fileset

[2302.14793v2.pdf](https://mdr.nims.go.jp/filesets/349fed3d-d993-4465-a9b4-b0e488afcdf1/download)

## Creator

Evgeny Posenitskiy, Vijay Gopal Chilkuri, Abdallah Ammar, Michał Hapka, Katarzyna Pernal, Ravindra Shinde, Edgar Josué Landinez Borda, Claudia Filippi, [Kosuke Nakano](https://orcid.org/0000-0001-7756-4355), Otto Kohulák, Sandro Sorella, Pablo de Oliveira Castro, William Jalby, Pablo López Ríos, Ali Alavi, Anthony Scemama

## Rights

Copyright 2023 Author(s). This article is distributed under a Creative Commons Attribution (CC BY) License.[Creative Commons BY Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)

## Other metadata

[TREXIO: A file format and library for quantum chemistry](https://mdr.nims.go.jp/datasets/ca58bfda-446c-449c-80bc-721c16900647)

## Fulltext

TREXIO: A File Format and Library for Quantum ChemistryEvgeny Posenitskiy,1, 2 Vijay Gopal Chilkuri,1, 3 Abdallah Ammar,1 Micha l Hapka,4 Katarzyna Pernal,5 RavindraShinde,6 Edgar Josué Landinez Borda,6 Claudia Filippi,6 Kosuke Nakano,7, 8 Otto Kohulák,8, 1 Sandro Sorella,8Pablo de Oliveira Castro,9 William Jalby,9 Pablo López Ŕıos,10 Ali Alavi,10 and Anthony Scemama1, a)1)Laboratoire de Chimie et Physique Quantiques (LCPQ), Université de Toulouse (UPS) and CNRS, Toulouse,France2)Qubit Pharmaceuticals, Incubateur Paris Biotech Santé, 24 Rue du Faubourg Saint Jacques, 75014 Paris, France3)Aix Marseille Univ, CNRS, Centrale Marseille, ISM2, Marseille, France4)Faculty of Chemistry, University of Warsaw, ul. L. Pasteura 1, 02-093 Warsaw,Poland5)Institute of Physics, Lodz University of Technology, ul. Wolczanska 217/221, 93-005 Lodz,Poland6)MESA+ Institute for Nanotechnology, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands7)Research and Services Division of Materials Data and Integrated System, National Institute for Materials Science(NIMS), Tsukuba, Ibaraki 305-0047, Japan8)International School for Advanced Studies (SISSA), Via Bonomea 265, 34136, Trieste, Italy9)Université Paris-Saclay, UVSQ, LI-PaRAD10)Max Planck Institute for Solid State Research, Heisenbergstrasse 1, 70569 Stuttgart, GermanyTREXIO is an open-source file format and library developed for the storage and ma-nipulation of data produced by quantum chemistry calculations. It is designed with thegoal of providing a reliable and efficient method of storing and exchanging wave functionparameters and matrix elements, making it an important tool for researchers in the fieldof quantum chemistry. In this work, we present an overview of the TREXIO file formatand library. The library consists of a front-end implemented in the C programming lan-guage and two different back-ends: a text back-end and a binary back-end utilizing theHDF5 library which enables fast read and write operations. It is compatible with a va-riety of platforms and has interfaces for the Fortran, Python, and OCaml programminglanguages. In addition, a suite of tools has been developed to facilitate the use of theTREXIO format and library, including converters for popular quantum chemistry codesand utilities for validating and manipulating data stored in TREXIO files. The simplic-ity, versatility, and ease of use of TREXIO make it a valuable resource for researchersworking with quantum chemistry data.Keywords: quantum chemistry, data, interoperabilityI. INTRODUCTIONQuantum chemistry relies on quantum mechanics toexplain and predict the properties and behaviors ofatoms, molecules, and materials. Although density func-tional theory (DFT) is one of the most widely used ap-proaches thanks to its excellent ratio between computa-tional cost and accuracy, another important tool is wavefunction theory (WFT), which describes the behavior ofa quantum system in terms of its wave function. In orderto perform WFT calculations, it is necessary to manipu-late a large number of parameters, such as the expansioncoefficients of the wave function and the matrix elementsof the Hamiltonian operator. These parameters are typi-cally numerous and difficult to handle, making it impor-tant to have a robust and efficient method for storing andaccessing them.Reproducible research remains a challenging topic, de-spite recent advances such as the introduction of thea)Electronic mail: scemama@irsamc.ups-tlse.frFAIR (findable, accessible, interoperable, reusable) dataprinciples.1 A key aspect of reproducibility is softwareinteroperability, which refers to the ability of differentprograms to work together and exchange information,allowing different systems to communicate and exchangedata in order to function as a cohesive whole. Interop-erable software is prevalent nowadays and is a key com-ponent of the Unix philosophy.2 In Unix shells, the moststraightforward application of software interoperabilityis made through the use of the pipe operator, where theoutput of a program is the input of another program.Similarly, shell scripts are created through the composi-tion of smaller programs, exchanging data through filesor pipes.A major challenge of reproducible research is theuniformity of input/output (I/O) data within a par-ticular research domain. The Unix philosophy recom-mends the use of text files because they are architecture-independent, readable in any language, and can be readas a stream, which is useful for making programs com-municate over a network. However, storing data in a textformat can result in large file sizes and conversion fromASCII to binary format can be computationally expen-arXiv:2302.14793v2  [physics.chem-ph]  30 Mar 2023mailto:scemama@irsamc.ups-tlse.fr2sive for large data sets. To address this concern, domain-specific binary formats have been developed, such as theJoint Photographic Experts Group (JPEG) format3 fordigital images and the Moving Picture Experts Group(MPEG) format4 for videos. These binary formats areutilized through standardized application programminginterfaces (API).In the field of wave function theory such a standardformat and API is still lacking, and the purpose of theTREXIO library presented in this article is to fill thisgap. This paper is organized as follows: firstly, a briefoverview of the related work is presented. Secondly, theTREXIO format for the electronic wave functions is in-troduced together with some details concerning the inter-nal representation and the associated API. Finally, someapplications are demonstrated with a major focus on theinteroperability achieved within the TREX Center of Ex-cellence in Exascale Computing5 due to the use of theTREXIO format.II. RELATED WORKIt is worth mentioning that there have been severalefforts to unify the data formats within different subdo-mains of quantum chemistry. Probably one of the earliestworks in this direction was the definition of the Crystallo-graphic Information File (CIF) for establishing databasesof crystal structures.6 A few years later, the ChemicalMarkup Language (CML)7,8 was introduced. It is a for-mat based on the Extensible Markup Language (XML)which is used to describe chemical data: molecules, chem-ical properties, reactions, spectra, materials, etc. Withformats like CIF or CML, the burden of following a stan-dard is placed on the code writing the data. As a con-sequence, any tool that can read the format will be ableto interpret the data without needing to understand thespecific code that was used to produce it. This meansthat data can be easily shared and reused across differ-ent programs, and new tools can be developed to workwith the format without needing to know anything aboutthe code used to produce the data.Recently, the cclib Python package9, originally de-veloped for performing computational chemistry calcula-tions, has accumulated several internal converters capa-ble of parsing and transforming the output of differentprograms into the internal representation called ccData.A similar approach has been taken by the developers ofIOData10, who have implemented converters and parsersfor commonly used programs and their output files. How-ever, there is currently no unified data representation orAPI that can be integrated into quantum chemistry codesto improve interoperability. Consequently, each timea given program modifies its input/output formatting,the IOData package must be adapted accordingly andpromptly, which poses an additional challenge for main-tainers. More recently, consolidated efforts have givenrise to QCSchema11, which provides an API-like accessto data generated by existing quantum chemistry codes,thereby addressing the issue of dependence on the out-put file’s formatting style. In this case, the responsibilityfor adhering to conventions falls on the code reading thedata, as it must be aware of the conventions chosen bythe code that generated the data. With the ElectronicStructure Common Data Format (ESCDF)12 and its as-sociated library, codes that write data can supply meta-data to assist codes that read data in comprehendingthe organization of the data in the files. Hence, ESCDFaims to provide low-level tools and flexibility to facilitatethe exchange of large datasets between codes with high-performance I/O. While this greatly reduces the difficultyof understanding conventions for developers reading thedata, they may still need to apply different conversionsdepending on the code that generated the data. Conse-quently, implementing support for ESCDF may requiremore effort on the part of code developers compared tousing a standardized format such as CML.Another popular format for storing quantum chemistrydata is the Gaussian13 fchk format. While it is a propri-etary format specific to the Gaussian software package,its compatibility with several other software programshas contributed to its extensive utilization. However, theformat’s proprietary and closed-source nature preventsexternal developers from improving the format, leavingenhancements and compatibility updates solely in thehands of Gaussian developers.Recently, the mwfn14 format was introduced with theprimary goal of enhancing the existing solutions such aswfn,13 wfx,15 and Molden16 formats, which were designedto store parameters of molecular orbitals and atomic ba-sis sets in view of reconstructing the one-particle densitymatrix. Although mwfn is an improvement on these otherformats, it does not allow the user to store enough infor-mation for a wave function coming from a configurationinteraction (CI) or coupled cluster (CC) calculation.For post-Hartree-Fock calculations, the FCIDUMPformat17 has become a de facto standard because of itssimplicity. It is a text-based format that only containsminimal information for building the second-quantizedHamiltonian, namely the one- and two-electron integralsin the basis of molecular orbitals (MO), the number ofelectrons and information about the spin state and or-bital symmetries. The nuclear coordinates and basis setare not saved in FCIDUMP files. The text format makesits adoption extremely simple, but it has a very high im-pact on the performance since FCIDUMP files are usuallylarge. Although very practical, the use of the FCIDUMPformat has other important limitations than efficiency.Once a program has computed a post-Hartree-Fock wavefunction using an FCIDUMP file as an input, the parame-ters of the basis set and the molecular orbitals may havebeen lost unless they were stored in a separate file in an-other format. Although configuration interaction or cou-pled cluster calculations can be performed using FCIDUMPfiles, this format is too limited to be used for quantumMonte Carlo (QMC) calculations, which require all the3wave function parameters.The Q5Cost18–20 initiative was one of the first at-tempts aiming at standardizing the WFT data by in-troducing both a format and the API to interact with it.With Q5Cost, it was possible to store all the wave func-tion parameters of CI expansions together with the basisset, molecular orbitals, and even electron repulsion inte-grals. The Q5Cost library was relying on the HierarchicalData Format version 5 (HDF5)21 to provide efficient I/Oand keep the data well organized in the file. Neverthe-less, Q5Cost had some severe drawbacks. First, Q5Costwas written in Fortran which made its use tedious inother programming languages such as C++ or Python. Inaddition, to be able to interpret a Q5Cost file, it wasoften necessary to know which code had generated it.Indeed, most WFT codes have different conventions interms of normalization of the basis functions, ordering ofthe atomic orbitals, etc, and no conversion into a uniqueinternal representation was imposed by the library. Sothe burden of understanding conventions was still on theshoulders of the readers of the files. Finally, Q5Cost hadimportant technical limitations: the Q5Cost library wasintended to be used as a compiled Fortran module (a so-called .mod file), that depended on the compiled Fortranmodules provided by the HDF5 library. As the formatof the compiled Fortran modules is specific to the com-piler vendor and even to the version of the compiler, theQ5Cost library could not be simply linked as an externallibrary to any code. Using the Q5Cost library in a For-tran code imposed that the user’s code was compiled withthe same Fortran compiler as the one that was used tocompile both the HDF5 Fortran modules and the Q5Costlibrary. This contamination of dependencies could lead tosome important impact on the performance of the user’scode, and the only solution to solve that problem was tocompile many different versions of the HDF5 Fortran in-terface and Q5Cost library with multiple compilers andcompiler versions.The TREXIO initiative, heavily influenced by theQ5Cost project, aims to propose a standard format andlibrary for wave function calculations. This initiativeseeks to leverage the strengths of the Q5Cost project andlearn from its design flaws that hindered its widespreadadoption. One of the key improvements we aim to achieveis to shift the effort of adopting a format and conventionsto the side of the code writing the data. This way, thefiles will be easily readable without any prior knowledgeby any code, similar to CML or JPEG.III. THE TREXIO FORMATThe TREXIO format (version 2.3.0) is designed tostore all the necessary information to represent a wavefunction, including: the number of up- and down-spinelectrons, nuclear coordinates and charges, basis set andeffective core potential (ECP) parameters, atomic andmolecular orbital parameters, Slater determinants andCI coefficients, configuration state function (CSF) def-initions, and metadata related to the description of ex-cited states. It is also capable of storing data required forthe computation of the wave function, such as one- andtwo-electron integrals, numerical integration grids usedin DFT calculations, and one- and two-particle reduceddensity matrices.One notable feature of TREXIO is that it is self-contained, meaning that all the parameters needed torecreate the wave function are explicitly stored withinthe file, eliminating the need for external databases. Forexample, instead of storing the name of a basis set (suchas cc-pVDZ), the actual basis set parameters used in thecalculation are stored. All data are stored in atomic unitsfor simplicity.The data in TREXIO are organized into groups, eachcontaining multiple attributes defined by their type anddimensions. Each attribute within a group correspondsto a single scalar or array variable in a code. In whatfollows, the notation <group>.<attribute> will be usedto identify an attribute within a group. For example,nucleus.charge refers to the charge attribute in thenucleus group. It is an array of type float with dimen-sion nucleus.num, the attribute describing the numberof nuclei. For simplicity, the singular form is always usedfor the names of groups and attributes.A. Data typesSo that TREXIO can be used in any language, we usea limited number of data types. It is important to keepin mind that these types are abstract in the sense thatthey are defined independently of their implementation,and are not tied to any specific representation on a com-puter. The main data types are int for integers, floatfor floating-point values, and str for character strings.The real and imaginary parts of complex numbers arestored separately as floats. To minimize the risk of in-teger overflow and accuracy loss, numerical data typesare stored using 64-bit representations by default. How-ever, in specific cases where integers are bounded (such asorbital indices in four-index integrals), the smallest pos-sible representation is used to reduce the file size. TheAPI presented in the next section handles any necessarytype conversions.There are also two types derived from int: dim andindex. dim is used for dimensioning variables, whichare positive integers used to specify the dimensions ofan array. In the previous example, nucleus.num is adimensioning variable that specifies the dimensions ofthe nucleus.charge array. index is used for integersthat correspond to array indices, because some languages(such as C or Python) use zero-based indexing, while oth-ers (such as Fortran) use one-based indexing by default.For convenience, values of the index type are shifted byone when TREXIO is used in one-based languages to beconsistent with the semantics of the language.4Arrays can be stored in either dense or sparse formats.If the sparse format is selected, the data is stored in co-ordinate format. For example, the element A(i,j,k,l)is stored as a quadruplet of integers (i, j, k, l) alongwith the corresponding value. Typically, one- and two-dimensional arrays are stored as dense arrays, while ar-rays with higher dimensions are stored in sparse format.B. Stored dataIn this section, we provide a comprehensive overviewof the data that can be stored in TREXIO files. A com-plete list of the groups and attributes is available as sup-plementary information or in the documentation of thelibrary. In both resources, multi-dimensional arrays areexpressed in column-major order, meaning that elementsof the same column are stored contiguously.1. MetadataIn order to facilitate the archiving of TREXIO filesin open-data repositories, users have the option to storemetadata in the metadata group. This includes thenames of the codes that were used to create the file, alist of authors, and a textual description. This allows formore information about the file to be easily accessibleand transparent.2. System informationThe chemical system consists of nuclei and electrons,where the nuclei are considered as fixed point chargeswith Cartesian coordinates. The wave function is storedin the spin-free formalism,22 and therefore, it is neces-sary to explicitly store the number of spin-up (N↑) andspin-down (N↓) electrons. These numbers correspond tothe normalization of the spin-up and spin-down single-particle reduced density matrices.Certain calculations, such as DFT calculations, requirethe use of a numerical integration grid. The grid groupprovides information for storing grids, inspired by thedata required by the numgrid software.23,24To keep things simple, TREXIO can only store a singlewave function per file. When working with excited states,it is often the case that multiple states only differ in theirCI coefficients, while other parameters (such as geome-try, basis set, molecular orbitals, etc.) are the same. Tofacilitate the storage of multiple states, TREXIO pro-vides the option to store all the data needed to describeone state in a main file, along with the names of addi-tional TREXIO files that contain only the state-specificparameters.3. Basis setIn the basis group, the atomic basis set is definedas a list of shells. Each shell i is centered at a centerAi, has a specified angular momentum li, and a radialfunction Ri. The radial function is a linear combinationof Nprim i primitive functions, which can be Slater typeorbitals (STO, p = 1) or Gaussian type orbitals (GTO,p = 2). These primitive functions are parameterized byexponents γki and coefficients aki:Ri(r) = Ni|r−RAi |niNprim i∑k=1aki fki(γki, p) e−γki|r−RAi|p .(1)Different codes have different normalization practices,so it is necessary to store normalization factors in theTREXIO file to ensure that it is self-contained and doesnot rely on the client program having the ability to com-pute overlap integrals. Some codes assume that the con-traction coefficients are applied to normalized linear com-binations of primitives, so a normalization constant fkifor each primitive must also be stored. Some codes as-sume that the functions Ri are normalized, requiring thecomputation of an additional normalization factor, Ni.4. Atomic orbitalsThe ao group in TREXIO contains information relatedto the expansion of the shells in the basis set into atomicorbitals (AOs). For example, a p-shell is expanded intothree AOs: px, py, and pz. AOs are defined as follows:χi(r) = N ′i Pη(i)(r)Rs(i)(r) (2)where i is the atomic orbital index, P refers to eitherpolynomials or spherical harmonics, and s(i) specifies theshell on which the AO is expanded.η(i) denotes the chosen angular function. The AOscan be expressed using real spherical harmonics orpolynomials in Cartesian coordinates. In the caseof real spherical harmonics, the AOs are ordered as0,+1,−1,+2,−2, . . . ,+m,−m. In the case of polyno-mials, the canonical (or alphabetical) ordering is used,p : px, py, pzd : dxx, dxy, dxz, dyy, dyz, dzzf : fxxx, fxxy, fxxz, fxyy, fxyz, fxzz, fyyy, fyyz, fyzz, fzzz...Note that for p orbitals in real spherical harmonics, theordering is 0,+1,−1 which corresponds to pz, px, py.N ′i is a normalization factor that allows for differentnormalization coefficients within a single shell, as in theGAMESS25 convention where each individual function isunit-normalized. Using GAMESS convention, the nor-malization factor of the shell Nd (Eq. 1) in the basis5group is appropriate for instance for the d2z function (i.e.Nd ≡ Nz2) but not for the dxy AO, so the correctionfactor N ′i for dxy in the ao groups is the ratioNxyNz2.5. Effective core potentialsAn effective core potential (ECP) V ECPA can be used toreplace the core electrons of atom A. It can be expressedas:26V ECPA = VA`max+1 +`max∑`=0δVA`∑̀m=−`|Y`m〉〈Y`m| (3)The first term in this equation is attributed to the localchannel, while the remaining terms correspond to non-local channel projections. `max refers to the maximumangular momentum in the non-local component of theECP. The functions δVA` and VA`max+1 are parameterizedas:δVA`(r) =Nq`∑q=1βAq` |r−RA|nAq` e−αAq`|r−RA|2VA`max+1(r) = − Zeff|r−RA|+ δVA`max+1(r) (4)where Zeff is the effective nuclear charge of the center.All the parameters can be stored in the ecp group.6. Molecular orbitalsThe mo group is devoted to the storage of the molecu-lar orbitals (MOs). MO coefficients are stored in a two-dimensional array, with additional information such assymmetries or occupation numbers stored in separate ar-rays. It is also possible to store the spin to enable thedescription of unrestricted Hartree-Fock or unrestrictedKohn-Sham determinants.7. Hamiltonian matrix elementsOne-electron integrals can be stored in the AO andMO bases in the groups ao 1e int and mo 1e int, re-spectively. Similarly, two-electron integrals can be storedin the AO and MO bases in the groups ao 2e intand mo 2e int, respectively. One-electron integrals arestored as two-dimensional arrays, while two-electron in-tegrals are stored in a sparse format, with a quadruplet ofindices and the corresponding value stored for each non-zero integral. The order of the indices follows Dirac’sbra-ket notation.It is also possible to store a low-rank representation ofthe two-electron integrals, obtained via a Cholesky de-composition.8. CI expansionThe wave function Ψ can be represented as a combi-nation of Slater determinants DI :|Ψ〉 =∑ICI |DI〉 (5)In the determinant group of a TREXIO file, the defi-nition of these Slater determinants, as well as the con-figuration interaction (CI) expansion coefficients, can bestored. Each Slater determinants is represented as aWaller-Hartree double determinant,27 i.e. the product ofa determinant with ↑-spin electrons and a determinantwith ↓-spin electrons. To enable the storage of arbitraryCI expansions and to reduce the storage size, the deter-minants are stored as pairs of binary strings: one for the↑ spin sector and one for the ↓ spin. Each binary stringhas a length equal to the number of MOs, with the i-thbit set to one if and only if the i-th MO is included in thedeterminant. As the creation of these binary strings maybe tedious, we provide some helper functions to trans-form lists of orbital indices into binary strings. If theorbital indices are not in increasing order, a reorderingis made and the user is informed if a change of sign isneeded in the corresponding CI coefficient.Alternatively, the wave function may be expanded ina basis of configuration state functions (CSFs),|Ψ〉 =∑IC̃I |ψI〉 . (6)where each CSF ψI is a linear combination of Slater de-terminants. The csf group allows for the storage of theCSF expansion coefficients, as well as the matrix 〈DI |ψJ〉in a sparse format. This enables the projection of theCSFs onto the basis of Slater determinants.9. AmplitudesThe wave function may also be expressed in terms ofthe action of the cluster operator T̂ :T̂ = T̂1 + T̂2 + T̂3 + . . . (7)on a reference wave function Ψ, where T̂1 is the singleexcitation operator,T̂1 =∑iatai â†aâi, (8)T̂2 is the double excitation operator,T̂2 =14∑ijabtabij â†aâ†bâj âi, (9)etc. Indices i, j, a and b denote molecular orbital indices.6Wave functions obtained with perturbation theory orconfiguration interaction are of the form:|Φ〉 = T̂ |Ψ〉 (10)and coupled-cluster wave functions are of the form:|Φ〉 = eT̂ |Ψ〉 (11)The reference wave function Ψ is stored using thedeterminant and/or csf groups, and the amplitudes arestored using the amplitude group. The attributes withthe exp suffix correspond to exponentialized operators.10. Reduced density matricesThe reduced density matrices, stored in the rdm group,are defined in the basis of molecular orbitals.The ↑-spin and ↓-spin components of the one-bodydensity matrix are given byγ↑ij = 〈Ψ|â†jα âiα|Ψ〉 (12)γ↓ij = 〈Ψ|â†jβ âiβ |Ψ〉 (13)and the spin-summed two-body density matrix isγij = γ↑ij + γ↓ij (14)The ↑↑, ↓↓, and ↑↓ components of the two-body densitymatrix are given byΓ↑↑ijkl = 〈Ψ|â†kα â†lαâjα âiα|Ψ〉 (15)Γ↓↓ijkl = 〈Ψ|â†kβ â†lβ âjβ âiβ |Ψ〉 (16)Γ↑↓ijkl = 〈Ψ|â†kα â†lβ âjβ âiα|Ψ〉+〈Ψ|â†lα â†kβ âiβ âjα|Ψ〉, (17)and the spin-summed one-body density matrix isΓijkl = Γ↑↑ijkl + Γ↓↓ijkl + Γ↑↓ijkl. (18)11. Correlation factorsExplicit correlation factors can be introduced in thewave function, such as in QMC, F12, or transcorrelatedmethods.In the current version of the library, it is possible tostore two different types of Jastrow factors. The Jastrowfactor is an N -electron function which multiplies the ref-erence wave function expansion: Ψ = Φ× exp(J), whereJ(r,R) = JeN(r,R) + Jee(r) + JeeN(r,R). (19)In the following, we use the notations rij = |ri − rj | andRiα = |ri − Rα|, where indices i and j correspond toelectrons and α to nuclei.The first form of Jastrow factor is the one used inthe CHAMP28 program.29 JeN contains electron-nucleusterms:JeN(r,R) =Nelec∑i=1Nnucl∑α=1[a1,α fα(Riα)1 + a2,α fα(Riα)+Naord∑p=2ap+1,α [fα(Riα)]p − J∞eN](20)Jee contains electron-electron terms:Jee(r) =Nelec∑i=1i−1∑j=1[12(1 + δ↑↓ij)b1 fee(rij)1 + b2 fee(rij)+Nbord∑p=2bp+1 [fee(rij)]p − J∞ee,ij](21)where δ↑↓ij is zero when the electrons i and j have thesame spin, and one otherwise. JeeN contains electron-electron-nucleus terms:JeeN(r,R) =Nnucl∑α=1Nelec∑i=1i−1∑j=1Nord∑p=2p−1∑k=0p−k−2δk,0∑l=0clkpα [gee(rij)]k[[gα(Riα)]l+ [gα(Rjα)]l][gα(Ri α) gα(Rjα)](p−k−l)/2,(22)clkpα being non-zero only when p − k − l is even. Theterms J∞ee and J∞eN are shifts to ensure that Jee and JeNhave an asymptotic value of zero. f and g are scalingfunctions defined asfα(r) =1− e−κα rκαand gα(r) = e−κα r, (23)and the possible presence of an index α indicates thatthe scaling coefficient κ depends on the atom α.The second form of Jastrow factor is the µ Jastrowfactor30Jee(r) =Nelec∑i=1i−1∑j=1rij (1− erf(µ rij))−1µ√πe−(µ rij)2.(24)It is a single parameter correlation factor that has beenrecently introduced in the context of transcorrelatedmethods. It imposes the electron-electron cusp and isbuilt such that the leading order in 1/r12 of the effectivetwo-electron potential reproduces the long-range interac-tion of the range-separated density functional theory. Anenvelope function has then been introduced to cancel outthe Jastrow effects between two electrons when at leastone electron is close to a nucleus, and standard one-bodyterms were also introduced to avoid the expansion of theone-body density.As there exist multiple forms of Jastrow factors in theliterature, contributions to extend this section are wel-come.712. QMC dataWe also provide in the qmc group some informa-tion specific to QMC calculations. In QMC methods,the wave function is evaluated at points in the 3N -dimensional space, where N is the number of electrons.It might be convenient to store the coordinates of pointstogether with the wave function, and to store the value ofthe wave function and the local energy ĤΨ(r)/Ψ(r) eval-uated at these points, for example, to check that differentcodes give the same values.IV. THE TREXIO LIBRARYThe TREXIO library is written in the C language, andis licensed under the open-source 3-clause BSD license toallow for use in all types of quantum chemistry software,whether commercial or not.The design of the library is divided into two main sec-tions: the front-end and the back-end. The front-endserves as the interface between users and the library,while the back-end acts as the interface between the li-brary and the physical storage.A. The front-endBy using the TREXIO library, users can store andextract data in a consistent and organized manner.The library provides a user-friendly API, includingfunctions for reading, writing, and checking for theexistence of data. The functions follow the pat-tern trexio [has|read|write] <group> <attribute>,where the group and attribute specify the particular databeing accessed. It also includes an error handling mech-anism, in which each function call returns an exit codeof type trexio exit code, explaining the type of error.This can be used to catch exceptions and improve debug-ging in the upstream user application. Figures 1 and 2show examples of usage of the TREXIO library in C andPython, respectively.To ensure the consistency of the data, the attributescan only be written if all the other attributes on whichthey explicitly depend have been written. For example,as the nucleus.coord array is dimensioned by the num-ber of nuclei nucleus.num, the nucleus.coord attributecan only be written after nucleus.num. However, thelibrary is not aware of non-explicit dependencies, suchas the relation between the electron repulsion integrals(ERIs) and MO coefficients. A complete control of theconsistency of the data is therefore impossible, so theattributes were chosen to be by default immutable. Byonly allowing data to be written only once, the risk ofmodifying data in a way that creates inconsistencies isreduced. For example, if the ERIs have already beenwritten, it would be inconsistent to later modify the MO1 #include <stdio.h>2 #include <trexio.h>34 int main() {5 int num = 3; // Number of atoms6 double coord[][3] = {7 // xyz coordinates in atomic units8 0. , 0. , -0.24962655,9 0. , 2.70519714, 1.85136466,10 0. , -2.70519714, 1.85136466 };1112 trexio_exit_code rc;1314 // Open the TREXIO file15 trexio_t* f = trexio_open("water.trexio",16 'w', TREXIO_HDF5, &rc);17 if (rc != TREXIO_SUCCESS) {18 fprintf(stderr, "Error: %s\n",19 trexio_string_of_error(rc));20 return -1;21 }2223 // Write the number of nuclei24 rc = trexio_write_nucleus_num (f, num);25 if (rc != TREXIO_SUCCESS) {26 fprintf(stderr, "Error: %s\n",27 trexio_string_of_error(rc));28 return -1;29 }3031 // Write the nuclear coordinates32 rc = trexio_write_nucleus_coord (f, &coord[0][0]);33 if (rc != TREXIO_SUCCESS) {34 fprintf(stderr, "Error: %s\n",35 trexio_string_of_error(rc));36 return -1;37 }3839 // Close the TREXIO file40 rc = trexio_close(f);41 if (rc != TREXIO_SUCCESS) {42 fprintf(stderr, "Error: %s\n",43 trexio_string_of_error(rc));44 return -1;45 }46 return 0;47 }FIG. 1. C code writing the nuclear coordinates of a watermolecule in a TREXIO file, with error handling.1 import trexio2 coord = [ # xyz coordinates in atomic units3 [0. , 0., -0.24962655],4 [0. , 2.70519714, 1.85136466],5 [0. , -2.70519714, 1.85136466]6 ]7 # The Python API calls can raise `trexio.Error`8 # exceptions to be handled via try/except clauses9 # in the user application10 with trexio.File("water.trexio", 'w',11 back_end=trexio.TREXIO_HDF5) as f:12 trexio.write_nucleus_num(f, len(coord))13 trexio.write_nucleus_coord(f, coord)FIG. 2. Python code writing the nuclear coordinates of awater molecule in a TREXIO file.coefficients. To allow for flexibility, the library also al-lows for the use of an unsafe mode, in which data canbe overwritten. However, this mode carries the risk ofproducing inconsistent files, and the metadata group’sunsafe attribute is set to 1 to indicate that the file haspotentially been modified in a dangerous way. This at-tribute can be manually reset to 0 if the user is confident8that the modifications made are safe.B. The back-endAt present, TREXIO supports two back-ends: one re-lying only on the C standard library to produce plaintext files (the so-called text back-end), and one relyingon the HDF5 library.With the text back-end, the TREXIO “file” is a di-rectory containing multiple text files, one for each group.This back end is intended to be used in development envi-ronments, as it gives access to the user to standard toolssuch as diff and grep. In addition, text files are bet-ter adapted than binary files for version control systemssuch as Git, so this format can be also used for storingreference data for unit tests.HDF5 is a binary file format and library for storing andmanaging large amounts of data in a hierarchical struc-ture. It allows users to manipulate data in a way sim-ilar to how files and directories are manipulated withinthe file system. The HDF5 library provides optimal per-formance through its memory mapping mechanism andsupports advanced features such as serial and parallelI/O, chunking, and compression filters. However, HDF5files are in binary format, which requires additional toolssuch as h5dump to view them in a human-readable for-mat. HDF5 is widely used in scientific and engineeringapplications, and is known for its high performance andability to handle large data sets efficiently.The TREXIO HDF5 back-end is the recommendedchoice for production environments, as it provides highI/O performance. Furthermore, all data is stored in asingle file, making it especially suitable for parallel filesystems like Lustre. These file systems are optimized forlarge, sequential I/O operations and are not well-suitedfor small, random I/O operations. When multiple smallfiles are used, the file system may become overwhelmedwith metadata operations like creating, deleting, or mod-ifying files, which can adversely affect performance.In a benchmarking program designed to compare thetwo back-ends of the library, the HDF5 back-end wasfound to be significantly faster than the text back-end.The program wrote a wave function made up of 100 mil-lion Slater determinants and measured the time taken towrite the Slater determinants and CI coefficients. TheHDF5 back-end achieved a speed of 10.4× 106 Slater de-terminants per second and a data transfer rate of 406MB/s, while the text back-end had a speed of 1.1 × 106determinants per second and a transfer rate of 69 MB/s.These results were obtained on a DELL 960 GB mix-usesolid-state drive (SSD). The HDF5 back-end was able toachieve a performance level close to the peak performanceof the SSD, while the text back-end’s performance waslimited by the speed of the CPU for performing binaryto ASCII conversions.In addition to the HDF5 and text back-ends, it is alsopossible to introduce new back-ends to the library. Forexample, a back-end could be created to support ob-ject storage systems, such as those used in cloud-basedapplications31 or for archiving in open data repositories.To use a new back-end, only a minor modification is re-quired in the code using TREXIO: the correct back-endargument needs to be passed to the trexio open func-tion (see Figures 1 and 2).C. Supported languagesOne of the main benefits of using C as the interfacefor a library is that it is easy to use from other program-ming languages. Many programming languages, such asPython or Julia, provide built-in support for calling Cfunctions, which means that it is relatively straightfor-ward to write a wrapper that allows a library written in Cto be called from another language. In general, librarieswith a C interface are the easiest to use from other pro-gramming languages, because C is widely supported andhas a simple, stable application binary interface (ABI).Other languages, such as Fortran and C++, may havemore complex ABIs and may require more work to inter-face with them.TREXIO has been employed in codes developed in var-ious programming languages, including C, C++, Fortran,Python, OCaml, and Julia. While Julia is designed toenable the use of C functions without the need for ad-ditional manual interfacing, the TREXIO C header filewas automatically integrated into Julia programs usingthe CBindings.jl package.32 In contrast, specific bind-ings have been provided for Fortran, Python, and OCamlto simplify the user experience.In particular, the binding for Fortran is not distributedas multiple compiled Fortran module files (.mod), but in-stead as a single Fortran source file (.F90). The distribu-tion of the source file instead of the compiled module hasmultiple benefits. It ensures that the TREXIO moduleis always compiled with the same compiler as the clientcode, avoiding the compatibility problem of .mod filesbetween different compiler versions and vendors. Thesingle-file model requires very few changes in the buildsystem of the user’s codes, and it facilitates the searchfor the interface of a particular function. In addition,advanced text editors can parse the TREXIO interfaceto propose interactive auto-completion of the TREXIOfunction names to the developers.Finally, the Python module, partly generated withSWIG33 and fully compatible with NumPy,34 allowsPython users to interact with the library in a more intu-itive and user-friendly way. Using the Python interface islikely the easiest way to begin using TREXIO and under-standing its features. In order to help users get startedwith TREXIO and understand its functionality, tutorialsin Jupyter notebooks are available on GitHub (https://github.com/TREX-CoE/trexio-tutorials), and canbe executed via the Binder platform.https://github.com/TREX-CoE/trexio-tutorialshttps://github.com/TREX-CoE/trexio-tutorials9D. Source code generation and documentationSource code generation is a valuable technique thatcan significantly improve the efficiency and consis-tency of software development. By using templatesto generate code automatically, developers can avoidmanual coding and reduce the risk of errors or in-consistencies. This approach is particularly use-ful when a large number of functions follow simi-lar patterns, as in the case of the TREXIO library,where functions are named according to the patterntrexio [has|read|write] <group> <attribute>. Bygenerating these functions from the format specificationusing templates, the developers can ensure that the re-sulting code follows a consistent structure and is free fromerrors or inconsistencies.The description of the format is written in a text file inthe Org format.35 Org is a structured plain text format,containing information expressed in a lightweight markuplanguage similar to the popular Markdown language.36While Org was introduced as a mode of the GNU Emacstext editor, its basic functionalities have been imple-mented in most text editors such as Vim, Atom or VSCode.There are multiple benefits in using the Org format.The first benefit is that the Org syntax is easy to learnand allows for the insertion of equations in LATEX syntax.Additionally, Org files can be easily converted to Hyper-Text Markup Language (HTML) or Portable DocumentFormat (PDF) for generating documentation. The sec-ond benefit is that GNU Emacs is a programmable texteditor and code blocks in Org files can be executed inter-actively, similar to Jupyter notebooks. These code blockscan also manipulate data defined in tables and this fea-ture is used to automatically transform tables describ-ing groups and attributes in the documentation into aJavaScript Object Notation (JSON) file.37,38 This JSONfile is then used by a Python script to generate the neededfunctions in C language, as well as header files and somefiles required for the Fortran, Python, and OCaml inter-faces.With this approach, contributions to the developmentof the TREXIO library can be made simply by addingnew tables to the Org file, which can be submitted aspull requests on the project’s GitHub repository (https://github.com/trex-coe/trexio). Overall, this processallows for a more efficient and consistent developmentprocess and enables contributions from a wider range ofindividuals, regardless of their programming skills.E. Availability and reliabilityThe TREXIO library is designed to be portable andeasy to install on a wide range of systems. It follows theC99 standard to ensure compatibility with older systems,and can be configured with either the GNU Autotools orthe CMake build systems. The only external dependencyis the HDF5 library, which is widely available on HPCplatforms and as packages on major Linux distributions.Note that it is possible to disable the HDF5 back-endat configuration time, allowing TREXIO to operate onlywith the text back-end and have zero external dependen-cies. This can be useful for users who may not be ableto install HDF5 on certain systems.TREXIO is distributed as a tarball containing thesource code, generated code, documentation, and Fortraninterface. It is also available as a binary .deb packagefor Debian-based Linux distributions and as packages forGuix39, Spack40 and Conda.41 The Python module canbe found in the PyPI repository, the OCaml binding isavailable in the official OPAM repository, and the .debpackages are already available in Ubuntu 23.04.To ensure the reliability and quality of the TREXIOlibrary, we have adopted standard continuous integra-tion and deployment practices. For example, we use unittests that are executed automatically using GitHub ac-tions whenever modifications are made to the codebase.These tests cover a wide range of functionalities and helpto identify any potential issues or bugs in the code. Ad-ditionally, the TREXIO library is regularly used by theauthors of the present paper, and as such, it is contin-uously tested and validated in the context of ongoingresearch activities.TREXIO was built, tested and installed successfullyon 20 different architectures supported by the Debianbuild farm. Furthermore, we ensure that the quality ofour code meets the requirements of the CERT codingstandards,42 and we use the cppcheck43 tool to validatethe quality of our code. These measures demonstrate ourcommitment to ensuring that the TREXIO library is areliable and trustworthy tool.F. Open-Source Governance and Sustainability StrategiesOur approach to the development and governance ofthe TREXIO library follows the standard design of open-source projects, which typically involve a collaborativeeffort from a community of contributors. The TREX Eu-ropean Center of Excellence initiated the project and pro-posed the first functional version of the software. How-ever, we consider this to be just the starting point for alarger community effort.As an open-source project, we encourage contributionsfrom anyone interested in the development of the library.This includes not only contributions to the codebase butalso contributions to the documentation, testing, andother aspects of the project. We believe that this collab-orative approach is the key to the success of any open-source project.Regarding governance, we have a small group of main-tainers who oversee the development of the project, re-view and merge contributions, and ensure the qualityof the code. However, we strive to make the develop-ment process as transparent and open as possible, andhttps://github.com/trex-coe/trexiohttps://github.com/trex-coe/trexio10we encourage contributions from anyone interested in theproject.Overall, our strategy for the governance and develop-ment of the TREXIO library follows the standard de-sign of open-source projects, which emphasizes collabo-ration and transparency. We believe that this approach,combined with our commitment to seeking and securingfunding for the continued development and maintenanceof TREXIO, will ensure the long-term success and useful-ness of the library to the quantum chemistry community.V. EXAMPLES OF APPLICATIONSThe open-source Python package trexio tools44 hasbeen created to enhance the use of the TREXIO libraryand corresponding data format. It includes convertersfor transforming output files from codes such as Gaus-sian, GAMESS,25 or PySCF45 into TREXIO files. How-ever, in the future, it would be preferable if the devel-opers of these codes were to offer the option to exportdata in TREXIO format in order to maintain numeri-cal precision and ensure consistency in the stored data.In addition, the package includes utilities to convert cer-tain data blocks from TREXIO files into FCIDUMP orMolden formats. It also has a feature that validates theconsistency of a wave function by numerically calculat-ing overlap integrals on a grid and comparing them tothe overlap matrix stored in the file. This helps to con-firm that all basis set parameters are consistent with theconventions of the original program.TREXIO is currently used to exchange wave func-tion parameters between the selected CI code QuantumPackage46 and the QMC code CHAMP.28 The QMCcodes QMC=Chem47 and TurboRVB48 are also able toread TREXIO files, allowing for comparison of the threeQMC codes using the same wave function. TREXIO isalso used to transfer integrals between Quantum Packageand the FCIQMC code NECI,49 and to read density ma-trices produced by Quantum Package in GammCor50 forsymmetry-adapted perturbation theory (SAPT)51 molec-ular interaction calculations with near-full CI densitymatrices.52 In addition, the recent development of a codefor calculating electron repulsion integrals using Slater-type orbitals53 now produces TREXIO files, enablingFCIQMC calculations using Slater-type orbitals withNECI and similar selected CI calculations with QuantumPackage, which can then be used as trial wave functionsfor QMC calculations.VI. CONCLUSIONThe TREXIO format and library offer a convenientand flexible way to store and exchange quantum chem-istry data. Its open-source nature allows for easy inte-gration into various software applications and its com-patibility with multiple programming languages makes itaccessible to a wide range of users. The use of the HDF5library as the default back-end ensures efficient storageand retrieval of data, while the option to disable HDF5and use the text back-end allows for zero external depen-dencies. The development of TREXIO has been drivenby the need to facilitate collaboration and reproducibil-ity in quantum chemistry research, and its adoption invarious codes and projects is a testament to its useful-ness in achieving these goals. We would like to emphasizethat the TREXIO library is a work in progress, and weare committed to expanding its scope and functionalityin future releases. Our immediate priorities include sup-porting periodic boundary conditions and other basis setssuch as grids, and plane waves. Overall, the TREXIO for-mat and library is a valuable resource for the quantumchemistry community and its continued development andadoption will surely benefit the field.ACKNOWLEDGMENTSThe authors would like to thank Susi Lehtola for pro-viding valuable feedback on an earlier version of thismanuscript. This work was supported by the Euro-pean Centre of Excellence in Exascale Computing TREX— Targeting Real Chemical Accuracy at the Exas-cale. Hence, the name of the software is TREX In-put/Output (TREXIO). This project has received fund-ing from the European Union’s Horizon 2020 — Re-search and Innovation program — under grant agreementno. 952165. A CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/) public copyright license hasbeen applied by the authors to the present document andwill be applied to all subsequent versions up to the Au-thor Accepted Manuscript arising from this submission,in accordance with the grant’s open access conditions.1M. D. Wilkinson, M. Dumontier, I. J. Aalbersberg, G. Apple-ton, M. Axton, A. Baak, N. Blomberg, J.-W. Boiten, L. B.da Silva Santos, P. E. Bourne, J. Bouwman, A. J. Brookes,T. Clark, M. Crosas, I. Dillo, O. Dumon, S. Edmunds, C. T.Evelo, R. Finkers, A. Gonzalez-Beltran, A. J. G. Gray, P. Groth,C. Goble, J. S. Grethe, J. Heringa, P. A. C. ’t Hoen, R. Hooft,T. Kuhn, R. Kok, J. Kok, S. J. Lusher, M. E. Martone, A. Mons,A. L. Packer, B. Persson, P. Rocca-Serra, M. Roos, R. van Schaik,S.-A. Sansone, E. Schultes, T. Sengstag, T. Slater, G. Strawn,M. A. Swertz, M. Thompson, J. van der Lei, E. van Mulligen,J. Velterop, A. Waagmeester, P. Wittenburg, K. Wolstencroft,J. Zhao, and B. Mons, Sci. Data 3, 1 (2016).2M. D. McIlroy, E. N. Pinson, and B. A. Tague, Bell SystemTechnical Journal 57, 1899 (1978).3“JPEG image compression standard,” (2022), online; accessed22. Dec. 2022.4“Standards – MPEG,” (2022), online; accessed 22. Dec. 2022.5“Targeting Real Chemical accuracy at the EXascale,” (2023),[Online; accessed 25. Jan. 2023].6S. R. Hall, F. H. Allen, and I. D. Brown, Acta Crystallogr., Sect.A: Found. Crystallogr. 47, 655 (1991).7P. Murray-Rust and H. S. Rzepa, J. Chem. Inf. Comput. Sci. 39,928 (1999).8P. Murray-Rust and H. S. Rzepa, J. Cheminf. 3, 1 (2011).9N. M. O’boyle, A. L. Tenderholt, and K. M. Langner, J. Comput.Chem. 29, 839 (2008).https://creativecommons.org/licenses/by/4.0/https://creativecommons.org/licenses/by/4.0/http://dx.doi.org/10.1038/sdata.2016.18http://dx.doi.org/10.1002/j.1538-7305.1978.tb02135.xhttp://dx.doi.org/10.1002/j.1538-7305.1978.tb02135.xhttps://www.jpeg.org/jpeg/https://www.mpeg.org/standardshttps://www.trex-coe.euhttp://dx.doi.org/10.1107/S010876739101067Xhttp://dx.doi.org/10.1107/S010876739101067Xhttp://dx.doi.org/10.1021/ci990052bhttp://dx.doi.org/10.1021/ci990052bhttp://dx.doi.org/10.1186/1758-2946-3-44http://dx.doi.org/10.1002/jcc.20823http://dx.doi.org/10.1002/jcc.208231110T. Verstraelen, W. Adams, L. Pujal, A. Tehrani, B. D. Kelly,L. Macaya, F. Meng, M. Richer, R. Hernández-Esparza, X. D.Yang, M. Chan, T. D. Kim, M. Cools-Ceuppens, V. Chuiko,E. Vöhringer-Martinez, P. W. Ayers, and F. Heidar-Zadeh, J.Comput. Chem. 42, 458 (2021).11D. G. A. Smith, A. T. Lolinco, Z. L. Glick, J. Lee, A. Ale-naizan, T. A. Barnes, C. H. Borca, R. Di Remigio, D. L. Dotson,S. Ehlert, A. G. Heide, M. F. Herbst, J. Hermann, C. B. Hicks,J. T. Horton, A. G. Hurtado, P. Kraus, H. Kruse, S. J. R. Lee,J. P. Misiewicz, L. N. Naden, F. Ramezanghorbani, M. Scheurer,J. B. Schriber, A. C. Simmonett, J. Steinmetzer, J. R. Wagner,L. Ward, M. Welborn, D. Altarawy, J. Anwar, J. D. Chodera,A. Dreuw, H. J. Kulik, F. Liu, T. J. Mart́ınez, D. A. Matthews,H. F. Schaefer, J. Šponer, J. M. Turney, L.-P. Wang, N. De Silva,R. A. King, J. F. Stanton, M. S. Gordon, T. L. Windus, C. D.Sherrill, and L. A. Burns, J. Chem. Phys. 155, 204801 (2021).12M. J. T. Oliveira, N. Papior, Y. Pouillon, V. Blum, E. Ar-tacho, D. Caliste, F. Corsetti, S. de Gironcoli, A. M. Elena,A. Garćıa, V. M. Garćıa-Suárez, L. Genovese, W. P. Huhn,G. Huhs, S. Kokott, E. Küçükbenli, A. H. Larsen, A. Laz-zaro, I. V. Lebedeva, Y. Li, D. López-Durán, P. López-Tarifa,M. Lüders, M. A. L. Marques, J. Minar, S. Mohr, A. A. Mostofi,A. O’Cais, M. C. Payne, T. Ruh, D. G. A. Smith, J. M. Soler,D. A. Strubbe, N. Tancogne-Dejean, D. Tildesley, M. Torrent,and V. W.-z. Yu, J. Chem. Phys. 153, 024117 (2020).13M. J. Frisch, G. W. Trucks, H. B. Schlegel, G. E. Scuseria, M. A.Robb, J. R. Cheeseman, G. Scalmani, V. Barone, G. A. Peters-son, H. Nakatsuji, X. Li, M. Caricato, A. V. Marenich, J. Bloino,B. G. Janesko, R. Gomperts, B. Mennucci, H. P. Hratchian,J. V. Ortiz, A. F. Izmaylov, J. L. Sonnenberg, D. Williams-Young, F. Ding, F. Lipparini, F. Egidi, J. Goings, B. Peng,A. Petrone, T. Henderson, D. Ranasinghe, V. G. Zakrzewski,J. Gao, N. Rega, G. Zheng, W. Liang, M. Hada, M. Ehara,K. Toyota, R. Fukuda, J. Hasegawa, M. Ishida, T. Nakajima,Y. Honda, O. Kitao, H. Nakai, T. Vreven, K. Throssell, J. A.Montgomery, Jr., J. E. Peralta, F. Ogliaro, M. J. Bearpark, J. J.Heyd, E. N. Brothers, K. N. Kudin, V. N. Staroverov, T. A.Keith, R. Kobayashi, J. Normand, K. Raghavachari, A. P. Ren-dell, J. C. Burant, S. S. Iyengar, J. Tomasi, M. Cossi, J. M.Millam, M. Klene, C. Adamo, R. Cammi, J. W. Ochterski, R. L.Martin, K. Morokuma, O. Farkas, J. B. Foresman, and D. J.Fox, “Gaussian˜16,” (2016), Gaussian Inc. Wallingford CT.14T. Lu and Q. Chen, ChemRxiv (2022), 10.26434/chemrxiv-2021-lt04f-v6.15T. A. Keith, “.wfx Format Specification,” (2014), [Online; ac-cessed 27. Dec. 2022].16G. Schaftenaar and J. H. Noordik, J. Comput.-Aided Mol. Des.14, 123 (2000).17P. J. Knowles and N. C. Handy, Comput. Phys. Commun. 54,75 (1989).18S. Borini, A. Monari, E. Rossi, A. Tajti, C. Angeli, G. L. Ben-dazzoli, R. Cimiraglia, A. Emerson, S. Evangelisti, D. Maynau,J. Sanchez-Marin, and P. G. Szalay, J. Chem. Inf. Model. 47,1271 (2007).19A. Scemama, A. Monari, C. Angeli, S. Borini, S. Evangelisti,and E. Rossi, in International Conference on Computational Sci-ence and Its Applications (ICCSA 2008), Lecture Notes in Com-puter Science, Vol. 5072, edited by Gervasi, O. Murgante, andB (SPRINGER-VERLAG, Perugia, Italy, 2008) pp. 1094–1107.20E. Rossi, S. Evangelisti, A. Laganà, A. Monari, S. Rampino,M. Verdicchio, K. K. Baldridge, G. L. Bendazzoli, S. Borini,R. Cimiraglia, C. Angeli, P. Kallay, H. P. Lüthi, K. Ruud,J. Sanchez-Marin, A. Scemama, P. G. Szalay, and A. Tajti, J.Comput. Chem. 35, 611 (2014).21Q. Koziol, D. Robinson, and U. O. of Science, “Hdf5,” (2018).22R. Pauncz, Int. J. Quantum Chem. 35, 717 (1989).23R. Bast, “Numgrid: Numerical integration grid for molecules,”(2021).24J. Burkardt, “Sphere lebedev rule: Quadrature rules for the unitsphere,” (2010).25G. M. J. Barca, C. Bertoni, L. Carrington, D. Datta, N. De Silva,J. E. Deustua, D. G. Fedorov, J. R. Gour, A. O. Gunina,E. Guidez, T. Harville, S. Irle, J. Ivanic, K. Kowalski, S. S. Leang,H. Li, W. Li, J. J. Lutz, I. Magoulas, J. Mato, V. Mironov,H. Nakata, B. Q. Pham, P. Piecuch, D. Poole, S. R. Pruitt,A. P. Rendell, L. B. Roskop, K. Ruedenberg, T. Sattasathuchana,M. W. Schmidt, J. Shen, L. Slipchenko, M. Sosonkina, V. Sun-driyal, A. Tiwari, J. L. Galvez Vallejo, B. Westheimer, M. W loch,P. Xu, F. Zahariev, and M. S. Gordon, J. Chem. Phys. 152,154102 (2020).26J. R. Trail and R. J. Needs, J. Chem. Phys. 146, 204107 (2017).27R. Pauncz, Int. J. Quantum Chem. 25, 707 (1984).28C. J. Umrigar and C. Filippi, “Cornell-Holland ab-initio materi-als package (CHAMP),” (2023).29A. D. Güçlü, G. S. Jeon, C. J. Umrigar, and J. K. Jain, Phys.Rev. B 72, 205327 (2005).30E. Giner, J. Chem. Phys. 154, 084119 (2021).31J. Liu, Q. Koziol, G. F. Butler, N. Fortner, M. Chaarawi,H. Tang, S. Byna, G. K. Lockwood, R. Cheema, K. A. Kallback-Rose, D. Hazen, and M. Prabhat, in 2018 IEEE/ACM 3rd Inter-national Workshop on Parallel Data Storage & Data IntensiveScalable Computing Systems (PDSW-DISCS) (IEEE, 2018) pp.24–34.32K. Rutkowski, “Cbindings,” https://github.com/analytech-solutions/CBinding.jl (2023).33D. M. Beazley, in TCLTK’96: Proceedings of the 4th conferenceon USENIX Tcl/Tk Workshop, 1996 - Volume 4 (USENIX As-sociation, 1996) p. 15.34C. R. Harris, K. J. Millman, S. J. van der Walt, R. Gommers,P. Virtanen, D. Cournapeau, E. Wieser, J. Taylor, S. Berg,N. J. Smith, R. Kern, M. Picus, S. Hoyer, M. H. van Kerk-wijk, M. Brett, A. Haldane, J. F. del Ŕıo, M. Wiebe, P. Peter-son, P. Gérard-Marchant, K. Sheppard, T. Reddy, W. Weckesser,H. Abbasi, C. Gohlke, and T. E. Oliphant, Nature 585, 357(2020).35E. Schulte, D. Davison, T. Dye, and C. Dominik, J. Stat. Soft.46, 1 (2012).36S. Leonard, “The text/markdown Media Type,” RFC 7763(2016).37T. Bray, “The JavaScript Object Notation (JSON) Data Inter-change Format,” RFC 8259 (2017).38F. Pezoa, J. L. Reutter, F. Suarez, M. Ugarte, and D. Vrgoč,in WWW ’16: Proceedings of the 25th International Confer-ence on World Wide Web (International World Wide Web Con-ferences Steering Committee, Republic and Canton of Geneva,CHE, 2016) pp. 263–273.39L. Courtès, in European Lisp Symposium (Madrid, Spain, 2013).40T. Gamblin, M. LeGendre, M. R. Collette, G. L. Lee, A. Moody,B. R. de Supinski, and S. Futral, in SC ’15: Proceedings ofthe International Conference for High Performance Computing,Networking, Storage and Analysis (Association for ComputingMachinery, New York, NY, USA, 2015) pp. 1–12.41conda-forge community, “The conda-forge Project: Community-based Software Distribution Built on the conda Package Formatand Ecosystem,” (2015).42R. C. Seacord, The CERT® C Coding Standard, Second Edi-tion: 98 Rules for Developing Safe, Reliable, and Secure Systems(Addison-Wesley Professional, Boston, MA, USA, 2014).43“Cppcheck - A tool for static C/C++ code analysis,” (2023),[Online; accessed 23. Mar. 2023].44“Trexio tools,” (2022).45Q. Sun, X. Zhang, S. Banerjee, P. Bao, M. Barbry, N. S. Blunt,N. A. Bogdanov, G. H. Booth, J. Chen, Z.-H. Cui, J. J. Eriksen,Y. Gao, S. Guo, J. Hermann, M. R. Hermes, K. Koh, P. Ko-val, S. Lehtola, Z. Li, J. Liu, N. Mardirossian, J. D. McClain,M. Motta, B. Mussard, H. Q. Pham, A. Pulkin, W. Purwanto,P. J. Robinson, E. Ronca, E. R. Sayfutyarova, M. Scheurer,H. F. Schurkus, J. E. T. Smith, C. Sun, S.-N. Sun, S. Upad-hyay, L. K. Wagner, X. Wang, A. White, J. D. Whitfield, M. J.Williamson, S. Wouters, J. Yang, J. M. Yu, T. Zhu, T. C. Berkel-http://dx.doi.org/10.1002/jcc.26468http://dx.doi.org/10.1002/jcc.26468http://dx.doi.org/ 10.1063/5.0059356http://dx.doi.org/ 10.1063/5.0012901http://dx.doi.org/10.26434/chemrxiv-2021-lt04f-v6http://dx.doi.org/10.26434/chemrxiv-2021-lt04f-v6http://aim.tkgristmill.com/wfxformat.htmlhttp://dx.doi.org/10.1023/A:1008193805436http://dx.doi.org/10.1023/A:1008193805436http://dx.doi.org/10.1016/0010-4655(89)90033-7http://dx.doi.org/10.1016/0010-4655(89)90033-7http://dx.doi.org/10.1021/ci7000567http://dx.doi.org/10.1021/ci7000567http://dx.doi.org/ 10.1007/978-3-540-69839-5_83http://dx.doi.org/ 10.1007/978-3-540-69839-5_83http://dx.doi.org/10.1002/jcc.23492http://dx.doi.org/10.1002/jcc.23492http://dx.doi.org/10.11578/dc.20180330.1http://dx.doi.org/10.1002/qua.560350607http://dx.doi.org/10.5281/zenodo.1470276https://people.sc.fsu.edu/~jburkardt/c_src/sphere_lebedev_rule/sphere_lebedev_rule.htmlhttps://people.sc.fsu.edu/~jburkardt/c_src/sphere_lebedev_rule/sphere_lebedev_rule.htmlhttp://dx.doi.org/10.1063/5.0005188http://dx.doi.org/10.1063/5.0005188http://dx.doi.org/10.1063/1.4984046http://dx.doi.org/10.1002/qua.560250409https://www.utwente.nl/en/tnw/ccp/research/CHAMPhttps://www.utwente.nl/en/tnw/ccp/research/CHAMPhttp://dx.doi.org/10.1103/PhysRevB.72.205327http://dx.doi.org/10.1103/PhysRevB.72.205327http://dx.doi.org/10.1063/5.0044683http://dx.doi.org/10.1109/PDSW-DISCS.2018.00005http://dx.doi.org/10.1109/PDSW-DISCS.2018.00005http://dx.doi.org/10.1109/PDSW-DISCS.2018.00005https://github.com/analytech-solutions/CBinding.jlhttps://github.com/analytech-solutions/CBinding.jlhttp://dx.doi.org/10.5555/1267498.1267513http://dx.doi.org/10.5555/1267498.1267513http://dx.doi.org/10.1038/s41586-020-2649-2http://dx.doi.org/10.1038/s41586-020-2649-2http://dx.doi.org/ 10.18637/jss.v046.i03http://dx.doi.org/ 10.18637/jss.v046.i03http://dx.doi.org/10.17487/RFC7763http://dx.doi.org/10.17487/RFC8259http://dx.doi.org/10.17487/RFC8259http://dx.doi.org/ 10.1145/2872427.2883029http://dx.doi.org/ 10.1145/2872427.2883029https://hal.inria.fr/hal-00824004http://dx.doi.org/10.1145/2807591.2807623http://dx.doi.org/10.1145/2807591.2807623http://dx.doi.org/10.1145/2807591.2807623http://dx.doi.org/10.5281/zenodo.4774216http://dx.doi.org/10.5281/zenodo.4774216http://dx.doi.org/10.5281/zenodo.4774216https://books.google.fr/books?id=441tAwAAQBAJ&source=gbs_book_similarbookshttps://books.google.fr/books?id=441tAwAAQBAJ&source=gbs_book_similarbookshttps://cppcheck.sourceforge.iohttps://github.com/TREX-CoE/trexio_tools12bach, S. Sharma, A. Yu. Sokolov, and G. K.-L. Chan, J. Chem.Phys. 153, 024109 (2020).46Y. Garniron, T. Applencourt, K. Gasperich, A. Benali, A. Ferté,J. Paquier, B. Pradines, R. Assaraf, P. Reinhardt, J. Toulouse,P. Barbaresco, N. Renon, G. David, J.-P. Malrieu, M. Véril,M. Caffarel, P.-F. Loos, E. Giner, and A. Scemama, J. Chem.Theory Comput. 15, 3591 (2019).47A. Scemama, M. Caffarel, E. Oseret, and W. Jalby, J. Comput.Chem. 34, 938 (2013).48K. Nakano, C. Attaccalite, M. Barborini, L. Capriotti, M. Ca-sula, E. Coccia, M. Dagrada, C. Genovese, Y. Luo, G. Mazzola,A. Zen, and S. Sorella, J. Chem. Phys. 152, 204121 (2020).49K. Guther, R. J. Anderson, N. S. Blunt, N. A. Bogdanov, D. Cle-land, N. Dattani, W. Dobrautz, K. Ghanem, P. Jeszenszki,N. Liebermann, G. L. Manni, A. Y. Lozovoi, H. Luo, D. Ma,F. Merz, C. Overy, M. Rampp, P. K. Samanta, L. R. Schwarz,J. J. Shepherd, S. D. Smart, E. Vitale, O. Weser, G. H. Booth,and A. Alavi, J. Chem. Phys. 153, 034107 (2020).50K. Pernal, M. Hapka, M. Przybytek, M. Modrzejewski, andA. Sokó l, “Gammcor code,” .51B. Jeziorski, R. Moszyński, and K. Szalewicz, Chem. Rev. 94,1887 (1994).52M. Hapka, M. Przybytek, and K. Pernal, J. Chem. Theory Com-put. 17, 5538 (2021).53M. Caffarel, J. Chem. Phys. 151, 064101 (2019).Appendix A: Table of stored dataTABLE I: List of all the data that can be stored in TREXIO files. The name ofthe group is written in the first line of each block. Multi-dimensional arrays areexpressed in column-major order, meaning that elements of the same column arestored contiguously.Attribute Type Dimensions Descriptionmetadatacode num dim Number of codes used to produce the filecode str (metadata.code num) Names of the codes usedauthor num dim Number of authors of the fileauthor str (metadata.author num) Names of the authors of the filepackage version str TREXIO version used to produce the filedescription str Text describing the content of fileunsafe int 1: true, 0: falsenucleusnum dim Number of nucleicharge float (nucleus.num) Charges of the nucleicoord float (3,nucleus.num) Coordinates of the atomslabel str (nucleus.num) Atom labelspoint group str Symmetry point grouprepulsion float Nuclear repulsion energygriddescription str Details about the used quadratures can go hererad precision float Radial precision parameternum dim Number of grid pointsmax ang num int Maximum number of angular grid pointsmin ang num int Minimum number of angular grid pointscoord float (grid.num) Discretized coordinate spaceweight float (grid.num) Grid weights according to a given partitioning (e.g. Becke)ang num dim Number of angular integration pointsang coord float (grid.ang num) Discretized angular spaceang weight float (grid.ang num) Angular grid weightsrad num dim Number of radial integration pointsrad coord float (grid.rad num) Discretized radial spacerad weight float (grid.rad num) Radial grid weightselectronnum dim Number of electronsup num int Number of ↑-spin electronsdn num int Number of ↓-spin electronsstatenum dim Number of states (including the ground state)id int Index of the current state (0 is ground state)current label str Label of the current statelabel str (state.num) Labels of all statesfile name str (state.num) Names of the TREXIO files linked to the current onebasistype str Type of basis set: “Gaussian” or “Slater”prim num dim Total number of primitivesshell num dim Total number of shellsnucleus index index (basis.shell num) One-to-one correspondence between shells and atomic indicesshell ang mom int (basis.shell num) One-to-one correspondence between shells and angular momentashell factor float (basis.shell num) Normalization factor of each shell (Ns)r power int (basis.shell num) Power to which r is raised (ns)shell index index (basis.prim num) One-to-one correspondence between primitives and shell indexexponent float (basis.prim num) Exponents of the primitives (γks)coefficient float (basis.prim num) Coefficients of the primitives (aks)prim factor float (basis.prim num) Normalization coefficients for the primitives (fks)e cut float Energy cut-off for plane-wave calculationsecpmax ang mom plus 1 int (nucleus.num) `max + 1, in the removed core orbitalsz core int (nucleus.num) Number of core electrons to remove per atomnum dim Total number of ECP functions for all atoms and all values of `ang mom int (ecp.num) One-to-one correspondence between ECP items and `nucleus index index (ecp.num) One-to-one correspondence between ECP items and the atom indexexponent float (ecp.num) αAq` all ECP exponentscoefficient float (ecp.num) βAq` all ECP coefficientshttp://dx.doi.org/10.1063/5.0006074http://dx.doi.org/10.1063/5.0006074http://dx.doi.org/ 10.1021/acs.jctc.9b00176http://dx.doi.org/ 10.1021/acs.jctc.9b00176http://dx.doi.org/ 10.1002/jcc.23216http://dx.doi.org/ 10.1002/jcc.23216http://dx.doi.org/10.1063/5.0005037http://dx.doi.org/10.1063/5.0005754https://github.com/pernalk/GAMMCORhttp://dx.doi.org/10.1021/cr00031a008http://dx.doi.org/10.1021/cr00031a008http://dx.doi.org/10.1021/acs.jctc.1c00344http://dx.doi.org/10.1021/acs.jctc.1c00344http://dx.doi.org/10.1063/1.511470313power int (ecp.num) nAq` all ECP powersaocartesian int 1: true, 0: falsenum dim Total number of atomic orbitalsshell index (ao.num) Basis set shell for each AOnormalization float (ao.num) Normalization factors N ′ao 1e intoverlap float (ao.num,ao.num) 〈p|q〉kinetic float (ao.num,ao.num) 〈p|T̂e|q〉potential n e float (ao.num,ao.num) 〈p|V̂ne|q〉ecp float (ao.num,ao.num) 〈p|V̂ecp|q〉core hamiltonian float (ao.num,ao.num) 〈p|ĥ|q〉overlap im float (ao.num,ao.num) 〈p|q〉 (imaginary part)kinetic im float (ao.num,ao.num) 〈p|T̂e|q〉 (imaginary part)potential n e im float (ao.num,ao.num) 〈p|V̂ne|q〉 (imaginary part)ecp im float (ao.num,ao.num) 〈p|V̂ECP|q〉 (imaginary part)core hamiltonian im float (ao.num,ao.num) 〈p|ĥ|q〉 (imaginary part)ao 2e interi float sparse (ao.num,ao.num,ao.num,ao.num) Electron repulsion integralseri lr float sparse (ao.num,ao.num,ao.num,ao.num) Long-range electron repulsion integralseri cholesky num dim Number of Cholesky vectors for ERIeri cholesky float sparse (ao.num,ao.num,ao 2e int.eri cholesky num) Cholesky decomposition of the ERIeri lr cholesky num dim Number of Cholesky vectors for long range ERIeri lr cholesky float sparse (ao.num,ao.num,ao 2e int.eri lr cholesky num) Cholesky decomposition of the long range ERImotype str String to identify the set of MOs (HF, Natural, Local, CASSCF, etc)num dim Number of MOscoefficient float (ao.num,mo.num) MO coefficientscoefficient im float (ao.num,mo.num) MO coefficients (imaginary part)class str (mo.num) Choose among: Core, Inactive, Active, Virtual, Deletedsymmetry str (mo.num) Symmetry in the point groupoccupation float (mo.num) Occupation numberenergy float (mo.num) For canonical MOs, corresponding eigenvaluespin int (mo.num) For UHF wave functions, 0 is α and 1 is βmo 1e intoverlap float (mo.num,mo.num) 〈i|j〉kinetic float (mo.num,mo.num) 〈i|T̂e|j〉potential n e float (mo.num,mo.num) 〈i|V̂ne|j〉ecp float (mo.num,mo.num) 〈i|V̂ECP|j〉core hamiltonian float (mo.num,mo.num) 〈i|ĥ|j〉overlap im float (mo.num,mo.num) 〈i|j〉 (imaginary part)kinetic im float (mo.num,mo.num) 〈i|T̂e|j〉 (imaginary part)potential n e im float (mo.num,mo.num) 〈i|V̂ne|j〉 (imaginary part)ecp im float (mo.num,mo.num) 〈i|V̂ECP|j〉 (imaginary part)core hamiltonian im float (mo.num,mo.num) 〈i|ĥ|j〉 (imaginary part)mo 2e intseri float sparse (mo.num,mo.num,mo.num,mo.num) Electron repulsion integralseri lr float sparse (mo.num,mo.num,mo.num,mo.num) Long-range electron repulsion integralseri cholesky num dim Number of Cholesky vectors for ERIeri cholesky float sparse (mo.num,mo.num,mo 2e int.eri cholesky num) Cholesky decomposition of the ERIeri lr cholesky num dim Number of Cholesky vectors for long range ERIeri lr cholesky float sparse (mo.num,mo.num,mo 2e int.eri lr cholesky num) Cholesky decomposition of the long range ERIdeterminantnum dim readonly Number of determinantslist int special (determinant.num) List of determinants as integer bit fieldscoefficient float buffered (determinant.num) Coefficients of the determinants from the CI expansioncsfnum dim readonly Number of CSFscoefficient float buffered (csf.num) Coefficients CI of the CSF expansiondet coefficient float sparse (determinant.num,csf.num) Projection on the determinant basisamplitudesingle float sparse (mo.num,mo.num) Single excitation amplitudessingle exp float sparse (mo.num,mo.num) Exponentialized single excitation amplitudesdouble float sparse (mo.num,mo.num,mo.num,mo.num) Double excitation amplitudesdouble exp float sparse (mo.num,mo.num,mo.num,mo.num) Exponentialized double excitation amplitudestriple float sparse (mo.num,mo.num,mo.num,mo.num,mo.num,mo.num) Triple excitation amplitudestriple exp float sparse (mo.num,mo.num,mo.num,mo.num,mo.num,mo.num) Exponentialized triple excitation amplitudesquadruple float sparse (mo.num,mo.num,mo.num,mo.num Quadruple excitation amplitudes,mo.num,mo.num,mo.num,mo.num)quadruple exp float sparse (mo.num,mo.num,mo.num,mo.num Exponentialized quadruple excitation amplitudes,mo.num,mo.num,mo.num,mo.num)rdm1e float (mo.num,mo.num) One body density matrix1e up float (mo.num,mo.num) ↑-spin component of the one body density matrix1e dn float (mo.num,mo.num) ↓-spin component of the one body density matrix2e float sparse (mo.num,mo.num,mo.num,mo.num) Two-body reduced density matrix (spin trace)2e upup float sparse (mo.num,mo.num,mo.num,mo.num) ↑↑ component of the two-body reduced density matrix2e dndn float sparse (mo.num,mo.num,mo.num,mo.num) ↓↓ component of the two-body reduced density matrix2e updn float sparse (mo.num,mo.num,mo.num,mo.num) ↑↓ component of the two-body reduced density matrix2e cholesky num dim Number of Cholesky vectors2e cholesky float sparse (mo.num,mo.num,rdm.2e cholesky num) Cholesky decomposition of the two-body RDM (spin trace)142e upup cholesky num dim Number of Cholesky vectors ↑↑2e upup cholesky float sparse (mo.num,mo.num,rdm.2e upup cholesky num) Cholesky decomposition of the two-body RDM (↑↑)2e dndn cholesky num dim Number of Cholesky vectors ↓↓2e dndn cholesky float sparse (mo.num,mo.num,rdm.2e dndn cholesky num) Cholesky decomposition of the two-body RDM (↓↓)2e updn cholesky num dim Number of Cholesky vectors ↑↓2e updn cholesky float sparse (mo.num,mo.num,rdm.2e updn cholesky num) Cholesky decomposition of the two-body RDM (↑↓)jastrowtype string Type of Jastrow factor: CHAMP or Muee num dim Number of electron-electron parametersen num dim Number of electron-nucleus parameters, per nucleuseen num dim Number of electron-electron-nucleus parameters, per nucleusee float (jastrow.ee num) Electron-electron parametersen float (jastrow.en num) Electron-nucleus parameterseen float (jastrow.een num) Electron-electron-nucleus parametersen nucleus index (jastrow.en num) Nucleus relative to the eN parametereen nucleus index (jastrow.een num) Nucleus relative to the eeN parameteree scaling float κ value in CHAMP Jastrow for electron-electron distancesen scaling float (nucleus.num) κ value in CHAMP Jastrow for electron-nucleus distancesqmcnum dim Number of 3N-dimensional pointspoint float (3,electron.num,qmc.num) 3N-dimensional pointspsi float (qmc.num) Wave function evaluated at the pointse loc float (qmc.num) Local energy evaluated at the points TREXIO: A File Format and Library for Quantum Chemistry Abstract I Introduction II Related work III The TREXIO format A Data types B Stored data 1 Metadata 2 System information 3 Basis set 4 Atomic orbitals 5 Effective core potentials 6 Molecular orbitals 7 Hamiltonian matrix elements 8 CI expansion 9 Amplitudes 10 Reduced density matrices 11 Correlation factors 12 QMC data IV The TREXIO library A The front-end B The back-end C Supported languages D Source code generation and documentation E Availability and reliability F Open-Source Governance and Sustainability Strategies V Examples of applications VI Conclusion  Acknowledgments A Table of stored data