How to do RHF, ROHF, UHF, and GVB calculations

General considerations

These four SCF wavefunctions are all based on Fock operator techniques, even though some GVB runs use more than one determinant. Thus all of these have an intrinsic N**4 time dependence, because they are all driven by integrals in the AO basis. This similarity makes it convenient to discuss them all together. In this section we will use the term HF to refer generically to any of these four wavefunctions, including the multi-determinate GVB-PP functions. $SCF is the main input group for all these HF wavefunctions.

As will be discussed below, in GAMESS the term ROHF refers to high spin open shell SCF only, but other open shell coupling cases are possible using the GVB code.

Analytic gradients are implemented for every possible HF type calculation possible in GAMESS, and therefore numerical hessians are available for each.

Analytic hessian calculation is implemented for RHF, ROHF, and any GVB case with NPAIR=0 or NPAIR=1. Analytic hessians are more accurate, and much more quickly computed than numerical hessians, but require additional disk storage to perform an integral transformation, and also more physical memory.

The second order Moller-Plesset energy correction (MP2) is implemented for RHF, UHF, ROHF, and MCSCF wave functions. Analytic gradients may be obtained for MP2 with a RHF reference function. MP2 properties are formed only by RHF gradient runs, or if you select MPPROP in the $MP2 group. All other cases give properties for the SCF function.

Direct SCF is implemented for every possible HF type calculation. The direct SCF method may not be used with DEM convergence. Direct SCF may be used during energy, gradient, numerical or analytic hessian, CI or MP2 energy correction, or localized orbitals computations.

direct SCF

Normally, HF calculations proceed by evaluating a large number of two electron repulsion integrals, and storing these on a disk. This integral file is read back in during each HF iteration to form the appropriate Fock operators. In a direct HF, the integrals are not stored on disk, but are instead reevaluated during each HF iteration. Since the direct approach *always* requires more CPU time, the default for DIRSCF in $SCF is .FALSE.

Even though direct SCF is slower, there are at least three reasons why you may want to consider using it. The first is that it may not be possible to store all of the integrals on the disk drives attached to your computer. Secondly, the index label packing scheme used by GAMESS restricts the basis set size to no more than 361 if the integrals are stored on disk, whereas for direct HF you can (in principle) use up to 2047 basis functions. Finally, what you are really interested in is reducing the wall clock time to obtain your answer, not the CPU time. Workstations have modest hardware (and sometimes software) I/O capabilities. Other environments such as an IBM mainframe shared by many users may also have very poor

CPU/wall clock performance for I/O bound jobs such as conventional HF.

You can estimate the disk storage requirements for conventional HF using a P or PK file by the following formulae:

nint = 1/sigma * 1/8 * N**4
Mbytes = nint * x / 1024**2
Here N is the total number of basis functions in your run, which you can learn from an EXETYP=CHECK run. The 1/8 accounts for permutational symmetry within the integrals. Sigma accounts for the point group symmetry, and is difficult to estimate accurately. Sigma cannot be smaller than 1, in no symmetry (C1) calculations. For benzene, sigma would be almost six, since you generate 6 C's and 6 H's by entering only 1 of each in $DATA. For water sigma is not much larger than one, since most of the basis set is on the unique oxygen, and the C2v symmetry applies only to the H atoms. The factor x is 12 bytes per integral for RHF, and 20 bytes per integral for ROHF, UHF, and GVB. Finally, since integrals very close to zero need not be stored on disk, the actual power dependence is not as bad as N**4, and in fact in the limit of very large molecules can be as low as N**2. Thus plugging in sigma=1 should give you an upper bound to the actual disk space needed. If the estimate exceeds your available disk storage, your only recourse is direct HF.

What are the economics of direct HF? Naively, if we assume the run takes 10 iterations to converge, we must spend 10 times more CPU time doing the integrals on each iteration. However, we do not have to waste any CPU time reading blocks of integrals from disk, or in unpacking their indices. We also do not have to waste any wall clock time waiting for a relatively slow mechanical device such as a disk to give us our data.

