Hendrik Vennekate reported a crash writing the orbital file in the SCF module. We traced this to a problem with the number of MO's changing, and the new filesize is different than the previous filesize, giving PSIO fits. The solution will be to blow away the file before we write the new coefficients.

molecule schi112 {
0 1
C 1.992381797174 -2.384354751712 -2.993366397562
C 1.228121526863 -1.274847835639 -3.351496142704
C 1.013099808976 -0.096716453452 -2.640334263532
C 1.529504298267 0.292928191105 -1.409192139229
C 2.494126536754 -0.467080983006 -0.560933641235
C 3.003582432090 -1.737924160834 -0.783889065036
C 2.769133637687 -2.598542901279 -1.856952991548
C 1.277514575629 1.516518268211 -0.750473230890
C 2.043031766314 1.530064287276 0.429834437874
C 2.781071200241 0.346831462421 0.547222303270
C 0.331279128018 2.597569873302 -1.170283396618
C -1.055809083241 2.619579374400 -0.505102826064
C -3.007822478580 1.467887750457 0.346313567353
C -2.737441971995 1.210386860246 1.823863198791
C -1.771682755626 -0.377549950855 3.288385929391
C -0.725219293291 -1.470001880969 3.265198353103
O -2.011738101654 -0.000473360001 1.946048595534
N -1.814457990750 1.476521947835 -0.495974028017
O -1.486124528571 3.658969974773 -0.022977929056
H 1.983643665259 -3.200384618921 -3.705961229953
H 0.718461117324 -1.345849367127 -4.303825324337
H 0.350907237427 0.616950149147 -3.119075116214
H 3.676140620880 -2.109282391465 -0.017487285463
H 3.272531113987 -3.555754086369 -1.807900216108
H 2.058943071980 2.349266204546 1.134368500502
H 3.472739721386 0.097519945506 1.336731400325
H 0.168474080806 2.547179744292 -2.248127020046
H 0.756093357555 3.571701649289 -0.937344979453
H -3.473888529556 2.443761502993 0.233969033713
H -3.678528703972 0.693841954810 -0.023021795736
H -3.683424826831 1.122758821689 2.369341272280
H -2.158587217937 2.040718408406 2.239661235900
H -1.397654842931 0.478282649094 3.862936033974
H -2.689164190718 -0.745525653670 3.760362229725
H -0.522908742059 -1.829437030547 4.270707232296
H -1.335460161411 0.599637097912 -0.637487324770
H 0.191838379615 -1.070755100110 2.832096282140
N -1.176303107524 -2.652929380092 2.505563226321
N -1.350778086421 -2.531724211116 1.296707152615
N -1.541968166301 -2.578278885168 0.192089082738
}
set_num_threads(12)
set_memory(int(10.0e9))
set basis 6-311ppg_d_p_
optimize("b3lyp")

For educational purposes it would be helpful to have some basis sets that span the periodic table (although obviously computations will be poor for heavier elements, especially without pseudopotentials). Identify and enter such basis sets.

Ryan thinks this routine seems to be giving wrong values for g-shells. Check.

Dear psi4 developer.
I found out that the MRMP2 method doesn't use out_of_core algorithm like MKCCSD and MRCCSD(T) does for sorting (src/bin/psimrcc/sort_out_of_core.cc).
MRPT2 incore algorithm uses large amounts of memory, for example 31Gb for C8H8 molecule, C2V symmetry, in cc-pVTZ basis, instead of ~11GB for MRCCSD with same options.
I not completely understand algorithm of sorting, but is there an opportunity to use sort_out_of_core.cc algorithm for MRPT2, may be with some simplifications or modification?
Any comments are welcomed.

WebMO can do nice coordinate scans but PSI4 can't parse the corresponding output. Matt said he could look at this and that JR might have put in an update to WebMO to make it easier for us to handle.

