Introduction (analogy to basis set database files)
Many programs have a database of basis sets stored in a file such as the following (so that users can just specify in their input file something like H:STO-2G
to get the STO-2G
basis set for the H atom):
H:STO-2G
# STO-2G Minimal Basis (2 functions/AO)
0.1309756377D+01 0.2331359749D+00
0.4301284983D+00
0.6789135305D+00
HE:STO-2G
# STO-2G Minimal Basis (2 functions/AO)
0.2432879285D+01 0.4330512863D+00
0.4301284983D+00
0.6789135305D+00
A proposed format for a geometry database file
My group has made something similar for geometries: a database with about 62,000 geometries, and interfaces to PySCF, OpenMolcas, Psi4, CFOUR, Dalton, and MRCC (so far) so that users can just put something like:
geometry = C33H53N5O9:GW5000.v2
in the program's input file to use v2 (version 2) of the GW5000 geometry of the $\ce{C33H53N5O9}$ molecule, rather than copying-and-pasting the 100-line XYZ file with the risk of human error and making the input file maybe 10x longer than it needs to be!
The current format for the geometry database file is such as that each entry looks as follows:
NAME = C33H53N5O9:GW5000.v0
# Number of atoms: 100
# Common name: Unknown
# InChI=1S/C33H53N5O9/c1-20(47-29(2,3)4)22(23(39)35-31(7,8)25(41)37-33(11,12)27(43)45-13)34-24(40)30(5,6)36-26(42)32(9,10)38-28(44)46-19-21-17-15-14-16-18-21/h14-18,20,22H,19H2,1-13H3,(H,34,40)(H,35,39)(H,36,42)(H,37,41)(H,38,44)/t20-,22+/m1/s1
# SMILES : COC(=O)C(NC(=O)C(NC(=O)[C@H]([C@H](OC(C)(C)C)C)NC(=O)C(NC(=O)C(NC(=O)OCc1ccccc1)(C)C)(C)C)(C)C)(C)C
# SMARTS: Unknown
# Reference code: QIXLEO
# CAS number: Unknown
# Source paper: https://doi.org/10.1038/s41597-020-0385-y (Stuke et al.)
# Source data host: https://doi.org/10.14459/2019mp1507656
# Source download link: https://dataserv.ub.tum.de/index.php/s/m1507656 , Filename: df_5k.json
# Source method: def2-TZVPP/PBE+TS-vdW
# Properties: Number of electrons = 123, Spin multiplicity = Singlet, Electronic state = Ground, Charge = 0, Point group = Unknown
# Notes: IR spectroscopy has been done in (2010) Dehghany M, et al.
# Date first added: 2023-02-04 14:14:48 (by Walter Kohn Jr.)
# Date modified: 2023-04-05 12:01:18 (by Walter Kohn Jr.)
# Date modified: 2023-04-06 19:03:26 (by Nike Dattani)
# Date last modified: 2023-04-07 03:01:58 (by Nike Dattani)
H 37.13229674 36.52932952 30.63502894
H 37.87447083 34.45373990 31.61484874
H 38.29175516 34.28685128 29.88425431
H 39.43188162 36.70033091 26.00124438
C 36.88232957 40.90658315 31.61111721
...
Parts of the proposed format that "need" to be kept
Since every line that starts with the #
character is a "comment", we really only need the NAME
and the XYZ lines, but the following information in the "comments" is extremely useful:
Number of atoms
allows us to quickly find all 30-atom molecules (for example)Common name
allows us to quickly find all stored geometries for "butane" (for example)Source paper
andSource data host
andSource download link
/Filename
are crucial for "reproducibility" and crediting the papers from which certain geometries originate.Source method
is "crucial" for reproducibility and it tells us whether it's an experimental geometry from, for example, microwave spectroscopy (quite reliable) or a theoretical geometry from STO-2G/Hartree-Fock (very reliable).
Parts of the proposed format that are more questionable
InChI
,SMILES
,SMARTS
,Reference code
, andCAS number
seem useful, since so many different molecules can have the same chemical formula, and might not have a "common name". However, it seems that there's so many molecular identifiers, for example here you can see that there's an "EINECS" number, a "Beilstein" number, an "RN" number, an "MDL number" several "DBID" numbers, and much more that I could include here, including different "types" of SMILES formats. It seems that at least one specifier in addition to the chemical formula and "common name" must be provided, but which one?- The
Date added
andDate modified
comments aren't strictly necessary because the revision history would ideally be visible from GitHub, but it doesn't seem harmful to include this information here (it's not like we have to choose which information to include form dozens of options, as was the case in the previous bullet point). However, maybe we only need the firstDate added
and the lastDate modified
?
Parts of the proposed format that I would like to keep, but am not sure how to include them in the best way
- Some of the
Properties
are quite important (e.g. charge, spin, and electronic state), since they tell the user which keywords to use when doing an electronic structure calculation, for example. This information could even go in theNAME
variable, which can really be anything (it doesn't need to be the chemical formula), and you might even think this would be better than the format I currently have, so I welcome feedback on that. One reason why I included the "number of electrons" was so that I can easily get a rough idea of how hard a calculation with this molecule would be, but this isn't strictly necessary. The "point group" was included for similar reasons, for example if I wanted to do a study on only linear molecules.
What format do you think would be best?
If you think any part of my proposed format can be improved (for example, removing unnecessary information, or adding more useful information, or making a change like C33H53N5O9:GW5000.v2
to C33H53N5O9_GW5000.(v2)
), please paste it in a code block!