Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Davide 
Me too I use 14.02
Everything work fine 
Thanks a lot to everyone 
Dearly 
Lorenzo 

Inviato da iPhone

> Il giorno 21 set 2016, alle ore 13:50, Davide Ceresoli 
>  ha scritto:
> 
> Dear Lorenzo's,
> I've just tested GIPAW with QE snapshot of Sep 19,
> and I haven't got any crash like the one reported.
> I'm using Intel compiler 2015.0.3.
> 
> Best,
>     Davide
> 
> 
> 
>> On 09/20/2016 01:59 PM, Lori 91 wrote:
>> Dear Lorenzo
>> Thanks a lot after I will try
>> Thanks again
>> Dearly
>> Lorenzo
>> 
>> Inviato da iPhone
>> 
>> Il giorno 20 set 2016, alle ore 13:37, Lorenzo Paulatto
>> mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
>> scritto:
>> 
>>> You can get the last development version from here:
>>> http://qe-forge.org/snapshots/
>>> 
>>> On Tue, Sep 20, 2016 at 12:27 PM Lori 91 >> <mailto:lorechimic...@hotmail.it>> wrote:
>>> 
>>>Dear Lorenzo thanks a lot
>>>Now XSpectra work fine problem solved.
>>>and for GIPAW must I wait the version of QE
>>>Dearly and thanks again to help me.
>>>lorenzo
>>> 
>>>>Il giorno 20 set 2016, alle ore 11:48, Lorenzo Paulatto
>>>>mailto:lorenzo.paula...@impmc.upmc.fr>>
>>>>ha scritto:
>>>> 
>>>>DO is = 1,nrc
>>>>aux(is) = rgrid(xiabs)%r(is) * &
>>>> paw_recon(xiabs)%aephi(ip)%psi(is) * &
>>>> core_wfn(is)
>>>>ENDDO
>>> 
>>>___
>>>Pw_forum mailing list
>>>Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
>>>http://pwscf.org/mailman/listinfo/pw_forum
>>> 
>>> ___
>>> Pw_forum mailing list
>>> Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
>>> http://pwscf.org/mailman/listinfo/pw_forum
> 
> -- 
> +--+
>   Davide Ceresoli
>   CNR Institute of Molecular Science and Technology (CNR-ISTM)
>   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
>   Email: davide.ceres...@cnr.it
>   Phone: +39-02-50314276, +39-347-1001570 (mobile)
>   Skype: dceresoli
>   Website: http://sites.google.com/site/dceresoli/
> +--+
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

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

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Lorenzo
Thanks a lot after I will try
Thanks again
Dearly
Lorenzo

Inviato da iPhone

Il giorno 20 set 2016, alle ore 13:37, Lorenzo Paulatto 
mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
scritto:

You can get the last development version from here:
http://qe-forge.org/snapshots/

On Tue, Sep 20, 2016 at 12:27 PM Lori 91 
mailto:lorechimic...@hotmail.it>> wrote:
Dear Lorenzo thanks a lot
Now XSpectra work fine problem solved.
and for GIPAW must I wait the version of QE
Dearly and thanks again to help me.
lorenzo

Il giorno 20 set 2016, alle ore 11:48, Lorenzo Paulatto 
mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
scritto:

DO is = 1,nrc
aux(is) = rgrid(xiabs)%r(is) * &
 paw_recon(xiabs)%aephi(ip)%psi(is) * &
 core_wfn(is)
ENDDO

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

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Lorenzo thanks a lot
Now XSpectra work fine problem solved.
and for GIPAW must I wait the version of QE
Dearly and thanks again to help me.
lorenzo
Il giorno 20 set 2016, alle ore 11:48, Lorenzo Paulatto 
mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
scritto:

DO is = 1,nrc
aux(is) = rgrid(xiabs)%r(is) * &
 paw_recon(xiabs)%aephi(ip)%psi(is) * &
 core_wfn(is)
ENDDO

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

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Lorenzo
I replaced  Real(dp), Intent(in) :: y(:),x(:) with  Real(dp), Intent(in) :: 
y(n),x(n) and recompiled xspectra but the problem it’s the same i found 
segmentation fault.
Thanks to help me with this problem
dearly
lorenzo
Il giorno 19 set 2016, alle ore 16:37, Lori 91 
mailto:lorechimic...@hotmail.it>> ha scritto:

Hi Lorenzo
I tried on Ubuntu 14.04 LTS with ifort 14.02 and 16.01 and 16.02 and the 
problem it is the same.
On my personal Mac I compiled the serial version of QE 5.4 with Intel compiler 
16.02 and I found no problem in XSpectra and GIPAW
Now I will try what you told me and I will wait the new version of QE
Thanks a lot
Lorenzo


Il giorno 19 set 2016, alle ore 14:36, Lorenzo Paulatto 
mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
scritto:

Hello Lorenzo,
the issue about GIPAW comes fro ma mismatch of internal indexes, it is actually 
fixed in the development version. The XSpectra one is a bit more tricky, it 
appears to only come on ifort 13 with vectorization turned on (which is the 
default), or maybe a mix of explicit and implicit array size. A quick 
workaround (try it please, and let me know if it also works for you) is to 
change line 19 of radin_mod.f90 from
Real(dp), Intent(in) :: y(:),x(:)
to
Real(dp), Intent(in) :: y(n),x(n)

thank you for reporting!

On 24 May 2016 at 18:48, Lorenzo Donà 
mailto:lorechimic...@hotmail.it>> wrote:
Dear all I have configured QE 5.4 on ubuntu 12.04 in this way :
./configure MPIF90=mpiifort FC=ifort F77=ifort CC=icc CXX=icpc 
-with-internal-blas -with-intenal-lapack

and I have run PW and Phonon examples without problem but when I run XSpectra 
examples i found 3 segmentation fault of this type for diamond SiO2 NiO but not 
segmentation fault occurred for Cu_L23:

Image  PCRoutineLineSource
xspectra.x 00AB9319  Unknown   Unknown  Unknown
xspectra.x 00AB7BEE  Unknown   Unknown  Unknown
xspectra.x 00A60252  Unknown   Unknown  Unknown
xspectra.x 009F47D3  Unknown   Unknown  Unknown
xspectra.x 009FB9AB  Unknown   Unknown  Unknown
libpthread.so.07F336DC6F340  Unknown   Unknown  Unknown
xspectra.x 00437000  xanes_dipole_ 143  
xanes_dipole.f90
xspectra.x 00405E3E  MAIN__308  xspectra.f90
xspectra.x 00403BA6  Unknown   Unknown  Unknown
libc.so.6  7F336D5B5EC5  Unknown   Unknown  Unknown
xspectra.x 00403A99  Unknown   Unknown  Unknown
Error condition encountered during test: exit status = 174
Aborting

