# What are the trade-offs setting DIRSCF to either .TRUE. or .FALSE. (the default) in GAMESS (US)?

The first software I used to run calculations was Gaussian09. When submitting a input, I used to see a pattern of resource usage where the allocated CPU quickly maxed out, remaining high most of the time, with not much disk activity.

Later, when I started to use Gamess (US), I was a bit confused, because it didn't follow this resource usage pattern. Instead, I saw allocated CPU utilization bellow maximum for most of the time, with occasional spikes, and heavy disk usage for most of the time.

To illustrate it, I ran a single point energy (SPE) calculation on a C20 molecule (the reference system benchmarked on the page @r2compchem pointed in a answer to another question of mine), with the following input:

! C20 | Single Point | B3LYP/6-31G(d)
$$BASIS GBASIS=N31 NGAUSS=6 NDFUNC=1$$END
$$CONTRL SCFTYP=RHF RUNTYP=ENERGY ICHARG=0 MULT=1 DFTTYP=B3LYP$$END
$$SYSTEM MWORDS=250$$END

$$DATA Title C1 C 6.0 -2.56361 2.53552 -1.18910 C 6.0 -2.58167 1.21111 -0.56424 C 6.0 -2.71457 2.35598 -2.63472 C 6.0 -2.74378 0.21303 -1.62368 C 6.0 -2.82592 0.92060 -2.90331 C 6.0 0.45050 1.49084 -3.31626 C 6.0 0.61261 2.48891 -2.25682 C 6.0 0.43244 0.16642 -2.69140 C 6.0 0.69474 1.78135 -0.97719 C 6.0 0.58339 0.34597 -1.24577 C 6.0 -0.45654 2.18038 -0.16469 C 6.0 -1.25022 3.13457 -0.94217 C 6.0 -1.27943 0.99162 0.06888 C 6.0 -0.58944 3.32525 -2.23517 C 6.0 -0.63671 -0.14211 -0.59927 C 6.0 -1.49446 2.84406 -3.28123 C 6.0 -0.85174 1.71033 -3.94938 C 6.0 -1.67463 0.52156 -3.71581 C 6.0 -1.54173 -0.62330 -1.64533 C 6.0 -0.88096 -0.43262 -2.93833$$END


Logging resource usage, I got the following execution profile:

Some time after identifying this execution pattern for the first time, I learned there is a keyword you can use to control whether Gamess (US) precomputes and stores integrals on disk or if it just keeps recalculating them on the fly. The default value, .FALSE., precomputes and stores integrals on disk. If for the same system I set it to .TRUE. by hand, adding the line \$SCF DIRSCF=.TRUE. \$END to the input file:

! C20 | Single Point | B3LYP/6-31G(d)
$$BASIS GBASIS=N31 NGAUSS=6 NDFUNC=1$$END
$$CONTRL SCFTYP=RHF RUNTYP=ENERGY ICHARG=0 MULT=1 DFTTYP=B3LYP$$END
$$SYSTEM MWORDS=250$$END
$$SCF DIRSCF=.TRUE.$$END

$$DATA Title C1 C 6.0 -2.56361 2.53552 -1.18910 C 6.0 -2.58167 1.21111 -0.56424 C 6.0 -2.71457 2.35598 -2.63472 C 6.0 -2.74378 0.21303 -1.62368 C 6.0 -2.82592 0.92060 -2.90331 C 6.0 0.45050 1.49084 -3.31626 C 6.0 0.61261 2.48891 -2.25682 C 6.0 0.43244 0.16642 -2.69140 C 6.0 0.69474 1.78135 -0.97719 C 6.0 0.58339 0.34597 -1.24577 C 6.0 -0.45654 2.18038 -0.16469 C 6.0 -1.25022 3.13457 -0.94217 C 6.0 -1.27943 0.99162 0.06888 C 6.0 -0.58944 3.32525 -2.23517 C 6.0 -0.63671 -0.14211 -0.59927 C 6.0 -1.49446 2.84406 -3.28123 C 6.0 -0.85174 1.71033 -3.94938 C 6.0 -1.67463 0.52156 -3.71581 C 6.0 -1.54173 -0.62330 -1.64533 C 6.0 -0.88096 -0.43262 -2.93833$$END


Now I get the following execution profile:

That is just what I was used to before.

Since when I first learned this, I always set DIRSCF to .TRUE., for the following reasons:

• In my experience, the calculations run faster when the integrals are not precomputed and stored on disk. Notice in my example, the DIRSCF=.FALSE. version took about 5000s to finish, while the DIRSCF=.TRUE. took a little under 1000s;
• In my experience, the system keeps more responsive under heavy CPU load than with heavy disk read/write load;
• As a rule of thumb, I assume a device with moving parts is more subject to early failure on heavy loads. HDs have moving parts, while CPUs have not. So I think is wiser to load the CPU instead of disk, when I have a choice.

Said that, what puzzles me to this day is that, if Gamess (US) creators set the default value of DIRSCF to .FALSE., they probably had good reason to do so, and I just don't know why. Initially I assumed it was just some sort of space-speed trade-off, but then I noticed the stored version usually runs slower, and was left wondering.

So, If someone more experienced here could explain what are the trade-offs involved in setting DIRSCF to either .TRUE. or the default .FALSE., and what are the situations where is appropriate to use each setting, I would be grateful.

• +10. A very nice question and very thoroughly put together! Nov 2, 2020 at 1:13
• Though I am not an expert on GAMESS, the usual reason for software defaults that no longer seem sensible is backwards-compatibility, historical reasons, and an unwillingness to change options that users may implicitly rely on. Further, for your own repoducibility, it is good practice to explicitly set every threshold and option. Also note that some programs will try to do both: store the most expensive integrals on disk/memory and recompute the easy ones. Nov 2, 2020 at 5:11
• Besides the reason of backwards-compatibility, I only think in the price of RAM vs hard disk space. Other day I run a Gaussian calculations that create two files with 21GB each, impossible to move this calculation to RAM (I only have 64MB).
– Camps
Nov 2, 2020 at 20:54