The use of memory in Gaussian depends on: 1) the type of calculation; 2) the number of basis set (BS) functions N; 3) the server architecture (32/64 bit).

Be aware that it is not useful, or even limiting, providing a calculation with more memory than that actually required. The amount of memory can be calculated quite easily.

First, Gaussian does NOT adopt SI units, so for Gaussian:

1MW = 1024 kW = 1024^2 W = 1048576 W = 8·1024^2 B = 8388608 B

There is a memory threshold M0, depending from the type of calculations and the highest angular momentum of the basis set. Since rarely BSs have momenta larger than f-functions, M0 can be safely taken as large as 4 MW (6 MW for MP2 freq calculations).

Under these conditions, the memory M for a 1-core calculation is:

M = M0 + 2N^2

For n cores M must be multiplied times n, while for 64 bit systems, it must be doubled. Therefore, for a n-core 64 bit server, the required memory M, in 8-byte W units, is:

M = 2n(M0+2N^2)

In order to know the actual total number of basis functions N, a test calculation can be run on the desired model compound (with the proper specification of BS), and in the output file the N value can be found after the basis set specification:

"N basis functions, ... primitive gaussians, N cartesian basis functions"

For who may be interested, I prepared a small program (GaussMem, running under Linux, Win, macOS) to calculate automatically M and convert in the most useful memory units. Contact me privately if interested.

I hope this may help.

Hi Jonathan! Convergence failure is not always related to memory issues, it can be related even to the starting geometry. However, returning to your question, since you've said that you are running on some cluster and you seem to know how to manipulate your Gaussian input file and write the memory there, I could advice you to specify the usage of Gaussian scratch directory. That is the place where the program will put very large temporary files. If your storage where you send your input files is small but you have a lot of memory on compute nodes, then you shall specify that usage in your batch-script for the scratch directory. Moreover, think that CPU-time which you have written might not be enough, you might need a longer time. Finally, since you haven't mentioned more details on what you computed exactly I suggest you the previous comment as well. It can be useful to consider that usage before you specify numbers in batch and Gaussian input files.

Thank you for both of your comments. This is very helpful. I can likely fix the convergence failure and will increase the time. Just wanting to make sure I am using it efficiently before I commit too much time on the cluster. If I do not specify the scratch memory will those files just be automatically stored on the compute nodes and should I increase the compute node memory to account for that?

Looking into my output files it appears on the larger cluster is using 5,700 basis functions and on the smaller ligand is using 1,470 basis functions. Taking M0 to be 4MW on a 64-bit system I get about (1.1 GB / core) and (136 MB / core) respectively. Under the current set up (32 cores) I would expect the large cluster to use (~35GB) and the small ligand to use (~4.4GB) yet when I run the "seff" command to look at the computing efficiency the small ligand used far more than that and the large cluster used far less, as mentioned before. It appears as I have increased the number of basis sets the percent of the 64GB being used has only gone down. Is there some other limiting factor I am missing and is the additional memory being used for the smaller ligands unnecessary/limiting? Also is there an optimum amount of cores to allocate? I can go up to 384 cores on a single job spread over multiple nodes, I just do not know if that provides any actual benefit.

I just would like to point out that the increase of the number of cores does not necessarily imply an increase in computational performance. In general, if you carry out the same calculation with an increasing number of cores, you see that it will converge on a certain number of ‘optimal’ cores. Using a larger amount of cores won’t increase the performance: it is more likely that you get the opposite effect. This is at least my experience with much smaller molecular systems than yours.

Dear Jonathan, if you do not specify the scratch directory and if it is not specified else where as a default setting (by a system administrator , for example), your files will end up in the directory with your batch-scripts. Moreover, it might be so that your calculation can go on its own like that (if you have enough space), but if you run several calculations at the same time you will cause the crash of your calculation by taking too much space. Another thing is the number of tasks per node: your calculation might go fast even on few cores, but if you take too many cores (like you took 32) it can also cause the crash, since you will overload the space with data. I can add as well that you shall run one heavy calculation on one node. Running several such calculations can also overload the space.