It's still a bit slow, mainly because of the diagonalisation of the large matrices you get from the kappa-points and states. We're currently improving the efficiency by using mixed precision code.
Regards,
Kay.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I.e. the ArXiv paper says:
* Ideally, the smallest distance between k-points should be greater than the largest distance between κ-points, i.e. |κ − κ′| < |k − k′|. This will ensure that the set k + κ does not overlap for any two k-points, which may lead to double counting and an over-complete basis set.*
I'm not quite familiar with thinking in terms of reciprocal cell distances, especially when it comes to supercells. But, after some trial and error I got this:
1. Each k-point is surrounded by the box of kappa-points centered on the k-point.
2. The size of the said box depends in the ultracell size (avecu).
3. When I tried a 3x3x3 ultracell, the kappa-box was spanning from -1/3 to 1/3, which was too much for a 3x3x3 k-point grid I use. Also, some kappa+k points (Q-points?) were overlapping, which is not good (checked in KPOINT.OUT).
5. When I tried a 10x10x10 ultracell, the kappa-box spanned from -0.1 to 0.1, and was thus smaller (0.2) than the k-point increment (1/3).
6. All that was for a 3x3x3 kappa-point grid. With larger kappa-point grid, the step will be the same, but the span will increase.
7. Kappa-grid is controled via q-grid in src/genkpakq.f90 (via ngridq keyword):
! kappa-point grid should be half the Q-point grid
! ngridkpa(:)=(ngridq(:)+1)
Note: this is quite an unintuitive solution. A separate keyword would be welcome.
Am I right?
Does the size of avecu affect RAM and CPU use?
Grid sizes definitely do.
Thank you in advance.
Also, a separate notion.
I once got this error: "Error(nfftifc): n <= 0 : -1", which (I assume) comes from FFT grid being too small, and the program does not handle that specifically.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first thing you need is a large computer. We are currently calculating 2D Skyrmions and running the code on about 1200 cores.
To give you an idea of the numbers: our k-point set is quite small (4x4x2) and the q-point grid (which is twice the kappa-point grid) is 8x8x1. There are 8 atoms per unit cell and 10814 atoms per ultracell. The calculation is non-collinear and includes spin-orbit. On 1200 cores, each iteration takes a few minutes. This is either because of the large Hamiltonian or the large number of FFTs that need to be performed.
For the moment, I think it's best to stick to 2D kappa-point grids.
The size of avecu does not affect RAM or CPU use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How does the method scale in terms of CPU time?
If I have an SCF with 27 k-points and task 700 with 27x27 = 729 Q-points, do I expect a x27 factor to the SCF loop time?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that the kappa-point set is about half the Q-point set. So a 27x27x1 Q-point set would give a 14x14x1 kappa-point set.
All kappa-points have to be included in the ultracell Hamiltonian (even though the k-points are still decoupled). Thus the Hamiltonian gets large quickly as you increase the Q-point set.
We need all the eigenvalues and eigenvectors. Thus if you have an n x n x 1 Q-point set, the size of the ultracell Hamiltonian scales as n^2 and the computational time scales as n^6.
Regards,
Kay.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do I use this approach with a defect?
In a regualr periodic calculation, if I add one defect per cell, I get, in principle, infinitely many defects in a periodic lattice.
Is it possible to use the method to calculate a defect in a cell surrounded by defect-free cells?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The underlying potential generated by the nucleus is still lattice-periodic. However, you may be able to simulate a defect with an long-range external Coulomb potential.
Set the flag:
trdvclr
.true.
and provide a potential in real-space in the file VCLR.OUT. You could make the potential zero everywhere except one point. This would look like a defect to the method.
See the routine readvclr.f90 for the format of the file VCLR.OUT.
Regards,
Kay.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you, please, post here the other output comands related to Ultra-long calculations?
For example: how to output 2D charge/magnetization density map?
best,
Zhiwei
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Users,
Ultra long-range calculations have been implemented in Elk.
The respective papers are here and here.
This is a superb method, and I am happy it was implemented.
How about we make this post sticky and have the questions as separate comments?
Dear Andrew,
I'm pleased you like the method!
It's still a bit slow, mainly because of the diagonalisation of the large matrices you get from the kappa-points and states. We're currently improving the efficiency by using mixed precision code.
Regards,
Kay.
How do I choose kappa-point grid size?
I.e. the ArXiv paper says: * Ideally, the smallest distance between k-points should be greater than the largest distance between κ-points, i.e. |κ − κ′| < |k − k′|. This will ensure that the set k + κ does not overlap for any two k-points, which may lead to double counting and an over-complete basis set.*
I'm not quite familiar with thinking in terms of reciprocal cell distances, especially when it comes to supercells. But, after some trial and error I got this:
1. Each k-point is surrounded by the box of kappa-points centered on the k-point.
2. The size of the said box depends in the ultracell size (avecu).
3. When I tried a 3x3x3 ultracell, the kappa-box was spanning from -1/3 to 1/3, which was too much for a 3x3x3 k-point grid I use. Also, some kappa+k points (Q-points?) were overlapping, which is not good (checked in KPOINT.OUT).
5. When I tried a 10x10x10 ultracell, the kappa-box spanned from -0.1 to 0.1, and was thus smaller (0.2) than the k-point increment (1/3).
6. All that was for a 3x3x3 kappa-point grid. With larger kappa-point grid, the step will be the same, but the span will increase.
7. Kappa-grid is controled via q-grid in src/genkpakq.f90 (via ngridq keyword):
! kappa-point grid should be half the Q-point grid
! ngridkpa(:)=(ngridq(:)+1)
Note: this is quite an unintuitive solution. A separate keyword would be welcome.
Am I right?
Does the size of avecu affect RAM and CPU use?
Grid sizes definitely do.
Thank you in advance.
Also, a separate notion.
I once got this error: "Error(nfftifc): n <= 0 : -1", which (I assume) comes from FFT grid being too small, and the program does not handle that specifically.
The first thing you need is a large computer. We are currently calculating 2D Skyrmions and running the code on about 1200 cores.
To give you an idea of the numbers: our k-point set is quite small (4x4x2) and the q-point grid (which is twice the kappa-point grid) is 8x8x1. There are 8 atoms per unit cell and 10814 atoms per ultracell. The calculation is non-collinear and includes spin-orbit. On 1200 cores, each iteration takes a few minutes. This is either because of the large Hamiltonian or the large number of FFTs that need to be performed.
For the moment, I think it's best to stick to 2D kappa-point grids.
The size of avecu does not affect RAM or CPU use.
What happens if I specify avecu not corresponding to an integer number of unit cells?
What if it has a rotation in respect to the unit cell?
One of the nice aspects of this approach is that the ultracell does not need to be commensurate with the unit cell, or each have the same shape.
For example, our skyrmion calculation has a cubic unit cell and a hexagonal ultracell.
How does the method scale in terms of CPU time?
If I have an SCF with 27 k-points and task 700 with 27x27 = 729 Q-points, do I expect a x27 factor to the SCF loop time?
Note that the kappa-point set is about half the Q-point set. So a 27x27x1 Q-point set would give a 14x14x1 kappa-point set.
All kappa-points have to be included in the ultracell Hamiltonian (even though the k-points are still decoupled). Thus the Hamiltonian gets large quickly as you increase the Q-point set.
We need all the eigenvalues and eigenvectors. Thus if you have an n x n x 1 Q-point set, the size of the ultracell Hamiltonian scales as n^2 and the computational time scales as n^6.
Regards,
Kay.
How do I use this approach with a defect?
In a regualr periodic calculation, if I add one defect per cell, I get, in principle, infinitely many defects in a periodic lattice.
Is it possible to use the method to calculate a defect in a cell surrounded by defect-free cells?
The underlying potential generated by the nucleus is still lattice-periodic. However, you may be able to simulate a defect with an long-range external Coulomb potential.
Set the flag:
and provide a potential in real-space in the file VCLR.OUT. You could make the potential zero everywhere except one point. This would look like a defect to the method.
See the routine readvclr.f90 for the format of the file VCLR.OUT.
Regards,
Kay.
Dear Kay,
Can you, please, post here the other output comands related to Ultra-long calculations?
For example: how to output 2D charge/magnetization density map?
best,
Zhiwei