[Pw_forum] PHonon versions 5.0.2/5.0.3 can give very different frequencies as compared to older versions and the latest SVN builds

2013-05-06 Thread Brad Malone
In the event that someone stumbles across this thread in the future and
looks for an answer by subject line, I just wanted to note here that this
issue has been resolved by the new 5.0.3 patch that Paolo released this
morning.

Best,
Brad Malone
Harvard University
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130506/95a8f654/attachment.html
 


[Pw_forum] PHonon versions 5.0.2/5.0.3 can give very different frequencies as compared to older versions and the latest SVN builds

2013-05-03 Thread Brad Malone
Hi everyone,

I recently came across some phonon softening in a system calculated with
the 5.0.2 version of QE. This came as a surprise because, in addition to
having some physical reasons for not believing it, it was in contrast to
previous calculations I had done some time back on the same system (and
input files) with QE 4.3.2. The deviations with respect to QE version over
a 3x3x3 grid of q vectors in this system amounted to a maximal error of
13.5 cm^-1 for a particular q vector.

This previously mentioned system was fairly large, so I tried to find
simpler systems to run so that I could narrow down where the problem was
coming from. I found that many simple systems (like cubic diamond)
exhibited essentially zero error regardless of version. However, in
guessing that the problem could possibly be related to systems with
hexagonal symmetry, I chose to test the hexagonal diamond phase of Ge (4
atoms/cell) and found that over a 3x3x3 grid of q vectors, I got deviations
on the order of 95 cm^-1 for some q vectors. I actually do not think the
problem is limited to hexagonal symmetry systems however, as I've seen some
deviations in other orthorhombic systems (although they have been more
minor).

