Gamess (US) frequently asked questions. Part 7: How to distinguish alpha from beta orbitals in the $VEC deck

Each line in a $VEC group contains the coefficients of five basis functions for a given orbital. These are formatted in a special way, with seven numbers in each line. These numbers are:

1st) the number of the orbital to which the coefficients belong (written with at most two characters, so that 1 means orbital 1, .. , 99 means orbital 99, 00 means orbital 100) . This number is repeated in the beginning of every line, until all coefficients for that orbital have been written

2nd) this number tells the program how to assign the coefficients to the basis functions. "1" means that the coefficients are for basis functions 1-5, "2" means that the coefficients are for basis functions 5-10, etc. In general , that number "n" directs the program to assign the five coefficients present in the line to basis functions 5*(n-1)+1 to 5*n.

3rd to 7th) coefficients of five basis functions

BETA orbitals are punched as a group immediately after all ALPHA orbitals.

This format entails that in molecules with more than 100 orbitals the $VEC group contains several blocks with the same 1st number. For example, in a molecule with 200 orbitals, alpha orbital 27 is described by the first block of lines beginning with "27", and alpha orbital 127 is described by the SECOND block of lines beginning with "27".

I usually find the beginning of the BETA orbitals by repeating a search for the string " 1 1" : if that string is preceded by a block beginning with "00 1", it usually refers to orbitals 101, or 201, etc. (the exception being those systems with exactly 100, 200, etc. orbitals). If string " 1 1" is NOT preceded by a block beginning with "00 1", you are sure to have found the beginnning of the BETA orbitals

Gamess (US) frequently asked questions part 6: Obtaining proper SCF convergence (Anti-)ferromagnetic coupled Fe-S clusters

Obtaining SCF convergence of FeS clusters is a very demanding task.

The problem in FeS clusters is the arrangement of spins on the Fe atoms: if you have a cluster with 4 Fe atoms, each of them with 5 up-spins, and a total spin of zero, the arrangement of spins on the atoms could be

• Fe1 and Fe2  up-spin, Fe3 and Fe4 down-spin; or
• Fe1 and Fe4  up-spin, Fe2 and Fe3 down-spin; or
• Fe1 and Fe3  up-spin, Fe2 and Fe4 down-spin;

The problem is compounded if you have a mixture of Fe²⁺ and Fe³⁺, which may lead to 12 (or more) different spin arrangements, depending on the number of Fe²⁺ atoms. However, if you have a good guess SCF for one instance instance, you may simply substitute the coordinates of Fe2 with those of Fe4 to get a comparably good guess for the second instance, and so forth... This is the approach suggested by Greco, Fantucci, Ryde, de Gioia (2011) Int. J. Quantum Chem. 111, 3949-3960. Obtaining the guess for one of the instances is in itself quite difficult, and I usually follow the approach outlined by Szilagyi, R. K. and Winslow, M. A. (2006) J. Comput. Chem., 27: 1385–1397  .

It goes like this:

- obtain orbitals for bare Fe²⁺, Fe³⁺, S^2-, and isolated ligands, with proper spins on the Fe atoms (5/2 for Fe³⁺, 2 for Fe²⁺)

- Manually split the "alpha/up" and "beta/down" portions of the resulting  $VEC groups. For example, assuming you have a system with three Fe atoms (two Fe²⁺ and one Fe³⁺) with total spin S=5/2 and the $VEC groups for bare Fe²⁺ and bare Fe³⁺, you should cut the $VEC groups of Fe²⁺ and Fe³⁺ as:

