[Enhancement] Add lattice support

[alchem0x2A]

This is an issue tracker for PR #36 regarding the lattice support.

• VASP patch for interactive mode
  • [x] Confirm subroutine INLATT works (MPI_sum_d split on rank0 and other)
  • [x] Confirm new patch to main.F solves output truncation ~- [ ] (optional) Remove blank lines between fortran write blocks~
  • [x] Test patch.py regex patterns
  • [x] Embed patch files with py script for better distribution?
  • [x] Refine the readme for why and how
  • [x] Add example makefile, makefile.include and compile.sh from ulissigroup repo
• Code implementation
  • [x] More robust input stream writing (position only, position + lattice, raise exception when lattice change not allowed)
  • [x] Unit tests for input stream
  • [x] More robust read_results (inherit from parent read_results + completion, record vasprun.xml and outcar completeness)
  • [x] Unit tests for read_results
  • Results comparison
  • [x] Results comparison with single point Vasp
  • [x] Stress test on trajectory from VASP-internal CG routine
  • [x] Stress test with BFGS (Vasp, VaspInteractive)

[bernstei]

I once wrote my own VASP patch to add variable cell support to interactive mode, and I really need that feature, so I'm very happy to see that you're working on supporting it. If there's anything I can do to help, or just test, let me know.

[edited] what's the current status of VASP 6 support?

[alchem0x2A]

thanks @bernstei ! yeah the PR is almost done and will be merging in a few days (with README and some residual CI/CD). I think the new features basically solves the lattice input issues, but we may need some extra testing since I find tiny amount of energy difference (up to 1e-2 eV in the test systems) compared with single point calculations (may due to wavefunction extrapolation etc). I appreciate if you have insights on that :)

[edited] what's the current status of VASP 6 support?

A new feature I just added is to show the support with some known VASP binaries, see the readme section https://github.com/ulissigroup/vasp-interactive#compatibility-test-fails. The incoming v0.1.0 of VaspInteractive should support most vasp binaries (5 or 6) without issue and you can test using our script

wget https://raw.githubusercontent.com/ulissigroup/vasp-interactive/main/examples/ex00_vasp_test.py
python ex00_vasp_test.py

[bernstei]

When comparing with single point, are you doing it at fixed k-point mesh (as opposed to KSPACING) and more subtly, plane wave grid (rather than ENCUT)?

Also, did you somehow manage to get variable cell support without patching VASP? Could a patch fix the partial support issues, if flush call were added?

[alchem0x2A]

thx!

When comparing with single point, are you doing it at fixed k-point mesh (as opposed to KSPACING) and more subtly, plane wave grid (rather than ENCUT)?

There is a test https://github.com/ulissigroup/vasp-interactive/pull/36/files#diff-ac22369e17edc08f13c74d9ce58007fcd850e269314cec780780272b78d4a52a I'm comparing. I'm just letting the difference in energy threshold to be large (0.05 eV) to pass testing. Maybe it's due to the low kpts and encut (3x3x3). On the other hand, the reference energies from iPI-patched VASP show almost identical values. But still want to go back to this issue to double check

Also, did you somehow manage to get variable cell support without patching VASP? Could a patch fix the partial support issues, if flush call were added?

AFAIC It would be quite difficult (if not impossible) to do that since the INPOS subroutine in poscar.F is hardcoded. For the partial output issue yes the flush calls solves truncated output in both vasprun and OUTCAR. On slurm (and other batch) systems you probably also need to provide the "unbuffered pipe" option. I've seen this issue on one of NERSC's native VASP binaries.

[bernstei]

OK, so you are using a patched VASP. I looked through the PR and now I see it - I was just looking for something that more obviously looked like a patch file initially.

The problem with your test, from what I can tell glancing at it, is that your plane-wave mesh is probably changing in your single point calculation, but within a single VASP run the mesh is fixed even through lattice deformations. I'm not 100% sure the ASE calculator can handle it, but if you run specifying NGX, NGY, NGZ instead of ENCUT (you should be able to get sensible values from an ENCUT-based run OUTCAR), possibly also the NG[XYZ]F set as well, it should be nearly identical.

[alchem0x2A]

thx for the great insight! I think that makes sense. Will try updating the tests.

On the other hand I'm trying to make the readme / guideline to make the way of patching more obvious. Currently just using one patch.py but thinking about providing the actual examples of Dockerfiles we use in this group. See https://github.com/ulissigroup/vasp-interactive/pull/41

[alchem0x2A]

Close as #41 #36 are merged