Hi,
I got this error msg after update my system and already ran pmg config --add as in the pymatgen website but it doesn’t seem like it work.
I wonder if anyone has the similar experience could help me fix this one? /Users/nganhuynh/opt/anaconda3/lib/python3.8/site-packages/pymatgen/io/vasp/inputs.py:1839: UnknownPotcarWarning: POTCAR with symbol C has metadata that does not match any VASP POTCAR known to pymatgen. The data in this POTCAR is known to match the following functionals: ['PBE_52', 'unvie_PBE_52', 'PBE_54'] warnings.warn("POTCAR with symbol {} has metadata that does not match\
unfortunately I do not have a solution to this issue, other than just ignoring it which I have done for the last couple of months.
However, I like to add that overriding the default potcar in the vasp_input_set (vis) also does not resolve this issue, but results in an additional BadInputSetWarning. For the setting PMG_DEFAULT_FUNCTIONAL: PBE_54 in ~/.pmgrc.yaml, the folder name POT_GGA_PAW_PBE_54 in my PMG_VASP_PSP_DIR, and 'PBE_54' in vis.potcar_functional results in the following output for a quick static test calculation using a StaticFW firework from atomate on Si:
2020-11-30 09:56:30,326 INFO Launching Rocket
/home/mwo/anaconda3/envs/TriboFlow/lib/python3.8/site-packages/pymatgen/io/vasp/sets.py:441: BadInputSetWarning: Overriding the POTCAR functional is generally not recommended as it significantly affect the results of calculations and compatibility with other calculations done with the same input set. Note that some POTCAR symbols specified in the configuration file may not be available in the selected functional.
warnings.warn(
2020-11-30 09:56:30,787 INFO RUNNING fw_id: 1744 in directory: /home/mwo/FireWorks/TriboFlow/launcher_2020-11-30-08-56-30-325529
2020-11-30 09:56:30,982 INFO Task started: {{atomate.vasp.firetasks.write_inputs.WriteVaspFromIOSet}}.
2020-11-30 09:56:31,013 INFO Task completed: {{atomate.vasp.firetasks.write_inputs.WriteVaspFromIOSet}}
2020-11-30 09:56:31,063 INFO Task started: {{atomate.vasp.firetasks.run_calc.RunVaspCustodian}}.
/home/mwo/anaconda3/envs/TriboFlow/lib/python3.8/site-packages/pymatgen/io/vasp/inputs.py:1839: UnknownPotcarWarning: POTCAR with symbol Si has metadata that does not match any VASP POTCAR known to pymatgen. The data in this POTCAR is known to match the following functionals: ['PBE_52', 'PBE_54', 'unvie_PBE_52']
warnings.warn("POTCAR with symbol {} has metadata that does not match\
/home/mwo/anaconda3/envs/TriboFlow/lib/python3.8/site-packages/pymatgen/io/vasp/inputs.py:1839: UnknownPotcarWarning: POTCAR with symbol Si has metadata that does not match any VASP POTCAR known to pymatgen. The data in this POTCAR is known to match the following functionals: ['PBE_52', 'PBE_54', 'unvie_PBE_52']
warnings.warn("POTCAR with symbol {} has metadata that does not match\
2020-11-30 09:57:02,850 INFO Task completed: {{atomate.vasp.firetasks.run_calc.RunVaspCustodian}}
Current pymatgen --version ==2022 has issue in recognizing the metadata of VASP potential .52 .54 or universal. i solve this issue by downgrading the pymatgen==2019.5.8.
I used the latest pymatgen.
I also have the above problems.
The code I run is：
from pymatgen.core import Structure
from pymatgen.io.vasp.sets import MPRelaxSet
structure = Structure.from_file('ZrSi.cif')
Relax = MPRelaxSet(structure=structure )
Relax.write_input('./relax1')
An error will appear after running the code：
anaconda3/lib/python3.9/site-packages/pymatgen/io/vasp/inputs.py:1820: UnknownPotcarWarning: POTCAR with symbol Zr_sv has metadata that does not match any VASP POTCAR known to pymatgen. The data in this POTCAR is known to match the following functionals: ['PBE_52', 'PBE_54', 'unvie_PBE_52']
warnings.warn(
But this error only occurs once.When the last two lines of code are run again, the error will not occur again.And the program will also generate the POTCAR file normally.
Does anyone know what the problem is？
By chance I have been looking again into this recently. In the end these are warnings that serve a purpose: To warn the user that the potcar used is not completely identical to the one that has been used by the MaterialsProject, thus it is might be problematic to mix data calculated with it this downloaded from there.
At the moment two hashes are calculated:
data: Here the metadata only is used for the potential generation is checked. This is the data in potcar.PSCTR (were potcar is the potcar object) which is converted to a string and then hashed. If this failes, usually something is quite wrong. And a different warning that the one you report is returned that alerts you to a possible file corruption.
file: Here the full potcar file as a string is hashed and compared to the saved hashes from pymatgen. This ALWAYS FAILS for the most recent potentials (both version 5.4 and 5.2!), since they have been updated to include sha256 hashes and copyright notices in the header. The warning printed is the one you see and can be usually disregarded. Check also the VASP wiki here.
My feeling is that it would be nice to update the cashing a bit to be able to use this internal sh256 hashes if available to verify that the file is unaltered.
I believe the @rkingsbury developed the hashing stuff for the PotcarSingle class, so maybe he can advise if I should open an issue or make a pull request to add this internal check for the latest PAW potentials.
Hi @mwo, thank you for investigating! We implemented these warnings in an attempt to avert accidental use of the wrong POTCARs (and hence wasted computed time) because as you can appreciate, their versioning and distribution can be confusing.
If I understand you correctly, VASP has recently updated the PBE52 and PBE54 POTCARs they distribute to include additional metadata in the headers, is that right? If that’s the case, then I agree it would be great to re-hash the latest POTCAR files so that the file hash no longer raises this warning.
One possible issue is that now it sounds like there will be multiple valid file hashes for the same POTCAR version. I don’t recall if our current implementation can accommodate that or not. Maybe it’s OK to just check against the latest file hashes.
In any event, I would encourage an issue or PR on this. Note that although I did do the original implementation, I will defer to others on the code review at this point because they are more actively involved in using pymatgen for Materials Project VASP calculations.
Yes, both the PBE52 and PBE54 (as well as the corresponding LDA sets) have been updated to include more metadata. These are copyright notices (3 lines starting with COPYR = and a sha256 hash starting with SHA256 =.
I think there are two options here:
Rehashing the new files using md5 and updating the vasp_potcar_file_hashes.json file to include those hashes. Since the hashes in that file are the keys of the dictionary, I see no real problem to just add the new hashes, and have some duplicate values.
Look for the SHA256 lines while initializing the PotcarSingle object and check file integrity against this hash while still comparing the PotcarSingle.PSCTR hashes with the vasp_potcar_pymatgen_hashes.json file. Of course then one has to be careful to exclude the COPYR and SHA256 values from the that hash. In the case the internal hash is found, the check against the whole file hash does not need to be done of course, since file integrity is ensured by the internal hash comparison.
I would prefer the second option I think. It might be a little more work to get it implemented nicely, but it will automatically extend to newer potentials because from now on we can expect them to have SHA256 hashes in the header, so legacy POTCARS are covered by the existing pymatgen hashes, and all new ones are checked using the SHA256 for consistency and the PotcarSingle.get_potcar_hash() for compatibility with the MP.
I am happy to open an issue and/or make a pull request with this functionality, since I have already implemented the SHA256 internal check and only would have to update PotcarSingle.get_potcar_hash() and PotcarSingle.__init__ I think.
In fact I have already opened a pull request that fixes a very minor bug in PotcarSingle.get_potcar_hash(), so I could just extend that?
Please let me know who you have in mind to deal with the code review, so I can contact them regarding this.
The warnings are switched around. If the file-hash check fails, one gets a warning about metadata, while the warning about the corrupted POTCAR or incomplete database is printed when the metadata-hash does not match.
Easy fix of course, which I will include in my PR.
Rehashing the new files using md5 and updating the vasp_potcar_file_hashes.json file to include those hashes. Since the hashes in that file are the keys of the dictionary, I see no real problem to just add the new hashes, and have some duplicate values.
Look for the SHA256 lines while initializing the PotcarSingle object and check file integrity against this hash while still comparing the PotcarSingle.PSCTR hashes with the vasp_potcar_pymatgen_hashes.json file. Of course then one has to be careful to exclude the COPYR and SHA256 values from the that hash. In the case the internal hash is found, the check against the whole file hash does not need to be done of course, since file integrity is ensured by the internal hash comparison.
I would prefer the second option I think.
I think I agree, as long as in Option 2 you are still actually computing the hash of the POTCAR. If I understand you, you’re just going to compare that against the value in the file itself rather than one stored in a JSON file. That will be a more future-proof approach as you said.
good catch! and thanks for the PR. I’ll make additional comments there