`UnknownPotcarWarning` occurs for valid POTCARs due to mismatched line endings

[Andrew-S-Rosen]

Python version

3.11

Pymatgen version

2025.6.14

Operating system version

No response

Current behavior

Pymatgen is returning UnknownPotcarWarning for a valid POTCAR, which may cause some unnecessary concern for users. Here, I am using the La pseudopotential from the PAW_PBE.64 pseudopotential set. The POTCAR has a SHA256 hash of b7aad99517e50aeb53363b20a29bb0dfa896544080812fb23322f071df953199. A similar warning is raised for Yb. Doing the same analysis on, for instance, H or W has no warning.

from pymatgen.io.vasp.inputs import Potcar

Potcar(['La'],functional="PBE_64")

/home/asrosen/.conda/envs/cms/lib/python3.12/site-packages/pymatgen/io/vasp/inputs.py:2508: UnknownPotcarWarning: POTCAR data with symbol La is not known to pymatgen. Your POTCAR may be corrupted or pymatgen's POTCAR database is incomplete.
  return cls(file.read(), symbol=symbol or None)  # type:ignore[arg-type]

It's not just the PBE_64 sets. For instance, the following also raises a warning:

from pymatgen.io.vasp.inputs import Potcar

Potcar(['Yb'],functional="PBE_52")

Note to self: I ran into this warning in practice when running Custodian because the VaspJob and handlers call VaspInput.from_directory() which itself does a POTCAR check automatically. See here.

[esoteric-ephemera]

Just noting we're going to look at this outside GH so that I can investigate how MP's POTCARs differ from those mentioned in the issue

[Andrew-S-Rosen]

Documenting here that this is likely a Windows vs. Linux line-ending issue. On Linux, it gives me the warning, while on Windows it does not.

[shyuep]

I think this is really an unnecessary level of complexity and we should just kill off the hash check

[Andrew-S-Rosen]

Just had a user asking about this as well. I'd lean towards disabling by default at the very least.

(Sorry, don't have time to implement this --- but hopefully one day I or someone else can take care of it.)