There are some less obvious savings too, as first noted by Almlof. First, since the density matrix is known while we are computing integrals, we can use the Schwarz inequality to avoid doing some of the integrals. In a conventional SCF this inequality is used to avoid doing small integrals. In a direct SCF it can be used to avoid doing integrals whose contribution to the Fock matrix is small (density times integral=small). Secondly, we can form the Fock matrix by calculating only its change since the previous iteration. The contributions to the change in the Fock matrix are equal to the change in the density times the integrals. Since the change in the density goes to zero as the run converges, we can use the Schwarz screening to avoid more and more integrals as the calculation progresses. The input option FDIFF in $SCF selects formation of the Fock operator by computing only its change from iteration to iteration. The FDIFF option is not implemented for GVB since there are too many density matrices from the previous iteration to store, but is the default for direct RHF, ROHF, and UHF.

So, in our hypothetical 10 iteration case, we do not spend as much as 10 times more time in integral evaluation. Additionally, the run as a whole will not slow down by whatever factor the integral time is increased. A direct run spends no additional time summing integrals into the Fock operators, and no additional time in the Fock diagonalizations. So, generally speaking, a RHF run with 10-15 iterations will slow down by a factor of 2-4 times when run in direct mode. The energy gradient time is unchanged by direct HF, and this is a large time compared to HF energy, so geometry optimizations will be slowed down even less. This is really the converse of Amdahl's law: if you slow down only one portion of a program by a large amount, the entire program slows down by a much smaller factor.

To make this concrete, here are some times for GAMESS benchmark BENCH12, which is a RHF energy for a moderately large molecule. The timings shown were obtained on a DECstation 3100 under Ultrix 3.1, which was running only these tests, so that the wall clock times are meaningful. This system is typical of Unix workstations in that it uses SCSI disks, and the operating system is not terribly good at disk I/O. By default GAMESS stores the integrals on disk in the form of a P supermatrix, because this will save time later in the SCF cycles. By choosing NOPK=1 in $INTGRL, an ordinary integral file can be used, which typically contains many fewer integrals, but takes more CPU time in the SCF. Because the DECstation is not terribly good at I/O, the wall clock time for the ordinary integral file is actually less than when the supermatrix is used, even though the CPU time is longer. The run takes 13 iterations to converge, the times are in seconds.

                                     P supermatrix   ordinary file
             # nonzero integrals      8,244,129       6,125,653
             # blocks skipped            55,841          55,841
             CPU time (ints)              709              636
             CPU time (SCF)              1289             1472
             CPU time (job total)        2123             2233
             wall time (job total)       3468             3200

When the same calculation is run in direct mode (integrals are processed like an ordinary integral disk file when running direct),

                iteration 1:         FDIFF=.TRUE.   FDIFF=.FALSE.
             # nonzero integrals       6,117,416      6,117,416
             # blocks skipped             60,208         60,208
                iteration 13:
             # nonzero integrals       3,709,733      6,122,912
             # blocks skipped            105,278         59,415
             CPU time (job total)         6719            7851
             wall time (job total)        6764            7886
 

Note that elimination of the disk I/O dramatically increases the CPU/wall efficiency. Here's the bottom line on direct HF:

                best direct CPU / best disk CPU = 6719/2123 = 3.2
                best direct wall/ best disk wall= 6764/3200 = 2.1
 
Direct SCF is slower than conventional SCF, but not outrageously so! From the data in the tables, we can see that the best direct method spends about 6719-1472 = 5247 seconds doing integrals. This is an increase of about 5247/636 = 8.2 in the time spent doing integrals, in a run which does 13 iterations (13 times evaluating integrals). 8.2 is less than 13 because the run avoids all CPU charges related to I/O, and makes efficient use of the Schwarz inequality to avoid doing many of the integrals in its final iterations.

SCF convergence accelerators

Generally speaking, the simpler the HF function, the better its convergence. In our experience, the majority of RHF, ROHF, and UHF runs will converge readily from GUESS=HUCKEL. GVB runs typically require GUESS=MOREAD, although the Huckel guess usually works for NPAIR=0. RHF convergence is the best, closely followed by ROHF. In the current implementation in GAMESS, ROHF is always better convergent than the closely related unrestricted high spin UHF. For example, the radical cation of diphosphine (test job BENCH10) converges in 12 iterations for ROHF and 15 iterations for UHF, starting from the neutral's closed shell orbitals. GVB calculations require much more care, and cases with NPAIR greater than one are particularly difficult.

