Outcar class returns empty magnetization attribute when parsing OUTCAR file on Windows operating system

[KylinGuo]

Python version

Python 3.11.5

Pymatgen version

2024.7.18

Operating system version

Windows 11, 24H2

Current behavior

When using the Outcar class to parse an OUTCAR file from VASP on Windows 11, the magnetization attribute returns an empty tuple (). However, this issue does not occur on Ubuntu 22.04 LTS, where the attribute works as expected.

# Windows 11
from pymatgen.io.vasp.outputs import Outcar
outcar = Outcar(filename='OUTCAR')
print(outcar.magnetization)  # ==> ()

I hope the attched file helps to reproduce this issue (Please remove the suffix .txt of OUTCAR.txt).
OUTCAR.txt

Expected Behavior

I expect the outcar.magnetization output on Windows to be identical to the one on Ubuntu 22.04 LTS.

# Ubuntu 22.04 LST
from pprint import pprint  # prety print
from pymatgen.io.vasp.outputs import Outcar
outcar = Outcar(filename='OUTCAR')
pprint(outcar.magnetization)
({'d': Magnetic moment [ 0.    -0.     4.474],
  'p': Magnetic moment [-0.     0.     0.029],
  's': Magnetic moment [-0.    -0.     0.036],
  'tot': Magnetic moment [-0.    -0.     4.539]},
 {'d': Magnetic moment [ 0.     0.    -4.474],
  'p': Magnetic moment [-0.    -0.    -0.029],
  's': Magnetic moment [-0.    -0.    -0.036],
  'tot': Magnetic moment [-0.     0.    -4.539]},
 {'d': Magnetic moment [0. 0. 0.],
  'p': Magnetic moment [-0.     0.001  0.   ],
  's': Magnetic moment [ 0. -0.  0.],
  'tot': Magnetic moment [-0.  0.  0.]},
 {'d': Magnetic moment [0. 0. 0.],
  'p': Magnetic moment [-0.    -0.001  0.   ],
  's': Magnetic moment [-0.  0.  0.],
  'tot': Magnetic moment [-0. -0.  0.]},
 {'d': Magnetic moment [-0. -0. -0.],
  'p': Magnetic moment [-0. -0.  0.],
  's': Magnetic moment [0. 0. 0.],
  'tot': Magnetic moment [ 0. -0.  0.]},
 {'d': Magnetic moment [-0. -0. -0.],
  'p': Magnetic moment [-0. -0. -0.],
  's': Magnetic moment [0. 0. 0.],
  'tot': Magnetic moment [ 0. -0. -0.]},
 {'d': Magnetic moment [ 0. -0. -0.],
  'p': Magnetic moment [ 0. -0.  0.],
  's': Magnetic moment [-0.  0. -0.],
  'tot': Magnetic moment [-0. -0.  0.]},
 {'d': Magnetic moment [ 0.  0. -0.],
  'p': Magnetic moment [0. 0. 0.],
  's': Magnetic moment [-0. -0.  0.],
  'tot': Magnetic moment [-0.  0.  0.]},
 {'d': Magnetic moment [-0.  0. -0.],
  'p': Magnetic moment [-0.  0.  0.],
  's': Magnetic moment [ 0. -0. -0.],
  'tot': Magnetic moment [0. 0. 0.]},
 {'d': Magnetic moment [ 0.  0. -0.],
  'p': Magnetic moment [ 0.  0. -0.],
  's': Magnetic moment [-0. -0. -0.],
  'tot': Magnetic moment [-0.  0. -0.]})

Minimal example

No response

Relevant files to reproduce this bug

No response

[DanielYang59]

Thanks for providing the OUTCAR and code snippet, it's super helpful. I could confirm this.

It's owing to difference in reverse_readfile from monty (different line endings for Windows \r\n and Linux\n):

pymatgen/src/pymatgen/io/vasp/outputs.py

Line 1941 in edcd465

for line in reverse_readfile(self.filename):

In a previous bug fix, I replaced the hard-coded line separator \n with an OS-independent os.linesep, which leads to failure to identify i in the following code for the case of OUTCAR, where the file was generated in Linux but parsed on Windows (which is a common use case):

filemap = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
n = len(filemap)
while n > 0:
    i = filemap.rfind(os.linesep.encode(), 0, n)
    yield filemap[i + 1 : n].decode("utf-8").rstrip(os.linesep)
    n = i

I would fix this soon.