Using VASP k point meshes with TRIQS

[laurobbraz]

Dear TRIQS community,

I'm quite excited with all the possibilities of using TRIQS to study many-body quantum mechanics problems. This huge project motivated me to pursue some more ambitious ideas and now I'm trying to load VASP data in TRIQS.

I know there is DFTTools and if what I want to achieve is possible with it, I'd be glad to know.

I have a VASP non-self consistent simulation that ran with a regular grid of k points. My output is a function of these points and I managed to read everything with Python. I also built a Green's function manually with the data. However, I need to parse it to a TRIQS Gf object to then use the amazing fourier transform modules available. To that, I created a k mesh and a w mesh. However, when using MeshBrZone to create the k mesh from a BZ built with the VASP lattice vectors, TRIQS gives a different k mesh from the one VASP gives. I understand that this difference compromises the Fourier transformations of Green's functions. Having this fact in mind, I have a few questions that maybe people with more experience can answer:

1. Can I build my own MeshBrZone by hand? Points are equally spaced but based on the VASP output. I've tried but could not find a way to do it.

Something that I noticed is that TRIQS does not give k points in the BZ reciprocal space coordinates, but in Cartesian coordinates. VASP, on the other hand, gives k points in the BZ coordinates. I converted the TRIQS output accordingly by a simple transformation matrix.

With best regards,

Lauro.

[the-hampel]

Hi @laurobbraz ,

thank you for reaching out to us. I fear that the MeshBrZone object in triqs cannot do what you ask. I think it only works on its own generated mesh and you cannot give it a list of kpoints from for example VASP. Correct me if I am wrong @Thoemi09 @Wentzell . However, what you can do is to generate a regular mesh via MeshBrZone and use the kpoints in VASP: https://www.vasp.at/wiki/index.php/KPOINTS#Explicit_k-point_mesh . Something like:

from triqs.gf import MeshBrZone
from triqs.lattice.lattice_tools import BrillouinZone
from triqs.lattice.lattice_tools import BravaisLattice
import numpy as np


bl = BravaisLattice(np.eye(3), [(0,0,0)])
bz = BrillouinZone(bl)

mesh = MeshBrZone(bz, [5,5,5])
mesh_val = mesh.values()
print(mesh_val)

and use the output in VASP KPOINTS file and with Cartesian flag you should be able to use the cartesian coordinates that triqs gives you. that is my immediate idea. Let's see what the others say, but maybe this would work for you?

Best,
Alex

[laurobbraz]

Dear @the-hampel,

Thank you for the light-speed reply!

This idea is great and it should work indeed and I've tested it! However, it feels like I'm at a crossroads because I'm using the LOCPROJ post-processing in the VASP nscf simulation, which relies on PEAD routines. These in turn raise me an error when not using Monkhorst-Pack grids, which is the case for the regular TRIQS grid. It's a can of worms.

In more details, I've tried the following:

1. Running an SCF simulation with a Monkhorst-Pack grid and a NSCF simulation with the TRIQS grid. It raises the error: "The PEAD routines require you to use a Monkhorst-Pack type of k-points grid."
2. Running an SCF simulation with the TRIQS grid and a NSCF simulation with the exact same grid. The same error is raised.

At this point, I'm already thanking you for helping while wondering that my problem might not have a simple solution on trying to match TRIQS and VASP inputs. I'm even considering writing routines to implement the TRIQS FFTs for the Monkhorst-Pack or computing the quantities I need in a lazy and dumb, but practical way without the efficient TRIQS FFTs.

Having in mind that perhaps LOCPROJ won't allow me compatibility with TRIQS to really create a TRIQS Gf object, would you happen to know any other function or software that computes the projected wavefunctions keeping their phase (real and imaginary parts)? If positive, this would answer my question on how to work around k-points grid compatibility between TRIQS and VASP. I intend to make all advances I happen to make on this issue openly available.

With best regards,

Lauro.

[the-hampel]

Ah I totally forgot about that. That is indeed a problem right now. I am currently working on a VASP feature to allow to create projectors via LOCPROJ on a given list of kpoints, after a SCF calculations via https://www.vasp.at/wiki/index.php/KPOINTS_OPT . However, this will still take a while.

I would still be curious if we can trick triqs to take the kpoint mesh that VASP generated. In principle TRIQS just needs a homogenous k point mesh for that lattice. VASP does exactly that. It just might choose as you said a different order etc...

Best,
Alex

[laurobbraz]

Dear @the-hampel,

I'm looking forward to know bettet about the new VASP feature based on KPOINTS_OPT. I have tests running on it right now. Is there a way of keeping in touch regarding this feature? It would do exactly what I need and I would be glad to add my codes to generate VASP KPOINTS from TRIQS in the TRIQS Python utilities.

Regarding tricking TRIQS, I wonder how would TRIQS take into account that the Monkhorst-Pack grid i) features different weights for each k point and ii) is not necessarily regularly spaced (I'm not sure about this last point although I could not reproduce the MP grid using TRIQS in my tests). Any suggestions would be very welcome!

Best regards,

Lauro.

[the-hampel]

Hi @laurobbraz ,

I will update you here once such feature is available in VASP.

I think that is a problem that is not likely to be solved in TRIQS itself soon. Right now there is no way to build a custom mesh with custom weights in TRIQS, especially not if it is not regularly spaced. Such mesh would be of little help has things like FFTs would not be possible. However, I still believe it would be a nice feature addition if TRIQS would allow to use a different regular grid that the user specified. In principle in VASP and TRIQS you must be using in the end the same grid, as both rely on FFTs. Probably the order of k-points just changes etc. no?

Best,
Alex