[Wien] Optimization convergence for phonon calculations.

[Stefaan Cottenier]

TOLF is needed only when you are creating your initial, entirely optimized cell that will be the start for your phonon calculations. It is not used during the force calculation in the distorted cells.

-fc 0.1 is used as a stopping criterium during one scf cycle: the scf cycle will stop when forces do not change any longer by more than 0.1.

-fc must be smaller than TOLF, rule of thumb 3-10 times smaller. Imagine the opposite, say -fc 1.0 and TOLF=0.1 : the scf-cycle will stop as soon as forces vary within 1.0 only, but the position optimization would stop only if forces are below 0.1. If that would happen, it would be by chance only.

About the counting in your distorted cells: do you report the total number of atoms, or the inequivalent number of atoms? For more unambiguous counting, it’s easier to count the number of electrons (NE in case.in2). Does it make more sense that way? If you have 2 times more electrons, the total number of k-points can be divided by 2 (e.g. from -numk 1000 to -numk 500), without having to care about divisions per axis.

Stefaan


Van: Wien [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] Namens chin Sabsu
Verzonden: vrijdag 26 januari 2018 17:11
Aan: wien at zeus.theochem.tuwien.ac.at
Onderwerp: Re: [Wien] Optimization convergence for phonon calculations.

I would like to join this discussion and have two queries!

I finished some scf with - fc 0.1.  Previously I was not aware of TOLF but now I see the importance of TOLF factor.  Now I see that TOLF is defined in case.inM.

In UG, it is mentioned that "TOLF: force tolerance, geometry optimization will stop when all forces are  below TOLF."

In my case, TOLF value is 5 while - fc is 0.1 and total forces on the system is  "4.598435 mRy/bohr. So according to Peter's reply, this scf calculation is not good for phonon calculations and the forces must be small as much as we can get  (0.1mRy/bohr).


My question is can we use the same value for TOLF and  -fc? i.e. 0.1 .
I have an additional question regarding a number of k-points:

The pristine unit cell (225 SG has 3 non-equivalent atoms). Its P-cell is having 12 non-equivalent atoms.
If I create the distorted structure for Phonopy by 1x1x1 cell then the atoms become 16, 15, 28 and 28 with no change in lattice dimension.

When I create the distorted structure for by 2x2x2 cell then the atoms become 96, 72, 184 and 184 nonequivalent atoms in four *struct_00* files and lattice parameters are doubled which is obviously should be!

I know the basic relation between cell dimension and mesh size, nxnxn supercell Kx/n, Ky/n, Kz/n mesh size, but here I stuck and not able to pick to suitable mesh size which reduces my computational power.

In my bulk optimization, I used 12 12 12 mesh (for 3 non-equivalent atoms and total 9 atoms in 225 SG cell).

According to your expertise what should be the mesh size for the structure created by 1x1x1 supercell (four distorted structures with 16, 15, 28 and 28  atoms)?

What should be the mesh size for the cases (from 2x22x2 supercell) with atoms 96, 72, 184 and 184?

Why I asked this question on mesh size is: because with 6x6x6 mesh size and RKmax 6 one scf cycle is not completed even after two hrs on 8 cores (for a single case).

Hope, I explained my query nicely!


Regards

Chin S.


On Friday 26 January 2018, 8:55:18 PM IST, Peter Blaha <pblaha at theochem.tuwien.ac.at<mailto:pblaha at theochem.tuwien.ac.at>> wrote:



Yes, of course for phonon calculations you have first to optimize the
structure. And for that, TOLF should be reduced, because for phonons you
should start with a structure which has "zero" (typically 0.1 to 0.01)
forces.
tolf tells the code when to stop moving atoms.
-fc xx  tells the code to stop the scf when forces are converged to xx mRy.


On 01/26/2018 02:30 PM, Luis Ogando wrote:
> Dear Wien2k community,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20180126/967d4cef/attachment.html>