also for GIPAW modules I found segmentation fault of this type for quartz 
H2O_environ H2O+ benzene-USPP but not for benzene-NCPP:

  Computing the magnetic susceptibility isolve=0ethr=  0.1000E-13
 k-point #1 of 1  pool #  1cpu time:   7.3
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
gipaw.x00B2ADF9  Unknown   Unknown  Unknown
gipaw.x00B296CE  Unknown   Unknown  Unknown
gipaw.x00AD1D92  Unknown   Unknown  Unknown
gipaw.x00A66313  Unknown   Unknown  Unknown
gipaw.x00A6D4EB  Unknown   Unknown  Unknown
libpthread.so.07F0187E4D340  Unknown   Unknown  Unknown
gipaw.x004D357E  gen_us_dj_ 68  
gen_us_dj.f90
gipaw.x0044C861  paramagnetic_corr 323  
nmr_routines.f90
gipaw.x0042E8A6  suscept_crystal_I 470  
suscept_crystal.f90
gipaw.x0042A757  suscept_crystal_  218  
suscept_crystal.f90
gipaw.x00403FF3  MAIN__146  
gipaw_main.f90
gipaw.x00403BA6  Unknown   Unknown  Unknown
libc.so.6  7F0187793EC5  Unknown   Unknown  Unknown
gipaw.x00403A99  Unknown   Unknown  Unknown

I need to do EPR and NMR.
Please can you help me to solve these problems.

Thanks a lot to help me.

lorenzo donà

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



--
Dr. Lorenzo Paulatto
IdR @ IMPMC -- CNRS & Université Paris 6
phone: +33 (0)1 44275 084 / skype: paulatz
www:   http://www-int.impmc.upmc.fr/~paulatto/
mail:  23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05
___
Pw_forum mailing list
Pw_forum@pwscf.org<mailto:Pw_forum@pwscf.org>
http://p

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Hi Lorenzo
I tried on Ubuntu 14.04 LTS with ifort 14.02 and 16.01 and 16.02 and the 
problem it is the same.
On my personal Mac I compiled the serial version of QE 5.4 with Intel compiler 
16.02 and I found no problem in XSpectra and GIPAW
Now I will try what you told me and I will wait the new version of QE
Thanks a lot
Lorenzo


Il giorno 19 set 2016, alle ore 14:36, Lorenzo Paulatto 
mailto:lorenzo.paula...@impmc.upmc.fr>> ha 
scritto:

Hello Lorenzo,
the issue about GIPAW comes fro ma mismatch of internal indexes, it is actually 
fixed in the development version. The XSpectra one is a bit more tricky, it 
appears to only come on ifort 13 with vectorization turned on (which is the 
default), or maybe a mix of explicit and implicit array size. A quick 
workaround (try it please, and let me know if it also works for you) is to 
change line 19 of radin_mod.f90 from
Real(dp), Intent(in) :: y(:),x(:)
to
Real(dp), Intent(in) :: y(n),x(n)

thank you for reporting!

On 24 May 2016 at 18:48, Lorenzo Don? 
mailto:lorechimic...@hotmail.it>> wrote:
Dear all I have configured QE 5.4 on ubuntu 12.04 in this way :
./configure MPIF90=mpiifort FC=ifort F77=ifort CC=icc CXX=icpc 
-with-internal-blas -with-intenal-lapack

and I have run PW and Phonon examples without problem but when I run XSpectra 
examples i found 3 segmentation fault of this type for diamond SiO2 NiO but not 
segmentation fault occurred for Cu_L23:

Image  PCRoutineLineSource
xspectra.x 00AB9319  Unknown   Unknown  Unknown
xspectra.x 00AB7BEE  Unknown   Unknown  Unknown
xspectra.x 00A60252  Unknown   Unknown  Unknown
xspectra.x 009F47D3  Unknown   Unknown  Unknown
xspectra.x 009FB9AB  Unknown   Unknown  Unknown
libpthread.so.07F336DC6F340  Unknown   Unknown  Unknown
xspectra.x 00437000  xanes_dipole_ 143  
xanes_dipole.f90
xspectra.x 00405E3E  MAIN__308  xspectra.f90
xspectra.x 00403BA6  Unknown   Unknown  Unknown
libc.so.6  7F336D5B5EC5  Unknown   Unknown  Unknown
xspectra.x 00403A99  Unknown   Unknown  Unknown
Error condition encountered during test: exit status = 174
Aborting

also for GIPAW modules I found segmentation fault of this type for quartz 
H2O_environ H2O+ benzene-USPP but not for benzene-NCPP:

  Computing the magnetic susceptibility isolve=0ethr=  0.1000E-13
 k-point #1 of 1  pool #  1cpu time:   7.3
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
gipaw.x00B2ADF9  Unknown   Unknown  Unknown
gipaw.x00B296CE  Unknown   Unknown  Unknown
gipaw.x00AD1D92  Unknown   Unknown  Unknown
gipaw.x00A66313  Unknown   Unknown  Unknown
gipaw.x00A6D4EB  Unknown   Unknown  Unknown
libpthread.so.07F0187E4D340  Unknown   Unknown  Unknown
gipaw.x004D357E  gen_us_dj_ 68  
gen_us_dj.f90
gipaw.x0044C861  paramagnetic_corr 323  
nmr_routines.f90
gipaw.x0042E8A6  suscept_crystal_I 470  
suscept_crystal.f90
gipaw.x0042A757  suscept_crystal_  218  
suscept_crystal.f90
gipaw.x00403FF3  MAIN__146  
gipaw_main.f90
gipaw.x00403BA6  Unknown   Unknown  Unknown
libc.so.6  7F0187793EC5  Unknown   Unknown  Unknown
gipaw.x00403A99  Unknown   Unknown  Unknown

I need to do EPR and NMR.
Please can you help me to solve these problems.

Thanks a lot to help me.

lorenzo don?

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



--
Dr. Lorenzo Paulatto
IdR @ IMPMC -- CNRS & Universit? Paris 6
phone: +33 (0)1 44275 084 / skype: paulatz
www:   http://www-int.impmc.upmc.fr/~paulatto/
mail:  23-24/4?16 Bo?te courrier 115, 4 place Jussieu 75252 Paris C?dex 05
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Wyckoff Positions in diamond

[Lori 91]

Thanks a lot 
I understood
Dearly 
Lorenzo 

Inviato da iPhone

> Il giorno 02 lug 2016, alle ore 17:07, Manu Hegde  ha 
> scritto:
> 
> please look at crystallography server, your wykoff site 8a can generate only 
> two atomic positions or coordinates (in FCC). In simple cubic form it can 
> generate 8 atoms.
> 
> hope it helps.
> 
>> On Sat, Jul 2, 2016 at 3:08 AM, Lorenzo Donà  
>> wrote:
>> Good morning to everyone.
>> I have some problem with Wyckoff Positions…..
>> this is my input but in the output i found only 2 atoms and not 8…..
>> Someone can tell me where i make a mistake??
>> &control
>> pseudo_dir='/Users/lorenzodona/Downloads/espresso-5.4.0/pseudo'
>> verbosity= high,
>> /
>>  &system
>> a= 3.56679, space_group = 227,
>> nat=  1, ntyp= 1,
>> ecutwfc =15.0,
>> /
>>  &electrons
>> mixing_beta = 0.7
>>  /
>> ATOMIC_SPECIES
>> C 12.010 C.pbe-van_ak.UPF
>> ATOMIC_POSITIONS crystal_sg
>> C 8a
>> K_POINTS automatic
>> 4 4 4 0 0 0
>> 
>> Thanks a lot
>> lorenzo 
>> 
>> ___
>> Pw_forum mailing list
>> Pw_forum@pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] how to define celldm(4) or cos(ab) for monoclinic system.

[Lori 91]

Thanks a lot Stefano but in My caluclation with space group 15 must I put 
ubiqueb=.true.???
Thanks a lot 

Inviato da iPhone

