Tips and Troubles

Questions

• Is there a restart option for excitation calculations?
• Can the SAOP potential be used for g-tensor calculations?
• Can I find the eigenvalue of S² in the output ?
• Where can I find the total energy in the output?
• Can I do geometry optimizations with ZORA?
• Can I calculate the g-tensor and A-tensor in one calculation?
• Can I calculate frequencies for selected vibration modes?
• With ADF one can use BLYP, but not B3LYP?
• Are Time-dependent DFT calculations compatible with the COSMO model?
• Is there any way to derive UV/visible absorption values by using ADF?
• Is it possible to use TDDFT for unrestricted systems in ADF?
• Can I do excited state geometry optimizations with TDDFT?
• What MM force fields are available?
• Can I use Gaussian type basis functions in ADF?
• Can I determine Raman intensities for open-shell systems?
• Does ADF calculate zero-field splittings?

• How do I calculate the second-hyperpolarizability, GAMMA?
• Why is the relativistic ZORA FULL option not working for my property?
• Why is the U.5d basis set in the ZORA/TZ2P directory the same as the one in ZORA/TZP?
• Can I use non-relativistic basis sets in ZORA calculations?
• What values should the fitcoefficients have if I make my own basis set?
• I have a crystal structure. Which atoms should I put in the ADF calculation?
• Why is there no frozen core Au basis set with 11 valence electrons, but only Au.4d and Au.4f?
• Why should one use Hirshfeld or Voronoy charges rather than Mulliken ?
• The SCF in ADF does not converge. What to do?
• Why are my g-tensor results for some Cu(II) complexes not so accurate?
• In my geometry optimization I run into serious orbital occupation problems. What should I do?
• How can I do a spin-restricted open-shell calculation for the calculation of the A-tensor?
• Why do I get a huge bonding energy in spin-orbit coupled calculations?

• Can a TAPE21 (or TAPE41) generated on one platform be used on another platform?
• Do you have any performance data for ADF with high speed interconnects: notably, SCI and Myrinet?
• iraloc: exceeded maximum memory
• CIO_ERROR cio_llwrite: lseek failed (TAPE10_0,fd=6,rec=524290)
• BAD ETA INTEGRALS
• Connection refused when using MPICH version of ADF
• adf.exe: error while loading shared libraries: libX11.so.6: cannot open shared object file
• Molekel cannot read energy levels.
• ADF-GUI does not work on my computer. What to do?
• Where can I send a bug report?

Answers

No. Excitation calculations in ADF usually do not take much longer than the SCF, so a restart option is almost never needed.

Yes. Because of the asymptotically correct behavior of this potential in the outer region, improved results are typically obtained for property calculations. This has already been demonstrated for excitations, polarizabilities, and NMR chemical shieldings.

Starting from the ADF version 2004.01, the expectation of S² is calculated in case of unrestricted calculations.

ADF does not calculate total energies. It calculates difference energies with respect to fragment energies. By default, these are the spherical spin-restricted atoms. For this reason total energies from other programs cannot be compared to ADF directly. Only energy difference comparisons are meaningful. These are the only energies that play a role in chemistry of course.

At the moment one can perform scalar relativistic geometry optimizations and frequency calculations in ADF. The preferred method for this is ZORA. Spin-orbit geometry optimizations and frequency calculations are not (yet) possible.

Starting from the ADF version 2004.01 both g-tensor and A-tensor can be calculated with spin-unrestricted spin-orbit coupled calculations in the collinear approximation. Spin-unrestricted effects are important especially for the A-tensor.

Because ADF currently starts from Cartesian displacements, this is not currently possible.

One can not use B3LYP as XC-potential. Starting from the adf2004.01 the B3LYP energy can be calculated post SCF (keyword HFEXCHANGE and METAGGA) using orbitals from a different XC-potential. One should include the keyword HFEXCHANGE also in the create of the atoms. Starting from the adf2006.01 the B3LYP potential can be also be calculated.

Yes, it is be possible to combine COSMO and TDDFT. The usually major effect (modified zeroth order KS orbitals and orbital energies) is then included. However, COSMO should also modify the first-order change in the KS potential. This effect has not yet been implemented and will certainly be important in case of a high value for the dielectric constant.

Yes, the TDDFT modules (keyword EXCITATIONS) will give you the peak positions and intensities for general closed-shell molecules. This can be combined with the ZORA scalar relativistic option.

Not yet.

Not yet.

Currently Sybil, Amber95, and UFF are available within ADF.