Hello,
One of our users hit a problem last year on our supercomputer with his SAPT (energy('sapt2+3-ct')) jobs. Our sysadmins flagged low cpu utilisation for his jobs for which we decided that 4 cpus would give him optimum efficiency. However, the jobs were large enough as to take > 1000 hours (also frowned upon by our sysadmins) so I was asked to look into whether he could make better parallel use of the processors. We had some teething problems bringing our new supercomputer on line last year so I wanted to rule out issues on our side and I think I have now ruled out issues with IO, memory and threading (that had affected other programs).
Furthermore, during the investigations we noticed that "top" showed an almost equal alternation between one cpu and maximum cpus thus averaging above/below 50% use no matter how many cpus were requested. Roger Amos and I had a quick look at the SAPT papers and decided there wasn't anything intrinsic about the method that wouldn't allow it to parallel or would cause this behaviour (note I initially thought it might be a load imbalance between monomer basis and dimer basis calculations but it isn't). Also, subsequently we were asked to look into the performance of energy('fno-df-ccsd(t)') and that doesn't show this serial/parallel alternation.
Do you have any thoughts on this and have suggestions for determining optimum number of processors (does it depend on memory?) for this sort of calculation?
Thanks.
Rika
PS Do you need an input deck for this? Originally, the smallest case he had showing this behaviour took 230 hrs (seemed to be ok for his 60 hr SAPT job) but since then I think I have a 48 hr test case that will also display this behaviour. I'll need to ask the user for permission to pass it on first though.

I tried to run a geometry optimization on (H_2)+. A segfault occurs.

Input file:

memory 250 mb

molecule h2 {
1 2
H
H 1 1.5
}

set reference uhf
set basis aug-cc-pVDZ
optimize('scf')

Valgrind trace
==12400== Invalid read of size 8
==12400== at 0x11C73A9: psi::scfgrad::SCFGrad::compute_gradient() (in /usr/bin/psi4)
==12400== by 0x11BF3EC: psi::scfgrad::scfgrad(psi::Options&) (in /usr/bin/psi4)
==12400== by 0x67BD9E: py_psi_scfgrad() (in /usr/bin/psi4)
==12400== by 0x682F96: boost::python::objects::caller_py_function_impl<boost::python::detail::caller<int (*)(), boost::python::default_call_policies, boost::mpl::vector1 > >::operator()(object, object) (in /usr/bin/psi4)
==12400== by 0x31C2429AAA: boost::python::objects::function::call(object, object) const (in /usr/lib64/libboost_python.so.1.50.0)
==12400== by 0x31C2429CC7: ??? (in /usr/lib64/libboost_python.so.1.50.0)
==12400== by 0x31C2432C4A: boost::python::handle_exception_impl(boost::function0) (in /usr/lib64/libboost_python.so.1.50.0)
==12400== by 0x31C2427F84: ??? (in /usr/lib64/libboost_python.so.1.50.0)
==12400== by 0x3D50849C0D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==12400== by 0x3D508D9582: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==12400== by 0x3D508DDCBE: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==12400== by 0x3D5086DA36: ??? (in /usr/lib64/libpython2.7.so.1.0)
==12400== Address 0x0 is not stack'd, malloc'd or (recently) free'd

I cannot use the default options provided by ../configure.cmake to finish compiling unless --with-ldflags='-lm' is added. With the default options, it complains
gcc: : No such file or directory
during compiling of libint_compiler

My platform is gcc-4.4, cmake-2.8.2

CCSD calculations on the N and F atoms result in segmentation faults for me (gcc 4.8.1, boost 1.53, python 3.3.2). I used the input file:

molecule f { 
    f 0.00 0.00 0.00
}
set basis cc-pVTZ
set scf reference uhf 
energy('ccsd')

(and similarly for N). I tried increasing the memory and changing basis set to no avail (some basis sets caused a back trace rather than just a segmentation fault).

Curiously CCSD calculations with a UHF reference on the rest of the period 2 atoms ran without a problem.

Running psi4 through gdb and the backtraces indicate the problem is with freeing an invalid pointer when closing a dpd buffer in ccenergy/pair_energies.cc.

Full backtrace from gdb:

(gdb) where
#0  0x00007ffff45e62a4 in free () from /usr/lib/libc.so.6
#1  0x000000000136b8bc in psi::free_int_matrix (array=0x29d1fc0) at /home/james/projects/psi4/src/lib/libciomr/int_array.cc:134
#2  0x00000000012edea5 in psi::DPD::buf4_close (this=<optimized out>, Buf=Buf@entry=0x7fffffffd630)
    at /home/james/projects/psi4/src/lib/libdpd/buf4_close.cc:50
#3  0x000000000082dbf8 in psi::ccenergy::pair_energies (epair_aa=epair_aa@entry=0x7fffffffd7c8, epair_ab=epair_ab@entry=0x7fffffffd7d0)
    at /home/james/projects/psi4/src/bin/ccenergy/pair_energies.cc:99
#4  0x000000000086b797 in psi::ccenergy::ccenergy (options=...) at /home/james/projects/psi4/src/bin/ccenergy/ccenergy.cc:307
#5  0x000000000086f4a5 in psi::ccenergy::CCEnergyWavefunction::compute_energy (this=0x293b760) at /home/james/projects/psi4/src/bin/ccenergy/ccenergy.cc:171
#6  0x00000000007004f4 in py_psi_ccenergy () at /home/james/projects/psi4/src/bin/psi4/python.cc:429
#7  0x00000000007080f7 in invoke<boost::python::to_python_value<double const&>, double (*)()> (rc=..., f=<optimized out>)
    at /usr/include/boost/python/detail/invoke.hpp:75
#8  operator() (args_=<optimized out>, this=<optimized out>) at /usr/include/boost/python/detail/caller.hpp:223
#9  boost::python::objects::caller_py_function_impl<boost::python::detail::caller<double (*)(), boost::python::default_call_policies, boost::mpl::vector1<double> > >::operator() (this=<optimized out>, args=<optimized out>, kw=<optimized out>) at /usr/include/boost/python/object/py_function.hpp:38
#10 0x00007ffff6695f2a in boost::python::objects::function::call(_object*, _object*) const () from /usr/lib/libboost_python3.so.1.54.0
#11 0x00007ffff6696298 in ?? () from /usr/lib/libboost_python3.so.1.54.0
#12 0x00007ffff66a01b3 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const ()
   from /usr/lib/libboost_python3.so.1.54.0
#13 0x000000000070c003 in operator() (this=<optimized out>, translate=0x6f9ff0 <translate_psi_exception(psi::PsiException const&)>, f=..., handler=...)
    at /usr/include/boost/python/detail/translate_exception.hpp:48
#14 operator()<bool, boost::python::detail::translate_exception<psi::PsiException, void (*)(const psi::PsiException&)>, boost::_bi::list2<const boost::python::detail::exception_handler&, const boost::function0<void>&> > (f=..., a=<synthetic pointer>, this=<optimized out>) at /usr/include/boost/bind/bind.hpp:382
#15 operator()<boost::python::detail::exception_handler, boost::function0<void> > (a2=..., a1=..., this=<optimized out>)
    at /usr/include/boost/bind/bind_template.hpp:102
#16 boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<psi::PsiException, void (*)(psi::PsiException const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(psi::PsiException const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke (function_obj_ptr=..., a0=..., a1=...) at /usr/include/boost/function/function_template.hpp:132
#17 0x00007ffff669ff7d in boost::python::handle_exception_impl(boost::function0<void>) () from /usr/lib/libboost_python3.so.1.54.0
#18 0x00007ffff6694a53 in ?? () from /usr/lib/libboost_python3.so.1.54.0
#19 0x00007ffff509dfdc in PyObject_Call (func=func@entry=0x278dbd0, arg=arg@entry=0x7ffff7f4f050, kw=kw@entry=0x0) at Objects/abstract.c:2084
#20 0x00007ffff5148fa6 in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffffdc30, func=<optimized out>) at Python/ceval.c:4283
#21 call_function (oparg=<optimized out>, pp_stack=0x7fffffffdc30) at Python/ceval.c:4086
#22 PyEval_EvalFrameEx (f=f@entry=0x290fc70, throwflag=throwflag@entry=0) at Python/ceval.c:2679
#23 0x00007ffff514d265 in PyEval_EvalCodeEx (_co=0x7fffef1d9270, globals=<optimized out>, locals=locals@entry=0x0, args=args@entry=0x7ffff7eace28, 
    argcount=1, kws=kws@entry=0x7ffff7f4f068, kwcount=kwcount@entry=0, defs=defs@entry=0x0, defcount=defcount@entry=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3433
#24 0x00007ffff50c4033 in function_call (func=0x7fffef2128c0, arg=0x7ffff7eace10, kw=0x7fffef1a75f0) at Objects/funcobject.c:633
#25 0x00007ffff509dfdc in PyObject_Call (func=func@entry=0x7fffef2128c0, arg=arg@entry=0x7ffff7eace10, kw=kw@entry=0x7fffef1a75f0) at Objects/abstract.c:2084
#26 0x00007ffff5148044 in ext_do_call (nk=<optimized out>, na=<optimized out>, flags=<optimized out>, pp_stack=0x7fffffffdf48, func=0x7fffef2128c0)
    at Python/ceval.c:4378
#27 PyEval_EvalFrameEx (f=f@entry=0x2982860, throwflag=throwflag@entry=0) at Python/ceval.c:2720
#28 0x00007ffff514d265 in PyEval_EvalCodeEx (_co=_co@entry=0x7fffefef5e40, globals=<optimized out>, locals=locals@entry=0x0, args=<optimized out>, 
    argcount=argcount@entry=1, kws=0x28d54e8, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3433
#29 0x00007ffff514b004 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7fffffffe160, func=<optimized out>) at Python/ceval.c:4161
#30 call_function (oparg=<optimized out>, pp_stack=0x7fffffffe160) at Python/ceval.c:4084
#31 PyEval_EvalFrameEx (f=f@entry=0x28d5360, throwflag=throwflag@entry=0) at Python/ceval.c:2679
#32 0x00007ffff514d265 in PyEval_EvalCodeEx (_co=_co@entry=0x7ffff7f22150, globals=globals@entry=0x7ffff7ed07a0, locals=locals@entry=0x7ffff7ed07a0, 
    args=args@entry=0x0, argcount=argcount@entry=0, kws=kws@entry=0x0, kwcount=kwcount@entry=0, defs=defs@entry=0x0, defcount=defcount@entry=0, 
    kwdefs=kwdefs@entry=0x0, closure=closure@entry=0x0) at Python/ceval.c:3433
