Blog Archives

Restarting Calculations from rwf Files – Gaussian

Having a long calculation terminated just because it ran out of time in the queue is very frustrating; even more so if restarting it from the last accesible point is hard to do.

I have recently performed some particularly demanding calculation: Basis Set Superposition Error (BSSE) with the Counterpoise method and second order Moller-Plesset perturbation theory calculation (MP2). The calculation ran out of time but I was able to restart it because I had the rwf file! My input looked a bit like this:

#p mp2/GEN counterpoise=2 maxdisk=200GB

So here is how it works.

The very first line of your calculation gives you the process ID number which is not necessarily the same as the PID given by the queue system (in fact, is not the same because the latter corresponds to the submitted script, not the instructions in it i.e. your calculation)

 Entering Gaussian System, Link 0=g09
 Initial command:
 /opt/SC/aplicaciones/g09-C.01/l1.exe /tmpu/joaqbf_g/joaqbf/Gau-38954.inp 
 Entering Link 1 = /opt/SC/aplicaciones/g09-C.01/l1.exe PID=     38955.

(emphasis in red is mine)

This is the number you want to write down. You will need to find the corresponding rwf file (usually in your SCRATCH directory) as Gau-PID.rwf (in the aforementioned case, Gau-38955.rwf). If you are a bit paranoid like myself you want to copy and keep this file safe but be aware that these are very long files, in my case it was 175 GB long. Now you need to launch your calculation again with the following input:


Title Card

# restart

rest of input

You can add all other controls to the Link0 section such as %nprocshared or %mem according to your needs.

I’m pretty sure it should work for other kinds of calculations in which taking from the checkpoint file is not as easy, so if you run into this kind of problems, its worth the try.

Some .fchk files wont open in GaussView5.0 (Update)

A couple of weeks ago I posted a solution for a common error regarding .fchk files that will display the error below when opened with GaussView5.0. As I expected, this error has to do with the use of diffuse functions in the basis set and is related to a change of format between Gaussian versions.

Missing or bad data: Alpha Orbital Energies
Line Number 1234

Although the method described in the previous post works just fine, the following update is a better approach. Due to a change of spelling between G03 and G09 (which has been corrected for G09 but not available for GV versions prior to 5.0.9) one must change “independent” for “independant

To make the change directly from the terminal the following command is needed:

sed -i 's/independent/independant/g' file.fchk

Alternatively you can redirect the output to a new file

sed -e 's/independent/independant/g' file.fchk > newfile.fchk

if you want to keep the old version and work with a new one.

Of course this edition can be performed manually with any text editor available (for example if you work in Windows) but solutions from the terminal always seem easier and a lot more fun to me.

Thanks to Dr. Fernando Cortés for sharing his insight into this issue.

If a .fchk file wont open in GaussView5.0

I’ve found the following error regarding the opening of .fchk files in GaussView5.0.

Missing or bad data: Alpha Orbital Energies
Line Number 1234

The error is prevented to a first approximation (i.e. it at least will allow GV to open and visualize the file but other issues may arise) by opening the file and modifying the number of basis functions to equal the number of independent functions (which is lower)

FOpt RM062X 6-311++G(d,p) 
Number of atoms I 75
Info1-9 I N= 9
 163 163 0 0 0 110
 2 18 -502
Charge I 0
Multiplicity I 1
Number of electrons I 314
Number of alpha electrons I 157
Number of beta electrons I 157
Number of basis functions I 1199
Number of independent functions I 1199
Number of point charges in /Mol/ I 0
Number of translation vectors I 0
Atomic numbers I N= 75
... ...
... ...

Once both numbers match you can open the file normally and work with it. My guess is this will continue to happen with highly polarized basis sets but I need to run some tests.

%d bloggers like this: