Re: [QE-users] on the use of tb09 functional from libxc

[José Carlos Conesa]

Hi,

What I could verify is that, in a simple test on rutile TiO2, I obtain 
the same total energy (to within 10**(-7) Ry) with any of these lines in 
the input file:


input_dft='sla+pw+tb09+tb09'

input_dft='pw+pbc+tb09+tb09'

input_dft="noc+nogc+tb09+tb09"

The first case is the one specified in the Modules/funct.f90 file as 
equivalent to input_dft='tb09', the second one corresponds to having gga 
correlation, the last one, to using no correlation at all. One can 
understand this since the said file contains these lines:


    ! special case : TB09 meta-GGA Exc
    else IF ('TB09'.EQ. TRIM(dftout) ) THEN
   dft_defined = set_dft_values(0,0,0,0,0,3)

I think that since the original mBJ functional was defined as including 
LDA correlation, this should be changed. Preferably, by allowing the 
user to specify the type of correlation (s)he desires. I wonder if just 
suppressing in the said file the three lines mentioned above would be 
enough.


Regards,

JC Conesa

El 05/05/2018 a las 10:44, Paolo Giannozzi escribió:
I don't think it is possible right now to use any meta-GGA with 
exchange/correlations/gradient corrections that differ from those 
assumed in the original definition of the meta-GGA functional. 
Meta-GGA follow a different path from all other XC functionals. I hope 
to manage sooner or later to clean up the meta-GGA mess, but cannot 
guarantee anything.


Paolo

On Fri, May 4, 2018 at 6:33 PM, José C. Conesa > wrote:


Hi,

Does this mean that it is not possible to combine tb09 with any
correlation contribution?

José Carlos


El 04/05/2018 a las 17:41, Paolo Giannozzi escribió:

I think that with meta-GGA what is written in the first two
fields is just ignored

Paolo

On Fri, May 4, 2018 at 5:39 PM, José C. Conesa
> wrote:

Dear QE developers,

I wish to use in Quantum Espresso the tb09 potential-only
meta-GGA functional (from Tran & Blaha, PRL 102, 2009,
226401) which is available in libxc. I downloaded the libxc
library and compiled successfully qe-6.2.1 with it. Then I
see in Modules/funct.f90 that the instruction to use this
functional is equivalent to specifying

input_dft="sla+pw+tb09+tb09"

But as far as I know, the tb09 functional gives only the
exchange part, and gives it in full (not as a correction to
another expression for the exchange), while sla is a LDA
exchange form (and pw a LDA correlation form). Should one
conclude that exchange is being introduced twice? And, is a
gradient correction to the correlation term not included?
From these considerations, I would have thought that using
something like

input_dft="pw+pbc+tb09+tb09"

(where I hope that the tb09 exchange functional is not
included twice), i.e. the correlation part of PBE plus the
Tran & Blaha exchange functional, would be the proper way to
proceed.

Can you please comment on this?

I also would add that it would be good to be able to adjust
the A and B parameters of the tb09 functional. This has been
proposed in (Koller, Tran & Blaha, PRB 85, 2012, 155109) to
obtain better bandgaps in certain families of semiconductors.

All the best,

-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. (+34)915854766




Libre de virus. www.avast.com





<#m_3291306830783023308_m_5099655024476259839_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
users mailing list
users@lists.quantum-espresso.org

https://lists.quantum-espresso.org/mailman/listinfo/users





-- 
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



___
users mailing list
users@lists.quantum-espresso.org

https://lists.quantum-espresso.org/mailman/listinfo/users



-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, 

[QE-users] problem compiling qe-6.3

[José Carlos Conesa]

Hi,

I just downloaded the qe-6.3 version just recently made availableand 
tried to compile it. I found the following compilation fatal error:


fox_init_module.f90(22): error #6784: The number of actual arguments 
cannot be greater than the number of dummy arguments. [SETUP_IO]
  CALL setup_io(ERR_CODE = errcodes(1), EOR_CODE = errcodes(2), 
EOF_CODE = errcodes(3))

---^
and compilation aborts.

I am using ifort compiler (v. 15.0.1.133) with mkl libraries and intel 
mpi v. 5.0.2.044


Any help?

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] problem compiling qe-6.3

[José Carlos Conesa]

Dear Paolo,
Indeed this was the problem. I changed the configure options and 
compilation went OK.

Many thanks
El 10/07/2018 a las 21:41, Paolo Giannozzi escribió:
It looks like a mismatch between Modules/fox_init_module.f90 and FoX. 
Please verify that you have compiled the sources of FoX that come with 
QE and that your compiler is pointing (with -I options) to them and 
not to something else.


Paolo

On Tue, Jul 10, 2018 at 6:46 PM, José Carlos Conesa 
mailto:jccon...@icp.csic.es>> wrote:


Hi,

I just downloaded the qe-6.3 version just recently made
availableand tried to compile it. I found the following
compilation fatal error:

fox_init_module.f90(22): error #6784: The number of actual
arguments cannot be greater than the number of dummy arguments.
[SETUP_IO]
  CALL setup_io(ERR_CODE = errcodes(1), EOR_CODE =
errcodes(2), EOF_CODE = errcodes(3))
---^
and compilation aborts.

I am using ifort compiler (v. 15.0.1.133) with mkl libraries and
intel mpi v. 5.0.2.044

Any help?

-- 
José C. Conesa

Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain

<https://maps.google.com/?q=Marie+Curie+2,+Madrid,+Spain=gmail=g>
www.icp.csic.es <http://www.icp.csic.es>
Tel. (+34)915854766

___
users mailing list
users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>




--
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



___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users



--
José C. Conesa
Instituto de Catálisis y Peroleoquímica, CSIC
Campus de Excelencia UAM-CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. +34-915854766   Fax +34-915854760

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [Pw_forum] ibrav = 13 monoclinic-base-centered unique axis

[José Carlos Conesa]

Hi,

Based on this answer I tried to run pw.x (from qe-6.2.1) with these 
lines in input:

...


     ibrav=-13
     space_group=12
     A=14.3100,B=6.3383,C=10.1995,cosAC=-0.70644


I find the following error in stdout:

%%
  Error in routine input (1):
  Input ibrav not compatible with space group number
  %%

  stopping ...

Which is the problem?
Regards,
JC Conesa

El 23/09/2015 a las 13:57, Andrea Dal Corso escribió:
> In recent versions of QE
>
> ibrav=-13
>
> is allowed for b-unique base centered monoclinic.
>
> HTH,
>
> Andrea
>
> On Wed, 2015-09-23 at 11:17 +0200, Ludwig, Stephan wrote:
>> Hello,
>>
>> 
>>
>> I want to work on a salt with space group monoclinic-base centered. This 
>> means ibrav=13 in th input file.
>>
>> For simple monoclinic lattices there are two distinct possibilties to choose 
>> the unique axis (ibrav=12 or -12).
>>
>> Ibrav=13 obviously chooses the c-axis to be the unique one.
>>
>> Is there a possibility to choose the b-axis to be unique?
>>
>>
>>
>> Thanks and regards
>>
>>
>>
>> Stephan
>>
>> 
>>
>> ___
>> Pw_forum mailing list
>> Pw_forum@pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum

-- 
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] version.f90 not found durin installation of qe-6.2

[José Carlos Conesa]

Hi,

I have downloaded qe 6.2, run ./configure and given the make all 
command. Compilation starts and generates in the bin folder the iotk, 
iotk_print_kinds.x and iotk.x executables, but then aborts with the 
message that version.f90 cannot be found. Please help.

Thanks,

-- 
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] version.f90 not found durin installation of qe-6.2

[José Carlos Conesa]

Hi Paolo,
I do not understand what you mean by "unlikely"; this qe-6.2 version is 
available in the normal qe download page. Maybe the -rc suffix means 
pre-release; I did not know it.
In any case, the indication in the link that you give does not suffice: 
at least I could not find any file named version.f90 in the tarball, and 
what should one do otherwise with Modules/Makefile is unclear.
Please tell if one should refrain from using that version while it has 
the -rc suffix.

Regards,
José Carlos
El 05/10/2017 a las 13:58, Paolo Giannozzi escribió:
On Thu, Oct 5, 2017 at 1:43 PM, José Carlos Conesa 
<jccon...@icp.csic.es <mailto:jccon...@icp.csic.es>> wrote:


I have downloaded qe 6.2


unlikely: what is available is a pre-release, for testing

Compilation starts [...] then aborts with the
message that version.f90 cannot be found.


see here: 
http://qe-forge.org/pipermail/pw_forum/2017-September/113895.html 
<http://qe-forge.org/pipermail/pw_forum/2017-September/113895.html>


Paolo

--
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



--
José C. Conesa
Director
Instituto de Catálisis y Peroleoquímica, CSIC
Campus de Excelencia UAM-CSIC
Marie Curie 2, Cantoblanco
28049 Madrid, Spain
Tel. +34-915854766   Fax +34-915854760

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] version.f90 not found durin installation of qe-6.2

[José Carlos Conesa]

Hi Paolo,

El 06/10/2017 a las 10:59, Paolo Giannozzi escribió:

 $ grep finclude make.inc
IFLAGS = -I$(TOPDIR)/include -I$(TOPDIR)/FoX/finclude 
-I../include/ -I/opt/intel/mkl/include


is $(TOPDIR)/FoX/finclude there, and does it contain compiled modules?

I see the cause of this problem. I was using, like for qe-6.1, the 
following call to configure:


./configure --with-scalapack=intel ARCH=x86_64 F90=ifort MPIF90=mpiifort 
LIBDIRS="/opt/intel/composer_xe_2015.1.133/mkl/lib/intel64 
/opt/fftw-3.2.2/lib" IFLAGS="-I/opt/fftw-3.2.2/include -I../include"


This explains that, although $(TOPDIR)/FoX/finclude does contain many 
modules,

$ grep finclude make.inc
gives nothing, as indeed in make.inc I have this:

IFLAGS = -I/opt/fftw-3.2.2/include -I../include

I thus have added -I../FoX/finclude to the configure call and that 
problem disappears.

Now I find a new one, as I get these other errors:

pw_restart_new.f90(18): error #7002: Error in opening the compiled 
module file.  Check INCLUDE paths.   [FOX_WXML]

  USE qes_module
--^
pw_restart_new.f90(142): error #6618: The INTERFACE/CONTAINS stack is 
full. This means that modules are being 'used' in a circular way.   
[QES_LIBS_MODULE]

  ALLOCATE( ngk_g( nkstot ) )
^
pw_restart_new.f90(142): error #6618: The INTERFACE/CONTAINS stack is 
full. This means that modules are being 'used' in a circular way.   
[FOX_WXML]

  ALLOCATE( ngk_g( nkstot ) )
^
pw_restart_new.f90(116): error #7002: Error in opening the compiled 
module file.  Check INCLUDE paths.   [FOX_WXML]
  USE qexsd_input,  ONLY : qexsd_init_k_points_ibz, 
qexsd_init_occupations, qexsd_init_smearing

--^
pw_restart_new.f90(696): error #6618: The INTERFACE/CONTAINS stack is 
full. This means that modules are being 'used' in a circular way.   
[FOX_WXML]

  ierr = 0
^
pw_restart_new.f90(677): error #7002: Error in opening the compiled 
module file.  Check INCLUDE paths.   [FOX_WXML]
  USE qes_libs_module,  ONLY : qes_write_input, 
qes_write_output, qes_write_parallel_info, &

--^

I verified that qes_module.mod does appear in Modules directory. Which 
can be the problem then?

Regards,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] gipaw cannot be compiled in QE 6.2

[José Carlos Conesa]

Hi,

I installed this recent version of QE and, after completing make all, 
when I do make gipaw I find the following:


configure: error: Cannot compile against this version of Quantum-Espresso

What should be done?

Regards,

JC Conesa


El 24/10/2017 a las 16:46, Paolo Giannozzi escribió:
Quantum ESPRESSO v.6.2 is available for download on qe-forge.org 
. A list of main differences with respect to the 
previous version is attached.


Paolo
--
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


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] SternheimerGW cannot be installed in QE 6.2

[José Carlos Conesa]

Hi all,

The information on QE 6.2 states that it can compute GW according to 
SternheimerGW equation. But if I write, as suggested by the Makefile,


make SternheimerGW

the following message appears:

gzip: ../archive/v0.14_qe6.2.tar.gz: not in gzip format

and indeed I can see that the mentioned file is only 130 bytes long. It 
is a text file, and its content is this one:


You are being href="https://codeload.github.com/QEF/SternheimerGW/tar.gz/v0.14_qe6.2;>redirected.[jcconesa@trueno-login00 
archive]$ ^C


What should be done?
Regards,
J.C. Conesa

El 24/10/2017 a las 16:46, Paolo Giannozzi escribió:
Quantum ESPRESSO v.6.2 is available for download on qe-forge.org 
. A list of main differences with respect to the 
previous version is attached.


Paolo
--
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


--
José C. Conesa
Director
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [QE-users] Crystallographic group determination

[José Carlos Conesa]

Hi,

I'm not sure to understand your question, but if what you mean is that 
the primitive cell of Ga2O3 has all angles different from 90º, this is 
the normal situation for any monoclinic centered lattice. In fact there 
is still symmetry there; you will see that two of the primitive unit 
cell length parameters coincide, as well as two of the angles. This is 
due to the presence of a symmetry plane.


Besides this, you should note that even a fully triclinic cell is not 
necessarily of space group P1; it might be also group P-1 (group number 
2) if it has an inversion center of symmetry.


All the best,

JC Conesa

El 01/04/2019 a las 4:18, Ankit Sharma escribió:

Hi,
Thank you very much for the reply Dr. Conesa.
As a follow up question, is it a convention to represent the symmetry 
of the primitive unit cell as that of the conventional cell because by 
looking at the crystal structure of the primitive unit cell for the 
above mentioned system i.e Gallium Oxide, it appears to be triclinic 
and hence the P1 symmetry.


Thank You,
Ankit Sharma
University at Buffalo

 
	Virus-free. www.avg.com 
 




On Sun, Mar 31, 2019 at 12:55 PM Ankit Sharma > wrote:


Hi,
I am working with Gallium Oxide which has a 20 atom conventional
cell with the space group of *C2/m *and a 10 atom primitive cell
with space group of *P1 *(materials project):
https://materialsproject.org/materials/mp-886/#.

When I run scf calculations on conventional cell the output
clearly states as *C2/m *symmetry, but for the primitive cell too,
the output is again *C2/m*.
I am unable to figure out the reason for it. Am I missing
something? Any help in this regard will be greatly appreciated.
Attached is the cif file from the materials project for reference
for both the conventional and the primitive unit cells and the
input and output files for the fake run to determine the symmetry.

Thank You,
Ankit Sharma
University at Buffalo


___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] using hybrid functional with vcut

[José Carlos Conesa]

Dear colleagues,

I am carrying out HSE calculations with a unit cell that has rather 
noncubic shape. Following the advice of the manual I use therefore 
exxdiv_treatment='vcut_ws'; but I have no idea on the value that I 
should use for ecutvcut. Is there any guide? Should it depend on the 
unit cell dimensions, on the type of pseudopotential, on the ecutwfc 
value? Please give some hint on the good way to estimate the value of 
that parameter.


All the best,

JC Conesa

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Tran-Blaha modified Becke-Johnson potential (TB-mBJ)

[José Carlos Conesa]

Hi,

It can be done, supposedly, using libxc (see É. Germaneau et al. Comp. 
Phys. Commun. 184 (2013) 1697). It requires that QE is compiled 
including -D__LIBXC  in DFLAGS; then one must include "input_dft = 
'tb09' " in the input to QE.


But note that this is an exchange-only functional; how to handle the 
correlation part is not clear. Also, this functional was developed to 
work with the Wien2k program, which is an all-electron code; it is not 
clear if it can give good results when using pseudopotentials or PAW 
functions.


Al the best,

José Carlos Conesa

El 25/01/2019 a las 12:10, Anibal Bezerra escribió:

Dear Quantum Espresso experts

Is there any implementation of Tran-Blaha modified Becke-Johnson 
potential (TB-mBJ) on Quantum Espresso?


Thanks a Lot!!

Em sex, 25 de jan de 2019 às 09:01, 
<mailto:users-requ...@lists.quantum-espresso.org>> escreveu:


Send users mailing list submissions to
users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.quantum-espresso.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-requ...@lists.quantum-espresso.org
<mailto:users-requ...@lists.quantum-espresso.org>

You can reach the person managing the list at
users-ow...@lists.quantum-espresso.org
<mailto:users-ow...@lists.quantum-espresso.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Tutorial on writing reproducible workflows for computational
      materials science using AiiDA (Leopold Talirz)


--

Message: 1
Date: Thu, 24 Jan 2019 19:15:46 +0100
From: Leopold Talirz mailto:leopold.tal...@gmail.com>>
To: users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
Subject: [QE-users] Tutorial on writing reproducible workflows for
        computational materials science using AiiDA
Message-ID:
       
mailto:cajnv91hmcxb5g1kapb8abwxbt2k56vqmshwjfvqjzmdq5ob...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Dear mailing list,

we'll be hosting a tutorial on writing reproducible workflows for
computational materials science  from May 21st, 2019 (9:00) until
May 24th,
2019 (13:00) at EPFL, Lausanne, Switzerland.

This 3.5-day tutorial is designed to get Master students, PhD
students and
Postdocs from the field of computational materials science started
with
writing reproducible workflows. Participants will be introduced to the
state of the art in workflow management and high-throughput
computations by
experts in the field, and gain in-depth hands-on experience using
a tool
that they can directly apply to their own research.

Our tool of choice is the AiiDA framework (see aiida.net
<http://aiida.net>) for workflow
management and provenance tracking, which is backed by a significant
community of users and developers, and has interfaces to more than 20
materials science codes (see plugin registry), including to the ab
initio
codes Quantum ESPRESSO, VASP, cp2k, Castep, Siesta, Fleur,
Crystal, NWChem,
Wannier90, and Yambo. AiiDA?s permissive open source license (MIT)
enables
participants to use it both in academic and commercial settings.
By virtue
of its general design and flexible plugin system, AiiDA is easily
extended
to new codes and new use cases.

For more information, please head over to the tutorial web site:
http://www.aiida.net/news/tutorial-writing-reproducible-workflows/

Looking forward to meeting you in Lausanne!
Leopold
-- next part --
An HTML attachment was scrubbed...
URL:

<http://lists.quantum-espresso.org/pipermail/users/attachments/20190124/e1a8e778/attachment-0001.html>

--

Subject: Digest Footer

___
users mailing list
users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users

--

End of users Digest, Vol 138, Issue 24
**


___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Structure optimization using rvv10-scan

[José Carlos Conesa]

Hi,

I meant, including stress. But if it is as slow as EXX I wonder if it is 
worthwhile...


JC

El 06/06/2019 a las 18:02, Giuseppe Mattioli escribió:


Dear José
I do not know about rvv10, but spin-polarized SCAN (and at least plus 
dft-d2 for sure) is implemented in pw.x AFAIK. In my tests it was 
quite stable but as slow as EXX, anyway...

HTH
Giuseppe


José Carlos Conesa  ha scritto:


Hi,

Are there plans to implement in qe any meta-GGA (or at least 
rvv10-scan) for the spin-polarized case?


José Carlos

El 26/04/2019 a las 22:12, Paolo Giannozzi escribió:
Correcting myself: stress for meta-GGA is implemented, but only in 
the spin-unpolarized case


Paolo

On Thu, Apr 25, 2019 at 8:48 AM Paolo Giannozzi 
mailto:p.gianno...@gmail.com>> wrote:


   I am not sure that the calculation of stress is implemented with
   meta-GGA.

   SCAN behaves better than other meta-GGA, but still it is
   numerically unstable. See for instance here:
   https://gitlab.com/QEF/q-e/issues/32. Before trying difficult
   calculations with SCAN you should verify whether you can do simple
   ones.

   Paolo


   On Sat, Apr 20, 2019 at 3:33 AM Giovani Rech
   mailto:gio.pi.r...@gmail.com>> wrote:

   Hello all,

   Have anyone tried structure optimization using rvv10-scan?

   I'm trying to optimize a structure (graphite) at 0.0 kbar
   taking into account van der Waals interactions. For such, I'm
   using the SCAN+rVV10 by setting "input_dft = 'rvv10-scan'".
   What I'm getting as a result makes no sense, with unreasonable
   pressures. Here's a plot of the pressure and volume as a
   function of optimization step:
   image.png

   When I got this values I was using version 6.4.0 and then
   tried again with 6.3 and finally with the latest version,
   6.4.1, and got the same values (plotted above). Here's the
   input that I used:

   
                    title = "graphite_rvv10_vcrelax" ,
              calculation = 'vc-relax' ,
             restart_mode = "from_scratch" ,
                   outdir = "./" ,
               pseudo_dir = 
"/home/giovani/graphite/pseudo" ,

                   prefix = "gC" ,
                  disk_io = 'default' ,
                verbosity = 'default' ,
            etot_conv_thr = 1.0D-4 ,
            forc_conv_thr = 1.0D-3 ,
                    nstep = 400 ,
                  tstress = .true. ,
                  tprnfor = .true. ,
    /
    
                        A = 2.47000e+00 ,
                        C = 8.68000e+00 ,
                      nat = 4,
                     ntyp = 1,
                  ecutwfc = 80 ,
                  ecutrho = 320 ,
                input_dft = 'rvv10-scan' ,
                    ibrav = 4 ,
    /
    
         electron_maxstep = 200,
                 conv_thr = 1.0e-06 ,
              startingpot = "atomic" ,
              startingwfc = 'atomic' ,
              mixing_mode = "plain" ,
              mixing_beta = 7.0e-01 ,
              mixing_ndim = 8,
          diagonalization = 'david' ,
           diago_thr_init = 1e-4 ,
    /
    
             ion_dynamics = 'bfgs' ,
            ion_positions = 'from_input' ,
                  upscale = 100 ,
         trust_radius_max = 1.0D-3 ,
    /
    
            cell_dynamics = 'bfgs' ,
                    press = 0.0 ,
           press_conv_thr = 0.05 ,
              cell_factor = 1.2 ,
    /
   ATOMIC_SPECIES
   C  12.0107 C.SR.ONCVPSP.PBEsol.stringent.upf
   ATOMIC_POSITIONS crystal
   C 0.00 0.00 0.0
   C 1/3          2/3          0.0
   C 1/3          2/3          1/2
   C 2/3          1/3          1/2
   K_POINTS automatic
     6 6 2   0 0 0 I then tried the same 
optimization using PBE, by just

   commenting the 'input_dft' line, and got values of both
   pressure and volume converging to fairly reasonable values (as
   plotted below) which makes me think that the problem might be
   with the rVV10-scan option. Have anyone else had this kind of
   problem? Any ideas on how this could be fixed?
   image.png

   Also, when testing and comparing the results of both
   approaches with verbosity=high to inve

[QE-users] use of libxc functional

[José Carlos Conesa]

Dear all,

I wish to try in qe the functional HLE17 which is included in libxc 
(with the name MGGA_XC_HLE17); but I do not see any reference to it in 
the Modules/funct.f90 file. Would this be possible?


Regards,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] forcing Sn(iv) or Sn(0) charges in a MASnI3 crystal