#33 0x00007ffff514d33b in PyEval_EvalCode (co=co@entry=0x7ffff7f22150, globals=globals@entry=0x7ffff7ed07a0, locals=locals@entry=0x7ffff7ed07a0)
    at Python/ceval.c:771
#34 0x00007ffff51669e4 in run_mod (mod=<optimized out>, filename=filename@entry=0x7ffff51bde72 "<string>", globals=globals@entry=0x7ffff7ed07a0, 
    locals=locals@entry=0x7ffff7ed07a0, flags=flags@entry=0x0, arena=arena@entry=0x28ca640) at Python/pythonrun.c:1981
#35 0x00007ffff5168335 in PyRun_StringFlags (str=<optimized out>, start=257, globals=0x7ffff7ed07a0, locals=0x7ffff7ed07a0, flags=0x0)
    at Python/pythonrun.c:1914
#36 0x00007ffff66a3f45 in boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object) ()
   from /usr/lib/libboost_python3.so.1.54.0
#37 0x00000000006fcad7 in psi::Python::run (this=<optimized out>, input=<optimized out>) at /home/james/projects/psi4/src/bin/psi4/python.cc:1446
#38 0x000000000069a8ae in main (argc=2, argv=<optimized out>) at /home/james/projects/psi4/src/bin/psi4/psi4.cc:111

Any suggestions on what I could do to track this down further? I looked in ccenergy/pair_energies.cc and there was nothing immediately obvious.

Thanks!

We need to be able to fail over to a universal JK-set when a particular JK-set isn't available. There's a Karlsruhe QZ universal set we should adopt and enter into PSI4. Lori has some info on it.

If a user wants to make a potential energy curve or surface, it is very easy to generate nonsense when using cartesian coordinates. Using nocom and no_reorient fixes this, so maybe the driver should be setting these options if it detects such a case.

molecule beh2 {
Be 0.0  0.0    z
H  0.0  1.0  0.0
H  0.0 -1.0  0.0
}
molecule beh2_nocom {
Be 0.0  0.0    z
H  0.0  1.0  0.0
H  0.0 -1.0  0.0
nocom
no_reorient
}
activate(beh2)
set basis sto-3g
set guess sad
for i in range (1,41):
    z = i*0.1
    beh2.z = z
    e = energy('scf')
    print z,e
    set guess read
print ''

activate(beh2_nocom)
set basis sto-3g
set guess sad
for i in range (1,41):
    z = i*0.1
    beh2_nocom.z = z
    e = energy('scf')
    print z,e
    set guess read

Dear all,

I just made a clone of the psi4public. However, I got the error message "Cannot find source file sapt_dft.cc" when trying to compile psi4 (in a directory "psi4public/build") by either "../configure.cmake" or "cmake ..".

Is it a bug in psi4? Thank you.

Cheers
Gao

I know how to fix this myself, but let's pretend I'm a stupid Mac user that has Xcode and, by the grace of god, managed to install gfortran without losing a limb. Don't I deserve for CMake to throw me a bone and auto-detect the fast system BLAS/LAPACK?

I am surprised that CMake doesn't do this already btw. Seems dirt-simple for them.

Cheers,

Jeff

Jeffs-MacBook-Pro:build jhammond$ cmake ..
-- The C compiler identification is Clang 4.2.0
-- The CXX compiler identification is Clang 4.2.0
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: /usr/local/bin/gfortran
-- Check for working Fortran compiler: /usr/local/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/local/bin/gfortran supports Fortran 90
-- Checking whether /usr/local/bin/gfortran supports Fortran 90 -- yes
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS)
-- Looking for include file dlfcn.h
-- Looking for include file dlfcn.h - found
-- Looking for MKL_Free_Buffers
-- Looking for MKL_Free_Buffers - not found
-- Looking for erf
-- Looking for erf - found
-- Looking for MPI_Finalize
-- Looking for MPI_Finalize - not found
-- Checking for restrict keyword
-- Checking for restrict keyword - restrict
-- Looking for Fortran dgemm
-- Looking for Fortran dgemm - not found
-- Looking for Fortran dgemm
-- Looking for Fortran dgemm - not found
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
CMake Error at /usr/local/Cellar/cmake/2.8.12.1/share/cmake/Modules/FindBLAS.cmake:594 (message):
A required library with BLAS API not found. Please specify library
location.
Call Stack (most recent call first):
/usr/local/Cellar/cmake/2.8.12.1/share/cmake/Modules/FindLAPACK.cmake:142 (find_package)
CMakeLists.txt:135 (find_package)