Unfortunately, not all HF runs converge readily. The best way to improve your convergence is to provide better starting orbitals! In many cases, this means to MOREAD orbitals from some simpler HF case. For example, if you want to do a doublet ROHF, and the HUCKEL guess does not seem to converge, do this: Do an RHF on the +1 cation. RHF is typically more stable than ROHF, UHF, or GVB, and cations are usually readily convergent. Then MOREAD the cation's orbitals into the neutral calculation which you wanted to do at first.

GUESS=HUCKEL does not always guess the correct electronic configuration. It may be useful to use PRTMO in $GUESS during a CHECK run to examine the starting orbitals, and then reorder them with NORDER if that seems appropriate.

Of course, by default GAMESS uses the convergence procedures which are usually most effective. Still, there are cases which are difficult, so the $SCF group permits you to select several alternative methods for improving convergence. Briefly, these are

EXTRAP. This extrapolates the three previous Fock matrices, in an attempt to jump ahead a bit faster. This is the most powerful of the old-fashioned accelerators, and normally should be used at the beginning of any SCF run. When an extrapolation occurs, the counter at the left of the SCF printout is set to zero.

DAMP. This damps the oscillations between several successive Fock matrices. It may help when the energy is seen to oscillate wildly. Thinking about which orbitals should be occupied initially may be an even better way to avoid oscillatory behaviour.

SHIFT. This shifts the diagonal elements of the virtual part of the Fock matrix up, in an attempt to uncouple the unoccupied orbitals from the occupied ones. At convergence, this has no effect on the orbitals, just their orbital energies, but will produce different (and hopefully better) orbitals during the iterations.

RSTRCT. This limits mixing of the occupied orbitals with the empty ones, especially the flipping of the HOMO and LUMO to produce undesired electronic configurations or states. This should be used with caution, as it makes it very easy to converge on incorrect electronic configurations, especially if DIIS is also used. If you use this, be sure to check your final orbital energies to see if they are sensible. A lower energy for an unoccupied orbital than for one of the occupied ones is a sure sign of problems.

DIIS. Direct Inversion in the Iterative Subspace is a modern method, due to Pulay, using stored error and Fock matrices from a large number of previous iterations to interpolate an improved Fock matrix. This method was developed to improve the convergence at the final stages of the SCF process, but turns out to be quite powerful at forcing convergence in the initial stages of SCF as well. By giving ETHRSH as 10.0 in $SCF, you can practically guarantee that DIIS will be in effect from the first iteration. The default is set up to do a few iterations with conventional methods (extrapolation) before engaging DIIS. This is because DIIS can sometimes converge to solutions of the SCF equations that do not have the lowest possible energy. For example, the 3-A-2 small angle state of SiLi2 (see M.S.Gordon and M.W.Schmidt, Chem.Phys.Lett., 132, 294-8(1986)) will readily converge with DIIS to a solution with a reasonable S**2, and an energy about 25 milliHartree above the correct answer. A SURE SIGN OF TROUBLE WITH DIIS IS WHEN THE ENERGY RISES TO ITS FINAL VALUE. However, if you obtain orbitals at one point on a PES without DIIS, the subsequent use of DIIS with MOREAD will probably not introduce any problems. Because DIIS is quite powerful, EXTRAP, DAMP, and SHIFT are all turned off once DIIS begins to work. DEM and RSTRCT will still be in use, however.

SOSCF. Approximate second-order (quasi-Newton) SCF orbital optimization. SOSCF will converge about as well as DIIS at the initial geometry, and slightly better at subsequent geometries. There's a bit less work solving the SCF equations, too. The method kicks in after the orbital gradient falls below SOGTOL. Some systems, particularly transition metals with ECP basis sets, may have Huckel orbitals for which the gradient is much larger than SOGTOL. In this case it is probably better to use DIIS instead, with a large ETHRSH, rather than increasing SOGTOL, since you may well be outside the quadratic convergence region. SOSCF does not exhibit true second order convergence since it uses an approximation to the inverse hessian. SOSCF will work for MOPAC runs, but is slower in this case. SOSCF will work for UHF, but the convergence is slower than DIIS. SOSCF will work for non-Abelian ROHF cases, but may encounter problems if the open shell is degenerate.