Using the hexagonal diamond system, I tested a wide variety of QE releases
and SVN versions. The problem occurs for the more recent releases of 5.0.2
and 5.0.3 (i.e., the patch doesn't fix the problem). The latest SVN version
is consistent with 5.0.1 and 5.0.0 as well as older versions tested (4.3.2
and 4.2.1). I'm not sure the exact SVN version where the problem first
occurred, but rev 9724 is the first commit which gives the "correct" phonon
frequencies.

Rev 9724 differs from 9723 as follows:

login1$ svn -r 9723:9724 diff
> Index: PHonon/PH/sgam_ph.f90
> ===
> --- PHonon/PH/sgam_ph.f90 (revision 9723)
> +++ PHonon/PH/sgam_ph.f90 (revision 9724)
> @@ -161,7 +161,8 @@
> sym(irot) = sym(irot) .and. (abs(raq(ipol)-aq(ipol)) < 1.0d-5)
>  enddo
>   endif
> - if (.not.minus_q) then
> +! if (.not.minus_q) then
> + if (sym(irot).and..not.minus_q) then
>  raq = - raq
>  minus_q = eqvect (raq, aq, zero, accep)
>   endif


Anyway, hope these tests are useful. Unless I've made a mistake somewhere,
I think it suggests that it's extremely dangerous to do phonon calculations
with 5.0.2 or 5.0.3 and you should either stick to 5.0.1 or svn revision
9724 or later.

Best,
Brad Malone
Harvard University
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130503/c9347638/attachment.html
 


[Pw_forum] Pw_forum Digest, Vol 48, Issue 68

2011-06-27 Thread Brad Malone
Dear Stefano,

I appreciate your additional remarks and Claudia's thesis. They are both
very helpful. I'll continue to look into this possible Kohn anomaly and its
relationship with the lattice instability as the pressure is lowered.

Thanks again,
Brad
UC Berkeley



>
> Dear Brad & Nicola,
>
> I was going to reply to Brad, when I noticed that Nicola already did so,
> and quite appropriately. Let me just elaborate a little bit on Nicola's
> remarks.
>
> The reason why Kohn anomalies require so many k-points to be properly
> captured on a computer is the same why they are so sensitive to temperature
> in nature. They are due to different portions of the Fermi surface to be
> quasi-parallel (i.e. connected by a same q vector, the "nesting" vector). By
> the way, this is why Kohn anomalies are more important on low dimensions:
> the lower the dimension, the easier it is to have nesting. When this occurs,
> perturbations with the periodicity of the nesting vector will be strongly
> screened, hence phonons with that periodicity will be soft or "quasi soft".
> When the temperature increases, the Fermi surfaces becomes "blurred", and
> the very concept of nesting breaks down. Computationally, in a metal the
> energy smearing (Gaussian or other) plays the role of an effective
> temperature. The smaller the smearing, the larger the number of k-points
> necessary to sample the Brillouin zone to an energy resolution compatible
> with the smearing.
>
> An early paper studying a system where these effects show dramatically is:
>
> Claudia Bungaro et al. PRL 77, 2491 (1996)
> http://link.aps.org/doi/10.1103/PhysRevLett.77.2491
> You may also find Claudia's PhD thesis worth some attention:
> http://www.sissa.it/cm/thesis/1995/bungaro.ps.gz
>
> Hope this may help.
>
> Stefano
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20110627/42a47d76/attachment.htm
 


[Pw_forum] Convergence of imaginary modes

2011-06-27 Thread Brad Malone
Dear Nicola,

Thanks so much for your suggestion; I was not aware of this characteristic
of Kohn anomalies. I will look into some of those papers (a quick glance at
them already suggests that they may be useful). My smearing is pretty
"standard" for metallic systems at 0.03 Ry, and so I will look into the
possible presence of a Kohn anomaly in the system.

Best,
Brad
UC Berkeley


> Dear Brad,
>
>
> if you have a Kohn anomaly it's not unusual to require that high
> of a k-point sampling - comparable numbers are needed to converge
> some of the optical modes in graphene/graphite (do check some of
> the early papers of Mauri/Lazzeri).
>
> I haven't heard of other cases where such high-sampling is needed
> for phonons, unless your system was a metal, and you were not using
> a smearing scheme (or way too small a smearing).
>
>nicola
>
>
> --
> --
> Prof Nicola MarzariDepartment of MaterialsUniversity of Oxford
> Chair of Materials Modelling  Director, Materials Modelling Laboratory
> nicola.marzari at materials.ox.ac.uk http://mml.materials.ox.ac.uk/NM
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20110626/d270c2a0/attachment.htm
 


[Pw_forum] Convergence of imaginary modes

2011-06-26 Thread Brad Malone
Hello QE users,

I am calculating the lattice dynamical properties of a high-pressure phase.
As has been documented in this forum, phonon frequencies can be quite
sensitive to the various other parameter of the calculation (wavefunction
cutoff, BZ sampling, etc.) and it's important to test this explicitly and
not rely on the parameters one finds converged for say, a total-energy SCF
calculation.

In the testing of my phonon frequencies with respect to the density of the
k-point sampling in the SCF calculation prior to the phonon calculation, I
decided to test a uniform grid of q-points rather than simply the Gamma
phonon since I don't know of any a priori reason to expect that all phonon
frequencies converge identically (although in my prior experience this is
approximately true). I found that almost all frequencies are converged to
within about 1% or so at a "small" kgrid sampling of about 40x40x40.
However, one mode is wildly unconverged at this point, and differences on
the order of 100s of cm^1 can be found by going to a kgrid sampling of
80x80x80. So I just kept increasing the kpoint sampling until I converged
this mode. The mode didn't fully converge until 200x200x200, although it is
pretty close at 160x160x160.The mode finally converged to a negative value
(although was positive until the kpoint sampling was in the triple digits in
each direction).

This negative mode signals an instability of the structure along the path
corresponding to the phonon displacement pattern. That's all well and good.
I know that this structure is thermodynamically unstable at pressures in the
ballpark of the calculation, and so if it's dynamically unstable too no
problem. Since the structure becomes more thermodynamically stable at higher
presures, I increased the pressure and tested the phonon frequencies again.
I found that the negative mode goes positive, and increases in frequency as
the pressure is increased (as one might guess). However, this mode still
depends very sensitively on the kpoint sampling and doesn't get close to
full convergence until about 160x160x160 similarly to the calculation at
lower pressures.

In previous lattice dynamical calculations, I've always been blessed with
positive frequencies (at least those that can't be ASRed away) and I'm
curious as to whether the more sensitive convergence of imaginary modes (and
those that are close to being unstable) is a property that others have found
in their calculations or whether it is something unusual with the system
that I am studying.

Thanks,
Brad Malone
UC Berkeley
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20110626/514877af/attachment.htm
 


[Pw_forum] Details on "third order derivatives not implemented with GGA" error

2010-11-10 Thread Brad Malone
Lorenzo and Paolo,

Thanks for the replies, I appreciate it. I'll contact Tobias to inquire
about the status.

Best,
Brad
UC Berkeley

On Tue, Nov 9, 2010 at 9:01 PM, Brad Malone  wrote:

>
>>
>> FYI.
>> There is NO truncation on the mailing list, we got all what you sent.
>> You gmail did it. Click Show Quote Text for full email.
>>
>>
> That doesn't seem to be completely true. Check out the posts here
> http://www.democritos.it/pipermail/pw_forum/2010-November/date.html . What
> is seen on the digest is different than what is stored online at the site
> above for some reason.
>
>
>
> Best,
> Brad
> UC Berkeley
>
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20101110/014a4112/attachment.htm
 


[Pw_forum] Details on "third order derivatives not implemented with GGA" error

2010-11-09 Thread Brad Malone
No idea why it is being truncated, so this time I'll start the email after
the error message
---


[Pw_forum] Details on "third order derivatives not implemented with GGA" error

2010-11-09 Thread Brad Malone
It appears that my last email was severely truncated on the mailing list
(even though it looks fine in my outbox). Below is what is should have been:
---
Hi, I am seeking more information on the error

> from phq_setup : error # 1
> third order derivatives not implemented with GGA



[Pw_forum] Details on "third order derivatives not implemented with GGA" error

2010-11-09 Thread Brad Malone
Hi, I am seeking more information on the error

> from phq_setup : error # 1
> third order derivatives not implemented with GGA



[Pw_forum] about the program style of pwscf

2010-08-11 Thread Brad Malone
The book 'FORTRAN 90/95 for Scientists and Engineers' goes through basic
FORTRAN 90 syntax, and is pretty good. There's a new book out for FORTRAN
95/2003, but the differences should be minor.

Best,
Brad Malone
UC Berkeley

On Wed, Aug 11, 2010 at 3:19 AM,  wrote:

>
> first thank you for you reply in details, yes ,just like you said, the
> pwscf
> is written mostly in standard Fortran90, and what I want to is just to
> learn
> this standard style of program.
> 2010/8/11 Gabriele Sclauzero 
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20100811/26645d79/attachment.htm
 


[Pw_forum] What happens at REALLY large ectuwfc?

2010-01-25 Thread Brad Malone
>start with 'random' or 'atomic+random' initial wavefunctions
>(startingwfc='...'). I didn't find anything wrong with very
>high cutoffs. Occasionally you can end up in the wrong ground
>state, though, especially in highly symmetric cases like the
>Si example you sent.

Hi Paolo. I tried startingwfc='random' and the eigenvalues are now
essentially the same as the 200 Ry calculation.


  k = 0. 0. 0. (** PWs)   bands (ev):

-5.1746   7.0369   7.0369   7.0369

!total energy  =   -14.59208472 Ry
 Harris-Foulkes estimate   =   -14.59208472 Ry
 estimated scf accuracy<3.8E-11 Ry

 The total energy is the sum of the following terms:

 one-electron contribution = 5.58227211 Ry
 hartree contribution  = 1.67255887 Ry
 xc contribution   =-5.04795092 Ry
 ewald contribution=   -16.79896478 Ry
 Fock energy 1 = 0. Ry
 Fock energy 2 = 0. Ry
 Half Fock energy 2= 0. Ry


Thanks,
Brad


On Sun, Jan 24, 2010 at 2:38 PM, Brad Malone  wrote:

> >are you using the latest cvs version? apparently there is a problem
> >with the new symmetrization algorithm that will be fixed ASAP.
>
> The results I posted are from espresso-4.0.5, although I originally saw
> this problem with espresso-4.1.1 in a different system (AlAs on a 2x2x2
> shifted grid).
>
> As for what Lorenzo said, it makes sense with what I'm seeing. The energy
> breakdowns for the 200 Ry and the 2000 Ry cases are shown below:
>
> For 200 Ry:
> 
> !total energy  =   -14.59208467 Ry
>  Harris-Foulkes estimate   =   -14.59208467 Ry
>  estimated scf accuracy<3.9E-11 Ry
>
>  The total energy is the sum of the following terms:
>
>  one-electron contribution = 5.58227319 Ry
>  hartree contribution  = 1.67255719 Ry
>  xc contribution   =-5.04795028 Ry
>  ewald contribution=   -16.79896478 Ry
>  Fock energy 1 = 0. Ry
>  Fock energy 2 = 0. Ry
>  Half Fock energy 2= 0. Ry
> -
> For 2000 Ry:
> -
> !total energy  =   -14.11008918 Ry
>  Harris-Foulkes estimate   =   -14.11008918 Ry
>  estimated scf accuracy<1.0E-11 Ry
>
>  The total energy is the sum of the following terms:
>
>  one-electron contribution = 6.07256114 Ry
>  hartree contribution  = 1.58024935 Ry
>  xc contribution   =-4.96393489 Ry
>  ewald contribution=   -16.79896478 Ry
>  Fock energy 1 = 0. Ry
>  Fock energy 2 = 0. Ry
>  Half Fock energy 2= 0. Ry
> ---
>
> So you can see the one-electron contribution going up and the hartree
> contribution going down as Lorenzo as argued.
>
> Brad
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20100125/4075c9ae/attachment.htm
 


[Pw_forum] What happens at REALLY large ectuwfc?

2010-01-24 Thread Brad Malone
>are you using the latest cvs version? apparently there is a problem
>with the new symmetrization algorithm that will be fixed ASAP.

The results I posted are from espresso-4.0.5, although I originally saw this
problem with espresso-4.1.1 in a different system (AlAs on a 2x2x2 shifted
grid).

As for what Lorenzo said, it makes sense with what I'm seeing. The energy
breakdowns for the 200 Ry and the 2000 Ry cases are shown below:

For 200 Ry:

!total energy  =   -14.59208467 Ry
 Harris-Foulkes estimate   =   -14.59208467 Ry
 estimated scf accuracy<3.9E-11 Ry

 The total energy is the sum of the following terms:

 one-electron contribution = 5.58227319 Ry
 hartree contribution  = 1.67255719 Ry
 xc contribution   =-5.04795028 Ry
 ewald contribution=   -16.79896478 Ry
 Fock energy 1 = 0. Ry
 Fock energy 2 = 0. Ry
 Half Fock energy 2= 0. Ry
-
For 2000 Ry:
-
!total energy  =   -14.11008918 Ry
 Harris-Foulkes estimate   =   -14.11008918 Ry
 estimated scf accuracy<1.0E-11 Ry

 The total energy is the sum of the following terms:

 one-electron contribution = 6.07256114 Ry
 hartree contribution  = 1.58024935 Ry
 xc contribution   =-4.96393489 Ry
 ewald contribution=   -16.79896478 Ry
 Fock energy 1 = 0. Ry
 Fock energy 2 = 0. Ry
 Half Fock energy 2= 0. Ry
---

So you can see the one-electron contribution going up and the hartree
contribution going down as Lorenzo as argued.

Brad
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20100124/059131a8/attachment.htm
 


[Pw_forum] What happens at REALLY large ectuwfc?

2010-01-22 Thread 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



   prefix = 'si'
   calculation = 'scf'
   restart_mode = 'from_scratch'
   wf_collect = .false.
   tstress = .true.
   tprnfor = .true.
   outdir = './'
   wfcdir = './'
   pseudo_dir = './'
/

   ibrav = 0
   celldm(1) = 10.2612
   nat = 2
   ntyp = 1
   nbnd = 4
   ecutwfc = 2000.0
/

   electron_maxstep = 100
   conv_thr = 1.0d-10
   mixing_beta = 0.7
   diago_full_acc = .true.
/
CELL_PARAMETERS cubic
  0.0  0.5  0.5
  0.5  0.0  0.5
  0.5  0.5  0.0
ATOMIC_SPECIES
  Si  28.086  Si.pz-vbc.UPF
ATOMIC_POSITIONS crystal
  Si  -0.12500  -0.12500  -0.12500
  Si  0.12500  0.12500  0.12500
K_POINTS automatic
1 1 1 0 0 0
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20100122/728285a7/attachment.htm
 


[Pw_forum] [Fwd: diagonalization failure (david, cg) for large numbers of bands]

2009-12-01 Thread Brad Malone
Joseph,

I've never tried computing quite that many bands (only gone up to about 1200
bands) or with that many atoms per cell. However, I've never not been able
to get the bands to converge using both 'cg' diagonalization and also with
increasing the cutoff. You mentioned that you have tried increasing the
cutoff, but perhaps you haven't gone high enough?

Here is a quote from Paolo that might be relevant in your situation:


the algorithm used in PWscf is based on the assumption that
> the number of Kohn-Sham states (aka bands) is much smaller
> than the number of basis functions (i.e. plane waves). If this
> assumption doesn't hold (and it doesn't if you calculate 500
> bands in fcc Si unless you use a very large cutoff) you may
> run into trouble. Moreover iterative diagonalization becomes
> slower and more memory-consuming than conventional
> diagonalization. If you really need to do that, you need to
> modify the code
>
>
Best,
Brad Malone
UC Berkeley
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20091201/4a3b1540/attachment.htm
 


