Hi All,
I encountered a strange problem these days with DFT using Gaussian16 package. I optimized the molecule geometry and asked the computer to do a frequency calculation. The optimization could be done smoothly. However, the job self-termindated when the computer started to calculate the frequency. I tried to define the basis set by myself, remove MO calculation command, or separate the optimization and frequency calculation. But none of the methods work for it. There was no clear error message in the output file but only a warning of the MO gap.
I have attached my input and output files in this question. Thanks for your comments and suggestions in advanced!
Hi Wenda,
Considering that your *.log file does not have an error termination message, my guess is that it has been killed by the computer. I would check the SLURM document as well to see if there are any specific error messages there.
I think that the most likely issue is an out-of-memory error. Frequency calculations are quite memory-hungry. Based on your input file, you are requesting 48 cores and 24GB of RAM. In general, I would recommend using a minimum of 2GB per core, preferably 4GB.
Hope this helps!
The problem probably is lack of memory as already stated by Mihai or lack of disk space for the scratch files.
Gaussian has some rare "bugs" concearning the combination of some methods, I've had the experience where a certain composition of implicit solvent model and basis set would somehow lead to unexplicable (and random) errors. So I'd also run the calculation with the same input but changing the structure to something really simple (like a benzene) just to check if it runs smoothly, if so, you can spot that the problem is alocating computational resources.
I think 24Gb is plenty of memory IF your system actually has that much available to allocate. Are you submitting these to a job scheduler like PBS or Slurm? If so, make sure your CPU and memory requests in the input file match those in the submission script:
%nproc=48
%mem=24GB
Finally, looking at your output file, it seems as though the job simply ran out of time. Calculating derivatives, especially with solvation, takes a lot of time.
Hi All,
Thank you so much for the information you provided. I finally got this problem solved yesterday.
The job was processed by a .slurm file on the high performance computer from the university. I checked the .err file before and I gave an unclear information: exited with exit code 1. If it is terminated by the computer or out of time, it would show the cancellation message or out-of-time message in the .err file.
Follow the tips from all of you, I switched the nproc and mem to be: %nproc=24, %mem=48GB, remove the command of %chk, and set the time for 3 days instead of a few hours. It still running very slow at the beginning and I found an extremely large .rwf file that was >4000 MB. The time of the calculation files (.log, .rwf, etc.) kept updating with time but no new information can be found in the .log file.
Finally, the job was finished after 2 days waiting and gave a normal .log output file with 'Normal termination of Gaussain16' in the end. This is really a rare 'bug' but we finally resolve it!
Thank you all again for your suggestions on this question!
Wenda Wu That big .rwf file is the temporary one gaussian writes with information about the calculation ongoing (matrices that are too large for the ram and so on...), for frequency calculations with large basis sets it can get very large. For example, I've studied compounds with several metal centers that would generate .rwf files with over 100 gb size.
Sometimes it is useful to check how much space your scratch folder may spend and how large the temporary files are getting, so you can track if the calculation is exausting the quota you have (considering most high performance computational centers limit the resources a single user may use).
- Badges
- Science topic