[Pw_forum] ecut dependence of symmetry operations(?)
Dear Stefano,
Thanks for your reply. I had not initially realized that discussions in
the forum about symmetry and FFT grid are directly related to its ecut
dependence. I browsed through forum after getting replies, and now have
got some idea about it.
Sincerely,
Madhura.
> Madhura: this has been discussed zilliions of times in this forum, and has
> to do with the way symmetry operations are found out by the code. When the
> symmetry group of the system is non-symmorphic, only those fractional
> translations that are commensurate with the FFT grid are actually found.
> This may sound a bit cryptic, and I leave it as such on purpose. You will
> find much more about this issue by browsing the archives of this mailing
> list. Hope this helps - SB
>
> On Jan 5, 2010, at 12:24 PM, Madhura Marathe wrote:
>
>> Dear all,
>>
>> While performing convergence calculations w.r.t energy cut-off for a
>> bulk
>> system, I found that the number of symmetry operations detected by a
>> code
>> is different depending on the value of ecut. This is very surprising
>> because for the same system, the symmetries should not depend on the
>> ecut
>> value.
>>
>> For Ecut = 20, 25, 40, 50 and 55 Ry, the output says -
>> "24 Sym.Ops. (with inversion)";
>> whereas for ecut = 30, 35, 45 and 60 Ry, the output is -
>> "12 Sym.Ops. (no inversion)"
>>
>> I have performed the same calculations using versions 4.0.4 and 4.1 with
>> the same results.
>> The input file is as follows -
>> *
>>
>>calculation = 'scf'
>>verbosity = 'high'
>>restart_mode = 'from_scratch',
>>prefix = 'RuGGA',
>>tstress=.true.
>>tprnfor=.true.
>>pseudo_dir = '/home/madhura-data/pseudo/',
>>outdir = '/home/madhura-data/tmp/'
>> /
>>
>>ibrav = 4, celldm(1) = 5.1831, celldm(3) = 1.584,
>>nat = 2, ntyp = 1,
>>ecutwfc = 20, ecutrho = 160, # ecutrho =
>> 8*ecutwfc
>>occupations='smearing', smearing='mp',degauss=0.05
>>nbnd = 20
>> /
>>
>>diagonalization = 'david', mixing_mode = 'plain',
>>mixing_beta = 0.7, conv_thr = 1.0d-12
>> /
>> ATOMIC_SPECIES
>> Ru 101.07 Ru.pbe-n-van.UPF
>> ATOMIC_POSITIONS {crystal}
>> Ru 0.00 0.00 0.00
>> Ru 0.6667 0. 0.50
>> K_POINTS automatic
>> 8 8 8 0 0 0
>> *
>>
>> Can anybody explain what is happening? Or do I need to file a bug
>> report?
>> Because except for this problem, energies and stress values seem to be
>> converging.
>>
>> Thanks and regards,
>> Madhura.
>>
>> --
>> Madhura Marathe,
>> PhD student, TSU,
>> JNCASR, Bangalore.
>> India.
>> Phone No: +91-80-22082835
>> ___
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum
>
> ---
> Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste
> http://stefano.baroni.me [+39] 040 3787 406 (tel) -528 (fax) /
> stefanobaroni (skype)
>
> La morale est une logique de l'action comme la logique est une morale de
> la pens?e - Jean Piaget
>
> Please, if possible, don't send me MS Word or PowerPoint attachments
> Why? See: http://www.gnu.org/philosophy/no-word-attachments.html
>
>
>
>
>
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
--
Madhura Marathe,
PhD student, TSU,
JNCASR, Bangalore.
India.
Phone No: +91-80-22082835
[Pw_forum] Band structure calculation from geometry optimization output files.
Dear Mohnish, Look at the examples 1 and 5 from espresso*/examples/ directory for details of band structure calculations. Regards, Madhura. > Dear PWSCF users, > >I have done geometry optimization for thin films of different systems. > Now I want to calculate the band structure of the compound. Can anybody > please give me a direction for the same. I am pasting a sample input file > for the geometry optimization for silver. > > Sincere Thanks in advance, > MOHNISH PANDEY > > > calculation = 'relax' > prefix='silver' > restart_mode='restart' > nstep=200, > outdir='/home/rajpala/Desktop/silver3hcp_7' > pseudo_dir="/home/rajpala/Desktop/silver3hcp_7" > / > > ibrav= 4, celldm(1) =9,celldm(3)=5.25099769,nat= 9, ntyp= 1, > ecutwfc = > 30,ecutrho=240,occupations='smearing',degauss=0.015,smearing='gaussian' > / > >diagonalization='david' >mixing_mode = 'local-TF' >mixing_beta = 0.7 >electron_maxstep=200 >conv_thr = 1.0d-6 > / > > ion_dynamics='bfgs' > trust_radius_min=1.D-4 > / > > cell_dynamics='bfgs' > / > ATOMIC_SPECIES > Ag 107.8682 Ag.pbe-d-rrkjus.UPF > ATOMIC_POSITIONS (crystal) > Ag 0.0 0.0 0.0 > Ag 0. 0. 0.0 > Ag 0. 0. 0.0 > Ag 0. 1.0 0.088 > Ag 0. 0. 0.088 > Ag 0.0 0. 0.088 > Ag 0.0 0.0 0.176 > Ag 0. 0. 0.176 > Ag 0. 0. 0.176 > K_POINTS (automatic) > 7 7 1 1 1 1 > > > -- > Mohnish Pandey > Y6927262,4th Year dual degree student, > Department of Chemical Engineering, > IIT KANPUR > 09235721300 > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] ecut dependence of symmetry operations(?)
Thanks Kun Yin and Lorenezo. I checked the output files and saw the warnings related to FFT at the start of the output file for which I get less number of symmetry operations. Best wishes for new year, Madhura. > Quoting Madhura Marathe : >> Dear all, >> >> While performing convergence calculations w.r.t energy cut-off for a >> bulk >> system, I found that the number of symmetry operations detected by a >> code >> is different depending on the value of ecut. This is very surprising >> because for the same system, the symmetries should not depend on the >> ecut >> value. > > > Dear Madhura, > your question is the complementary one to a Frequentedly-Asked > Question (FAQ), when the code suppresses some symmetry operation > because they are incompatible with the FFT grid a warning is issued. > See this page <http://quantum-espresso.org/user_guide/node57.html> for > more details. > > regards > > > > -- > Lorenzo Paulatto > > formerly at: > SISSA & DEMOCRITOS (Trieste) > skype: paulatz > www: http://people.sissa.it/~paulatto/ > > *** save italian brains *** >http://saveitalianbrains.wordpress.com/ > > > >SISSA Webmail https://webmail.sissa.it/ >Powered by Horde http://www.horde.org/ > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] simulated STM image
Dear Paolo, Thanks for the reply, but what I really wanted to know is whether there was some bug because of which that option was discontinued or just because it became incompatible with modifications in other part of the code? In the second case, one can just modify its format. However, because it is not for the 'constant-density' mode I guess I won't modify it. Now to get 'constant-density' mode - finding the constant-height STM images at various heights (range relevant for the system under study) and then using 'grep' or something to get required quantity - should work. Is that reasonable process? Or there are some problems with that which I can not see? Thanks once again. Madhura. > > On Dec 10, 2009, at 14:34 , Madhura Marathe wrote: > >> 1) The option of 'stm_wfc_matching' is not working [...] why >> was that disabled? > > because it wasn't working any longer > >> And if necessary, can I use the wave-functions and charge density >> files >> from the latest version for the older version post-processing >> tools, to >> get this option working? > > no. As far as I know, it has never been working in any public version > of QE. > It may have worked in some old version lost (forever) in cyberspace. > >> 2) [...] wave-function matching option has some z and dz parameters >> which probably were used to get the image corresponding to the >> latter mode. >> Is that correct guess? > > I don't think so. The idea of wavefunction matching is to fit the > exponential > tail of the wavefunction to an analytical function, thus reducing the > noise > >> 3) I have seen some papers which give simulated STM images >> calculated at >> "constant-current" mode using QE (e.g. - Valentin, JCP 2007). So does >> there exist some post-processing tool to calculate that? > > not that I know > > P. > --- > Paolo Giannozzi, Dept of Physics, University of Udine > via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] simulated STM image
Dear all, I have been trying to find the simulated STM images for some surfaces. I have some doubts about the procedure: 1) The option of 'stm_wfc_matching' is not working. According to some forum posts, it has been disabled for some latest versions. The working of that option itself was not very clear to me from documentation, but why was that disabled? And if necessary, can I use the wave-functions and charge density files from the latest version for the older version post-processing tools, to get this option working? 2) I am interested to know that because from calculations what we get is ILDOS and we plot it some fixed plane. This will correspond to "constant-height" mode of the STM experiments. However, more common mode in experiments is "constant-current"; and that wave-function matching option has some z and dz parameters which probably were used to get the image corresponding to the latter mode. Is that correct guess? 3) I have seen some papers which give simulated STM images calculated at "constant-current" mode using QE (e.g. - Valentin, JCP 2007). So does there exist some post-processing tool to calculate that? If yes, where can I find it? Thanks and regards, Madhura. -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] DOS and pDOS parallelization
ss wf_collect flag is set to 'true' for scf >> calc.s; >> >> also one has to use the same no. of proc.s as were used for scf >> calc.s >> >> to >> >> get projected DOS. >> >> >> >> Now my question is are these interpretations correct? Or they may >> change >> >> for some other system?? Do I need to do some more checks to ascertain >> >> these? If yes, what sort of tests? >> >> >> >> Thanks for reading this long mail patiently, but I need to clarify on >> >> these points before I can start with bigger systems. >> >> Sincerely, >> >> Madhura. >> >> >> >> >> >> >> > >> > -- >> > Andrea Ferretti >> > MIT, Dept Material Science & Engineering >> > bldg 13-4078, 77, Massachusetts Ave, Cambridge, MA >> > Tel: +1 617-452-2455; Skype: andrea_ferretti >> > URL: http://quasiamore.mit.edu >> > >> > Please, if possible, don't send me MS Word or PowerPoint attachments >> > Why? See: http://www.gnu.org/philosophy/no-word-attachments.html >> > >> > >> > ___ >> > Pw_forum mailing list >> > Pw_forum at pwscf.org >> > http://www.democritos.it/mailman/listinfo/pw_forum >> > >> >> >> > > -- > Andrea Ferretti > MIT, Dept Material Science & Engineering > bldg 13-4078, 77, Massachusetts Ave, Cambridge, MA > Tel: +1 617-452-2455; Skype: andrea_ferretti > URL: http://quasiamore.mit.edu > > Please, if possible, don't send me MS Word or PowerPoint attachments > Why? See: http://www.gnu.org/philosophy/no-word-attachments.html > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] DOS and pDOS parallelization
Dear all, There have been many discussions in this forum about parallelization of DOS and projected DOS codes. However, some of the points were not clear to me, so I have performed some scf calculations for a very simple system using 8 processors and with flag wf_collect 'false'. I have performed same calculations once without use of pools (A) and then using 2 pools (B). Then using theses wavefunctions I have performed DOS and PDOS calculations. Following is the summary of results and my interpretation: i) Pool parallelization is not implemented for both these codes. ii) DOS calculations: for both the cases A and B, one can calculate DOS with the same no. of processors (= 8) and the results match within numerical errors; even though for case B, the wavefunctions were obtained with pooling and DOS without it. For case A, even if I use 4 processors I get identical results as when I use 8 processors. (Note, I have not checked with less no. of proc.s for B). => The condition that we need the same no. of processors and pools as were used in scf calculations is not necessary; and it is possible to get DOS results even with wavefunctions generated with pool parallelization. iii) PDOS calculations: This can be calculated only in case of A and using the same no. of processors. If I use wavefunctions generated in case B or less no. of processors (= 4) with A wavefn.s then I get "davcio" error. => For PDOS calculations, one cannot use wavefunctions generated with pool parallelization unless wf_collect flag is set to 'true' for scf calc.s; also one has to use the same no. of proc.s as were used for scf calc.s to get projected DOS. Now my question is are these interpretations correct? Or they may change for some other system?? Do I need to do some more checks to ascertain these? If yes, what sort of tests? Thanks for reading this long mail patiently, but I need to clarify on these points before I can start with bigger systems. Sincerely, Madhura. -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] conv_thr for forces for relaxing ions
Dear Stefano, Thanks for the quick reply. This was really necessary to confirm since the calculations are expensive. And I am more interested in the ground state structure, may not use the actual value of the force for further analysis. Madhura. > In PWscf the forces are calculated from the Hellman-Feynman theorem > (strictly true only at the stationary point) plus a correction that > (approximately) accounts for the residual lack of self-consistency. As > such when the correction is large compared to the Hellman-Feynman term > one should be careful. > In your case I would say that the forces are now probably very small > and therefore the structure is reliable. > I would say that the actual (small) value for the force are probably > correct within a few percent since the correction term is (according to > the value quote) of the order of 10 % of the total (and hopefully is not > completely wrong). > Hope this helps, > stefano de Gironcoli -SISSA and DEMOCRITOS > > Madhura Marathe wrote: >> Dear all, >> >> During one of the ionic relaxation calculations, I got the error >> message, >> "SCF correction compared to forces is too large, reduce conv_thr". I am >> using conv_thr = 1.0d-8 which is generally sufficient, so I increased >> the >> parameter upscale (from 10.0 to 100.0) in to reduce the the >> threshold during relaxation. This lead to the convergence till the last >> ionic iteration which was converged to sufficient accuracy, when again >> the >> same error message occurred. The forces then are >> Total force = 0.000136 Total SCF correction = 0.16 >> SCF correction compared to forces is too large, reduce conv_thr >> >> There has been a recent discussion on the topic. From that, I gathered >> that the subsequent relaxations after this error message are not >> reliable. >> So my question is whether the forces are reliable in this last >> iteration? >> Or do I need to further reduce the conv_thr and re-run the whole >> calculation? >> >> Thanks for the help, >> Madhura. >> >> > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] conv_thr for forces for relaxing ions
Dear all, During one of the ionic relaxation calculations, I got the error message, "SCF correction compared to forces is too large, reduce conv_thr". I am using conv_thr = 1.0d-8 which is generally sufficient, so I increased the parameter upscale (from 10.0 to 100.0) in to reduce the the threshold during relaxation. This lead to the convergence till the last ionic iteration which was converged to sufficient accuracy, when again the same error message occurred. The forces then are Total force = 0.000136 Total SCF correction = 0.16 SCF correction compared to forces is too large, reduce conv_thr There has been a recent discussion on the topic. From that, I gathered that the subsequent relaxations after this error message are not reliable. So my question is whether the forces are reliable in this last iteration? Or do I need to further reduce the conv_thr and re-run the whole calculation? Thanks for the help, Madhura. -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India. Phone No: +91-80-22082835
[Pw_forum] About PWgui-4.0 and XCrySDen
Hi, I had encountered the same problem with Xcrysden. It occurs because of change in output format for the latest version. Earlier versions will print only relaxed atomic positions (x, y and z coords), but in 4.0 version the relaxed positions are followed by input parameters specified in input file for relaxing atoms (0 or 1). Hence Xcrysden cannot read these and shows only initial configuration which is in usual format. If you remove extra three no.s in each atomic positions from the output file, it works fine. -Madhura. > Dear everyone, > I have two questions about the additional tools for espresso-4.0. > First is the compilation of PWgui-4.0, namely, when executing ./pwui > I got error message: Can't find package Itcl while executing. >The second is about XCrySDen, when runing espresso-4.0, it seems > that only the initial structure could be displayed, while the subsequent > configurations could not be imported. If I use the previous version, > espresso-3.2.3, then everything goes well. >Does anyone have the same problem? >Best Regards, > > > =Fan Yang > PH.D Candidate in Electrochemistry > College of Chemistry and Molecular Science > Wuhan University,430072,Hubei Province,China > E-mail:shrek_826 at yahoo.com.cn > === > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Madhura Marathe, PhD student, TSU, JNCASR, Bangalore. India.