Update the SAPT output to conform with the recommendations of our systematic study in ``Levels of Symmetry Adapted Perturbation Theory (SAPT). I. Efficiency and Performance for Interaction Energies,'' T. M. Parker, L. A. Burns, R. M. Parrish, A. G. Ryno, and C. D. Sherrill, J. Chem. Phys. 140, 094106 (2014) [doi: 10.1063/1.4867135 ]

Dear psi4 developers.
I found that in function
def run_cc_gradient(name, **kwargs) in psi4.0b5/lib/python/proc.py
analitic gradient now disabled for RHF CCSD, but in psi4.0b5 tarball this was enabled and worked properly in my case.

chages occurred in commit:
commit 68966f1
Author: Alexander Sokolov [email protected]
Date: Fri Oct 4 14:42:01 2013 -0400

Psi4 throws now if someone tries to run CCSD(T) gradients with RHF reference

what reason of this change?
Sincerely,
Konjkov Vladimir

Hello,
This is Jason from Monash Uni again. Thought I'd post my issue here instead of emailing everyone. I'm getting a PSIO error for some FNO-CD-CCSD(T) calculations and I'm hoping someone could help solve my problem. See below for the details.

Cheers,
Jason

Input

memory 126 Gb
molecule complex {
*** Atomic coordinates omitted ***
}

set globals {
   basis aug-cc-pVDZ
   scf_type df
   df_basis_cc cholesky
   freeze_core True
   guess sad
   basis_guess 3-21G
}
energy('fno-df-ccsd(t)')

End of calculation output

*** at Mon Feb 10 13:17:33 2014



        *******************************************************
        *                                                     *
        *                       DF-CCSD                       *
        *                 Density-fitted CCSD                 *
        *                                                     *
        *                   Eugene DePrince                   *
        *                                                     *
        *******************************************************


  ==> 3-index integrals <==

        Generating Cholesky vectors ...
        Cholesky decomposition threshold: 1.00e-04
        Number of Cholesky vectors:           2784

  ==> Frozen Natural Orbitals <==

        Doubles contribution to MP2 energy in full space:      -4.157303195170

        Cutoff for significant NO occupancy: 1.000e-06

        Number of virtual orbitals in original space:    678
        Number of virtual orbitals in truncated space:   640

  ==> Memory <==

        Total memory requirements:        78825.79 mb
        3-index integrals:                10109.75 mb
        CCSD intermediates:               68716.04 mb


        <<< warning! >>> switched to low-memory (t) algorithm

        memory requirements for CCSD(T):  36451.32 mb

  ==> Input parameters <==

        Freeze core orbitals?                 yes
        Use frozen natural orbitals?          yes
        r_convergence:                  1.000e-07
        e_convergence:                  1.000e-06
        Number of DIIS vectors:                 8
        Number of frozen core orbitals:        26
        Number of active occupied orbitals:    74
        Number of active virtual orbitals:    640
        Number of frozen virtual orbitals:     38


  Begin singles and doubles coupled cluster iterations

   Iter  DIIS          Energy       d(Energy)          |d(T)|     time
      0   0 2    0.0000000000    0.0000000000    0.0000000000      393

  CCSD iterations converged!

        T1 diagnostic:                        0.000000000000
        D1 diagnostic:                        0.000000000000

        OS MP2 FNO correction:               -3.045395864164
        SS MP2 FNO correction:               -1.111907331006
        MP2 FNO correction:                  -4.157303195170

        OS MP2 correlation energy:           -3.045395864164
        SS MP2 correlation energy:           -1.111907331006
        MP2 correlation energy:              -4.157303195170
      * MP2 total energy:                 -1500.355601695273

        OS CCSD correlation energy:          -3.045395864164
        SS CCSD correlation energy:          -1.111907331006
        CCSD correlation energy:             -4.157303195170
      * CCSD total energy:                -1500.355601695273

  Total time for CCSD iterations:    3404.15 s (user)
                                      270.93 s (system)
                                         607 s (total)

  Time per iteration:                    inf s (user)
                                         inf s (system)
                                         inf s (total)

*** tstop() called on r3546 at Mon Feb 10 14:43:17 2014
Module time:
    user time   =   31046.70 seconds =     517.45 minutes
    system time =     945.63 seconds =      15.76 minutes
    total time  =       5144 seconds =      85.73 minutes
Total time:
    user time   =   33202.74 seconds =     553.38 minutes
    system time =     990.31 seconds =      16.51 minutes
    total time  =       5317 seconds =      88.62 minutes

*** tstart() called on r3546
*** at Mon Feb 10 14:57:28 2014


        *******************************************************
        *                                                     *
        *                      CCSD(T)                        *
        *                                                     *
        *******************************************************

        num_threads =                    16
        available memory =      83711.64 mb
        memory requirements =   36451.32 mb

PSIO error (from stderr)

PSIO_ERROR: unit = 260, errval = 18
PSIO_ERROR: 18 (Incorrect block end address)
Traceback (most recent call last):
  File "<string>", line 77, in <module>
  File "/apps/psicode/4.0b5.1/share/psi/python/driver.py", line 570, in energy
    procedures['energy'][lowername](lowername, **kwargs)
  File "/apps/psicode/4.0b5.1/share/psi/python/proc.py", line 2289, in run_fnodfcc
    psi4.fnocc()
RuntimeError: PSIO Error
file: /short/z00/cyl900/psi4/psi4public/src/lib/libpsio/error.cc
line: 1p

Right now it crashes with no helpful message.

@jturney can you take a look?

I was trying to run a Gaussian-2 energy calculation for hydrogen disulfide, which appears in the original G2 test set: http://scitation.aip.org/content/aip/journal/jcp/94/11/10.1063/1.460205

The job terminated after calculating the MP4(SDTQ) total energy, with message:

RuntimeError: sanity check failed! Gaussian94BasisSetParser::parser: Unable to find the basis set for S in /opt/science/psi/psi4/share/psi/basis/6-311g_2df_p_.gbs

