"36676847 words are not enough for (...)" means that you don't have enough RAM memory to perform this calculation. You need to specify more memory for the calculation in the input, e.g. "%Mem=8GB" or physically add more memory to the computer you're working on.

"36676847 words are not enough for (...)" means that you don't have enough RAM memory to perform this calculation. You need to specify more memory for the calculation in the input, e.g. "%Mem=8GB" or physically add more memory to the computer you're working on.

try it on another computer with bigger %mem in the input

The required amount of RAM cannot be evaluated randomly but it depends rationally on the type of calculation, the number of used processors, and the number of basis functions you're using. The number of functions in turn depends on your choice of the basis set. See:

http://www.gaussian.com/g_tech/g_ur/m_running_w.htm

and

http://www.lct.jussieu.fr/manuels/Gaussian03/g_ur/m_eff.htm

Look at your output file and take note of the number of basis functions you're using. Then based on the number of functions and cores you can calculate the required memory with GaussMem (http://people.unica.it/marca/2015/03/06/gaussmem/).

Regards

Dear all,

thank you for your replies! Actually, with the increased memory amount (by %mem command) the frequency calculations managed to go through that step of "36676847 words are not enough for AlAXAO", but now the situation is not improved: instead of all frequencies and other values there are only sets of "NaN" in the output, which is ended with the message like below:

Maximum of*** iterations exceeded in RedStp.

Error termination via Lnk1e in /opt/apps/gaussian/09/g09/l103.exe at Wed Feb 3 05:53:15 2016.

Job cpu time: 5 days 12 hours 55 minutes 5.3 seconds.

File lengths (MBytes): RWF= 21345 Int= 0 D2E= 0 Chk= 135 Scr= 1

Did anybody see a message like this before? Again, probably, problems with memory (at the supercomputer, by the way)? The number of basis functions in this case is about 1000, and calculations are done with solvent effects using PCM model.

Thank you again for your help!

Best regards,

Aleksey.

Aleksey,

Just out of curiosity, can you run it with the weakest basis set available? Just to test it out? Because that is starting to sound a lot like a problem I had before, which was hardware related - I had overclocked AMD FX 8350 running Gaussian, and the calculations died. Later, when I changed the clock setting, they got back to normal. But the problem may very well reside elsewhere... 

"NaN" stays for "Not a Number" and generally points to a convergence PCM problem. Maybe you are already doing the following, but I would proceed like this: 1) optimize the geometry of your compound at a lower level (gas phase, double-z basis set for everything but Pd); 2) introduce the 6-31G* BS for a second gas phase optimization; 3) optimize with IEF-PCM; 4) calculate the frequencies at the final geometry. Each step should privide you the starting point for the following one.

Hope this helps

As Massimiliano suggested, there is a good chance that PCM optimization is taking too long (exceeding the number of available steps in optimization) which is unfortunately often. Definitely try what he suggests: first optimize the system without the solvent (no PCM option) and then try reoptimizing with PCM.

If it still doesn't work, you can try optimizing the system in gas-phase and then just do single-point PCM calculations to get the solvent effect. While this is suboptimal, the geometries with and without solvent are quite often very similar and you can justify it in your work.