[Pw_forum] The issue of k-points in CARTESIAN coordinates obtained by XCrySDen-1.5.24.
Dear Prof. Tone and others,
I use pre-compiled xc-1.5.24-linux_x86-semishared.tar.gz on my Debian box.
Now I use the k-path selection function to prepare k-point file used for
pwscf. My system is graphene. The graphene.inp file is as follows:
-
calculation = 'scf'
prefix='graphene'
pseudo_dir = './'
outdir='./'
tstress=.true.
tprnfor = .true.
forc_conv_thr=1.0d-4
nstep=200
/
ibrav=0
celldm(1)=1.889726
nat=2
ntyp=1
ecutwfc=36
/
mixing_beta=0.7
conv_thr = 1.0d-8
electron_maxstep=200
/
trust_radius_max=0.2
/
cell_dynamics='bfgs'
/
ATOMIC_SPECIES
C 12.0110 C.UPF
CELL_PARAMETERS (alat)
2.1314617179 -1.2306200.00
0.002.4612400.00
0.000.00 36.918600
ATOMIC_POSITIONS (crystal)
C 0.0 0.0 0.0
C 0.66671 0.5 0.0
K_POINTS {automatic}
4 4 4 1 1 1
-
I select the k-path as M --> G -->K --> M , and then generate the
corresponding files, i.e., graphene.pwscf and supportInfo.kpath.
In the file supportInfo.kpath, you can find the following information:
-
Selected k-points in CARTESIAN coordinates:
0.234580.00.0M
0.00.00.0G
0.234580.135430.0K
0.234580.00.0M
Selected k-points in crystal coordinates:
(with respect to RECIPROCAL-PRIMITIVE vectors)
0.50.00.0M
0.00.00.0G
0.30.30.0K
0.50.00.0M
Selected k-points in crystal coordinates:
(with respect to RECIPROCAL-CONVENTIONAL vectors)
0.50.00.0M
0.00.00.0G
0.30.30.0K
0.50.00.0M
---
Here, I have some puzzles on the k-points in CARTESIAN coordinates
obtained by XCrySDen. For example, the K point in BZ has the fractional
coordinates as this: ( 0.30.30.0 ).
And in my case, I've the lattice vectors as follows:
--
CELL_PARAMETERS (alat)
2.1314617179 -1.2306200.00
0.002.4612400.00
0.000.00 36.918600
---
So, I can obtain the reciprocal lattice like this:
B ^ T = 2*Pi* A ^ (-1), where, A and B are 3*3 matrix whose column vectors
are corresponding to the real space lattice vectors and reciprocal
lattice vectors, respectively.
Thus, I obtain B as follows from within matlab:
>> B= 2*pi*inv([2.1314617179 -1.2306200.00;
0.002.4612400.00;
0.000.00 36.918600])'
B =
2.9478 0 0
1.47392.5529 0
0 00.1702
So the CARTESIAN coordinates for K point ( 0.30.30.0
) should be:
>> [0.30.30.0]*B
ans =
1.47390.8510 0
As you can see, your XCrySDen gives the CARTESIAN coordinates for K
point ( 0.30.30.0 ) as follows:
0.234580.135430.0K
I cann't figure out what's the reason. Could you please give me some
hints on this issue?
Attached please find all the files mentioned above.
Regards.
--
Hongsheng Zhao
School of Physics and Electrical Information Science,
Ningxia University, Yinchuan 750021, China
-- next part --
A non-text attachment was scrubbed...
Name: graphene.inp
Type: chemical/x-gamess-input
Size: 731 bytes
Desc: not available
Url :
http://www.democritos.it/pipermail/pw_forum/attachments/20110628/b14cdcfd/attachment.inp
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: graphene.pwscf
Url:
http://www.democritos.it/pipermail/pw_forum/attachments/20110628/b14cdcfd/attachment.asc
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: supportInfo.kpath
Url:
http://www.democritos.it/pipermail/pw_forum/attachments/20110628/b14cdcfd/attachment.txt
[Pw_forum] Pw_forum Digest, Vol 48, Issue 71
On Jun 28, 2011, at 18:58 , Nicola Marzari wrote: > 1) the converter fhi2ups might have been changed in the last 5 years, > but now things work properly it has changed, even recently, but I haven't seen anything justifying weird results. I remember however there have been reports of funny results with the fhi converter also in the past. Moreover, no later than two weeks ago, I got strange results with fhi converted LDA Si and O PP from Abinit tables. > 2) we should remove O.pbe-mt.UPF from the pseudo table, and > replace it with a O.pbe-mt-new.UPF, that is your O.cpi.UPF. will be done P. --- Paolo Giannozzi, Dept of Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] Pw_forum Digest, Vol 48, Issue 71
Thanks Deyu Lu - it looks like 1) the converter fhi2ups might have been changed in the last 5 years, but now things work properly 2) we should remove O.pbe-mt.UPF from the pseudo table, and replace it with a O.pbe-mt-new.UPF, that is your O.cpi.UPF. Paolo, what do you think? As a side comment - wonderful work. This is really precious. nicola On 6/28/11 3:48 PM, Deyu Lu wrote: > Thank Nicola and Paolo for the reply. I did some further tests. > The oxygen psp (both fhi form and input file) was downloaded from > http://www.abinit.org/downloads/psp-links/gga_fhi. In the previous > test, I converted fhi to UPF directly. Following Nicola's suggestion, > I regenerated the cpi file with 08-O.GGA.ini using fhi98pp. The output > (O.cpi) is converted to UPF using fhi2upf. The mesh of the new psp > (O.cpi.UPF) starts from 7.8125000E-04, the same as 08-O.PBE.fhi.UPF, but > is slightly different from 7.81252980657E-04 in > O.pbe-mt.UPF. The resulting lattice constant is 4.633 A, consistent with what > I found before. > > In the attachment, I include the input/output using O.pbe-mt.UPF (2.d) and > O.cpi.UPF (10.d). > > Best > Deyu -- -- 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
[Pw_forum] q not allowed while using q2r.x
Dear Prof. Giannozzi: Thank you very much for your reply. I have solved the problem in the error of " q not allowed ": Having run q2r.x in MPI mode was one of my mistakes, but the major problem was that I ran ph.x after vc-relax. Since the lattice parameter matrix has been changed after vc-relax, q-vectors were not exact (0,0,0), (0,0,1/3), (0,1/3,1/3) and (1/3,1/3,1/3) for SC structure at q-mesh of 3x3x3. After changing lattice parameter by hand in a new scf calculation, " q not allowed " problem has been overcome. Best Regards. -- GAO Zhe CMC Lab, MSE, SNU, Seoul, S.Korea At 2011-06-27 14:32:13?"Paolo Giannozzi" wrote: > >On Jun 20, 2011, at 2:56 , GAO Zhe wrote: > >> $MPIBIN/mpirun -n 6 q2r.x -npool 2 A0.q2r.out > >you should not run q2r on more than 1 processor > >P. >--- >Paolo Giannozzi, Dept of Chemistry, >Univ. 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 -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20110628/a89d93ed/attachment-0001.htm
[Pw_forum] oxygen pseudopotential in tio2
On Jun 28, 2011, at 3:27 , Deyu Lu wrote: > In the end, I was quite confused about the fact that a very small > change > in the mesh (<5d-3 max at 80 a.u.) can cause a difference in the > lattice > constant by 1%. so am I, but this is exactly what is happening here (I tried with ZrO2). For some reason the radial grid was not written to the O.pbe-mt.UPF file with sufficient accuracy. The current version of the converter from FHI format seems to work properly, though. P. --- Paolo Giannozzi, Dept of Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] including vdwl interactions during phonon calculations
Dear Stefano, Thank you very much for the email. I would need some guidance regarding how to proceed. I went through mm_dispersion.f90 and understood how the forces, energy and stress were calculated. I have been looking at the program flow (calculation and printing of dynamical matrix) but did not get clear idea how to proceed. Couple of queries to start? 1. Should I calculate the london contributions to dynamical matrix separately and add it to actual matrix after that? 2. Where does the response to atomic displacement (as written in the discussion of phonon code) calculated? If so, can we add vdwl response also to the psuedopotential response (with a flag if london=true), and let other programs work as they are to calculate and diagonalize the dynamical matrix? Any help will be appreciated. Best Regards, Vikas On Mon, Jun 27, 2011 at 4:15 PM, Stefano de Gironcoli wrote: > dear Vikas Varshney, > > I think you analyzed correctly the situation. > > london (grimme) correction for vdW is included in the total energy, > force and stress but not for dynamical matrix. > > It should not be too difficult because it is an extra term in the > energy depending explicitly on the atomic positions. > > you could have a look on how this term is computed in ?energy_london, > force_london and stress_london (all contained in > Modules/mm_dispersion.f90) > and work out a similar routine for dynmat_london... > that would be a great contribution to the community. > > stefano > - > Stefano de Gironcoli - SISSA and DEMOCRITOS > > > Quoting Vikas Varshney : > >> Dear QE users, >> I tried looking for answer for this question (the one in the subject) but >> could not find, hence I am asking this. >> >> I wanted to calculate phonon dispersion curves for layered materials like >> MoS2. I have successfully relaxed the crystal structure of both of these >> systems using vc-relax and including vdwl interactions (using .london. flag) >> and got all the relaxed crystal dimensions within 1.5% of experimental >> values. >> >> Now I want to run ph.x to calculate normal modes for different wave vectors. >> However, I could not find, how I can include vdwl interactions in these >> calculations? It is also interesting to note that in ph.x input script, >> there is no need to specify pseudopotential file information. So, I am >> suspecting it is gathering information from certain directories which were >> created during scf run. >> >> In order to test whether vdwl interactions are taken into account in phonon >> calculations implicitly, I ran two phonon cases (in two different >> directories) after successful convergence of two SCF calculations (one >> including .london option and one without including that option). The >> coordinates and cell dimensions for both calculations were identical. The >> initial structure was based on vc-relaxed structure with .london=true was >> from previous vc-relax calculations. >> >> On looking the predicted frequencies, I find that both cases yeilded exactly >> same numbers for frequencies. This is pointing me to believe that while >> calculating dynamical matrix, vdwl interactions are not taken into account >> implicitly. Am I wrong? Is there a way to include such interactions? >> >> In addition, I got one of the 12 predicted frequencies to be -ve (~45 cm-1). >> I am not sure if it is because of non-inclusion of vdwl interactions. I also >> wanted to mention that higher optical modes are predicted very near to >> experimental values (within 10 cm-1) for all IR and Raman active modes. ? I >> have read many such questions before on the forum on this issue (-ve >> frequency) and would be trying different suggestions but I wanted to address >> the issue of inclusion/exclusion of vdwl interactions in phonon calculations >> and how one can you about calculating their contribution towards dynamical >> matrix. >> >> Best Wishes, >> >> Regards, >> Vikas Varshney >> Computational Materials Scientist >> Wright Patterson Air Force Base, Dayton, OH >> >> >> >> Best Regards, >> >> Vikas Varshney >> Computational Research Scientist, >> Wright Patterson Air Force Base, Dayton OH >> > > > > > ? 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 >
[Pw_forum] The issue of k-points in CARTESIAN coordinates obtained by XCrySDen-1.5.24.
Hi Hongsheng,
The difference is 2*pi, I guess it is just a matter of convention.
Regards
jia
On Tue, Jun 28, 2011 at 9:22 AM, Hongsheng Zhao
wrote:
> Dear Prof. Tone and others,
>
> I use pre-compiled xc-1.5.24-linux_x86-semishared.tar.gz on my Debian box.
>
> Now I use the k-path selection function to prepare k-point file used for
> pwscf. ?My system is graphene. ?The graphene.inp file is as follows:
>
> -
> ? ?
> calculation = 'scf'
> prefix='graphene'
> pseudo_dir = './'
> outdir='./'
> tstress=.true.
> tprnfor = .true.
> forc_conv_thr=1.0d-4
> nstep=200
> /
> ? ?
> ibrav=0
> celldm(1)=1.889726
> nat=2
> ntyp=1
> ecutwfc=36
> /
> ? ?
> mixing_beta=0.7
> conv_thr = ?1.0d-8
> electron_maxstep=200
> /
> ? ?
> trust_radius_max=0.2
> /
> ? ?
> cell_dynamics='bfgs'
> /
> ATOMIC_SPECIES
> ? ?C ?12.0110 ? C.UPF
>
> CELL_PARAMETERS (alat)
> ? ?2.1314617179 ? -1.230620 ? ?0.00
> ? ?0.00 ? ?2.461240 ? ?0.00
> ? ?0.00 ? ?0.00 ? 36.918600
>
> ATOMIC_POSITIONS (crystal)
> ?C ? ? ? 0.0 ? ? 0.0 ? ? 0.0
> ?C ? ? ? 0.66671 ? ? 0.5 ? ? 0.0
> K_POINTS {automatic}
> ?4 4 4 ?1 1 1
> -
>
> I select the k-path as M --> G -->K --> M , and then generate the
> corresponding files, i.e., ?graphene.pwscf and supportInfo.kpath.
>
> In the file supportInfo.kpath, you can find the following information:
>
> -
> ? ?Selected k-points in CARTESIAN coordinates:
> ? ? ? 0.23458 ? ?0.0 ? ?0.0 ? ?M
> ? ? ? 0.0 ? ?0.0 ? ?0.0 ? ?G
> ? ? ? 0.23458 ? ?0.13543 ? ?0.0 ? ?K
> ? ? ? 0.23458 ? ?0.0 ? ?0.0 ? ?M
>
> ? ?Selected k-points in crystal coordinates:
> ? ?(with respect to RECIPROCAL-PRIMITIVE vectors)
> ? ? ? 0.5 ? ?0.0 ? ?0.0 ? ?M
> ? ? ? 0.0 ? ?0.0 ? ?0.0 ? ?G
> ? ? ? 0.3 ? ?0.3 ? ?0.0 ? ?K
> ? ? ? 0.5 ? ?0.0 ? ?0.0 ? ?M
>
> ? ?Selected k-points in crystal coordinates:
> ? ?(with respect to RECIPROCAL-CONVENTIONAL vectors)
> ? ? ? 0.5 ? ?0.0 ? ?0.0 ? ?M
> ? ? ? 0.0 ? ?0.0 ? ?0.0 ? ?G
> ? ? ? 0.3 ? ?0.3 ? ?0.0 ? ?K
> ? ? ? 0.5 ? ?0.0 ? ?0.0 ? ?M
> ---
>
> Here, I have some puzzles on the k-points in CARTESIAN coordinates obtained
> by XCrySDen. ?For example, the K point in BZ has the fractional coordinates
> as this: ( 0.3 ? ?0.3 ? ?0.0 ).
>
> And in my case, I've the lattice vectors as follows:
>
> --
> CELL_PARAMETERS (alat)
> ? ?2.1314617179 ? -1.230620 ? ?0.00
> ? ?0.00 ? ?2.461240 ? ?0.00
> ? ?0.00 ? ?0.00 ? 36.918600
> ---
>
> So, I can obtain the reciprocal lattice like this:
>
> B ^ T = 2*Pi* A ^ (-1), ?where, A and B are 3*3 matrix whose column vectors
> ?are corresponding to the real space lattice vectors and reciprocal lattice
> vectors, respectively.
>
> Thus, I obtain B as follows from within matlab:
>
> ?>> ?B= 2*pi*inv([2.1314617179 ? -1.230620 ? ?0.00;
> ? ?0.00 ? ?2.461240 ? ?0.00;
> ? ?0.00 ? ?0.00 ? 36.918600])'
>
> B =
>
> ? ? 2.9478 ? ? ? ? 0 ? ? ? ? 0
> ? ? 1.4739 ? ?2.5529 ? ? ? ? 0
> ? ? ? ? ?0 ? ? ? ? 0 ? ?0.1702
>
> So the CARTESIAN coordinates for K point ( 0.3 ? ?0.3 ? ?0.0 )
> should be:
>
> ?>> [0.3 ? ?0.3 ? ?0.0]*B
>
> ans =
>
> ? ? 1.4739 ? ?0.8510 ? ? ? ? 0
>
> As you can see, your XCrySDen gives the CARTESIAN coordinates for K point (
> 0.3 ? ?0.3 ? ?0.0 ) as follows:
>
> ? ? ? 0.23458 ? ?0.13543 ? ?0.0 ? ?K
>
> I cann't figure out what's the reason. ?Could you please give me some hints
> on this issue?
>
> Attached please find all the files mentioned above.
>
> Regards.
> --
> Hongsheng Zhao
> School of Physics and Electrical Information Science,
> Ningxia University, Yinchuan 750021, China
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>
--
Jia Chen
[Pw_forum] oxygen pseudopotential in tio2
On Jun 28, 2011, at 3:27 , Deyu Lu wrote: > There seems to be a bug in the section of O.pbe-mt.UPF, > where Max angular momentum component is set to 1 instead of 2. this should be correct: the projectors have a maximum angular componente l=1, while l=2 is in the local part only > In the end, I was quite confused about the fact that a very small > change in > the mesh (<5d-3 max at 80 a.u.) can cause a difference in the > lattice constant by 1%. interesting... P. --- Paolo Giannozzi, Dept of Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] oxygen pseudopotential in tio2
Thanks Deyu Lu for this very careful analysis. It looks like the two pseudos are coming from the same source (the FHI fhi98pp repository), but 08-O.PBE.fhi.UPF as a UPF conversion of the abinit PSP library, while O.pbe-mt.UPF as a direct conversion from the fhi98pp output. My first guess is that either 1) the fhi to UPF conversion for O.pbe-mt.UPF was not done properly or 2) the fhi to UPF converter messes up the start of the radial mesh. Would you be so kind to test 1) - i.e. download/compile the fhi code, obtain the TM pseudopotential with their parameters, convert it to UPF, and test? If it comes out right, either the conversion was not done properly or the converter has been fixed. If it comes out wrong, there is a problem with the converter. Very much appreciated, nicola On 6/28/11 2:27 AM, Deyu Lu wrote: > Dear PW developers and users: > I have been doing norm-conserving PSP (PBE) calculations to > study the structure of rutile tio2. During my study, I found the > resulting lattice constant is sensitive to some fine details of > the PSPs I used. Such effect is kind of counter-intuitive. Perhaps > someone with a better understanding can clarify it for me. The story is a bit > long, which I summarize below. Input files and some PSPs are attached. > > All the calculations are carried out on a Linux cluster with QE 4.2.1. > The code is compiled with Intel compiler (ifort) and mvapich2-1.2, > and is linked to the mkl library accompanied with the code. Main > results are verified on a Cray XE6 machine (hopper at NERSC) with the same > version of QE. > > The Ti PBE PSP was generated from an ionic configuration > 3s2 3p6 3d0 4s0, with semi-core included explicitly. A small rcut > (0.9 0.9 1.0 for 3s 3p 3d) was used to ensure a good transferability. > The psp was generated from opium, and the convergence can be > reached at ecutwfn=160 Ry. > > The structure of Rutile TiO2 was calculated using this Ti PSP > and O.pbe-mt.UPF from QE library. The lattice constant 4.587 angstrom > is in excellent agreement with experiment (4.587 and 4.582 angstrom) > but at odds with all the known theoretical results (ultrasoft and paw) in > the literature (4.63 - 4.65). The error is about 1.1%. So our good agreement > seems to be accidental. In order to obtain a better understanding, I > performed the calculations using paw (vasp) and norm-conserving PSP with HGH > (abinit library Theor. Chem. Acc. 114, 145 (2005)) which is known to be very > accurate. Indeed, the results are consistent with literature. > > The 1% difference was later found to be related to the Oxygen PSP. > Different Oxygen PSPs are used in the following tests. > > 1.d: 08-O.PBE.fhi.UPF (abinit PSP library, converted to UPF, lmax=3, local=2) > a=4.633 angstrom > > 2.d: O.pbe-mt.UPF (QE PSP library, lmax=2, local=2) > a=4.587 angstrom > > In order to see if the f channel can cause any difference, 08-O.PBE.fhi.UPF > is modified (08-O.PBE.fake.UPF) by removing f channel and making > corresponding changes in DIJ. > No difference is found as compared to 1.d. > > 6.d: 08-O.PBE.fake.UPF (modified version, lmax=2, local=2) > a=4.633 angstrom > > There seems to be a bug in the section of O.pbe-mt.UPF, where Max > angular momentum component is set to 1 instead of 2. I manually changed it to > 2 (O.pbe-mt.9.UPF), and no difference found in output as compared to 2.d. So > this field is not sensitive in the calculation. > > 9.d: O.pbe-mt.9.UPF (minor modification of O.pbe-mt.UPF) > a=4.587 angstrom > > In the rest of tests, the "Max angular momentum component" is left unchanged. > > To find out the difference between 08-O.PBE.fake.UPF and O.pbe-mt.UPF, I plot > term by term for two PSPs, and the results are shown in the xmgrace plots for > mesh, local, and nonlocal parts of the PSP. The two meshes have the same > size, with a max difference within 5d-3 a.u (mesh.agr). There is no > difference found in local and non-local components of the PSP (local.agr and > nonlocal.agr). In the inset of local.agr, we see that even the small wiggle > at the origin is id > entical. My conclusion is that the two PSPs are literally the same. > > Further tests were done by replace local PP and Beta sections in O.pbe-mt.UPF > one by one by the corresponding section from 08-O.PBE.fake.UPF, and the > difference is negligible as compared to 2.d. > > In the end, I replaced section in O.pbe-mt.UPF with that from > 08-O.PBE.fake.UPF, and kept everything else unchanged, the lattice constant > increased from 4.587 to 4.633. > > 8.d: O.pbe-mt.8.UPF ( section modified) > a=4.633 > > In the end, I was quite confused about the fact that a very small change in > the mesh (<5d-3 max at 80 a.u.) can cause a difference in the lattice > constant by 1%. > > Best > Deyu Lu > > > Deyu Lu > Assistant Physicist, Theory& Computation Group > the Center for Functional
[Pw_forum] Pw_forum Digest, Vol 48, Issue 71
Thank Nicola and Paolo for the reply. I did some further tests. The oxygen psp (both fhi form and input file) was downloaded from http://www.abinit.org/downloads/psp-links/gga_fhi. In the previous test, I converted fhi to UPF directly. Following Nicola's suggestion, I regenerated the cpi file with 08-O.GGA.ini using fhi98pp. The output (O.cpi) is converted to UPF using fhi2upf. The mesh of the new psp (O.cpi.UPF) starts from 7.8125000E-04, the same as 08-O.PBE.fhi.UPF, but is slightly different from 7.81252980657E-04 in O.pbe-mt.UPF. The resulting lattice constant is 4.633 A, consistent with what I found before. In the attachment, I include the input/output using O.pbe-mt.UPF (2.d) and O.cpi.UPF (10.d). Best Deyu > Message: 1 > Date: Tue, 28 Jun 2011 09:31:17 +0200 > From: Paolo Giannozzi > Subject: Re: [Pw_forum] oxygen pseudopotential in tio2 > To: PWSCF Forum > Message-ID: <2A8AABA7-2A96-4B25-93B5-21C3E1FC86D1 at democritos.it> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; > format=flowed > > > On Jun 28, 2011, at 3:27 , Deyu Lu wrote: > > > There seems to be a bug in the > section of O.pbe-mt.UPF, > > where Max angular momentum component is set to 1 > instead of 2. > > this should be correct: the projectors have a maximum > angular? > componente l=1, > while l=2 is in the local part only > > > In the end, I was quite confused about the fact that a > very small? > > change in > > the mesh (<5d-3 max at 80 a.u.) can cause a > difference in the? > > lattice constant by 1%. > > interesting... > > P. > --- > Paolo Giannozzi, Dept of > Chemistry, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > > > > > > -- > > Message: 2 > Date: Tue, 28 Jun 2011 08:46:43 +0100 > From: Nicola Marzari > Subject: Re: [Pw_forum] oxygen pseudopotential in tio2 > To: PWSCF Forum > Cc: Deyu Lu > Message-ID: <4E0986E3.9000605 at materials.ox.ac.uk> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > > > Thanks Deyu Lu for this very careful analysis. > > It looks like the two pseudos are coming from the same > source > (the FHI fhi98pp repository), but 08-O.PBE.fhi.UPF as a UPF > conversion > of the abinit PSP library, while O.pbe-mt.UPF as a direct > conversion > from the fhi98pp output. > > My first guess is that either > > 1) the fhi to UPF conversion for O.pbe-mt.UPF was not done > properly > > or > > 2) the fhi to UPF converter messes up the start of the > radial mesh. > > Would you be so kind to test 1) - i.e. download/compile the > fhi code, > obtain the TM pseudopotential with their parameters, > convert it to > UPF, and test? > > If it comes out right, either the conversion was not done > properly or > the converter has been fixed. If it comes out wrong, there > is a problem > with the converter. > > Very much appreciated, > > ??? ??? ??? > nicola -- next part -- A non-text attachment was scrubbed... Name: output.tar.gz Type: application/x-gzip Size: 70548 bytes Desc: not available Url : http://www.democritos.it/pipermail/pw_forum/attachments/20110628/ea982ac4/attachment-0001.bin
[Pw_forum] phonon calculation
Hi, I want to perform a phonon calculation using QE 4.1.2. The scf calculation runs properly, but when I run ph.x it does not go forward and stuck in this step; Program PHONONv.4.1.2 starts ... Today is 28Jun2011 at 10: 0:21 Parallel version (MPI) Number of processors in use: 16 K-points division: npool =2 R & G space division: proc/pool =8 Ultrasoft (Vanderbilt) Pseudopotentials The ph,in file is fine and runs well on other computres, here is the ph,in: phonons tr2_ph=1.0d-14, prefix='Au', ldisp=.true., nq1=4 , nq2=4 , nq3=4, amass(1)=196.96655, outdir='/home-fs4/hp0070/data-stress/Au/LDA/FccC4.45/phonon/', fildyn='Au.dyn', / Do you have any idea why this happens? any help would be appreciated. thanks a lot --- Mohammad Saghayezhian Computational Condensed Matter Research Lab Physics Department, Isfahan University of Technology, Isfahan, Iran Tel lab: +98 311 391 3731 Fax Office: +98311 391 3746 --- -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20110628/43d7ef75/attachment.htm