DEM. Direct energy minimization should be your last recourse. It explores the "line" between the current orbitals and those generated by a conventional change in the orbitals, looking for the minimum energy on that line. DEM should always lower the energy on every iteration, but is very time consuming, since each of the points considered on the line search requires evaluation of a Fock operator. DEM will be skipped once the density change falls below DEMCUT, as the other methods should then be able to affect final convergence. While DEM is working, RSTRCT is held to be true, regardless of the input choice for RSTRCT. Because of this, it behooves you to be sure that the initial guess is occupying the desired orbitals. DEM is available only for RHF. The implementation in GAMESS resembles that of R.Seeger and J.A.Pople, J.Chem.Phys. 65, 265-271(1976). Simultaneous use of DEM and DIIS resembles the ADEM-DIOS method of H.Sellers, Chem.Phys.Lett. 180, 461-465(1991). DEM does not work with direct SCF.

High spin open shell SCF (ROHF)

Open shell SCF calculations are performed in GAMESS by both the ROHF code and the GVB code. Note that when the GVB code is executed with no pairs, the run is NOT a true GVB run, and should be referred to in publications and discussion as a ROHF calculation.

The ROHF module in GAMESS can handle any number of open shell electrons, provided these have a high spin coupling. Some commonly occurring cases are:

          one open shell, doublet:
               $CONTRL SCFTYP=ROHF MULT=2 $END
 
          two open shells, triplet:
               $CONTRL SCFTYP=ROHF MULT=3 $END
 
          m open shells, high spin:
               $CONTRL SCFTYP=ROHF MULT=m+1 $END
 

John Montgomery (then at United Technologies) is responsible for the current ROHF implementation in GAMESS. The following discussion is due to him:

The Fock matrix in the MO basis has the form

                             closed       open        virtual
                  closed      F2      |     Fb     | (Fa+Fb)/2
                           -----------------------------------
                  open        Fb      |     F1     |    Fa
                           -----------------------------------
                  virtual   (Fa+Fb)/2 |     Fa     |    F0
 
where Fa and Fb are the usual alpha and beta Fock matrices any UHF program produces. The Fock operators for the doubly, singly, and zero occupied blocks can be written as
                  F2 = Acc*Fa + Bcc*Fb
                  F1 = Aoo*Fa + Boo*Fb
                  F0 = Avv*Fa + Bvv*Fb
 

Some choices found in the literature for these canonicalization coefficients are

                                    Acc  Bcc  Aoo  Boo  Avv  Bvv
           Guest and Saunders       1/2  1/2  1/2  1/2  1/2  1/2
           Roothaan single matrix  -1/2  3/2  1/2  1/2  3/2 -1/2
           Davidson                 1/2  1/2   1    0    1    0
           Binkley, Pople, Dobosh   1/2  1/2   1    0    0    1
           McWeeny and Diercksen    1/3  2/3  1/3  1/3  2/3  1/3
           Faegri and Manne         1/2  1/2   1    0   1/2  1/2
 

The choice of the diagonal blocks is arbitrary, as ROHF is converged when the off diagonal blocks go to zero. The exact choice for these blocks can however have an effect on the convergence rate. This choice also affects the MO coefficients, and orbital energies, as the different choices produce different canonical orbitals within the three subspaces. All methods, however, will give identical total wavefunctions, and hence identical properties such as gradients and hessians.

The default coupling case in GAMESS is the Roothaan single matrix set. Note that pre-1988 versions of GAMESS produced "Davidson" orbitals. If you would like to fool around with any of these other canonicalizations, the Acc, Aoo, Avv and Bcc, Boo, Bvv parameters can be input as the first three elements of ALPHA and BETA in $SCF.

Other open shell SCF cases (GVB)

Genuine GVB-PP runs will be discussed later in this section. First, we will consider how to do open shell SCF with the GVB part of the program.

