[Pw_forum] Problem With Total-Energy Convergence vs. ecutwfc
As Nicola said, what matters are the energy differences. Please, check that the forces and stresses are converged. From a practical point of view that is enough. To be happy, I prefer that the energy also converge. I think the non convergence is the (frequent) fault of the pseudopotential. If you are worrried enough, try to generate a new pseudopotential, and chek that is yet transferible. Cheers Eduardo Menendez -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/2021/49b64371/attachment.htm
[Pw_forum] Problem With Total-Energy Convergence vs. ecutwfc
Dear Vic, as you correctly point out, differences in total energy are very well converged in your calculations. This is all what matters. Absolute total energies are not yet converged, but those are not relevant or useful - if you think about, what you'll need will always be differences in energies between different calculations, and those are the ones you need to converge (as indeed you do). nicola On 11/21/11 9:32 PM, Vic Bermudez wrote: > Hello, > > I seem to be having some serious trouble getting total energies to > converge as I vary > "ecutwfc" and "ecutrho". This is for a slab-model calculation, using PBE and > USPP's, for > an HF molecule reacting with the surface of Si3N4. The total energy results I > get in > representative calculations are: > > ecutwfc = 40 ecutrho = 400 Etot = -1504.8173322951 > ecutwfc = 50 ecutrho = 500 Etot = -1505.03408093 > ecutwfc = 60 ecutrho =720 Etot = -1505.12486679 > > From what I'm reading in various posts in the Users' Forum, in tutorials > available on the > web and in the Users' Guide, these values of "ecutwfc" and "ecutrho" are > greatly in excess > of what should be needed to achieve convergence. > This raises the question of how to define convergence. One Users' Forum > post said that a > convenient criterion is 1 mryd/atom. Since my slab unit cell contains 91 > atoms, the > difference between 40/400 and 50/500 is 2.4 mryd/atom. Is it total energy or > total energy > per atom that I should be looking at ? > What I'm actually interested in is reaction energies (or adsorption > energies). The > reaction energies I get for 40/400 and 60/720 are -0.316 and -0.317 eV > respectively. In > other words, they're identical, because the energy differences between 40/400 > and 60/720 > for the bare slab and for the slab+adsorbate cancel. I'm not sure whether I > should be > relieved by this or if I should be wary of a hidden problem. > As another comment, results for 6x6x1 and 12x12x1 Monkhorst-Pack grids > are virtually > identical (with ecutwfc=40 and ecutrho=400 in both cases). Hence, k-point > spacing doesn't > appear to be an issue. > I'm inserting below a typical input file here: > > calculation='scf', > title='repeat energy calculation like #50400 but bigger ecutwfc and ecutrho', > pseudo_dir='/lustre/cmf/scratch/b/bermudez/QE_PP/', > verbosity='default' > / > > > ibrav=8, > a=5.860, b=7.673, c=53.00, > nat=91, > ntyp=5, > ecutwfc=50.0, > ecutrho=500.0, > occupations='fixed', > nosym_evc=.TRUE. > / > > > electron_maxstep=100, > conv_thr=1.0D-9, > mixing_beta=0.7D0, > mixing_ndim=8, > mixing_mode='plain' > / > > ATOMIC_SPECIES > Si 28.0855 Si_pbe-n-van_UPF > N 14.0067 N_pbe-van_ak_UPF > O 15.9994 O_pbe-van_ak_UPF > F 18.9984032 F_pbe-n-van_UPF > H 1.00794 H_pbe-van_ak_UPF > > ATOMIC_POSITIONS angstrom > F -0.828943122 -3.842610696 10.898762889 > H2.956336746 -3.913628193 11.481740207 > O2.130945237 -3.743406775 10.990758649 > Si -0.740055896 -3.727473495 9.278104350 > Si 2.197736003 -3.719125735 9.357412872 > O0.733635389 -0.092404715 8.709367118 > O -2.198390199 -0.092106250 8.703606145 > N0.727690134 -2.912055280 8.831492617 > N -2.199510369 -2.913961388 8.797211298 > N -0.730334009 2.291265533 8.708545486 > N2.200026883 2.26238 8.715832903 > Si 0.740325891 1.486240963 8.197839727 > Si -2.201425602 1.487223849 8.194133645 > Si 0.731520021 -1.484390893 7.805743483 > Si -2.199544503 -1.481807201 7.794749488 > N -0.730477119 -1.509950402 6.851115290 > N2.192766376 -1.509070971 6.850785646 > N0.734572342 1.428876787 6.443023829 > N -2.196689576 1.428710465 6.440830516 > Si -0.730671582 1.383061493 5.485559504 > Si 2.198231920 1.383467537 5.484097670 > Si -0.731571258 -1.634722031 5.102794951 > Si 2.196186337 -1.634652146 5.102809652 > N0.732378551 -2.470977191 4.637802788 > N -2.197580366 -2.470463034 4.640966741 > N -0.731691807 2.788232427 4.443687098 > N2.197979174 2.788401786 4.442656379 > N -0.731484010 -0.019627141 4.441442429 > N2.198010976 -0.019733235 4.440785365 > Si 0.732965820 3.599969198 3.935485972 > Si -2.196881366 3.600616053 3.936927345 > Si -0.732092418 0.194969145 2.706451385 > Si 2.197948022 0.194942344 2.705997893 > N0.732838523 3.815828133 2.206216987 > N -2.196890255 3.816167783 2.207269314 > N0.732842940 1.010463084 2.200606165 > N -2.197021884 1.010498140 2.200720312 > N -0.732301333 -1.402362859 1.988160033 > N2.197752904 -1.402429612 1.987932157 > Si 0.732683992 -2.247692417 1.532621948 > Si -2.197244178 -2.247708827
[Pw_forum] (no subject)
http://www.test.horehron.sk/modules/mod_wdbanners/work.php?html143 -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/2021/6694aa92/attachment.htm
[Pw_forum] unallocated variable
Dear developers, I compiled with Intel and debugging flags, and encountered a runtime error due to use of an unallocated variable. The value will not ultimately be used, but it seems like it could cause segmentation faults or memory corruption, and at any rate makes it harder to use these flags to find other bugs. I ran example09, on 4 nodes, ch4.nm.in intel/11.1.072, mkl/11.1.072, fftw/3.2.2-intel,openmpi/1.4.2-intel FFLAGS = -g -O0 -check all -traceback In the output, I get: Representation # 3 mode # 3 ... End of self-consistent calculation Convergence has been achieved Number of q in the star =1 List of q in the star: 1 0.0 0.0 0.0 forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable RAMTNS when it is not allocated Image PCRoutineLineSource ph.x 01A7F16D Unknown Unknown Unknown ph.x 01A7DC75 Unknown Unknown Unknown ph.x 01A201A0 Unknown Unknown Unknown ph.x 019B853F Unknown Unknown Unknown ph.x 019B8942 Unknown Unknown Unknown ph.x 0046EFAC dynmatrix_150 dynmatrix.f90 ph.x 00443CAA MAIN__118 phonon.f90 ph.x 00443A9C Unknown Unknown Unknown libc.so.6 2B76493A8994 Unknown Unknown Unknown ph.x 004439A9 Unknown Unknown Unknown The offending lines in PH/dynmatrix.f90 are: IF (lgamma.AND.done_epsil.AND.done_zeu) THEN CALL write_dyn_mat_header( fildyn, ntyp, nat, ibrav, nspin_mag, & celldm, at, bg, omega, symm_type, atm, pmass, tau, ityp, m_loc, & nqq, epsilon, zstareu, lraman, ramtns*omega/fpi*convfact) I added if(.not. allocated(ramtns)) allocate ( ramtns (3, 3, 3, nat) ) before the call, which allowed the calculation to complete, but what really ought to be done is to avoid passing this thing at all when lraman == .false. since ramtns is an optional parameter to write_dyn_mat_header. David Strubbe UC Berkeley -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/2021/cb486a03/attachment.htm
[Pw_forum] PlotPhon Examples
*.fc is generated from dynamics matrics by q2r.x. The script in examples just organizes several programs, matdyn.x, k_for_bands.x, bands_to_gnuplot.x and E_min_max.x, working one by one with certain data exchanging. Through pw.x and ph.x, you can just obtain dynamics matrics. -- GAO Zhe CMC Lab, MSE, SNU, Seoul, S.Korea At 2011-11-21 15:32:17,W2AGZ wrote: To All (especially Eyvas), Are the input scripts used to generate the .fc files for the two Al examples and Fe from pw.x and ph.x available? Thanks, -Paul Paul Michael Grant, PhD Physicist and Science Writer Senior Life Fellow, American Physical Society Fellow, Institute of Physics, United Kingdom Staff Associate, Jet Propulsion Laboratory, NASA (2011) Visiting Scholar, Applied Physics, Stanford (2005-2008) EPRI Science Fellow (Retired) IBM Research Staff Member Emeritus Principal, W2AGZ Technologies w2agz at w2agz.com http://www.w2agz.com -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/2021/71487f30/attachment.htm
[Pw_forum] Problem With Total-Energy Convergence vs. ecutwfc
Hello, I seem to be having some serious trouble getting total energies to converge as I vary "ecutwfc" and "ecutrho". This is for a slab-model calculation, using PBE and USPP's, for an HF molecule reacting with the surface of Si3N4. The total energy results I get in representative calculations are: ecutwfc = 40 ecutrho = 400 Etot = -1504.8173322951 ecutwfc = 50 ecutrho = 500 Etot = -1505.03408093 ecutwfc = 60 ecutrho =720 Etot = -1505.12486679
[Pw_forum] SCF calculations do not converge
Hello All, I am trying to calculate the phonon dispersion relations and phonon density of states of UO2. Please find the attached files UO2.scf.in and UO2.ph.in The calculations assume GGA and include spin-polarized effects. There are 6 representations and nine modes. The problem I have is: When I run the input file UO2.ph.in, the second representation of the second mode for q (-0.167 0.167 -0.167), the *scf **calculations do not converge.* Notes: 1- My runs assume UO2 is metallic, in fact UO2 is insulator with band gap of 2eV.( However, when I do the calculations using the VASP code I got very good result only by including the polarization effects) 2- In order to account for the band gap, one should implement the Hubbard term (LDA/GGA+U) 3- I tried different occupations (smearing, tetrahedra) 4- I tried different starting_magnetization= 0.5, 1.0 5- the lattice parameter a= 10.285, is based on optimizing the structure and including spin-polarization effects. Any adivce to overcome this problem is highly welcomed. Kindest Regards, __ aIYAD I. AL-QASIR, PhD Research Associate Department of Nuclear Engineering North Carolina State University Campus Box 7909 2500 Stinson Dr. Raleigh, NC 27695-7909 -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/2021/967f21d2/attachment.htm -- next part -- A non-text attachment was scrubbed... Name: UO2.scf.in Type: application/octet-stream Size: 598 bytes Desc: not available Url : http://www.democritos.it/pipermail/pw_forum/attachments/2021/967f21d2/attachment.obj -- next part -- A non-text attachment was scrubbed... Name: UO2.ph.in Type: application/octet-stream Size: 204 bytes Desc: not available Url : http://www.democritos.it/pipermail/pw_forum/attachments/2021/967f21d2/attachment-0001.obj
[Pw_forum] PlotPhon Examples
On Sun, 2011-11-20 at 23:32 -0800, W2AGZ wrote: > Are the input scripts used to generate the .fc files for the two Al > examples and Fe from pw.x and ph.x available? examples 6 and 7 contain the procedure to produce force constants. Maybe not exactly you mention, though Paolo -- Paolo Giannozzi, IOM-Democritos and University of Udine, Italy
[Pw_forum] Segmentation Faults - Running QE-4.3.2 under Kubutu 11.10 within Latest Oracle Virtualbox
On Sun, 2011-11-20 at 23:48 -0800, W2AGZ wrote: > The Forum blames most segmentation issues on virtual memory > limitations?but I have 100 gigs. not sure about whom the Forum blames; I tend to blame (unless there is evidence of the opposite) bad compilers for most "segmentation faults" P. -- Paolo Giannozzi, IOM-Democritos and University of Udine, Italy
[Pw_forum] Segmentation Faults - Running QE-4.3.2 under Kubutu 11.10 within Latest Oracle Virtualbox
On Mon, Nov 21, 2011 at 2:48 AM, W2AGZ wrote: > To All, > > > > I know segmentation faults are a constant nuisance given the multitude of > platforms on which we ask QE to perform, but I?m having consistent failures > trying to run the examples on a new Windows box I?ve built based on the > latest Win7 and Oracle VB (Yeah, Yeah?I know?just switch to Linux, > period?but I need to run antediluvian tasks from time to time). > > hi paul, > The Forum blames most segmentation issues on virtual memory limitations?but > I have 100 gigs. those 100gigs may be useless if you have a 32-bit compiler or are compiling for a 32bit target. windows can be a bit funny there at times. if you _do_ compile for 64-bit, please keep an eye out for differences in sizes of integer variables. as far as i remember, there are differences between linux and windows and i would bet that very few Q-E developers, if any test on windows. the first step to solving a segfault issue is to determine exactly what is segfaulting where. for that you usually need to compile with debug information turned on and run under the control of a debugger to get a stack trace and thus determine the location of the segfault and then figure out whether you are running out of stack space or into some other issue. cheers, axel. > > > Thanks, -Paul > > > > Paul Michael Grant, PhD > > Physicist and Science Writer > > Senior Life Fellow, American Physical Society > > Fellow, Institute of Physics, United Kingdom > > Staff Associate, Jet Propulsion Laboratory, NASA (2011) > > Visiting Scholar, Applied Physics, Stanford (2005-2008) > > EPRI Science Fellow (Retired) > > IBM Research Staff Member Emeritus > > Principal, W2AGZ Technologies > > w2agz at w2agz.com > > http://www.w2agz.com > > > > > > > > > > > > > > > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > -- Dr. Axel Kohlmeyer akohlmey at gmail.com ?http://goo.gl/1wk0 College of Science and Technology Temple University, Philadelphia PA, USA.