[José Carlos Conesa]

Hi,

Most probably the proper way to do this change in Sn redox state is to 
add or suppress some atom in the lattice, or change it for an ion having 
naturally another valence; this is surely the way in which the mentioned 
degradation proceeds. Note also that the location of the modified charge 
may depend on where that modified atom position lies. Now, since the 
valence band of MASnI3 is made mainly by iodine p orbitals, while the Sn 
s levels lie much lower, any attempt of increasing the charge in Sn is 
likely to deplete mainly the population of those iodine orbitals, not of 
tin. Since the conduction band is formed mainly by Sn p orbitals it may 
be easier to add electrons to Sn, for example by substituting some of 
its atoms by e.g. In which will probably get a (3+) redox state.


Good luck.

José C. Conesa

El 24/04/2019 a las 6:27, JULIEN, CLAUDE, PIERRE BARBAUD escribió:


Dear users,

I am working on a MASnI3 crystal. In this structure, the Sn can 
usually be considered as a Sn2+ cation. I ran some calculations on the 
system, and performed a Bader charge analysis on an all-electron paw 
charge density. It seems to confirm that the tin is in Sn(2) 
configuration with bader charge 48.3 instead of 50 (this is, by the 
way, inconsistent with the results of Lowdin analysis as implemented 
in projwfc.x, which gives pretty much the full 4d10 5s2 5p2 orbitals 
of Sn(0) ).


So everything is as expected so far (from the Bader point of view at 
least). However, I would like to model a MASnI3 with a “defect” 
consisting of an “oxidized or reduced” tin atom given by Sn(iv) or 
Sn(0) in this material. Indeed, it was reported /in J. Mater. Chem. A, 
2018,6, 21389-21395/ that some degradation mechanisms can lead to the 
presence of such states, and I want to explore their consequence on 
the material properties.


However, I am not sure how to tackle this. My first idea was that I 
probably needed to create a pseudopotential with 2 missing or 
additional valence electrons. But on second thought, this method might 
be valid if we have missing core electrons, but not for valence. I 
highly doubt that  it would give me the expected result once I place 
it in the crystal lattice, given that there is really no reason for 
those additional electrons to gently “stay on their starting atom”, so 
to speak.


So is there a reliable method to study such a system by “forcing” an 
oxidization state for an atom in a crystal ? This task seems to be 
made difficult by the very subjective definition of an “atomic charge” 
in the framework of quantum mechanics and DFT…


Thanks in advance

Julien


___
Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Madrid, Spain
www.icp.csic.es
Tel. (+34)915854766

___
Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Odd number of electrons yields even total magnetization

[José Carlos Conesa Cegarra]

Hi,

Sodium metal has an odd number of electrons per primitive unit cell 
(which contains a single atom), and however is nonmagnetic. The same 
applies to aluminum. This is the result of having a large overlap 
between orbitals, making the (in principle) spin up and spin down energy 
separation much smaller than the bandwidth so that spin up and down 
electrons are equaled in population. Did you verify whether this is your 
case?


Regards,

José Carlos

El 16/07/2019 a las 15:34, Ayestaran Latorre, Carlos escribió:

Hi,

I have a system consistent of a diamond slab with a boron 
substitutional defect, an adsorbed hydroxyl and an adsorbed hydrogen 
on the surface. The system has an odd number of electrons (487) and I 
run a spin polarized (nspin=2) structural relaxation (see attached). 
One would expect an odd value for the total magnetization, but the it 
quickly converges to zero.


I assumed this would be a side effect of smearing allowing partial 
electronic occupations (I employed gaussian smearing with 
degauss=0.02). I tried lowering the smearing value down to 0.001, both 
for gaussian and mv smearing, but only managed to get total 
magnetization ~ 0.3 Bohr mag/cell in both cases. Fixing 
tot_magnetization=1, however, yields a noticeably higher final energy 
(~0.3 eV).


When I run a structural relaxation on a similar system (with an 
adsorbed H2O molecule instead of the hydroxyl+hydrogen fragments), the 
total magnetization satisfyingly reaches 1 Bohr mag/cell rather 
quickly. Other combinations (for example, without the H2O molecule at 
all) also give total magnetization values that don't match the 
even/odd number of electrons.


Regards,
Carlos Ayestaran Latorre




___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] weird errors when linking with libxc

[José Carlos Conesa Cegarra]

Dear Paolo,

El 03/03/2019 a las 8:52, Paolo Giannozzi escribió:
With libxc only a few functionals - those "(with libxc)" and a few 
others - currently work.


Paolo


What does "(with libxc)" mean here? I cannot find this expression in 
parentheses in any of the QE documents.


In any case, and assuming that libxc has been linked with QE: which is 
the proper way to tell QE that it should use one of the functionals in 
libxc? The documentation coming with libxc gives all functionals with 
uppercase letters, and in many cases there are different names for 
exchange and for correlation functionals (respectively -X- and -C-) 
which are not always reflected in those including both exchange and 
correlation (labeled -XC-). Furthermore, there are "kinetic" functionals 
(labeled -K-).


How should all this be handled? Can one give to the input_dft key only 
functionals of the XC class? What to do with the kinetic functionals? 
And should one put the functionals in uppercase or lowercase letters? On 
the other hand, is it already possible to use some meta-GGA, and if so 
with which type of pseudopotential? Of course I know that not all 
functionals in libxc are compatible with QE. Maybe the only way to 
verify is by trial and error...


Best regards,

José Carlos

--

José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Campus de Cantoblanco
Tel. 915854766
Madrid, Spain

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] input file format for earlier QE versions

[José Carlos Conesa Cegarra]

Hi,

I am interested in some earlier QE versions, for which the detailed 
instructions for the input files (e.g. INPUT_PW) existed only in the 
.def format. How can one transform this format into an easier to handle 
one, like .html or .txt?


Thanks in advance,

--
José C. Conesa
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Campus de Cantoblanco
Tel. 915854766
Madrid, Spain

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] forcing cubic symmetry for a slab

[José Carlos Conesa Cegarra]

Dear Julien,

A slab can never be cubic. At most it can be forced to remain 
tetragonal. But I see that your perovskite contains formamidinium 
cations. Even if you force the dimensions of the bulk cell to remain 
cubic, the internal symmetry after relaxation will not be cubic; those 
organic cations lack threefold symmetry, which is the condition for a 
structure to be cubic by symmetry. This said, a correct arrangement of 
the formamidinium ions might allow having tetragonal symmetry, both in 
the bulk and in the slab.


José C. Conesa

El 21/02/2020 a las 13:13, Julien Barbaud escribió:


Dear users,


I am trying to simulate the surface of a perovskite. If I let vc-relax 
do its job on my system, it ends up yielding  a monoclinic unit cell. 
However, the phase of interest for my purposes has a cubic symmetry 
(actually becomes stable only at at higher temperatures). When it 
comes to bulk calculations, this is no problem, because we can easily 
constrain the system to a cubic symmetry and let it relax (constrained 
vc-relax, or Birch fit method). And I do get very good agreement with 
experimental lattice constants.


When I try to simulate a slab of a few atomic layers, however, the 
vacuum thickness left in the unit cell allows for one more degree of 
freedom for the slab. This results in my atomic slab "tilting" during 
the relax calculation, effectively mimicking the monoclinic result 
(without the actual fictitious "slab cell" changing, of course). I am 
afraid this description might not be clear, so I attached an 
illustration of the problem I get after a relax run on an initially 
cubic slab.


My question boils down to this:*Is there a good method force a slab to 
remain cubic, even though it has this additional freedom?*