[Pw_forum] Calculation of Raman tensor/intensity for material with indirect band overlap

2009-11-30 Thread Brad Malone
As a follow up on my previous post, I let the calculation run to completion
on a less dense k-grid and saw the following output:

   ik   2 ibnd  17 linter: root not converged  0.748E+35
>  kpoint   2 ibnd  17 pcgreen: root not converged 0.421E+23
>  Non-scf  u_k: avg # of iterations =137.0
>  Non-scf Du_k: avg # of iterations =200.0
>
>   Dielectric constant from finite-differences
>
>   (   NaN   NaN   NaN )
>   (   NaN   NaN   NaN )
>   (   NaN   NaN   NaN )
>
>  Computing Second order response
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>
>
>   iter #   1   av.it.: 147.2
>   thresh= 0.100E-01 alpha_mix =  0.100 |ddv_scf|^2 =  NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>  kpoint   2 ibnd  17 pcgreen: root not converged NaN
>
>
>   iter #   2   av.it.: 200.0
>   thresh= 0.100E-01 alpha_mix =  0.100 |ddv_scf|^2 =  NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>  kpoint   1 ibnd  17 pcgreen: root not converged NaN
>
>
> and so on. The code crashes at the end with the error:

%%
>  from broyden : error # 1
>  factorization
>  %
>
>
but obviously the problem occurs well before this crash. Again, I am trying
to calculate the Raman intensity for a material with a small indirect
overlap. Should this not be possible? I know that DFPT is applicable
(without modification) only for systems with a clear distinction between
occupied and valence states (in order to clearly specify what the projectors
over the occupied and unoccupied manifolds I guess?). For the indirect
overlap case with fixed occupancies I would imagine that this would be
possible.