When I examine the 6-311g_2df_p_.gbs file, I see that it only has entries for H, He, Li, Be, B, C, N, O, F, Ne, K, Ca. According to the comment at the top of the file it's supposed to have been merged from 6-311G** and 6-311G on the EMSL Basis Set Exchange. I double checked on the BSE and these basis sets also have entries for Na, Mg, Al, Si, P, S, Cl, Ar, Ga, Ge, As, Se, Br, Kr, I, as expected.

Streamline handling of modules that require integrals to exist on disk but maybe they're not present (e.g., because DF-SCF was run). This is handled in a lot of places (although probably not everywhere it needs to be) through some python boilerplate. I think it would be a little more elegant to handle C-side in each module that needs the ints (doesn't hurt to spin off a cints call, I suspect). Lori says Jet did a fix recently on MRCC to do something like this. Check that, and if it looks good, roll that out for all codes requiring conventional integrals on disk (and remove corresponding python boilerplate).

# cubane Transition State CСSD(T)/cc-pVDZ geometry optimization

memory 2 Gb

molecule cubane {
 0 1
 H                    -1.460    -1.409    -1.325
 C                    -0.747    -0.790    -0.779
 H                    -1.460    -1.409     1.325
 C                    -0.747    -0.790     0.779
 H                    -1.388     1.387    -1.426
 C                    -0.772     0.772    -0.772
 H                     1.460    -1.460    -1.475
 C                     0.725    -0.725    -1.177
 H                    -1.388     1.387     1.426
 C                    -0.772     0.772     0.772
 H                     1.460    -1.460     1.475
 C                     0.725    -0.725     1.177
 H                     1.409     1.460    -1.325
 C                     0.790     0.747    -0.779
 H                     1.409     1.460     1.325
 C                     0.790     0.747     0.779
}

set {
 basis cc-pVDZ
 opt_type ts
}

set_num_threads(2)

optimize('ccsd(t)')

Initial molecule has Molecular point group: cs, Full point group: Cs
after couple of step geometry optimization atomic coordinates changed to
Center X Y Z
------------ ----------------- ----------------- -----------------
H -1.473705914299 -1.435393855860 -1.358489164213
C -0.797159999078 -0.797004109009 -0.746661382504
H -1.476630117570 -1.415339339271 1.362245194949
C -0.797740772644 -0.782869624563 0.746875065611
H -1.403399626888 1.397804298812 -1.532486210635
C -0.816065575433 0.813208518621 -0.796372487595
H 1.564836624106 -1.553887853367 -0.825942923699
C 0.782186226366 -0.785194185540 -0.703283447355
H -1.398864375817 1.398697058928 1.533459031552
C -0.813477696736 0.814494835084 0.795484014989
H 1.543644549536 -1.569635373854 0.822765427607
C 0.785442354192 -0.778370034240 0.690456922666
H 1.425099138027 1.481569438277 -1.355017034180
C 0.789948918555 0.800919182066 -0.744361460399
H 1.425889588787 1.478227539320 1.363344118168
C 0.793832546892 0.798935970506 0.747984335038
but Molecular point group didn't - cs
error issued
ERROR: Symmetry operation 1 did not map atom 7 to another atom:

Hi,
I was trying the MRCC interface in Psi4 to run energy('mrccsd(t)_l') but I run into a PSIO_ERROR.

Input

memory 126 Gb
molecule complex {
0 1
C   0.028824000   0.102541000   0.329511000
H   -0.846717000   0.257672000   -0.295811000
C   1.368536000   0.016176000   0.003655000
H   1.872535000   0.082040000   -0.957212000
N   -0.055760000   -0.031179000   1.697636000
C   1.178669000   -0.178253000   2.203240000
H   1.426085000   -0.303457000   3.252661000
N   2.052611000   -0.167236000   1.184832000
C   3.504230000   -0.205550000   1.365908000
H   3.698001000   -0.576769000   2.380482000
H   3.898020000   0.813550000   1.260411000
H   3.939232000   -0.884942000   0.619049000
C   -1.256640000   0.100763000   2.523448000
H   -1.529670000   1.162452000   2.578623000
H   -1.007837000   -0.272600000   3.525198000
H   -2.062908000   -0.500349000   2.079371000
F   1.181657000   2.676729000   1.439625000
B   1.518848000   2.859437000   2.791181000
F   1.689389000   4.189751000   3.137207000
F   0.482658000   2.259079000   3.612149000
F   2.731761000   2.111893000   3.070818000
C   1.992235000   1.241852000   8.156885000
H   1.485477000   1.176688000   9.116348000
C   3.332840000   1.154673000   7.834922000
H   4.206519000   0.999649000   8.462845000
N   1.311649000   1.424993000   6.973626000
C   2.188563000   1.435214000   5.957752000
H   1.944614000   1.560136000   4.907488000
N   3.421451000   1.288054000   6.467033000
C   4.624491000   1.154329000   5.644658000
H   4.896627000   0.092348000   5.590783000
H   4.378873000   1.527036000   4.641881000
H   5.430033000   1.755038000   6.090598000
C   -0.139438000   1.464529000   6.788437000
H   -0.534567000   0.445964000   6.893963000
H   -0.329914000   1.835298000   5.773051000
H   -0.575851000   2.145114000   7.533419000
F   2.193639000   -1.420051000   6.719505000
B   1.853598000   -1.602720000   5.368653000
F   1.684676000   -2.933106000   5.022169000
F   2.887295000   -1.000476000   4.545917000
F   0.639066000   -0.856861000   5.091564000
}
set globals {
   basis aug-cc-pVDZ
   scf_type direct
   freeze_core True
   guess sad
   basis_guess 3-21G
}
energy('mrccsd(t)_l')

End of output

*** tstart() called on r3584
*** at Mon Feb 17 12:17:52 2014

  PSI4 interface to MRCC:
    Generating inputs for CCSD(T)_L.

    Automatically determined settings:
        method 4
        exlevel 3
        fullname CCSD(T)_L

    Orbital Information:

            Frozen Core [  24]
            Active DOCC [  70]
                   SOCC [   0]
         Frozen Virtual [   0]

              Total MOs [ 690]

    Beginning integral transformation.
    Presorting SO-basis two-electron integrals.
    Sorting File: SO Ints (nn|nn) nbuckets = 5

