QUANTUM CHEMISTRY

Frequently Asked Questions:

For a comprehensive guide to the basic operation of TURBOMOLE, please see the documentation. However, this FAQ may help with some of the more quirky features of the program package.

Index list


Which viewers can be used with Turbomole?


Which builders can be used for TURBOMOLE?

The graphical user interface TmoleX is able to read in coordinates in various formats and can be used to build new molecules or modify existing ones.
In principle, any builder that is able to write xyz files can be used. TURBOMOLE comes with a script (x2t) that converts xyz files to TURBOMOLE coordinates. Once you have the coordinates, just use define to build the rest of the input or use the graphical user interface TmoleX.


The test suite script TTEST does not work.

Check the following points:


Some programs do not run, they crash with Segmentation fault or Bus error or some incomprehensible error output - or even without any error output at all!

Please check if your user limits are sufficient.

sh/bash/ksh users: please do a ulimit -a to get your actual limits. The output should look like:

core file size (blocks)0
data seg size (kbytes)unlimited
file size (blocks)unlimited
max locked memory (kbytes)unlimited
max memory size (kbytes)unlimited
open files1024
pipe size (512 bytes)8
stack size (kbytes)unlimited
cpu time (seconds)unlimited
max user processes8191
virtual memory (kbytes)unlimited

Important entries: data size, stack size, max memory size, and virtual memory should be either unlimited or as big as your total RAM.

To set, e.g. the stack size to unlimited, do:

ulimit -s unlimited

csh/tcsh users: please do limit and check the output.

Again, like given above, the limits should be at least as high as your memory available.
The syntax for changing the limits in csh/tcsh is:

limit stacksize unlimited

And please note that on 32bit machines, unlimited can be the same as 4GB (4194303 kbytes).

If you are using a queuing system:

Note that if you are submitting jobs to a queue, the user limits might be different from what you get when you log in on the machines! To check your limits, you have to add ulimit or limit in the script that is sent to the queue. Like:

....
ulimit -a > mylimits.out
jobex -ri -c 200 -statpt > jobex.out

...

send it to the queue and look in the file mylimits.out to see how the settings are.

Parallel version:

The parallel binaries are being started by the mpirun command which often uses ssh to start a process on a remote node. The limits for the stack size can not be set by the user in such a case, so everything in $HOME/.profile, $HOME/.bashrc, etc. will not help to get rid of the problem.

To check the limits on a node, try (sh/bash/ksh syntax):

ssh machinename ulimit -a

If the ssh command gives a lower stack size than unlimited or a large number, you have to change the file

/etc/security/limits.conf

on all nodes where the parallel binaries might run, and add there the line (example for 4GB limit)

* soft stack 4194303

Redo ssh machinename ulimit -a and you should get 4GB stack size limit, as it is set in limits.conf now.

On systems like Tru64 Unix, HP-UX or IBM AIX the maximal stack size might be limited by a kernel parameter. Try to set the stack size to a value as high as possible. And ask your system administrator if that still is not sufficient.


The parallel version does not run.

Check the following points:

Important:


When I run the parallel Linux version, only one node is used as client for the calculations.

If you do not run the calculations from a queuing system like PBS, SGE, LSF,... the TURBOMOLE scripts will run on one node by default.

You can set the environment variable HOSTS_FILE to a file that contains a list of nodes. More details can be found in the TURBOMOLE documentation.


How can I carry out a geometry optimization if define fails to generate a full set of internal coordinates?

Use internal redundant coordinates by using the ired command in the coordinate main menu in DEFINE.

Two other possibilites are to construct internal coordinates by hand (and check with DEFINE that they are linearly independent) or to use Cartesian coordinates (which will make the optimization considerably slower) by setting

$optimize
internal off
redundant off
cartesian on

in the control file.


I have deleted the files energy, gradient and forceapprox in order to start a new geometry optimization on the same system using the old control file. DSCF and GRAD run properly, but RELAX crashes with the error

force constant matrix will be read from $forceapprox
$forceapprox : could not find file !
relax step ended abnormally
STOP HREAD : error reading $forceapprox !

Why?

Because of the entry $forceinit off in the old control file, RELAX expects to find the approximate force constants to help it update the geometry. Change this to $forceinit on (simply enter finit at the command line to change it), rerun RELAX and then restart the geometry optimization from a DSCF step.


What does this error from RIDFT mean?

MISSING BASIS SET SPECIFICATION(S) IN $atoms
BE SURE TO ADD THE REMAINING BASIS SETS !

You may have changed the $atoms data group in the control file by hand, but the lines have become confused. All the data for each atomic type must be on one line - the line is continued using a backslash, for example

$atoms
o 1-2 \
jbas =o SVP \
basis =o SVP


RELAX stops with an error about internal coordinates:

keyword $intdef missing in file

but I don't use internal coords at all!

If you have tried to automatically generate internal coordinates and 'iaut' failed, or if you have started with internal coords and changed later to another symmetry and told DEFINE that you do NOT want to use internal coordinates, it sometimes happens that the control file won't be changed. Check that you've switched to cartesian optimization:

$optimize
internal off
redundant off
cartesian on


The JOBEX script does not stop, although energy and gradient have reached convergence.

If you have switched from internal to cartesian coordinates or vice versa, check that in the control file only the appropriate keyword exists:

$maximum norm of cartesian gradient = 0.85863061E-09
$maximum norm of internal gradient = 0.10462894E-01

in this example, an geometry optimization with cartesian coordinates will run forever since JOBEX also checks for the internal gradient which never will reach convergence...


After running RIDFT once, I resorted the atoms in $coord, ran DEFINE and tried RIDFT again. But the energy changed by many Hartrees and the results are clearly nonsense. What has gone wrong?

Some inconsistencies in the control file slip past DEFINE. In this example the order of the atoms in the data groups $atoms and $coord are different, so that the wrong basis sets are used. The solution is to delete $atoms and rerun DEFINE, or correct $atoms by hand.


If you still have problems after checking this FAQ and after reading the documentation, please contact us.

© Copyright 1999-2010 COSMOlogic GmbH & Co. KG, All rights reserved | Contact | Impressum