Community efforts in the computational molecular sciences (CMS) are evolving toward modular, open, and interoperable interfaces that work with existing community codes to provide more functionality and composability than could be achieved with a single program. The Quantum Chemistry Common Driver and Databases (QCDB) project provides such capability through an application programming interface (API) that facilitates interoperability across multiple quantum chemistry software packages. In tandem with the Molecular Sciences Software Institute and their Quantum Chemistry Archive ecosystem, the unique functionalities of several CMS programs are integrated, including CFOUR, GAMESS, NWChem, OpenMM, Psi4, Qcore, TeraChem, and Turbomole, to provide common computational functions, i.e., energy, gradient, and Hessian computations as well as molecular properties such as atomic charges and vibrational frequency analysis. Both standard users and power users benefit from adopting these APIs as they lower the language barrier of input styles and enable a standard layout of variables and data. These designs allow end-to-end interoperable programming of complex computations and provide best practices options by default.
REFERENCES
The finite difference and vibrational analysis procedures have been extracted from PSI4 as an independent module in QCDB. For the moment, there is a lingering library dependence on PSI4 for SALCs, so it, too, must be installed (as indicated in Fig. 3).
The QCElemental molecule parsing machinery is also used for PSI4, so its documentation and http://docs.qcarchive.molssi.org/projects/QCElemental/en/latest/model_molecule.html can be helpful. The following describes the particular case in the text. In Snippet 1, the units bohr string indicates that the Cartesian coordinates are already in QCSchema’s required atomic units, so these are unchanged in Snippet 2’s geometry field. The Snippet 1 strings O, H, and Ne specify the elements and are processed into Snippet 2 fields atomic_numbers and symbols. The prefix character @ to neon in Snippet 1 indicates it’s a ghost atom, so the Snippet 2 field real shows a T, T, F pattern. Gh(22Ne) would have been equivalent to the given @22Ne. The prefix string 22 to neon in Snippet 1 specifies the mass number, much like a nuclide symbol. Thus the Snippet 2 fields mass_numbers and masses use default values for the oxygen and hydrogen but 22Ne values for neon. @Ne@21.99138511 to specify the mass value would have been equivalent. The strings no_com and no_reorient were not given in Snippet 1, so the fields fix_com and fix_orientation in Snippet 2 are F, meaning that the origin and frame of geometry are incidental to the Molecule specification. A user label like O1 or O_bigbasis is parsed, but since Snippet 1 doesn’t include any, the atom_labels field of Snippet 2 are empty strings. The--line of Snippet 1 indicates there are two fragments in the molecule, the first with two atoms and the second with one. This is encoded in the fragments field of Snippet 2. No charge/multiplicity lines are present in Snippet 1, either overall or per-fragment, so defaults are assigned. The second fragment is all ghosts and so is a neutral singlet. Electrons are never added or removed to the specification, so the first fragment is assigned neutral doublet, and the overall molecule is a neutral doublet. These defaults are reflected in the Snippet 2 fields molecular_charge, molecular_multiplicity, fragment_charges, and fragment_multiplicities. The string parser also stamps the schema name and provenance information in Snippet 2.
In full, the command requests a Dunning 5ζ to 6ζ Helgaker-formula extrapolation of the MP2 correlation gradient performed by PSI4 with a coupled-cluster singles and doubles excitations correction (CCSD−MP2) at the Dunning triple-ζ to quadruple-ζ Helgaker-formula extrapolation gradient performed by NWCHEM with a CC up to quadruples excitations at cc-pVDZ performed by CFOUR, all atop an implicit 6-ζ Hartree–Fock.