Pseudopotential install broken?

I have been using pymatgen for several years now with my current pseudopotential setup, but since Vasp released a new set of pseudopotentials (64), I thought I would go through the installation process again and ran in to some problems. Perhaps I am making a mistake somewhere along the line, but I think I followed the instructions on the pymatgen homepage correctly.

I downloaded the different versions of pseudopotentials from the Vasp website into a temporary directory called pseudos:

potpaw_LDA.52
potpaw_LDA.54
potpaw_LDA.64
potpaw_PBE.52
potpaw_PBE.54
potpaw_PBE.64

I then made a new directory cleverly named pyatgen_pseudos and executed the series of commands

pmg config -p ./pseudos/potpaw_LDA.64 pymatgen_pseudos/
pmg config -p ./pseudos/potpaw_PBE.64 pymatgen_pseudos/
pmg config -p ./pseudos/potpaw_LDA.54 pymatgen_pseudos/
pmg config -p ./pseudos/potpaw_PBE.54 pymatgen_pseudos/
pmg config -p ./pseudos/potpaw_LDA.52 pymatgen_pseudos/
pmg config -p ./pseudos/potpaw_PBE.52 pymatgen_pseudos/

For each pseudopotential set, I was prompted about the output directory and after replying ‘y’, the following directories were in the output directory pymatgen_pseudos

POT_GGA_PAW_LDA_64
POT_GGA_PAW_PBE_64/
POT_GGA_PAW_PBE_54
POT_GGA_PAW_PBE_64
POT_LDA_PAW_52
POT_LDA_PAW_54

I then told pymatgen where the new pseudopotential directory was using

pmg config --add PMG_VASP_PSP_DIR /path/to/pymatgen_pseudos

and set the default pseudopotentials to the newest 64 version

pmg config --add PMG_DEFAULT_FUNCTIONAL PBE_64

A quick test using MPStaticSet showed that the pseudopotentials were not found

FileNotFoundError: You do not have the right POTCAR with functional=‘PBE’ and symbol=‘Ga_d’
in your PMG_VASP_PSP_DIR=‘/data/Software/Vasp/pymatgen_pseudos’.
Paths tried:

  • /data/Software/Vasp/pymatgen_pseudos/POT_GGA_PAW_PBE/POTCAR.Ga_d
  • /data/Software/Vasp/pymatgen_pseudos/POT_GGA_PAW_PBE/Ga_d/POTCAR

It would appear that pymatgen is looking in the correct directory, but with the wrong directory name (POT_GGA_PAW_PBE), rather than the correct POT_GGA_PAW_PBE_64. This is a problem and I would like to have the flexibility to be able to select the different versions of the pseudopotentials on the fly. At the moment, I have worked around the problem by creating a symbolic link from the POT_GGA_PAW_PBE and POT_GGA_PAW_LDA that points to the corresponding POT_GGA_PAW_PBE POT_64_GGA_PAW_LDA_64 directories, but it is not an ideal solution. Also why did pmg generate the self-contridictory name POT_GGA_PAW_LDA when GGA and LDA are two different functionals? Thanks for any advice on the.

For the moment the hack with symbolic links works, but a hash error is generated (perhaps this is because pymatgen is not aware of the “64” version of the pseudopotentials?
The error is:

In [3]: potcar = static.potcar

/data/mamba/envs/pymatgen/lib/python3.12/site-packages/pymatgen/io/vasp/sets.py:921: BadInputSetWarning: POTCAR data with symbol Ga_d is not known by pymatgen to correspond with the selected user_potcar_functional=‘PBE’. This POTCAR is known to correspond with functionals [‘PBE_52_W_HASH’, ‘PBE_54_W_HASH’, ‘PBE_64’]. Please verify that you are using the right POTCARs!

warnings.warn(

/lib/python3.12/site-packages/pymatgen/io/vasp/sets.py:921: BadInputSetWarning: POTCAR data with symbol As is not known by pymatgen to correspond with the selected user_potcar_functional=‘PBE’. This POTCAR is known to correspond with functionals [‘PBE_52_W_HASH’, ‘PBE_54_W_HASH’, ‘PBE_64’]. Please verify that you are using the right POTCARs!

warnings.warn(

Hi @111457, the PMG_DEFAULT_FUNCTIONAL setting only applies to the base pymatgen Potcar object. If you try this snippet:

from pymatgen.io.vasp import Potcar
p = Potcar(symbols=["Ga_d"])

you should get a PBE_64 POTCAR.

For the input sets, a POTCAR library release is fixed so that results computed with the set are consistent. Thus the MPStaticSet uses the PBE version pseudopotentials. To override that, you need to pass:

from pymatgen.io.vasp.sets import MPStaticSet

set = MPStaticSet(user_potcar_functional="PBE_64")

Because the sets expect a consistent POTCAR version, not all pseudopotentials specified by MPStaticSet will be available in another release. I just checked that the W pseudo is unavailable in the PBE_64 release.

Also why did pmg generate the self-contridictory name POT_GGA_PAW_LDA when GGA and LDA are two different functionals?

This is a bug in the library generation, pymatgen doesn’t use that name for the LDA pseudos. I’ll look into fixing that

It also looks like the library setup yielded two POT_GGA_PAW_PBE_64 directories. Is that a typo? You may want to just pip install --upgrade pymatgen to see if that resolves the library generation issues.

Thank you for reply. I should add that the duplicate directories was a consequence of an editing error of the text from “ls”.

The pseudopotential directories generated by the “pmg config -p” command were

drwxrwxr-x 2 paulfons paulfons 12288 Jul 22 15:10 POT_LDA_PAW_52
drwxrwxr-x 2 paulfons paulfons 12288 Jul 22 14:47 POT_GGA_PAW_LDA_64
drwxrwxr-x 2 paulfons paulfons 12288 Jul 22 14:46 POT_GGA_PAW_PBE_64
drwxrwxr-x 2 paulfons paulfons 12288 Jul 22 14:44 POT_LDA_PAW_54
drwxrwxr-x 2 paulfons paulfons 12288 Jul 22 14:44 POT_GGA_PAW_PBE_54

Trying the code snippet you posted above for the “Ga_d” symbol generates the error:

FileNotFoundError: You do not have the right POTCAR with functional=‘PBE_64’ and symbol=‘Ga_d’

in your PMG_VASP_PSP_DIR=‘/data/Software/Vasp/pymatgen_pseudos/’.

Paths tried:

  • /data/Software/Vasp/pymatgen_pseudos/POT_PAW_PBE_64/POTCAR.Ga_d

  • /data/Software/Vasp/pymatgen_pseudos/POT_PAW_PBE_64/Ga_d/POTCAR

Note that the directory name that is attempted is “POT_PAW_PBE_64” while the directory generated by “pmg config -p” is “POT_GGA_PAW_PBE_64”. This latter is the name generated by the “pmg” command using the procedure I summarized in my last post. Either there is a bug and the “GGA” phrase is being added or there is something wrong with the procedure I used. Any insights into the matter would be appreciated. For the moment, I am simply going to make symbolic links to directories without the GGA to get around the problem, but it would be good to know if this is an actual bug or not.

Hi @111457, this sounds like a bug on the pymatgen side, I’ll look into this and get back to you!