> Il giorno 30 giu 2016, alle ore 18:25, Stefano de Gironcoli 
>  ha scritto:
> 
> The code assumes that the non-right angle is gamma= the angle between a and b 
> axes. 
> Hence A=6.63.. B=21.09.. C=6.10.. cosab=cos(115.39..)
> 
> stefano 
> (sent from my phone)
> 
>> On 30 Jun 2016, at 18:05, Lorenzo Donà  wrote:
>> 
>> Dear all I really hate no idea how to define cilldm(4) or cosab I have 
>> searched in pw.x mail archive and red the pw.x input documentations but 
>> really i don’t understand how to define it.
>> I have a system with this lattice parameters:
>>   A   B   CALPHABETA   GAMMA
>> 21.09173 6.10720 6.6360590.0   115.3935890.0
>> Excuse for the really stupid question but i really don’t understand.
>> Thanks a lot
>> dearly 
>> lorenzo
>> ___
>> Pw_forum mailing list
>> Pw_forum@pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] monoclinic system number of atom generated is incorrect

[Lori 91]

Dear Paolo 
Just another thing for example how to define it for a monoclinic structure 
Thanks really a lot
Dearly
Lorenzo 

Inviato da iPhone

> Il giorno 11 giu 2016, alle ore 09:39, Lori 91  ha 
> scritto:
> 
> Dear Paolo i wish know how to define the lattice vector to put in 
> CELL_PARAMETERS I wish to know how to calculate v1 v2 and v3 because I have 
> read tha pwscf input documentation but I don't understand how to define them 
> Thanks a lot 
> Lorenzo 
> 
> Inviato da iPhone
> 
>>> Il giorno 11 giu 2016, alle ore 08:44, Paolo Giannozzi 
>>>  ha scritto:
>>> 
>>> On Wed, Jun 8, 2016 at 9:08 PM, Lorenzo Donà  
>>> wrote:
>>> 
>>> where or how can i find the Bravais lattice vectors for a system??
>> 
>> what do you mean? they aren't uniquely defined. The specific choice
>> done by QE is described in the input documentation and reprinted on
>> output.
>> 
>> -- 
>> 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
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

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

Re: [Pw_forum] monoclinic system number of atom generated is incorrect

[Lori 91]

Dear Paolo i wish know how to define the lattice vector to put in 
CELL_PARAMETERS I wish to know how to calculate v1 v2 and v3 because I have 
read tha pwscf input documentation but I don't understand how to define them 
Thanks a lot 
Lorenzo 

Inviato da iPhone

> Il giorno 11 giu 2016, alle ore 08:44, Paolo Giannozzi 
>  ha scritto:
> 
>> On Wed, Jun 8, 2016 at 9:08 PM, Lorenzo Donà  
>> wrote:
>> 
>> where or how can i find the Bravais lattice vectors for a system??
> 
> what do you mean? they aren't uniquely defined. The specific choice
> done by QE is described in the input documentation and reprinted on
> output.
> 
> -- 
> 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

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

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Thanks to replay Davide.
cosab=-0.5 give me an error.
Thanks a lot dearly 
Lorenzo 

Inviato da iPhone

