Core correlation energy

Dear developers,

I am just facing a problem with the following simple job:

#! HF
memory 20 gb
molecule{
0 1
H 0. 0. 0.
F 0. 0. 0.8
}
set global{
reference rhf
basis cc-pcvdz
guess gwh
df_scf_guess false
mp2_type conv
e_convergence 9
r_convergence 4
}
scf_e, scf_wfn = energy(‘scf’, return_wfn = True)

set freeze_core true
eval = energy(‘mp2’, ref_wfn=scf_wfn)

set freeze_core false
eall = energy(‘mp2’, ref_wfn=scf_wfn)
ecor = eall-eval

It crashes in the mp2 module with the error message “iwl_buf_init: Can’t open file 33”
and the syslog file says:

  • /home/koput/psi4/bin/psi4 -i /home/koput/bfgs/hf_core.psi -o /home/koput/bfgs/hf_core.psi_out -p hf_core -n 8
    PSIO_ERROR: Can’t find TOC Entry IWL Buffers
    PSIO_ERROR: unit = 33, errval = 13
    PSIO_ERROR: 13 (no such TOC entry)
    An error has occurred python-side.

The scratch directory includes the files:

-rw------- 1 koput users 11193 Feb 13 17:57 hf_core.29969.180
-rw------- 1 koput users 8 Feb 13 17:57 hf_core.29969.33
-rw------- 1 koput users 27848 Feb 13 17:57 hf_core.29969.35
-rw------- 1 koput users 8 Feb 13 17:57 hf_core.29969.41

I would greatly appreciate any advice. Perhaps, there is a simpler way to calculate the core correlation energy in Psi4?

Hi, I ran the input you posted and I got no errors in my output. How recent is your copy of psi4? You can try compiling an up to date version and re-running since it worked for me with the most recent code.

Thanks! My ‘recent’ version of Psi4 is from June 2, 2016, psi4-1.0rc.tar.gz. I tried to compile the new version, but failed because I am still using gcc 4.8.5. So, it will take a while to update the system.

I feel your GCC pain, as our system is 4.8.5 also. This can help without needing to disrupt your OS intrinsics.

The new (Feb. 10, 2017) version is installed. But, it crashes at the very beginning (running under SLURM). A part of the syslog file is:

Currently Loaded Modulefiles:

  1. gmp/5.1.3(default) 6) ifort/17.0.1
  2. mpfr/3.1.2(default) 7) mkl/2017.1.132
  3. libmpc/1.0.1(default) 8) python/2.7.12
  4. gcc/6.2.0 9) boost/1.61.0-gcc482_py2712
  5. icc/17.0.1
  • eval
  • export PATH=/home/users/koput/psi4/bin:/opt/exp_soft/local/haswell/python/2.7.12/bin:/opt/exp_soft/local/haswell/gcc/6.2.0/bin:/opt/exp_soft/local/haswell/intel/compilers_and_libraries_2017.1.132/linux/bin/intel64:.:/home/users/koput/mrcc:/bin:/home/users/koput/bin:.:/home/users/koput/mrcc:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibutils/bin
  • PATH=/home/users/koput/psi4/bin:/opt/exp_soft/local/haswell/python/2.7.12/bin:/opt/exp_soft/local/haswell/gcc/6.2.0/bin:/opt/exp_soft/local/haswell/intel/compilers_and_libraries_2017.1.132/linux/bin/intel64:.:/home/users/koput/mrcc:/bin:/home/users/koput/bin:.:/home/users/koput/mrcc:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibutils/bin
  • export MKL_NUM_THREADS=8
  • MKL_NUM_THREADS=8
  • export OMP_NUM_THREADS=8
  • OMP_NUM_THREADS=8
  • export PSIPATH=/home/users/koput/psi_gbs:
  • PSIPATH=/home/users/koput/psi_gbs:
  • export PSI_SCRATCH=/tmp/lustre/koput.22127
  • PSI_SCRATCH=/tmp/lustre/koput.22127
  • mkdir -p /tmp/lustre/koput.22127
  • cd /tmp/lustre/koput.22127
  • date
    Thu Feb 16 10:06:52 CET 2017
  • /home/users/koput/psi4/bin/psi4 -i /home/users/koput/molpro/hf_core.psi -o /home/users/koput/molpro/hf_core.psi_out -p hf_core
    Traceback (most recent call last):
    File “/home/users/koput/psi4/bin/psi4”, line 140, in
    import psi4
    File “/home/users/koput/psi4/lib//psi4/init.py”, line 59, in
    raise ImportError("{0}".format(err))
    ImportError: /home/users/koput/psi4/lib//psi4/core.so: undefined symbol: _ZN3psi11PSIOManager23mark_file_for_retentionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb

I would greatly appreciate any advice :slight_smile:

That basic_string symbol error almost certainly means that psi4 compiled against an acceptable gcc, but it isn’t finding it at runtime. Do export LD_LIBRARY_PATH=${GCC5}/lib:$LD_LIBRARY_PATH, where ${GCC5} is where you put your new GCC. This is an article on the subject, if you’re interested in the details.

Thanks, I will cope with this problem.

Meanwhile, I compiled the new version using gcc 6.2. The program is running smoothly, but the results are strange. In both the mp2 runs, the number of frozen orbitals is set to zero and, therefore, the mp2 energies are the same. The first command ‘set freeze_core true’ seems to be overwritten by the second command ‘set freeze_core false’. Is this the case?
On the other hand, in the list of options to the mp2 module (“Options:”, printed just before the first mp2 run), there is
FREEZE_CORE => TRUE

It seems that there is a bug in the module mp2 (MP2, Program Written by Ugur Bozkaya, Latest Revision June 25, 2014.)
No matter how ‘freeze_core’ is set,
FREEZE_CORE => TRUE
FREEZE_CORE => FALSE
the number of the frozen orbitals is zero
IRREP FC OCC VIR FV
==============================
A1 0 3 9 0
A2 0 0 1 0
B1 0 1 4 0
B2 0 1 4 0
==============================
and the mp2 total energies in both cases are the same -100.24068891697287

Not a bug, but that’s a reasonable impression to get. Orbital spaces are stored in the Wavefunction object (including frozen-core-ness in an SCF wfn). An even though that property doesn’t effect the SCF, logic for the source-of-truth of orbital spaces is so ticklish (e.g., https://github.com/psi4/psi4/issues/483) and wavefunction passing is so new that we’re conservative and not allowing user resetting spaces on an existing wfn. EDITED TO ADD: The MP2 code doesn’t respond directly to the set freeze_core but takes it off the wfn. END EDIT

So, your input will run just fine without reusing the scf wfn:

scf_e, scf_wfn = energy('scf', return_wfn = True)
print(scf_wfn.frzcpi().to_tuple())

set freeze_core true
eval, mp2_fc_wfn = energy('mp2', return_wfn=True)
print(mp2_fc_wfn.frzcpi().to_tuple())

clean()
set freeze_core false
eall, mp2_nfc_wfn = energy('mp2', return_wfn=True)
print(mp2_nfc_wfn.frzcpi().to_tuple())

ecor = eall-eval

print(eval, eall, ecor)
(0, 0, 0, 0)
(1, 0, 0, 0)
(0, 0, 0, 0)
-100.20324513171455 -100.2407296546917 -0.037484522977152324

Lori, thanks for explanations. It is working now. An another short question: The print command prints to the system output, not to the output file defined in the psi4 command in -o out_file_name. Is it possible to redirect the print output to that file?

Sure, you can use psi4.core.print_out("any python printing syntax here") to direct to output file. In input file, just print_out("stuff") will do.