Stderr

iwl_buf_init: Can't open file 33
PSIO_ERROR: Can't find TOC Entry IWL Buffers
PSIO_ERROR: unit = 33, errval = 13
PSIO_ERROR: 13 (no such TOC entry)
Traceback (most recent call last):
  File "<string>", line 72, in <module>
  File "/apps/psicode/4.0b5.1/share/psi/python/driver.py", line 570, in energy
    procedures['energy'][lowername](lowername, **kwargs)
  File "/apps/psicode/4.0b5.1/share/psi/python/proc.py", line 2111, in run_mrcc
    psi4.mrcc_generate_input(level)
RuntimeError: PSIO Error
file: /short/z00/cyl900/psi4/psi4public/src/lib/libpsio/error.cc
line: 116

Formula for off-diagonal Hessian elements in /src/bin/findif/fd_geoms_freq_0.cc has inverse sing:
3-point - off-diagonal
O(1/h^2): new-way: [f(1,1)+f(-1,-1)+2f(0,0) -f(1,0) -f(-1,0) -f(0,1) -f(0,-1)]/(2h^2)
Implementation is the same.
But off-diagonal elements of the Hessian matrix (cross-derivatives) is:
[f(1,0) + f(-1,0) - f(1,1) - f(0,0)] + [f(0,1) + f(0,-1) - f(-1,-1) - f(0,0)]/(2h^2)
with a negative sign at f(0,0).
Does it mean that off-diagonal Hessian elements are calculated and stored with an opposite sign? or it is an issue?

The file src/lib/attic/libyeti/dataimpl.h is zero-length. Could it be removed?

Dear all,

 I tried to install the latest PSI4 on my PC, whose operating system is Fedora 14. I have passed the steps "./configure --with-opt=-O2" and "make" successfully according to PSI4's manual. However, I met a trouble in "make tests".  One of the error report is pasted below:

echo "Testing omp2_5-grad1..."
Testing omp2_5-grad1...
make -C omp2_5-grad1; true
make[2]: Entering directory `/usr/local/src/psi4/objdir/tests/omp2_5-grad1'
PSIO_ERROR: unit = 32, errval = 5
PSIO_ERROR: 5 (file not open or open call failed)
Traceback (most recent call last):
File "", line 38, in
File "/usr/local/src/psi4/lib/python/driver.py", line 671, in gradient
procedures['gradient'][lowername](lowername, **kwargs)
File "/usr/local/src/psi4/lib/python/proc.py", line 459, in run_omp2_5_gradient
run_omp2_5(name, *_kwargs)
File "/usr/local/src/psi4/lib/python/proc.py", line 440, in run_omp2_5
scf_helper(name, *_kwargs)
File "/usr/local/src/psi4/lib/python/proc.py", line 757, in scf_helper
e_scf = psi4.scf(precallback, postcallback)
RuntimeError: PSIO Error
file: /usr/local/src/psi4/src/lib/libpsio/error.cc
line: 116P
make[2]: *** [omp2_5-grad1.passed] Error 1

make[2]: Leaving directory `/usr/local/src/psi4/objdir/tests/omp2_5-grad1'

There are also many other error report which are similar to this.

I am wondering what cause these errors and how can I fix them. Can you help me to install PSI4 successfully?

Looking forward to any comments and suggestions! Many thanks!

Best Regards
Xin

The two files src/lib/misc/cfft.{cc,h} in the MADNESS directory have the following license/copyright statement:

// The code is property of LIBROW
// You can use it on your own
// When utilizing credit LIBROW site

This appears to be not compatible with any definition of Open Source.

Assuming that those two files are not required for the MADNESS interaction in PSI4 it would be easiest to remove them for now.

I have also reported this issue with the MADNESS developers.

Hi all,

I am trying Psi4 4.0.0-beta4 today, but encountered a problem when parsing input and fetching corresponding basis set info. Here is a sample input file,

=======================

! sample input

memory 500 mb

molecule test {
Li 0.000 0.000 0.000
}

set reference uhf
set globals = {
scf_type direct
basis 6-31G
e_convergence 10
}

this_energy = energy('scf')

=======================

running with Psi 4.0.0-beta4 on Linux, compiled with intel composer xe 2013 (x86-64)

The error message is:

=======================

Traceback (most recent call last):
File "", line 36, in
File "/home/ren/soft/Psi4/share/psi/python/driver.py", line 526, in energy
procedures['energy'][lowername](lowername, **kwargs)
File "/home/ren/soft/Psi4/share/psi/python/proc.py", line 489, in run_scf
scf_helper(name, **kwargs)
File "/home/ren/soft/Psi4/share/psi/python/proc.py", line 707, in scf_helper
e_scf = PsiMod.scf(precallback, postcallback)
RuntimeError: sanity check failed! Gaussian94BasisSetParser::parser: Unable to find the basis set for LI
file: /home/ren/soft/psi4.0b4/src/lib/libmints/basisset_parser.cc
line: 339

=======================

Is it a but or am I wrong anywhere?
I appreciate any help and suggestions,
Hao

Referring to
http://kojipkgs.fedoraproject.org//work/tasks/6231/5326231/build.log

PSI4 fails to build on the development version of Fedora. The error that occurs is

In file included from /builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/serialimpl.h:4:0,
from /builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/serialize.cc:2:
/builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/xmlarchive.h:241:14: error: 'void smartptr::XMLArchive::getAttribute(unsigned int&, const string&)' cannot be overloaded
void getAttribute(unsigned int& val, const std::string& attrname);
^
/builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/xmlarchive.h:237:14: error: with 'void smartptr::XMLArchive::getAttribute(size_t&, const string&)'
void getAttribute(size_t& val, const std::string& attrname);
^
/builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/xmlarchive.h:255:14: error: 'void smartptr::XMLArchive::setAttribute(unsigned int, const string&)' cannot be overloaded
void setAttribute(unsigned int val, const std::string& attrname);
^
/builddir/build/BUILD/psi4.0b4/src/lib/libsmartptr/xmlarchive.h:251:14: error: with 'void smartptr::XMLArchive::setAttribute(size_t, const string&)'
void setAttribute(size_t val, const std::string& attrname);

Fedora 19 has GCC 4.8 and Boost 1.53.0.

