Hi
On the wiki page regarding the new LFOCKACE feature in VASP 6 (wiki/index.php/LFOCKACE), it says that this tag can be used in combination with ALGO = Normal for hybrid calculations, giving a speed up by ~3x.
However hybrid calculations are often unstable with ALGO = Normal, requiring tuning of mixing parameters etc.
I was thinking that this wiki entry might be suggesting that VASP 6 hybrid calculations with ALGO = Normal would be more stable than for VASP 5, but from running some tests on CdTe and LaZnOP, this doesn't seem to be the case.
Am I correct in saying that hybrid calculations with ALGO = Normal on VASP 6, with LFOCKACE = True, aren't any more stable than VASP 5, but rather for hybrid calculations that run ok with ALGO = Normal on VASP 5, running them on VASP 6 with LFOCKACE will allow a speedup of ~3x?
For other algorithms (e.g. ALGO = All), I have noticed a slight speedup with LFOCKACE = True (of approx. 15%). Is there a different ALGO that would be stable with hybrid calcs and give a better speedup?
Any help with this is much appreciated!
Cheers
Seán
ALGO = Normal with LFOCKACE = True in VASP 6
Moderators: Global Moderator, Moderator
-
- Newbie
- Posts: 4
- Joined: Mon Nov 18, 2019 3:22 pm
-
- Global Moderator
- Posts: 460
- Joined: Mon Nov 04, 2019 12:44 pm
Re: ALGO = Normal with LFOCKACE = True in VASP 6
In our experience ALGO = N is generally speaking not unstable when used with hybrid functionals.
Could you provide us an example where it happens? We would like to have a look at this problem.
The ~3x speedup associated with the use of the adaptively compresses exchange (LFOCKACE=T) for ALGO=N is meant to be understood as a speedup per electronic iteration.
To see a similar speedup in the overall "time-to-solution" would indeed require that ALGO=N works as intended.
Could you provide us an example where it happens? We would like to have a look at this problem.
The ~3x speedup associated with the use of the adaptively compresses exchange (LFOCKACE=T) for ALGO=N is meant to be understood as a speedup per electronic iteration.
To see a similar speedup in the overall "time-to-solution" would indeed require that ALGO=N works as intended.