[Pw_forum] same Problem with BFGS
your scf convergence threshold (10^-4) looks very lousy to me. In particular it's larger than the required energy convergence in the bfgs relaxation (10^-5) !! Lousy self consitency affects the quality of the computed forces ... indeed the "scf correction" is larger that the force itself. stefano Quoting mnunez at ncsu.edu: > > I am getting the same bfgs error posted before: > - > %% > from bfgs : error # 1 > bfgs history already reset at previous step > %% > > stopping ... > > the bfgs algorithm seems to get stucked. > the total forces along the minimization before it stops are: > > Total force = 0.002868 Total SCF correction = 0.034876 > Total force = 0.042610 Total SCF correction = 0.039637 > Total force = 0.008934 Total SCF correction = 0.029486 > Total force = 0.003953 Total SCF correction = 0.016921 > Total force = 0.012592 Total SCF correction = 0.010567 > Total force = 0.004110 Total SCF correction = 0.009995 > Total force = 0.001633 Total SCF correction = 0.012211 > Total force = 0.001412 Total SCF correction = 0.019146 > Total force = 0.001607 Total SCF correction = 0.021538 > Total force = 0.001555 Total SCF correction = 0.012259 > Total force = 0.001361 Total SCF correction = 0.012868 > Total force = 0.001432 Total SCF correction = 0.013882 > Total force = 0.001343 Total SCF correction = 0.011201 > Total force = 0.001422 Total SCF correction = 0.013635 > Total force = 0.001369 Total SCF correction = 0.005947 > Total force = 0.001317 Total SCF correction = 0.011391 > Total force = 0.001485 Total SCF correction = 0.006279 > Total force = 0.001351 Total SCF correction = 0.014118 > Total force = 0.001475 Total SCF correction = 0.011927 > > the input file > &control > calculation = "relax", > title='scf BaOPtAl big slab 1 001' > restart_mode="from_scratch", > prefix="BaOPtAlSlabMeth", > pseudo_dir ="/spin/home/mnunez/pwcheetah/pseudo/", > outdir="/tmp/work/mnunez/BaOPtAlSlabMethod/", > forc_conv_thr = 1.0d-4 > etot_conv_thr = 1.0d-5 > tstress = .true., > tprnfor = .true. > / > &system > ibrav = 6, > celldm(1) =7.297, > celldm(3) = 16.9397, > nat = 42, > ntyp = 4, > nbnd=230, > ecutwfc =35, > ecutrho=245, > occupations ='smearing', > smearing='gaussian', > degauss=0.008 > / &electrons > mixing_mode= 'local-TF' > diagonalization= 'cg' > mixing_beta = 0.3, > mixing_ndim = 11, > conv_thr = 1.0d-4 > / > &ions > upscale=11 > / > ATOMIC_SPECIES > O 15.9994 O.pz-rrkjus.UPF > Ba 137.327 Ba.vdb.UPF > Pt 195.078 Pt.pz-rrkjus.UPF > Al 26.981538 Al.pz-vbc.UPF > ATOMIC_POSITIONS > Pt 0.5 0.5 -5.843889151 > Pt 0.0 0.0 -5.841443397 > Pt 0.5 0.0 -5.341181221 > Pt 0.0 0.5 -5.341181221 > Pt 0.5 0.5 -4.831963549 > Pt 0.0 0.0 -4.829809502 > Pt 0.5 0.0 -4.316032074 > Pt 0.0 0.5 -4.316032074 > Pt 0.5 0.5 -3.800183390 > Pt 0.0 0.0 -3.799129595 > Pt 0.5 0.0 -3.250938002 > Pt 0.0 0.5 -3.250938002 > Al 0.5 0.5 -2.892741738 > Al 0.0 0.0 -2.774954863 > Ba 0.5 0.5 -2.105588663 > O0.0 0.0 -2.318966082 > Ba 0.0 0.0 -1.375247423 > O0.5 0.5 -1.434073949 > Ba 0.5 0.5 -0.681716547 > O0.0 0.0 -0.728523986 > Ba 0.0 0.0 0.025502608 > O0.5 0.5 -0.009862356 > Ba 0.5 0.5 0.726855678 > O0.0 0.0 0.705024595 > Ba 0.0 0.0 1.435097711 > O0.5 0.5 1.393104543 > Ba 0.5 0.5 2.115982686 > O0.0 0.0 2.118086625 > Pt 0.5 0.5 2.836917653 > Pt 0.0 0.0 2.696183926 > Pt 0.5 0.0 3.298956976 > Pt 0.0 0.5 3.298956976 > Pt 0.5 0.5 3.810364151 > Pt 0.0 0.0 3.819965483 > Pt 0.5 0.0 4.332138351 > Pt 0.0 0.5 4.332138351 >
[Pw_forum] projwfc.x
Dear all, Running PROJWFC I often get the message: %% from davcio : error #10 i/o error in davcio %% although the pw.x step worked allright, what is the problem ? Thanks a lot
[Pw_forum] projwfc.x
On Wednesday 12 July 2006 09:00, Alain Allouche wrote: > Running PROJWFC I often get the message: > from davcio : error #10 > i/o error in davcio > although the pw.x step worked allright, what is the problem ? it depends. The above error means that the code could not read some data files, presumably because their format was not what was expected. In order to find out why, one needs to know exactly under which (reproducible) circumstances this happens. P. -- Paolo Giannozzi Phone: +39/050-509876 DEMOCRITOS and SNS Fax: +39/050-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy
[Pw_forum] about phonon calculation
On Tuesday 11 July 2006 10:59, Ezad Shojaee wrote: > i have made a phonon calculation with a small grid (221) [...] > when i want to calculate the IFC's in the real space with q2r.x , > there is no dielectric tensor this is normal, if you do not explicitly require its calculation by ph.x (epsil=.true.) > & i have this error too : >from init : error # 1 > q not allowed there is a mismatch between what the q2r.x code thinks q-points should be, and what you provided. It is sufficient that a coordinate differs by 10^-5 from what it should be to get this error. Please check what you used as q-points Paolo -- Paolo Giannozzi Phone: +39/050-509876 DEMOCRITOS and SNS Fax: +39/050-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy
[Pw_forum] Problems with PH.X in QE-31
On Tuesday 11 July 2006 04:29, Sigifredo Sanchez-Carrera wrote: > I compiled espresso-3.1 using an intel fortran compiler (IFC) on a > machine that has intel xeon processors. I had no problem with pw.x > using MPI for parallel use, but whe I try to use the ph.x program > after a few seconds the following error message appears: > Timeout alarm signaled it looks like a compiler problem or a problem with MPI libraries or the interactions of the two. Your system administrator might be able to understand where the code stops and why. You might try a different compiler version and/or different MPI libraries Paolo -- Paolo Giannozzi Phone: +39/050-509876 DEMOCRITOS and SNS Fax: +39/050-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy
[Pw_forum] Input file for cp.x system of C(111)2x1: diagonalization failed
Hello all. Thank you in advance for your time. I have been trying to get a C or Si (111) 2x1 surface to work in cp for some time. I am using a small cluster, Intel processors (Itanium 32bit I think), IFC 9.0 with MKL. The version of cp.x I am working with is from ESPRESSO 3.1.1, although I have had the same problems with 3.1. I started with a simple 8 atom bulk, which seems to work. Here is the input file for reference: &control title='Carbon bulk' calculation='cp', restart_mode='restart', ndr = 51, ndw = 51, nstep = 2000, iprint = 10, isave = 100, tstress = .true., tprnfor = .true., dt = 5.0d0, etot_conv_thr = 1.d-9, ekin_conv_thr = 1.d-4, prefix='diamond' pseudo_dir = '/home/tteatro/pseudo/', outdir='/home/tteatro/tmp/tmp02/', / &system ibrav=1, celldm(1)=6.8d0, celldm(2)=0.0d0, celldm(3)=0.0d0, nat=8, ntyp=1, nelec=32, nbnd=16, ecutwfc = 30.0d0, nr1b=10, nr2b=10, nr3b=10, xc_type = 'BLYP' / &electrons emass = 400.d0, emass_cutoff = 2.5d0, electron_dynamics = 'verlet', !electron_velocities='zero' / &ions ion_dynamics='verlet', !ion_velocities='zero', ion_temperature='nose', fnosep = 32.d0, tempw = 300.0 / ATOMIC_SPECIES C 12.01 C.blyp-mt.UPF ATOMIC_POSITIONS (alat) C0.0 0.0 0.0 1 1 1 C0.25000 0.25000 0.25000 1 1 1 C0.5 0.5 0.0 1 1 1 C0.75000 0.75000 0.25000 1 1 1 C0.5 0.0 0.5 1 1 1 C0.25000 0.75000 0.75000 1 1 1 C0.0 0.5 0.5 1 1 1 C0.75000 0.25000 0.75000 1 1 1 I then changed only the geometry of the system to a 24 atom surface, and got the following error: from rhoofr: total integrated electronic density in g-space = 96.00 in r-space = 96.00 %% from dspev_drv : error #47 diagonalization failed %% stopping ... p0_12001: p4_error: : 0 Here is a listing of the input file, but you should note that the below file has additional changes beyond those of geom try. This is because I tried changing various things, such as ibrav 8 to ibrav 14, using, a different PP, etc. &control title='C(111)2x1 Surface' calculation='cp', restart_mode='from_scratch', ndr = 51, ndw = 51, nstep = 2000, iprint = 10, isave = 100, tstress = .true., tprnfor = .true., dt = 5.0d0, etot_conv_thr = 1.d-9, ekin_conv_thr = 1.d-4, prefix='diamond' pseudo_dir = '/home/tteatro/pseudo/', outdir='/home/tteatro/tmp/tmp02/', / &system ibrav=8, celldm(1)=8.206000, celldm(2)=0.577334, celldm(3)=3.955935, celldm(4)=0.00, celldm(5)=0.00, celldm(6)=0.00, nat=24, ntyp=1, nelec=96, nbnd=48, ecutwfc = 30.0d0, / &electrons !emass = 400.d0, !emass_cutoff = 2.5d0, electron_dynamics = 'sd', / &ions ion_dynamics='none', / ATOMIC_SPECIES C 12.01 C.pz-vbc.UPF ATOMIC_POSITIONS (bohr) C 7.0186010.000 -10.447049 C 10.905062.368 -9.140353 C 4.4171840.000 -9.152089 C 8.3098872.368 -10.439228 C 5.4204610.000 -6.303335 C 9.7797002.368 -6.256876 C 2.7908150.000 -5.174785 C 6.8879452.368 -5.488460 C 2.7410550.000 -2.368432 C 6.8553682.368 -2.463769 C 0.000.000 -1.457720 C 4.1030802.368 -1.457720 C 0.000.0001.457720 C 4.1030802.3681.457720 C -2.741055 0.0002.368432 C 1.3507922.3682.463769 C -2.790815 0.0005.174785 C 1.3182152.3685.488460 C -5.420461 0.0006.303335 C -1.573540 2.3686.256876 C -4.417184 0.0009.152089 C -0.103727 2.368 10.439228 C -7.018601 0.000 10.447049 C -2.698906 2.3689.140353 I would think that the geometry is bad, except that these coordinates have worked in both fhi98 AND pw.x! Here is an input example for pw.x (which works) &control calculation='md', restart_mode='from_scratch', pseudo_dir = '/home/timtro/espresso-3.1/pseudo/', outdir='/scratch/timtro/tmp/tmp02/', dt=10, nstep=15000, isave=10, disk_io='high' / &system ibrav=8, celldm(1)=8.206000, celldm(2)=0.577334, celldm(3)=3.955935, nat=24, ntyp=1, ecutwfc = 30.0d0 / &electrons emass=700.0d0, electron_dynamics='verlet', conv_thr = 1.0d-8, mixing_beta = 0.5 / &ions ion_dynamics='verlet', / ATOMIC_SPECIES C 12.01 C.pz-vbc.UPF ATOMIC_POSITIONS (bohr) C 7.0186010.000 -10.447049 C10.9050662.368 -9.140353 C 4.4171840.000 -9.152089 C 8.3098872.368 -10
[Pw_forum] Plot |psi|^2 for an arbitary k point
Dear PWSCF users and developers: In running post-processing pp.x, I got an error message "from local_dos : error # 1 k must be zero" when calculating |psi|^2 for a non-zero K point. I've searched the code "local_dos.F90" and find that the non-zero K point does not seem to be allowed. Since there is a "kpoint" keyword in the input list, I just wonder if the non-zero K point wavefunction visualization has not been implemented yet. Thanks Tianshu Li
