Re: [QE-users] Question about optimizing the lattice constant of iron
Hi, Dear Gui Wei, Using the PBE functional, the lattice constant of bcc Fe is supposed to be smaller than experimental value.Please take a look at https://molmod.ugent.be/deltacodesdft. Wien2K gives 2.831 A. PSlib and GBRV give some value around 2.834.And, PBE is one of the best functionals on bcc Fe.As Stefano suggests, you might need to increase somehow the plane wave cutoff, though. (to reproduce other properties correctly) (and as well as the k-points) Yi Wang Tsinghua University On 12/25/2018 18:02，Stefano de Gironcoli wrote： cutoff might be too small for a reliable computation of the stress. other than that I see no big issue in your input stefano On 25/12/18 04:35, Gui Wei wrote: Hi, When optimizing the lattice constant of bcc Fe,the result is a=2.830A， which is in disagreement with experimentally derived structural parameter a=2.863A.Could someone give me some advice? calculation = 'vc-relax' prefix='Fe1', pseudo_dir = '/public/home/duan1/gw2/pseudo/', outdir='/public/home/duan1/gw2/tempdir/' tprnfor = .true. tstress = .true. / ibrav= 1, A=2.8664 nat= 2 ntyp= 1 occupations='smearing', smearing='mp', degauss=0.02, ecutwfc =37 ecutrho =240 nspin = 2 starting_magnetization(1) = 0.4 / conv_thr = 1.0d-8 mixing_beta = 0.7 / ion_dynamics = 'bfgs' / cell_dynamics = 'bfgs' / ATOMIC_SPECIES Fe 55.847 Fe.pbe-n-kjpaw_psl.0.2.4.UPF ATOMIC_POSITIONS crystal Fe 0. 0. 0. Fe 0.5001 0.5001 0.5001 K_POINTS automatic 8 8 8 0 0 0 The result: CELL_PARAMETERS (alat= 5.41671099) 0.987418499 0.0 0.0 0.0 0.987418499 0.0 0.0 0.0 0.987418499 Gui Wei School of Mechanical Engineering，Chongqing University, China ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] any tool to get real space force constant from shifted q grid or manually q grid phonon calculations?
Many thanks.I will refresh the textbooks.Best,Yi Wang On 5/10/2018 19:44，Lorenzo Paulatto<paul...@gmail.com> wrote： Yes, I understand the cost of phonon is the critical part.For clarification, I meant if I perform phonon calculation on less q points (not on full gamma centered MP grids), This is not how force constants work: as they are the (discrete) Fourier transform of the dynamical matrix, they can only be computed accurately for points which are reciprocal to the q-points in the grid. Using shifted grids is a good trick when computing "square modulus" integrals, where the phase does not count. But the calculation of force constants is all about the phase, and shifted grids do not work very well for this case. The fact that you eventually want the DOS is a red herring, it is completely irrelevant to the problem.Kind regards how could I get reliable real space force constants toward the calculation of DOS. Yi Wang Nanjing University of Sci. & Tech. On 5/10/2018 12:42，Lorenzo Paulatto<paul...@gmail.com> wrote： Hello, the cost of computing the phonon dos with matdyn is zero, compared to the cost of the phonon calculation itself. -- Lorenzo PaulattoWritten on a virtual keyboard with real fingersOn 10 May 2018 06:31, "Yi Wang" <wangw...@gmail.com> wrote: Dear everyone,As I understand, the q2r.x works only on gamma centered q grids for the DFPT calculations. However, is there any tool to calculate the real space force constant for the shift q points calculations and the manually q grid calculations?If it is possible, I want to test the phonon DOS calculation on some smaller q grids for the sake of saving cost.Thank for your guidance. Yi WangNanjing University of Sci. & Tech. ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] any tool to get real space force constant from shifted q grid or manually q grid phonon calculations?
Dear Dr. Lorenzo Paulatto,Thanks for your replyYes, I understand the cost of phonon is the critical part.For clarification, I meant if I perform phonon calculation on less q points (not on full gamma centered MP grids), how could I get reliable real space force constants toward the calculation of DOS. Yi Wang Nanjing University of Sci. & Tech. On 5/10/2018 12:42，Lorenzo Paulatto<paul...@gmail.com> wrote： Hello, the cost of computing the phonon dos with matdyn is zero, compared to the cost of the phonon calculation itself. -- Lorenzo PaulattoWritten on a virtual keyboard with real fingersOn 10 May 2018 06:31, "Yi Wang" <wangw...@gmail.com> wrote: Dear everyone,As I understand, the q2r.x works only on gamma centered q grids for the DFPT calculations. However, is there any tool to calculate the real space force constant for the shift q points calculations and the manually q grid calculations?If it is possible, I want to test the phonon DOS calculation on some smaller q grids for the sake of saving cost.Thank for your guidance. Yi WangNanjing University of Sci. & Tech. ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] any tool to get real space force constant from shifted q grid or manually q grid phonon calculations?
Dear everyone,As I understand, the q2r.x works only on gamma centered q grids for the DFPT calculations. However, is there any tool to calculate the real space force constant for the shift q points calculations and the manually q grid calculations?If it is possible, I want to test the phonon DOS calculation on some smaller q grids for the sake of saving cost.Thank for your guidance. Yi WangNanjing University of Sci. & Tech. ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] a question on k-points
Hi,When doing SCF calculations, if I manually input a set of full grid k-points using the card "K_POINTS crystal" without any symmetry reduction, will pw.x automatically do the reduction with respect to the symmetry? (assuming nosym=.false.)Many thanks.Yi WangNanjing University of Science and Technology ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[Pw_forum] a convergency problem
Dear everyone, I have a convergency problem facing the pw.x after version 5.0.2 The example input is given in the last section. The structure is a bcc-like supercell containing Fe and Cu atoms (relaxed) (with GBRV uspp). The structure can be run properly with smearing, the problem comes from "tetrahedra" occupation. If I use a non-offset k point mesh, as given in the input, the convergency would get stuck around 1E-6~1E-8 Ry, never get better like most other supercells of Fe and Cu. The problem can be solved by offset the k mesh. However, my local mentors do not suggest me to do so. Because we have lots of different supercells, the offseted k mesh would give very different centering k point in different supercells, it would appear to be trouble if I compare their energies. (btw, what is your opinions on this?) The problem can also be solved by increasing the size of k mesh, but still, not cheap and absolute necessary for the calculation of lots supercells. However, in version 5.0.2, there is no such problem, and convergency can be achieved quickly (if I rerun [in post 5.0.2 versions] starting from the converged charge density [by v 5.0.2], convergency still cannot be achieved ). That's why I'm asking for help here, before I turn to other solutions. So far, I tried to change number of bands, mixing beta, and parallel running parameter...all those appear to be irrelevant. Only k mesh would change the result. Your suggestions and help is appreciated. Yi Wang Nanjing university of Science and Technology calculation = 'scf' , prefix = 'pwscf' , outdir = './temp-p_t/' , pseudo_dir = '/home/sim/pot/pwscf/' , restart_mode = from_scratch , disk_io= 'none' / ibrav = 0 , ecutwfc = 40 , ecutrho = 400 , occupations = 'tetrahedra' , nspin=2, nbnd= 120, nat = 12 , ntyp = 2 , starting_magnetization( 1 )= 0.01, starting_magnetization( 2 )= 0.26, use_all_frac=.true. / conv_thr = 1d-9 , diagonalization = 'david' , mixing_mode = 'local-TF' , startingpot = 'atomic' , startingwfc = 'atomic+random' mixing_beta = 0.12 , mixing_ndim = 16, diago_david_ndim=4 / CELL_PARAMETERS bohr 5.689675841 0.0 0.0 0.0 -10.558955237 0.0 0.0 0.0 -15.996363568 ATOMIC_SPECIES Cu 63.546 cu_pbe_v1.2.uspp.F.UPF Fe 55.845 fe_pbe_v1.5.uspp.F.UPF ATOMIC_POSITIONS crystal Fe 1.0 0.498189104 0.666054422 Fe 0.5 0.251812190 0.500611021 Fe 1.0 0.003971761 0.664566351 Fe 0.5 0.746028153 0.502102015 Fe 1.0 0.500799770 0.0 Fe 0.5 0.249203627 0.83320 Cu 1.0 0.998064252 0.33150 Cu 0.5 0.751929936 0.83540 Fe 0.5 0.251812380 0.166055619 Fe 0.5 0.746028003 0.164564485 Fe 1.0 0.498188874 0.000612278 Fe 1.0 0.003971951 0.002100469 K_POINTS automatic 12 7 4 0 0 0 ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
Re: [Pw_forum] strange population analysis result, in PW v 5.4
Dear Dr. Paolo,
Many thanks for the explanation!
I read make_pointlists.f90 to understand this. About the radius, I think,
would not it be reasonable to calculate distmin in a.u. cartesian
coordinates, and then directly get r_m(nt) in a.u. unit, finally give its
equivalent of alat unit as r_m(nt)/alat? That would ensure a same
integration for all cases (and won't be harmful if an option for r_m is
directly allowed in input)
Yi Wang
--
Yi Wang
Ph.D candidate at Nanjing University of Science and Technology
On Mon, 05 Sep 2016 18:00:25 +0800, Paolo Giannozzi
<p.gianno...@gmail.com> wrote:
In the first case, lattice parameter alat = the value of celldm(1);
in the second case, alat = length of the first cell vector ("a" in
crystallography).
There is a factor sqrt(3) difference.
The "atomic magnetization" (whatever it means) is computed by
integrating over a sphere whose radius is a fixed >fraction of the
lattice parameter (look for r_m in the output). So the two
magnetizations differ even if >everything else is the same
Paolo
On Sat, Sep 3, 2016 at 5:19 AM, Yi Wang <wangw...@gmail.com> wrote:
Hi, dear developers,
I'm using PW v5.4 to do some calculation, I found the population
analysis
printed during scf calculation has a strange behavior depending on the
settings of cell_parameter.
bellowing is the input where I found the strange thing:
as you may see, here, I use celldm(1) and alat to control the cell
parameters. I got a m=1.36 in this case.
If I change the cell parameters in the form of "CELL_PARAMETERS bohr", I
got m=1.96.
In both cases, the "total magnetization" is 1.96 (the cutoff is not
converged for the potential, but anyway, potentials and cutoffs are
irrelevant, I've checked both of them)
The geometry is essentially the same, but the analysis is very
different,
energy, "total" and "absolute" magnetizations are not affected, of
course.
May I also ask is the analysis printed during scf is the Mulliken
analysis?
calculation = 'scf' ,
prefix = 'pwscf' ,
outdir = './tempfft/' ,
pseudo_dir = './' ,
restart_mode = from_scratch ,
disk_io= 'none'
/
ibrav = 0 ,
ecutwfc = 80 ,
occupations = 'tetrahedra' ,
nspin=2,
nbnd= 18 ,
nat = 1 ,
ntyp = 1 ,
use_all_frac=.TRUE.
celldm(1)=2.7120201830,
starting_magnetization( 1 )= 0.26,
/
conv_thr = 1d-12 ,
diagonalization = 'david' ,
mixing_mode = 'plain' ,
startingpot = 'atomic' ,
startingwfc = 'atomic+random' ,
mixing_beta = 0.12 ,
mixing_ndim = 10,
/
CELL_PARAMETERS alat
-1 1 1
1 -1 1
1 1 -1
ATOMIC_SPECIES
Fe 55.845 Fe.gth.upf
ATOMIC_POSITIONS bohr
Fe 0 0 0
K_POINTS automatic
20 20 20 0 0 0
Thanks for your attention.
Yi Wang
--
Yi Wang
Ph.D candidate at Nanjing University of Science and Technology
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum
--Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] strange population analysis result, in PW v 5.4
Hi, dear developers, I'm using PW v5.4 to do some calculation, I found the population analysis printed during scf calculation has a strange behavior depending on the settings of cell_parameter. bellowing is the input where I found the strange thing: as you may see, here, I use celldm(1) and alat to control the cell parameters. I got a m=1.36 in this case. If I change the cell parameters in the form of "CELL_PARAMETERS bohr", I got m=1.96. In both cases, the "total magnetization" is 1.96 (the cutoff is not converged for the potential, but anyway, potentials and cutoffs are irrelevant, I've checked both of them) The geometry is essentially the same, but the analysis is very different, energy, "total" and "absolute" magnetizations are not affected, of course. May I also ask is the analysis printed during scf is the Mulliken analysis? calculation = 'scf' , prefix = 'pwscf' , outdir = './tempfft/' , pseudo_dir = './' , restart_mode = from_scratch , disk_io= 'none' / ibrav = 0 , ecutwfc = 80 , occupations = 'tetrahedra' , nspin=2, nbnd= 18 , nat = 1 , ntyp = 1 , use_all_frac=.TRUE. celldm(1)=2.7120201830, starting_magnetization( 1 )= 0.26, / conv_thr = 1d-12 , diagonalization = 'david' , mixing_mode = 'plain' , startingpot = 'atomic' , startingwfc = 'atomic+random' , mixing_beta = 0.12 , mixing_ndim = 10, / CELL_PARAMETERS alat -1 1 1 1 -1 1 1 1 -1 ATOMIC_SPECIES Fe 55.845 Fe.gth.upf ATOMIC_POSITIONS bohr Fe 0 0 0 K_POINTS automatic 20 20 20 0 0 0 Thanks for your attention. Yi Wang -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
Re: [Pw_forum] patch to allow compilation with MKL FFTW3
Hi, Dear David Strubbe, If you use the DFLAG "-D__DFTI" for mkl-fftw, there will be no such problem. I encountered this too, because the flag D__FFTW3 worked in QE 5.0.3, but then I realized that was just luck. Since the fftw interface seems to be systematically improved, it is better to use the more suitable flag. -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology On Thu, 21 Apr 2016 07:25:15 +0800, David Strubbe <dstru...@berkeley.edu> wrote: In trying to compile version 5.3.0 with Intel compilers (version 16.0.0 20150815) and Intel MPI, using MKL >version 2016.0.109 for FFTW3, I got the following error for linking pw.x: mpiifort -o pw.x \ pwscf.o libpw.a ../../Modules/libqemod.a ../../FFTXlib/libqefft.a ../../flib/ptools.a ../../flib/>flib.a ../../clib/clib.a ../../iotk/src/libiotk.a -lmkl_scalapack_lp64 -Wl,--start-group /opt/intel/>compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/>compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_sequential.a /opt/intel/>compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_core.a /opt/intel/>compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group /opt/intel/compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_intel_lp64.a(fftw_version.o):(.rodata>+0x0): multiple definition of `fftw_version' ../../FFTXlib/libqefft.a(fft_stick.o):(.data+0x430): first defined here ld: Warning: size of symbol `fftw_version' changed from 8 in ../../FFTXlib/libqefft.a(fft_stick.o) to 27 in />opt/intel/compilers_and_libraries_2016.0.109/linux/mkl/lib/intel64/libmkl_intel_lp64.a(fftw_version.o) I solved this problem by removing the following three offending lines: clib/fftw.h:129:extern char *fftw_version; FFTXlib/fftw.h:136:extern char *fftw_version; FFTXlib/fftw.c:348:char *fftw_version = "FFTW V1.1 ($Id: fftw.c,v 1.3 2010-01-26 14:06:59 giannozz Exp $)"; Then compilation and running of pw.x are successful. As far as I can tell, those fftw_version lines do not serve >any purpose at least for pw, pp, or ph, since I do not find this variable being used anywhere else in those >parts of the code. I recommend the removal of these lines, or if in some plugin I have not downloaded the >fftw_version is actually used, I suggest you rename it to avoid this name clash. Cheers, David Strubbe MIT___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] On the size of Monkhorst-Pack grid for phonon calculation
Dear everyone, What would be the appropriate value for the size of Monkhorst-Pack grid for phonon calculation?(Such as for primitive cell of bcc/fcc metals) In the published papers, I saw it is usually very detailed on SCF or relax parameters but seldom saw on this. Could you tell me how should we consider the size effect? Is there a procedure like how we do on ecut convergence? Sorry this question is not directly PWscf concerned. Many thanks for any help. -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] the algorithm of Virtual.x and related reference paper
Dear developers, What is the algorithm that virtual.x uses to generate VCA pseudo potentials? Which papers I need to cite when using this tool? Thank you very much. Yi Wang Ph.D candidate at Nanjing University of Science and Technology ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] meaning of Lowdin charges with non-collinear magnetizations
Dear everyone, I'm doing a non-collinear magnetization calculation(non spin-orbit). I wanted to know the magnetic moment on each atom, thus I performed the Lowdin charge calculation with projwfc.x. The code gives the the results of "polarization", "spin up", "spin down", and "total charge". I want to ask what is the physical meaning of the "polarization" under this non-collinear condition? I noticed its value is somehow close to the absolute value of the magnetization of each atom along the z axis(which is printed out every iteration, I read it is calculated from the charge integration inside a given volume, please correct me if I'm wrong), is that what it means? The z axis component of the magnetic moment rather than the total magnetic moment? or something else? Thank you for your precious time. -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology ___ Pw_forum mailing list Pw_forum@pwscf.org http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] pwscf 5.1 IO open error
Dear Prof. Paolo Giannozzi, Thank you for the quick reply. The workaround of setting initial spin polarization works. It seems if we let the code self consistently to get the result that BCC-Cu is nonmagnetic with a non zero starting_magnetization at the very beginning, the final scf check will runs fine. Well, we set the starting value as zero just want to save some time, because at least for the potential(from GBRV, I forgot to tell last time) we are using now, in different configurations containing Fe and Cu atoms, different value of starting_magnetization for Cu always leads to the same energy and magnetization value as the ones when starting_magnetization=0 for Cu. Seems the current code favors more to find this by itself ;) -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology On Sun, 29 Jun 2014 17:03:07 +0800, Paolo Giannozzi wrote: > It is actually a bug, during the check for the unlikely > but not impossible case of a structural optimization > where the magnetization is lost during the process, > leading to a final nonmagnetic ground state, in a > system whose final configuration is instead magnetic. > Workaround: restart from the final configuration, allowing > an initial spin polarization. Removing the call to "wfcinit" > in move_ions.f90 should also work, but I didn't test it. > > Paolo > > On Fri, 2014-06-27 at 13:49 +0800, Yi Wang wrote: >> (I sent this mail previously, but wrongly used an unsubscribed mail >> address. Please ignore this if it is duplicated. Thank you for >> understanding.) >> >> Hi dear developers, >> >> When I use the 5.1 version, I may found a possible bug during vc-relax. >> I >> didn't see related threads in the listing, so I'm reporting it here. >> I'm using the pwscf version 5.1. For the attached input file >> 'pwscfrxf.rx.in', pw.x will fail at the final scf checking during >> vc-relax, error information is copied into 'errorinfo' file. The same >> input works fine for version 5.0.3. It appears the version 5.1 pw.x trys >> to open a file handler whose unit is already used/opened. Sorry I don't >> have the ability to further debug which file it trys to open again, I >> don't how to debug mpi codes with -g compile option. >> The error seems can be reproduced when there is no magnetization but >> nspin=2, however for magnetic systems--e.g. ferromagnetic alpha-Fe, the >> input runs fine. In my input the nspin is turned to 2 because it is >> automatically generated as one of a series of inputs for exploration in >> Fe-Cu alloys. >> >> >> -- >> Yi Wang >> Ph.D candidate at Nanjing University of Science and Technology >> ___ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://pwscf.org/mailman/listinfo/pw_forum > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] pwscf 5.1 IO open error
(I sent this mail previously, but wrongly used an unsubscribed mail address. Please ignore this if it is duplicated. Thank you for understanding.) Hi dear developers, When I use the 5.1 version, I may found a possible bug during vc-relax. I didn't see related threads in the listing, so I'm reporting it here. I'm using the pwscf version 5.1. For the attached input file 'pwscfrxf.rx.in', pw.x will fail at the final scf checking during vc-relax, error information is copied into 'errorinfo' file. The same input works fine for version 5.0.3. It appears the version 5.1 pw.x trys to open a file handler whose unit is already used/opened. Sorry I don't have the ability to further debug which file it trys to open again, I don't how to debug mpi codes with -g compile option. The error seems can be reproduced when there is no magnetization but nspin=2, however for magnetic systems--e.g. ferromagnetic alpha-Fe, the input runs fine. In my input the nspin is turned to 2 because it is automatically generated as one of a series of inputs for exploration in Fe-Cu alloys. -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology -- next part -- A non-text attachment was scrubbed... Name: errorinfo Type: application/octet-stream Size: 632 bytes Desc: not available Url : http://pwscf.org/pipermail/pw_forum/attachments/20140627/1b3b9249/attachment.obj -- next part -- A non-text attachment was scrubbed... Name: pwscfrxf.rx.in Type: application/octet-stream Size: 1104 bytes Desc: not available Url : http://pwscf.org/pipermail/pw_forum/attachments/20140627/1b3b9249/attachment-0001.obj