It is possible to do other open shell cases with the GVB code, which can handle the following cases:

          one open shell, doublet:
               $CONTRL SCFTYP=GVB MULT=2 $END
               $SCF    NCO=xx NSETO=1 NO(1)=1 $END
          two open shells, triplet:
               $CONTRL SCFTYP=GVB MULT=3 $END
               $SCF    NCO=xx NSETO=2 NO(1)=1,1 $END
          two open shells, singlet:
               $CONTRL SCFTYP=GVB MULT=1 $END
               $SCF    NCO=xx NSETO=2 NO(1)=1,1 $END
 

Note that the first two cases duplicate runs which the ROHF module can do better. Note that all of these cases are really ROHF, since the default for NPAIR in $SCF is 0.

Many open shell states with degenerate open shells (for example, in diatomic molecules) can be treated as well. There is a sample of this in the 'Input Examples' section of this manual.

If you would like to do any cases other than those shown above, you must derive the coupling coefficients ALPHA and BETA, and input them with the occupancies F in the $SCF group.

Mariusz Klobukowski of the University of Alberta has shown how to obtain coupling coefficients for the GVB open shell program for many such open shell states. These can be derived from the values in Appendix A of the book "A General SCF Theory" by Ramon Carbo and Josep M. Riera, Springer-Verlag (1978). The basic rule is

                 (1)      F(i) = 1/2 * omega(i)
                 (2)  ALPHA(i) =       alpha(i)
                 (3)   BETA(i) =      - beta(i),
 
where omega, alpha, and beta are the names used by Ramon in his Tables.

The variable NSETO should give the number of open shells, and NO should give the degeneracy of each open shell. Thus the 5-S state of carbon would have NSETO=2, and NO(1)=1,3.

Some specific examples, for the lowest term in each of the atomic P**N configurations are

          !   p**1   2-P state
           $CONTRL SCFTYP=GVB  MULT=2   $END
           $SCF    NCO=xx   NSETO=1  NO=3   COUPLE=.TRUE.
                F(1)=  1.0  0.16666666666667
            ALPHA(1)=  2.0  0.33333333333333  0.00000000000000
             BETA(1)= -1.0 -0.16666666666667 -0.00000000000000  $END

          !   p**2   3-P state
           $CONTRL SCFTYP=GVB  MULT=3   $END
           $SCF    NCO=xx   NSETO=1  NO=3   COUPLE=.TRUE.
                F(1)=  1.0  0.333333333333333
            ALPHA(1)=  2.0  0.66666666666667  0.16666666666667
             BETA(1)= -1.0 -0.33333333333333 -0.16666666666667  $END

          !   p**3   4-S state
           $CONTRL SCFTYP=ROHF  MULT=4   $END

          !   p**4   3-P state
           $CONTRL SCFTYP=GVB  MULT=3   $END
           $SCF    NCO=xx   NSETO=1  NO=3   COUPLE=.TRUE.
                F(1)=  1.0  0.66666666666667
            ALPHA(1)=  2.0  1.33333333333333  0.83333333333333
             BETA(1)= -1.0 -0.66666666666667 -0.50000000000000  $END

          !   p**5   2-P state
           $CONTRL SCFTYP=GVB  MULT=2   $END
           $SCF    NCO=xx   NSETO=1  NO=3   COUPLE=.TRUE.
                F(1)=  1.0  0.83333333333333
            ALPHA(1)=  2.0  1.66666666666667  1.33333333333333
             BETA(1)= -1.0 -0.83333333333333 -0.66666666666667  $END

Be sure to give all the digits, as these are part of a double precision energy formula.

