Re: [QE-users] Error while running Quantum Espresso with Intel MPI

[DAVID BARCENE]

Dear Will and Nicola thank you for your fast reply.

I recently compiled with openmpi, following Will's advice, there were some 
warnings about missing include directories for FoX and iotk, I believe, but I 
just ignored them. Then run the example again and this is the output:
**
[dbarcene@NGC2501 example01]$ ./run_example

/home/dbarcene/qe-6.3/PW/examples/example01 : starting

This example shows how to use pw.x to calculate the total energy and
the band structure of four simple systems: Si, Al, Cu, Ni.

 executables directory: /home/dbarcene/qe-6.3/bin
 pseudo directory:  /home/dbarcene/qe-6.3/pseudo
 temporary directory:   /home/dbarcene/qe-6.3/tempdir
 checking that needed directories and files exist...
Downloading Si.pz-vbc.UPF to /home/dbarcene/qe-6.3/pseudo...
Downloading Al.pz-vbc.UPF to /home/dbarcene/qe-6.3/pseudo...
Downloading Cu.pz-d-rrkjus.UPF to /home/dbarcene/qe-6.3/pseudo...
Downloading Ni.pz-nd-rrkjus.UPF to /home/dbarcene/qe-6.3/pseudo... done

 running pw.x as: mpirun -np 4 /home/dbarcene/qe-6.3/bin/pw.x  -nk 1 -nd 1 -nb 
1 -nt 1

 running the scf calculation for Si... done
 running the band-structure calculation for Si... done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Al... done
 running the band-structure calculation for Al... done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Cu... done
 running the band-structure calculation for Cu... done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Ni... done
 running the band-structure calculation for Ni... done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Si... done
 running the band-structure calculation for Si...Note: The following 
floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Al... done
 running the band-structure calculation for Al...Note: The following 
floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Cu... done
 running the band-structure calculation for Cu...Note: The following 
floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
done
 cleaning /home/dbarcene/qe-6.3/tempdir... done
 running the scf calculation for Ni... done
 running the band-structure calculation for Ni...Note: The following 
floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
done
 cleaning /home/dbarcene/qe-6.3/tempdir... done

/home/dbarcene/qe-6.3/PW/examples/example01 : done
**

Comparing the results for Si.cg.out with the reference there were no difference 
aside for the use of RAM. I can work with this build as long as it remains 
without bugs (I hope so). I also downloaded the virtual machine provided by 
Nicola to take a look at it.
Finally, I'll let you with the make.inc file I used for the first build with 
Intel MPI, as I'm a novice I might have done something wrong there that you 
could point out and discard any bugs related to software by doing so. Thanks 
again.

​*

# make.inc.  Generated from make.inc.in by configure.

# compilation rules

.SUFFIXES :
.SUFFIXES : .o .c .f .f90

# most fortran compilers can directly preprocess c-like directives: use
#  $(MPIF90) $(F90FLAGS) -c $<
# if explicit preprocessing by the C preprocessor is needed, use:
#  $(CPP) $(CPPFLAGS) $< -o $*.F90
# $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o
# remember the tabulator in the first column !!!

.f90.o:
$(MPIF90) $(F90FLAGS) -c $<

# .f.o and .c.o: do not modify

.f.o:
$(F77) $(FFLAGS) -c $<

.c.o:
$(CC) $(CFLAGS)  -c $<