If I build psi4 and then run make distclean, I do not get the initial tarball content again, as the script doc/sphinxman/document_tests.pl overwrites samples/SUMMARY and some samples with new content. This makes Debian source package building fail after a build:

dpkg-source: info: local changes detected, the modified files are:
psi4.0b5/samples/SUMMARY
psi4.0b5/samples/dcft1/input.dat
psi4.0b5/samples/dcft4/input.dat
psi4.0b5/samples/dcft5/input.dat
psi4.0b5/samples/dcft6/input.dat
psi4.0b5/samples/pywrap-alias/input.dat

I think it would be best if (i) the samples are written to the builddir, or (ii) the samples are not shipped in the tarball in the first place, assuming all of samples/ is being autogenerated during doc-creation/installation anyway.

Few people know how to do this.

Hello,

It seems that there may be a problem with the normalization of the contraction coefficients in the molden wavefunction format for d functions (and higher). An example computation on an test molecule (NH3) where exactly the same basis sets were given to ORCA and PSI4 can be downloaded here:

https://dl.dropboxusercontent.com/u/4871688/moldenbug.tar.bz2

The molden files are almost the same, except for the contraction coefficients of the D functions.

Is there an authoritative source that can tell us what the correct normalization of the contraction coefficients in the molden file should be? Having different variants of the same format is a pain in terms of post-processing.

Issue causing pywrap-cbs1 to fail. Has existed for many months. Symptom:

terminate called after throwing an instance of 'psi::PsiException'
  what():  BasisSet::shell: requested shell is out-of-bounds.

Can generate with:

memory 250 mb

molecule {
O 0.0 0.0 0.0
H 1.0 0.0 0.0
H 0.0 1.0 0.0
O 3.0 3.0 3.0
H 4.0 3.0 3.0
H 3.0 4.0 3.0
}

set basis aug-cc-pvqz
set scf_type pk

energy('scf')

The libscf_solver code has a "Copyright 2008 by Justin M. Turney, Ph.D.. All rights reserved." copyright line below the GPL2+ boilerplate. I suggest to remove at least the "All rights reserved." if possible, as this makes it unclear which license is really considered applicable.

The attic/libsmartptr files have no license information, if they are not used (as hinted at by the attic location) I suggest to remove them for the next public release.

It would be nice to have restart capability for SAPT and other expensive calculations.

Lori says the parsing of manually specified (general) basis sets is a little quirky and could use improvement. We may have one user complaint on this topic we could use as a test case.

The detcas/detcasman code is still present, but disbled in Beta4. This issue is to track the status of the CASSCF code in PSI4.

Even though NWChem also has analytical gradients for CASSCF, at least I considered the CASSCF module a major part of the PSI3 functionality and it would be great to have it back in PSI4, in order to supersede PSI3 completely.

Is this a problem to force it to compile in C mode? Ryan encountered an issue here trying to compile on PACE where by carefully specifying all the options, the C++ compiler got used instead of C, and it didn't work. Is this a problem to be solved or is this a non-issue if it should always be possible to compile it as straight C?

The eps file doc/progman/svn/svn.eps.in is 1.4 MB and takes a long time to render in Gnome evince. Furthermore, it has the following commtens inside:

%%Copyright: Copyright(C)2000-2003 Adobe Systems, Inc. All Rights Reserved.
%%Copyright: Copyright(C)1997-2005 Adobe Systems, Inc. All Rights Reserved.

Apparently, doc/progman/svn.fig is the source for a previous version of this .eps. As the progman Makefile is no longer generated by configure.ac, maybe the whole directory could be yanked or the .eps regenerated with fig2dev (which also reduces the size to a few kilobytes)

Dear devs,

I've been running some dihedral-constrained optimizations on capped dipeptides, and a small percentage of them fail. Examples are attached.

In the first example, the optimizer takes a huge step and ends up in a crazy geometry. I worked around it by setting intrafrag_step_limit 0.1. Unfortunately I lost the .intco file, but the output file shows that two dihedrals have been constrained.

https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize.dat
https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize.out
https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize.xyz

In the second example, the energy oscillates with periodicity 3.

https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize-1.dat
https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize-1.out
https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize-1.xyz
https://dl.dropboxusercontent.com/u/5381783/psi4-opt/optimize-1.THR.intco

I'll try to work around this by using step_type nr, but thought it was worth reporting nonetheless.

Thanks,

• Lee-Ping Wang (Postdoc, Stanford)

I'm in the process of implementing forces in my own code, ERKALE. Related
to this, I was looking at the nuclear attraction integral derivative code
in PSI.

Interestingly, it would seem that there is a bug in PSI: the loop limits
are the same in the derivative code as in the normal attraction integral
code.

The relevant code in src/lib/libmints/osrecur.cc is

 int mmax = am1 + am2;

 double *F = new double[mmax+1];

 // Form Fm(U) from A20
 calculate_f(F, mmax, u);

 // Perform recursion in m for (a|A(0)|s) using A20
 for (m=0; m<=mmax; ++m) {
     vi_[0][0][m] = tmp * F[m];
 }
 for (m=0; m<=mmax-1; ++m) {
     vx_[0][0][m] = 2.0*zeta*PC[0]*vi_[0][0][m+1];
     vy_[0][0][m] = 2.0*zeta*PC[1]*vi_[0][0][m+1];
     vz_[0][0][m] = 2.0*zeta*PC[2]*vi_[0][0][m+1];
 }

Table X in the Obara-Saika paper states that
(s | Au | s)^(0) = 2 zeta ( Pu - Cu ) (s | A0 | s)^(1).

If you look at what the code above does, it gives a plain zero for this
integral.

Furthermore, if you look at the recursion formulas for the integral derivatives A(mu), you see that they are equivalent to the case A(0) with an additional term depending on A(mu-1i). However, in the initializations and the recursions the derivatives only go to mmax-1, not mmax.

dear psi4 team,

i am trying to restart an interrupted coupled cluster run, but to no avail. the input file has the following keywords:

set cceom restart_eom_cc3 true
set ccenergy restart true
set cclambda restart true
set ccresponse restart true

yet, in the output file in the ccenergy section i find:

Restart = No

