Problems enabling DKH

Hi,

a fresh build on my linux cluster trying to enable DKH yields the following runtime error when I set relativistic to dkh:

RuntimeError:
Fatal Error: DKH is not a valid choice
Error occurred in file: /home/kipeters/psi4/psi4/src/psi4/liboptions/liboptions.h on line: 52

My cmake build line is:

cmake -H. -Bbroadwell
-DCMAKE_C_COMPILER=/share/apps/gcc6.2/bin/gcc
-DCMAKE_CXX_COMPILER=/share/apps/gcc6.2/bin/g++
-DCMAKE_Fortran_COMPILER=ifort
-DCMAKE_BUILD_TYPE=release
-DPYTHON_EXECUTABLE=/opt/python/bin/python2.7
-DPYTHON_LIBRARY=/opt/python/lib/libpython2.7.so
-DPYTHON_INCLUDE_DIR=/opt/python/include/python2.7
-DMAX_AM_ERI=6
-DCMAKE_INSTALL_PREFIX=/share/apps/psi4/broadwell
-DENABLE_dkh=ON

An analogous set of cmake options on my Mac works just fine. During the Linux build I can see where the dkh module is actually being built. What have I forgotten?

thanks in advance.

You’re doing everything right. There were a couple CMake changes that conspired (along with no dkh test case) to make DKH inaccessible (dkh library was fine but USING_dkh compile definition wasn’t getting applied to the file that defined the relativistic keyword). This PR fixes it. You can add these three lines, re- make and get a working version again. Sorry about that.

P.S. You’ve almost certainly used dkh in Psi4 more that all the developers. If you should happen to have handy an input file and dkh answer you trust, and would be willing to send it, I’ll make a test case so this can’t happen again.

Thanks Lori, this does indeed get my DKH up and running again. But unfortunately I can’t seem to reproduce the DKH2 energies from Molpro. In the simple input below for Ne atom, the DKH2 HF energy is about 4 mEh higher in energy. Things are even worse if I use the non-relativistically contracted basis set (I get an exact match with Molpro if I turn DKH off in this latter case). Using a larger uncontracted auxiliary set (than the uncontracted orbital set) doesn’t help. For the input below, Molpro gives a HF energy of -128.66891610. Psi4 gives -128.6642012.

memory 450 mb

molecule Ne {
0 1
Ne
}

set {
reference rhf
basis cc-pvtz-dk
relativistic dkh
dkh_order 2
print 2
scf_type pk
}

energy(‘scf’)

Thank you. Unfortunately, I’ve never been able to reproduce Molpro DKH either, though, as you say, plain SCF is just fine. I had thought from another thread on this site that you had reconciled them. One of these days, I’ll figure out what’s going on on this issue. So glad your DKH is functional again.

I believe we can get X2C to match between the 2 codes, but DKH in PSI4 seems to be the outlier. I was involved in a thread on this earlier, but I thought that had more to do with linear dependency issues, which doesn’t seem to apply in this simple case.

I believe the issue is that the DKH code in psi4 does not perform a decontraction/recontraction of the basis set. I never verified this numerically, but should be simple to test. If you run DKH in psi4 and molpro with uncontracted basis sets they should agree. If you have a chance could you confirm this?

BTW: I have made some progress on the elimination of linear dependencies in X2C but I have not yet pushed any code.

I’ll try this, but I thought there seemed to be some dependence on the so-called relativistic basis set when you specify this. I’ll test though.

I finally got around to this and you’re exactly right. If I use completely uncontracted basis sets from the start, the DKH results match between PSI4 and Molpro.

Thanks for checking that Kirk. I’ll work to get our DKH code to decontract automatically.

1 Like

Psi4 and Molpro should be reconciled as of yesterday.

1 Like