obtaining mu_s and mu_c in PHYSICAL REVIEW B 101, 134511 (2020) with sctk

alpinnovianus commented 8 months ago

Hi!

I am trying to reproduce some of the results published in PHYSICAL REVIEW B 101, 134511 (2020) with SCTK, using the k/q-points mesh, number of bands, and cutoff energies mentioned in the paper.

In Figure 2 of this paper, there are a few quantities listed, such as Tc, lambda, mu_s and mu_c.

I want to ask where to read the mu_s and mu_c values from SCTK output?

I understand that the output of calculation "lambda_mu_k" using sctk.x has a mu value at the end, for example:

Integrate gapeq

       mu :     0.18197E+00
   lambda :     0.95555E+00

but how to extract the individual mu_s and mu_c values?

mitsuaki1987 commented 8 months ago

Dear alpin

Sorry for my delay. As you wrote, $\mu\textrm{C}$ and $\mu\textrm{s}$ are computed with calculation "lambda_mu_k". https://mitsuaki1987.github.io/sctk/en/_build/html/program.html#namelist-scdft If we specify spin_fluc = .false., mu in the above output means $\mu\textrm{C}$, while it becomes $\mu\textrm{C}+\mu_\textrm{s}$ by specifying spin_fluc = .true..

alpinnovianus commented 8 months ago

Dear @mitsuaki1987 ,

If we specify spin_fluc = .false., mu in the above output means mu_c, while it becomes mu_c + mu_s by specifying spin_fluc = .true..

My calculation results for Pb mostly agree with the Tc and mu_s values in your paper, However, the mu_c value differs by approximately the value of mu_s if I follow your definition above. Because this is strange, I want to ask. Is it possible that there could be a mistake in the paper's published value for mu_c ?

For example, my lambda_mu_k output for calculations without SF, without SOI:

#####  Average matrix in grid  #####

   nindmax : 12
     Total RAM for Vc per process :   0.84E+00 GB
     Total RAM for gg per process :   0.60E-01 GB
     Total RAM for Vc (temporary) per process :   0.19E-02 GB
     Total RAM for gg (temporary) per process :   0.14E-03 GB
   DOS(E_F)[/Ry/cell/spin] :  0.35801E+01
   Number of total points for gap equation : 432

 #####  Integrate gapeq  #####

       mu :     0.18197E+00      ------> this should be mu_c in your definition quoted above

while this is the output for calculations "with SF, without SOI":

 #####  Average matrix in grid  #####

   nindmax : 12
     Total RAM for Vc per process :   0.17E+01 GB
     Total RAM for gg per process :   0.12E+00 GB
     Total RAM for Vc (temporary) per process :   0.39E-02 GB
     Total RAM for gg (temporary) per process :   0.28E-03 GB
   DOS(E_F)[/Ry/cell/spin] :  0.35801E+01
   Number of total points for gap equation : 432

 #####  Integrate gapeq  #####

       mu :     0.22741E+00    ------> this should be mu_c + mu_s in your definition quoted above

For completeness, these are my lambda_mu_k output for calculations without SF, with SOI:

 #####  Average matrix in grid  #####

   nindmax : 12
     Total RAM for Vc per process :   0.33E+01 GB
     Total RAM for gg per process :   0.24E+00 GB
     Total RAM for Vc (temporary) per process :   0.77E-02 GB
     Total RAM for gg (temporary) per process :   0.55E-03 GB
   DOS(E_F)[/Ry/cell/spin] :  0.76651E+01
   Number of total points for gap equation : 864

 #####  Integrate gapeq  #####

       mu :     0.19664E+00 ------> this should be mu_c in your definition quoted above

and for calculations with SF, with SOI:

 #####  Average matrix in grid  #####

   nindmax : 12
     Total RAM for Vc per process :   0.67E+01 GB
     Total RAM for gg per process :   0.48E+00 GB
     Total RAM for Vc (temporary) per process :   0.15E-01 GB
     Total RAM for gg (temporary) per process :   0.11E-02 GB
   DOS(E_F)[/Ry/cell/spin] :  0.76651E+01
   Number of total points for gap equation : 864

 #####  Integrate gapeq  #####

       mu :     0.24368E+00 ------> this should be mu_c + mu_s in your definition quoted above

Again, if I use this definition,

If we specify spin_fluc = .false., mu in the above output means mu_c, while it becomes mu_c + mu_s by specifying spin_fluc = .true..

Could you please confirm if the 0.224 and 0.241 values published in Figure 2 of this paper are indeed mu_c and not actually mu_c + mu_s?

If 0.224 and 0.241 are really only mu_c, could you please advise what could be the reason for the difference in value that I get?

My input file for calculation: lambda_mu_k without SF and without SOI are pasted below. It is also the input for calculation = 'kel' and calculation='scdft_tc'.

&CONTROL
calculation = "lambda_mu_k"
/
&KEL
     nci = 5
  laddxc = 0
     lsf = 0
ecutfock = 140.0
     nq1 = 6
     nq2 = 6
     nq3 = 6
/
&SCDFT
             temp = -1.0
             fbee = 1
             lbee = 28
xic = -1.0
              nmf = 10
               nx = 100
               ne = 50
             emin = 1.0e-7
             emax = 0.7
 electron_maxstep = 100
         conv_thr = 1.0e-15
spin_fluc =.false.
/

On a slightly different but related quantity, I would like to also confirm about the value of DOS(EF) reported in Figure 2. I understand that the quantities DOS(EF), omega_ln, and lambda reported in this Figure are obtained from matdyn.x output file 'lambda'. I attempted these calculations and obtained the following for system without SF and without SOI, for example:

Broadening 0.0000 lambda 1.0016 dos(Ef) 3.5801 omega_ln [K] 67.0740

Assuming the dos(EF) is in units of Ry /spin, then the corresponding value in eV/spin is 3.5801/13.6 = 0.263. Meanwhile, the value in Figure 2 is twice this number, which is 0.527.

Thus, am I right that the values in Figure 2 (e.g., 0.527 for Pb) are meant for the total dos(Ef) for both spins? Is this assumption correct?

Thank you for your guidance.

mitsuaki1987 / sctk

obtaining mu_s and mu_c in PHYSICAL REVIEW B 101, 134511 (2020) with sctk #12

Integrate gapeq