> Il giorno 31 mag 2016, alle ore 09:16, Tiana Davide  ha 
> scritto:
> 
> Ciao Lorenzo
> 
> I am not sure but one problem could be that you're using cosab 0.5 (60 
> degrees) instead of cosab=-0.5 (120 degrees)
> another one (again just a guess) is your cut-off seems to be really low even 
> for an ultrasoft pseudopotential.
> 
> anyway, you should try with this electron setting
> 
>   mixing_mode='local-TF',   
>   mixing_beta=0.6,
> 
> I've not problem in converging it (using different pseudo though)
> 
> Cheers
> Davide
> 
> P.S. the last test you can do is to use a bit of smearing, for instance:
> 
>   occupations='smearing',
>   smearing='marzari-vanderbilt'
>   degauss=0.05 
> 
> --
> 
> Message: 2
> Date: Sun, 29 May 2016 21:11:49 +0200
> From: Lorenzo Don? 
> Subject: [Pw_forum] CPO-27-Zn scf not converge
> To: PWSCF Forum 
> Message-ID: 
> Content-Type: text/plain; charset="us-ascii"
> 
> Dear all can you help me or give me some tips to make scf convergence on this 
> calculation:
> 
> &control
>pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>outdir = './',
>wf_collect = .true.,
>verbosity= high,
> /
> &system
>ibrav=  5,
>a= 25.226, cosab= 0.5,  space_group = 148,
>nat=  9, ntyp= 4,
>ecutwfc =15.0,
>occupations='fixed', smearing='gauss',
> input_dft= PBE,
> /
> &electrons
>mixing_mode='plain'
>diagonalization='david'
>mixing_beta = 0.01
>conv_thr= 1.0e-4
>electron_maxstep=500,
> /
> ATOMIC_SPECIES
> Zn 65.409 Zn.pbe-van.UPF
> C 12.010  C.pbe-van_ak.UPF
> O 16.00   O.pbe-van_ak.UPF
> H 1.00H.pbe-van_ak.UPF
> ATOMIC_POSITIONS crystal_sg
>  C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>  C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>  C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>  C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>  H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>  O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>  O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>  O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
> K_POINTS gamma
> 
> Thanks a lot to help me
> 
> dearly
> 
> lorenzo
> 
> 
> 
> ___
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

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

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Dear Paolo 
Thanks to help me now I have understood thanks a lot.
But can you tell why my structure is not correctly visualized from xcrysden or 
jice??
Thanks a lot again 
Dearly
Lorenzo 

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 22:42, Paolo Giannozzi 
>  ha scritto:
> 
> The cell you report is Hexagonal and is defined by two parameters, a
> and c. Space group 148 has a trigonal (R) lattice, defined by
> parameter a and alpha = angle between two vectors. You should figure
> out which alpha for the trigonal lattice corresponds to your hexagonal
> cell, then you provide in input a (in A) and cosab=cos(alpha); or,
> equivalently, celldm(1)=a (in a.u.) and celldm(4)=cos(alpha). See
> here: 
> http://www.quantum-espresso.org/wp-content/uploads/Doc/INPUT_PW.html#idm6425376
> for definition of lattices in PW, here for the two descriptions of
> space group 148:
> http://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-wp-list?gnum=148&grha=rhombohedral
> http://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-wp-list?gnum=148&grha=hexagonal
> Hard to say if your atomic positions are correct, but chemical formula
> Zn_6 C_24 O_18 H_6 looks strange to me
> 
> Paolo
> 
>> On Mon, May 30, 2016 at 7:42 PM, Lorenzo Donà  
>> wrote:
>> Dear Paolo thanks for your replay and to help me
>> this is an hexagonal space group there are 54 atoms in the cell and it is
>> correct.
>> Space group R-3 with 9 atoms in the asymmetric unit cell with this cell
>> parameters for my system:
>> 26.2256326.22563 6.9552990.090.0   120.0
>> But when i open the output with xcrysden for this system i found only atoms
>> without connectivity.
>> This appears only for system like hexagonal or other system where i must put
>> coasb or cosbc etc…. in the input.
>> can you tell me where my input is wrong???
>> this is my input:
>> 
>> &control
>> 
>>pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>> 
>>wf_collect = .true.,
>> 
>>verbosity= high,
>> 
>> /
>> 
>> &system
>> 
>>a= 25.226, cosab= 0.5, space_group = 148,
>> 
>>nat=  9, ntyp= 4,
>> 
>>ecutwfc =15.0,
>> 
>>   occupations='smearing', smearing='marzari-vanderbilt', degauss=0.07
>> 
>>   input_dft= PBE,
>> 
>> /
>> 
>> &electrons
>> 
>>mixing_mode='TF'
>> 
>>diagonalization='cg'
>> 
>>mixing_beta = 0.1
>> 
>>conv_thr= 1.0e-7
>> 
>>electron_maxstep=500,
>> 
>> /
>> 
>> ATOMIC_SPECIES
>> 
>> Zn 65.409 Zn.pbe-van.UPF
>> 
>> C 12.010  C.pbe-van_ak.UPF
>> 
>> O 16.00   O.pbe-van_ak.UPF
>> 
>> H 1.00H.pbe-van_ak.UPF
>> 
>> ATOMIC_POSITIONS crystal_sg
>> 
>>  C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>> 
>>  C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>> 
>>  C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>> 
>>  C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>> 
>>  H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>> 
>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>> 
>>  O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>> 
>>  O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>> 
>>  O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>> 
>> K_POINTS gamma
>> 
>> 
>> thanks a lot very very to help me.
>> dearly
>> lorenzo
>> 
>> Il giorno 30 mag 2016, alle ore 18:51, Paolo Giannozzi
>>  ha scritto:
>> 
>> You must provide what is needed: the space group number specifies the
>> lattice and the allowed atomic sites and symmetries, so you have to
>> specify
>> - the lattice parameter(s) for your lattice: either celldm, or a,b,c,
>> as described in the input documentation;
>> - the occupied sites, with the free parameter(s) (if any) of each site
>> (also described in the documentation of the input).
>> You find the information you need for your group in the Bilbao
>> Crystallographic server. If it is group 148, it can be described
>> either as hexagonal or as rhombohedra (see also option "rhombohedral":
>> I think hexagonal has 3 times the atoms of rhombohedral, so you should
>> use the latter)
>> 
>> Paolo
>> 
>> On Mon, May 30, 2016 at 5:50 PM, Lori 91  wrote:
>> 
>&

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Dear Paolo sorry if bother you again I found Wyckoff positions for my space 
group but I don't understand how to put in in my quantum espresso input??
Thanks again 
Dearly 
Lorenzo 

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 14:31, Paolo Giannozzi 
>  ha scritto:
> 
> You need to know the space group number and the Wyckoff positions of
> your crystal. Don't specify "ibrav", set "nat" to the number of
> inequivalent sites, list those inequivalent sites ufter
> ATOMIC_POSITIONS crystal_sg as explained in the documentation
> 
> 
> Paolo
> 
>> On Mon, May 30, 2016 at 12:43 PM, Lori 91  wrote:
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 12:37, Lori 91  ha
>> scritto:
>> 
>> 
>> 
>> Inviato da iPhone
>> 
>> (Inizio messaggio inoltrato)
>> 
>> Da: Lori 91 
>> Data: 30 maggio 2016 11:23:46 CEST
>> A: Giuseppe Mattioli 
>> Oggetto: Re: [Pw_forum] CPO-27-Zn scf not converge
>> 
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 11:02, Giuseppe Mattioli
>>  ha scritto:
>> 
>> 
>> 
>> Dear Lorenzo
>> 
>> Sorry, I'm not familiar with the new crystal_sg coordinates, but it seems to
>> me that there is something strange in the structure. I suggest that you
>> 
>> "fill the unit cell" with all the equivalent atoms (Avogadro or Vesta can do
>> it for you) and check the results to be sure that you are calculating
>> 
>> exactly what you want. If pw.x fills the unit cell and write the resulting
>> alat coordinates of all atoms (as usual), then you may directly check them
>> 
>> with xcrysden. You might try to run the job with the full structure and
>> simple "crystal" coordinates. Maybe something goes wrong when the code try
>> to
>> 
>> fill the unit cell in the crystal_sg case. Anyway I suppose that there is no
>> computational gain in using the crystal_sg coordinates ("no free lunch"
>> 
>> :-)).
>> 
>> HTH
>> 
>> Giuseppe
>> 
>> 
>> 
>> On Sunday, May 29, 2016 09:11:49 PM Lorenzo Donà wrote:
>> 
>> Dear all can you help me or give me some tips to make scf convergence on
>> this calculation:
>> 
>> 
>> &control
>> 
>>  pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>> 
>>  outdir = './',
>> 
>>  wf_collect = .true.,
>> 
>>  verbosity= high,
>> 
>> /
>> 
>> &system
>> 
>>  ibrav=  5,
>> 
>>  a= 25.226, cosab= 0.5,  space_group = 148,
>> 
>>  nat=  9, ntyp= 4,
>> 
>>  ecutwfc =15.0,
>> 
>>  occupations='fixed', smearing='gauss',
>> 
>>   input_dft= PBE,
>> 
>> /
>> 
>> &electrons
>> 
>>  mixing_mode='plain'
>> 
>>  diagonalization='david'
>> 
>>  mixing_beta = 0.01
>> 
>>  conv_thr= 1.0e-4
>> 
>>  electron_maxstep=500,
>> 
>> /
>> 
>> ATOMIC_SPECIES
>> 
>> Zn 65.409 Zn.pbe-van.UPF
>> 
>> C 12.010  C.pbe-van_ak.UPF
>> 
>> O 16.00   O.pbe-van_ak.UPF
>> 
>> H 1.00H.pbe-van_ak.UPF
>> 
>> ATOMIC_POSITIONS crystal_sg
>> 
>> C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>> 
>> C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>> 
>> C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>> 
>> C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>> 
>> H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>> 
>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>> 
>> O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>> 
>> O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>> 
>> O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>> 
>> K_POINTS gamma
>> 
>> 
>> Thanks a lot to help me
>> 
>> 
>> dearly
>> 
>> 
>> lorenzo
>> 
>> 
>> 
>> 
>> - Article premier - L

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Dear Paolo in the input must I put a and cosab or not with space group keyword??

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 14:31, Paolo Giannozzi 
>  ha scritto:
> 
> You need to know the space group number and the Wyckoff positions of
> your crystal. Don't specify "ibrav", set "nat" to the number of
> inequivalent sites, list those inequivalent sites ufter
> ATOMIC_POSITIONS crystal_sg as explained in the documentation
> 
> 
> Paolo
> 
>> On Mon, May 30, 2016 at 12:43 PM, Lori 91  wrote:
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 12:37, Lori 91  ha
>> scritto:
>> 
>> 
>> 
>> Inviato da iPhone
>> 
>> (Inizio messaggio inoltrato)
>> 
>> Da: Lori 91 
>> Data: 30 maggio 2016 11:23:46 CEST
>> A: Giuseppe Mattioli 
>> Oggetto: Re: [Pw_forum] CPO-27-Zn scf not converge
>> 
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 11:02, Giuseppe Mattioli
>>  ha scritto:
>> 
>> 
>> 
>> Dear Lorenzo
>> 
>> Sorry, I'm not familiar with the new crystal_sg coordinates, but it seems to
>> me that there is something strange in the structure. I suggest that you
>> 
>> "fill the unit cell" with all the equivalent atoms (Avogadro or Vesta can do
>> it for you) and check the results to be sure that you are calculating
>> 
>> exactly what you want. If pw.x fills the unit cell and write the resulting
>> alat coordinates of all atoms (as usual), then you may directly check them
>> 
>> with xcrysden. You might try to run the job with the full structure and
>> simple "crystal" coordinates. Maybe something goes wrong when the code try
>> to
>> 
>> fill the unit cell in the crystal_sg case. Anyway I suppose that there is no
>> computational gain in using the crystal_sg coordinates ("no free lunch"
>> 
>> :-)).
>> 
>> HTH
>> 
>> Giuseppe
>> 
>> 
>> 
>> On Sunday, May 29, 2016 09:11:49 PM Lorenzo Donà wrote:
>> 
>> Dear all can you help me or give me some tips to make scf convergence on
>> this calculation:
>> 
>> 
>> &control
>> 
>>  pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>> 
>>  outdir = './',
>> 
>>  wf_collect = .true.,
>> 
>>  verbosity= high,
>> 
>> /
>> 
>> &system
>> 
>>  ibrav=  5,
>> 
>>  a= 25.226, cosab= 0.5,  space_group = 148,
>> 
>>  nat=  9, ntyp= 4,
>> 
>>  ecutwfc =15.0,
>> 
>>  occupations='fixed', smearing='gauss',
>> 
>>   input_dft= PBE,
>> 
>> /
>> 
>> &electrons
>> 
>>  mixing_mode='plain'
>> 
>>  diagonalization='david'
>> 
>>  mixing_beta = 0.01
>> 
>>  conv_thr= 1.0e-4
>> 
>>  electron_maxstep=500,
>> 
>> /
>> 
>> ATOMIC_SPECIES
>> 
>> Zn 65.409 Zn.pbe-van.UPF
>> 
>> C 12.010  C.pbe-van_ak.UPF
>> 
>> O 16.00   O.pbe-van_ak.UPF
>> 
>> H 1.00H.pbe-van_ak.UPF
>> 
>> ATOMIC_POSITIONS crystal_sg
>> 
>> C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>> 
>> C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>> 
>> C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>> 
>> C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>> 
>> H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>> 
>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>> 
>> O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>> 
>> O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>> 
>> O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>> 
>> K_POINTS gamma
>> 
>> 
>> Thanks a lot to help me
>> 
>> 
>> dearly
>> 
>> 
>> lorenzo
>> 
>> 
>> 
>> 
>> - Article premier - Les hommes naissent et demeurent
>> 
>> libres et égaux en droits. Les distinctions sociales
>&g

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Sorry my message is uncompleted
Thanks to help me
Dearly 
Lorenzo 

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 14:31, Paolo Giannozzi 
>  ha scritto:
> 
> You need to know the space group number and the Wyckoff positions of
> your crystal. Don't specify "ibrav", set "nat" to the number of
> inequivalent sites, list those inequivalent sites ufter
> ATOMIC_POSITIONS crystal_sg as explained in the documentation
> 
> 
> Paolo
> 
>> On Mon, May 30, 2016 at 12:43 PM, Lori 91  wrote:
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 12:37, Lori 91  ha
>> scritto:
>> 
>> 
>> 
>> Inviato da iPhone
>> 
>> (Inizio messaggio inoltrato)
>> 
>> Da: Lori 91 
>> Data: 30 maggio 2016 11:23:46 CEST
>> A: Giuseppe Mattioli 
>> Oggetto: Re: [Pw_forum] CPO-27-Zn scf not converge
>> 
>> Someone can help me to use correctly crystal_sg and space group number
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot
>> 
>> Inviato da iPhone
>> 
>> Il giorno 30 mag 2016, alle ore 11:02, Giuseppe Mattioli
>>  ha scritto:
>> 
>> 
>> 
>> Dear Lorenzo
>> 
>> Sorry, I'm not familiar with the new crystal_sg coordinates, but it seems to
>> me that there is something strange in the structure. I suggest that you
>> 
>> "fill the unit cell" with all the equivalent atoms (Avogadro or Vesta can do
>> it for you) and check the results to be sure that you are calculating
>> 
>> exactly what you want. If pw.x fills the unit cell and write the resulting
>> alat coordinates of all atoms (as usual), then you may directly check them
>> 
>> with xcrysden. You might try to run the job with the full structure and
>> simple "crystal" coordinates. Maybe something goes wrong when the code try
>> to
>> 
>> fill the unit cell in the crystal_sg case. Anyway I suppose that there is no
>> computational gain in using the crystal_sg coordinates ("no free lunch"
>> 
>> :-)).
>> 
>> HTH
>> 
>> Giuseppe
>> 
>> 
>> 
>> On Sunday, May 29, 2016 09:11:49 PM Lorenzo Donà wrote:
>> 
>> Dear all can you help me or give me some tips to make scf convergence on
>> this calculation:
>> 
>> 
>> &control
>> 
>>  pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>> 
>>  outdir = './',
>> 
>>  wf_collect = .true.,
>> 
>>  verbosity= high,
>> 
>> /
>> 
>> &system
>> 
>>  ibrav=  5,
>> 
>>  a= 25.226, cosab= 0.5,  space_group = 148,
>> 
>>  nat=  9, ntyp= 4,
>> 
>>  ecutwfc =15.0,
>> 
>>  occupations='fixed', smearing='gauss',
>> 
>>   input_dft= PBE,
>> 
>> /
>> 
>> &electrons
>> 
>>  mixing_mode='plain'
>> 
>>  diagonalization='david'
>> 
>>  mixing_beta = 0.01
>> 
>>  conv_thr= 1.0e-4
>> 
>>  electron_maxstep=500,
>> 
>> /
>> 
>> ATOMIC_SPECIES
>> 
>> Zn 65.409 Zn.pbe-van.UPF
>> 
>> C 12.010  C.pbe-van_ak.UPF
>> 
>> O 16.00   O.pbe-van_ak.UPF
>> 
>> H 1.00H.pbe-van_ak.UPF
>> 
>> ATOMIC_POSITIONS crystal_sg
>> 
>> C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>> 
>> C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>> 
>> C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>> 
>> C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>> 
>> H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>> 
>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>> 
>> O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>> 
>> O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>> 
>> O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>> 
>> K_POINTS gamma
>> 
>> 
>> Thanks a lot to help me
>> 
>> 
>> dearly
>> 
>> 
>> lorenzo
>> 
>> 
>> 
>> 
>> - Article premier - Les hommes naissent et demeurent
>> 
>> libres et égaux en droits. Les distinctions sociales
>> 
&

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Dear Paolo 
Thanks to replay 
Can you tell me how can I find the Wyckoff positions of my crystal??

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 14:31, Paolo Giannozzi 
>  ha scritto:
> 
> Wyckoff positions

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

