Dear all, I apologize for sending a former e-mail from another account
other than the subscribed one.
So, here is my post again:
I’m having trouble to replicate the result for the raman spectra for some
hybrid perovskite, namely CH3NH3PbI3, a.k.a MAPbI3 (4 MAPbI3 molecules/unit
cell). I'm using
Dear Chi-Ta
> ".cube" shows a new set of cartesian coordinates based on fileout,
> which is different from my original cartesian coordinates.
Check whether the refolding of coordinates into your supercell
possibly made by pw.x or pp.x yielded a different but equivalent set
of cartesian
Dear users ,
I am having a problem in calculating the electron phonon coupling
coefficients for trilayers graphene in ABA stucking, the systeme have
no inversion. The problem is : when ph.x write the
${prefix}_elph.mat.q_${q} files the number of q points in the star do
not include the -q points
Dear Experts,
For the first time I am working on DFT that too by using quantum espresso
software. I am trying to do DFT calculations on MnWO4 bulk materials to
study the magnetic and structural properties using espresso-5.1 version.
With the MnWO4.scf.in file ( see the attachment), I got the
Dear Axel,
Thank you very much for your comments.
You are right. The programmers choose what to do and users is the other
side.
Bests,
mahmoud
-Original Message-
From: Axel Kohlmeyer
To: PWSCF Forum
Date: Tue, 9 Feb 2016 10:37:02 +0100
Hello everyone,
is it somehow possible to use the gipaw module for the calculation of NMR
chemical shifts only on some atoms instead of all atoms in the system?
Thus is there some keyword to restrict the evaluation of the chemical
shifts to specific atoms in order to reduce calculation time?
i) remove Emin and Emax variables, if absent the code automatically sets them
up to the band extrema (this is just to get rid of possible mistakes)
ii) check if in the scf or nscf calculations you have set up an nbnd value
which is too small
iii) What kind of pseudo potentials are you using?
On Tue, Feb 9, 2016 at 10:28 AM, Mahmoud Payami Shabestari
wrote:
> I went through all the "exx_*.f90" routines and it seems the problem was not
> what I mentioned in my last post. However, whatever the cause of the error
> is, it is in these routines (I do not know the exact
I went through all the "exx_*.f90" routines and it seems the problem was not
what I mentioned in my last post. However, whatever the cause of the error
is, it is in these routines (I do not know the exact reason). Maybe there is
some small programming error which is ignored by newer versions of