Read volumetric cube data from HDF5 binary file. This adds a dependency on the HDF5 library and the HighFive C++ wrappers to it. We could consider ditching HighFive and just use the C (or C++) API that comes with HDF5, but those are pretty low-level...
This leads to much more compact data files, but is obviously still not the optimal solution.[^1]
Tested for restricted HF. The reference numbers are updated wrt the h2_scf_cube test: the values differ by roughly 10-3 between the two tests, which I believe it's due to the better precision when reading data from HDF5.
I've also simplified the CUBEfunction class a bit, removing some data members that were initialized, but never used.
TODO
[ ] Test for unrestricted HF.
[ ] Add the Python scripts to obtain the volumetric cube data in HDF5 format from VeloxChem.
[ ] Fix CircleCI (most likely needs a new Docker image with the additional HDF5 and HighFive dependencies)
[ ] Extend to response and test it.
[^1]: An AO evaluator is the optimal solution, since the data file from a GTO calculation would be the AO basis set specification + the MO coefficients.
Read volumetric cube data from HDF5 binary file. This adds a dependency on the HDF5 library and the HighFive C++ wrappers to it. We could consider ditching HighFive and just use the C (or C++) API that comes with HDF5, but those are pretty low-level...
This leads to much more compact data files, but is obviously still not the optimal solution.[^1]
Tested for restricted HF. The reference numbers are updated wrt the
h2_scf_cubetest: the values differ by roughly 10-3 between the two tests, which I believe it's due to the better precision when reading data from HDF5.I've also simplified the
CUBEfunctionclass a bit, removing some data members that were initialized, but never used.TODO
[^1]: An AO evaluator is the optimal solution, since the data file from a GTO calculation would be the AO basis set specification + the MO coefficients.