Dear Vahid Askarpour,
currently, I am trying by fixing occupation tetrahedra and fixed also. I'll
update here if everything works fine.
Thank you so much for your response and suggestion.
Thanks and regards,
Poonam Sharma
I think for insulators, occupation =fixed in the scf calculation. The degauss
value is mainly for metals. You are using a broadening of 0.02Ry=0.272eV for a
gap which is only 0.04eV. This broadening will likely result in a metallic DOS,
which is what you are getting. For the nscf/DOS
Dear Expert,
About the first option, I used to confuse to select the correct option for
the occupation, smearing type, and broadening part. In my input file, I
used an 'mv' smearing with a broadening of 0.02 Ry. So either I can reduce
it to 0.01 Ry or I can try any other occupation, like
Thank you for the feedback, Paolo. Can you suggest any way of fixing this?
On Tue, Oct 13, 2020 at 3:10 PM Paolo Giannozzi
wrote:
> If you look at the value of \epsilon you will notice a very large value
> (likely a consequence of the smallness of the gap of InAs). In the force
> constant file,
If you look at the value of \epsilon you will notice a very large value
(likely a consequence of the smallness of the gap of InAs). In the force
constant file, this appears as
Paolo
On Mon, Oct 12, 2020 at 3:53 PM Sheikh Ziauddin Ahmed
wrote:
> Hello
>
> I have been trying to calculate
On 13/10/2020 20:43, Poonam Kaushik wrote:
Dear Expert,
So the only option that I have is to include the complete path and do
the calculation again.
Thank you so much for your suggestion.
Mostly welcome, but you have three options - destiny can be generous
sometimes.
The first option
Dear Expert,
So the only option that I have is to include the complete path and do the
calculation again.
Thank you so much for your suggestion.
Thanks and regards,
Poonam Sharma
-
Poonam Sharma
From the most to the less likely, it could be that your DOS has some
broadening that masks the existence of a small gap, or that the gap
closes across the last two segments of the path that you are missing, or
that you are very unlucky and the band gaps closes at points that do not
lie on
Dear Experts,
I have one query regarding k path selection. After using Kpath finder (
https://www.materialscloud.org/work/tools/seekpath ), i got this type of
k path
G-M-K-G-A-L-H-A|L-M|H-K for my structure. In the calculation, I used, up to
G-M-K-G-A-L-H-A. So, is this ok to select a path up to
Dear users,
Can anyone say how can we do surface hydrogen passivation for 2D
materials in quantum espresso.
Thank you
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
I think the problem (and the fix) is the same as here:
https://gitlab.com/QEF/q-e/-/merge_requests/1069
Paolo
On Tue, Oct 13, 2020 at 2:55 PM Jakob Kraus <
jakob.kr...@physik.tu-freiberg.de> wrote:
> Dear QE community,
>
>
> my phonon calculation for AlN complains about
>
>
> "Error in
Dear Paolo,
Thanks, for your reply, it makes sense to me now.
Abhirup
--
Abhirup Patra
Department of Chemistry
University of Pennsylvania
On Tue, Oct 13, 2020 at 4:04 AM Paolo Giannozzi
wrote:
> QE
Dear QE community,
my phonon calculation for AlN complains about
"Error in routine scale_sym_ops (4): incompatible FFT grid"
, whereas the scf calculation I performed beforehand went through
without any problems.
I've consulted the user guide and tried increasing the cutoffs for
Dear Mohammad,
> There are 4 q points in hp.out:
Ok. I was looking at the old files that you shared and there were 6 q points.
Probably you have changed something in your PW input, and now you have more
symmetries and hence fewer q points.
To solve the convergence problem for the q point
Dear Iurii,
Thanks for your prompt reply.
A google drive link is provided:
https://drive.google.com/file/d/1-wXwPi5t4gSRBAilDT0ym5vOK8vxosif/view?usp=sharing
There are 4 q points in hp.out:
=-
.
.
.
The grid of q-points ( 2,
Dear Mohammad,
> Based on your recommendations, everything went well for q point #3. However,
> q point #4 did not converge. Required converging iterations from q point #1
> to 3 is as following: 45 iterations for q1, 63 iterations for q2, and 51
> iterations for q3. q4 did not converge after
Thanks Paolo, the link is sufficient for me to verify compiler versions.
The compilation error I had is on the file "Modules/input_parameters.f90", but
I've just selected a few files from QE. I think I can solve it by myself now :D
--
--- 连云龙 | Yunlong LIAN ORCID :
On Tue, Oct 13, 2020 at 10:07 AM 连云龙 wrote:
What are the recommended versions ?
there are no recommended versions: nobody has the time to check all gcc
versions. Recent versions should work. Those tested here work for sure:
test-farm.quantum-espresso.org:8010/#/console. The older version for
It's a known problem and has been explained more than once here. If you
want to use symmetry, it is safe to explicitly specify the Bravais lattice
(with the correct "ibrav") and exactly symmetric atomic positions, or
better, space group and Wyckoff positions. You may still provide lattice
vectors
| Note however that gfortran 4.8.3 is very old and may not be able to compile
QE (but it should be recognized by configure)
What are the recommended versions ? I got some mysterious errors in the
compilation ...
--
--- 连云龙 | Yunlong LIAN ORCID :
As long as your cutoffs are sufficiently good to get the desired accuracy
on the targeted properties, there is no problem. The cutoffs suggested in
the PP file are on the safe side and thus quite high, if I remember
correctly.
Paolo
On Mon, Oct 12, 2020 at 2:56 PM ENDALE ABEBE wrote:
> Dear
QE doesn't switch atoms as far as I know. Visualizers occasionally do:
their algorithms sometimes cannot decide whether to visualize an atom or
its periodic image and so you see atoms at the border of a box that
disappear at one side and appear at the other side. If this is the case,
there isn't
Note however that gfortran 4.8.3 is very old and may not be able to compile
QE (but it should be recognized by configure)
Paolo
On Tue, Oct 13, 2020 at 8:53 AM Lorenzo Paulatto wrote:
> You can compile qe 6.6 in exactly the same way as 6.3. If someone else
> did it for you ask him/her for
Dear Lorenzo, could you please also send me the output of compiler versions? I
hope you haven’t close the terminal window yet ...
Sent from my iPhone
> On 13 Oct 2020, at 2:53 PM, Lorenzo Paulatto wrote:
>
> After having purged your "Makefile" (actually a bash script) of all the
>
Many thanks. I have make it. The license of ifort was expired.
Best regards,
LIANG Xiongyi
Department of Materials Science and Engineering
City University of Hongkong
Original message
From: Lorenzo Paulatto
Date: 13/10/2020 14:53 (GMT+08:00)
To:
You can compile qe 6.6 in exactly the same way as 6.3. If someone else
did it for you ask him/her for help.
kind regards
On 10/13/20 5:43 AM, LEUNG Clarence wrote:
I also have mpiifor:
which mpiifort
/opt/intel/compilers_and_libraries_2017.1.132/linux/mpi/intel64/bin/mpiifort
Thanks!
After having purged your "Makefile" (actually a bash script) of all the
erase/copy stuff, it is failing at a completely different point:
|-- compile -
read_cards.f90:46:11:
46 | USE autopilot, ONLY : init_autopilot
| 1
I got the error when I compile a minimal set of f90 source files from QE with
gfortran.
Sorry about the confusing descriptions... Making QE available for Julia is the
motivation for the entire effort.
Sent from my iPhone
> On 13 Oct 2020, at 2:42 PM, Pietro Delugas wrote:
>
>
> sorry
>
sorry
I am getting lost, do you ge the error compiling QE with gfortran or you
get the error using Julia ?
On 13/10/20 04:01, 连云龙 wrote:
thanks for all the quick replies!
I have created a github repo for my project.
https://github.com/algorithmx/QE/
I am trying to break QE into small
Dear Iurii,
Based on your recommendations, everything went well for q point #3.
However, q point #4 did not converge. Required converging iterations from q
point #1 to 3 is as following: 45 iterations for q1, 63 iterations for q2,
and 51 iterations for q3. q4 did not converge after 196
30 matches
Mail list logo