Coupling constants for d**N configurations are

          !     d**1   2-D state
           $CONTRL SCFTYP=GVB MULT=2 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.1
                   ALPHA(1)= 2.0, 0.20, 0.00
                    BETA(1)=-1.0,-0.10, 0.00  $END

          !     d**2   average of 3-F and 3-P states
           $CONTRL SCFTYP=GVB MULT=3 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.2
                   ALPHA(1)= 2.0, 0.40, 0.05
                    BETA(1)=-1.0,-0.20,-0.05  $END

          !     d**3   average of 4-F and 4-P states
           $CONTRL SCFTYP=GVB MULT=4 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.3
                   ALPHA(1)= 2.0, 0.60, 0.15
                    BETA(1)=-1.0,-0.30,-0.15  $END

          !     d**4   5-D state
           $CONTRL SCFTYP=GVB MULT=5 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.4
                   ALPHA(1)= 2.0, 0.80, 0.30
                    BETA(1)=-1.0,-0.40,-0.30 $END

          !     d**5   6-S state
           $CONTRL SCFTYP=ROHF MULT=6 $END

          !     d**6   5-D state
           $CONTRL SCFTYP=GVB MULT=5 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.6
                   ALPHA(1)= 2.0, 1.20, 0.70
                    BETA(1)=-1.0,-0.60,-0.50 $END

          !     d**7   average of 4-F and 4-P states
           $CONTRL SCFTYP=GVB MULT=4 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.7
                   ALPHA(1)= 2.0, 1.40, 0.95
                    BETA(1)=-1.0,-0.70,-0.55  $END

          !     d**8   average of 3-F and 3-P states
           $CONTRL SCFTYP=GVB MULT=3 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.8
                   ALPHA(1)= 2.0, 1.60, 1.25
                    beta(1)=-1.0,-0.80,-0.65  $end

          !     d**9   2-D state
           $CONTRL SCFTYP=GVB MULT=2 $END
           $SCF    NCO=xx NSETO=1 NO=5 COUPLE=.TRUE.  F(1)=1.0,0.9
                   ALPHA(1)= 2.0, 1.80, 1.60
                    BETA(1)=-1.0,-0.90,-0.80 $END
The source for these values is R.Poirier, R.Kari, and I.G.Csizmadia's book "Handbook of Gaussian Basis Sets", Elsevier, Amsterdam, 1985.

Note that GAMESS can do a proper calculation on the ground terms for the d**2, d**3, d**7, and d**8 configurations only by means of state averaged MCSCF. For d**8, use

           $CONTRL SCFTYP=MCSCF MULT=3 $END
           $DRT    GROUP=C1 FORS=.TRUE. NMCC=xx NDOC=3 NALP=2 $END
           $GUGDIA NSTATE=10 $END
           $GUGDM2 WSTATE(1)=1,1,1,1,1,1,1,0,0,0 $END
Open shell cases such as s**1,d**n are probably most easily tackled with the state-averaged MCSCF program.

True GVB perfect pairing runs

True GVB runs are obtained by choosing NPAIR nonzero. If you wish to have some open shell electrons in addition to the geminal pairs, you may add the pairs to the end of any of the GVB coupling cases shown above. The GVB module assumes that you have reordered your MOs into the order: NCO double occupied orbitals, NSETO sets of open shell orbitals, and NPAIR sets of geminals (with NORDER=1 in the $GUESS group).

Each geminal consists of two orbitals and contains two singlet coupled electrons (perfect pairing). The first MO of a geminal is probably heavily occupied (such as a bonding MO u), and the second is probably weakly occupied (such as an antibonding, correlating orbital v). If you have more than one pair, you must be careful that the initial MOs are ordered u1, v1, u2, v2..., which is -NOT- the same order that RHF starting orbitals will be found in. Use NORDER=1 to get the correct order.

These pair wavefunctions are actually a limited form of MCSCF. GVB runs are much faster than MCSCF runs, because the natural orbital u,v form of the wavefunction permits a Fock operator based optimization. However, convergence of the GVB run is by no means assured. The same care in selecting the correlating orbitals that you would apply to an MCSCF run must also be used for GVB runs. In particular, look at the orbital expansions when choosing the starting orbitals, and check them again after the run converges.

GVB runs will be carried out entirely in orthonormal natural u,v form, with strong orthogonality enforced on the geminals. Orthogonal orbitals will pervade your thinking in both initial orbital selection, and the entire orbital optimization phase (the CICOEF values give the weights of the u,v orbitals in each geminal). However, once the calculation is converged, the program will generate and print the nonorthogonal, generalized valence bond orbitals. These GVB orbitals are an entirely equivalent way of presenting the wavefunction, but are generated only after the fact.