Re: [Pw_forum] CPO-27-Zn scf not converge

[Lori 91]

Someone can help me to use correctly crystal_sg and space group number because 
I found a connectivity problem for CPO-27Zn??
Thanks a lot 

Inviato da iPhone

> Il giorno 30 mag 2016, alle ore 12:37, Lori 91  ha 
> scritto:
> 
> 
> 
> Inviato da iPhone
> 
> (Inizio messaggio inoltrato)
> 
>> Da: Lori 91 
>> Data: 30 maggio 2016 11:23:46 CEST
>> A: Giuseppe Mattioli 
>> Oggetto: Re: [Pw_forum] CPO-27-Zn scf not converge
>> 
>> Someone can help me to use correctly crystal_sg and space group number 
>> because I found a connectivity problem for CPO-27Zn??
>> Thanks a lot 
>> 
>> Inviato da iPhone
>> 
>>> Il giorno 30 mag 2016, alle ore 11:02, Giuseppe Mattioli 
>>>  ha scritto:
>>> 
>>> 
>>> Dear Lorenzo
>>> Sorry, I'm not familiar with the new crystal_sg coordinates, but it seems 
>>> to me that there is something strange in the structure. I suggest that you 
>>> "fill the unit cell" with all the equivalent atoms (Avogadro or Vesta can 
>>> do it for you) and check the results to be sure that you are calculating 
>>> exactly what you want. If pw.x fills the unit cell and write the resulting 
>>> alat coordinates of all atoms (as usual), then you may directly check them 
>>> with xcrysden. You might try to run the job with the full structure and 
>>> simple "crystal" coordinates. Maybe something goes wrong when the code try 
>>> to 
>>> fill the unit cell in the crystal_sg case. Anyway I suppose that there is 
>>> no computational gain in using the crystal_sg coordinates ("no free lunch" 
>>> :-)).
>>> HTH
>>> Giuseppe
>>> 
>>> 
>>>> On Sunday, May 29, 2016 09:11:49 PM Lorenzo Donà wrote:
>>>> Dear all can you help me or give me some tips to make scf convergence on 
>>>> this calculation:
>>>> 
>>>> &control
>>>>   pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>>>>   outdir = './',
>>>>   wf_collect = .true.,
>>>>   verbosity= high,
>>>> /
>>>> &system
>>>>   ibrav=  5,
>>>>   a= 25.226, cosab= 0.5,  space_group = 148,
>>>>   nat=  9, ntyp= 4,
>>>>   ecutwfc =15.0,
>>>>   occupations='fixed', smearing='gauss',
>>>>input_dft= PBE,
>>>> /
>>>> &electrons
>>>>   mixing_mode='plain'
>>>>   diagonalization='david'
>>>>   mixing_beta = 0.01
>>>>   conv_thr= 1.0e-4
>>>>   electron_maxstep=500,
>>>> /
>>>> ATOMIC_SPECIES
>>>> Zn 65.409 Zn.pbe-van.UPF
>>>> C 12.010  C.pbe-van_ak.UPF
>>>> O 16.00   O.pbe-van_ak.UPF
>>>> H 1.00H.pbe-van_ak.UPF
>>>> ATOMIC_POSITIONS crystal_sg
>>>> C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>>>> C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>>>> C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>>>> C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>>>> H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>>>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>>>> O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>>>> O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>>>> O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>>>> K_POINTS gamma
>>>> 
>>>> Thanks a lot to help me
>>>> 
>>>> dearly
>>>> 
>>>> lorenzo
>>> 
>>> 
>>> - Article premier - Les hommes naissent et demeurent
>>> libres et égaux en droits. Les distinctions sociales
>>> ne peuvent être fondées que sur l'utilité commune
>>> - Article 2 - Le but de toute association politique
>>> est la conservation des droits naturels et 
>>> imprescriptibles de l'homme. Ces droits sont la liberté,
>>> la propriété, la sûreté et la résistance à l'oppression.
>>> 
>>> 
>>>  Giuseppe Mattioli
>>>  CNR - ISTITUTO DI STRUTTURA DELLA MATERIA   
>>>  v. Salaria Km 29,300 - C.P. 10
>>>  I 00015 - Monterotondo Stazione (RM), Italy
>>>  Tel + 39 06 90672342 - Fax +39 06 90672316
>>>  E-mail: 
>>>  http://www.ism.cnr.it/en/staff/giuseppe-mattioli/
>>>  ResearcherID: F-6308-2012
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Fwd: CPO-27-Zn scf not converge

