HNFORM: k-point generating vectors and reciprocal lattice are incommensurate.

[sophie_weber]

Hello,

I am running calculations with an antiferromagnetic rock-salt structure which has a monoclinic primitive magnetic cell (magnetic space group number 15.90). When I run a bulk relaxation in VASP with the monoclinic cell using an 8x14x8 grid it works fine. I attach with mcif file with the symmetry information, as well as the relaxed bulk structure.

However, when I try to performed a calculations use a supercell with A=-2a, B=2a+3c, C=2b (attached), with vacuum and a doubled bulk cell along the supercell C direction, no matter what k-mesh I used I get the error "HNFORM: k-point generating vectors and reciprocal lattice are incommensurate and the calculations quits." If I'm interpreting this error correctly, VASP thinks the symmetry of the slab is higher than that of my k-mesh (I do notice that the ratio of my supercell B and A is exactly the square root of 2, but obviously, I can't use a k-grid with a ratio of values of exactly the square root of 2). I can get rid of this error by turning off symmetries with ISYM=0, but ideally I would like to keep the symmetries constrained to the pristine slab symmetry during the relaxation of atomic positions. It seems that the VASP symmetry routine is getting something wrong.

If you have suggestions of how I could get rid of this error while still keeping symmetries on I'd greatly appreciate it.

[manuel_engel1]

Hi Sophie,

Thanks for reaching out. This error can appear when the numbers in the POSCAR file are not specified with a high-enough precision. I noticed that your supercell POSCAR file has relatively few digits for each number. Try regenerating or symmetrizing the supercell POSCAR file with about twice as many digits and see if the error persists. If it does persist, I would ask you to please also upload the other input and output files as detailed in our forum posting guidelines.

[sophie_weber]

Hi Manuel,

Thanks very much for the quick reply. I tried what you said, regenerating the supercell with more digits, and that exact error went away, but now I get a very similar one saying
 PRICELV: current lattice and primitive lattice are incommensurate       | |     within SYMPREC.    

I tried increasing SYMPREC and that didn't fix it.

I attach the input and output of the calculation in this zip file. If you have suggestions I'd greatly appreciate it.

Best
Sophie

[manuel_engel1]

Ah, that sounds promising already. Thanks for uploading the data. I noticed that only the lattice parameters were updated to higher precision. What I meant to suggest is to update all the numbers, including the atomic positions. I'm sorry if I wasn't clear enough before. Please try again, this time updating both the lattice vectors and the atomic positions to higher precision in the POSCAR file. Let me know how it goes.

[sophie_weber]

Ah, thanks very much! Sorry for my misunderstanding. Just to clarify, would it be enough to just add zeros to the positions, or does it only work if you add nonzero digits to the atomic positions? If so it will be a bit of a pain as I think all of the symmetrisation utilities I use to not by default go to so many digits.

Once I hear back from you I'll give it a try. Thanks again for your help, I appreciate it!

[manuel_engel1]

Unfortunately, just adding zeros will not be enough, as VASP already does that when reading in the values from the POSCAR file. The issue you are experiencing is directly related to the symmetry routines in VASP as they cannot consistently find the right symmetries due to the low precision of the atomic positions.

Increasing SYMPREC can sometimes act as a workaround. However, it doesn't solve the underlying problem. In this case, I would highly recommend to update the symmetrization utilities to output more digits.

[sophie_weber]

Hello,

Thanks very much for the response. I tried regenerating the slab with 8 decimal points for atomic positions...After spending several hours pouring through both VESTA documentation as well as packages for various python utilities, I could not figure out how to output more digits then this when doing unit cell transformations; it is definitely nontrivial at least based on available documentation.

I get the same error message, i.e. that the current lattice and primitive lattice are incommensurate within SYMPREC. I would be really, really surprised if the number of digits in the positions is still the underlying problem, because the default SYMPREC=e-5 is well below this threshold, and I have never encountered this issue before (and I never output more than this number of digits in the POSCAR).

If necessary I can dig further, but before wasting a lot of time trying to figure out ways to hack programs to output a huge number of digits I was hoping you could take a quick glance at this to see if you think there are any other possibilities with a more straightforward fix.

Thanks again, and sorry for the trouble.

[manuel_engel1]

I would suggest the following procedure:

1. Extract your primitive cell from the structure. For example, I used this script.
2. Run a VASP calculation on the primitive-cell structure with ISIF=1 to update the atomic positions to high precision (if necessary, set ISYM=-1 to disable symmetry, but it runs on my end. That is likely because the effect of SYMPREC also depends a bit on system size).
3. Build your supercell again using the CONTCAR of the previous unit-cell calculation.
4. At this point, you should have a symmetrized high-precision POSCAR of your supercell that VASP can interpret without issue.

If you absolutely do not care about the symmetry of the atomic sites, then you can also disable symmetry completely in your original calculation (ISYM=-1). However, this is usually much slower and is most certainly not what you want.

The real solution is really to have more precision in your POSCAR. Changing SYMPREC can fix these issues on a surface level, but can in extreme cases also lead to other problems, such as the wrong determination of the symmetry group.

[sophie_weber]

Thank you very much, I'll give this a try and let you know.