This sounds like a basic question, but I couldn't find an answer so 
far. I thought of limiting the relaxation the the z-axis only, but I 
believe that would not be satisfying for the physics of my system 
(mostly because my material is made of organic cations encaged in an 
inorganic framework, and the orientation/rotation of those cations 
usually are relevant. If I don't allow any movement in the x-y 
directions, I won't be able to observe potential re-orientation of the 
cations at the surface)


Let me know if you need any more information!


Thanks for your attention,

Julien


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie 2, Campus de Cantoblanco
Tel. 915854766
Madrid, Spain

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] problem with number of atoms in pw.x

[José Carlos Conesa Cegarra]

Dear all,

I have found a problem with the number of atoms resulting in a 
computation with pw.x. The essentials of the geometry specification are:



  space_group=155, rhombohedral=.TRUE.
  A=8.7018, B=8.7018, C=8.7018
  cosAB=-0.0032742, cosAC=-0.0032742, cosBC=-0.0032742
  nat=13, ntyp=4
...

/

ATOMIC_POSITIONS crystal_sg
V    0.0    0.0    0.0
Ge  -0.75399   -0.99800   -0.74920
N   -0.73084   -0.51728   -0.00123
N   -0.01635   -0.01149   -0.23613
N   -0.52047   -0.23372   -0.50080
N   -0.22951   -0.73368   -0.74864
N   -0.26226   -0.48504   -0.98625
Sn  -0.12491   -0.62544   -0.12283
Ge   0.0   -0.49511   -0.50488
Ge  -0.5   -0.75534   -0.24466
Sn  -0.5   -0.24993   -0.75007
N   -0.76700   -0.76700   -0.76700
Sn  -0.62767   -0.62767   -0.62767

With this input I expect to have 56 atoms, as corresponds to a V-doped 
(Ge,Sn) spinel nitride having almost the same number of Ge and Sn atoms 
(in fact, there is one Sn atom less) as I have verified independently. 
However, I obtain at the beginning of the pw.x calculation the following 
list of atoms:


 site n. atom  positions (alat units)
 1   V   tau(   1) = (   0.000   0.000 0.000  )
 2   Ge  tau(   2) = (  -0.0033926  -0.2015179 0.2870436  )
 3   Ge  tau(   3) = (   0.1762159   0.0978209 0.2870436  )
 4   Ge  tau(   4) = (  -0.1728234   0.1036970 0.2870436  )
 5   Ge  tau(   5) = (  -0.0033926   0.2015179 1.4393268  )
 6   Ge  tau(   6) = (   0.1762159  -0.0978209 1.4393268  )
 7   Ge  tau(   7) = (  -0.1728234  -0.1036970 1.4393268  )
 8   N   tau(   8) = (  -0.5167561  -0.1236930 1.0074235  )
 9   N   tau(   9) = (   0.3654993  -0.3856774 1.0074235  )
    10   N   tau(  10) = (   0.1512567   0.5093704 1.0074235  )
    11   N   tau(  11) = (  -0.5167561   0.1236930 0.7189470  )
    12   N   tau(  12) = (   0.3654993   0.3856774 0.7189470  )
    13   N   tau(  13) = (   0.1512567  -0.5093704 0.7189470  )
    14   N   tau(  14) = (   0.1556621   0.0938462 1.5744671  )
    15   N   tau(  15) = (  -0.1591043   0.0878842 1.5744671  )
    16   N   tau(  16) = (   0.0034422  -0.1817305 1.5744671  )
    17   N   tau(  17) = (   0.1556621  -0.0938462 0.1519033  )
    18   N   tau(  18) = (  -0.1591043  -0.0878842 0.1519033  )
    19   N   tau(  19) = (   0.0034422   0.1817305 0.1519033  )
    20   N   tau(  20) = (  -0.0139315   0.2264700 1.0041779  )
    21   N   tau(  21) = (  -0.1891630  -0.1253001 1.0041779  )
    22   N   tau(  22) = (   0.2030945  -0.1011699 1.0041779  )
    23   N   tau(  23) = (  -0.0139315  -0.2264700 0.7221925  )
    24   N   tau(  24) = (  -0.1891630   0.1253001 0.7221925  )
    25   N   tau(  25) = (   0.2030945   0.1011699 0.7221925  )
    26   N   tau(  26) = (   0.3676808  -0.2000458 0.7412862  )
    27   N   tau(  27) = (  -0.0105956   0.4184438 0.7412862  )
    28   N   tau(  28) = (  -0.3570852  -0.2183980 0.7412862  )
    29   N   tau(  29) = (   0.3676808   0.2000458 0.9850842  )
    30   N   tau(  30) = (  -0.0105956  -0.4184438 0.9850842  )
    31   N   tau(  31) = (  -0.3570852   0.2183980 0.9850842  )
    32   N   tau(  32) = (   0.5127756   0.1138545 0.7287873  )
    33   N   tau(  33) = (  -0.3549887   0.3871495 0.7287873  )
    34   N   tau(  34) = (  -0.1577869  -0.5010040 0.7287873  )
    35   N   tau(  35) = (   0.5127756  -0.1138545 0.9975831  )
    36   N   tau(  36) = (  -0.3549887  -0.3871495 0.9975831  )
    37   N   tau(  37) = (  -0.1577869   0.5010040 0.9975831  )
    38   Sn  tau(  38) = (  -0.0014732  -0.4102001 1.2238930  )
    39   Sn  tau(  39) = (   0.3559803   0.2038242 1.2238930  )
    40   Sn  tau(  40) = (  -0.3545071   0.2063759 1.2238930  )
    41   Sn  tau(  41) = (  -0.0014732   0.4102001 0.5024774  )
    42   Sn  tau(  42) = (   0.3559803  -0.2038242 0.5024774  )
    43   Sn  tau(  43) = (  -0.3545071  -0.2063759 0.5024774  )
    44   Ge  tau(  44) = (  -0.3506754   0.2104528 0.5754626  )
    45   Ge  tau(  45) = (  -0.0069197  -0.4089202 0.5754626  )
    46   Ge  tau(  46) = (   0.3575951   0.1984674 0.5754626  )
    47   Ge  tau(  47) = (   0.3575880   0.1984633 0.5754510  )
    48   Ge  tau(  48) = (  -0.0069197  -0.4089120 0.5754510  )
    49   Ge  tau(  49) = (  -0.3506683   0.2104487 0.5754510  )
    50   Ge  tau(  50) = (  -0.1808480   0.3132379 

Re: [QE-users] problem with hq.x

[José Carlos Conesa Cegarra]

Dear Timrov,

Thanks for the clarification. I thought that it was enough specifying 
Hubbard_U(*) and putting the atom types involved in first place.  And 
it's true, the Warning message mentions ATOMIC_POSITIONS - I should have 
paid better attention to it. The reference to forrtl file 0 did 
completely upset me.


And yes, I want to put U also on the N atom. With the said composition, 
Cu would be in (+4) redox state, which is nearly impossible; it is 
likely that there will be holes in some of the N atoms. I know of some 
other cases in which U values are assigned to the N atom, even if it is 
seemingly of nitride type.


Thanks again,

José C. Conesa


El 04/08/2020 a las 17:24, Timrov Iurii escribió:


Dear José,


The code is called "hp.x" and not "hq.x" - there is a mistake in the 
title.



> WARNING! All Hubbard atoms must be listed first in the
> ATOMIC_POSITIONS card of PWscf


This message explains what is the problem.


In your case you put Hubbard U on Cu and N (do you really want to put 
U on N?), so all Cu and N atoms must be listed first in the 
ATOMIC_POSITIONScard.



HTH


Cheers,

Iurii


--
Dr. Iurii Timrov
Postdoctoral Researcher
STI - IMX - THEOSand NCCR - MARVEL
Swiss Federal Institute of Technology Lausanne (EPFL)
CH-1015 Lausanne, Switzerland
+41 21 69 34 881
http://people.epfl.ch/265334

*From:* users  on behalf of 
José Carlos Conesa Cegarra 

*Sent:* Tuesday, August 4, 2020 5:02:06 PM
*To:* users@lists.quantum-espresso.org
*Subject:* [QE-users] problem with hq.x
Dear colleagues,

I have found a problem when running hp.x after a pw.x calculation on a
nitride. The input to pw.x was the following:




    title = 'calc CuGeSnN4'
    calculation = 'scf'
    restart_mode = 'from_scratch'
    prefix = 'CuGeSnN4'
    outdir = './tmp'
    etot_conv_thr = 1.0D-5
    pseudo_dir = '..'
/


    space_group = 47
    A=4.3628, B=4.1528, C=4.3120
    nat= 7, ntyp= 4
    ecutwfc = 50.0
    nspin = 2
    occupations ='smearing'
    degauss= 0.003
    starting_magnetization(1)=1
    lda_plus_u = .TRUE.
    Hubbard_U(1)=0.01
    Hubbard_U(2)=0.01
/


 diagonalization='david'
 electron_maxstep = 100
 mixing_mode = 'plain'
 mixing_beta = 0.7
 conv_thr =  1.0d-8
/

ATOMIC_SPECIES
   Cu  63.5    Cu_pbe_v1.2.uspp.F.UPF
    N  14.0    N.pbe.theos.UPF
   Ge  72.6    Ge.pbe-dn-kjpaw_psl.1.0.0.UPF
   Sn 118.7    Sn_pbe_v1.uspp.F.UPF

ATOMIC_POSITIONS crystal_sg
Ge   0.5    0.5    0.0
Cu   0.5    0.0    0.5
Sn   0.0    0.5    0.5
N    0.5    0.5    0.5
N    0.5    0.0    0.0
N    0.0    0.5    0.0
N    0.0    0.0    0.5

K_POINTS  automatic

    6  6  6   0 0 0


The run proceeded seemingly smoothly. Then I undertook a hp.x
calculation using the following input:




   prefix = 'CuGeSnN4'
   outdir = './tmp'
   iverbosity = 2
   nq1 = 4, nq2 = 4, nq3 = 4
/


and found the following result in stderr:

forrtl: Operation not permitted   (repeated as many times as cores were
used)

and

forrtl: severe (28): CLOSE error, unit 0, file "Unknown"
followed by several references on errors in hp.x (all these lines
repeated as well as many times as cores were used)

The output of hp.x just contained at the end this line:

  WARNING! All Hubbard atoms must be listed first in the
ATOMIC_POSITIONS card of PWscf

But since this was the case I do not think that this may be the cause of
the problem.

I have been told that unit 0 is stderr; but how can this be, since these
lines appeared in the stderr output itself? I have been using qe-6.5
(for both pw.x and hp.x) and the SLURM queuing system

Please give advice.

Regards,

--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX 
(www.max-centre.eu/quantum-espresso 
<http://www.max-centre.eu/quantum-espresso>)

users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] NC pseudo for Pb with spin-orbit

[José Carlos Conesa Cegarra]

Hi all,

Could anyone provide a norm-conserving pseudopotential for Pb which has 
been computed including spinorbit coupling?


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] NC pseudo for Pb with spin-orbit

