## PC GAMESS/Firefly' FAST MATRIX DIAGONALIZATION AND INVERSION

The Fastdiag dynamic library (fastdiag.dll of Windows PC GAMESS/Firefly distributions, fastdiag.ex of Linux distributions) contains fast optimized modern algorithms of symmetric matrix diagonalization and inversion and is intended to improve the performance of initial guess generation, DIIS extrapolation, as well as some other computationally-intensive steps. Windows users should put this library into the same folder where the PC GAMESS/Firefly executables reside, Linux users should put it into the PC GAMESS/Firefly' working/scratch directories. Under Linux, it should be renamed to be all lower-case.

There are three related options in \$system and \$guess groups, namely:

• \$system kdiag= < one of 3,2,1,0,-1,-2 > \$end - controls the system-wide diagonalization routine used.

• \$system nojac= < N > \$end Instructs PC GAMESS/Firefly to never use Jacobi diagonalization for matrices of size NxN and above, even if Jacobi code was explicitly requested.

• \$guess kdiag= < one of 3,2,1,0,-1,-2 > \$end - controls diagonalization routine used during initial guess generation.

The values of 3, 2, 1 have the same meaning as in the regular GAMESS (US), the values of 0,-1,-2 are the PC GAMESS/Firefly specific Fastdiag values.

Namely, kdiag=0 selects very stable, fast and precise diagonalization routine based on the Divide and Conquer (DC) algorithm. However, DC-based code requires large amount of extra memory.

Kdiag=-1 selects potentially less stable, less precise but even faster diagonalization routine based on the Relatively Robust Representation (RRR) approach. This method requires less memory than DC code.

Finally, kdiag=-2 selects a combination of RRR and DC methods, which falls back to DC in the cases when RRR fails completely resulting in NANs and INFs. It is usually as fast as kdiag=-1 but requires as much memory as kdiag=0. However, as in the most cases results are obtained using RRR approach, kdiag=-2 is still less precise than purely DC-based kdiag=0.

Note, kdiag=-1 and kdiag=-2 options are currently considered as the experimental ones and are intended mainly for large MOPAC jobs. Otherwise, they should not normally be used! The most serious issue one can encounter using RRR-based code is the sporadic program hangs inside RRR-based diagonalization code. This seems to be the intrinsic property of the RRR approach and there does not seem to exist any solution to this problem.

The default value of kdiag found in \$system and \$guess groups is 0 (as -1 and -2 are the experimental options at present), which is reasonable. For better compatibility with GAMESS (US), the default value of nojac is -1, meaning that this variable has no effect at all. It is generally recommended to set nojac to some small value, e.g., 30 or so, especially if the number of basis functions is large enough.

Note that fast diagonalization routines uses extra memory which is not taken into account during check runs! Hence it is recommended to reserve some additional amount of memory for diagonalization routines. For example, if the system of interest has ca. 1000 basis functions, it is a good idea to add about 2.5-3 MW of memory for diagonalization purposes. Otherwise, the slower built-in routine will be called if the amount of memory is not enough to use fast routines.

Finally, it should be noted that fastdiag is not compatible with and is not used by the generic Pentium PC GAMESS/Firefly versions.