Strange output for |g| generated by print_gkk.f90

[AgentZero]

Dear Samuel,

Thank you for sharing the subroutine print_gkk. I have run this subroutine for MgB2 using the double-delta approximation.
In my calculation, the coarse k/q-mesh, and fine k/q-mesh are all 6x6x6. I set three runs with same input, but very different |g| are obtained.
I have checked that there is no difference in MgB2.ukk, MgB2.kmap, MgB2.kgmap, *.fmt files for the three runs.
It is stranger that these three runs give the same Tc (using grep "mu = 0.10 Tc" MgB2.epw.out).
In my understanding, different |g| will result in different lambda and Tc. Furthermore, some |g| datum are "Infinity" or "NaN" (please see below).


Each run produces a MgB2.epmatwp1 file. I restart these three calculations with corresponding MgB2.epmatwp1 file. The |g| in output files seems
more reasonable (without Infinity and NaN) and almost the same for the three runs. And the restart |g| is markedly different with the one obtained by direct run.
Could you please tell me why these three runs give different |g|, but the same lambda? Which |g| is more reliable, the direct run or the restart run?


Best wishes,
Miao Gao

------------------------------ "Infinity" and "NaN" |g| ---------------------------------

ik = 48 coord.: 0.1666667 0.1666667 0.8333333
ibnd jbnd imode enk[eV] enk+q[eV] omega(q)[meV] |g|[meV]
------------------------------------------------------------------------------
3 3 1 4.3969 4.8781 9.7650 Infinity
3 3 2 4.3969 4.8781 9.7650 Infinity
3 3 3 4.3969 4.8781 17.9578 Infinity
3 3 4 4.3969 4.8781 38.8068 Infinity
3 3 5 4.3969 4.8781 38.8068 Infinity
3 3 6 4.3969 4.8781 48.2284 0.4741464696-136
3 3 7 4.3969 4.8781 61.4255 0.4019667391+127
3 3 8 4.3969 4.8781 61.4255 0.4019667391+127
3 3 9 4.3969 4.8781 86.2050 0.0000000000E+00
3 4 1 4.3969 5.8868 9.7650 NaN
3 4 2 4.3969 5.8868 9.7650 NaN
3 4 3 4.3969 5.8868 17.9578 Infinity
3 4 4 4.3969 5.8868 38.8068 NaN
3 4 5 4.3969 5.8868 38.8068 NaN
3 4 6 4.3969 5.8868 48.2284 0.1203197387E+27
3 4 7 4.3969 5.8868 61.4255 Infinity
3 4 8 4.3969 5.8868 61.4255 Infinity
3 4 9 4.3969 5.8868 86.2050 0.0000000000E+00
3 5 1 4.3969 13.6618 9.7650 0.8940046265E+54
3 5 2 4.3969 13.6618 9.7650 0.8940046265E+54
3 5 3 4.3969 13.6618 17.9578 Infinity
3 5 4 4.3969 13.6618 38.8068 NaN
3 5 5 4.3969 13.6618 38.8068 NaN
3 5 6 4.3969 13.6618 48.2284 0.2750535624E+33

[sponce]

Dear Miao Gao,

The g are not stored and therefore not used for restart.

Only the g printed with the first full run should be reliable.

Best,
Samuel

[AgentZero]

Dear Samuel,

Thank you very much for the quick reply. I can not fully understand your answer. Since in a restart calculation, we can calculate e-ph coupling constant lambda,
which is related to |g|. I guess that the array epf17 or epmatf should be stored in the normal calculation (am I right?).
Because |g| is determined using epf17 in print_gkk.f90, thus |g| can be obtained in a restart calculation if epf17 are stored.
By the way, could you give me some clue about the reason for different |g| with the same input parameters? Look forward to your reply!

Best wishes,
Miao Gao

[andreyl]

Dear Samuel,

Since in a restart calculation, we can calculate e-ph coupling constant lambda,
which is related to |g|. I guess that the array epf17 or epmatf should be stored in the normal calculation (am I right?).
Because |g| is determined using epf17 in print_gkk.f90, thus |g| can be obtained in a restart calculation if epf17 are stored.

Dear Miao,