the files psi.{pid}.* from the previous run are in the current working directory, permissions are correct. increasing verbosity didn't seem to help me to trace the problem - i am basically not sure what file and from where psi4 wants to read, and i cannot find it in the manual. could anybody please enlighten me?

cheers,
bartek

Most of the source code files don't contain license boilerplates. As the result, the program doesn't currently specify any license.

You really should include a LICENSE file in the distribution, e.g.
**
PSI 4 is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published
by the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

PSI 4 is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <​http://www.gnu.org/licenses/>.
**

Additionally, license boilerplates should be added ASAP to every source code file. A working example:
/*

•            This source code is part of PSI 4.
  
• PSI 4 is free software; you can redistribute it and/or
• modify it under the terms of the GNU General Public License
• as published by the Free Software Foundation; either version 2
• of the License, or (at your option) any later version.
  */
  This should be added to the beginning of every source file (.cc and .h)

Also, copies of the full licenses should also be included in the distribution. I have added a GPLv2 license to the source tree from ​http://www.gnu.org/licenses/gpl-2.0.txt; if parts of PSI4 are licensed with a different license they should also be included.

After each exit of any run the following crash happens:

Program received signal SIGSEGV, Segmentation fault.
subtype_dealloc (self=<Molecule at remote 0x1110c8c0>) at /usr/src/debug/Python-2.7.5/Objects/typeobject.c:955
955     ++ tstate->trash_delete_nesting;
Missing separate debuginfos, use: debuginfo-install atlas-3.8.4-8.fc19.x86_64 blas-3.4.2-2.fc19.x86_64 keyutils-libs-1.5.5-4.fc19.x86_64 krb5-libs-1.11.3-1.fc19.x86_64 libcom_err-1.42.7-2.fc19.x86_64 libselinux-2.1.13-15.fc19.x86_64 pcre-8.32-7.fc19.x86_64
(gdb) bt full
#0  subtype_dealloc (self=<Molecule at remote 0x1110c8c0>) at /usr/src/debug/Python-2.7.5/Objects/typeobject.c:955
        type = 0x10d7f9c0
        base = <optimized out>
        basedealloc = <optimized out>
        tstate = 0x0
#1  0x00007ffff6b92cb2 in xdecref<_object> (p=<optimized out>) at boost/python/refcount.hpp:36
        p = <optimized out>
#2  reset (this=0x1107b438) at boost/python/handle.hpp:249
No locals.
#3  boost::python::converter::shared_ptr_deleter::operator() (this=0x1107b438) at libs/python/src/converter/builtin_converters.cpp:35
No locals.
#4  0x0000000000710812 in psi::Process::Environment::~Environment() ()
No symbol table info available.
#5  0x000000374f2390a9 in __run_exit_handlers (status=0, listp=0x374f5b96e8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77
        atfct = <optimized out>
        onfct = <optimized out>
        cxafct = <optimized out>
        f = <optimized out>
#6  0x000000374f2390f5 in __GI_exit (status=<optimized out>) at exit.c:99
No locals.
#7  0x000000374f221b7c in __libc_start_main (main=0x699720 <main>, argc=2, ubp_av=0x7fffffffdb38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdb28)
    at libc-start.c:292
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -420104691260379722, 7149040, 140737488345904, 0, 0, 420104692152085942, -412673899392062026}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 
              0x1c22e20 <__libc_csu_init>, 0x7fffffffdb38}, data = {prev = 0x0, cleanup = 0x0, canceltype = 29503008}}}
        not_first_call = <optimized out>
#8  0x00000000006d1619 in _start ()

Is this a crash in python/boost misusing python/psi misusing boost and python?

There is no general copyright statement in the Beta5 source tree for the PSI4 source code proper, just the psirmrcc module (Evangelista/Simmonett), some libmints files (carried over from mpqc/libint), libsmartptr (Marcin Kalicinski?) and libscf_solver (Turney).

I think it would be advisable to have a clear copyright statement, at least in the README or LICENSE file with the names of all the authors (or "The PSI4 Developers" or something).

The statment should include the years and the names of the copyright holders.

The only thing which comes close it the WIREs journal reference output at the top of the PSI4 computational output.

Quicktests fail on Fedora rawhide i686. The test case output is

Testing pywrap-freq-e-sowreap...
Performing finite difference calculations by energies
13 displacements needed.
Computation complete.
Frequencies.......................................................PASSED
ZPVE..............................................................PASSED
SP energy.........................................................PASSED
SP NRE............................................................PASSED
SP NRE............................................................PASSED
SP NRE............................................................PASSED
Testing cc8...
\tFAILED
Testing cc18...
Nuclear repulsion energy..........................................PASSED
SCF energy........................................................PASSED
CCSD correlation energy...........................................PASSED
CCSD total energy.................................................PASSED
\tFAILED
Testing cc19...
\tFAILED
Testing cc28...
\tFAILED
Testing cc49...
\tFAILED

The cc??.test files are empty, but the output.dat's seem sane...

If the user wants to run DF-MP2 on a molecule containing an element like Li or He, we need to use the requested basis set for most of the atoms and then a more generic basis set for the tricky atom. It might be useful to let Python query basis set availability per atom --- apparently such queries are currently made C-side.

This seems a little silly that we can't do this at present (after a recent upgrade).

Can we create a portable Mac binary for binary distribution?

From Daniel Schofield, 2/7/14: "I have been attempting to run SAPT calculations in PSI4, but am having little success due to my inability to converge the df-hf step for one of my monomers (H2). I think this is due to a combination of using density fitting and the size of the ghosted basis set relative to this monomer i.e. if I run in a monomer centered basis set the calculation converges and if I run direct SCF (outside of SAPT) the calculation converges."

I have the test input/output files. Apparently the DF-HF is going non-variational on the dimer computation.

check other methods

When nso is much greater than the number of retained NO's, DFCC can hang while determining how many rows of a matrix to read from disk. This issue is fixed in the master branch, and I am attaching a patch here to fix issue in psi4.0b5. To apply the patch:

1. download the patch from https://gist.github.com/edeprince3/6023223
2. untar that directory to find the file dfcc.bugfix1.patch
3. go to the source directory psi4/src/bin/fnocc and copy the patch here
4. on the command line type: patch < dfcc.bugfix1.patch
5. move the patch and the newly created file ccsd.cc.orig somewhere else (or delete them)
6. recompile