[Q-e-developers] Help requested.
Paolo Giannozzi
paolo.giannozzi at uniud.it
Sat Mar 5 10:07:18 CET 2011
Dear Sir
first of all: general questions should be sent to the
pw_forum at pwscf.org mailing
lists; specific technical questions (this might actually qualify)
should be sent to the
q-e-developers at qe-forge mailing list. I have written about symmetries
and explained
how they work a diverging number of times and I am a little bit tired
of this subject.
Anyway: are you sure you do not get all the symmetries you should have?
symmetry operations are checked vs the FFT grid ONLY if there are
fractional
translations. Has you system symmetries with "true" fractional
translations? it
seems to me unlikely. Note that if you have a supercell, you have
fractional
translations by definition, but the code recognizes this case and
disables fractional
translations.
If you are sure that the codes excludes bona fide symmetries because
they do not
transform the real-space grid into itself, try to comment out the
check in
PW/symm_base.f90, after the lines
! check that the grid is compatible with the S rotation
The check shouldn't be any longer needed because symmetrization is now
performed in reciprocal space (no warranty) but it is kept because
removing it
would break the phonon code
Paolo
On Mar 5, 2011, at 24:01 , Sandeep Kumar wrote:
> Dear Sir,
> I am a first year graduate student in Department of mechanical
> engineering at MIT. I am using Quantum Espresso suite of codes for
> calculating the strain energy of Al corresponding to various states
> of deformation. I am performing my calculations using primitive
> cell (which has one atom per cell) rather than the conventional
> cubic cell ( which has 4 atoms per cell). Apparently when I deform
> the fcc lattice into a tetragonal one and execute the code, it
> returns me a message that some of the symmetry operations are not
> compatible with the FFT grid. This problem does not arise if I
> perform calculations using conventional cubic cell.
> Of course the calculations do not get interrupted but the number of
> k-points used in the calculations get extremely large and so does
> the time of computation. I have already referred to the
> discussions in PWSCF user's community where it was suggested that
> changing the nr1, nr2, nr3 or cut-off energy would suffice to
> resolve this problem. I have tried hard to get rid of this problem
> by increasing the cut-off energy and k-point mesh but had no
> success. I would be really very very grateful to you if you could
> help me resolve this issue.
> Many thanks
> Sincerely
> Sandeep K. Lahiri
> Department of Mechanical Engineering
> Massachusetts Institute of Technology
> Cambridge, MA
> P.S. My input file looks like this.
> ______________________________________________________________________
> __________________
> &control
> calculation = 'scf'
> restart_mode='from_scratch',
> prefix='W',
> tstress= .true.
> tprnfor= .true.
> pseudo_dir = '/home/sandeep/Calculations/espresso-4.0.5/pseudo',
> outdir= './temp'
> wf_collect=.true.
> /
> &system
> ibrav=0,
> celldm(1)=7.67,
> nat=1,
> ntyp=1,
> ecutwfc =32,
> ecutrho=192,
> occupations="smearing",
> smearing = 'mv',
> degauss=0.04,
> /
> &electrons
> diagonalization='david'
> mixing_mode = 'plain'
> mixing_beta = 0.7
> conv_thr = 1E-08
> /
> ATOMIC_SPECIES
> Al 26 Al.pbe-rrkj.UPF
> ATOMIC_POSITIONS (crystal)
> Al 0.0000000000 0.000000000000000 0.00000000000000
> K_POINTS automatic
> 20 20 20 0 0 0
> CELL_PARAMETERS
> .25000 .70711 0.00000
> 0.00000 .70711 .70711
> .25000 0.00000 .70711
> ----------------------------------------------------------------------
> ----------------------------
>
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
More information about the developers
mailing list