NEVPT2 calculations

[Max]

Dear Dalton users and developpers,

I'm interested in performing CASSCF/NEVPT2 calculations on some
transition metal complexes, using DALTON2013.1. After having
started the calculations on a Cray XE6, I decided to rather
perform them on a local cluster: those locally provided resources
actually suffice and also because the allowed timelimit is larger.

The sources have been compiled on the XE6 with the Intel compiler,
and on the local cluster with the GG compiler (compilation details
are given at the end of the message).

The results obtained for a same test calculation performed on the XE6
and on the local cluster differ, as shown below:


Intel-compiler compiled code
--

STATE DIAGONALISATION PERTURBATION SC-D PERTURBATION PC-D
1 -1828.30058432 -1831.77601500 -1831.79545401


GCC-compiled code
--

STATE DIAGONALISATION PERTURBATION SC-D PERTURBATION PC-D
1 -1828.30058432 -1831.16943365 -1831.18895840


The CASSCF results are the same, but the NEVPT2 ones are not.

In view of this, I've run the test "DALTON/test/energy_nevpt2_gs"
with both executables: the energies are the same as those given
as references in "test/trueresult/energy_nevpt2_ex.ref". So it's
not clear to me where to start from for looking for a possible bug.


Going through the output, I've noticed that an integer is not
correctly printed:

[...]
number of single differences= 3769404
number of double differences= 74084604
number of triple differences= 778092564
number of quadruple differences= -344286088
[...]

This is the variable "nfours" in "DALTON/sirius/koopro4.F". So could
this be due to the way integers are handled on going form one compiler
to the other ?

If needed I can provide the input and the punched molecular orbitals.

Thanks in advance for your help.

Best regards,
Max






Compilation information -> XE6 (Intel compiler / 13.1.0.146)
-----------------------

Host | rosa101
System | Linux-2.6.32.59-0.7-default
CMake generator | Unix Makefiles
Processor | x86_64
64-bit integers | OFF
MPI | ON
Fortran compiler | /opt/cray/xt-asyncpe/5.16/bin/ftn
Fortran compiler version | unknown
C compiler | /opt/cray/xt-asyncpe/5.16/bin/cc
C compiler version | unknown
C++ compiler | /opt/cray/xt-asyncpe/5.16/bin/CC
C++ compiler version | unknown
Static linking | OFF
Last Git revision | 653a3c9fdcde6b463c7e208ddf10abd66f7c54f6





Compilation information -> local cluster (GCC compiler)
-----------------------

Host | master.cluster
System | Linux-2.6.32-358.23.2.el6.x86_64
CMake generator | Unix Makefiles
Processor | x86_64
64-bit integers | OFF
MPI | ON
Fortran compiler | /usr/mpi/gcc/openmpi-1.6.5/bin/mpif90
Fortran compiler version | GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
C compiler | /usr/mpi/gcc/openmpi-1.6.5/bin/mpicc
C compiler version | gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
C++ compiler | /usr/mpi/gcc/openmpi-1.6.5/bin/mpicxx
C++ compiler version | unknown
BLAS | /usr/lib64/libblas.so
LAPACK | /usr/lib64/liblapack.so
Static linking | OFF
Last Git revision | 653a3c9fdcde6b463c7e208ddf10abd66f7c54f6

[bast]

hi Max,
i know nothing about that code part but the "negative" integer indicates
that some integers become too large to fit into 32 bits and wrap around.
i would compile for 64bit integers and see what happens:

Code: Select all

./setup --int64 ...

good luck!
radovan

[Max]

Hi Radovan.

I didn't compile for 64bit intergers after having read somewhere that there were issues with the execs..
cannot rememnber where.

Anyway, I'l give it a try

Best,
Max

[bast]

by default i would go for 32bit integers because it's better tested and better supported
by MPI and math libs. but sometimes you have no other choice and this could be such a case.
in principle nothing wrong with 64bit integer binaries but one has to be careful
with math libraries (not all can cope with 64bit integers, MKL can, in doubt you can use builtin),
and some tests probably fail which maybe ok or not depending on what you run.
but it's good to double check this issue.