[Lori 91]

Inviato da iPhone

(Inizio messaggio inoltrato)

> Da: Lori 91 
> Data: 30 maggio 2016 11:23:46 CEST
> A: Giuseppe Mattioli 
> Oggetto: Re: [Pw_forum] CPO-27-Zn scf not converge
> 
> Someone can help me to use correctly crystal_sg and space group number 
> because I found a connectivity problem for CPO-27Zn??
> Thanks a lot 
> 
> Inviato da iPhone
> 
>> Il giorno 30 mag 2016, alle ore 11:02, Giuseppe Mattioli 
>>  ha scritto:
>> 
>> 
>> Dear Lorenzo
>> Sorry, I'm not familiar with the new crystal_sg coordinates, but it seems to 
>> me that there is something strange in the structure. I suggest that you 
>> "fill the unit cell" with all the equivalent atoms (Avogadro or Vesta can do 
>> it for you) and check the results to be sure that you are calculating 
>> exactly what you want. If pw.x fills the unit cell and write the resulting 
>> alat coordinates of all atoms (as usual), then you may directly check them 
>> with xcrysden. You might try to run the job with the full structure and 
>> simple "crystal" coordinates. Maybe something goes wrong when the code try 
>> to 
>> fill the unit cell in the crystal_sg case. Anyway I suppose that there is no 
>> computational gain in using the crystal_sg coordinates ("no free lunch" 
>> :-)).
>> HTH
>> Giuseppe
>> 
>> 
>>> On Sunday, May 29, 2016 09:11:49 PM Lorenzo Donà wrote:
>>> Dear all can you help me or give me some tips to make scf convergence on 
>>> this calculation:
>>> 
>>> &control
>>>   pseudo_dir='/home/utente/Scaricati/espresso-5.4.0/pseudo/'
>>>   outdir = './',
>>>   wf_collect = .true.,
>>>   verbosity= high,
>>> /
>>> &system
>>>   ibrav=  5,
>>>   a= 25.226, cosab= 0.5,  space_group = 148,
>>>   nat=  9, ntyp= 4,
>>>   ecutwfc =15.0,
>>>   occupations='fixed', smearing='gauss',
>>>input_dft= PBE,
>>> /
>>> &electrons
>>>   mixing_mode='plain'
>>>   diagonalization='david'
>>>   mixing_beta = 0.01
>>>   conv_thr= 1.0e-4
>>>   electron_maxstep=500,
>>> /
>>> ATOMIC_SPECIES
>>> Zn 65.409 Zn.pbe-van.UPF
>>> C 12.010  C.pbe-van_ak.UPF
>>> O 16.00   O.pbe-van_ak.UPF
>>> H 1.00H.pbe-van_ak.UPF
>>> ATOMIC_POSITIONS crystal_sg
>>> C   7.127430447398E-02 -2.455696438145E-01  7.991093030472E-02
>>> C   1.197468901477E-01 -2.066445045066E-01  2.152449225957E-01
>>> C   2.117353032357E-01 -1.117780631842E-01  2.553368090727E-01
>>> C   1.646071563067E-01 -1.528403540257E-01  1.440875844425E-01
>>> H   1.629458066146E-01 -1.419696182443E-01 -4.760745519579E-03
>>> Zn  -1.943259345214E-02  2.834354147594E-01  3.060064447988E-01
>>> O   7.229455751443E-02 -2.290060932141E-01 -9.085450716092E-02
>>> O   3.018234203718E-02 -2.947952345384E-01  1.422041978763E-01
>>> O   2.519030126218E-01 -6.097111538485E-02  1.721974260943E-01
>>> K_POINTS gamma
>>> 
>>> Thanks a lot to help me
>>> 
>>> dearly
>>> 
>>> lorenzo
>> 
>> 
>> - Article premier - Les hommes naissent et demeurent
>> libres et égaux en droits. Les distinctions sociales
>> ne peuvent être fondées que sur l'utilité commune
>> - Article 2 - Le but de toute association politique
>> est la conservation des droits naturels et 
>> imprescriptibles de l'homme. Ces droits sont la liberté,
>> la propriété, la sûreté et la résistance à l'oppression.
>> 
>> 
>>  Giuseppe Mattioli
>>  CNR - ISTITUTO DI STRUTTURA DELLA MATERIA   
>>  v. Salaria Km 29,300 - C.P. 10
>>  I 00015 - Monterotondo Stazione (RM), Italy
>>  Tel + 39 06 90672342 - Fax +39 06 90672316
>>  E-mail: 
>>  http://www.ism.cnr.it/en/staff/giuseppe-mattioli/
>>  ResearcherID: F-6308-2012
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Paolo I tried on Mac with disable parallel and with download manually 
xspectra and gipaw now for xspectra no segmentation fault appears and for gipaw 
I found only a segmentation fault for H2O_environ in H2O_nmr.in 
Please can you help me to fix this problem???
Thanks a lot to help me and for your patience .
Dearly Lorenzo 


> Il giorno 25 mag 2016, alle ore 12:01, Lori 91  ha 
> scritto:
> 
> Dear Professor i can try on My Mac with Intel compilers 
> At line 143 of xanex_dipole.f90 i found :
> aux(1:nrc) = rgrid(xiabs)%r(1:nrc) * &
> 
> And at line 68 of  gen_us_dj.f90 i found:
> 
> gk (1,ig) = xk (1, ik) + g(1, iig)
> 
> Thanks ti help me 
> Dearly Lorenzo 
> 
>> Il giorno 25 mag 2016, alle ore 09:28, Paolo Giannozzi 
>>  ha scritto:
>> 
>> 1. is it reproducible on other machines?
>> 2. what is there at line 68 of gen_us_dj.f90 and line 143 of 
>> xanes_dipole.f90?
>> 
>> Paolo
>> 
>>> On Tue, May 24, 2016 at 6:48 PM, Lorenzo Donà  
>>> wrote:
>>> Dear all I have configured QE 5.4 on ubuntu 12.04 in this way :
>>> ./configure MPIF90=mpiifort FC=ifort F77=ifort CC=icc CXX=icpc 
>>> -with-internal-blas -with-intenal-lapack
>>> 
>>> and I have run PW and Phonon examples without problem but when I run 
>>> XSpectra examples i found 3 segmentation fault of this type for diamond 
>>> SiO2 NiO but not segmentation fault occurred for Cu_L23:
>>>  
>>> Image  PCRoutineLineSource  
>>>
>>> xspectra.x 00AB9319  Unknown   Unknown  Unknown
>>> xspectra.x 00AB7BEE  Unknown   Unknown  Unknown
>>> xspectra.x 00A60252  Unknown   Unknown  Unknown
>>> xspectra.x 009F47D3  Unknown   Unknown  Unknown
>>> xspectra.x 009FB9AB  Unknown   Unknown  Unknown
>>> libpthread.so.07F336DC6F340  Unknown   Unknown  Unknown
>>> xspectra.x 00437000  xanes_dipole_ 143  
>>> xanes_dipole.f90
>>> xspectra.x 00405E3E  MAIN__308  
>>> xspectra.f90
>>> xspectra.x 00403BA6  Unknown   Unknown  Unknown
>>> libc.so.6  7F336D5B5EC5  Unknown   Unknown  Unknown
>>> xspectra.x 00403A99  Unknown   Unknown  Unknown
>>> Error condition encountered during test: exit status = 174
>>> Aborting
>>> 
>>> also for GIPAW modules I found segmentation fault of this type for quartz 
>>> H2O_environ H2O+ benzene-USPP but not for benzene-NCPP:
>>> 
>>>   Computing the magnetic susceptibility isolve=0ethr=  0.1000E-13
>>>  k-point #1 of 1  pool #  1cpu time:   7.3
>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>> Image  PCRoutineLineSource  
>>>
>>> gipaw.x00B2ADF9  Unknown   Unknown  Unknown
>>> gipaw.x00B296CE  Unknown   Unknown  Unknown
>>> gipaw.x00AD1D92  Unknown   Unknown  Unknown
>>> gipaw.x00A66313  Unknown   Unknown  Unknown
>>> gipaw.x00A6D4EB  Unknown   Unknown  Unknown
>>> libpthread.so.07F0187E4D340  Unknown   Unknown  Unknown
>>> gipaw.x004D357E  gen_us_dj_ 68  
>>> gen_us_dj.f90
>>> gipaw.x0044C861  paramagnetic_corr 323  
>>> nmr_routines.f90
>>> gipaw.x0042E8A6  suscept_crystal_I 470  
>>> suscept_crystal.f90
>>> gipaw.x0042A757  suscept_crystal_  218  
>>> suscept_crystal.f90
>>> gipaw.x00403FF3  MAIN__146  
>>> gipaw_main.f90
>>> gipaw.x00403BA6  Unknown   Unknown  Unknown
>>> libc.so.6  7F0187793EC5  Unknown   Unknown  Unknown
>>> gipaw.x00403A99  Unknown   Unknown  Unknown
>>> 
>>> I need to do EPR and NMR.
>>> Please can you help me to solve these problems.
>>> 
>>> Thanks a lot to help me.
>>> 
>>> lorenzo donà
>>> 
>>> ___
>>> Pw_forum 

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Lori 91]

Dear Professor i can try on My Mac with Intel compilers 
At line 143 of xanex_dipole.f90 i found :
aux(1:nrc) = rgrid(xiabs)%r(1:nrc) * &

And at line 68 of  gen_us_dj.f90 i found:

gk (1,ig) = xk (1, ik) + g(1, iig)

Thanks ti help me 
Dearly Lorenzo 