Anyway, just wanted to report on the results of my first post. If anyone
knows what I can do to calculate the intensity or simply if it should or
shouldn't work (and/or "why") I would greatly appreciate it.

Best,
Brad Malone
UC Berkeley


On Sun, Nov 22, 2009 at 11:36 AM, Brad Malone  wrote:

> Hi, I'm interested in calculating the Raman intensity for a material with a
> small indirect band overlap within LDA (~0.3 eV). As has been mentioned many
> times on this forum, Raman intensities cannot be calculated for a pure
> metal. But should I expect to be able to calculate the intensity for a
> material with a small, indirect band overlap? When I attempted to do so
> (using lraman=.true. in the ph.x calculation) I received the following
> messages:
>
>Computing Pc [DH,Drho] |psi>
>>
>>  Derivative coefficient:  0.001000Threshold: 1.00E-12
>>  ik   1 ibnd  17 linter: root not converged  0.578E+08
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.763E+05
>>  ik   1 ibnd  17 linter: root not converged  0.193E+11
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.119E+05
>>  ik   1 ibnd  17 linter: root not converged  0.595E+09
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.182E+05
>>  ik   1 ibnd  17 linter: root not converged  0.142E+31
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.224E+24
>>  ik   1 ibnd  17 linter: root not converged  0.143E+30
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.170E+25
>>  ik   1 ibnd  17 linter: root not converged  0.765E+28
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.151E+25
>>  ik   1 ibnd  17 linter: root not converged  0.643E+09
>>  kpoint   1 ibnd  17 pcgreen: root not converged 0.460E+05
>> 