# Top QE directory, useful for locating libraries,  linking QE with plugins
# The following syntax should always point to TOPDIR:
TOPDIR = $(dir $(abspath $(filter %make.inc,$(MAKEFILE_LIST
# if it doesn't work, uncomment the following line (edit if needed):

# TOPDIR = /home/dbarcene/qe-6.3

# DFLAGS  = precompilati

Re: [QE-users] HFX and USPP (QE6.3)

[Michal Krompiec]

Dear Paolo,
Do you mean L-ACE https://arxiv.org/pdf/1801.09263.pdf? Is L-ACE already
available in the development branch?
Best,
Michal Krompiec
Merck / U Southampton

On Thu, 14 Feb 2019 at 15:21, Paolo Giannozzi  wrote:

> SCDM is coming (very) soon but not with USPP
>
> Paolo
>
> On Thu, Feb 14, 2019 at 12:46 PM Tobias Kloeffel 
> wrote:
>
>> Hi Lorenzo,
>>
>> since no one else noticed it, I guess there is not much interest in
>> implementing it? I saw USPP + SCDM on some
>>   old slides from the development meeting back in 2017. However, if
>> forces are not available I guess SCDM is also not on the current todo
>> list?
>>
>>
>>
>> On 2/13/19 12:34 PM, Lorenzo Paulatto wrote:
>> >> The energy minimum is at around 1.249A whereas the force minimum is
>> >> at 1.253A, is there something missing in the force evaluation if PBE0
>> >> is used?
>> >
>> > It is quite likely, I did not implement it and I doubt anybody else
>> > did. I think it is more or less a matter of adding the HF
>> > contributions to the hamiltonian (deexx from vexx) to the expression
>> > of the ultrasoft forces, but there is some complexity with the
>> > indexes, I think.
>> >
>> > Anyway, I confirm it is probably not implemented and should be prevented
>> >
>> >
>>
>> --
>> M.Sc. Tobias Klöffel
>> ===
>> Interdisciplinary Center for Molecular Materials (ICMM)
>> and Computer-Chemistry-Center (CCC)
>> Department Chemie und Pharmazie
>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>> Nägelsbachstr. 25
>> D-91052 Erlangen, Germany
>>
>> Room: 2.305
>> Phone: +49 (0) 9131 / 85 - 20423
>> Fax: +49 (0) 9131 / 85 - 26565
>>
>> ===
>>
>> E-mail: tobias.kloef...@fau.de
>>
>> ___
>> 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
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] HFX and USPP (QE6.3)

[Paolo Giannozzi]

SCDM is coming (very) soon but not with USPP

Paolo

On Thu, Feb 14, 2019 at 12:46 PM Tobias Kloeffel 
wrote:

> Hi Lorenzo,
>
> since no one else noticed it, I guess there is not much interest in
> implementing it? I saw USPP + SCDM on some
>   old slides from the development meeting back in 2017. However, if
> forces are not available I guess SCDM is also not on the current todo list?
>
>
>
> On 2/13/19 12:34 PM, Lorenzo Paulatto wrote:
> >> The energy minimum is at around 1.249A whereas the force minimum is
> >> at 1.253A, is there something missing in the force evaluation if PBE0
> >> is used?
> >
> > It is quite likely, I did not implement it and I doubt anybody else
> > did. I think it is more or less a matter of adding the HF
> > contributions to the hamiltonian (deexx from vexx) to the expression
> > of the ultrasoft forces, but there is some complexity with the
> > indexes, I think.
> >
> > Anyway, I confirm it is probably not implemented and should be prevented
> >
> >
>
> --
> M.Sc. Tobias Klöffel
> ===
> Interdisciplinary Center for Molecular Materials (ICMM)
> and Computer-Chemistry-Center (CCC)
> Department Chemie und Pharmazie
> Friedrich-Alexander-Universität Erlangen-Nürnberg
> Nägelsbachstr. 25
> D-91052 Erlangen, Germany
>
> Room: 2.305
> Phone: +49 (0) 9131 / 85 - 20423
> Fax: +49 (0) 9131 / 85 - 26565
>
> ===
>
> E-mail: tobias.kloef...@fau.de
>
> ___
> 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

Re: [QE-users] NEB calculation no symmetry found

[Offermans Willem]

Dear Paolo Giannozzi and Quantum Espresso friends,

I thank you 1001 times for your remark that the neb.x code deals with symmetry 
in a most expected way.
Combined with the information about the pw_1.in file and the diff program, I 
was able to detect my mistake.

Unfortunately I had changed the unit cell vectors a bit by mistake. This led to 
a lost of the symmetry.

I’m sorry for the noise I created, but it was really a puzzle for me.

Thank you for your effort and attention.


Met vriendelijke groeten,
Mit freundlichen Grüßen,
With kind regards,


Willem Offermans
Researcher Electrocatalysis SCT
VITO NV | Boeretang 200 | 2400 Mol
Phone:+32(0)14335263 Mobile:+32(0)492182073

willem.offerm...@vito.be

[cid:982BA063-B96A-4A1B-89AB-5A01CA9FC70D@vito.local]

On 14 Feb 2019, at 10:04, Giovanni Cantele 
mailto:giovanni.cant...@spin.cnr.it>> wrote:

from PW/src/symm_base.f90 :

  ! ... these are acceptance criteria
  !
  REAL(DP), PARAMETER :: eps1 = 1.0d-6, eps2 = 1.0d-5


I guess you can change those values and recompile the code to force it to use a 
certain tolerance
Giovanni


On 14 Feb 2019, at 09:58, Fabrizio Cossu 
mailto:fabrizio.co...@apctp.org>> wrote:



On Thu, 14 Feb 2019 at 17:37, Paolo Giannozzi 
mailto:p.gianno...@gmail.com>> wrote:
On Thu, Feb 14, 2019 at 8:34 AM Offermans Willem 
mailto:willem.offerm...@vito.be>> wrote:

So neb.x is able to detect symmetry. Only in my particular case, it is not able 
to and I wonder why.

the reason has been explained no less than 1001 times: if the code does not 
find a symmetry, it's not there, according to the criteria implemented in the 
code.

Paolo

A DFT code should recognise symmetry operations within a certain tolerance 
given the coordinates of the atoms. A quick search ("symmetry", "tolerance") in 
the pw.x input options does not return any result for a tunable parameter. What 
is the default value for the tolerance, and what should I do if I had to define 
a certain tolerance?
Thank you,
Fabrizio

--
Fabrizio Cossu
postdoctoral fellow at APCTP (Asia Pacific Center for Theoretical Physics),
Hogil Kim Memorial Building #501
POSTECH, 67 Cheongam-Ro, Nam-Gu,
Pohang-si, Gyeongsangbuk-do,
790-784 (37673), Republic of Korea

   |
  .. .. .. |  ..   ===
  ,| || |  |  ||   http://www.apctp.org/?JrgId=16
  `^ |' `' `' |'   ===
 ||

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

--

Giovanni Cantele, PhD

CNR-SPIN
c/o Dipartimento di Fisica
Universita' di Napoli "Federico II"
Complesso Universitario M. S. Angelo - Ed. 6
Via Cintia, I-80126, Napoli, Italy

e-mail: giovanni.cant...@spin.cnr.it
gcant...@gmail.com
Phone: +39 081 676910
Skype contact: giocan74
Web page: https://sites.google.com/view/giovanni-cantele

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

Indien u VITO Mol bezoekt, hou aub er dan rekening mee dat de hoofdingang 
voortaan enkel bereikbaar is vanuit de richting Dessel-Retie, niet vanuit 
richting Mol, zie vito.be/route.
If you plan to visit VITO at Mol, then please note that the main entrance can 
only be reached coming from Dessel-Retie and no longer coming from Mol, see 
vito.be/en/contact/locations.
VITO Disclaimer: http://www.vito.be/e-maildisclaimer
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] niter_cg_restart parameter in cp.x

[Riccardo Bertossa]

Hi Zeeshan,

this is an internal parameter of the CG algorithm. The iterations are CG 
iterations, not verlet or anything else. A restart/reset in the CG means 
that the algorithm forgets the previous minimization directions and 
starts again minimizing the function in the gradient direction, as in 
the first step.


If you want to do a CG every N steps of the dynamics you can do a 
restart or use the autopilot module.



best regards,

Riccardo Bertossa

SISSA

On 14/02/19 07:49, Zeeshan Ahmad wrote:

Hi all,

The explanation for ’niter_cg_restart’ parameter belonging to cp.x input in 
docs is:

“frequency in iterations for which the conjugate-gradient algorithm for 
electronic relaxation is restarted” with a  default value of 20.

Does this mean for all types of electron_dynamics like ’none’, ‘verlet’, ‘damp’ 
etc., conjugate gradient algorithm will be used to converge the wave function 
every 20 steps by default?

Thanks,
-Zeeshan

--
Zeeshan Ahmad
PhD candidate, Mechanical Engineering
Carnegie Mellon University

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

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

Re: [QE-users] HFX and USPP (QE6.3)

[Tobias Kloeffel]

Hi Lorenzo,

since no one else noticed it, I guess there is not much interest in 
implementing it? I saw USPP + SCDM on some
 old slides from the development meeting back in 2017. However, if 
forces are not available I guess SCDM is also not on the current todo list?




On 2/13/19 12:34 PM, Lorenzo Paulatto wrote:
The energy minimum is at around 1.249A whereas the force minimum is 
at 1.253A, is there something missing in the force evaluation if PBE0 
is used?


It is quite likely, I did not implement it and I doubt anybody else 
did. I think it is more or less a matter of adding the HF 
contributions to the hamiltonian (deexx from vexx) to the expression 
of the ultrasoft forces, but there is some complexity with the 
indexes, I think.


Anyway, I confirm it is probably not implemented and should be prevented




--
M.Sc. Tobias Klöffel
===
Interdisciplinary Center for Molecular Materials (ICMM)
and Computer-Chemistry-Center (CCC)
Department Chemie und Pharmazie
Friedrich-Alexander-Universität Erlangen-Nürnberg
Nägelsbachstr. 25
D-91052 Erlangen, Germany

Room: 2.305
Phone: +49 (0) 9131 / 85 - 20423
Fax: +49 (0) 9131 / 85 - 26565

===

E-mail: tobias.kloef...@fau.de

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

Re: [QE-users] NEB calculation no symmetry found

[Giovanni Cantele]

from PW/src/symm_base.f90 :

  ! ... these are acceptance criteria
  !
  REAL(DP), PARAMETER :: eps1 = 1.0d-6, eps2 = 1.0d-5


I guess you can change those values and recompile the code to force it to use a 
certain tolerance
Giovanni


> On 14 Feb 2019, at 09:58, Fabrizio Cossu  wrote:
> 
> 
> 
> On Thu, 14 Feb 2019 at 17:37, Paolo Giannozzi  > wrote:
> On Thu, Feb 14, 2019 at 8:34 AM Offermans Willem  > wrote:
> 
> So neb.x is able to detect symmetry. Only in my particular case, it is not 
> able to and I wonder why.
> 
> the reason has been explained no less than 1001 times: if the code does not 
> find a symmetry, it's not there, according to the criteria implemented in the 
> code. 
> 
> Paolo
> 
> A DFT code should recognise symmetry operations within a certain tolerance 
> given the coordinates of the atoms. A quick search ("symmetry", "tolerance") 
> in the pw.x input options does not return any result for a tunable parameter. 
> What is the default value for the tolerance, and what should I do if I had to 
> define a certain tolerance?
> Thank you,
> Fabrizio
> 
> -- 
> Fabrizio Cossu
> postdoctoral fellow at APCTP (Asia Pacific Center for Theoretical Physics),
> Hogil Kim Memorial Building #501 
> POSTECH, 67 Cheongam-Ro, Nam-Gu, 
> Pohang-si, Gyeongsangbuk-do,
> 790-784 (37673), Republic of Korea
>|
>   .. .. .. |  ..   ===
>   ,| || |  |  ||   http://www.apctp.org/?JrgId=16 
> 
>   `^ |' `' `' |'   ===
>  ||
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users

-- 

Giovanni Cantele, PhD

CNR-SPIN
c/o Dipartimento di Fisica
Universita' di Napoli "Federico II"
Complesso Universitario M. S. Angelo - Ed. 6
Via Cintia, I-80126, Napoli, Italy

e-mail: giovanni.cant...@spin.cnr.it
gcant...@gmail.com
Phone: +39 081 676910
Skype contact: giocan74
Web page: https://sites.google.com/view/giovanni-cantele

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

Re: [QE-users] NEB calculation no symmetry found

[Fabrizio Cossu]

On Thu, 14 Feb 2019 at 17:37, Paolo Giannozzi  wrote:

> On Thu, Feb 14, 2019 at 8:34 AM Offermans Willem 
> wrote:
>
>>
>> So neb.x is able to detect symmetry. Only in my particular case, it is
>> not able to and I wonder why.
>
>
> the reason has been explained no less than 1001 times: if the code does
> not find a symmetry, it's not there, according to the criteria implemented
> in the code.
>
> Paolo
>
> A DFT code should recognise symmetry operations within a certain tolerance
given the coordinates of the atoms. A quick search ("symmetry",
"tolerance") in the pw.x input options does not return any result for a
tunable parameter. What is the default value for the tolerance, and what
should I do if I had to define a certain tolerance?
Thank you,
Fabrizio

-- 

*Fabrizio Cossupostdoctoral fellow at APCTP (Asia Pacific Center for
Theoretical Physics)*,
Hogil Kim Memorial Building #501
POSTECH, 67 Cheongam-Ro, Nam-Gu,
Pohang-si, Gyeongsangbuk-do,
790-784 (37673), Republic of Korea

   |
  .. .. .. |  ..   ===
  ,| || |  |  ||   http://www.apctp.org/?JrgId=16
  `^ |' `' `' |'   ===
 ||
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] 答复: PDOS for isolated gas molecule

[Paolo Giannozzi]

You sent an output from "projwfc.x", clearly showing that parallel
diagonalization (ScaLAPACK) is used for overlap matrices, whose size is
natomwfc x natomwfc. Iterative parallelization used in self-consistency is
a different story.

Paolo


On Thu, Feb 14, 2019 at 9:39 AM LEUNG Clarence 
wrote:

> Dear Paolo,
>
> Thanks for your reply.
> But I am not sure, You mean that diagonalization in scf uses 'cg' ? In my
> scf, diagonalization used the default option 'david' .
>
> Clarence
> --
> *发件人:* users  代表 Paolo
> Giannozzi 
> *发送时间:* 2019年2月14日 16:28
> *收件人:* Quantum Espresso users Forum
> *主题:* Re: [QE-users] PDOS for isolated gas molecule
>
>
> On Thu, Feb 14, 2019 at 9:18 AM LEUNG Clarence 
> wrote:
>
> When I calculate the PDOS for isolated gas molecule by projwfc.x , it stop
> with an error :
>
>
>
>  Error in routine  blk2cyc_zredist (1):
>   nb less than the number of proc
>
>
> you have 2x2  matrices (natomwfc x natomwfc), don't use parallel
> diagonalization.
> 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
>
> ___
> 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

Re: [QE-users] Problem with tetrahedra method: from tetra_init : error # 26, cannot remap grid on k-point list

[Pietro Davide Delugas]

Hi Oleksandr

Yes you are right, I just checked in the code, initializinfg the 
tetrahedra 2D grids are just  considered as 3D grids  because of the 
periodicity.


As for results I used tetrahedra for dos and pdos ( in 3D systems) and 
results are fine. Never used it for scf calculations though.

Pietro

On 02/14/2019 09:11 AM, Oleksandr Motornyi wrote:


Hello Pacome and Pietro,

I can confirm that tetrahedra_opt works for the 2D k-point meshes, 
both for scf/nscf and dos.x/projwfc.x calculations, so it should be 
implemented at least in some way. The other thing is that I am not 
convinced with the credibility of results I obtain, but it is a 
different story.


Regards,

Oleksandr

Oleksandr Motornyi
PhD

Laboratoire des Solides Irradies
Ecole Polytechnique (Palaiseau, France)
On 02/14/2019 08:58 AM, Pietro Davide Delugas wrote:

Hello Pacome

using qe-6.3  you can actually run the nscf  calculation without 
specifying occupation=tetrahedra leave smearing or whatever else and  
just take care to check that you are computing as many bands you 
need, which as I read you are already doing specifying nbnd.
In the dos.x input  you have just to add the option bz_sum = 
'tetrahedra_opt'.


if you use qe-6.3 remember that the format of xml and charge density 
files are different from those of 6.2 and older versions, so you have 
to rerun the scf computation as well.


One thing that I notice now is that you are using a 9X9X1 mesh, I am 
not sure whether 2D version of the method is actually implemented in 
Q.E. you could try using a 9X9X2 mesh and see if that works.


greetings - Pietro



On 02/14/2019 01:03 AM, Pacome NGUIMEYA wrote:

Hi all,

I have been trying to run the calculation of the Density of State 
(DOS) for TaAs using *QE-6.1* but It always crashes and returns the 
following error message:


     task #         6
     from tetra_init : error #        26
     cannot remap grid on k-point list

There are several forums on this subject where many workaround have 
been proposed.


I went through all of them and I tried each of the proposed 
workaround that I found, but none of them could solve the problem.


Neither adding bands *(ndnd=144)* nor *the increase of the 
convergence threshold to 1.0e-11* worked 
(http://blog.sina.com.cn/s/blog_5f15ead20100cw4d.html), not even the 
workaround propose by Prof Paolo Giannozzi here 
https://www.mail-archive.com/users@lists.quantum-espresso.org/msg32997.html


I even *changed the version of quantum espresso*; I used *QE 5.4*, 
*6.2* and *6.3* but I keep getting errors


with *QE-5.4* and *QE-6.2* I am getting the following error

     task #        21
     from tetrahedra : error #        26
     cannot remap grid on k-point list

 and this one with *QE-6.3*

     task #         0
     from pw_readfile : error #         1
     error opening xml data file

In the *particular case* of *QE-6.3* the *problem seems to be 
solved* but it looks like the program *can not find the xml file*; 
*it looks like it does not exist*.


I am using the CHPC(centre for high performance computing)'s cluster 
to run my calculations


I need your help to sort this out

Is it possible to calculate the DOS with *occupations = 'smearing', 
smearing = 'M-P', degauss = 0.011* and with the *automatically 
chosen k-points 9 9 1* 1 1 1 instead of *occupations = 'tetrahedra'* 
with *k-points 9 9 1* 1 1 1.


 I look forward to hearing from you,

 Below is my input file (also attached to this email)


&CONTROL
 calculation = 'nscf',
    prefix = 'TaAs',
restart_mode = 'from_scratch',
pseudo_dir = '/...,
outdir = '/...,
     etot_conv_thr = 1.0e-5,
wf_collect = .true.,
 /
&SYSTEM
 ibrav = 7,
 A = 3.4348002616,
 B = 3.4348002616,
 C = 11.641,
     cosAB = 0,
     cosAC = 0,
     cosBC = 0,
 nat = 8,
ntyp = 2,
nbnd = 72,
 ecutwfc = 70,
 ecutrho = 400,
occupations = 'tetrahedra',
 /
&ELECTRONS
          conv_thr = 1.0e-11,
       mixing_mode = 'plain',
 mixing_beta = 0.7,
 diagonalization = 'cg',
 /
 ATOMIC_SPECIES
   Ta   180.94788 Ta.pbe-spn-kjpaw_psl.0.2.UPF
   As   74.9216 As.pbe-n-kjpaw_psl.0.2.UPF
 ATOMIC_POSITIONS {crystal}
Ta       0.256888939 -0.145590417  -0.031926398
Ta       0.575434474  0.440904275   0.567465416
Ta      -0.284237537  0.808259399   0.316294705
Ta       0.027951774  0.396761377   0.919029854
As       0.041545914 -0.136018486   0.451188370
As       0.704536879  0.274274640   0.880297072
As       0.172406031  0.385662500   0.492672865
As       0.505473527 -0.024253289   0.072978100
 K_POINTS {automatic}
  9 9 1  1 1 1

 Regards,
 Pacome
*___**_
*Pacome NGUIMEYA
Ph.D. Candidate
Computational Condensed Matter Physics
University of Cape Town (UCT), South Africa
*/“Be Yourself; everyone else is already taken.”///*
*/Oscar Wilde/*


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





___
users mailing list
user

[QE-users] 答复: PDOS for isolated gas molecule

[LEUNG Clarence]

Dear Paolo,

Thanks for your reply.
But I am not sure, You mean that diagonalization in scf uses 'cg' ? In my scf, 
diagonalization used the default option 'david' .

Clarence

发件人: users  代表 Paolo Giannozzi 

发送时间: 2019年2月14日 16:28
收件人: Quantum Espresso users Forum
主题: Re: [QE-users] PDOS for isolated gas molecule


On Thu, Feb 14, 2019 at 9:18 AM LEUNG Clarence 
mailto:liangxy...@hotmail.com>> wrote:

When I calculate the PDOS for isolated gas molecule by projwfc.x , it stop with 
an error :

 Error in routine  blk2cyc_zredist (1):
  nb less than the number of proc

you have 2x2  matrices (natomwfc x natomwfc), don't use parallel 
diagonalization.
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

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

Re: [QE-users] NEB calculation no symmetry found

[Paolo Giannozzi]

On Thu, Feb 14, 2019 at 8:34 AM Offermans Willem 
wrote:

>
> Probably you meant to refer to another mail thread. Probably the one
> started by Abdul Shaik.
> http://lists.quantum-espresso.org/pipermail/users/2019-February/042084.html
>

yes, sorry, I cut-and-pasted the wrong address

But can you explicitly make clear why it is not a good idea to have
> symmetry in a NEB calculation?
>

because unlike structural optimization there is no guarantee that the
starting  symmetry will be kept during the run. When initial symmetry is
lost, you may end up with more k-points and the code crashes. Of course, if
this does not happen, it is perfectly fine to use symmetry in NEB.

So neb.x is able to detect symmetry. Only in my particular case, it is not
> able to and I wonder why.


the reason has been explained no less than 1001 times: if the code does not
find a symmetry, it's not there, according to the criteria implemented in
the code.

Paolo

On 14 Feb 2019, at 07:55, Paolo Giannozzi  wrote:


On Wed, Feb 13, 2019 at 10:07 PM Paolo Giannozzi 
wrote:

You can start a calculation from the files pw_1.in, pw_2.in, etc., that the
> NEB code creates in the current execution directory. They contain input
> data for the starting points on the NEB chain. I did that and got no
> symmetry, by the way.
>

and,  by the way, this recent thread explains why it is not a good thing to
have symmetry in NEB images:

http://lists.quantum-espresso.org/pipermail/users/2019-February/042111.html

Paolo


> $ pw.x -in pd.xml
>>
>>  Program PWSCF v.6.3 starts on 13Feb2019 at 11:49:38
>>
>>  This program is part of the open-source Quantum ESPRESSO suite
>>  for quantum simulation of materials; please cite
>>  "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
>>  "P. Giannozzi et al., J. Phys.:Condens. Matter 29 465901 (2017);
>>   URL http://www.quantum-espresso.org";,
>>  in publications or presentations arising from this work. More
>> details at
>>  http://www.quantum-espresso.org/quote
>>
>>  Parallel version (MPI & OpenMP), running on  20 processor cores
>>  Number of MPI processes: 1
>>  Threads/MPI process:20
>>
>>  MPI processes distributed on 1 nodes
>>  Reading xml input from pd.xml
>>
>>
>>  
>> %%
>>  Error in routine read_input (1):
>>  xml input disabled
>>
>>  
>> %%
>>
>>  stopping ...
>> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
>> [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
>> :
>> system msg for write_line failure : Bad file descriptor
>>
>> So I cannot easily play with the settings.
>>
>>
>> Met vriendelijke groeten,
>> Mit freundlichen Grüßen,
>> With kind regards,
>>
>>
>> Willem Offermans
>> Researcher Electrocatalysis SCT
>> VITO NV | Boeretang 200 | 2400 Mol
>> Phone:+32(0)14335263 Mobile:+32(0)492182073
>>
>> willem.offerm...@vito.be
>>
>> 
>>
>> On 13 Feb 2019, at 11:24, Offermans Willem 
>> wrote:
>>
>> Dear Stefano,
>>
>>
>> No, point symmetry doesn’t depend on units, i.e. squeezing or expanding
>> the system equally in all directions doesn’t change symmetry. I agree!
>>
>> The presence of the inversion symmetry is not to save computational time,
>> but to correct for possible dipole interactions.
>>
>> Anyway, the point is that neb.x is not able to detect and to use the
>> symmetry of the involved images. This is weird, since the task of
>> optimising/calculating the images
>> will be delegated to pw.x, I suppose. And I showed that pw.x detects and
>> uses the symmetry. Maybe the keyword ``use_all_frac = .true.`` is not
>> considered for a NEB calculation.
>>
>>
>>
>> Met vriendelijke groeten,
>> Mit freundlichen Grüßen,
>> With kind regards,
>>
>>
>> Willem Offermans
>> Researcher Electrocatalysis SCT
>> VITO NV | Boeretang 200 | 2400 Mol
>> Phone:+32(0)14335263 Mobile:+32(0)492182073
>>
>> willem.offerm...@vito.be
>>
>> 
>>
>> On 13 Feb 2019, at 10:04, Stefano Baroni  wrote:
>>
>>
>>
>> On 13 Feb 2019, at 09:50, Offermans Willem 
>> wrote:
>>
>> Dear Quantum Espresso friends,
>>
>>
>> Dear Wilem:
>>
>> I made a mistake in my previous e-mail.
>> The atom coordinates are not in Angstrom but in Bohr.
>>
>>
>> I have corrected this in my calculations, but still no symmetry found.
>>
>>
>> I would be surprised if you found the contrary. I cannot imagine that the
>> point symmetry of any system could depend on units: do you?
>>
>> $ grep "ymmetr" pd_?/PW.out
>> pd_1/PW.out: No symmetry found
>> pd_2/PW.out: No symmetry found
>> pd_3/PW.out: No symmetry found
>> pd_4/PW.out: No symmetry found
>> pd_5/PW.out: No symmetry found
>> pd_6/PW.out: No symmetry found
>> pd_7/PW.out: No symmetry found
>>
>> So the question remains. What is the reason that the symmetry cannot be
>

Re: [QE-users] PDOS for isolated gas molecule

[Paolo Giannozzi]

On Thu, Feb 14, 2019 at 9:18 AM LEUNG Clarence 
wrote:

When I calculate the PDOS for isolated gas molecule by projwfc.x , it stop
> with an error :
>


>  Error in routine  blk2cyc_zredist (1):
>   nb less than the number of proc
>

you have 2x2  matrices (natomwfc x natomwfc), don't use parallel
diagonalization.
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
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] PDOS for isolated gas molecule

[LEUNG Clarence]

Dear QE users,

When I calculate the PDOS for isolated gas molecule by projwfc.x , it stop with 
an error :

 Calling pprojwave 

  Problem Sizes
  natomwfc =2
  nbnd =   24
  nkstot   =  128
  npwx = 6346
  nkb  =4



 %%
 Error in routine  blk2cyc_zredist (1):
  nb less than the number of proc
 %%

 stopping ...

AFAIK, I should increase the nbnd in scf and nscf, right? But I wonder that is 
the nbnd will affect the final PDOS of H2 ?

Thanks a lot
Clarence
City University of Hong Kong

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

Re: [QE-users] Problem with tetrahedra method: from tetra_init : error # 26, cannot remap grid on k-point list

[Oleksandr Motornyi]

Hello Pacome and Pietro,

I can confirm that tetrahedra_opt works for the 2D k-point meshes, both 
for scf/nscf and dos.x/projwfc.x calculations, so it should be 
implemented at least in some way. The other thing is that I am not 
convinced with the credibility of results I obtain, but it is a 
different story.


Regards,

Oleksandr

Oleksandr Motornyi
PhD

Laboratoire des Solides Irradies
Ecole Polytechnique (Palaiseau, France)

On 02/14/2019 08:58 AM, Pietro Davide Delugas wrote:

Hello Pacome

using qe-6.3  you can actually run the nscf  calculation without 
specifying occupation=tetrahedra leave smearing or  whatever else and  
just take care to check that you are computing as many bands you need, 
which as I read you are already doing specifying nbnd.
In the dos.x input  you have just to add the option bz_sum = 
'tetrahedra_opt'.


if you use qe-6.3 remember that the format of xml and charge density 
files are different from those of 6.2 and older versions, so you have 
to rerun the scf computation as well.


One thing that I notice now is that you are using a 9X9X1 mesh, I am 
not sure whether 2D version of the method is actually implemented in 
Q.E. you could try using a 9X9X2 mesh and see if that works.


greetings - Pietro



On 02/14/2019 01:03 AM, Pacome NGUIMEYA wrote:

Hi all,

I have been trying to run the calculation of the Density of State 
(DOS) for TaAs using *QE-6.1* but It always crashes and returns the 
following error message:


     task #         6
     from tetra_init : error #        26
     cannot remap grid on k-point list

There are several forums on this subject where many workaround have 
been proposed.


I went through all of them and I tried each of the proposed 
workaround that I found, but none of them could solve the problem.


Neither adding bands *(ndnd=144)* nor *the increase of the 
convergence threshold to 1.0e-11* worked 
(http://blog.sina.com.cn/s/blog_5f15ead20100cw4d.html), not even the 
workaround propose by Prof Paolo Giannozzi here 
https://www.mail-archive.com/users@lists.quantum-espresso.org/msg32997.html


I even *changed the version of quantum espresso*; I used *QE 5.4*, 
*6.2* and *6.3* but I keep getting errors


with *QE-5.4* and *QE-6.2* I am getting the following error

     task #        21
     from tetrahedra : error #        26
     cannot remap grid on k-point list

 and this one with *QE-6.3*

     task #         0
     from pw_readfile : error #         1
     error opening xml data file

In the *particular case* of *QE-6.3* the *problem seems to be solved* 
but it looks like the program *can not find the xml file*; *it looks 
like it does not exist*.


I am using the CHPC(centre for high performance computing)'s cluster 
to run my calculations


I need your help to sort this out

Is it possible to calculate the DOS with *occupations = 'smearing', 
smearing = 'M-P', degauss = 0.011* and with the *automatically chosen 
k-points 9 9 1* 1 1 1 instead of *occupations = 'tetrahedra'* with 
*k-points 9 9 1* 1 1 1.


 I look forward to hearing from you,

 Below is my input file (also attached to this email)


&CONTROL
 calculation = 'nscf',
    prefix = 'TaAs',
restart_mode = 'from_scratch',
pseudo_dir = '/...,
outdir = '/...,
     etot_conv_thr = 1.0e-5,
wf_collect = .true.,
 /
&SYSTEM
 ibrav = 7,
 A = 3.4348002616,
 B = 3.4348002616,
 C = 11.641,
     cosAB = 0,
     cosAC = 0,
     cosBC = 0,
 nat = 8,
ntyp = 2,
nbnd = 72,
 ecutwfc = 70,
 ecutrho = 400,
occupations = 'tetrahedra',
 /
&ELECTRONS
          conv_thr = 1.0e-11,
       mixing_mode = 'plain',
 mixing_beta = 0.7,
 diagonalization = 'cg',
 /
 ATOMIC_SPECIES
   Ta   180.94788 Ta.pbe-spn-kjpaw_psl.0.2.UPF
   As   74.9216 As.pbe-n-kjpaw_psl.0.2.UPF
 ATOMIC_POSITIONS {crystal}
Ta       0.256888939 -0.145590417  -0.031926398
Ta       0.575434474  0.440904275   0.567465416
Ta      -0.284237537  0.808259399   0.316294705
Ta       0.027951774  0.396761377   0.919029854
As       0.041545914 -0.136018486   0.451188370
As       0.704536879  0.274274640   0.880297072
As       0.172406031  0.385662500   0.492672865
As       0.505473527 -0.024253289   0.072978100
 K_POINTS {automatic}
  9 9 1  1 1 1

 Regards,
 Pacome
*___**_
*Pacome NGUIMEYA
Ph.D. Candidate
Computational Condensed Matter Physics
University of Cape Town (UCT), South Africa
*/“Be Yourself; everyone else is already taken.”///*
*/Oscar Wilde/*


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





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


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