No. ADF uses Slater Type Orbitals (STOs), which are better from a theoretical point of view. Typically fewer STOs than GTOs are needed to reach a certain level of accuracy.

One can do the following by hand.
First calculate the normal modes "q" with ADF. Then calculate the polarizability tensor by applying finite electric fields at the geometries q_o + dq and q_o - dq. From this one can obtain, by double finite difference, the derivative of the polarizability w.r.t. a particular normal mode of interest. This should be less time-consuming then a regular Raman calculation as well.

No.

The beta tensor can be obtained by using the input key RESPONSE, for example:
RESPONSE
HYPERPOL 0.03
DYNAHYP
ALLCOMPONENTS
END
In order to obtain gamma, one should calculate beta in small electric fields. Such a field can be switched on by specifying, for example:
EFIELD 0 0 0.001
for an electric field of 0.001 a.u. in the z-direction The beta calculation needs to be repeated for different field directions. gamma_zzzz can be obtained from (for example):
gamma_zzzz = beta_zzz (E=0.001 z) - beta_zzz (E=-0.001z) / (2 * 0.001)
Similar relations hold for other tensor components.

The relativistic ZORA full option is becoming obsolete. We recommend to use the default ZORA option. For example, geometry optimizations are implemented only for the default scalar ZORA option.

The reason for doing this is to make the TZ2P basis set complete, which may be convenient in case a user is doing everything within the same basis. In this case the TZP basis set is already of TZ2P quality. The removal of a basis function will, however, reduce the quality to below TZP. Note that for most lanthanide and actinide frozen core basis sets going from TZP to TZ2P will not give you extra basis functions.

One should not use frozen core non-relativistic basis sets in ZORA calculations. However, for the light elements, say from H-Kr (Z=1-36), one can use all-electron non-relativistic basis sets in ZORA calculations. Note that, especially for the heavier elements, the core orbitals are described better with ZORA optimized basis sets (of the same size).

Simply specify only zeroes. Leave it unchanged, if you use an existing fit set. This will only affect the number of cycles in an atomic "Create" run, which will converge anyway.

Generally speaking, one can of course say that a larger cluster is a better approximation to a solid than a small one. However convergence may be not so fast. Often one puts point charges at appropriate places to get a better model of the solid. The number of electrons that you put in your cluster is important. One can think of using hydrogen atoms at places where covalent bonds are broken.

Au basis sets with a larger frozen core have been removed because they sometimes gave unreliable results due to the too large frozen core, although such a basis sets is still available for the BAND program.

Mulliken is very much basis set dependent and hence unreliable. The other two methods do not suffer from this and usually seem to give good agreement with chemical intuition.

Sometimes it helps to use the key OCCUPATIONS, in order to explicitly specify occupation numbers. There are several other ways to make sure that the SCF converges. They are described in the Troubleshooting section of the ADF User's Guide. (KEEPORBITALS, ELECTRON SMEARING)

The LDA or Becke-Perdew functionals implemented in ADF are apparently somewhat deficient for such molecules. These functionals might give too covalent bonds between Cu(II) and the ligands.

Geometry optimizations in cases where the SCF does not converge properly (or differently on different geometry iterations) are suspect or even useless. So, the question is how to ensure proper convergence of the SCF. There are several hints on this in the User's Guide. The first advice is probably to use the OCCUPATIONS keyword to avoid flipping occupations.

For a spin restricted open-shell calculation, save TAPE21, and use the whole molecule as a fragment in a SR unrestricted calculation with the keywords:
scf
iter 0
end
This will do the trick. ADF wil use the fragment density coming from the spin-restricted calculation as start-up density in the unrestricted calculation. iter 0 means that only 1 scf-iteration will be performed with the use of the fragment density (one should use the same XC-potential in both calculations of course), such that the alpha-orbital energies remain degenerate with the beta-orbitals.

In ADF you need a scalar relativistic fragment if you want to do a spin-orbit calculation. Thus the bond energy also contains the effect of spin-orbit coupling. Spin-orbit coupling has a huge effect, especially on the 2p core orbitals. In first order the effect of spin-orbit coupling on fully occupied 2p-orbitals is zero. However, higher order effects of spin-orbit coupling are large for heavy elements. You can see this already if you look at the hydrogen-like spectrum of a heavy element, like for example U91+ spinor energies
2p_1/2: -1257.39
2p_3/2:-1089.61
average: (2*2p_1/2+4*2p_3/2)/6: -1145.54 is lower than the scalar relativistic orbital energy of U91+
2p:-1130.34
Thus especially if you do all-electron calculations you will see a large bonding energy.