[José Carlos Conesa Cegarra]

Many thanks, Giuseppe. In fact I have downloaded the complete 
sg15_oncv_upf_2020-02-06.tar.gz file, as I might need other pseudos with 
spin-orbit


José C. Conesa

El 09/08/2020 a las 13:34, Giuseppe Mattioli escribió:


Dear José
You may try here, FR stands for "fully relativistic"

http://www.quantum-simulation.org/potentials/sg15_oncv/upf/

HTH
Giuseppe

Quoting José Carlos Conesa Cegarra :


Hi all,

Could anyone provide a norm-conserving pseudopotential for Pb which 
has been computed including spinorbit coupling?


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX 
(www.max-centre.eu/quantum-espresso)

users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users




GIUSEPPE MATTIOLI
CNR - ISTITUTO DI STRUTTURA DELLA MATERIA
Via Salaria Km 29,300 - C.P. 10
I-00015 - Monterotondo Scalo (RM)
Mob (*preferred*) +39 373 7305625
Tel + 39 06 90672342 - Fax +39 06 90672316
E-mail: 

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] problem with hq.x

[José Carlos Conesa Cegarra]

Dear colleagues,

I have found a problem when running hp.x after a pw.x calculation on a 
nitride. The input to pw.x was the following:





   title = 'calc CuGeSnN4'
   calculation = 'scf'
   restart_mode = 'from_scratch'
   prefix = 'CuGeSnN4'
   outdir = './tmp'
   etot_conv_thr = 1.0D-5
   pseudo_dir = '..'
/


   space_group = 47
   A=4.3628, B=4.1528, C=4.3120
   nat= 7, ntyp= 4
   ecutwfc = 50.0
   nspin = 2
   occupations ='smearing'
   degauss= 0.003
   starting_magnetization(1)=1
   lda_plus_u = .TRUE.
   Hubbard_U(1)=0.01
   Hubbard_U(2)=0.01
/


    diagonalization='david'
    electron_maxstep = 100
    mixing_mode = 'plain'
    mixing_beta = 0.7
    conv_thr =  1.0d-8
/

ATOMIC_SPECIES
  Cu  63.5    Cu_pbe_v1.2.uspp.F.UPF
   N  14.0    N.pbe.theos.UPF
  Ge  72.6    Ge.pbe-dn-kjpaw_psl.1.0.0.UPF
  Sn 118.7    Sn_pbe_v1.uspp.F.UPF

ATOMIC_POSITIONS crystal_sg
Ge   0.5    0.5    0.0
Cu   0.5    0.0    0.5
Sn   0.0    0.5    0.5
N    0.5    0.5    0.5
N    0.5    0.0    0.0
N    0.0    0.5    0.0
N    0.0    0.0    0.5

K_POINTS  automatic

   6  6  6   0 0 0


The run proceeded seemingly smoothly. Then I undertook a hp.x 
calculation using the following input:





  prefix = 'CuGeSnN4'
  outdir = './tmp'
  iverbosity = 2
  nq1 = 4, nq2 = 4, nq3 = 4
/


and found the following result in stderr:

forrtl: Operation not permitted   (repeated as many times as cores were 
used)


and

forrtl: severe (28): CLOSE error, unit 0, file "Unknown"
followed by several references on errors in hp.x (all these lines 
repeated as well as many times as cores were used)


The output of hp.x just contained at the end this line:

 WARNING! All Hubbard atoms must be listed first in the 
ATOMIC_POSITIONS card of PWscf


But since this was the case I do not think that this may be the cause of 
the problem.


I have been told that unit 0 is stderr; but how can this be, since these 
lines appeared in the stderr output itself? I have been using qe-6.5 
(for both pw.x and hp.x) and the SLURM queuing system


Please give advice.

Regards,

--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] wrong offset

[José Carlos Conesa Cegarra]

Thanks for the indication. Would any pseudo of the ONCV_PBE collection 
give the same result? Would any norm-conserving pseudo behave in the 
same way?


all hte best,

José C. Conesa

El 19/11/2020 a las 10:21, Paolo Giannozzi escribió:
On Thu, Nov 19, 2020 at 10:12 AM José C. Conesa > wrote:


  Error in routine offset_atom_wfc (1):
  wrong offset

Which may be the reason?


V_ONCV_PBE_FR-1.9.UPF contains no atomic wavefunctions

Paolo
--
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


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Incorrect identification+generations of atoms in specialpositions (space_group options used).

[José Carlos Conesa Cegarra]

Dear all,

