Part of LOM

This blog is part of web activities of the Laboratory of Organic Materials (LOM) of the Institute of Solid State Physics of the University of Latvia.
Showing posts with label Solving problems. Show all posts
Showing posts with label Solving problems. Show all posts

Friday, May 13, 2022

Gaussian input section ordering: Gen + Generic + External iteration

Sometimes I need to calculate solvent-wise relaxed excited states with a basis set not built in Gaussian. Often when I am doing this I encounter an error: either the SCRF module is trying to interpret the basis as a solvent definition:

 Using the following non-standard input for PCM:
 C H N O 0
 ------------------------------------------------------------------------------
 The following wrong keyword(s) have been found:
 C
 
 
 
 0
 ------------------------------------------------------------------------------

  or the actual solvent definition is confusing the program: 

 Unrecognized atomic symbolNonEq

 So what is going on? If we look at the official Gaussian page for the Input section ordering [1]:

 

we see that there are two SCRF sections! The problem with our input file was that we assumed that the ExternalIteration keyword is everywhere while in reality it is not present in the first job. Typically this happens because of the copy-paste attitude, also when the input files are prepared by a [non-ideally written] script.

The way I know works is as follows:

  1. For the first job with NonEq=Write we put the SCRF additional input after the Gen/GenECP additional input;
  2. For the rest of jobs, we do the opposite.
I hope this helps :)

 

[1] https://gaussian.com/input/

Sunday, November 7, 2021

Kā instalēt e-parakstu Ubuntu (ar fizisko karšu lasītāju).


 

Nākas uzrakstīt pašam, jo informācija internetos atšķiras no lapas uz lapu, galvenokārt jau svaiguma ziņā. Vietnē www.eparaksts.lv (puslīdz) aktuālā informācija ir šeit:

https://www.eparaksts.lv/download/eparakstitajs3-user-en_23012018_170527.pdf

Un nevis šeit:

https://www.eparaksts.lv/lv/lejupielades

Secība ir šāda:

1) dabūjam ierīces draiveri. Tas jāmeklē Google vai citā meklētājā; man ir DNIelectronico, kam mājaslapa ir tikai spāniski, bet viss ir aptuveni saprotams:

https://www.dnielectronico.es/portaldnie/PRF1_Cons02.action?pag=REF_1112

Neiesaku ņemt draiverus no jebkā, kas nav ražotāja mājaslapa, kā arī pirkt lasītāju, kam nav ražotāja mājaslapā Linux draiveri.

2) dabūjam AWP starpprogrammatūras pakotni no https://www.eparaksts.lv/lv/lejupielades (cilne "Starpprogrammatūra"). Vairāk neko no šejienes NELEJUPIELĀDĒJAM! Instalējot šo, apt automātiski pieinstalēs citas nepieciešamās lietas.

3) vēl ir vajadzīga viena cita starpprogrammatūra, latvia-eid-middleware, kas, kopā ar e-parakstītāja pakotni (deb, nevis tarball) ir pieejama LVRTC uzturētajā (kā izskatās) repozitorijā. Tā pievienošana ir aprakstīta minētajā pdf failā, bet ir jāatceras atjaunot distribūcijas versiju no xenial uz focal (vai kura nu būs LTS uz laiku, kad šo lasīsiet). Ja fails pazudīs, instrukciju dodu zemāk:

$ sudo wget -qO - https://www.eparaksts.lv/files/ep3updates/debian/public.key  | sudo apt-key add -
$ sudo apt-add-repository "deb https://www.eparaksts.lv/files/ep3updates/debian focal eparaksts"
$ sudo apt-add-repository --remove "deb-src https://www.eparaksts.lv/files/ep3updates/debian focal eparaksts"
$ sudo apt update
$ sudo apt install eparakstitajs3  latvia-eid-middleware eparaksts-token-signing

Voilá, viss, paldies Dievam, strādā!


Friday, May 26, 2017

ADMP error "IAtGet: Unknown atom type"

Now this is something that is not well documented by Gaussian, Inc. Description for the ADMP keyword states that most jobs will not require [additional input]. And yet if you have some additional input with lower priority than it would be for ADMP, the job dies and the following error appears:

IAtGet:  Unknown atom type

Considering that lower priority: look up the very beginning of the Gaussian NN Reference or go here (on the Gaussian homepage). For example,
  • additional input for Opt=ModRedundant or CPHF=RdFreq is of higher priority than the one for ADMP, while the
  • additional input for SCRF=Read or basis set specifications for the Gen keyword are of lower priority than the input for ADMP.
Actually, there is a hint on the mentioned pages of the Reference – the keyword field reads: ADMP and BOMD required input and ReadVelocity, ReadMWVelocity options, so we can actually figure out that there is some required input for ADMP, just like in the case of BOMD.

The solution is incredibly simple: you just have to add a blank line between the sections of additional input, the last one of higher priority and the first one with lower priority than the one of ADMP. For example, instead of
%Mem=120GB
%NProcShared=16
%Chk=/home/igors/darba/IN_dihedral_ADMP_DL1.chk

#T MaxDisk=250GB CAM-B3LYP/6-311G(d,p) ADMP=(MaxPoints=10000) Geom=(Crowd,ModRedundant) Guess=Mix scrf=(cpcm,solvent=Acetonitrile,Read)

::: IN17_469_CAM_6311_acetonitr_SASdrc_xplc_90deg IN17_469_CAM_6311_acetonitr_SASdrc_xplc_90deg GeometryOptimization Admp ADMP 1

0 1
   C     3.440990    2.083690   -0.808840
   C     3.774870    0.798710   -0.409860
   C     2.843130   -0.009000    0.245700

D 8 9 11 12 F

Surface=SAS Dis Rep Cav

you should have
%Mem=120GB
%NProcShared=16
%Chk=/home/igors/darba/IN_dihedral_ADMP_DL1.chk

#T MaxDisk=250GB CAM-B3LYP/6-311G(d,p) ADMP=(MaxPoints=10000) Geom=(Crowd,ModRedundant) Guess=Mix scrf=(cpcm,solvent=Acetonitrile,Read)

::: IN17_469_CAM_6311_acetonitr_SASdrc_xplc_90deg IN17_469_CAM_6311_acetonitr_SASdrc_xplc_90deg GeometryOptimization Admp ADMP 1

0 1
   C     3.440990    2.083690   -0.808840
   C     3.774870    0.798710   -0.409860
   C     2.843130   -0.009000    0.245700

D 8 9 11 12 F


Surface=SAS Dis Rep Cav

Yes, that's it. No more, no less. Everything goes on smoothly then.

Actually, this is in full analogy with BOMD, which requires the number of dissociation paths in the additional input section, but accepts blank line instead of zero.

P.S. Of course the structure in the input is not a real one :-)

Wednesday, December 28, 2016

Optimization with CalcAll not converged

Usually the scripts I use simply go to the next job step with Opt=CalcAll. Now, if THAT hasn't converged, it seems to be a serious trouble. I am far too lazy to change the initial geometry (although this is quite probable to help), so I try the following possibilities:
  • Opt=(CalcAll,NoRaman,MaxStep=2) (size of initial step taken by optimization algorithm; size of further steps is determined by the program as usual)
  • Opt=(CalcAll,NoRaman,RFO) (alternative algorithm)
  • Opt=(CalcAll,NoRaman,Cartesian) (optimization in Cartesian coordinates instead of redundant internals – works VERY rarely!)
  • Integral=UltraFineGrid (for meta functionals might help; also, makes sense because by default in G09 and G16 the grid used for CPHF/CPKS, which in involved in calculating the harmonic frequencies, is two steps behind the grid used for the density proper). If You do not want to repeat all other calculations with the better grid, this new one can be a better starting structure for calculation with G09 default FineGrid. (for CPKS, it's the Coarse). This problem is eliminated in G16, where the UltraFineGrid is the default (with SG1 for CPKS).
  • Also, Acc2E=11 if the CPKS problems are the culprit.
  • Sometimes switching from one algorithm to another in subsequent calculations may help.
  • With no other options, one have to use input file from different calculation method, different solvent or different ionization state.

First three options are easily implementable into Your scripts.

SCF Convergence failure. YQC and its friends

Lots of this already on the Internet, but for additional reference here is what I use in such cases, in the usual sequence:
  1. SCF=(YQC,IntRep,MaxConventionalCyc=40)
  2. SCF=(Fermi,IntRep,YQC,MaxConventionalCyc=40,NoVarAcc)
  3. SCF=(Fermi,IntRep,NoVarAcc)
  4. IOp(5/22=20) (pure EDIIS; by default, EDIIS is applied after CDIIS/EDIIS error becomes too big)
  5. Combinations of IOp(5/22=20) with all the previous variants.
IntRep is for symmetrical cases and usually shouldn't harm. If your molecule really has a symmetry other than C1, maybe Symmetry=Loose can help (usually input coordinates are a little distorted). NoVarAcc prevents too loose integral accuracy in early cycles of the SCF procedure (which usually speeds up the calculation, but may stab it in the back sometimes, too).

Note for code users:
Not always SCF failure is manifested by the

>>>>>>>>> Convergence criterion not met.

message. If the procedure failed at steepest descent stage, the following is printed:

No lower point found -- run aborted.

NB: in this case, there is no

Convergence failure -- run terminated.

message either.

Discussion of YQC output

YQC is an ingenious algorithm implemented in Gaussian. Citing the Release notes for Rev. D.01,
It does steepest descent and then scaled steepest descent as in SCF=QC, but then switches to regular SCF instead of quadratic convergence, using the quadratic algorithm only if the regular SCF fails to converge.
MaxConventionalCyc option set the number of cycles allowed for the direct SCF; usually if the calculation has not converged after 40 cycles, there is need for algorithm change. I do not remember where did I get the number, but most probably it is the ccl.net mailing list (amazing thing, check it out!).

One additional note for YQC: as the program exits one of the algorithms mentioned, it prints the SCF Done: line with corresponding energy and convergence. Usually the final energy appears the second SCF Done: line of YQC; this line can be distinguished by that the energy values are in capitals: "A.U." instead of "a.u.". Some people I know are used to capital "A.U." for finding the "right" energy for each optimization step, and usually it is completely OK. For example,

 SCF Done:  E(UCAM-B3LYP) =  -1440.14404401     a.u. after    7 cycles
 S**2 before annihilation     0.0000,   after     0.0000
 SCF Done:  E(UCAM-B3LYP) =  -1440.14408203     A.U. after   65 cycles
 S**2 before annihilation     0.0000,   after     0.0000
 QCSCF skips out because SCF is already converged.

But You should never use this in Your scripts. In rare cases, there might appear three subsequent SCF Done: lines, like here, for example:

 SCF Done:  E(UCAM-B3LYP) =  -1440.14404401     a.u. after    7 cycles
 S**2 before annihilation     0.0000,   after     0.0000
 SCF Done:  E(UCAM-B3LYP) =  -1440.14408203     A.U. after   65 cycles
 S**2 before annihilation     0.0000,   after     0.0000
 SCF Done:  E(UCAM-B3LYP) =  -1440.14408203     a.u. after    1 cycles
 S**2 before annihilation     0.0000,   after     0.0000

As You can check by running some simple calculations (e.g., CH4 with HF/6-31G(d)), in fact, lowercase "a.u." is the output of Link 508 which does both [scaled] steepest descent and quadratic (Newton–Raphson) SCF. At the same time, "A.U." is the output of Link 502, which does the direct SCF algorithm. Also, there are other output differences for the two Links:

Link 502:
SCF Done:  E(UCAM-B3LYP) =  -2125.66438397     A.U. after  129 cycles
            NFock=128  Conv=0.18D-06     -V/T= 2.0090
<Sx>= 0.0000 <Sy>= 0.0000 <Sz>= 0.5000 <S**2>= 0.8613 S= 0.5542


Link 508:
SCF Done:  E(UCAM-B3LYP) =  -2125.66438397     a.u. after    1 cycles
            Convg  =    0.3116D-05                     1 Fock formations.
              S**2 =  0.8613                  -V/T =  2.0090
<Sx>= 0.0000 <Sy>= 0.0000 <Sz>= 0.5000 <S**2>= 0.8613 S= 0.5542


So "NFock=" is not an indicator either (ah, how convenient would it be).

The point is that, in Your scripts, You should rather search for SCF Done: until something that always goes immediately after the last appearance of that phrase. Something like Population analysis or GradGradGradGrad, or The wavefunction if we are processing a Stable job (then You shouldn't search for Population analysis, it gets repeated before the result on stability) For example, if using sed:

sed '1,/The wavefunction\|Population analys\|GradGradGradGrad/p' filename | tac | grep 'SCF Don'

This works only for the first SCF energy. The general solution is, for instance,

sed -n '/SCF Don/ {:bulka s/\n/<br>/g; N; /\n SCF Don/{D};/The wavefunction\|Population analys\|GradGradGrad/!b bulka;s/<br>.*//g;p}' filename

Here, sed searches for lines with "SCF Don", sets label at them (label is named bulka), then replaces all newlines with <br> and reads in the next line. Hence, only two lines will be in the buffer (the pattern space, PS) at once. Then, if it founds that the second line in the  PS starts with " SCF Don", it deletes the first one. Next, sed returns to the label set (the bulka) unless the new line contains some of mentioned "aborting patterns" (The wafefunction, Population analys or GradGradGrad). After one of these has been reached, everything in the PS beginning with <br> is deleted, and the resulting lines (the desired final SCF energies) are printed.
Surely, this code is lame. But You should get the idea.

Fermi or level shifting (VShift)

Fermi option calls for Fermi temperature broadening during the initial iterations along with CDIIS and damping. As the broadening is removed in subsequent iterations, it should not affect the resulting energy, and it should still be comparable with results of calculations without the Fermi option. Damping is mixing of the old density matrix with the new one to reduce the amplitude of its oscillations during the early iterations of SCF procedure.[1]

VShift option shifts orbital energies (by default, it is 100 mHa, but You can set it with VShift=N where N is in millihartrees, mHa). This can aid, but the resulting SCF energy will change also; that's [probably] why, as the Gaussian 09 Reference says, the automatic archiving is disabled by this option. You should only use calculations with this option as an initial guess for subsequent 'normal' SCF job. I personally have never encountered a job that required this additional level-shifting headache, though.

[1] F. Neese, F. Wennmohs, et al. ORCA Manual, v. 3.0, p. 289 (even if You do not use alternative programs, it is highly educative to read their manuals).

Friday, April 22, 2016

ntrex1 error of Gaussian


Error


ntrex1

as a separate line at the bottom of output file occured recently, as I was transferring an .GJF file from Windows™ onto Linux® and forgot to change path for all checkpoint files. So, the system could not find "D:\darba\something.chk", and the process crashed with the aforementioned error. Please check twice when You are changing Your checkpoints! :-)

Sunday, March 27, 2016

OrtVc1 failed #1.

Well, no much information about this on the internet. We have run into this when doing polarizability calculations on a supercell cut from a molecular semiconductor crystal.
Only information I have found is available here: http://www.somewhereville.com/?p=2175.

Disabling fast multipole method (by NoFMM keyword which is denoted as "obsolete" keyword in G09 Reference) helped us to resolve the issue. We, however, wrote to Gaussian Tech support and received further advice. The key point is that the problem arises if the system considered has some symmetry and it is used in the calculation; then FMM for electric field CPHF can fail. Fast multipole method is used only for large enough systems, and not only for CPHF; so, Gaussian' s Dr. Clemente advised me to disable it only for CPHF calculation by using IOp(10/63=1) keyword in the route section of Gaussian input file.

Gaussian technical support can be contacted through help@gaussian.com, usually they are very helpful.