robparrish / lightspeed-defunct Goto Github PK

All ERI-type integrals (and derivatives) should be modified to handle a kernel of the type a / r_12 + b erf(w r_12) / r_12. This should just be a matter of modifying the fundamental slightly. Note that the composition is immutable for a given integral computer, so the creation of a more-optimized fundamental for a- or b-only types can be done in the constructor.

We need to port all integral derivatives and integral Hessians, and document in each integral computer how the integrals are returned in each buffer. Also, I am a fan of having several compute pair routines for the very difficult PotentialInt2C - e.g., one for moving the shells in the bra, the other for moving the nuclei in the ket. This will allow for good QM/MM support. This object could/should also be extended to do the ESP and electric field integrals.

In the Boost::python export, the operator overloading gets lost. We should either expose this to python (maybe too complicated), or re-implement it in the python side of libpygaussian.

For some reason, we need hundreds of terms in the Boys function for PotentialInt2C. This may be why PSI4's potential integrals are so slow too. Overall, the Boys function computers for all Coulomb-type integrals should be standardized.

Refactor all cc files to include internal headers first to check for correctness.

There is the potential for environmental noise in DirectJK - the screening is currently based on the maximum D matrix element over all tasks. This is sufficient to eliminate an integral, but then checks must be performed to see if the integral contributes in each task.

These break HF/H2O/STO-3G. Just leaving a note to fix this tomorrow.

Inclusion of omp.h and calls to OpenMP functions need to be wrapped in ifdefs. I'm already working on it.

From Lightspeed sto-3g potential integrals for the water molecule:

    O 1S    O 2S    O 1P                    H1 1S   H2 1S
[[-61.677  -7.434   0.      0.     -0.017  -1.573  -1.573]
 [ -7.434 -10.1     0.      0.     -0.208  -3.582  -3.582]
 [  0.      0.    -10.036   0.      0.      0.      0.   ]
 [  0.      0.      0.     -9.951   0.      2.124  -2.124]
 [ -0.017  -0.208   0.      0.    -10.092  -1.709  -1.709]
 [ -1.573  -3.582   0.      2.124  -1.709  -5.664  -1.426]
 [ -1.573  -3.582   0.     -2.124  -1.709  -1.426  -5.664]]

From psi4.MintsHelper, same molecule and basis:

[[-61.677  -7.434  -0.017   0.      0.     -1.573  -1.573]
 [ -7.434 -10.1    -0.208   0.      0.     -3.582  -3.582]
 [ -0.017  -0.208 -10.036   0.      0.     -1.709  -1.709]
 [  0.      0.      0.     -9.951   0.      0.      0.   ]
 [  0.      0.      0.      0.    -10.092   2.124  -2.124]
 [ -1.573  -3.582  -1.709   0.      2.124  -5.664  -1.426]
 [ -1.573  -3.582  -1.709   0.     -2.124  -1.426  -5.664]]

The ordering of angular momentum for P-shell containing blocks (and higher angular momentum blocks) is not consistent. This is only an issue for spherical shells, cartesian shells work just fine.

Try to build a vector of PotentialInt4C objects (not shared_ptr references). Very weird stuff is happening when the destructors are called as the vector resizes. I suspect this stems from a lack of default constructor.

Boost, ambit, and lightpseed must link the same libpython2.7.dylib on OSX. Since python-config will always return a relative path (in this case just libpython2.7.dylib) either absolute paths need to be inserted or we can do the following:

• install_name_tool -change /System/Library/Frameworks/Python.framework/Versions/2.7/Python @executable_path/../lib/libpython2.7.dylib *dylib
• Copy all required .so and .dylib into /anaconda/lib.
• Add /anaconda/lib to DYLD_LIBRARY_PATH (not a good idea, causes other apps to crash)
• Ignore anaconda until ambit/lightspeed is stable enough to make a conda package.

Interestingly these errors do not occur on linux. Also, Psi4 will link to system python on OS X and then can be run with the python anaconda interpreter without the now famous Fatal Python error: PyThreadState_Get: no current thread. I have not found a good solution so I will just avoid anaconda for now, but I wanted to tack this here for the future.

Grab a Tensor. Grab it's dims() reference. Change its dims(). Whoops.

There are several issues in the cmake files dealing with the Python module creation on a Mac. To list a couple:

• Name of the target file.
• Undefined functions from Ambit/BLAS/LAPACK

I'll get these working on my Mac and then confirm on Ubuntu 14.04.