I have a limited understanding of the source code, but I will try to give the answer to this part of your question.
The subroutine, which deals with e-p matrix elements on fine grid is called ephwann_shuffle, check it out in the source code. It calculates the epmatf and than stores it in epf17 (in memory). This exact subroutine calls prtgkk before the write_ephmat function (which actually do write e-p matrix elements on fine grid to disk for the Eliashberg equation, but that is another story).
So, yes, the e-p matrix elements on fine grid (epf17) are not stored to disk (until required by Eliashberg equation, but once again, out of scope here), but those on coarse grid are actually stored, and when you restart with tags elph and ep_coupling set to true, code recalculates epf17 from the coarse grid values (those in .epb* and .epmatw* files).
BTW lambdas, as well as a2f values are stored to disk, if the corresponding tags are set to true, hence your correct (or at least consistent) T_c.
What I think is, If your calculation is generally ok, the fine grid e-p matrix elements from restart run also should be correct.

I would be very grateful to Samuel, if he could confirm or correct/contradict my answer.

Best wishes,
Andrei

[sponce]

Dear Andrei,

That's quite correct.

The code works differently if you want to do superconductivity or compute the self-energy.

The g on the fine grid are not stored to file as this would be a very big file (it's a 5 dim (band,band,mode, k,q) object and potentially 6 (freq) if you do spectral function).
Instead what is stored on file is the partial self energy (only a 2 (band,k or q ) or 3 (freq) dim. object. When you restart the matrix elements
are indeed computed on the fly from the coarse grid stored quantities (.epmatw file).

The printing of g should not be done for production run as the output file will be huge. For this reasons I did not implement a restart
feature for this since in the case of a small calculation doing everything in one run is not a problem.

Best,
Samuel

[AgentZero]

Dear Andrei and Samuel,

Thank you very much for your nice explanations. But I still have some confusions. Yes, now I understand that epf17 is stored in memory and not written to disk,
and then |g| can not be directly calculated in a restart calculation. But as mentioned by Samuel in another post, we can use different (larger) fine k/q-meshes in a restart
calculation (by setting kgmap=.true., epbwrite=.false., epbread=.false., epwwrite=.false, and epwread=.true.), after the epwmatwp1 file is written to disk.
Thus the epf17 should be recalculated on the larger fine k/q-mesh in the restart calculation. According to this, we should obtain the |g| on the larger fine k/q-mesh.
Since epf17 on the larger fine k/q-mesh is already recomputed, although it is stored in memory.

Best wishes,
Miao Gao

[sponce]

Hello,

The confusions comes from the fact that we are talking about two different restart capabilities of EPW

1) Restart after the epwmatwp1 have been written to file (by setting kgmap=.true., epbwrite=.false., epbread=.false., epwwrite=.false, and epwread=.true.)
In that case you can use whatever fine grid you want and if you change the grid the prtgkk should always be fine.
If this is what you were doing, it is weird that the g were bad.

2) Restart within a fine q-grid calculation: This uses the input variable "restart" http://epw.org.uk/Documentation/Inputs#restart
In that case you cannot use prtgkk if you restart from there.

Best,
Samuel

[AgentZero]

Dear Samuel,

Thank you for clarifying the two different concepts of restart. My situation is weirder that three calculations for MgB2 with the same input give
different |g|. These three runs generate three epwmatwp1 files. If I restart the three calculations (by setting epwread = .true. and so on)
with respective epwmatwp1 files, meanwhile I do not change any other parameters. These three restart calculations print almost the same |g|.

Moreover, the lambda and Tc for the first three runs are the same. It is hard to understand that different |g| produce the same lambda and Tc.

Best wishes,
Miao Gao

[AgentZero]

Dear Samuel,

I further test the subroutine print_gkk and have the following findings.

1. If the calculations are performed across different computing nodes, the |g| are different each time even using the same number of processors.
2. If the calculations are performoed on a single computing node, the |g| are the same for different runs (with the same number of processors).
3. The |g| calculated by one processor are different with above two situations.

Does this phenomenon mean that there are possilbe bugs for the parallel computation in print_gkk? Hope to receive your reply! Thanks in advance!

Best wishes,
Miao Gao

[sponce]

Dear Miao Gao,

I just re-tested it with 4 cores and 1 cores (restart from epmatwp1) and got the same results for silicon.

Are you using the latest version of the prt_gkk.f90 subroutines.

I committed a small bugfix 14 july.
You can download the latest version at https://github.com/QEF/q-e

Hope this fixes it.

Best,
Samuel