Dev vasp kpointsopt by the-hampel · Pull Request #3 · TRIQS/dftkit

the-hampel · 2026-05-04T12:07:37Z

Convert KPOINTS_OPT/LOCPROJ_OPT data (along kpath) into dft_bands_input as it is possible for Wien2k and Elk. Auto-detect KPOINTS_OPT data during convert_dft_input.

Add dedicated SVO bands tests, and include minimal reproducibility inputs (INCAR/POSCAR/KPOINTS/KPOINTS_OPT/plo.cfg plus vaspout.h5).

Warning: this is based on a non released VASP version. So reproducibility of the provided vaspout.h5 is limited.

see TRIQS/dftkit#3 for more information. - add test for spaghettis for vasp - add documentation for new vasp bands converter feature

harrisonlabollita · 2026-06-23T12:24:00Z

Hi @the-hampel, thanks for this PR! This is a nice feature. While we are at, should we also add the high-symmetry path labels and x-ticks to the converter readers? For example, in Wien2k, the high-symmetry labels and high-symmetry points are printed at the end of the case.outband file. Our converters could be upgraded to read this and store in the hdf5. The user can then read data and metadata from the hdf5 file when making their plot. What do you think?

the-hampel · 2026-06-23T12:39:07Z

Hi @harrisonlabollita , yes that might be a good idea. Problem is that in VASP this is optional. A kpath is specified in the KPOINTS or KPOINTS_OPT file and might look like this:

k-points for bandstructure using Γ–X–M–Γ–R
100
line
reciprocal
  0.00000000   0.00000000   0.00000000 GAMMA
  0.00000000   0.50000000   0.00000000 X

  0.00000000   0.50000000   0.00000000 X
  0.50000000   0.50000000   0.00000000 M

  0.50000000   0.50000000   0.00000000 M
  0.00000000   0.00000000   0.00000000 GAMMA

  0.00000000   0.00000000   0.00000000 GAMMA
  0.50000000   0.50000000   0.50000000 R

Problem is that the 4 item in each coordinate is optional and you can write whatever you want. It is used by py4vasp and it is already stored by vasp into the vaspout.h5. So I can simply add this with a line of code to store it. But I shall add a check because the user can write there whatever. Where do we want to store it?

… specific kpoints

band_energy_and_write_charge_update only stored delta_N in the seedname h5 (dft_update group), which VASP's ADD_GAMMA_FROM_FILE does not read, so the CSC loop aborted with 'no GAMMA or vaspgamma.h5 file found'. Also write the correction to vaspgamma.h5 in the layout VASP expects (top-level band_window + deltaN/{up,down}, one nb x nb block per IBZ k-point), mirroring triqs_dft_tools SumkDFT.calc_density_correction(dm_type='vasp'). Handles the non-magnetic / spin-averaged case (up == down); SP!=0 and SOC are not written by this h5 path (SO needs the legacy GAMMA text file).

band_energy_and_write_charge_update now branches on the SO flag in the seedname h5: for spin-orbit it writes the single spinor-band channel to deltaN/ud (no spin average); otherwise the spin-averaged collinear blocks to deltaN/up and deltaN/down. This matches what VASP's ADD_GAMMA_FROM_FILE reads and mirrors triqs_dft_tools calc_density_correction(dm_type='vasp'). Add test/python/vasp/charge_update with collinear, spin-orbit and IBZ-slicing cases: the expected correction is built independently in numpy, written to a reference vaspgamma.h5, and compared to the writer output with triqs h5diff; the band-energy correction value is checked separately.

Report the global DFT+DMFT iteration, each inner DMFT iteration, and the point just before the VASP charge update / DFT driver is triggered.

vasp.Driver landed on this branch; link it in the interface table instead of marking it as in development.

The upstream ctseg fix (real(...) in work_data.cpp mu extraction) means solve_generic now accepts the complex-flagged Hermitian impurity levels directly; no need to strip the imaginary noise with h.real.copy().

Skip the final VASP charge update so the run always terminates on a DMFT step instead of a now-unused DFT charge update, and add a header comment plus inline comments explaining the setup and the outer/inner loops.

Call mpi.barrier with poll_msec=100 in the vasp, qe and abinit drivers (and the plovasp sc_dmft loop) so idle ranks sleep instead of busy- polling every 1 ms while the external DFT code occupies the CPUs.