$VEC  for the alpha (up) electrons of Fe²⁺   (let's call it "Fe2+_5_d_electrons")
$VEC  for the alpha (up) electrons of Fe³⁺   (let's call it "Fe3+_5_d_electrons")
$VEC  for the beta (down) electrons of Fe²⁺   (let's call it "Fe2+_1_d_electron")
$VEC  for the beta (down) electrons of Fe³⁺   (let's call it "Fe3+_0_d_electrons")

The total spin S=5/2 in this sample problem implies that  both Fe²⁺ atoms spins should annull each other, i.e., one Fe²⁺ is mostly "up" and the other is mostly "down". Building the new guess for the "up" electrons should therefore include:

"Fe2+_5_d_electrons" for one of the  Fe²⁺ ions,
"Fe2+_1_d_electrons" for the other  Fe²⁺,
"Fe3+_5_d_electrons" for the Fe³⁺

Building the new guess for the "down" electrons should  include:
"Fe2+_1_d_electrons" for the FIRST Fe²⁺ ions,
"Fe2+_5_d_electrons" for the other Fe²⁺,
"Fe3+_0_d_electrons" for the Fe³⁺

- combine the orbitals using the small utility called combo, which you may obtain from Alex Granovsky's Firefly website.

- Manually paste the "alpha" and "beta" guesses  into a single $vec group, which would be the proper guess.

- cross all your fingers and toes, and expect it to converge into the proper state. If it does not converge, change convergers (SOSCF=.T. DIIS=.F.), onset of SOSCF (SOGTOL=1e-3) , etc.

- after SCF optimization using this guess, manually scramble the ordering of Fe atoms in your input, to ascertain whether a lower energy solution can be obtained with a different spin distribution.



Good Luck!

Gamess (US) frequently asked questions Part 5: "THE VIBRATIONAL ANALYSIS IS NOT VALID"

Gamess (US) and Firefly by default assume geometric convergence has been achieved when the maximum gradient is below 1e-4 and the RMS gradient is smaller  than 1/3 of the maximum gradient.  This convergence criterion may be changed by the user with


 $STATPT OPTTOL=<your desired convergence criterion> $END


It is well known that the vibrational analysis is strictly valid mathematically when the Hessian is computed in true stationary points (i.e when the gradient is exactly equal to zero). If the maximum gradient is sufficiently close to zero, the vibrational analysis (although not absolutely correct) is still close enough to the "true" solution for all practical purposes.



This introduction brings us to today's FAQ. A recurring question in both the Gamess-US list and the Firefly forums concerns the message often printed by the program after a vibrational analysis:

*THIS IS NOT A STATIONARY POINT ON THE MOLECULAR PES THE VIBRATIONAL ANALYSIS IS NOT VALID*

This message arises from the way gradients are analyzed by Gamess: gradients are originally computed in one set of coordinates (cartesian coordinates, I believe) , and then transformed into the  coordinate system specified by the user. Optimizations stop when the "transformed gradient" lies below OPTTOL, but Gamess uses the original, non-transformed, gradient to decide whether to consider the geometry as a stationary point on the molecular PES.  Therefore, if  the geometry is converged, the scary message in capital letters above may be safely disregarded. When in doubt, simply decrease your OPTTOL value, continue the optimization and re-compute the hessian.

Gamess (US) frequently asked questions Part 1: SCF convergence

In spite of the very high quality of the Gamess(US) documentation, the Gamess(US) list is very often flooded with requests from new users regarding the lack of convergence of the SCF procedure. A few words of advice:

When your SCF does not converge,  you should re-run the job including a $guess guess=moread $end line, as well as the complete $VEC group present in the output PUNCH file (usually called <jobname>.dat, and present in you scratch directory).

Addendum:

Whenever you read a $VEC group from a UHF run you must assign NORB in the $GUESS group. An additional problem is that by default the $VEC group only includes the occupied orbitals, and this means that in UHF runs the $VEC group does not include equal numbers of alpha and beta orbitals (e.g., a run with 41 electrons and MULT=2) will have 21 alpha orbitals and 20 beta orbitals. Therefore, if you include

$guess guess=moread NORB=21 $end

Gamess will crash because there are not 21 beta orbitals, and if you input

$guess guess=moread NORB=20 $end

there will be another error, since there are more than 20 alpha orbitals. In these cases, you should check the number of alpha and beta orbitals. Then , copy the coefficients of the extra alpha orbitals to the end of the beta orbitals. In my example above

$guess guess=moread NORB=21 $end

will yield no problems, since the modification of the VEC group yields equal numbers of alpha and beta orbitals. There is also an option to PUNCH every orbital (occupied+virtuals) at every step. In this case, Gamess always punches a full $VEC group, making it very easy to assign NORB as one can simply inspect the output file to learn the number of orbitals. However, this yields gigantic PUNCH files, and may therefore not be feasible.

You should also experiment with changing convergers, damping, etc. Some systems are notoriously hard to converge, and may require several re-iterations of the whole process.