PW calculations at Gamma

[lorisercole]

In the PwBaseWorkChain, whenever one specifies a kpoints_distance that results in a [1, 1, 1] k-points mesh, i.e. a Gamma-only calculation, I suggest that the PW settings node should be set to Dict(dict={'gamma_only': True}). In this way the plugin will use

K_POINTS gamma

in the QE input file, instead of

K_POINTS automatic
1 1 1 0 0 0

The first results in the use of gamma-point specific algorithms (gamma tricks) by QE, that results in faster simulations (even 50% faster) and less memory usage (even 50% less). In some cases, I have encountered memory issues when running on GPUs using a [1, 1, 1] automatic k-mesh; using K_POINTS gamma made it work, because the memory consumption was halved.

I do not know if this matter was ever discussed with QE developers (@pietrodelugas). However, unless there are good reasons for it in certain cases that I am not aware of, it seems that enforcing a Gamma-only calculation is beneficial in the most common user case. This is particularly true when simulating large supercells for which Gamma-only is accurate enough.

Not sure if this behavior should be suggested/enforced by the workchain, or directly by the PwCalculation. Of course this issue may also apply to other QE workchains/calculations.

[pietrodelugas]

Hi @lorisercole Yes, Gamma-only is usually faster, particularly for large cells. The only caveat is that you can't use gamma calculations if you want to do a phonon calculation afterward

[mbercx]

Thanks for raising the issue @lorisercole and for the comments @pietrodelugas! In general I'm a little apprehensive towards overriding user inputs silently in a work chain, because there might always be use cases we have missed and it can be tricky/frustrating for the user to find out what's going on.

It seems like a bad idea to enforce gamma-only if create_kpoints_from_distance results in a [1, 1, 1] mesh by default if the a gamma-only calculation can't be combined with a phonon calculation afterwards. The PwBaseWorkChain doesn't know what the result will be used for. Maybe we can add another setting to the PwCalculation (e.g. enforce_gamma_only), which is False by default but can be used to enforce a gamma only calculation in case the kpoints input is a [1, 1, 1] mesh.

[lorisercole]

Yes, I understand your worries, but there are cases where this would result in several benefits. Of course the user must know what they are doing. I originally found this problem while using the PwRelaxWorkChain for a big supercell (and there the memory saving and performance are something important -- doubling the n. of nodes to increase memory would almost double the cost, when by using gamma-only would halve it).

So, as you suggested, I would add a flag that can enforce gamma-only if the required mesh is [1, 1, 1]. We need to distinguish 2 cases at the workchain level:

• the case where create_kpoints_from_distance returns a [1, 1, 1] mesh. A proper flag would authorize the workchain/calculation to use {'gamma_only': True} settings.
• the case where a user defines explicitly defines a kpoints input (yes, I stumbled upon #746 ). Here settings are not exposed like kpoints, so one should dive into the input namespaces to set it, which can be quite complicated, especially for the PwRelaxWorkChain.

[mbercx]

Thanks @lorisercole. Have to think a bit about what the best API for this would be. A settings key for the PwCalculation is definitely more hidden, and it feels more natural to have a new use_gamma_only top-level input for the PwBaseWorkChain. This should probably have three settings:

• no/false (default): do not execute a gamma-only calculation.
• mesh_dependent: Used in conjunction with kpoints_distance. If the generated mesh is 111, a gamma-only calculation is executed.
• yes/True: Always execute a gamma-only calculation.

[bastonero]

I just wanted to point out that not all pw.x subroutines support the 'gamma' option, e.g. the routine with electric fields. Thus, I would not enforce a priori.