Convergence of true GVB runs is by no means as certain as convergence of RHF, UHF, ROHF, or GVB with NPAIR=0. You can assist convergence by doing a preliminary RHF or ROHF calculation, and use these orbitals for GUESS=MOREAD. Few, if any, GVB runs with NPAIR non-zero will converge without using GUESS=MOREAD. Generation of MVOs during the prelimnary SCF can also be advantageous. In fact, all the advice outlined for MCSCF computations below is germane, for GVB-PP is a type of MCSCF computation.

The total number of electrons in the GVB wavefunction is given by the following formula:

                  NE = 2*NCO + sum 2*F(i)*NO(i) + 2*NPAIR
                                i

The charge is obtained by subtracting the total number of protons given in $DATA. The multiplicity is implicit in the choice of alpha and beta constants. Note that ICHARG and MULT must be given correctly in $CONTRL anyway, as the number of electrons from this formula is double checked against the ICHARG value.

the special case of TCSCF

The wavefunction with NSETO=0 and NPAIR=1 is called GVB-PP(1) by Goddard, two configuration SCF (TCSCF) by Schaefer or Davidson, and CAS-SCF with two electrons in two orbitals by others. Note that this is just semantics, as these are all identical. This is a very important type of wavefunction, as TCSCF is the minimum acceptable treatment for singlet biradicals. The TCSCF wavefunction can be obtained with SCFTYP=MCSCF, but it is usually much faster to use the Fock based SCFTYP=GVB. Because of its importance, the TCSCF function (if desired, with possible open shells) permits analytic hessian computation.

A caution about symmetry

Caution! Some exotic calculations with the GVB program do not permit the use of symmetry. The symmetry algorithm in GAMESS was "derived assuming that the electronic charge density transforms according to the completely symmetric representation of the point group", Dupuis/King, JCP, 68, 3998(1978). This may not be true for certain open shell cases, and in fact during GVB runs, it may not be true for closed shell singlet cases!

First, consider the following correct input for the singlet-delta state of NH:

           $CONTRL SCFTYP=GVB NOSYM=1 $END
           $SCF    NCO=3 NSETO=2 NO(1)=1,1 $END
          for the x**1y**1 state, or for the x**2-y**2 state,
           $CONTRL SCFTYP=GVB NOSYM=1 $END
           $SCF    NCO=3 NPAIR=1 CICOEF(1)=0.707,-0.707 $END
Neither gives correct results, unless you enter NOSYM=1. The electronic term symbol is degenerate, a good tip off that symmetry cannot be used. However, some degenerate states can still use symmetry, because they use coupling constants averaged over all degenerate states within a single term, as is done in EXAM15 and EXAM16. Here the "state averaged SCF" leads to a charge density which is symmetric, and these runs can exploit symmetry.

Secondly, since GVB runs exploit symmetry for each of the "shells", or type of orbitals, some calculations on totally symmetric states may not be able to use symmetry. An example is CO or N2, using a three pair GVB to treat the sigma and pi bonds. Individual configurations such as (sigma)**2,(pi-x)**2,(pi-y*)**2 do not have symmetric charge densities since neither the pi nor pi* level is completely filled. Correct answers for the sigma-plus ground states result only if you input NOSYM=1.

Problems of the type mentioned should not arise if the point group is Abelian, but will be fairly common in linear molecules. Since GAMESS cannot detect that the GVB electronic state is not totally symmetric (or averaged to at least have a totally symmetric density), it is left up to you to decide when to input NOSYM=1. If you have any question about the use of symmetry, try it both ways. If you get the same energy, both ways, it remains valid to use symmetry to speed up your run.

And beware! Brain dead computations, such as RHF on singlet O2, which actually is a half filled degenerate shell, violate the symmetry assumptions, and also violate nature. Use of partially filled degenerate shells always leads to very wild oscillations in the RHF energy, which is how the program tries to tell you to think first, and compute second. Configurations such as pi**2, e**1, or f2u**4 can be treated, but require GVB wavefunctions and F, ALPHA, BETA values from the sources mentioned.


Back to list of topics...