[Pw_forum] problems calculating large numbers of empty states

2009-10-22 Thread Brad Malone
Hi, I'm trying to calculate a large number of conduction band states for
cubic Si (to be used in a subsequent GW calculation). However, when doing
this I sometimes run into errors like "problems computing cholesky
decomposition"  or "too many bands are unconverged". An example file of the
nscf calculation that generates an error for me is below:

The problems can sometimes be avoided by going to a larger wavefunction
cutoff, but I'm not sure if this is for good reason or if changing the
wavefunction cutoff just happens to avoid the error in the cases I've
tried.  Also, for a chosen grid (not the one listed below) I get errors when
trying to calculate 400,500, and 700 total bands, but the calculation works
fine for 600 bands.

Any insight to why this might happen or suggestions as to how to avoid it?

Thanks,
Brad Malone
UC Berkeley

-

   prefix = 'si'
   calculation = 'nscf'
   restart_mode = 'from_scratch'
   wf_collect = .true.
   tstress = .false.
   tprnfor = .false.
   outdir = './'
   wfcdir = './'
   pseudo_dir = './'
/

   ibrav = 0
   celldm(1) = 10.2612
   nat = 2
   ntyp = 1
   nbnd = 300
   ecutwfc = 40.0
/

   conv_thr = 1.0d-10
   diagonalization = 'cg'
   diago_full_acc = .true.
