Does ENDING really need to "nap" for 2 seconds?

[ehermes]

• [x] Summary of the issue and expected results:

First, some context: I am developing a geometry optimization code, Sella, which can interface with a variety of electronic structure theory packages through the ASE library. I would like to benchmark my code using AM1 (or other semi-empirical) calculations on small molecules, but currently none of the free packages supported by ASE can perform AM1 calculations (with the exception of CP2K, a periodic DFT code which gives energies and forces that are not in quantitative agreement with other codes). I would like to add to ASE the capability to drive GAMESS calculations, but I'm running into problems with my desired workflow.

For very small/fast calculations (e.g. semi-empirical AM1 on a small molecule), the actual time to achieve convergence can be significantly less than one second. In this case, the wall-time of a calculation is dominated by the 2-second nap that occurs in ENDING. This hampers workflows which involve running many sequential calculations.

• [x] Description of the run environment:

  • operating system: Ubuntu 18.04.3 LTS
  • compiler: gfortran 7.4.0-1ubuntu2.3
  • math library: OpenBLAS 0.3.4.dev
  • communication library: OpenMPI 2.1.1-8

• [x] An input file (if applicable) to reproduce the issue.

  $CONTRL SCFTYP=RHF RUNTYP=GRADIENT $END
  $BASIS  GBASIS=AM1 $END
  
  $DATA
  Water
  C1
  O 8 0.000000  0.000000  0.119262
  H 1 0.000000  0.763239 -0.477047
  H 1 0.000000 -0.763239 -0.477047
  $END

Running the calculation with time rungms water.inp 00 1 1 produces the following timing information on my machine:

real    0m2.527s
user    0m0.184s
sys     0m0.252s

When I set IDELAY=0 in ENDING, I get the following timing:

real    0m0.482s
user    0m0.207s
sys     0m0.176s

This does not seem to cause problems, even when I increase the number of CPUs used (I realize this system is so small that parallelism does not help).

• [x] A copy of your install.info file.

  
  #!/bin/csh

Compilation configuration for GAMESS

Generated on S1033085

Generated at Mon Feb 10 08:15:31 PST 2020

GAMESS Paths

setenv GMS_PATH /home/ehermes/build/tmp/gamess setenv GMS_BUILD_DIR /home/ehermes/build/tmp/gamess

Machine Type

setenv GMS_TARGET linux64

FORTRAN Compiler Setup

setenv GMS_FORTRAN gfortran setenv GMS_GFORTRAN_VERNO 7.4

Mathematical Library Setup

setenv GMS_MATHLIB openblas setenv GMS_MATHLIB_PATH /opt/OpenBLAS/lib setenv GMS_AMD_BLAS_PATH

parallel message passing model setup

setenv GMS_DDI_COMM mixed setenv GMS_MPI_LIB openmpi setenv GMS_MPI_PATH /usr/lib/x86_64-linux-gnu/openmpi

Michigan State University Coupled Cluster

setenv GMS_MSUCC false

Please match any manual changes to the

GMS_MSUCC flag in /home/ehermes/build/tmp/gamess/Makefile

before running make

LIBCCHEM CPU/GPU Code Interface

setenv GMS_LIBCCHEM false setenv GMS_LIBCCHEM_LIBS -ldl setenv GMS_EIGEN_PATH
setenv GMS_BOOST_PATH
setenv GMS_GA_PATH

Intel Xeon Phi Build: none/knc/knl

setenv GMS_PHI none

Shared Memory Type: sysv/posix

setenv GMS_SHMTYPE sysv

GAMESS OpenMP support: true/false

setenv GMS_OPENMP false

Please match any manual changes to the

GMS_OPENM flag in /home/ehermes/build/tmp/gamess/Makefile

before running make

Singularity Setup

setenv GMS_CONTAINER
setenv GMS_CONTAINER_PATH /home/ehermes/build/tmp/gamess

################################################

Added any additional environmental variables

or module loads below if needed.

################################################ setenv GMS_FPE_FLAGS '-ffpe-trap=invalid,zero,overflow'

[colleeneb]

Thanks for the note. This seems like something we can change, but we'll look into it and get back to you.

[saromleang]

Thank you for the issue. This is a very unique use-case of GAMESS. As for now, given that you have a solution to reduce the delay in ENDING, I don't think anything further needs to be done.

There would need to be an increase in the number of high-throughput use-cases for us to consider removing the 2 second delay in ENDING.