TURBOMOLE Users Forum
TURBOMOLE Modules => Ricc2 => Topic started by: tom on February 18, 2010, 11:10:23 AM
-
I am trying to do an excited state geometry optimization of a molecule (50 atoms) in C1 symmetry with Turbomole 6.0.5. When I invoke jobex with
nohup jobex -level cc2 -c 200 -gcart 4 > jobex.out
from the extended hückel MO guess, the optimization starts with a dscf step, which proceeds without errors. Then, it says in the job.last:
fine, there is no data group "$actual step"
next step = ricc2
STARTING ricc2 ON 8 PROCESSORS!
And the ricc2 program seems to start, but at the end of job.last, still in the ricc2 section (!)
*---------------------------------------------------------------------*
| simplified C1 algorithm will be applied |
*---------------------------------------------------------------------*
MOs are in ASCII format !
reading orbital data $scfmo from file mos .
orbital characterization : scfconv=8
fine, there is no data group "$actual step"
next step = ricc2
The next thing is the job.1 output, which indicates statpt has started, which terminates with:
<getgrd> : data group $grad is missing
MODTRACE: no modules on stack
error reading energy and gradient in rdcor
statpt ended abnormally
statpt step ended abnormally
next step = statpt
Of course, since ricc2 didn't do anything, it doesn't find a gradient.
I don't see any further output which indicates what could have gone wrong in the ricc2 step. What could be the problem here?
[By the way, can someone responsible please correct the '-level CC2' to '-level cc2' in the Turbomole Manual, p 161 and p 162, or make the jobex options case-insensitive? Using the wrong case doesn't start the calculation, which is really annoying if you had to spend a lot of time in the queue waiting for 8 processors to be available.]
My control file looks like this:
$title
$operating system unix
$symmetry c1
$coord file=coord
$user-defined bonds file=coord
$atoms
c 1,3,7,9-10,13,15-16,18,47 \
basis =c TZVP \
cbas =c TZVP
si 2,4,6,8,11,14,46 \
basis =si TZVP \
cbas =si TZVP
o 5,12,17 \
basis =o TZVP \
cbas =o TZVP
h 19-45,48-50 \
basis =h TZVP \
cbas =h TZVP
$pople AO
$basis file=basis
$rundimensions
dim(fock,dens)=181492
natoms=50
nshell=307
nbf(CAO)=601
nbf(AO)=581
dim(trafo[SAO<-->AO/CAO])=641
rhfshells=1
$scfmo file=mos
$closed shells
a 1-106 ( 2 )
$scfiterlimit 30
$scfconv 8
$thize 0.10000000E-04
$thime 5
$scfdamp start=0.300 step=0.050 min=0.100
$scfdump
$scfintunit
unit=30 size=0 file=twoint
$scfdiis
$scforbitalshift automatic=.1
$drvopt
cartesian on
basis off
global off
hessian on
dipole on
nuclear polarizability
$interconversion off
qconv=1.d-7
maxiter=25
$optimize
internal off
cartesian on
global off
basis off logarithm
$coordinateupdate
dqmax=0.3
interpolate on
statistics 5
$forceupdate
ahlrichs numgeo=0 mingeo=3 maxgeo=4 modus=<g|dq> dynamic fail=0.3
threig=0.005 reseig=0.005 thrbig=3.0 scale=1.00 damping=0.0
$forceinit on
diag=default
$energy file=energy
$grad file=gradient
$forceapprox file=forceapprox
$lock off
$maxcor 3000
$denconv 0.10000000E-06
$cbas file=auxbasis
$ricc2
cc2
geoopt model=cc2 state=(s1)
maxiter=512
$excitations
irrep=a multiplicity= 1 nexc= 1 npre= 0 nstart= 1
spectrum states=all operators=diplen
exprop states=all operators=diplen
$actual step statpt
$statistics off
$2e-ints_shell_statistics file=metastase
$orbital_max_rnorm 0.13254929937581E-05
$last SCF energy change = -2643.8866
$dipole from dscf
x 0.66022338137571 y -1.35803464827535 z 0.00000000000396 a.u.
| dipole | = 3.8381107999 debye
$TMPDIR /home/flock/tmp/
$SHAREDTMPDIR
$end
-
Hi,
please change
geoopt model=cc2 state=(s1)
to
geoopt model=cc2 state=(a 1)
This should do the trick.
Cheers,
Arnim
-
No, unfortunately that did not change anything.
-
OK, finally I figured out that it was some write permission problem on the tempdir. It would have been nice if some error message would have given this hint.
-
Hi,
finding the error messages in the parallel version is sometimes a bit tricky. The error could be printed in the slave<N>.output file, in the job.* files, in the master output file, or in the error output of the queuing system - and in case that the kernel/glibc kills the process, in /var/log/messages (segmentation faults because of too low user limits are often not printed to any of the output files...). So depending on the kind of error (memory access, I/O, permissions, network problem, ...) an error message will be printed somewhere else. The only option to avoid that would be to have just one single output file for all programs and clients - as you know the overlap of that with respect to the default way in Turbomole is exactly zero :(.
Regards,
Uwe