Remove a leftover vasp.lock (in addition to STOPCAR) at the start of run_initial_stage: a stale lock would make the driver believe VASP is already running. Also clarify in run_update_stage that running several VASP steps per DMFT iteration is left to the caller.

harrisonlabollita · 2026-06-23T12:56:52Z

Indeed, the same problem would occur in Wien2k. If the high-symmetry label is not indicated in their case.klist_band, we would not know it either. By default, we could just do K1,..., KN. My thought was just include in the dft_bands_input group. The field could be kpts_labels and kpts_labels_idx?

the-hampel · 2026-06-23T12:59:49Z

That sounds good. Let me instruct Mr Claude and we see how this looks.

Convert KPOINTS_OPT/LOCPROJ_OPT data into dft_bands_input with strict shell matching and optional cfg-driven PLO transforms so VASP bands can be consumed like other DFT backends. Auto-detect KPOINTS_OPT data during convert_dft_input, add dedicated SVO bands tests, and include minimal reproducibility inputs (INCAR/POSCAR/KPOINTS/KPOINTS_OPT/plo.cfg plus vaspout.h5) while suppressing confusing density/local-H diagnostics on the bands path.

Read the band-path labels for KPOINTS_OPT line-mode runs directly from vaspout.h5 (/input/kpoints_opt: mode, labels_kpoints, number_kpoints) and store them as kpts_labels + kpts_labels_idx in dft_bands_input, so the high-symmetry tick metadata is available from the h5 at plot time (as Wien2k exposes via case.outband). VASP writes two labels (start, end) per line segment; each is mapped to its 0-based position in the flattened band k-path via segment arithmetic, and the shared endpoint of two adjacent segments is collapsed into a single tick. Non-line-mode runs simply omit the labels (no text-file fallback). Extend the SVO bands test to check the Gamma-X-M-Gamma-R path (labels and indices [0, 49, 99, 149, 199]).

the-hampel · 2026-06-23T15:36:13Z

7186a41 is a first draft. Let me know what you think and if this is compatible with wien2k.

the-hampel mentioned this pull request May 4, 2026

[vasp] add feat to read dft_bands_input for VASP calculations TRIQS/dft_tools#290

Merged

the-hampel added 15 commits June 23, 2026 14:48

[vasp] first draft of VASP dft driver incl example

162d8dc

API changes update

7a089bd

more API related updates

c3165d6

[fix] the slice over bands must be explicit in case there are more at…

8e62df1

… specific kpoints

[example] log progress per iteration in vasp_csc_svo example

c0baf71

Report the global DFT+DMFT iteration, each inner DMFT iteration, and the point just before the VASP charge update / DFT driver is triggered.

[doc] VASP driver is now available

2b485de

vasp.Driver landed on this branch; link it in the interface table instead of marking it as in development.

[doc] drop ctseg real h_loc0 workaround in vasp csc example

be29e89

The upstream ctseg fix (real(...) in work_data.cpp mu extraction) means solve_generic now accepts the complex-flagged Hermitian impurity levels directly; no need to strip the imaginary noise with h.real.copy().

[doc] end vasp csc example on a DMFT step and document the workflow

99f4ec6

Skip the final VASP charge update so the run always terminates on a DMFT step instead of a now-unused DFT charge update, and add a header comment plus inline comments explaining the setup and the outer/inner loops.

[drivers] poll barriers slower while the DFT code runs

6f1e545

Call mpi.barrier with poll_msec=100 in the vasp, qe and abinit drivers (and the plovasp sc_dmft loop) so idle ranks sleep instead of busy- polling every 1 ms while the external DFT code occupies the CPUs.

expand git ignore with VASP output files

cd58781

[git] extend git ignore with VASP output files

4f10ea5

[doc] updates to VASP dftkit driver example

b2c250d

the-hampel added 3 commits June 23, 2026 16:01

Refactor VASP LOCPROJ label handling

c649337

Document VASP KPOINTS_OPT bands conversion

e99f13b

the-hampel force-pushed the dev_vasp_kpointsopt branch from b92cdf9 to e99f13b Compare June 23, 2026 14:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Dev vasp kpointsopt#3

Dev vasp kpointsopt#3
the-hampel wants to merge 19 commits into
TRIQS:unstablefrom
the-hampel:dev_vasp_kpointsopt

the-hampel commented May 4, 2026

Uh oh!

harrisonlabollita commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

harrisonlabollita commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

the-hampel commented May 4, 2026

Uh oh!

harrisonlabollita commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

harrisonlabollita commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

the-hampel commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants