[Pw_forum] What happens at REALLY large ectuwfc?

[Brad Malone]

I happened to stumble upon something today that I thought was unusual.  The
problem is illustrated in a simple example: if you take the following basic
cubic Si input file and, say, the Si.pz-vbc.UPF pseudopotential from the QE
website and do a test for convergence with respect to ectutwfc.

If we look at the 4 bands that are calculated we see the following results:

At ecutwfc=40 Ry:   -5.1740   7.0370   7.0370   7.0370
    ecutwfc=100Ry:   -5.1746   7.0369   7.0369   7.0369
    ecutwfc=200Ry:    -5.1746   7.0369   7.0369   7.0369
Now try
   ecutwfc=2000Ry:       -5.2862   6.9066   6.9066  10.2399

Now why do the values change? If I look at the output file for the 2000 Ry
case I see that there is a negative starting charge:

Initial potential from superposition of free atoms
     Check: negative starting charge=   -0.057614

But still, why is this? The usual answer for a negative starting charge is
to increase the wavefunction cutoff, although I suspect that's not the
problem in this case.....

So besides the using of a 2000 Ry cutoff for silicon, what else is wrong
here?

Best,
Brad
UC Berkeley


&control
   prefix = 'si'
   calculation = 'scf'
   restart_mode = 'from_scratch'
   wf_collect = .false.
   tstress = .true.
   tprnfor = .true.
   outdir = './'
   wfcdir = './'
   pseudo_dir = './'
/
&system
   ibrav = 0
   celldm(1) = 10.2612
   nat = 2
   ntyp = 1
   nbnd = 4
   ecutwfc = 2000.0
/
&electrons
   electron_maxstep = 100
   conv_thr = 1.0d-10
   mixing_beta = 0.7
   diago_full_acc = .true.
/
CELL_PARAMETERS cubic
      0.000000000  0.500000000  0.500000000
      0.500000000  0.000000000  0.500000000
      0.500000000  0.500000000  0.000000000
ATOMIC_SPECIES
  Si  28.086  Si.pz-vbc.UPF
ATOMIC_POSITIONS crystal
  Si  -0.125000000  -0.125000000  -0.125000000
  Si  0.125000000  0.125000000  0.125000000
K_POINTS automatic
1 1 1 0 0 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20100122/728285a7/attachment.html>