A TAPE21 can always be made readable using the dmpkf command, and transformed back to the binary KF format with udmpkf. This would be a pragmatic solution for transferring KF-files if they would be incompatible on the different platforms.

Tests were performed with Myrinet. ADF is not so dependent on communication speed as we try to keep communication to a minimum. FastEthernet with a switch seems to be good enough for ADF, although Myrinet should be somewhat faster for calculations with 16 or more CPUs.

Part of ADF uses a static array with a dimension that can be controlled by the input. The error that is printed in the output file, is caused by the exceeding of this array. The dimension of the array can be modified in your input file, using the keyword MAXMEMORYUSAGE, for example
MAXMEMORYUSAGE 256
to use 256 MB. Memory claimed in this way is unavailable for the rest of the program through normal allocate statements, so in principle it should not be made larger than necessary. Using more processors may help to reduce the amount of memory needed. Sometimes calculations are just too big to fit on your computer.

This CIO_ERROR seems to indicate that a TAPE10 has passed a certain limit, for example 2GB. This is a limit for the adf executable on certain platforms. Or it can mean that your harddisk is full. If ADF is run in parallel, the file sizes per CPU reduce significantly. That would mean that the calculation might run normally on more CPUs.
This problem should no longer exist in ADF2004.01 and later. If you have enough free disk space, you should be able to run jobs that generate large files even on a single CPU.

This message shows that the numerical integration is not as accurate as required (currently tested only with spin-orbit calculations). You can force the calculation to continue using the
ALLOW BADINTEGRALS
input key. This will force the calculation to continue, but remember there are possible inaccuracies due to these integrals. You can probably increase the accuracy of the eta integrals by increasing the overall integration accuracy (using the integration key). One will then probably still get the BAD ETA INTEGRALS message, but this is relative to the required accuracy. One can check the accuracy (it is printed on output), and if the accuracy is good enough one can use the ALLOW BADINTEGRALS key to force the calculation to continue.

This error usually occurs in the configurations where connection between nodes via RSH is forbidden for various reasons. Since MPICH (and hence ADF) uses RSH by default, the connection to other hosts becomes impossible.

The solution in this case is to set environment variable P4_RSHCOMMAND to the name of a shell that replaces rsh, for example /usr/bin/ssh. Before using ADF with ssh make sure that unhindered connection between nodes using the new shell is possible. That is, if you are using ssh, make sure that the "ssh nodeXXX date" does not ask for a password and does not ask you to add the nodeXXX computer to the list of known hosts. The latter is usually the source of failed connections using MPICH with ssh.

This error usually means that X11 files are not installed on (some of) the computing nodes. Right now, the solution would be to install X11 libraries on each node where ADF is going to be used.

In ADF2004, there were some changes made regarding the printed output, which probably confuses Molekel and probably some other programs that parse ADF output. SCM generally discourages using .out files as input to visualization programs as this file format is subject to frequent changes. For example, new functionality or new literature references or simply readability enhancements can easily break such a program. From our point of view, the TAPE21 file format is more suitable for this purpose and should be used whenever possible.

Unfortunately, the choice of platforms on which we can support the GUI (as well as ADF itself) is limited. But the good news is: you can compile ADF-GUI yourself. This option involves some work but it gives the best result. I'll try to explain how to compile ADF-GUI on your platform. First, you need a working C++ compiler. GCC3 works best in most cases. Then, you need to build ADF, Cmake, and, finally, the GUI in thirteen easy steps:

1. Download and unpack ADF source distribution
2. Download and unpack ADF binary distribution for your platform on top of the source.
3. Configure and compile serial version of ADF as you would normally do.
4. If you have cmake version 2+ installed, skip to step 9.
5. Untar Install/cmake*.tgz in ADFHOME
6. cd to the cmake source directory created in the previous step.
7. Run ./configure (pay attention to the --prefix option if you're installing it in a non-default location)
8. Run "make" followed by "make install".
9. Untar Install/vtk.tgz in $ADFHOME
10. Copy Install//CMakeCache.txt to VTK/CMakeCache.txt
11. Edit VTK/CMakeCache.txt in the parts containing path names
12. Run "cmake ." followed by "make" and watch the show. Compilation may take a few hours depending on the computer speed.
13. Run "make install". You should have a new ADF-GUI working now.

If you believe you have encountered a bug in the software, please send an E-mail with a clear description of the problem to bugs@scm.com. We may then at a later stage request the complete input and output files from you, so that we can try to reproduce the problem on our machines.