Seemingly parsing issues with MLFF and VASP 6.4.1

[Alexyjones]

I just tried to use MLFF with VASP 6.4.1 and VASP interactive gets stuck at the update of coordinates, which was still working with VASP 6.4.0. I copy my energy lines from OUTCAR here, in the hope that somebody may spot the issue:

ML FREE ENERGIE OF THE ION-ELECTRON SYSTEM (eV)

free energy ML TOTEN = -903.16302845 eV

ML energy without entropy= -903.16302845 ML energy(sigma->0) = -903.16302845

[alchem0x2A]

@Alexyjones My latest version of VASP to test is 6.3.2 so I'm not 100% sure if there are more issues than the one you noticed, but it should be related to https://github.com/ulissigroup/vasp-interactive/blob/3e82db258b9c6fb47fdda8ee1c6171a71fba49f4/vasp_interactive/utils.py#L199

Previously this line "ML FREE ENERGIE OF THE ION-ELECTRON SYSTEM (eV)" is in lower case and the new output in 6.4.1 does not match the pattern.

If that's the only issue we faced, you can try one your side by changing the following line from your local copy https://github.com/ulissigroup/vasp-interactive/blob/3e82db258b9c6fb47fdda8ee1c6171a71fba49f4/vasp_interactive/utils.py#L212

newline = re.sub(pat, rep, newline, 0, re.MULTILINE | re.IGNORECASE)

hopefully that will make the parser more flexible. Due to unforeseeable changes in VASP MLFF outputs, I'd recommend sticking to the latest supported version (6.3.2) if possible. If your local changes solve your issue, I appreciate if you provide an example OUTCAR file for us to put in unit test. Of course, PRs always welcome!

[Alexyjones]

@alchem0x2A Thank you so much for your swift reply. I had to switch to VASP 6.4.1 as the MLFF received a tremendous boost in performance in that version, but the force field is not compatible anymore with older VASP versions. I noticed that I received regular warnings of this type with the previous VASP version:

/home/alexander/.local/lib/python3.8/site-packages/vasp_interactive/vasp_interactive.py:816: UserWarning: Direct reading from xml files failed. You VASP build may be truncating outputs.I'll recover the remaining information using OUTCAR and vasp.out at this point

It seems, that it just gets stuck, when VASP is waiting for a new set of coordinates. I tried your fix with IGNORECASE, but it didn't resolve the issue. I paste here the last few lines of the files, while vasp is waiting for stdin: OUTCAR:

--------------------------------------------------------------------------------------------------------

  ML FREE ENERGIE OF THE ION-ELECTRON SYSTEM (eV)
  ---------------------------------------------------
  free  energy ML TOTEN  =      -903.16302845 eV

  ML energy  without entropy=     -903.16302845  ML energy(sigma->0) =     -903.16302845

      MLFF:  cpu time      0.0209: real time      0.0209

vasp.out:

POSCAR, INCAR and KPOINTS ok, starting setup
 entering main loop
   1 F= -.90316303E+03 E0= -.90316303E+03  d E =-.903163E+03
POSITIONS AND LATTICE: reading from stdin

vasprun.xml:

 <energy>
  <i name="e_fr_energy">   -903.16302845 </i>
  <i name="e_wo_entrp">   -903.16302845 </i>
  <i name="e_0_energy">   -903.16302845 </i>
 </energy>

Sadly I failed to see, where exactly it fails. ASE seems to fail to parse the OUTPUT due to the lack of SCF iterations as it searches for the keyword "Iteration", which is completely absent. But I am not sure if this is the issue preventing VASP_interactive from proceeding.

P.S. I noted that one "ML" survives the translation: https://github.com/ulissigroup/vasp-interactive/blob/3e82db258b9c6fb47fdda8ee1c6171a71fba49f4/vasp_interactive/utils.py#L204

So in my case the parsed OUTCAR becomes:

ML  FREE ENERGIE OF THE ION-ELECTRON SYSTEM (eV)
---------------------------------------------------
free  energy   TOTEN  =      -903.16302845 eV

energy  without entropy=     -903.16302845     energy(sigma->0) =     -903.16302845

MLFF:  cpu time      0.0209: real time      0.0209

However fixing this did not change my problem...

[Alexyjones]

I have to add, that also normal calculations are broken. Just tested a standard calculation of ch4 and the same result- VASP interactive gets stuck at the point when reading from stdin.

[alchem0x2A]

~interesting @Alexyjones, could you run again python ex00_vasp_test.py to see how much vasp_interactive can extract information from vasp 6.4.1?~

@Alexyjones By accessing the source code, vasp 6.4.1 has a significant change of INPOS subroutine that breaks the current logic of vasp-interactive. Basically the new INPOS method now takes the full POSCAR content (in direct coordinates) when isif>=3 (the default behavior from vasp-interactive, to allow potential cell change)

you can confirm this by finding the following line in your vasp.out using vasp 6.4.1

POSITIONS AND LATTICE: reading from stdin

instead of the old

POSITIONS: read from stdin

this is both good and bad new for this package. VASP >=6.4.1 (hopefully no huge changes to INPOS in later versions) should fully support vasp-interactive's functions without need to patch the source code, but more logic need to be put in the source to make it work (a lot of stdout patterns are changed).

Due to my other projects at the moment (I'm not actively using vasp MLFF),the bug fix / test may take me a few weeks to finish. Meanwhile, if you have the bandwidth to submit PRs please feel free to do so

[Alexyjones]

@alchem0x2A I had a similar conclusion yesterday evening, when looking at the production of the stdin routine in vast-interactive. I can confirm that the last line in vasp.out that I see is:

POSITIONS AND LATTICE: reading from stdin

I had applied the patch.py before compiling. As far as I understood this keyword has not been used before. So if I check for this keyword and supply a POSCAR to stdout it should run again? Unfortunately my python is not very strong, but I will try if I can get it to work.