From owner-chemistry@ccl.net Mon Nov 2 16:14:01 2020 From: "Tobias Kraemer tobias.kraemer .. mu.ie" To: CCL Subject: CCL:G: Gaussian error in Frequency Calculation Message-Id: <-54201-201102161119-1912-LQoVmJ5b9DZxez7mGkUSXw|-|server.ccl.net> X-Original-From: "Tobias Kraemer" Date: Mon, 2 Nov 2020 16:11:16 -0500 Sent to CCL by: "Tobias Kraemer" [tobias.kraemer[-]mu.ie] Hello all, I hope everyone is well. I haven't posted here for a long time, but I have encountered some strange behaviour in a Gaussian frequency calculation that I have not seen before. There seems to be little to no information out there on this problem, so I was hoping to get some input from the list. Essentially, we are running a geometry optimisation with subsequent frequency job (same input) at the B3LYP/6-311+G(d) level of theory and including the GD3BJ dispersion correction. The molecule is a small molecules containing potassium. The optimisation furnishes a perfectly fine structure, but the calculation then error terminates with the following message Maximum of*** iterations exceeded in RedStp. All entries in this section contain NaN entries, e.g. Frequencies -- NaN NaN NaN Red. masses -- NaN NaN NaN Frc consts -- NaN NaN NaN IR Inten -- NaN NaN NaN Atom AN X Y Z X Y Z X Y Z 1 19 NaN NaN NaN NaN NaN NaN NaN NaN NaN 2 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN 3 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN 4 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN 5 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN 6 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN Obviously something has gone awfully wrong in the frequencies. The problem can be reproduced by running the frequency job on the optimised geometry alone (here we used a smaller basis set). Interestingly the calculation finishes normally in this case, but shows only NaN entries everywhere in the output. I have seen some indication that this may be related to the D3 correction, but I would like to hear your opinion on this. We are running G09 E.01. your help would be much appreciated. thanks in advance. Kind regards, Tobias From owner-chemistry@ccl.net Mon Nov 2 18:32:01 2020 From: "Close, David M. CLOSED-$-mail.etsu.edu" To: CCL Subject: CCL:G: [EXTERNAL] CCL:G: Gaussian error in Frequency Calculation Message-Id: <-54202-201102175223-14791-/v+xx9bGiZCspVRx/QjS1g#%#server.ccl.net> X-Original-From: "Close, David M." Content-Language: en-US Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Nov 2020 22:52:14 +0000 MIME-Version: 1.0 Sent to CCL by: "Close, David M." [CLOSED++mail.etsu.edu] Tobias: I saw this some time ago. I think it has to do with the amount of memory you have specified. Regards, Dave Close -----Original Message----- > From: owner-chemistry+closed==etsu.edu.#%#.ccl.net On Behalf Of Tobias Kraemer tobias.kraemer .. mu.ie Sent: Monday, November 2, 2020 4:11 PM To: Close, David M. Subject: [EXTERNAL] CCL:G: Gaussian error in Frequency Calculation Sent to CCL by: "Tobias Kraemer" [tobias.kraemer[-]mu.ie] Hello all, I hope everyone is well. I haven't posted here for a long time, but I have encountered some strange behaviour in a Gaussian frequency calculation that I have not seen before. There seems to be little to no information out there on this problem, so I was hoping to get some input from the list. Essentially, we are running a geometry optimisation with subsequent frequency job (same input) at the B3LYP/6-311+G(d) level of theory and including the GD3BJ dispersion correction. The molecule is a small molecules containing potassium. The optimisation furnishes a perfectly fine structure, but the calculation then error terminates with the following message Maximum of*** iterations exceeded in RedStp. All entries in this section contain NaN entries, e.g. Frequencies -- NaN NaN NaN Red. masses -- NaN NaN NaN Frc consts -- NaN NaN NaN IR Inten -- NaN NaN NaN Atom AN X Y Z X Y Z X Y Z 1 19 NaN NaN NaN NaN NaN NaN NaN NaN NaN 2 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN 3 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN 4 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN 5 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN 6 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN Obviously something has gone awfully wrong in the frequencies. The problem can be reproduced by running the frequency job on the optimised geometry alone (here we used a smaller basis set). Interestingly the calculation finishes normally in this case, but shows only NaN entries everywhere in the output. I have seen some indication that this may be related to the D3 correction, but I would like to hear your opinion on this. We are running G09 E.01. your help would be much appreciated. thanks in advance. Kind regards, Tobiashttp://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txtThe [EXTERNAL] tag in the subject line identifies emails that do NOT originate from an ETSU person or service. Please exercise caution when handling emails from external sources. Any email that is unsolicited and requires you to take immediate action, appears to be forged or is PHISHING for information can be verified by emailing the ITS Help Desk. From owner-chemistry@ccl.net Mon Nov 2 19:07:00 2020 From: "Igors Mihailovs igorsm+*+cfi.lu.lv" To: CCL Subject: CCL:G: Gaussian error in Frequency Calculation Message-Id: <-54203-201102185026-1720-v/VcgN41IabAaimdRMu/fA,+,server.ccl.net> X-Original-From: Igors Mihailovs Content-Language: en-US Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Date: Tue, 3 Nov 2020 01:50:13 +0200 MIME-Version: 1.0 Sent to CCL by: Igors Mihailovs [igorsm[-]cfi.lu.lv] Hello Dr. Kraemer, Not to help probably, but I have once encountered this in a calculation which does not utilize any dispersion correction at all. It was an LC-BLYP calculation using Linda, which somehow failed to even start (all force constants were NaN at the first iteration) but did not notice this and continued for 199 steps at which it signalled "Number of steps exceeded" (with all four optimization parameters "converged"). Also, at the end of the estimation of the Hessian (even at the very beginning) the following message is printed: RFO could not converge Lambda in  999 iterations. The route section was: #T LC-BLYP/6-311G(d,p) Opt(Tight) Integral(Grid=UltraFineGrid) SCRF(So  lvent=Chloroform) Guess=Mix Back then I then resorted to think this was a technical issue. The excerpt of the output is below: Electronic spatial extent (au):  =           9159.2106  Charge=              0.0000 electrons  Dipole moment (field-independent basis, Debye):     X=              4.6583    Y=             -2.0724 Z=              0.0000  Tot=              5.0985   Exact polarizability: 530.016 -25.136 261.274   0.000   0.000 105.036  Approx polarizability: 310.731 -12.857 234.854   0.000   0.000 111.144  Rotating derivatives to standard orientation.  Full mass-weighted force constant matrix:  Low frequencies ---       NaN       NaN       NaN       NaN NaN       NaN  Low frequencies ---       NaN       NaN       NaN  Diagonal vibrational polarizability:               NaN             NaN             NaN  Harmonic frequencies (cm**-1), IR intensities (KM/Mole), Raman scattering  activities (A**4/AMU), depolarization ratios for plane and unpolarized  incident light, reduced masses (AMU), force constants (mDyne/A),  and normal coordinates:                       1 2                      3                      A'                     A' A'  Frequencies --         NaN NaN                    NaN  Red. masses --         NaN NaN                    NaN  Frc consts  --         NaN NaN                    NaN  IR Inten    --         NaN NaN                    NaN   Atom  AN      X      Y      Z        X      Y      Z X      Y      Z      1   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN      2   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN      3   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN      4   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN      5   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN      6   6      NaN    NaN    NaN      NaN    NaN    NaN NaN    NaN    NaN Hope this at least eliminates some wrong paths of possible resolutions. Regards, IM On 11/2/20 11:11 PM, Tobias Kraemer tobias.kraemer .. mu.ie wrote: > Sent to CCL by: "Tobias Kraemer" [tobias.kraemer[-]mu.ie] > Hello all, > > I hope everyone is well. I haven't posted here for a long time, but I have encountered some strange > behaviour in a Gaussian frequency calculation that I have not seen before. There seems to be little to > no information out there on this problem, so I was hoping to get some input from the list. > Essentially, we are running a geometry optimisation with subsequent frequency job (same input) > at the B3LYP/6-311+G(d) level of theory and including the GD3BJ dispersion correction. The molecule > is a small molecules containing potassium. The optimisation furnishes a perfectly fine structure, but > the calculation then error terminates with the following message > > Maximum of*** iterations exceeded in RedStp. > > All entries in this section contain NaN entries, e.g. > > Frequencies -- NaN NaN NaN > Red. masses -- NaN NaN NaN > Frc consts -- NaN NaN NaN > IR Inten -- NaN NaN NaN > Atom AN X Y Z X Y Z X Y Z > 1 19 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 2 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 3 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 4 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 5 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 6 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > > Obviously something has gone awfully wrong in the frequencies. The problem can be reproduced by > running the frequency job on the optimised geometry alone (here we used a smaller basis set). > Interestingly the calculation finishes normally in this case, but shows only NaN entries everywhere in > the output. > > I have seen some indication that this may be related to the D3 correction, but I would like to hear your > opinion on this. We are running G09 E.01. > > your help would be much appreciated. thanks in advance. > > > Kind regards, > > Tobias> > From owner-chemistry@ccl.net Mon Nov 2 19:41:00 2020 From: "Igors Mihailovs igorsm[a]cfi.lu.lv" To: CCL Subject: CCL:G: [EXTERNAL] CCL:G: Gaussian error in Frequency Calculation Message-Id: <-54204-201102193430-521-z8IrXOTAUBlwVEMiamJnNQ:server.ccl.net> X-Original-From: Igors Mihailovs Content-Language: en-US Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Date: Tue, 3 Nov 2020 02:34:15 +0200 MIME-Version: 1.0 Sent to CCL by: Igors Mihailovs [igorsm ~ cfi.lu.lv] I can comment that I have run jobs with larger percentage of memory requested than in the job where I got 'NaN's (on identical nodes), and the job Hamiltonian was analogous (though it was a classical meta hybrid DFT (M06, in the OK case) vs. an RSH, LC-BLYP, in the failed case). Does these changes matter that much? Maybe there are some things (derivatives or so) which are actually unavailable for certain combinations of a functional (and which is not easy to find in the Reference)? But usually there are corresponding error notifications in such cases (like no 2nd derivatives for TPSSh). Sidenote: I failed to mention in the previous e-mail that my molecule is a classical organic dye (π system almost all over it) with the heaviest element being oxygen and total weight of 277 Da. Best wishes, Igors Mihailovs On 11/3/20 12:52 AM, Close, David M. CLOSED-$-mail.etsu.edu wrote: > Sent to CCL by: "Close, David M." [CLOSED++mail.etsu.edu] > Tobias: > I saw this some time ago. I think it has to do with the amount of memory you have specified. > Regards, Dave Close > > -----Original Message----- >> From: owner-chemistry+closed==etsu.edu###ccl.net On Behalf Of Tobias Kraemer tobias.kraemer .. mu.ie > Sent: Monday, November 2, 2020 4:11 PM > To: Close, David M. > Subject: [EXTERNAL] CCL:G: Gaussian error in Frequency Calculation > > > Sent to CCL by: "Tobias Kraemer" [tobias.kraemer[-]mu.ie] Hello all, > > I hope everyone is well. I haven't posted here for a long time, but I have encountered some strange behaviour in a Gaussian frequency calculation that I have not seen before. There seems to be little to no information out there on this problem, so I was hoping to get some input from the list. > Essentially, we are running a geometry optimisation with subsequent frequency job (same input) at the B3LYP/6-311+G(d) level of theory and including the GD3BJ dispersion correction. The molecule is a small molecules containing potassium. The optimisation furnishes a perfectly fine structure, but the calculation then error terminates with the following message > > Maximum of*** iterations exceeded in RedStp. > > All entries in this section contain NaN entries, e.g. > > Frequencies -- NaN NaN NaN > Red. masses -- NaN NaN NaN > Frc consts -- NaN NaN NaN > IR Inten -- NaN NaN NaN > Atom AN X Y Z X Y Z X Y Z > 1 19 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 2 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 3 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 4 1 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 5 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > 6 6 NaN NaN NaN NaN NaN NaN NaN NaN NaN > > Obviously something has gone awfully wrong in the frequencies. The problem can be reproduced by running the frequency job on the optimised geometry alone (here we used a smaller basis set). > Interestingly the calculation finishes normally in this case, but shows only NaN entries everywhere in the output. > > I have seen some indication that this may be related to the D3 correction, but I would like to hear your opinion on this. We are running G09 E.01. > > your help would be much appreciated. thanks in advance. > > > Kind regards, > > Tobiashttp://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txtThe [EXTERNAL] tag in the subject line identifies emails that do NOT originate from an ETSU person or service. Please exercise caution when handling emails from external sources. Any email that is unsolicited and requires you to take immediate action, appears to be forged or is PHISHING for information can be verified by emailing the ITS Help Desk.> >