Last 11th of september I sent a similar question, but the answer, 
provided by Paolo Giannozzi, did not clarify much. I can say that in 
that occasion I was using qe-6.5. Should I use qe -6.6?


Regards,

José C. Conesa

El 12/11/2020 a las 11:30, Pietro Delugas escribió:


Hi

 which version of the code are you using ?

with qe-6.6 using  your parameters I got two positions

  site n. atom  positions (alat units)

 1   Zn  tau( 1) = (   0.4873906   2.5406690   
1.4472625  )


 2   Zn  tau( 2) = (   0.3343454   0.8468897   
0.4736359  )


With alat = 11.5468  a.u.

alat = 11.5468  a.u.

ibrav=-12

hope it helps

greetings  - Pietro

Sent from Mail  for 
Windows 10


*From: *Michal Husak 
*Sent: *Thursday, November 12, 2020 10:34 AM
*To: *users@lists.quantum-espresso.org 

*Subject: *[QE-users] Incorrect identification+generations of atoms in 
specialpositions (space_group options used).


I


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Telef. +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Problem when compiling qe-6.7

[José Carlos Conesa Cegarra]

Dear Fabrizio,

I am compiling with libxc 5.0.0, which I installed previously. But 
because the first attempt was not successful, I used the followig 
recipe, that I found sometime ago:


- run configure without any libxc flag
- go to the make.inc file and, by following the comments inside, add the 
needed flags to DFLAGS, IFLAGS and LD_LIBS.


Do you think that it is better not to use libxc at all?

José C. Conesa

El 26/01/2021 a las 19:10, Fabrizio Ferrari escribió:

Hello,
are you compiling with libxc? Which version?

Fabrizio

On Tue, Jan 26, 2021 at 6:39 PM José Carlos Conesa Cegarra 
mailto:jccon...@icp.csic.es>> wrote:


Dear all,

I tried compiling qe-6.7. The compilation fails with a number of
messages like these:

funct.f90(40): error #7002: Error in opening the compiled module
file.
Check INCLUDE paths.   [XC_F03_LIB_M]
   USE xc_f03_lib_m
--^
funct.f90(424): error #6457: This derived type name has not been
declared.   [XC_F03_FUNC_T]
 TYPE(xc_f03_func_t) :: xc_func03
-^
funct.f90(776): error #6404: This name does not have a type, and must
have an explicit type.   [XC_FUNC03]
 CALL xc_f03_func_init( xc_func03, id_vec(ii), 1 )
---^
funct.f90(926): error #6054: A CHARACTER data type is required in
this
context.   [XC_F03_FUNCTIONAL_GET_NAME]
    name = xc_f03_functional_get_name( i )
--^
funct.f90(962): error #6601: In a CASE statement, the case-value
must be
a constant expression.   [XC_FAMILY_GGA]
   CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^
funct.f90(962): error #6612: In a CASE statement, the case-value
must be
of type INTEGER, CHARACTER, or LOGICAL.   [XC_FAMILY_GGA]
   CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^
funct.f90(962): error #6611: The case-value must be of the same
type as
the case-expr.   [XC_FAMILY_GGA]
   CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^

All of them relate to funct.f90. Maybe the key issue relates to error
#7002; but I could not find any module named xc_f03_lib_m.mod.
Which can
be the reason?

Regards,

José C. Conesa

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu
<http://www.max-centre.eu>)
users mailing list users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766



--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Problem when compiling qe-6.7

[José Carlos Conesa Cegarra]

Dear all,

I tried compiling qe-6.7. The compilation fails with a number of 
messages like these:


funct.f90(40): error #7002: Error in opening the compiled module file.  
Check INCLUDE paths.   [XC_F03_LIB_M]

  USE xc_f03_lib_m
--^
funct.f90(424): error #6457: This derived type name has not been 
declared.   [XC_F03_FUNC_T]

    TYPE(xc_f03_func_t) :: xc_func03
-^
funct.f90(776): error #6404: This name does not have a type, and must 
have an explicit type.   [XC_FUNC03]

    CALL xc_f03_func_init( xc_func03, id_vec(ii), 1 )
---^
funct.f90(926): error #6054: A CHARACTER data type is required in this 
context.   [XC_F03_FUNCTIONAL_GET_NAME]

   name = xc_f03_functional_get_name( i )
--^
funct.f90(962): error #6601: In a CASE statement, the case-value must be 
a constant expression.   [XC_FAMILY_GGA]

  CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^
funct.f90(962): error #6612: In a CASE statement, the case-value must be 
of type INTEGER, CHARACTER, or LOGICAL.   [XC_FAMILY_GGA]

  CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^
funct.f90(962): error #6611: The case-value must be of the same type as 
the case-expr.   [XC_FAMILY_GGA]

  CASE( XC_FAMILY_GGA, XC_FAMILY_HYB_GGA )
^

All of them relate to funct.f90. Maybe the key issue relates to error 
#7002; but I could not find any module named xc_f03_lib_m.mod. Which can 
be the reason?


Regards,

José C. Conesa

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] error with qe 6.5

[José Carlos Conesa Cegarra]

Dear all,

I have found (several times) this error with qe-6.5:

 %%
 Error in routine allocate_fft (1):
 wrong ngm
 %%

 stopping ...

The input file is attached. Please help

--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766



--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

   calculation='scf'
   title='CoGeSnN4_U'
   restart_mode='from_scratch'
   outdir='./tmp'
   etot_conv_thr=1.0D-5
   pseudo_dir='../..'
/

   space_group=148, rhombohedral=.TRUE.
   A=8.6856, B=8.6856, C=8.6856
   cosAB=-0.0021014, cosAC=-0.0021014, cosBC=-0.0021014
   nat=19, ntyp=4
   starting_magnetization(1)=1, nspin=2
   ecutwfc=1.0D-6
   occupations='tetrahedra_opt'
   lda_plus_u=.TRUE.,Hubbard_U(1)=0.01,Hubbard_U(2)=0.01
/

/
ATOMIC_SPECIES
Co  59.0 Co_pbe_v1.2.uspp.F.UPF
N   14.0 N.pbe.theos.UPF
Ge  74.0 Ge.pbe-dn-kjpaw_psl.1.0.0.UPF
Sn 120.0 Sn_pbe_v1.uspp.F.UPF

ATOMIC_POSITIONS crystal_sg
Co  0.00.00.0
N  -0.48261   -0.26780   -0.99868
N  -0.51739   -0.00132   -0.73220
N  -0.98743   -0.98331   -0.77013
N  -0.01257   -0.22987   -0.01669
N  -0.76645   -0.47954   -0.49898
N  -0.23355   -0.50102   -0.52046
N  -0.26651   -0.76957   -0.25152
N  -0.73349   -0.74848   -0.23043
N  -0.51528   -0.73873   -0.01378
N  -0.48472   -0.98622   -0.26127
N  -0.23402   -0.23402   -0.23402
Ge -0.00192   -0.24449   -0.24922
Ge -0.99808   -0.75078   -0.75551
Ge -0.49517   -0.504830.0
Ge -0.75545   -0.24455   -0.5
Sn -0.37211   -0.87601   -0.87826
Sn -0.24982   -0.75018   -0.5
Sn -0.37214   -0.37214   -0.37214

K_POINTS automatic
6 6 6  0 0 0
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Fwd: error with qe 6.5

[José Carlos Conesa Cegarra]

Dear all,

Even decreasing ecutwfc by two orders of magnitude the error remains the 
same. The PBE pseudopotentials are those included in


https://www.materialscloud.org/discover/sssp/table/

Please help.

 Mensaje reenviado 
Asunto: [QE-users] error with qe 6.5
Fecha:  Fri, 12 Feb 2021 13:49:24 +0100
De: José Carlos Conesa Cegarra 
Responder a: 	Quantum ESPRESSO users Forum 


Para:   Quantum ESPRESSO users Forum 



