Gibbs Workflow -- possible LEPSILON oversight?

[mattmcdermott]

Was discussing with @mkhorton a potential oversight in the Gibbs workflow when QHA analysis with phonopy is enabled. When a user sets input qha_type="phonopy", the workflow sets LEPSILON=True, which should be used to calculate the Born effective charge and dielectric constant that is fed in as the "non-analytical correction" in phonopy (see bottom of page here for explanation)

However it doesn't seem that the Gibbs workflow ever explicitly uses this non-analytical correction term, which should appear as an additional kwarg here: https://github.com/hackingmaterials/atomate/blob/a2cfee5c7cad28e43b2756a4168959a92f4494dc/atomate/vasp/analysis/phonopy.py#L75

which is an nac_params dict of the form:

 born = [[[1.08703, 0, 0],
          [0, 1.08703, 0],
          [0, 0, 1.08703]],
         [[-1.08672, 0, 0],
          [0, -1.08672, 0],
          [0, 0, -1.08672]]]
 epsilon = [[2.43533967, 0, 0],
            [0, 2.43533967, 0],
            [0, 0, 2.43533967]]
 factors = 14.400
 nac_params = {'born': born,
               'factor': factors,
               'dielectric': epsilon}

Can anyone confirm if this is truly an oversight or if we aren't seeing something?

[mkhorton]

Yes, I looked into this also -- I don't run Gibbs/phonopy workflows myself so would appreciate insight from those that do, but this looks like a clear error to me.

Suggested remedy would be to disable LEPSILON by default, add a non_analytical_correction=False kwarg to the workflow, and if set to True, enable LEPSILON, properly parse the Born effective charges from the vasprun.xml, and pass them through to the Phonopy initializer. Given the computational cost of LEPSILON (and the fact that it can be flaky) fixing this seems to be a priority for anyone running the Gibbs workflow.