## FLEUR Forum » User support » Magnetism, Non-collinear calculations, SOC » Tetrahedron integration

**05.09.2021 19:59**

Hi all,

I wanted to use tetrahedron integration for the calculation of magnetic anisotropy, but it looks like the generation of the k-point set quickly gets impossibly slow as the mesh is made more dense. I tried looking into the code and it seems like it tries to produce a somewhat optimized set of k-points instead of just taking a regular mesh, so I'm not sure what the input should be; the manual doesn't offer any help on this. I use version MaX-R4, and here's my BZ integration part in inp.xml:

<bzIntegration valenceElectrons="32.00000000" mode="tria" fermiSmearingEnergy=".00100000">

<kPointMesh nx="12" ny="12" nz="9" gamma="F"/>

<altKPointSet purpose="bands">

<kPointCount count=" 240" gamma="F"/>

</altKPointSet>

</bzIntegration>

The "out" file has this line: "coordinates of 1296 kpoints in cart. units", where 1296=12x12x9 so it seems like the input is used one way or another. This calculation (for FePt) completes fine, but for nx="24" ny="24" nz="18" the generation of the k-point set is already extremely slow and it looks like it will take hours. This is obviously not what it should be - other codes can produce tetrahedron sets in milliseconds for such meshes.

Am I doing something wrong?

**06.09.2021 16:15**

Hello,

The 'tria' mode is not generating a regular mesh for tetrahedron integration. It generates the given number of kpoints in the IBZ in a non-uniform distribution that is then divided into tetrahedra. This mode is not really meant for accurate SCF calculations but for generating a nice density of states without having to use many kpoints and has been in this state for a long time.

Additionally in the Max4 version especially due to a bug the total number of kpoints, 1296 in your case, is generated in the irreducible(!!) brillouin zone. This is why the runtime skyrockets when you move to larger kpoint sets. You can use the tag <kpointCount count="1000"/> for example to circumvent this bug.

In versions following MaX4 a new mode 'tetra' was introduced which will do the tetrahedron decomposition like you expect it.

I hope this is helpful.

Henning

**17.09.2021 19:15**

Thank you, Henning. I couldn't find any documentation or examples of the new "tetra" mode - I hope you can help me with this. Do I generate the grid and weights like this?

inpgen -inp.xml -kpt somename#tetra@gamma@grid=12,12,12

It's not clear how to combine the tags like "tetra" and "gamma", although the above seems to work. (?)

Then I should deploy the mesh as follows, right?

<bzIntegration valenceElectrons="62.00000000" mode="tetra" fermiSmearingEnergy=".00100000">

<kPointListSelection listName="somename"/>

</bzIntegration>

and this should work in both self-consistent and forceTheorem modes?

Thanks,

Kirill

**21.09.2021 12:58**

Dear Kirill

The "tetra" mode needs no special handling in the inpgen. You just generate a grid, which includes the gamma point. The tetra option in the inpgen is just a leftover, from an earlier version of this implementation. Then in the inp.xml you make the modifications exactly as you describe, setting the mode to "tetra" and selecting the kpointList you generated.

Yes this mode works in self-consistent and force theorem modes .

Best,

Henning