> Il giorno 25 mag 2016, alle ore 09:28, Paolo Giannozzi 
>  ha scritto:
> 
> 1. is it reproducible on other machines?
> 2. what is there at line 68 of gen_us_dj.f90 and line 143 of xanes_dipole.f90?
> 
> Paolo
> 
>> On Tue, May 24, 2016 at 6:48 PM, Lorenzo Donà  
>> wrote:
>> Dear all I have configured QE 5.4 on ubuntu 12.04 in this way :
>> ./configure MPIF90=mpiifort FC=ifort F77=ifort CC=icc CXX=icpc 
>> -with-internal-blas -with-intenal-lapack
>> 
>> and I have run PW and Phonon examples without problem but when I run 
>> XSpectra examples i found 3 segmentation fault of this type for diamond SiO2 
>> NiO but not segmentation fault occurred for Cu_L23:
>>  
>> Image  PCRoutineLineSource   
>>  
>> xspectra.x 00AB9319  Unknown   Unknown  Unknown
>> xspectra.x 00AB7BEE  Unknown   Unknown  Unknown
>> xspectra.x 00A60252  Unknown   Unknown  Unknown
>> xspectra.x 009F47D3  Unknown   Unknown  Unknown
>> xspectra.x 009FB9AB  Unknown   Unknown  Unknown
>> libpthread.so.07F336DC6F340  Unknown   Unknown  Unknown
>> xspectra.x 00437000  xanes_dipole_ 143  
>> xanes_dipole.f90
>> xspectra.x 00405E3E  MAIN__308  
>> xspectra.f90
>> xspectra.x 00403BA6  Unknown   Unknown  Unknown
>> libc.so.6  7F336D5B5EC5  Unknown   Unknown  Unknown
>> xspectra.x 00403A99  Unknown   Unknown  Unknown
>> Error condition encountered during test: exit status = 174
>> Aborting
>> 
>> also for GIPAW modules I found segmentation fault of this type for quartz 
>> H2O_environ H2O+ benzene-USPP but not for benzene-NCPP:
>> 
>>   Computing the magnetic susceptibility isolve=0ethr=  0.1000E-13
>>  k-point #1 of 1  pool #  1cpu time:   7.3
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image  PCRoutineLineSource   
>>  
>> gipaw.x00B2ADF9  Unknown   Unknown  Unknown
>> gipaw.x00B296CE  Unknown   Unknown  Unknown
>> gipaw.x00AD1D92  Unknown   Unknown  Unknown
>> gipaw.x00A66313  Unknown   Unknown  Unknown
>> gipaw.x00A6D4EB  Unknown   Unknown  Unknown
>> libpthread.so.07F0187E4D340  Unknown   Unknown  Unknown
>> gipaw.x004D357E  gen_us_dj_ 68  
>> gen_us_dj.f90
>> gipaw.x0044C861  paramagnetic_corr 323  
>> nmr_routines.f90
>> gipaw.x0042E8A6  suscept_crystal_I 470  
>> suscept_crystal.f90
>> gipaw.x0042A757  suscept_crystal_  218  
>> suscept_crystal.f90
>> gipaw.x00403FF3  MAIN__146  
>> gipaw_main.f90
>> gipaw.x00403BA6  Unknown   Unknown  Unknown
>> libc.so.6  7F0187793EC5  Unknown   Unknown  Unknown
>> gipaw.x00403A99  Unknown   Unknown  Unknown
>> 
>> I need to do EPR and NMR.
>> Please can you help me to solve these problems.
>> 
>> Thanks a lot to help me.
>> 
>> lorenzo donà
>> 
>> ___
>> Pw_forum mailing list
>> Pw_forum@pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum
> 
> 
> 
> -- 
> 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
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] QE 5.1 SIGABRT GWW

[Lori 91 aaaaaa]

Dear Professor how can I solve it??
Because i just rum the example found in QHA
Thanks for your patience
Dearly Lorenzo 

Inviato da iPhone

> Il giorno 09/apr/2014, alle ore 10:02, "Paolo Giannozzi"  uniud.it> ha scritto:
> 
>> On Wed, 2014-04-09 at 08:38 +0200, Lorenzo Don? wrote:
>> 
>> I have also an other problem I am not able to compile QHA with
>> gfortran.
>> I found this error:
> 
> it's an execution error, not a compilation error. 
> 
> P.
> 
>> MacBook-Pro-di-Lorenzo-Dona:Al lorenzodona$
>> cd /Users/lorenzodona/Documents/espresso-5.0.99/QHA/Examples/Al/
>> MacBook-Pro-di-Lorenzo-Dona:Al lorenzodona$ Run_Me 
>> ** input tetrahedra for BZ-integration **
>>   4   1  12
>>  0.00  0.00  0.00
>>  0.50  0.50  0.50
>>  0.50  0.00  0.00
>>  0.50  0.50  0.00
>> ** input tetrahedra for BZ-integration **
>> ** generate_tetra *
>>  NT0=   1  NTETMX=1728
>>0.   0.5000   0.5000   0.5000
>>0.   0.5000   0.   0.5000
>>0.   0.5000   0.   0.
>>1.   1.   1.   1.
>>  volume of tetrahedron =  0.02083
>>  total volume of BZ is =   0.0208  omg48=  96.
>> ** end of generate_tetra **
>> Recalculating omega(q) from C(R)
>> At line 44 of file Partial_phonon_DOS.f90 (unit = 9, file =
>> 'matdyn.modes')
>> Fortran runtime error: Bad value during floating point read
>> natoms==   4
>> irec 168
>>  0.75000 
>> Al1 Al2 
>> It seems you have imaginary frequences.\
>> Hopefully you know what you are doing
>> nstep 446
>>  153.7215  153.7215  153.7223
>>  145.6765  155.2405  155.2451
>>  153.6642  153.6642  153.6645
>>  150.1399  150.1485  157.9149
>>  137.3023  159.5947  159.6110
>>  145.7365  155.1528  155.1576
>>  141.9176  153.1774  160.8602
>>  153.4544  153.4545  153.4553
>>  150.1386  150.1470  157.7811
>>  147.2314  147.2462  162.6442
>>  128.6174  158.9711  166.1367
>> E_min=   0. E_max=   319.816502 
>> nstep 446
>> ** input tetrahedra for BZ-integration **
>>   4   1  12
>>  0.00  0.00  0.00
>>  0.50  0.50  0.50
>>  0.50  0.00  0.00
>>  0.50  0.50  0.00
>> ** input tetrahedra for BZ-integration **
>> ** generate_tetra *
>>  NT0=   1  NTETMX=1728
>>0.   0.5000   0.5000   0.5000
>>0.   0.5000   0.   0.5000
>>0.   0.5000   0.   0.
>>1.   1.   1.   1.
>>  volume of tetrahedron =  0.02083
>>  total volume of BZ is =   0.0208  omg48=  96.
>> ** end of generate_tetra **
>> before integration:  E_min=   0. E_max=
>> 319.816502 
>> At line 72 of file Integration.f (unit = 21, file = 'partial_DOS')
>> Fortran runtime error: Non-existing record number
>> At line 58 of file Atom_projected_properties.f90 (unit = 9, file =
>> 'projected.DOS')
>> Fortran runtime error: End of file
>> At line 71 of file Mean_square_displacement.f90 (unit = 1, file =
>> 'projected_DOS.Al1')
>> Fortran runtime error: End of file
>> mv: rename Displacements to Displacements.Al1: No such file or
>> directory
>> At line 58 of file Atom_projected_properties.f90 (unit = 9, file =
>> 'projected.DOS')
>> Fortran runtime error: End of file
>> At line 71 of file Mean_square_displacement.f90 (unit = 1, file =
>> 'projected_DOS.Al2')
>> Fortran runtime error: End of file
>> mv: rename Displacements to Displacements.Al2: No such file or
>> directory
>> At line 58 of file Atom_projected_properties.f90 (unit = 9, file =
>> 'projected.DOS')
>> Fortran runtime error: End of file
>> At line 71 of file Mean_square_displacement.f90 (unit = 1, file =
>> 'projected_DOS.Al3')
>> Fortran runtime error: End of file
>> mv: rename Displacements to Displacements.Al3: No such file or
>> directory
>> At line 58 of file Atom_projected_properties.f90 (unit = 9, file =
>> 'projected.DOS')
>> Fortran runtime error: End of file
>> At line 71 of file Mean_square_displacement.f90 (unit = 1, file =
>> 'projected_DOS.Al4')
>> Fortran runtime error: End of file
>> mv: rename Displacements to Displacements.Al4: No such file or
>> directory
>> ndiv from file === 446
>> ndiv===   0
>>5.000.0.0.0.
>>   10.000.0.0.0.
>>   15.000.0.0.0.
>>   20.000.0.0.0.
>>   25.000.0.0.0.
>>   30.000.0.0.0.
>>   35.000.0.0.0.
>>   40.000.0.0.0.
>>   45.000.