Dear all,

I have found (several times) this error with qe-6.5:

 %%
 Error in routine allocate_fft (1):
 wrong ngm
 %%

 stopping ...

The input file is attached. Please help

--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766



--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus


   calculation='scf'
   title='CoGeSnN4_U'
   restart_mode='from_scratch'
   outdir='./tmp'
   etot_conv_thr=1.0D-5
   pseudo_dir='../..'
/

   space_group=148, rhombohedral=.TRUE.
   A=8.6856, B=8.6856, C=8.6856
   cosAB=-0.0021014, cosAC=-0.0021014, cosBC=-0.0021014
   nat=19, ntyp=4
   starting_magnetization(1)=1, nspin=2
   ecutwfc=1.0D-6
   occupations='tetrahedra_opt'
   lda_plus_u=.TRUE.,Hubbard_U(1)=0.01,Hubbard_U(2)=0.01
/

/
ATOMIC_SPECIES
Co  59.0 Co_pbe_v1.2.uspp.F.UPF
N   14.0 N.pbe.theos.UPF
Ge  74.0 Ge.pbe-dn-kjpaw_psl.1.0.0.UPF
Sn 120.0 Sn_pbe_v1.uspp.F.UPF

ATOMIC_POSITIONS crystal_sg
Co  0.00.00.0
N  -0.48261   -0.26780   -0.99868
N  -0.51739   -0.00132   -0.73220
N  -0.98743   -0.98331   -0.77013
N  -0.01257   -0.22987   -0.01669
N  -0.76645   -0.47954   -0.49898
N  -0.23355   -0.50102   -0.52046
N  -0.26651   -0.76957   -0.25152
N  -0.73349   -0.74848   -0.23043
N  -0.51528   -0.73873   -0.01378
N  -0.48472   -0.98622   -0.26127
N  -0.23402   -0.23402   -0.23402
Ge -0.00192   -0.24449   -0.24922
Ge -0.99808   -0.75078   -0.75551
Ge -0.49517   -0.504830.0
Ge -0.75545   -0.24455   -0.5
Sn -0.37211   -0.87601   -0.87826
Sn -0.24982   -0.75018   -0.5
Sn -0.37214   -0.37214   -0.37214

K_POINTS automatic
6 6 6  0 0 0
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Fwd: error with qe 6.5

[José Carlos Conesa Cegarra]

I mean,

ecutwfc=1.0D-8

JC Conesa

El 14/02/2021 a las 20:38, Paolo Giannozzi escribió:

"decreasing" ?

On Sun, Feb 14, 2021 at 8:16 PM José Carlos Conesa Cegarra 
mailto:jccon...@icp.csic.es>> wrote:


Dear all,

Even decreasing ecutwfc by two orders of magnitude the error
remains the same. The PBE pseudopotentials are those included in

https://www.materialscloud.org/discover/sssp/table/
<https://www.materialscloud.org/discover/sssp/table/>

Please help.

 Mensaje reenviado 
Asunto: [QE-users] error with qe 6.5
Fecha:  Fri, 12 Feb 2021 13:49:24 +0100
De: José Carlos Conesa Cegarra 
<mailto:jccon...@icp.csic.es>
Responder a:Quantum ESPRESSO users Forum

<mailto:users@lists.quantum-espresso.org>
Para:   Quantum ESPRESSO users Forum

<mailto:users@lists.quantum-espresso.org>



Dear all,

I have found (several times) this error with qe-6.5:

 
%%
 Error in routine allocate_fft (1):
 wrong ngm
 
%%

 stopping ...

The input file is attached. Please help

-- 
José C. Conesa

Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766



-- 
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.

https://www.avast.com/antivirus  <https://www.avast.com/antivirus>



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
Libre de virus. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>


<#m_817471404283560405_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu
<http://www.max-centre.eu>)
users mailing list users@lists.quantum-espresso.org
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>



--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 206, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Fwd: error with qe 6.5

[José Carlos Conesa Cegarra]

Dear all,

Indeed I mistakedly confounded the conv_thr and ecutwfc values. Looking 
at the instructions I see now that ecutwfc is a value in Rydbergs. One 
reason for my mistake is that the ecutwfc values suggested for Co and Sn 
in the pseudos I used are 0.00 Ry; I did not go further, if I had looked 
for the pseudos of Ge and N I would have seen that the suggested values 
are around 40 Ry.


I will change the ecutwfc values to an average of those given by 
Giuseppe, and might test a few others.


Thanks to all,

José C. Conesa

El 15/02/2021 a las 12:46, Giuseppe Mattioli escribió:


Dear José

Maybe you are mistaking ecutwfc (in namelist ) with conv_thr 
(in namelist ). The former is the wavefunction cutoff (in 
Ry). Its generally meaningful values, depending on pseudopotential 
type, are in a 25~250 Ry range. Thus your 1.0D-8 value is absurdly 
small. The latter is the convergence threshold for wavefunctions in 
the iterative scf steps. Its default value is 1.0D-6 and may be 
lowered down to 1.0D-10 for different kinds of general-purpose 
calculation.


Without seeing sssp convergence tests, I would expect for your 
pseudopotentials values around


ecutwfc=40~60 Ry
ecutrho=320~600 Ry

HTH
Giuseppe

Quoting José Carlos Conesa Cegarra :


I mean,

ecutwfc=1.0D-8

JC Conesa

El 14/02/2021 a las 20:38, Paolo Giannozzi escribió:

"decreasing" ?

On Sun, Feb 14, 2021 at 8:16 PM José Carlos Conesa Cegarra 
mailto:jccon...@icp.csic.es>> wrote:


   Dear all,

   Even decreasing ecutwfc by two orders of magnitude the error
   remains the same. The PBE pseudopotentials are those included in

   https://www.materialscloud.org/discover/sssp/table/
   <https://www.materialscloud.org/discover/sssp/table/>

   Please help.

    Mensaje reenviado 
   Asunto: [QE-users] error with qe 6.5
   Fecha: Fri, 12 Feb 2021 13:49:24 +0100
   De:     José Carlos Conesa Cegarra 
   <mailto:jccon...@icp.csic.es>
   Responder a: Quantum ESPRESSO users Forum
   
   <mailto:users@lists.quantum-espresso.org>
   Para: Quantum ESPRESSO users Forum
   
   <mailto:users@lists.quantum-espresso.org>



   Dear all,

   I have found (several times) this error with qe-6.5:

 %%
    Error in routine allocate_fft (1):
    wrong ngm
 %%

    stopping ...

   The input file is attached. Please help

   -- José C. Conesa
   Research Professor
   Instituto de Catálisis y Petroleoquímica, CSIC
   Marie Curie, 2; Campus de Cantoblanco
   28028 Madrid (Spain)
   Phone +34 915854766



   -- El software de antivirus Avast ha analizado este correo 
electrónico en busca de virus.

   https://www.avast.com/antivirus <https://www.avast.com/antivirus>


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
   Libre de virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>


<#m_817471404283560405_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
   ___
   Quantum ESPRESSO is supported by MaX (www.max-centre.eu
   <http://www.max-centre.eu>)
   users mailing list users@lists.quantum-espresso.org
   <mailto:users@lists.quantum-espresso.org>
   https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>



--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 206, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766




GIUSEPPE MATTIOLI
CNR - ISTITUTO DI STRUTTURA DELLA MATERIA
Via Salaria Km 29,300 - C.P. 10
I-00015 - Monterotondo Scalo (RM)
Mob (*preferred*) +39 373 7305625
Tel + 39 06 90672342 - Fax +39 06 90672316
E-mail: 

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users


--
José C. Conesa
Research Professor
Instituto de Catálisis y Petroleoquímica, CSIC
Marie Curie, 2; Campus de Cantoblanco
28028 Madrid (Spain)
Phone +34 915854766


--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailin