11
$\begingroup$

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:

enter image description here

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:

enter image description here

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.

$\endgroup$
3
  • 2
    $\begingroup$ +10. A very nice question and very thoroughly put together! $\endgroup$ Nov 2, 2020 at 1:13
  • 2
    $\begingroup$ 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. $\endgroup$
    – TAR86
    Nov 2, 2020 at 5:11
  • 1
    $\begingroup$ 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). $\endgroup$
    – Camps
    Nov 2, 2020 at 20:54

1 Answer 1

5
$\begingroup$

I would say the reason that they default to storing the integrals is because there is no obvious choice to make one way or the other as it depends a lot on what resources are available and how large of a calculation you are doing. I have encountered this same situation while using Molpro before. In fact, every electronic structure package I'm aware of has an option to either compute the integrals directly or cache them on disk. Many packages also have semi-direct methods for caching some integrals and directly computing others. To be more specific, I'll quote a relevant section from the Molpro manual which I think answers your questions:

Most methods implemented in MOLPRO can be performed integral-direct, i.e., the methods are integral driven with the two-electron integrals in the AO basis being recomputed whenever needed, avoiding the bottleneck of storing these quantities on disk. Exceptions are currently full CI (FCI), perturbative triple excitations (T), UMP2, RMP2, CPP, MRCI-F12, and RS2-F12. For small molecules, this requires significantly more CPU time, but reduces the disk space requirements when using large basis sets. However, due to efficient prescreening techniques, the scaling of the computational cost with molecular size is lower in integral-direct mode than in conventional mode, and therefore integral-direct calculations for extended molecules may even be less expensive than conventional ones. The break-even point depends strongly on the size of the molecule, the hardware, and the basis set. Depending on the available disk space, calculations with more than 150–200 basis functions in one symmetry should normally be done in integral-direct mode.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .