Dear TURBOMOLE support, question about not.converged file,thank you very much!

[ComingNine]

Dear TURBOMOLE support,

   It seems that Turbomole utilizes the file "not.converged" to check the convergence. The jobex script suggests that the binary ridft is responsible for writing "not.converged", and the script convgrep is repsonsible for checking the "$convergence reached" line and creating a temporary "converged" file, and the function checkconv in the jobex script is responsible for "mv -f not.converged converged".

   My question is, this works great in Turbomole v5.10, but not in Turbomole v6.1. Please allow short description of the problem:

   The "not.converged" produced by Turbomole v5.10 looks as below (jobex -ri -c 800 -energy 5):
This is the not.converged at the very beginning:

Code: [Select]

$convcrit
  energy              5       
  cartesian gradient  3
  basis set gradient  3
  cycles              800     
$convergence not reached 
This is the format when the calculation is going on:

Code: [Select]

$convcrit
  energy               5.0000000
  cartesian gradient   3.0000000
  cycles              800     
  previous value         -153.2894341915
$convinfo
 energy change  : actual value =  -0.6528E-02 threshold =   0.1000E-04
 geom. gradient : actual value =   0.1510E-01 threshold =   0.1000E-02
$convergence not reached
$end

   The "not.converged" produced by Turbomole v6.1 looks as below (jobex -relax -ri -c 800 -energy 5):
This is the not.converged at the very beginning, the same as the one produced by Turbomole v5.10:

Code: [Select]

$convcrit
  energy              5       
  cartesian gradient  3
  basis set gradient  3
  cycles              800     
$convergence not reached 
After the first SCF cycle (by first, I mean when the job.$c just becomes job.2) ,
one can see that the "energy" on the second line changes to "polarizability":

Code: [Select]

$convcrit
  polarizability       5.0000000
  cartesian gradient   3.0000000
  cycles              800     
  previous value         -153.2610675863
$convinfo
 energy change  : actual value =   -153.3     threshold =   0.1000E-04
 geom. gradient : actual value =   0.6591E-02 threshold =   0.1000E-02
$convergence not reached
$end
$end

In the rest SCF cycles (by rest, I mean after the job.$c becomes job.3 ) ,
one can see that the "energy" on the second line changes to "polarizability"; also, the specified "$estop" is lost.

Code: [Select]

$convcrit
  polarizability       6.0000000
  cartesian gradient   3.0000000
  cycles              800     
  previous value         -153.5222247719
$convinfo
 energy change  : actual value =  -0.5119E-02 threshold =   0.1000E-05
 geom. gradient : actual value =   0.2341E-01 threshold =   0.1000E-02
$convergence not reached
$end

   I mean, could you help to explain a little about why the specified "$estop" is replaced by default (maybe built-into the binary)? Also, is the change from "energy" to "polarizibility" a typo?

   Thank you very much for your time and effort!

Best wishes,

Xichen

[S.Schmidt]

I can confirm this problem for TM6.1 with and without -relax.  It seems that the convergence criterium for the energy is lost after the second optimization step.

If you have a look at the GEO_OPT_CONVERGED file:

Code: [Select]

CONVERGENCY CRITERIA FULFILLED IN CYCLE 10

 energy change  : actual value =   0.1340E-06 threshold =   0.1000E-05
 geom. gradient : actual value =   0.7131E-04 threshold =   0.1000E-03

...

jobex WAS CALLED AS: jobex -ri -energy 8 -gcart 4 -c 200 -relax
AN OPTIMIZATION WITH MAX. 200 CYCLES WILL BE PERFORMED
CONVERGENCY CRITERION FOR TOTAL SCF-ENERGY IS 10**(-8)
CONVERGENCY CRITERION FOR MAXIMUM NORM OF SCF-ENERGY GRADIENT IS 10**(-4)
CONVERGENCY CRITERION FOR MAXIMUM NORM OF BASIS SET GRADIENT IS 10**(-3)

The convergence criteria are correctly recognized but reset to standard values during the optimization. Seems to be a bug.


UPDATE: Same thing without '-ri'. Maybe the problem is within jobex?

UPDATE2: Seems to be working in TM 6.2

[christof.haettig]

You should report this problem to your TURBOMOLE reseller.

Regards,
Christof

[uwe]

Hi,

that was a Compiler bug. A workaround in Turbomole 6.2 avoids that, so 6.2 will run correctly.

Regards,

Uwe