Supercell

[jk262626]

Hi Nakib,
I just wonder how your elphbolt code defines supercell. I did epw calcuation of Al with 3x3x3 supercell and I got some error when matching the second order force constants while running elphbolt.

[nakib]

Hi jk262626,

Can you share your epw and elphbolt input files so that I know what you are trying to achieve? Are you asking how to set the quantity coarse_qmesh in the namelist wannier?

Best,
Nakib

[jk262626]

I mean like we used supercell with 27 atoms in epw calculation (see the below quote) but we couldn't find a part where we can define atoms in elphbolt input script.

Al
27
Cartesian
0.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000003 2.0194648465912501 2.0194648465912501
0.0000000000000006 4.0389296931825003 4.0389296931825003
2.0194648465912501 0.0000000000000000 2.0194648465912501
2.0194648465912506 2.0194648465912501 4.0389296931825003
2.0194648465912506 4.0389296931825003 6.0583945397737509
4.0389296931825003 0.0000000000000000 4.0389296931825003
4.0389296931825003 2.0194648465912501 6.0583945397737509
4.0389296931825012 4.0389296931825003 8.0778593863650006
2.0194648465912506 2.0194648465912501 0.0000000000000002
2.0194648465912506 4.0389296931825003 2.0194648465912501
2.0194648465912510 6.0583945397737509 4.0389296931825003
4.0389296931825003 2.0194648465912501 2.0194648465912501
4.0389296931825012 4.0389296931825003 4.0389296931825003
4.0389296931825012 6.0583945397737509 6.0583945397737509
6.0583945397737509 2.0194648465912501 4.0389296931825003
6.0583945397737509 4.0389296931825003 6.0583945397737509
6.0583945397737518 6.0583945397737509 8.0778593863650006
4.0389296931825012 4.0389296931825003 0.0000000000000004
4.0389296931825012 6.0583945397737509 2.0194648465912506
4.0389296931825012 8.0778593863650006 4.0389296931825003
6.0583945397737509 4.0389296931825003 2.0194648465912506
6.0583945397737518 6.0583945397737509 4.0389296931825003
6.0583945397737518 8.0778593863650006 6.0583945397737509
8.0778593863650006 4.0389296931825003 4.0389296931825003
8.0778593863650006 6.0583945397737509 6.0583945397737509
8.0778593863650023 8.0778593863650006 8.0778593863650006

[nakib]

