Recent Posts

Pages: [1] 2 3 ... 10
1
Ridft, Rdgrad, Dscf, Grad / Re: scfdamp
« Last post by uwe on December 13, 2017, 11:07:36 am »
Hello,

Quote
So does the high value of $scfdamp mean that DIIS won't include a lot of old Fock matrices in creating the error

the number of included Fock matrices does not change. DIIS is done in the same manner, but how much of the DIIS predicted coefficients are added to the Fock matrix, which comes out of the usual SCF procedure, is determined by this damping factor. Instead of simply adding Fock + DIIS (in a symbolic way of notation), it is Fock + 1/[damping factor] * DIIS. Well, actually the denominator is (1+damping factor) to have full DIIS with a damping factor of zero...

 Regards,

Uwe
2
Ridft, Rdgrad, Dscf, Grad / Re: scfdamp
« Last post by Addiw7 on December 12, 2017, 11:04:14 am »
Dear Uwe,

Could you explain what you mean by
A high value of $scfdamp will follow DIIS only a very short way, a low value of the damping factor will trust the new extrapolated coefficients.
, please?
So does the high value of $scfdamp mean that DIIS won't include a lot of old Fock matrices in creating the error
vector?

Best wishes,
Dawid
3
Escf and Egrad / Symmetry of excited states
« Last post by dcav on December 10, 2017, 12:45:02 pm »
Hello everyone,
   Recently I've been trying to use turbomole to calculate tddft excitation energies and I am having trouble reading the output file. When we specify the symmetry in the control file using $soes, what we specify is the excitation vector symmetry. That much I understand. However, in escf.out file, it is also specified the symmetry:

"                         1 singlet ag excitation
 Total energy:                           -385.3282662922613
 Excitation energy:                      0.2312951426386921"

    Is this the symmetry of the excited state, as in the ouput of ricc2, or is this the symmetry of the excitation vector?
    Thanks in advance,
    Daniel.
4
Aoforce and Numforce / Re: aoforce + cosmo convergence
« Last post by uwe on December 08, 2017, 10:10:53 am »
Hi Martijn,

the default convergence threshold is 10^-5, so you are more or less almost converged (1.48D-05). If the usual convergence enhancers like increasing DFT grid size (m3 to m4 or 4 or m5) and density convergence ($denconv 1d-7) do not help, you probably hit the accuracy limit of the COSMO cavity derivative (holes in the cavity, very high charges on some small cavity patches, ...).

A pragmatic solution would be to restart escf (since you are already near convergence) and change the convergence settings for the CPKS iterations to $rpaconv 4

Regards,

Uwe

5
Aoforce and Numforce / aoforce + cosmo convergence
« Last post by martijn on December 07, 2017, 05:30:08 pm »
Hi,

When combining aoforce with cosmo in 7.2.1 I encounter the following situation that I have never observed for gas phase frequency calculations:

COSMO cphf update
   23       a      170        1.482021067048531D-05
            b      170        7.672115628665743D-06
 
 COSMO cphf update
   24       a      170        1.482182443756061D-05
            b      170        7.672115628665743D-06
 
 COSMO cphf update
   25       a      170        1.481440684000221D-05
            b      170        7.672115628665743D-06
 


 Warning! No convergence within  25 iterations.
 Unless you have specified a very low $escfiterlimit/$forceiterlimit,
 this is a reason to worry!



========================
 internal module stack:
------------------------
    force
========================

 CPKS-Iteration did not converge !
 force ended abnormally


Increasing the number of allowed iterations makes no difference whatsoever; the error/norm stays the same.

Does anybody have an idea what might be going on and if there's a parameter to play with in order to aid convergence? A NumForce + cosmo calculation on the same structure converges without any issues.

Thanks,

Martijn
6
News and Announcements / Turbomole 7.2.1 update release
« Last post by uwe on November 24, 2017, 06:02:44 pm »
Dear Turbomole users,

the Turbomole version 7.2 shows (on some CPU types with AVX2 and newer) unexpected behavior when running the SMP parallel version (job seems to run, but does not proceed). It also refuses to run on older Linux distributions and stops with a GLIBC error.

In addition, we have been asked about an own version for the new AMD CPU types (Ryzen and EPYC). And we had a couple of user requests, see list below.

We thus release a minor update, version 7.2.1, which includes a couple of changes:

A) technical issues

- parallel SMP version runs stable also on new CPU types

- new optimized binaries for the latest AMD CPU family

- minimum requirement for GLIBC version reduced to GLIBC_2.4
  and should now run on older Linux versions too

- TTEST script failed due to security changes of Perl on newest
  Debian distributions, fixed


B) new features

- new X2C basis set family included [1]

- XCFun functionals (M06-L, ...) enabled in MPI version

- MPI server task can now be sent to sleep during the
  calculation, reduces the CPU usage of this task
  distributing process.
    (export TM_SERVERSLEEP=on  # see documentation)

- NumForce uses all CPUs from the $PARNODES
  variable if PARA_ARCH=SMP is set


C) bug fixes

- fix problem with RECL error when using aoforce

- bug fix of point charge gradients for MPI version
  (7.2 gives NaN in some cases)

- improved TDDFT restart

- EDA keyword recognition was faulty, fixed

- changes which lead to a more stable behavior
  if small molecules are calculated with a large number of CPUs


D) TmoleX changes

- visualization of periodic geometry optimizations in 1D and 2D
  corrected

- improved import of old TmoleX projects

- spectra plot, corrected plot range


[1] Patrik Pollak and Florian Weigend
    Segmented Contracted Error-Consistent Basis Sets of Double-
    and Triple-ζ Valence Quality for One- and Two-Component
    Relativistic All-Electron Calculations
    Journal of Chemical Theory and Computation 2017 13 ( 8 ), 3696-3705
    http://pubs.acs.org/doi/abs/10.1021/acs.jctc.7b00593
7
Miscellaneous / Re: t2x breaks symmetry
« Last post by resofidentity on November 17, 2017, 07:58:46 am »
Well it is by-eye inspection.
 R
8
Miscellaneous / Re: t2x breaks symmetry
« Last post by uwe on November 16, 2017, 03:54:31 pm »
Hi,

t2x does nothing but to multiply the coordinates with the Bohr radius to convert them from atomic units to . So 'symmetry breaking' can only happen in the very last digit due to rounding errors.

Turbomole itself should and will not complain about such tiny deviations - I wonder which program told you that the symmetry is broken??

Regards,

Uwe
9
Miscellaneous / t2x breaks symmetry
« Last post by resofidentity on November 16, 2017, 10:11:24 am »
Hello all,

I just noticed that when one uses t2x on a symmetric input the coordinates very slightly break the symmetry, I suppose there are somewhere some rounding+cutoff problems. In some cases that can be a bot annoying, not that I couldn't write a workaround for myself, but I thought it would be better if the problems could be fixed directly in t2x.

Cheers
 R
10
Define / Re: EHT dimension problem
« Last post by juhidutta on November 15, 2017, 05:23:04 am »
Hi Uwe,
Thanks for your reply. But the way you told, it is not working. It is showing the same error. I am using Turbomole 6.5 version. Please just tell me How to use external guess mos avoiding the eht?? Or if anything else is possible, please suggest me that also.
actually the problem is due to the increase of Se atoms not the total no. of atoms. So please help me out.

Thanks,
Juhi.
Pages: [1] 2 3 ... 10