/
CELL_PARAMETERS cubic
  +0.0  +0.5  +0.5
  +0.5  +0.0  +0.5
  +0.5  +0.5  +0.0
ATOMIC_SPECIES
  Si  28.086  Si.UPF
ATOMIC_POSITIONS crystal
  Si  -0.12500  -0.12500  -0.12500
  Si  +0.12500  +0.12500  +0.12500
K_POINTS crystal
   8
  0.0  0.0  0.0  1.0
  0.0  0.0  0.25000  8.0
  0.0  0.0  0.5  4.0
  0.0  0.25000  0.25000  6.0
  0.0  0.25000  0.5 24.0
  0.0  0.25000  0.75000 12.0
  0.0  0.5  0.5  3.0
  0.25000  0.5  0.75000  6.0

-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20091022/92715f32/attachment.htm
 


[Pw_forum] Tips for vc-relax when far from equilibrium

2009-10-06 Thread Brad Malone
Hi, I am trying to relax (via vc-relax) structures that are, at least most
likely, very far from equilibrium. I was wondering if there were any tips on
how to make this more robust, as I'm currently experiencing frequent crashes
for these systems.

The main problem I'm having is shown below:

 After a *couple successful relaxation steps*, I'll find the following

 extrapolated charge6.83616, renormalised to8.0
>
>  total cpu time spent up to now is614.83 secs
>
>  per-process dynamical memory:28.6 Mb
>
>  Self-consistent Calculation
>
>  iteration #  1 ecut=20.00 Ry beta=0.10
>  CG style diagonalization
>  WARNING pzsteqr, convergence not achieved INFO =3
>  c_bands:  4 eigenvalues not converged
>  WARNING pzsteqr, convergence not achieved INFO =3
>  c_bands:  4 eigenvalues not converged
>  WARNING pzsteqr, convergence not achieved INFO =3
>  c_bands:  4 eigenvalues not converged
>  c_bands:  1 eigenvalues not converged
>
 4 processes killed (possibly by Open MPI)
>


So the first thing is that my extrapolated charge is very far off from the
value of 8 expected (I have two Si atoms in the unit cell). Secondly, the
self-consistent calculation fails and kills the job. I've tried using
davidson diagonalization as well and it also crashes.

Any suggestions on how I might avoid this? Thanks for your time.

Best,
Brad
UC Berkeley
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20091006/064b83d4/attachment.htm