In elphbolt, the lattice vectors and the basis atoms are specified with lattvecs and basis in crystal_info (https://github.com/nakib/elphbolt?tab=readme-ov-file#crystal_info). Note the coordinate system. The basis atoms' positions have to be given in crystal coordinates.

May I ask why you want to calculate a 3x3x3 supercell of Al? This will lead to 81 phonon branches and the transport calculations will be rather expensive. Not to mention, the phonon and the EPW calculations must also have been extremely expensive. Typically one would just need to calculate transport properties with the primitive unit cell.

[jk262626]

Thank you for your answer! Okay I understand you use primitive unit cell in elphbolt code.
I was using wrong number of basis atoms. Now the code works.
However, I'm still wondering how your elphbolt code use force constants made from supercell.
We generated 2nd and 3rd order force constants using fitting method (instead of perturbation theory) with 3x3x3 supercell to have enough cutoff length and got multiple row of force constant data according to 27 atoms. I wonder how your code match the data to the single primitive cell.
I noticed that you also do 3rd order force constant calculation with supercell for silicon example, and then use the data to the elphbolt code which is using primitive unit cell.

[nakib]

The 2nd and 3rd order force constants calculations can either be done with DFPT (which you can do with a primitive cell) or DFT (which requires supercells with a few atoms displaced in each). In any case, the real space information is already present in the force constants files, so elphbolt does not require the user to explicitly pass this information again through the input.nml file. I hope this answers your question. Let me know if anything is still unclear.

[jk262626]

Hi Nakib,

In the middle of running elphbolt, the calculation was stuck in "Calculating density of states..." stage for over 10 hours.
Do you happen to know the reason?

I'm attaching slurm and input files.
Attachment.zip

[nakib]

Thanks. First a few general comments about the input file. You are calculating transport in a metal. So you probably want to set the flag metallic to .true. in the namelist group electrons. This also means that you should remove the indlowconduction line.

Regarding the stall: you have just 16 irreducible q-points. Since you are parallelizing these over 20 coarray images, the code is stalling. This is not a desirable behavior and I will fix this issue in the near future. But for the time being, you should use a smaller number of coarray images. That said, for publication quality, converged calculations you will probably need a q-mesh ~ 50x50x50 and k/k+q-mesh of 100x100x100. In those cases, it will almost always be the case that the number of coarray images will be smaller than the number of irreducible points. I hope this helps. But keep an eye out for a fix to this issue.

[nakib]

Update: On the develop branch, the issue with the stalling you reported above should now be fixed.

[jk262626]

Thank you so much! Now it's running well

May I ask why you used lattice vector of silicon as (a) instead of using (b)?
(a)
Lattice vectors [nm]:
-0.27010011E+00 0.00000000E+00 0.27010011E+00
0.00000000E+00 0.27010011E+00 0.27010011E+00
-0.27010011E+00 0.27010011E+00 0.00000000E+00
(b)
Lattice vectors [nm]:
0.27010011E+00 0.00000000E+00 0.27010011E+00
0.00000000E+00 0.27010011E+00 0.27010011E+00
0.27010011E+00 0.27010011E+00 0.00000000E+00

[nakib]

Lattice vectors are not uniquely defined. I typically like to use the convention given here (for silicon it would be ibrav = 2): https://www.quantum-espresso.org/Doc/INPUT_PW.html#idm224

You are free to define the lattice vectors any way you like as long as they describe your crystal system. That said, you just need to use the same lattice vectors for all of your calculations. For example, you should not use different lattice vectors for EPW and elphbolt.

[jk262626]

Hi Nakib,
How are the #k and #q in interaction step calculated?

[nakib]

Could you be a bit more specific? Are you asking about irreducible vs full Brillouin zone meshes? Or is your question about how the computational task is parallelized? Also, which interaction step? There are different types of interactions.

[jk262626]

In the 'Calculating interactions' stage, I got #q=3107 and #k=11467.
The number of k points is so big that the calculation in this stage is taking so long and I just want to know how the #q and #k is determined.

I'm calculating Al with the following mesh
q-mesh = 50 50 50
k-mesh = 150 150 150
and I'm attaching my slurm file (the calculating is still running)

slurm-29157039.zip

[nakib]

The output log is already explaining the meaning of these numbers. I see that you are using just 20 images. For a 150x150x150 mesh, you should use more images, if you have access to the resources. The computational load is simply very big. Once these calculations are done, for all other temperatures you can reuse all the temperature independent quantities: gk2, gq2, and V2. You might find it useful to read the technical paper to get familiar with all these quantities. Best, Nakib

…

On Tue, Mar 12, 2024, 19:36 Jiyoung Kim ***@***.***> wrote: In the 'Calculating interactions' stage, I got #q=3107 and #k=11467. The number of k points is so big that the calculation in this stage is taking so long and I just want to know how the #q and #k is determined. I'm calculating Al with the following mesh q-mesh = 50 50 50 k-mesh = 150 150 150 and I'm attaching my slurm file (the calculating is still running) slurm-29157039.zip <https://github.com/nakib/elphbolt/files/14577133/slurm-29157039.zip> — Reply to this email directly, view it on GitHub <#131 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN7Y2OXZR4OBA5WT4DGY23YX5DMNAVCNFSM6AAAAABD4K35M6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONRTHAYDA> . You are receiving this because you commented.Message ID: ***@***.***>

[jk262626]

I ran the calculation with 128cores and I got some error like this.

slurm-29216762.zip

[nakib]

This looks like a memory limitation issue. You can check if you have higher memory nodes.

Before running 50x50x50 q-mesh and 150x150x150 k-mesh, I can suggest running something like 25x25x25 and 75x75x75 first. Of course, you will then have to do convergence tests with respect to the mesh densities.

[jk262626]

Hi Nakib,
I'm trying calculation for Al and I could get results at 100K, 300K, and 400K.
But sometimes I got an error like this when I'm trying calculation with 200K and 500K while using the same input data set.
I think it's kind of computational problem. Do you have any idea?
slurm-29572286.zip

[nakib]

Hmm...I have not seen this particular error before.

Could you include your input.nml file and the job submission script? It is not possible for me to guess what is happening without looking at these files. If you send them over, I will take a look after the Easter holidays.

By the way, you should be using the flags read_gk2, read_gq2, read_V2 whenever possible since gk2, gq2, and V2 only have to be calculated once. Once you have calculated these quantities for one temperature point, you can then reuse them. These are all temperature independent quantities. I draw your attention to the following sections of the documentation: https://github.com/nakib/elphbolt?tab=readme-ov-file#numerics and https://github.com/nakib/elphbolt?tab=readme-ov-file#description-of-output-files

[jk262626]

Thank you for the suggestion!
I did like the followings
input.zip
job.zip
I changed only T variable in 'crystal info' section in the input file for different temperature and run the whole calculation again.

[nakib]

It is not clear from the job submission script how you are setting up the calculation directories. If you run multiple temperature jobs in the same directory (./result/) simultaneously, then multiple calculations will try to read/write the same files. You should have a different workdir for each temperature. You can use the the same workdir for different temperatures as long as all of these different temperature calculations are done one after another, not simultaneously.

You should not run the whole calculation for every temperature since the temperature independent quantities are the most expensive parts of the calculation. The paper associated with the code discusses this. I suggest doing one temperature calculation all the way through. Following that, you can do different temperature calculations with the read_gk2, read_gq2, and read_V2 all set to .true.. All of these latter calculations will be much faster and you can get your work done with less resources.

[jk262626]

Hi Nakib,

I have a simple question about the Si example.

1. I'm little bit confused about enref and chempot. You used 6.7eV for silicon but isn't it 0.5eV (fermi level of silicon at 0K)?
2. What does lowest and highest transport band mean?

Thank you!

[jk262626]

3. What does K0.dev (%) mean in slurm file? cause I got large value of 66%

[nakib]

Dear jk262626,

1. Both enref and chempot are described in the documentation. I don't understand the number 0.5eV. Can you share a reference from where you are getting the information that the Fermi level of Si is 0.5eV at 0K? Also, elphbolt does not ask for a Fermi level, rather a chemical potential.
2. These are explained in the documentation. All the bands are not transport active and you can reduce computational load by choosing the bands that are close to where your chemical potential will be.
3. KO dev (%) stands for the deviation from the Kelvin-Onsager relationship. I refer you to the section "Transport coefficients" of npj Comp. Mat. 8, 28 (2022) where this is explained. This number should ideally be zero or, at most, very very small. I can't comment on your calculation without knowing the details such as all the input files and the relevalt output files. Is this still the silicon example?

A general comment: you are asking these questions in a discussion thread titled "supercell". Perhaps you can consider starting a different discussion with a more appropriate title.

Best,
Nakib