Re: [QE-users] Help Needed with Empty Trace File in BoltzTrap Calculation

[Davide Ceresoli]

Dear Elham,

with all due respect, do you know what are you trying to calculate?
Does you PhD advisor know how to do it? if not, I suggest you change
topic.

Anyway, there exist several thousands of papers on thermoelectric
properties (typically of Heusler compounds). The majority of them plot
the transport properties as a function of both T and Ef. They were
lucky not to meet "Reviewer #2".

Simply plot the transport properties as a function of T and doping.
Try to stay into reasonable ranges (i.e. 1e20 cm^-3 -- 1e22 cm^-3)

Finally, the Boltztrap papers (v1 and v2) are well written. The manual of
the code is short but very clear.

Good luck,
D.




On 5/9/24 20:40, Elham Rezaee wrote:


Thank you for your explanation.

Do you have any recommendation to fix the situation ? I am not sure weather I 
should change the Fermi in the python file, or in my calculation.



Thanks,
Elham
PhD, UNB, Canada

*From:* users  on behalf of Davide 
Ceresoli 

*Sent:* Thursday, May 9, 2024 7:12 AM
*To:* users@lists.quantum-espresso.org 
*Subject:* Re: [QE-users] Help Needed with Empty Trace File in BoltzTrap 
Calculation

✉External message: Use caution.


Dear Elham,

your Ef is such that there are -2 electrons in the solid. Probably
Ef is inside a band gap, or in the wrong range. Obviously if the DOS
is vanishing, all quantities are vanishing or ill-defined (zero
divided by zero).

Best,
D.



On 5/8/24 18:36, Elham Rezaee wrote:

Dear Quantum ESPRESSO Users,
I am currently performing calculations using BoltzTrap and have encountered an
issue that I hope you might help me resolve. I ran BoltzTrap using an
unsymmetric CIF file, but my resulting prefix.trace file is empty, displaying
values like the attachment. Does anyone have any ideas why this might be
happening or suggestions on how to fix it?
Thank you,
Best regards,
Elham Rezaee,
UNB, Canada, PhD


___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu 
<http://www.max-centre.eu>)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users 
<https://lists.quantum-espresso.org/mailman/listinfo/users>


--
+------+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] Help Needed with Empty Trace File in BoltzTrap Calculation

[Davide Ceresoli]

Dear Elham,

your Ef is such that there are -2 electrons in the solid. Probably
Ef is inside a band gap, or in the wrong range. Obviously if the DOS
is vanishing, all quantities are vanishing or ill-defined (zero
divided by zero).

Best,
D.



On 5/8/24 18:36, Elham Rezaee wrote:

Dear Quantum ESPRESSO Users,
I am currently performing calculations using BoltzTrap and have encountered an 
issue that I hope you might help me resolve. I ran BoltzTrap using an 
unsymmetric CIF file, but my resulting prefix.trace file is empty, displaying 
values like the attachment. Does anyone have any ideas why this might be 
happening or suggestions on how to fix it?

Thank you,
Best regards,
Elham Rezaee,
UNB, Canada, PhD


___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] Boltztrap Calculation

[Davide Ceresoli]

Here it is. I hope I haven't introduced new bugs.
Please check if the results make sense!

Anyway, I find it's much easier to do:
pip install BoltzTraP2
btp2 -n 8 interpolate -m 20 ./scratch/
btp2 -n 8 integrate -b 5000 interpolation.bt2 300 400 500 600
...

HTH.

D.




On 5/4/24 14:44, Elham Rezaee wrote:

Thank you so much for  your help.
That is a real good point.
Can you share the modified version of qe2boltz.py?

Thanks,
Elham , PhD Canada UNB

Get Outlook for iOS <https://aka.ms/o0ukef>

*From:* users  on behalf of Davide 
Ceresoli 

*Sent:* Saturday, May 4, 2024 9:05:27 AM
*To:* users@lists.quantum-espresso.org 
*Subject:* Re: [QE-users] Boltztrap Calculation
✉External message: Use caution.


Dear Elham,
... in short: use BoltzTrap2!

I have fixed qe2boltz.py but I don't recommend using Boltztrap 1...

I have found the following glitches:
- for spin polarized systems, it will compute the transport properties
    only of the spin up channel
- if you don't change 'TETRA' to 'HISTO' in the file generated by
    qe2boltz.py, the Fermi level is miscalculated, with the result
    that even insulators will have a finite conductivity
- when the Fermi level is inside the gap, the Seebeck coefficient
    is meaningless (don't plot it!)

I'm writing this, hoping to help whoever is doing thermoelectric
calculations. Do not blame "Reviewer #2" then... 😂

Best,
D.




On 5/3/24 14:50, Elham Rezaee wrote:

Dear Quantum Espresso Users,
I hope this email finds you well. I am reaching out to seek assistance regarding
a Boltztrap calculation I am attempting to perform on the ComputeCanada cluster.
I have successfully completed relax and nscf calculations in Quantum Espresso
(QE), and following the tutorial provided at
https://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/ 

<https://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/>
<https://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/ 

<https://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/>>, I was

able to generate the files prefix.structure and prefix.energy. However, I
encountered difficulties obtaining the results for prefix.def and 
prefix.intract.
I should mention that while I could obtain all these 4 files for the silicon
(Si) material, I am facing challenges with my compound, which lacks symmetry.
Despite employing the following command in Python to handle the 'No symmetry
found' error: /elif 'No symmetry found' in line:/
/    nsym = 1/
/    try:/
/    print(nsym)/
/    except:/
/    nsym = 1/

I am unable to generate prefix.def and prefix.intract files.
Does anyone have suggestions on what steps I should take next to address this
issue? Alternatively, does anyone possess a version of the Python file that
effectively handles this part of the process? The link provided in the tutorial
for qe2boltz.py seems to be inaccessible.
Thank you,
Best regards,
Elham Rezaee, PhD
University of New Brunswick, Canada


___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu 
<http://www.max-centre.eu>)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users 
<https://lists.quantum-espresso.org/mailman/listinfo/users>


--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+#! /usr/bin/python

eps3 = 1.0e-3
inf6 = 1.0e6
rydberg = 13.60569253

def main(argv = None):
if argv is None:
argv = sys.argv
if len(argv) < 5 or len(argv) > 7:
self = '/' + argv[0]
self = self[len(self)-self[::-1].find('/'):]
print("")
print("Converts the output of Quantum Espresso 5.0 or BerkeleyGW 1.0")
print("to the input of BoltzTraP 1.2.1. Written by Georgy Samsonidze,")
print("An Li, Daehyun Wee, Bosch Research (October 2011).")
print("")
print("Usage: %s prefix format efermi nbnd_exclude [fn_pw [fn_energy]]" % self)
print("")
print("  * prefix = name of th

Re: [QE-users] Boltztrap Calculation

[Davide Ceresoli]

Dear Elham,
... in short: use BoltzTrap2!

I have fixed qe2boltz.py but I don't recommend using Boltztrap 1...

I have found the following glitches:
- for spin polarized systems, it will compute the transport properties
  only of the spin up channel
- if you don't change 'TETRA' to 'HISTO' in the file generated by
  qe2boltz.py, the Fermi level is miscalculated, with the result
  that even insulators will have a finite conductivity
- when the Fermi level is inside the gap, the Seebeck coefficient
  is meaningless (don't plot it!)

I'm writing this, hoping to help whoever is doing thermoelectric
calculations. Do not blame "Reviewer #2" then... 😂

Best,
D.




On 5/3/24 14:50, Elham Rezaee wrote:

Dear Quantum Espresso Users,
I hope this email finds you well. I am reaching out to seek assistance regarding 
a Boltztrap calculation I am attempting to perform on the ComputeCanada cluster. 
I have successfully completed relax and nscf calculations in Quantum Espresso 
(QE), and following the tutorial provided at 
https://blog.levilentz.com/boltztrap-tutorial-for-quantum-espresso/ 
, I was 
able to generate the files prefix.structure and prefix.energy. However, I 
encountered difficulties obtaining the results for prefix.def and prefix.intract.
I should mention that while I could obtain all these 4 files for the silicon 
(Si) material, I am facing challenges with my compound, which lacks symmetry. 
Despite employing the following command in Python to handle the 'No symmetry 
found' error: /elif 'No symmetry found' in line:/

/    nsym = 1/
/    try:/
/        print(nsym)/
/    except:/
/        nsym = 1/

I am unable to generate prefix.def and prefix.intract files.
Does anyone have suggestions on what steps I should take next to address this 
issue? Alternatively, does anyone possess a version of the Python file that 
effectively handles this part of the process? The link provided in the tutorial 
for qe2boltz.py seems to be inaccessible.

Thank you,
Best regards,
Elham Rezaee, PhD
University of New Brunswick, Canada


___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] Broken kramers degeneracy in antiferromagnet

[Davide Ceresoli]

Dear Francesco,
I might be wrong, but could it be this case:
https://physics.aps.org/articles/v17/4
?

Best,
D.


On 1/16/24 21:47, Francesco Delodovici wrote:

Dear users,

I have a problem computing the electrons band structure of BiFeO3, 
antiferromagnet (no SOC), R3c space gorup,

with Hubbard corrections on Fe.
I define different starting_magnetizations for the two sublattices of spin 
centers, as described in the Input File Description.
When I compute the electronic bands I see that the degeneracy of the spin-up and 
spin-down states is lifted

only along certain directions.
Since the time-reversal symmetry is present but the inversion symmetry is broken 
I would expect the bands to respect

Kramers degeneracy:   E_up (k) = E_dn (-k) .
This is not what I find, as you can see from the picture attached.
The energy difference can be as large as 0.2 eV, so this is not numerical noise.

I tried different solutions, including using an explicit k-points mesh, use 
nosym=true, starting from different

initial magnetizations, but I always obtain the same odd behaviour.
I also tried FeO3, same procedure, with an automatically generated k-mesh, and 
the spin-polarized bands are degenerate as they should.
I paste below the input file of the self consistent calculation, I'm using 
version 7.0, with PAW pseudopotentials.


I appreciate any suggestion,
thank you!

Francesco Delodovici, CentraleSupelec, Universitè Paris-Saclay.


##

  &control
     calculation='scf'
     restart_mode='from_scratch',
     pseudo_dir = './pseudop/',
     outdir='./'
     prefix='BFO'
     tstress = .TRUE.
     tprnfor = .TRUE.
  /
&system
     ibrav = 0, celldm(1)=10.660942,
     nat= 10, ntyp=4,
     ecutwfc =120.0, ecutrho=600.0
     occupations='smearing', smearing='gaussian', degauss=0.02
     nspin = 2,
     starting_magnetization(2) = -1
     starting_magnetization(3) = 1
     lda_plus_u=.true.
     lda_plus_u_kind = 0
     Hubbard_U(2) = 4.5
     Hubbard_U(3) = 4.5

  /
  &electrons
     conv_thr = 1.0e-9
  /

ATOMIC_SPECIES
  Bi 208.98 Bi.upf
  Fe1 55.85  Fe.upf
  Fe2 55.85  Fe.upf
  O  15.999 O.upf

CELL_PARAMETERS (alat= 10.66094200)
    0.496963620  -0.286922080   0.819002251
   -0.0   0.573844160   0.819002251
   -0.496963620  -0.286922080   0.819002251

ATOMIC_POSITIONS (crystal)
Bi   -0.0064211942   -0.0064211938   -0.0064211942
Bi    0.4935787307    0.4935787311    0.4935787307
Fe1   0.2189690501    0.2189690504    0.2189690501
Fe2   0.7189689110    0.7189689114    0.7189689110
O 0.3893335266    0.5347428617    0.9390758847
O 0.9390758845    0.3893335266    0.5347428617
O 0.5347428621    0.9390758842    0.3893335268
O 0.0347428643    0.8893334799    0.4390758846
O 0.8893334801    0.4390758843    0.0347428647
O 0.4390758848    0.0347428643    0.8893334799

K_POINTS (automatic)
6 6 6 0 0 0



--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] NMR of Metallic Systems

[DAVIDE CERESOLI]

Dear Megan, the code calculates the orbital shift and it is included in the 
numbers. Only one term of the Knight shift is implemented, and I never 
reproduced the results of Mayeul. Idk. I'm afraid it is useless now.
Best.
D.

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>

From: Megan Burrill 
Sent: Thursday, November 23, 2023 4:17:42 PM
To: Marzari Nicola ; Quantum ESPRESSO users Forum 

Cc: DAVIDE CERESOLI 
Subject: Re: [QE-users] NMR of Metallic Systems

Hi Nicola and Davide,

Thank you for your responses! So would I be correct in understanding that the 
NMR calculations for metals will correctly calculate the orbital portion of the 
shift, but will not include the Knight contribution? Or is it the case that if 
there is a Knight shift, I will not see convergence with respect to k-points?

Nicola - from my understanding of your paper, you did perform the Knight shift 
calculations, but they were more difficult to converge with respect to smearing 
that the orbital shifts. Given that the Knight shifts are not implemented, does 
this mean that the method did not extrapolate well to other systems, so was not 
added to the published version of Quantum Espresso?

Thanks again,
Megan

On Thu, Nov 23, 2023 at 5:08 AM Nicola Marzari via users 
mailto:users@lists.quantum-espresso.org>> 
wrote:
On 23/11/2023 12:03, Davide Ceresoli wrote:
> Dear Megan,
> the orbital shift is implemented, the Knight shift no. I can't
> get it to converge with respect to k-points.
>
> Best,
> Davide


Spot on! We worked on this a long time ago -
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.76.165122
and I always wondered if wannier interpolations could help - we hadn't
the time then to try that out.

nicola

>
> , and
> On 11/22/23 19:51, Megan Burrill wrote:
>> Hi,
>>
>> This is a question which has been asked in years previously, but I did
>> not find any recent answers. I am interested in NMR simulations using
>> GIPAW of a metallic system, and was wondering if that has been
>> implemented in Quantum Espresso. I appreciate any updates as to the
>> status of metallic systems and the knight shift.
>>
>> Thank you,
>> Megan Burrill
> ___
> The Quantum ESPRESSO community stands by the Ukrainian
> people and expresses its concerns about the devastating
> effects that the Russian military offensive has on their
> country and on the free and peaceful scientific, cultural,
> and economic cooperation amongst peoples
> ___
> 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

--
--
Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
Director, National Centre for Competence in Research NCCR MARVEL, SNSF
Head, Laboratory for Materials Simulations, Paul Scherrer Institut
Contact info and websites at http://theossrv1.epfl.ch/Main/Contact

___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] NMR of Metallic Systems

[Davide Ceresoli]

Dear Megan,
the orbital shift is implemented, the Knight shift no. I can't
get it to converge with respect to k-points.

Best,
Davide


On 11/22/23 19:51, Megan Burrill wrote:

Hi,

This is a question which has been asked in years previously, but I did not find 
any recent answers. I am interested in NMR simulations using GIPAW of a metallic 
system, and was wondering if that has been implemented in Quantum Espresso. I 
appreciate any updates as to the status of metallic systems and the knight shift.


Thank you,
Megan Burrill

___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] gipaw + hubbard + qe-7.2 question

[Davide Ceresoli]

Found!

Please, edit file GIPAW/src/orthoatwfc1.f90 and change line 47 from:
  call ortho_swfc(npw, normalize_only, natomwfc, wfcatom, swfcatom)
to:
  call ortho_swfc(npw, normalize_only, natomwfc, wfcatom, swfcatom, .FALSE.)

and recompile gipaw. I will commit this change in the git repo shortly.

Best wishes,
D.




On 11/6/23 00:16, Randall Hall wrote:

Dear Davide,
   Hopefully I am replying to the correct email address. The files I am sending 
are are a modification of an input file studying a ZnO surface with a bound 
organic molecule, with has the segmentation error.  For simplicity, I removed 
all atoms except a single Zn atom and left all other parameters untouched. I 
attach 5 files


1. trial.epr.scf.withoutDFT+U.in, the input file with the Hubbard DFT+U lines 
commented out

!HUBBARD (ortho-atomic)

       !U Zn-3d 5.2

2. trial.epr.scf.withDFT+U.in, the input file using the Hubb ard DFT+U lines
3. trial.epr.withoutDFT+U.out, the output file that runs succesfully
4. trial.epr.withoutDFT+U.out, the output file that stops during gipaw.  I 
appended the system error message to this file

5. trial.epr.gtensor.in, the input file for gipaw.

The job is run on 40 cores using the intel compiler to make qe and gipaw.

Please let me know if you have any questions and thank you.
Randy


Randall Hall (he/him/his)
Lillian L.Y. Wang Yin, Ph.D. Endowed Professor of Chemistry
Dominican University of California
randall.h...@dominican.edu
220 Science Center
Phone: 415-482-1911
Fax: 415-482-1972






On Nov 5, 2023, at 5:15 AM, Davide Ceresoli  wrote:

Dear Randall,
it should work with DFT+U. Please, send the input files,
I'll have a look.

Best,
D.

On 11/4/23 15:53, Randall Hall wrote:

Greetings,
I am trying to use gipaw to calculate the g-tensor for a system with Zn atoms 
using DFT + U and QE 7.2.  If I use the Hubbard U I get a segmentation error 
at line 389 in orthoatwfc.f90.  If I do not use DFT+U the job runs fine.  I 
can send input/output files, but before I go further — should gipaw work with 
DFT + U?

Randy
Randall Hall (he/him/his)
Lillian L.Y. Wang Yin, Ph.D. Endowed Professor of Chemistry
Dominican University of California
randall.h...@dominican.edu <mailto:randall.h...@dominican.edu>
220 Science Center
Phone: 415-482-1911
Fax: 415-482-1972

___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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




--
+------+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] gipaw + hubbard + qe-7.2 question

[Davide Ceresoli]

Dear Randall,
it should work with DFT+U. Please, send the input files,
I'll have a look.

Best,
D.

On 11/4/23 15:53, Randall Hall wrote:

Greetings,
I am trying to use gipaw to calculate the g-tensor for a system with Zn atoms 
using DFT + U and QE 7.2.  If I use the Hubbard U I get a segmentation error at 
line 389 in orthoatwfc.f90.  If I do not use DFT+U the job runs fine.  I can 
send input/output files, but before I go further — should gipaw work with DFT + U?

Randy

Randall Hall (he/him/his)
Lillian L.Y. Wang Yin, Ph.D. Endowed Professor of Chemistry
Dominican University of California
randall.h...@dominican.edu 
220 Science Center
Phone: 415-482-1911
Fax: 415-482-1972





___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] Parallelization and Input/Output of wfc in QE

[Davide Ceresoli]

Dear Riccardo,
the wfc*.dat files generated by QE in the scratch directory do
contain the actual plane wave coefficients, not just the square modulus.
The wfc coefficients are "collected", no need to do MPI stuff.

As Paolo Giannozzi pointed out, you can use pp_example.f90 or the routine
read_QE_wfc at: 
https://github.com/Sassafrass6/PAOFLOW/blob/master/src/defs/do_atwfc_proj.py


Indeed, we were able to replicate exactly the behavior of projwfc.x in
pure python for further processing.

Best,
Davide


On 11/24/22 16:33, Riccardo Piombo uniroma1 wrote:

Dear Prof. Giannozzi,

As far as I know, QE doesn't allow downloading the wavefunctions on a .dat file, 
only their modulus squared. My implementation in the local_dos.f90 code roughly 
fills this gap by saving the coefficients of the


plane waves expansion in k-space.

Whenever I run pp.x on multiple nodes, what happens is that the same file (say 
wfc_g.dat or g_vectors.dat) is overwritten.


For example, when I run a job on one node, my wfc_g.dat file is made of 500k 
rows. When I run the same job on two nodes, the file gets halved (250k rows), 
and so on, as the number of nodes increases.


This problem concerns the parallelization of the job on multiple nodes since the 
file on which the wfc is written is always the same.


Therefore, since I'm not into MPI and stuff like that, what syntax is to 
implement to avoid such a misprint?



Regards,

Riccardo Piombo

Post doc researcher in Condensed Matter Physics at Sapienza University of Rome



--
+------+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] [SPAM] "Paratec" and "Eq.(7)" in output of g tensor

[Davide Ceresoli]

The spin-other-orbit is defined in Eq 7 of PRL 88, 086403.
The first tensor is the trivial definition. The "a la paratec"
method tries to cancel the self-interaction of the unpaired
electron, as explained in the paragraph following Eq.7

HTH.

D.


On 9/2/22 13:46, 王禹齐 wrote:

Dear all,
I am a beginner of QE. I want to calculate the g tensor of a paramagnetic 
system.After I set the  job = 'g_tensor' in gipaw, I get the outpt file. However 
the result shows two result,"Delta_g total (SOO a la Paratec)" and "Delta_g 
total (SOO as in Eq.(7))".

I don't know the difference and what is "a la paratec".


Any help/suggestion is highly appreciated.

___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
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] change lattice constant for orthorhombic structure

[Davide Ceresoli]

Instead of doing a constant volume relaxation (calculation='relax'),
do a constant pressure relaxation (calculation='vc-relax', press=).
This way you will obtain E(V) where E=E(P), V=V(P) and the enthalpy
H(P) = E(P) + P*V(P).

HTH.

D.



On 10/27/21 11:05 AM, Pooja Vyas wrote:

Dear users,
I have obtained equilibrium parameters for my orthorhombic system which has 
ibrav=8 and lattice constants A, B and C in Angstroms. Now, I need energy vs. 
lattice constant curve, for which I require to change the lattice constant. For 
a cubic system only 'a' is used and hence only 'a' used to change. But can I 
know what could be the correct way for changing lattice constants for 
orthorhombic? If I change 'a' in step of 0.05 angstrom, then how should I change 
B and C?


Any kind of help is appreciated.

___
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] scf of orthorhombic structure

[Davide Ceresoli]

Dear Pooya Vyas,
for perovskites, it is customary to report the volume per
unit formula, in order to compare different polymorphs.
The Pbnm, Pnma etc... have 4 unit formula. Pm-3m has 1 unit
formula, etc...

Best.
D.C.


On 10/26/21 12:19 PM, Pooja Vyas wrote:

Then according to it, shouldn't I be using the formula V=abc?

On Tue, Oct 26, 2021 at 3:47 PM Pooja Vyas <mailto:poojavyas...@gmail.com>> wrote:


Dear user,
my lattice parameters are in agreement with
https://materialsproject.org/materials/mp-560885/
<https://materialsproject.org/materials/mp-560885/>. For which I've used
ibrav=8 which is for primitive.

On Tue, Oct 26, 2021 at 3:35 PM Kazume NISHIDATE mailto:nisid...@iwate-u.ac.jp>> wrote:


I don't know what type of primitive vectors you are choosing, but the
difference of the volumes may originate from the difference of their
definitions.

The simple orthorhombic Bravais lattice is identical to the
conventional cell with the volume of V=abc. While the volume of the
primitive face-centered orthorhombic unit cell is V=abc/4.
In your system, 45x4 => 180 is close to your value of 176.

see eg.
http://aflowlib.org/prototype-encyclopedia/orthorhombic_lattice.html
<http://aflowlib.org/prototype-encyclopedia/orthorhombic_lattice.html>

best regards
kazume NISHIDATE
敬具　西館数芽

nisid...@iwate-u.ac.jp <mailto:nisid...@iwate-u.ac.jp>
kazume.nishid...@gmail.com <mailto:kazume.nishid...@gmail.com>


2021年10月26日(火) 17:52 Pooja Vyas mailto:poojavyas...@gmail.com>>:

Dear users,

I required optimized lattice parameters of orthorhombic CaSiO3 for
which I executed variable cell relaxation. The equilibrium volume
obtained was 176 ang^3 while the reported ones are around 45 ang^3.
The optimized lattice constant agrees well with reported data. Can I
know how to convert lattice parameters a, b, c of orthorhombic
CaSiO3 into volume?

Also If I require a lattice constant-energy curve, should I change
all lattice constants a, b, and c with equal step size and run an
scf at all points?

Regards.
___
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
<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>



--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] GIPAW crashes with nspin=2

[Davide Ceresoli]

000
O    0.856208   0.535224   0.978106
O    0.143792   0.464776   0.021894
O    0.143792   0.535224   0.521894
O    0.856208   0.464776   0.478106
K_POINTS {automatic}
4 4 8 0 0 0

we intend to obtain the electric field gradient:

&inputgipaw
job='efg'
prefix='CaMnGe2O6U4_paw_spin'
tmp_dir='./tmp/'
verbosity='high'
spline_ps= .true.
Q_efg(1) = -6.65 !43Ca
Q_efg(2) = 33.0 !55Mn
Q_efg(3) = 33.0 !55Mn
Q_efg(4) = -19.6 !73Ge
Q_efg(5) = -2.56 !17O
q_gipaw = 0.01
/

However, when running gipaw.x for this system we obtain an error message
related to segmentation fault problems. By increasing RAM, nodes or even
decreasing the K-point mesh, the problem persists. By performing the
gipaw calculation on another system, which is spin-unpolarized the
calculation runs smoothly without any problem. We think it might be
related to the calculation being spin polarized, since after the
'q-space interpolation' the calculation crashes, after outputting the 
line:

(RHO,ZETA) => (RHO_UP,RHO_DOWN)

   select_spin: s_maj=1 s_min=2 rho_diff=    0.00

Can you please advise on what the problem might be related to and if
there is a workaround this issue? We have also tried removing the LDAU
calculation, to check if the problem could be related to the inclusion
of the Hubbard paramters, but unfortunately with no luck.

Regards

Estelina Silva


___
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
<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
<https://lists.quantum-espresso.org/mailman/listinfo/users>



--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] normalization of wfcs (wfck2r)

[Davide Ceresoli]

Dear Chris,
you don't need the volume, just to divide by (n1*n2*n3).

Best,
D.


On 8/26/21 6:24 AM, Christoph Wolf wrote:

Dear all,

I am converting a wave-function from k to R space using wfck2r.x. There is only 
1 k-point (particle in a box of 15*15*15 Ang) and the wfc looks like:


 e(   8) =    -4.84501 eV 
      psi = 0.998*[#   2]
     |psi|^2 = 0.999

state #   2: atom   1 (Fe ), wfc  2 (l=0 m= 1)

So this is a "pure s state"; i converte the wfc into real space by using:

    first_k = 1,
    last_k = 1,
    first_band = 8
    last_band = 8

and I get an ".oct" (plain text) file containing on a grid of 144 x 144 x144:

(*-0.885667802907E+01*,  0.607695317678E-16)
( *-0.627285985227E+01*, -0.418670474801E-15)
( -0.291716024900E+01, -0.436306625693E-15)

..

if I  understood the manual correctly the order is such that the real part for 
example:


re[:,:,0]= [ *-8.85667803, * *-6.02698044, * -2.39305522, ..., -12.45808728,  
  -11.95557896, -10.79190254]


that is the first 144*144 elements belong to z=0, the next to z=1, z=2, 
...z=144.

my volume element would be: (15/0.529)**3/144**3=0.0076 (au^3/grid^3)

if I take the dot product of the complex wfc 
*0.076=25733.51243066387+0j, but should this not be the same as 
|psi|^2 = 0.999?


This is probably a very stupid and obvious mistake but I have been looking at 
this for a while now and don't get it...


Best,
Chris
--
Group Leader "Theory of Quantum Systems at Surfaces"
IBS Center for Quantum Nanoscience
Seoul, South Korea


--
+------+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] questions related to QE-GIPAW

[Davide Ceresoli]

Dear Sergei,
the simplest way to include relativistic effects is ZORA. I'm working
on it because it requires minor changes to the code. This is different
from Pauli-SOC with spinor wavefunctions, but results are close.

You can use full symmetry and ibrav/=0 except for hexagonal/trigonal
crystal. In that case better to use ibrav=0 and do not set a or b
lattice vector parallel to the cartesian axis.

Best wishes,
Davide


On 5/20/21 9:13 PM, Sergei Butorin wrote:

I wonder if someone can answer a couple of questions related to QE-GIPAW:

-Have any of methods discussed at QE-developer workshops to take into account 
SOC been ever implemented in QE-GIPAW?


-Is it always better to use ibrav=0 and nosym=.true. rather than to try to 
specify symmetry in terms of ibrav?


Best regards,

Dr. Sergei Butorin

Uppsala University

Sweden

Page Title







När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/


E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/en/about-uu/data-protection-policy


--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] GIPAW PP generation via ld1.x

[Davide Ceresoli]

Dear Hooman,
basically it is sufficient to add two wfc per angular momentum
for each non local channel in the &input and &test section and run with
lgipaw_reconstruction=.true.

Below is an example with Mn.

Best,
Davide

&input
title = 'Mn'
prefix = 'mn'
zed = 25
dft = 'pbesol'
rel = 1
iswitch = 3
beta = 0.2, xmin = -8, dx = 0.005
rlderiv = 2.4, eminld = -2.0, emaxld = 2.0, deld = 0.01, nld = 3
 /
9
1S  1  0  2.0  1
2S  2  0  2.0  1
2P  2  1  6.0  1
3S  3  0  2.0  1
3P  3  1  6.0  1
3D  3  2  5.0  1
4S  4  0  0.0  1
4P  4  1  0.0  1
4D  4  2  0.0  1
 &inputp
pseudotype = 1
lloc = 2
tm = .true.
file_pseudopw = 'Mn.pbesol-tm-semi-dc-gipaw-new.UPF'
author = 'D.C.'
lgipaw_reconstruction = .true.
 /
3
3S  1  0  2.0  0.00  0.80  0.80
3P  2  1  6.0  0.00  1.40  1.40
3D  3  2  5.0  0.00  1.40  1.40
&test
   ecutmin = 150
   ecutmax = 200
   decut   = 10
/
6
3D  3  2  5.0  0.00  1.40  1.40
4D  4  2  0.0  0.00  1.40  1.40
3P  2  1  6.0  0.00  1.40  1.40
4P  3  1  0.0  0.00  1.40  1.40
3S  1  0  2.0  0.00  0.90  0.90
4S  2  0  0.0  0.00  0.90  0.90







On 5/6/21 9:45 PM, human yaghoob nejad wrote:

Greetings,
I was spending a few days reading guides and manuals for the generation of 
norm-conserving PPs for the calculation of the g-tensor and hyperfine splitting 
of EPR spectra using GIPAW module. I realized that the generation of 
gauge-including PPs has not been discussed at length and all the information is 
limited to the input guide of the ld1.x code. As I'm not an expert in PP 
generation, I appreciate it greatly if someone with relevant experience in 
making GIPAW PPs can provide an input as an example, preferably with scalar 
relativistic or fully relativistic forms.


Thank you very much
Hooman Asl
Research Associate, University of Texas at Austin, Austin USA

___
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] QE 6.7 with gipaw 6.6

[Davide Ceresoli]

Dear Chris,
I didn't understand if 6.7MaX is an "official" release
of there will be 6.7-without-MaX release. I'm going to skip
this one for the moment, especially if there are changes to
IO, sorry.

Best wishes,
Davide


On 3/7/21 12:20 PM, Christoph Wolf wrote:

Dear all,

As far as I can see GIPAW 6.7, which make attempts to download from 
https://github.com/dceresoli/qe-gipaw/archive/6.7MaX.tar.gz 
<https://github.com/dceresoli/qe-gipaw/archive/6.7MaX.tar.gz> does not exist 
(yet) - is it OK to compile QE 6.7 with GIPAW for QE 6.6 considering some of the 
changes with IO?


Best,
Chris

--
IBS Center for Quantum Nanoscience
Seoul, South Korea


--
+-+
Special Issue:
"First Principles Electronic Structure and Molecular Dynamics"
www.mdpi.com/journal/materials/special_issues/First_princ_electron_struct_Mol_Dyn
+--+

+------+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] Atomic code: writing the l-dependent pseudopotentials

[Davide Ceresoli]

You can try with these three lines lines:
  do n=1,grid%mesh
 write(99,'(5e18.8)') grid%r(n),((vnl(n,l,1)+vpsloc(n)),l=0,lmax)
  end do
right after variables declaration in atomic/src/descreening.f90

HTH.
D.



On 2/7/21 10:48 PM, Mahmoud Payami Shabestari wrote:

Dear All,
To make more specific my question in my previous post to the list, the question 
is posed in a clearer way:
According to the paper *K. Laasonen et al, PRB47 (16), 10142(1993) *, the USPP 
is fully determined by the quantities: V_{loc}^{ion}(r), D_{nm}^{(0)}, 
Q_{nm}(r), and beta_n(r).
I would like to study HARDNESS vs SOFTNESS of the generated pseudopots with LD1 
code. The files potentially accessible are available by specifying *file_chi, 
file_beta, file_qvan, file_screen*.
Unfortunately, I do not know how to use the written files to extract the needed 
information.

Any comments is highly appreciated.
Best regards,
Mahmoud Payami
AEOI, Tehran, Iran

___
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] definition of the hyperfine coupling constant in QE-GIPAW

[Davide Ceresoli]

Dear Gregor,
the hyperfine coupling should be multiplied by the number
of unpaired electrons (2*S_z). It also assumes I=1/2.

In the past I checked that GIPAW yields the same results of ORCA
and Gaussian for molecules in the case S = I = 1/2. I can re-check that.

Best.
Davide



On 12/18/20 10:22 AM, Gregor Mali wrote:

Hello.


Isotropic hyperfine coupling constants A_iso, calculated by QE-GIPAW, can differ 
by a large factor from A_iso, obtained by Orca. The factor depends on the number 
of unpaired electrons in the unit cell (used in QE) and in the cluster model 
(used in Orca). In Orca, A_iso is proportional to spin-density at the position 
of a nucleus divided by .  is the maximum value of the z component. 
What is the definition of A_iso in QE-GIPAW? Is it perhaps proportional 
to spin-density multiplied by S(S+1)/?



Thanks in advance!


Gregor Mali

National Institute of Chemistry

Ljubljana, Slovenia

___
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] error compile gipaw

[Davide Ceresoli]

27;
   include 'laxlib_hi.fh'
   include 'laxlib_param.fh'

   INTEGER, EXTERNAL ::  ldim_block, ldim_cyclic, ldim_block_sca

1 warning generated.
clang: *error: *no input files
make[1]: *** [laxlib.fh] Error 1
make: *** [libla] Error 1

___
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 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222

___
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
<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 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222

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




--
+--+
  Davide Ceresoli
  CNR - Istituto di Scienze e Tecnologie Chimiche (SCITEC)
  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/
+--+
___
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] error compile gipaw

[Davide Ceresoli]

I'm porting qe-gipaw to qe-6.6. I'm almost done.
Later in the afternoon I will commit the chnages.

D.



On 11/18/20 5:04 PM, Sangho Chung wrote:

Do you mean that installing QE v.6.5 will help to resolve this issue?

Regards,
Sangho


___
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] Orbital magnetization and GIPAW

[Davide Ceresoli]

Dear Malte,
it is available on an old version of QE. You can find it at:
https://code.google.com/archive/p/converse-nmr/

Best.
D.

On 9/23/20 7:55 PM, Malte Sachs wrote:

Dear all,

I have found a paper (PHYSICAL REVIEW B 81, 060409
R 
2010) in which the 
orbital magnetization of Fe,Co and Ni is calculated by the GIPAW method. The 
authors mention that the method is implemented in Quantum Espresso. However, I 
do not find any hint in the Quantum Espresso distribution or at the GIPAW code. 
Can anybody tell me, where to find this code or if it available at all?


Thank you and best regards,

Malte


___
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] GIPAW, SIGSEGV error

[Davide Ceresoli]

Dear Ivo,
I'm investingating the problem. It might be due to
missing AE information in one of the pseudopotentials.
I will try to fix the problem by obtaining the kkpsi
array from other fields of the pseudopotential type.

D.



On 5/17/19 2:48 PM, Ivo Batistic wrote:

Hi to QE & GIPAW developers,


I have problem with EFG-calculations using GIPAW.

I have no idea whether it is my input files error or something else.

gipaw.x gets SIGSEGV error after 15 minutes of running or so.
As I understand, most of that time is spent on wavefunctions rewriting. When 
real job should start, it gets killed.


It is QE-6.3 code compiled with gnu (gfortran-6) compiler.

The error message as well as input/output files are in
attachment.

Please help or advice

Ivo Batistić

Department of Physics
Faculty of Science, University of Zagreb

___
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] vc-relax for orthorhombic systems

[Davide Ceresoli]

to everybody:
3 days in a row I was testing everything that my imagination allowed to and came 
up to a conclusion that with soft materials, with orthorhombic cells of > 20 
atoms there are TOO many degrees of freedom to expect vc-relax to give good 
numbers for cell parameters.
Within the same third decimal digit in total energy (-.xxX Ry) one might 
came to slightly(?!) different cells depending on starting points and general 
logic of relaxation (say, you start from orthorhombic space group doing relax 
and for a corresponding ibrav continue with vc-relax Or you start from the 
closest tetragonal space group and continue with xyz vc-relax).
I will also do a few variable-cell NEB (coupled with QE for ab initio part) 
between the orthorhombic and tetragonal systems, maybe it will help me more to 
better understand the problem.


PS I have a full right to be wrong I am learning and will be thankful for any 
feedback ;-)

Dear Alex,
we made this experiment: we created 10 initial configuration by randomizing
the lattice spacings by 5% and we performed very tight vc-relax-ations.
Then we took the average lattice spacings and angles with their standard
deviations. For a typical orthorhombic perovskite with 20 atoms, we got
+/-0.007 angstrom accuracy on the lattice, +/-0.05° on the angles and
+/-0.0003 Ry on the energy.

For a given XC functional, this is the accuracy due to the numerics.
We are doing worse than PXRD experiments! If your system is softer, I
would expect even larger standard deviations.

HTH.

Best,
Davide

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

Re: [QE-users] SCF not converging in QE6.3 (but it does so in QE6.0)

[Davide Ceresoli]

    ibrav=  12 ,
 a = 11.8022910005134168d0 ,
 b =  8.8517182503850626d0 ,
 c = 20.0d0 ,
 cosab = -.5 ,
 nat =  36 ,
 ntyp = 1 ,
 ecutwfc = 36 ,
 ecutrho = 220 ,
 occupations = 'smearing' ,
 degauss = 0.02 ,
 smearing = 'mv' ,
  /
  &electrons
 mixing_mode = 'local-TF'
 conv_thr = 1e-7
  /
  &ions
  /
ATOMIC_SPECIES
  Au  0.0 Au.pbe-dn-rrkjus_psl.0.1.UPF
ATOMIC_POSITIONS Angstrom
Au  1.475286375063  0.851756985775 -4.818265124511
Au  4.425859125193  0.851756985775 -4.818265124511
Au  7.376431875324  0.851756985775 -4.818265124511
Au 10.327004625454  0.851756985775 -4.818265124511
Au  0.  3.407027943102 -4.818265124511
Au  2.950572750130  3.407027943102 -4.818265124511
Au  5.901145500260  3.407027943102 -4.818265124511
Au  8.851718250391  3.407027943102 -4.818265124511
Au -1.475286375063  5.962298900428 -4.818265124511
Au  1.475286375067  5.962298900428 -4.818265124511
Au  4.425859125197  5.962298900428 -4.818265124511
Au  7.376431875328  5.962298900428 -4.818265124511
Au  0.  1.703513971551 -2.409132562256
Au  2.950572750130  1.703513971551 -2.409132562256
Au  5.901145500260  1.703513971551 -2.409132562256
Au  8.851718250391  1.703513971551 -2.409132562256
Au -1.475286375063  4.258784928877 -2.409132562256
Au  1.475286375067  4.258784928877 -2.409132562256
Au  4.425859125197  4.258784928877 -2.409132562256
Au  7.376431875328  4.258784928877 -2.409132562256
Au -2.950572750126  6.814055886203 -2.409132562256
Au  0.0004  6.814055886203 -2.409132562256
Au  2.950572750134  6.814055886203 -2.409132562256
Au  5.901145500265  6.814055886203 -2.409132562256
Au  0.  0.  0.013283696000
Au  2.950572750130  0.  0.013283696000
Au  5.901145500260  0.  0.013283696000
Au  8.851718250391  0.  0.013283696000
Au -1.475286375063  2.555270957326  0.013283696000
Au  1.475286375067  2.555270957326  0.013283696000
Au  4.425859125197  2.555270957326  0.013283696000
Au  7.376431875328  2.555270957326  0.013283696000
Au -2.950572750126  5.110541914652  0.013283696000
Au  0.0004  5.110541914652  0.013283696000
Au  2.950572750134  5.110541914652  0.013283696000
Au  5.901145500265  5.110541914652  0.013283696000
K_POINTS automatic
  3 4 1  1 1 0

Thank you for your kind attention,

Guido Fratesi



-- 
Guido Fratesi


Dipartimento di Fisica
Universita` degli Studi di Milano
Via Celoria 16, 20133 Milano, Italy




___
users mailing list
users@lists.quantum-espresso.org <mailto: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


--
+--+
  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/
+--+
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] GIPAW Segmentation Fault

[Davide Ceresoli]

Dear Ben,
is your mpif90 using the intel compiler or gfortran?
why are you linking libmkl_gf_lp64 ? that is specific for
gfortran and it might be reason of the crashes, when using
the intel compiler.

Best wishes,
Davide

On 08/08/2018 06:08 PM, Ben Comer wrote:

Davide,

I am using the intel 17.0 compiler with mkl 11.3. Adding the suggested line to 
the bottom of my make.inc file did not change the error unfortunately. I've 
included a dropbox link containing my build script and make.inc. I'm using the 
QE-GIPAW 6.2.2 release (QE and GIPAW bundled).


https://www.dropbox.com/sh/1znj73stc2opkkq/AABVcYoSXKIGlhi293GIB8Zpa?dl=0



Dear Ben,
    I'm afraid it's a problem with MKL-blas ZDOTC, which must
return a complex(dp) result. Very strange, because if you grep
the source code, we have declared it: complex(dp), external::zdtoc

Can you tell us your compiler and MKL version? can you add
DFLAGS+=-Dzdotc=zdotc_wrapper
to the QE make.inc and recompile both (QE and GIPAW)?

Best wishes,
    Davide

On 08/06/2018 03:19 PM, Ben Comer wrote:
Hello,

I've been trying to do g factor calculations in GIPAW working for a few days 
now. I keep getting a segmentation fault (below) no matter how I compile it 
on our cluster. Does anyone have a good idea of what might be causing this?



forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PC    Routine Line Source
gipaw.x    00C40604  Unknown Unknown  Unknown
libpthread-2.12.s  00328DE0F7E0  Unknown Unknown  Unknown
libmkl_avx2.so 2AAAB7DA5CA3  mkl_blas_avx2_zdo Unknown  Unknown

Thanks,

Ben Comer

Georgia Tech








--
+------+
  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...@istm.cnr.it
  Phone: +39-02-50314276, +39-347-1001570 (mobile)
  Skype: dceresoli
+--+
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] GIPAW Segmentation Fault

[Davide Ceresoli]

Dear Ben,
I'm afraid it's a problem with MKL-blas ZDOTC, which must
return a complex(dp) result. Very strange, because if you grep
the source code, we have declared it: complex(dp), external::zdtoc

Can you tell us your compiler and MKL version? can you add
DFLAGS+=-Dzdotc=zdotc_wrapper
to the QE make.inc and recompile both (QE and GIPAW)?

Best wishes,
Davide


On 08/06/2018 03:19 PM, Ben Comer wrote:

Hello,

I've been trying to do g factor calculations in GIPAW working for a few days 
now. I keep getting a segmentation fault (below) no matter how I compile it on 
our cluster. Does anyone have a good idea of what might be causing this?



forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PC    Routine Line    Source
gipaw.x    00C40604  Unknown Unknown  Unknown
libpthread-2.12.s  00328DE0F7E0  Unknown Unknown  Unknown
libmkl_avx2.so 2AAAB7DA5CA3  mkl_blas_avx2_zdo Unknown  Unknown

Thanks,

Ben Comer

Georgia Tech





--
+------+
  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...@istm.cnr.it
  Phone: +39-02-50314276, +39-347-1001570 (mobile)
  Skype: dceresoli
+--+
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [Pw_forum] gipaw in 6.2.1 was Re: gipaw cannot be compiled in QE 6.2

[Davide Ceresoli]

Dear Scott,
 I'm aware of the problems. I think I missed the email
from qe-developers regarding the release and packaging of 6.2.1.

However, in passing from 6.1 to 6.2 I didn't expected so many
changes to the code base (i.e. the API). You can see my commits at: 
https://github.com/dceresoli/qe-gipaw

However, because of the large number of changes, before releasing,
I need to test every feature of gipaw with all possible combination
of pseudopotentials and parallelism.

Best wishes,
 Davide



On 02/16/2018 08:06 PM, Scott Brozell wrote:
> Hi,
> 
> This is not fixed in 6.2.1 because an incorrect url is still
> produced in install/plugins_list.
> Attached is a patch file for install/install_utils which
> improves the error handling when an incorrect url is used; see 1.
> Also attached is a patch file for install/plugins_list which
> produces the correct url for gipaw; see 2.
> 
> Unfortunately, compilation errors are then encountered using various
> versions of intel compilers - 17 and 18.  I am looking for help on
> this, see 3.
> 
> 1.
> If an incorrect url is produced in install/plugins_list then
> download_and_unpack in install/install_utils ignores errors from
> gzip and tar.  Target uncompress-gipaw in plugins_makefile finishes
> without error and configuration for gipaw is started.
> 
> install_utils.patch changes this behavior so that uncompress-gipaw
> produces an error which terminates the gipaw build:
> ===
>  0 -rw-r--r-- 1 me hpcsoft2 Feb 13 19:50 qe-gipaw-6.2.tar.gz
> 
> gzip: ../archive/qe-gipaw-6.2.tar.gz: not in gzip format
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> *** Unable to download 
> http://files.qe-forge.org/index.php?file=qe-gipaw-6.2.tar.gz.
> *** Verify that the url is correct.
> make: *** [uncompress-gipaw] Error 1
> ===
> 
> 2.
> An incorrect url is produced in install/plugins_list because
> $(URL) is used:
> ===
> URL=http://files.qe-forge.org/index.php?file=
> ...
> GIPAW=qe-gipaw-6.2
> GIPAW_URL=$(URL)$(GIPAW).tar.gz
> ===
> This is corrected in plugins_list.patch.
> 
> 3.
> mpif90 -O2 -assume byterecl -g -traceback -nomodule -fpp -D__FFTW -D__MPI 
> -D__SCALAPACK   -I/usr/local
> /src/espresso/qe-6.2.1-intel-18.0.0//include 
> -I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0//FoX/finc
> lude -I../include/ -I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0/iotk/src 
> -I/usr/local/src/espresso/
> qe-6.2.1-intel-18.0.0/Modules 
> -I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0/FFTXlib -I/usr/local/src
> /espresso/qe-6.2.1-intel-18.0.0/LAXlib 
> -I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0/KS_Solvers/CG -
> I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0/KS_Solvers/Davidson 
> -I/usr/local/src/espresso/qe-6.2.1-
> intel-18.0.0/PW/src -I/usr/local/src/espresso/qe-6.2.1-intel-18.0.0/UtilXlib 
> -I. -c paw_gipaw.f90
> paw_gipaw.f90(157): error #6580: Name in only-list does not exist or is not 
> accessible.   [SCAN_BEGIN]
>  use upf_module, only : scan_begin, scan_end
> ---^
> paw_gipaw.f90(157): error #6580: Name in only-list does not exist or is not 
> accessible.   [SCAN_END]
>  use upf_module, only : scan_begin, scan_end
> ---^
> ...
> 
> I did a little bit of investigation; my guess is that gipaw is out of
> sync with the main code branch or maybe that there is a module include
> mixup.  Note that XSpectra/src/paw_gipaw.f90 uses read_upf_v1_module
> instead of upf_module.
> 
> thanks,
> scott
> 
> Scott Brozell, Ph.D.
> Scientific Applications Group
> Ohio Supercomputer Center
> Columbus, OH 43212
> 
> 
> On Fri, Oct 27, 2017 at 11:07:58AM +0200, Davide Ceresoli wrote:
>>   please modify the file install/plugins_list as follows:
>> GIPAW=qe-gipaw-6.2
>> GIPAW_URL=http://qe-forge.org/gf/download/frsrelease/245/1119/qe-gipaw-6.2.tar.gz
>>
>> On 10/25/2017 09:56 AM, José Carlos Conesa wrote:
>>> 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

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

Re: [Pw_forum] gipaw cannot be compiled in QE 6.2

[Davide Ceresoli]

Dear all,
 please modify the file install/plugins_list as follows:
GIPAW=qe-gipaw-6.2
GIPAW_URL=http://qe-forge.org/gf/download/frsrelease/245/1119/qe-gipaw-6.2.tar.gz

Best,
 Davide





On 10/25/2017 09:56 AM, José Carlos Conesa wrote:
> 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
> 
> 
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] inconsistent quadrupolar coupling from gipaw calculation

[Davide Ceresoli]

...I wasn't able to obtain reasonable results for Co3O4 with elk.
Therefore I've run an all-electron calculation with an uncontracted
basis set with ORCA, for the Co(CO)$_4$H complex.

Here are the results (Vzz component in Hartree/bohr^2):

atom ORCANCPPNC-semi PAW+NC  PAW+US
---
Co   1.0747  1.0368  0.9011  1.0684  1.0526
H0.1372  0.1343  0.1353  1.0821  1.0797
C   -0.7097 -0.7821 -0.7891 -0.2583 -0.2306
C   -0.7100 -0.7825 -0.7893 -0.2585 -0.2307
C   -0.7100 -0.7825 -0.7893 -0.2585 -0.2307
C   -0.7176 -0.7880 -0.8000 -0.2700 -0.2430
O   -0.2675 -0.2194 -0.2307  0.1459 -0.1818
O   -0.2681 -0.2201 -0.2320  0.1446 -0.1833
O   -0.2681 -0.2201 -0.2320  0.1446 -0.1833
O   -0.2651 -0.2121 -0.2286 -0.1086 -0.1802

NCPP: Co.pbe-tm-gipaw-dc.UPF  C.pbe-tm-gipaw-dc.UPF  H.pbe-tm-gipaw-dc.UPF 
O.pbe-tm-gipaw-dc.UPF
NC-semi: Co.pbe-tm-semi-gipaw.UPF  C.pbe-tm-gipaw-dc.UPF  H.pbe-tm-gipaw-dc.UPF 
O.pbe-tm-gipaw-dc.UPF
PAW+NC: Co.pbe-paw-gipaw-nh.UPF  C.pbe-tm-gipaw-dc.UPF  H.pbe-tm-gipaw-dc.UPF 
O.pbe-tm-gipaw-dc.UPF
PAW+US: Co.pbe-paw-gipaw-nh.UPF  C.pbe-rrkjus-gipaw-dc.UPF 
H.pbe-rrkjus-gipaw-dc.UPF  O.pbe-rrkjus-gipaw-dc.UPF

It seems now that the Co EFG does not depend too much on Co pseudopotential.
However, the choice of Co pseudo appears to influence dramatically the EFG of
the neighboring atoms. The NC pseudos are in better agreement with ORCA.

Uhm... the plot thickens... this is very strange. I need to investigate more.
I hope it's not a bug.

Davide



On 10/09/2017 02:13 PM, Davide Ceresoli wrote:
> Dear Jia,
>      I have to admit that this is the first time that NMR/EFG results
> depend so much on the choice of the pseudopotential. I've calculated
> a bunch of minerals, both with NC and US pseudos, and results are
> in good agreement each other.
> 
> I've tested several Co pseudos (NC, NC+semicore, PAW+semicore) on
> Co3O4 spinel and the EFG results span the entire real numbers range,
> both for Co and for O.
> 
> Which one is correct? I don't know. I'm in favor of pseudopotentials
> with semicore states. They should be closer to all-electron.
> 
> Do you have some reference with Co EFG calculated all-electron (wien2k,
> elk/exciting) on some simple system? If not, is there someone that
> could help us to setup a wien2k/elk calculation?
> 
> Best regards,
>      Davide
> 
> 
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] inconsistent quadrupolar coupling from gipaw calculation

[Davide Ceresoli]

Thank you very much. I'll also try Co3O4 with ELK.
D.


On 10/09/2017 02:30 PM, Ary Junior wrote:
> Hi Jia,
> 
> I would start with Elk and I'm sending an example input file. More 
> information 
> about essential convergence tests necessary to obtain some initial results 
> can 
> be found at
> 
> http://elk.sourceforge.net/faq.html 
> http://elk.sourceforge.net/elk.pdf 
> 
> Try starting with the default atomic species configuration files.
> 
> Cheers!
> 
> Ary Ferreira
> 
> FAPESP postdoctoral fellow
> UFSCar - Brazil
> 
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] inconsistent quadrupolar coupling from gipaw calculation

[Davide Ceresoli]

Dear Jia,
 restarting GIPAW after a DFT+U calculation works in 6.1. It
needs some fix in the SVN version (marked on my agenda).

Best,
 Davide



On 10/09/2017 06:20 PM, Jia Chen wrote:
> Dear Davide,
> 
> Thank you very much for this. I will try to do some more digging into this 
> issue. It seems to me elk is the way to go, since wien2k is commercial and I 
> have no access to it .
> 
> I have one more question about gipaw with DFT+U. If I am only interested in 
> chemical shift, is gipaw fully functional with DFT+U, for both 
> norm-conserving 
> and ultra-soft pesudopotentials? Does DFT+U type in pwscf matter for gipaw? I 
> noticed some issues in calculations, but I would like to know what the code 
> is 
> supposed to do at this stage before reporting it.
> 
> Cheers
> 
> On Mon, Oct 9, 2017 at 8:13 AM, Davide Ceresoli  <mailto:davide.ceres...@cnr.it>> wrote:
> 
> Dear Jia,
>      I have to admit that this is the first time that NMR/EFG results
> depend so much on the choice of the pseudopotential. I've calculated
> a bunch of minerals, both with NC and US pseudos, and results are
> in good agreement each other.
> 
> I've tested several Co pseudos (NC, NC+semicore, PAW+semicore) on
> Co3O4 spinel and the EFG results span the entire real numbers range,
> both for Co and for O.
> 
> Which one is correct? I don't know. I'm in favor of pseudopotentials
> with semicore states. They should be closer to all-electron.
> 
> Do you have some reference with Co EFG calculated all-electron (wien2k,
> elk/exciting) on some simple system? If not, is there someone that
> could help us to setup a wien2k/elk calculation?
> 
> Best regards,
>      Davide
> 
> 
> 
> 
> 
> On 09/20/2017 06:50 PM, Jia Chen wrote:
> 
> Dear All,
> 
> I am working on calculating nmr parameters with gipaw code. I have two
> settings: one with norm-conserving gipaw pesudopotentials which has 
> some
> semi-core states, and the other with ultra-soft gipaw 
> pseudopotentials.
> Electronic structure eigenvalues from pwscf look similar, and
> chemical-shift are not far away from each other. The issue is
> quadrupolar coupling, for Co, norm-conserving calculation gives 0.5MHz
> and ultra-soft gives 1.5MHz. It seems to me a significant 
> discrepancy. 
> I don't know what caused the inconsistency, and which one is more
> reliable. I appreciate any insight on this problem.
> 
> One thing about norm-conserving calculation is that the code gives
>     warming about some orbitals has zero norm. I don't know if that could 
> be
> of concern.
> 
> Cheers
> Jia
> 
> 

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

Re: [Pw_forum] inconsistent quadrupolar coupling from gipaw calculation

[Davide Ceresoli]

Dear Jia,
 I have to admit that this is the first time that NMR/EFG results
depend so much on the choice of the pseudopotential. I've calculated
a bunch of minerals, both with NC and US pseudos, and results are
in good agreement each other.

I've tested several Co pseudos (NC, NC+semicore, PAW+semicore) on
Co3O4 spinel and the EFG results span the entire real numbers range,
both for Co and for O.

Which one is correct? I don't know. I'm in favor of pseudopotentials
with semicore states. They should be closer to all-electron.

Do you have some reference with Co EFG calculated all-electron (wien2k,
elk/exciting) on some simple system? If not, is there someone that
could help us to setup a wien2k/elk calculation?

Best regards,
 Davide





On 09/20/2017 06:50 PM, Jia Chen wrote:
> Dear All,
> 
> I am working on calculating nmr parameters with gipaw code. I have two 
> settings: 
> one with norm-conserving gipaw pesudopotentials which has some semi-core 
> states, 
> and the other with ultra-soft gipaw pseudopotentials. Electronic structure 
> eigenvalues from pwscf look similar, and chemical-shift are not far away from 
> each other. The issue is quadrupolar coupling, for Co, norm-conserving 
> calculation gives 0.5MHz and ultra-soft gives 1.5MHz. It seems to me a 
> significant discrepancy.  I don't know what caused the inconsistency, and 
> which 
> one is more reliable. I appreciate any insight on this problem.
> 
> One thing about norm-conserving calculation is that the code gives warming 
> about 
> some orbitals has zero norm. I don't know if that could be of concern.
> 
> Cheers
> Jia
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] NMR Gipaw Calculations

[Davide Ceresoli]

Dear Alan,
 then probably 0.01 over 520 is ok. You might increase the
cutoff by 5-10 Ry, to improve the f-sum rule. Diagonalization='cg'
in gipaw, is usually faster.

Best,
 Davide


On 09/22/2017 04:11 PM, Ambrozio wrote:
> Dear Davide,
> 
> Thanks for replying,
> 
> I'm working with systems with more than 100 electrons. The systems have 130 
> or 
> more carbon atoms, it's expensive to me increase the number of k-points. I 
> need 
> optimize the computational cost, do you have a hint in this case?
> 
> Thanks a lot,
> 
> 
> Alan.
> 
> 2017-09-22 7:15 GMT-03:00 Davide Ceresoli  <mailto:davide.ceres...@cnr.it>>:
> 
> Dear Alan,
>       I would try to reach an absolute error of the order of
> 0.001 on the f-sum rule, for systems up to ~100 electrons.
> I never investigated whether an absolute or relative error
> is the right choice.
> 
> Best regards,
>       Davide
> 
> 
> 
> On 09/21/2017 07:41 PM, Ambrozio wrote:
>  > Hi dear users and developers,
>  >
>  > I have a question regarding the chemical shielding convergence using
> Gipaw. As
>  > the best of my knowledge, the f-sum rule parameter is an indicative of 
> the
>  > convergence, corresponding to the number of valence electrons. I use a
> criterion
>  > of 0.01 for the absolute error in the f-sum rule tensor  principal
> components.
>  > I'd like to know if this criterion is correct? I mean ... should I 
> take the
>  > absolute error ? or the relative one?
>  >
>  > Regards,
>  >
>  > Alan,
>  >
>  > Federal University of Espirito Santo, Vitoria, Brazil.
>  >
>  > --
>  >
>  > Alan J. Romanel Ambrozio
>  > Bacharel em Física
>  > Mestre em Eng. de Materiais
>  > Doutorando em Física - PPGFis
>  >
>  >
> 
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org <mailto:Pw_forum@pwscf.org>
> http://pwscf.org/mailman/listinfo/pw_forum
> <http://pwscf.org/mailman/listinfo/pw_forum>
> 
> 
> 
> 
> -- 
> 
> Alan J. Romanel Ambrozio
> Bacharel em Física
> Mestre em Eng. de Materiais
> Doutorando em Física - PPGFis
> 
> 

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

Re: [Pw_forum] NMR Gipaw Calculations

[Davide Ceresoli]

Dear Alan,
 I would try to reach an absolute error of the order of
0.001 on the f-sum rule, for systems up to ~100 electrons.
I never investigated whether an absolute or relative error
is the right choice.

Best regards,
 Davide



On 09/21/2017 07:41 PM, Ambrozio wrote:
> Hi dear users and developers,
> 
> I have a question regarding the chemical shielding convergence using Gipaw. 
> As 
> the best of my knowledge, the f-sum rule parameter is an indicative of the 
> convergence, corresponding to the number of valence electrons. I use a 
> criterion 
> of 0.01 for the absolute error in the f-sum rule tensor  principal 
> components. 
> I'd like to know if this criterion is correct? I mean ... should I take the 
> absolute error ? or the relative one?
> 
> Regards,
> 
> Alan,
> 
> Federal University of Espirito Santo, Vitoria, Brazil.
> 
> -- 
> 
> Alan J. Romanel Ambrozio
> Bacharel em Física
> Mestre em Eng. de Materiais
> Doutorando em Física - PPGFis
> 
> 

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

Re: [Pw_forum] gipaw calculation with DFT+U missing prefix.hub files

[Davide Ceresoli]

 <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
> <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 <mailto:Pw_forum@pwscf.org>
> http://pwscf.org/mailman/listinfo/pw_forum
> <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
> <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 <mailto:Pw_forum@pwscf.org>
> http://pwscf.org/mailman/listinfo/pw_forum
> <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
> <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
> 

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

Re: [Pw_forum] GIPAW acceleration

[Davide Ceresoli]

Dear Yasser,
 I have to investigate this issue. There is no reason GIPAW
should work only with a specific number of CPU and pools.

Best,
 Davide



On 07/16/2017 12:06 PM, Yasser Fowad AlWahedi wrote:
> Thanks Davide,
>
> I am running using the smearing option since the system is metallic.
>
> I also noticed an interesting relation. GIPAW runs succeed if  number of 
> cores (np) <= number of k points/npool. I checked this in the 38 atom case 
> which kept failing whenever I chose a number of processors higher than the 
> number of kpoints per pool. Although the SCF runs was finishing successfully 
> all the time. This was also observed in other cases. Is this a general rule?
>
> I will send you the files privately.
>
> Yasser
>
> -----Original Message-
> From: Davide Ceresoli [mailto:davide.ceres...@cnr.it]
> Sent: Sunday, July 16, 2017 1:49 PM
> To: Yasser Fowad AlWahedi ; PWSCF Forum 
> 
> Subject: Re: [Pw_forum] GIPAW acceleration
>
> Dear Yasser,
>  no problem! First of all, it seems to me that I/O is not a problem.
> In fact cputime ~= walltime and davcio routines consume only 1.88 s.
>
> I compared calculations of similar size and I've got:
>  wollastonite: 30 atoms, 36 k-points: 10h40m
>  coesite:  48 atoms, 32 k-points: 19h20m
> on a rather old (2008) Xeon E5520 2.27 GHz, 8 cores.
>
> My timings are more favorable than your C1 results. However, if your system 
> is a slab, the empty space carries a non-neglibigle extra cost.
> You can try to minimize it as much as possible. NMR interactions are 
> short-ranged, contrary to electrostatic interactions
>
> Is your system metallic? even if it has a small band gap, I suggest using 
> occupations='smearing'. This will speed up the linear-response in GIPAW, and 
> convergence wrt k-points.
>
> Finally, the clock difference between the i7 (3.5 GHz) and the Xeon (2.2 GHz) 
> can explain the difference in timing. The clock ratio is ~1.6, similar to the 
> walltime ratio.
>
> In any case, if you send me privately input and output files, I can look them 
> in detail.
>
> Best wishes,
>  Davide
>
>
>
>
>
>
> On 07/16/2017 10:26 AM, Yasser Fowad AlWahedi wrote:
>> Dear Davide,
>>
>> Thanks for your support and my apologies for the late reply.  PW and GIPAW 
>> are compiled using GNU compilers and the intel MKL libs.
>>
>> I am running DFT of Ni2P clusters of various surfaces over two computational 
>> rigs:
>>
>> 1) The university cluster: Each node consist of dual 8 cores/8 threads
>> CPUs Xeons clocked at 2.2 GHz with 64 GB ram. I only use one node per
>> simulation. For storage it uses a mechanical hard drive . (Later
>> called C1)
>>
>> 2) My home pc: which is equipped with i7 5930K processor 6 cores 12 threads 
>> clocked at 3.9 GHz with 128 GB ram (Later called C2). For storage I use a 
>> Samsung 850 EVO SSD.
>>
>> Below table summarize the cases performed/running and the time of finish or 
>> expected time of finishing assuming linear extrapolation.
>>
>>
>> # of atoms   npool   Cores   # kpoints per pool  ComputerTime 
>> (hrs)
>> 30   2   16  17  C1  28.9
>> 38   1   16  25  C1  31.3
>> 49   1   16  34  C1  124.9*
>> 50   2   16  17  C1  474.6*
>> 52   1   10  34  C2  295.2*
>>
>> * estimated time of finish
>>
>> I understand that the cases are different and as such they will require more 
>> or less time to finish.
>>
>> But I noticed that the 50 and 52 cases which are quite similar (same k 
>> points and similar number of atoms) but done over two different systems 
>> attain substantially different time of finish. My guess it is probably due 
>> to the SSD being used to write off the data.  Considering that C2 uses less 
>> computational threads and more atoms but is expected to finish faster.
>>
>> I also noticed an interesting relation. GIPAW runs succeed if  number of 
>> cores (np) <= number of k points/npool. I checked this in the 38 atom case 
>> which kept failing whenever I chose a number of processors higher than the 
>> number of kpoints per pool. Although the SCF runs was finishing successfully 
>> all the time. This was also observed in other cases. Is this a general rule?
>>
>> Below is the timing output of the 38 atoms case:
>>
>> gipaw_setup  :  0.46s CPU  0.50s WALL (   1

Re: [Pw_forum] GIPAW acceleration

[Davide Ceresoli]

Dear Yasser,
 no problem! First of all, it seems to me that I/O is not a problem.
In fact cputime ~= walltime and davcio routines consume only 1.88 s.

I compared calculations of similar size and I've got:
 wollastonite: 30 atoms, 36 k-points: 10h40m
 coesite:  48 atoms, 32 k-points: 19h20m
on a rather old (2008) Xeon E5520 2.27 GHz, 8 cores.

My timings are more favorable than your C1 results. However, if your
system is a slab, the empty space carries a non-neglibigle extra cost.
You can try to minimize it as much as possible. NMR interactions are
short-ranged, contrary to electrostatic interactions

Is your system metallic? even if it has a small band gap, I suggest using
occupations='smearing'. This will speed up the linear-response in GIPAW,
and convergence wrt k-points.

Finally, the clock difference between the i7 (3.5 GHz) and the Xeon (2.2 GHz)
can explain the difference in timing. The clock ratio is ~1.6, similar to
the walltime ratio.

In any case, if you send me privately input and output files, I can look
them in detail.

Best wishes,
 Davide






On 07/16/2017 10:26 AM, Yasser Fowad AlWahedi wrote:
> Dear Davide,
>
> Thanks for your support and my apologies for the late reply.  PW and GIPAW 
> are compiled using GNU compilers and the intel MKL libs.
>
> I am running DFT of Ni2P clusters of various surfaces over two computational 
> rigs:
>
> 1) The university cluster: Each node consist of dual 8 cores/8 threads CPUs 
> Xeons clocked at 2.2 GHz with 64 GB ram. I only use one node per simulation. 
> For storage it uses a mechanical hard drive . (Later called C1)
>
> 2) My home pc: which is equipped with i7 5930K processor 6 cores 12 threads 
> clocked at 3.9 GHz with 128 GB ram (Later called C2). For storage I use a 
> Samsung 850 EVO SSD.
>
> Below table summarize the cases performed/running and the time of finish or 
> expected time of finishing assuming linear extrapolation.
>
>
> # of atomsnpool   Cores   # kpoints per pool  ComputerTime 
> (hrs)
> 302   16  17  C1  28.9
> 381   16  25  C1  31.3
> 491   16  34  C1  124.9*
> 502   16  17  C1  474.6*
> 521   10  34  C2  295.2*
>
> * estimated time of finish
>
> I understand that the cases are different and as such they will require more 
> or less time to finish.
>
> But I noticed that the 50 and 52 cases which are quite similar (same k points 
> and similar number of atoms) but done over two different systems attain 
> substantially different time of finish. My guess it is probably due to the 
> SSD being used to write off the data.  Considering that C2 uses less 
> computational threads and more atoms but is expected to finish faster.
>
> I also noticed an interesting relation. GIPAW runs succeed if  number of 
> cores (np) <= number of k points/npool. I checked this in the 38 atom case 
> which kept failing whenever I chose a number of processors higher than the 
> number of kpoints per pool. Although the SCF runs was finishing successfully 
> all the time. This was also observed in other cases. Is this a general rule?
>
> Below is the timing output of the 38 atoms case:
>
> gipaw_setup  :  0.46s CPU  0.50s WALL (   1 calls)
>
>  Linear response
>  greenf   :  20177.91s CPU  20207.68s WALL ( 600 calls)
>  cgsolve  :  20057.24s CPU  20086.82s WALL ( 600 calls)
>  ch_psi   :  19536.93s CPU  19563.75s WALL (   44231 calls)
>  h_psiq   :  13685.97s CPU  13707.40s WALL (   44231 calls)
>
>  Apply operators
>  h_psi:  44527.30s CPU  46802.35s WALL ( 5434310 calls)
>  apply_vel:262.98s CPU263.30s WALL ( 525 calls)
>
>  Induced current
>  j_para   :559.19s CPU560.39s WALL ( 675 calls)
>  biot_savart  :  0.05s CPU  0.06s WALL (   1 calls)
>
>  Other routines
>
>  General routines
>  calbec   :  39849.22s CPU  37474.79s WALL (10917262 calls)
>  fft  :  0.12s CPU  0.15s WALL (  42 calls)
>  ffts :  0.01s CPU  0.01s WALL (  10 calls)
>  fftw :   8220.39s CPU   9116.72s WALL (27084278 calls)
>  davcio   :  0.02s CPU  1.88s WALL ( 400 calls)
>
>  Parallel routines
>  fft_scatter  :   3533.10s CPU   3242.29s WALL (27084330 calls)
>
>  Plugins
>
>  GIPAW: 112557.79s CPU 112726.12s WALL (   1 calls)
>
> Yasser
>
>
>
>
> -Original Message--

Re: [Pw_forum] GIPAW acceleration

[Davide Ceresoli]

Dear Yasser,
 how many atoms? how many k-points? I/O can always be
the reason, but in my experience if the system is very
large, time is dominated by computation, not I/O.
You should get some speedup if diagonalization='cg' in
GIPAW.

Anyway, if I have time, I will introduce a "disk_io" variable
in the input file, to try to keep more data in memory instead
that on disk.

Best regards,
 Davide


On 07/13/2017 10:02 AM, Yasser Fowad AlWahedi wrote:
> Dear GIPAW users,
>
>
>
> For nmr shifts calculations, I am suffering from the extreme slowness of GIPAW
> nmr shifts calculations.  I have noticed that GIPAW write off the results
> frequently for restart purposes. In our clusters we have mechanical hard 
> drives
> which stores the off data for. Could that be a reason for its slowness?
>
>
>
> Yasser Al Wahedi
>
> Assistant Professor
>
> Khalifa University of Science and Technology
>

-- 
+--+
   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...@istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Allowed symmetries in GIPAW

[Davide Ceresoli]

Dear Nelson,
 95% I think that fractional translation are allowed, because they
shift rigidly the cartesian reference frame. 5% I will be proven
wrong by experts in group theory and symmetry.

Best wishes,
 Davide


On 07/10/2017 10:47 AM, J. Nelson wrote:
> Dear Davide,
>
> Thanks very much for your explanation.
>
> Could I check one further example with you. This one is (x,y,z) => (-x,y,-z),
> but, it has a fractional translation as well:
>
>  isym =  3 180 deg rotation - cart. axis [0,1,0]
>
> cryst. s( 3) = ( 0 -1  0  )  f =( -0.500 )
>(-1  0  0  ) ( -0.500 )
>( 0  0 -1  ) ( -0.500 )
>
> cart.  s( 3) = ( -1.000  0.000  0.000 )  f =( -0.3026487 )
>(  0.000  1.000  0.000 ) (  0.000 )
>(  0.000  0.000 -1.000 ) ( -0.4029274 )
>
> Would this be allowed in GIPAW?
>
> Many thanks,
>
> Joseph Nelson
> TCM Group
> Cavendish Laboratory
> University of Cambridge
>
>
> On 2017-07-08 14:41, Davide Ceresoli wrote:
>> Dear Joseph,
>>  that operation is allowed because x=>x, y=>-y, z=>-z,
>> if I read correctly. The cartesian matrices can be off
>> diagonal. For example the rotation of 90° along z, is also
>> allowed, because the triplet (x,y,z) => (-y,x,z) is still
>> parallel to the original.
>>
>> Basically the problems are with hexagonal crystals and
>> with system with very low symmetry.
>>
>> For hexagonal crystals, it's better to use ibrav=0, and
>> set a,b in the xy plane, c//z, a forming an angle of 30°
>> with x.
>>
>> In all other cases, if unsure, set nosym=.true. in the SCF
>> calc.
>>
>> Best wishes,
>>  Davide
>>
>>
>> On 07/07/2017 12:35 PM, J. Nelson wrote:
>>> Dear all QE users,
>>>
>>> I am using QE-6.1.
>>>
>>> The user guide for GIPAW explains that 'symmetry operations that do not map
>>> cartesian axes are not allowed (i.e. 120 deg. rotations)'.
>>>
>>> Does this mean that the Cartesian rotation matrices for each symmetry 
>>> operation
>>> - e.g.:
>>>
>>>   isym =  4 180 deg rotation - cart. axis [1,0,0]
>>>
>>>  cryst.   s( 4) = ( 0  1  0  )
>>>   ( 1  0  0  )
>>>   ( 0  0 -1  )
>>>
>>>  cart.s( 4) = (  1.000  0.000  0.000 )  [<--this matrix 
>>> here]
>>>   (  0.000 -1.000  0.000 )
>>>   (  0.000  0.000 -1.000 )
>>>
>>> need to be diagonal for the symmetry operation to be compatible with GIPAW? 
>>> Are
>>> symmetry operations with an associated fractional translation allowed?
>>>
>>>
>>> Many thanks,
>>>
>>> Joseph Nelson
>>> TCM Group
>>> Cavendish Laboratory
>>> University of Cambridge
>>>
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Allowed symmetries in GIPAW

[Davide Ceresoli]

Dear Joseph,
 that operation is allowed because x=>x, y=>-y, z=>-z,
if I read correctly. The cartesian matrices can be off
diagonal. For example the rotation of 90° along z, is also
allowed, because the triplet (x,y,z) => (-y,x,z) is still
parallel to the original.

Basically the problems are with hexagonal crystals and
with system with very low symmetry.

For hexagonal crystals, it's better to use ibrav=0, and
set a,b in the xy plane, c//z, a forming an angle of 30°
with x.

In all other cases, if unsure, set nosym=.true. in the SCF
calc.

Best wishes,
 Davide


On 07/07/2017 12:35 PM, J. Nelson wrote:
> Dear all QE users,
>
> I am using QE-6.1.
>
> The user guide for GIPAW explains that 'symmetry operations that do not map
> cartesian axes are not allowed (i.e. 120 deg. rotations)'.
>
> Does this mean that the Cartesian rotation matrices for each symmetry 
> operation
> - e.g.:
>
>   isym =  4 180 deg rotation - cart. axis [1,0,0]
>
>  cryst.   s( 4) = ( 0  1  0  )
>   ( 1  0  0  )
>   ( 0  0 -1  )
>
>  cart.s( 4) = (  1.000  0.000  0.000 )  [<--this matrix here]
>   (  0.000 -1.000  0.000 )
>   (  0.000  0.000 -1.000 )
>
> need to be diagonal for the symmetry operation to be compatible with GIPAW? 
> Are
> symmetry operations with an associated fractional translation allowed?
>
>
> Many thanks,
>
> Joseph Nelson
> TCM Group
> Cavendish Laboratory
> University of Cambridge
>

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

Re: [Pw_forum] Gipaw - Magnetic susceptibility

[Davide Ceresoli]

Dear Alan,
 I think that there is no problem in doing a G=0 response
with a shifted mesh. The response is at G=0, hence it couples
wfcs at the same k. The susceptibility depends a lot on k-points
sampling and if your system has a vanishing band gap, convergence
can be a nightmare.
By default the macroscopic shape is diagonal:
   nmr_macroscopic_shape(:,:) = 0.d0
   nmr_macroscopic_shape(1,1) = 2.d0 / 3.d0
   nmr_macroscopic_shape(2,2) = 2.d0 / 3.d0
   nmr_macroscopic_shape(3,3) = 2.d0 / 3.d0
You can change the component (demagnetizing field) in the input file.

Good luck for your calculations!

Best,
 Davide



On 05/12/2017 07:47 PM, Ambrozio wrote:
> Dear QE users and Developers,
>
> I'm working with NMR calculations in Gipaw. Recently I did some shielding
> calculations and I have some questions regarding the magnetic susceptibility.
> The article from developers Mauri et al (*PRL 77, 26, 1996*) explain that the
> shielding of a bulk of a periodic system is also periodic (i.e. has the same
> periodicity of *G*, the reciprocal lattice vectors), and it is proportional to
> the magnetic susceptibility matrix. In the paper Mauri did a short discussion
> about the macroscopic susceptibility, which is calculated at *G=0*. Follow my
> questions:
>
> i) Assuming that the macroscopic susceptibility is calculating at gamma point
> (*G=0*) and depends of the sample's shape, Does make sense to do a NMR
> calculation with automatic kpoints (monkhorst pack grid)  that does not 
> include
> the gamma point? It is mandatory to including the gamma point when the shape
> correction is .true.?
>
> ii) Does the susceptibility depends of the supercell size? I found very
> different susceptibilities for the same material (AB graphite) changing the
> supercell size.
>
> iii) Why the susceptibility  matrix is not diagonal when the shape correction 
> is
> .true.? Assuming the Mauri paper I think it doens't make sense. Help me to
> understand...
>
>
> I appreciate any help,
>
> Thanks in advance,
>
>
> Alan.
>
>
>
> --
>
> Alan J. Romanel Ambrozio
> Bacharel em Física
> Mestre em Eng. de Materiais
> Doutorando em Física - PPGFis
>
>
>

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

Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault

[Davide Ceresoli]

)
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #5  0x411E6A in greenfunction_ at greenfunction.f90:257
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #6  0x43070A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> 0x41E9C9 in #8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  0x41E9C9 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #8  0x#8  0x4053F2 in MAIN__ at gipaw_main.f90:155
> 4053F2 in MAIN__ at gipaw_main.f90:155
>
> Solution 2: I used the existing Netlib math libs compiled everything as is 
> using GNU compilers without any change to the greenfunction.f90.
>
> This worked fine and I managed to get the magres file.
>
> Of course I prefer to use intel mkl since in benchmark cases I ran it was 3 
> to 5 times faster than Netlib.
>
> Solution 4:   Add  the line-Dzdotc=zdotc_wrapper   to 
> DFLAGS in make.inc then compile with GNU, intel mkl and fftw3
>
> This solution worked perfectly without any problems and produced the same 
> result of solution 2.  Thanks again for your help.
>
> One small question; to use the FFT library of intel mkl what libraries should 
> i add to the make.inc file?
>
> Yasser
>
> 
> From: pw_forum-boun...@pwscf.org [pw_forum-boun...@pwscf.org] on behalf of 
> Paolo Giannozzi [p.gianno...@gmail.com]
> Sent: Sunday, January 29, 2017 1:19 PM
> To: PWSCF Forum
> Subject: Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault
>
> 3) re-link with -lmkl_gf_lp64 instead of -lmkl_intel_lp64, or
> 4) re-compile with preprocessing option -Dzdotc=zdotc_wrapper added to DFLAGS
>
> Paolo
>
> On Sun, Jan 29, 2017 at 10:07 AM, Davide Ceresoli
>  wrote:
>> Dear Yasser,
>>  can you tell us the compiler version, and send the generated
>> make.inc? The crash is on the very first call to 'zdotc' which
>> returns a complex (128 bit) and I suspect an incompatibility
>> between GNU compilers and Intel MKL.
>>
>> While I'm checking this, could you try two things?
>> 1) modify greenfunction.f90:209 from:
>> eprec (ibnd) = 1.35d0 * zdotc (npw, evq (1, ibnd), 1, work, 1)
>> to:
>> eprec (ibnd) = 1.35d0 * sum( conjg(evq(1:npw,inbd)) * work(1:npw) )
>>
>> 2) recompile without mkl? configure with --with-netlib or with any
>> other blas/lapack implementation.
>>
>> Best,
>>  Davide
>>
>>
>>
>>
>> On 01/27/2017 03:23 PM, Yasser Fowad AlWahedi wrote:
>>> Dear all,
>>>
>>> I have compiled QE 6.0 with GNU compilers, intel mkl for all libraries 
>>> except
>>> fft which i used fftw3 for it. I used MPICH for the MPI libs.
>>>
>>> I also compiled successfully gipaw version 6.0 using the same libraries. I
>>> started running the quartz example. SCF went successfully without any 
>>> problems.
>>>
>>> GIPAW failed and gave the following error:
>>>
>>> /Program received signal SIGSEGV: Segmentation fault - invalid memory 
>>> reference.
>>>
>>> Backtrace for this error:
>>> #0  0x7F050C81AE08
>>> #1  0x7F050C819F90
>>> #2  0x7F050BD2F4AF
>>> #3  0x7F050F6CF2CD
>>> #4  0x411A17 in greenfunction_ at greenfunction.f90:209
>>> #5  0x43069A in paramagnetic_correction_aug_ at nmr_routines.f90:375
>>> #6  0x41E959 in suscept_crystal_

Re: [Pw_forum] qe-gipaw 6.0 Segmentation fault

[Davide Ceresoli]

Dear Yasser,
 can you tell us the compiler version, and send the generated
make.inc? The crash is on the very first call to 'zdotc' which
returns a complex (128 bit) and I suspect an incompatibility
between GNU compilers and Intel MKL.

While I'm checking this, could you try two things?
1) modify greenfunction.f90:209 from:
eprec (ibnd) = 1.35d0 * zdotc (npw, evq (1, ibnd), 1, work, 1)
to:
eprec (ibnd) = 1.35d0 * sum( conjg(evq(1:npw,inbd)) * work(1:npw) )

2) recompile without mkl? configure with --with-netlib or with any
other blas/lapack implementation.

Best,
 Davide




On 01/27/2017 03:23 PM, Yasser Fowad AlWahedi wrote:
> Dear all,
>
> I have compiled QE 6.0 with GNU compilers, intel mkl for all libraries except
> fft which i used fftw3 for it. I used MPICH for the MPI libs.
>
> I also compiled successfully gipaw version 6.0 using the same libraries. I
> started running the quartz example. SCF went successfully without any 
> problems.
>
> GIPAW failed and gave the following error:
>
> /Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
> #0  0x7F050C81AE08
> #1  0x7F050C819F90
> #2  0x7F050BD2F4AF
> #3  0x7F050F6CF2CD
> #4  0x411A17 in greenfunction_ at greenfunction.f90:209
> #5  0x43069A in paramagnetic_correction_aug_ at nmr_routines.f90:375
> #6  0x41E959 in suscept_crystal_inner_qzero at suscept_crystal.f90:469
> #7  0x4053F2 in MAIN__ at gipaw_main.f90:155
> Segmentation fault (core dumped)/
>
> I ran using 1 core and 10 cores, both gave similar errors.
>
> I checked other posts and it seems a similar problem existed before in version
> 5.4. I assumed it was fixed in version 6.0. Can you please advise on what can 
> i
> do to address this problem?
>
> Yasser Al Wahedi
> Assistant Professor
> Petroleum Institute
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] segmentation fault XSpectra and GIPAW

[Davide Ceresoli]

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

Re: [Pw_forum] error while running gipaw tutorial examples

[Davide Ceresoli]

It is now fixed in the development version (SVN) of both QE and GIPAW.
D.

On 07/06/2016 12:21 PM, Paolo Giannozzi wrote:
> It's a known problem. See this message:
> https://www.mail-archive.com/pw_forum%40pwscf.org/msg28946.html
>
> On Wed, Jul 6, 2016 at 12:14 PM, Mohan maruthi sena
>  wrote:
>> Hi all,
>>   I have recently installed quantum espresso 5.4.0 including gipaw
>> package.  There are some examples to run. I have successfully ran
>> benzene-NCPP example and output is matching with reference output. While
>> running benzene-USPP example, I encounter following error:
>>
>>
>>
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] gipaw.x

[Davide Ceresoli]

Dear Manuel,
 you can find info, examples and postprocessing
options at: http://www.cecam.org/workshop-0-868.html

Best,
D.

On 05/12/2016 09:14 PM, Manuel Otero wrote:
> Hello
> I'm trying to obtain the NMR spectrum of ethanol using the gipaw.x program. I
> managed to install gipaw.x in the espresso-5.4.0 version. I think it is 
> working
> fine. But I can not find any tutorial that explains how to extract the 
> spectrum
> from the output file.
>
> My input is:
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] gipaw pseudopotential

[Davide Ceresoli]

Dear Arles,
 I've never worked with In, Cd, and Au. But to compute
EFG's you can use any "PAW" (kjpaw) pseudo from pslibrary.

Best,
 Davide


On 04/09/2016 12:30 PM, Arles V. Gil Rebaza wrote:
> Hi QE users,
>
> I would like calculated the electric field gradient (EFG) for different
> compounds with atoms In, Cd, Au, but i does not found these GIPAW
> pseudopotentials. (QE database and Ceresoli web-page).
>
> If someone have these pseudopotential (tested or not), could you send me 
> please.
>
> Thank in advance.
>
> Best
>
> PhD. Arles V. Gil Rebaza
> IFLP - Argentina.

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

[Pw_forum] International Symposium on Material Design & the 11th USPEX Workshop

[Davide Ceresoli]

Dear QE users,
 we are delighted to announce the "International Symposium on Material
Design & the 11th USPEX Workshop":

 http://www.uspex-team.org/11workshop/welcome

to be held at Villa Monastero, Varenna, Lake Como, Italy, 5-9 June 2016.

This school-symposium aims to spread among (young) researchers the use of
structure prediction methods and the different methods of investigation
that allow to characterize the properties of the new structures so
discovered, in normal conditions and high pressure. These methods
are generally of great importance in the head materials science,
crystallography of ordinary pressures and high-pressure, mineralogy,
chemistry/structural physics solid state, of nanoscience and catalysis.

A generous amount of bursaries for young scientists is available thanks
to IUCr, AIC and INSTM (information and deadlines on the website).

Here is the list of invited speakers:

- Artem R. Oganov, Skolkovo Institute of Science and Technology (Russia) and
   Stony Brook University (USA)
- Pavel Bushlanov, Moscow Institute of Physics and Technology (Russia)
- Vladislav A. Blatov, Center for Theoretical Materials Science,
   Samara State Aerospace University (Russia)
- Davide Ceresoli, CNR-ISTM, Milano (Italy)
- Carlo Gatti, CNR-ISTM, Milano (Italy)
- Miroslav Kohout, Max Planck Institute for Chemical Physics of Solids,
   Munich (Germany)
- Stefano Leoni, Cardiff University, Cardiff (United Kingdom)
- Angel Martin Pendas, Oviedo University, Oviedo (Spain)
- Alexandre Tkatchenko, Fritz Haber Institute of the Max Planck Society,
   Berlin (Germany)
- Michele Parrinello, ETH Lugano, Zurich (Switzerland)
- Qiang Zhu, Stony Brook University (USA)

The organizing committee:
 Davide Ceresoli
 Carlo Gatti
 Artem R. Oganov
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] GIPAW Problem (Cholesky)

[Davide Ceresoli]

Dear Vic,
 could you try disabling the parallel linear algebra by
adding "-ndiag 1" after gipaw.x? also could you try to change
isolve from 0 to 1 or viceversa? third and last possibility:
increase q_gipaw from 0.01 to 0.02 or 0.03.

Best,
 Davide


On 11/11/2015 11:22 PM, Vic Bermudez wrote:
> Hello,
>
>   I'm trying to use GIPAW for the first time and encountering a problem 
> that
> isn't discussed at the users' forum. I'm using GIPAW vers. v.5.0.2 (svn rev.
> 9392), and I get this error message soon after execution starts:
>
> 
>   Error in routine  cdiaghg (2785):
>problems computing cholesky
>   
>   stopping ...
>
>   Here's my GIPAW input file:
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] How to simualtion the EPR line with Quantum Espresso

[Davide Ceresoli]

Dear Jinfan,
 given the calculated EPR g-tensor and hyperfine coupling,
you must use a software package to *simulate* the EPR spectrum
such as Easyspin, Spinach, Spinevolution or the software provided
with the EPR spectrometer.

HTH.

Best,
 Davide



On 06/25/2015 11:11 AM, Jinfan wrote:
> Dear Madam/Sir,
>
>  I am trying to calculate the EPR line with intensity as the y-axis and
> magetic field as the x-axis, just like that in experiment. But I don't know 
> how
> to do that with  Quantum Espresso. The lecture by Dr. Davide Ceresoli seems to
> tell how to calculate the EPR parameters only and I'm still not very clear 
> about
> how to do the calculations.  Can someone help me on this? It would be best to
> attach some simple examples. Thank you very much.
>
>
> Best,
>
> Jinfan
>
> /
> />/  School of Energy and Environment
> />/  City University of Hong Kong//
> /
>
>  >/E-Mail:cjinf_0...@sina.com/
>
>>/Kong Kong SAR /
>
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Calculation of Mössbauer Isomer shift

[Davide Ceresoli]

It's implemented in GIPAW (job='mossbauer'). Then you will need
EFGs (job='efg') and maybe hyperfine Fermi contact (job='hyperfine').

HTH.

Best,
 Davide


On 12/15/2014 11:48 PM, Hidembergue Ordozgoith da Frota wrote:
> Can anyone tell me if it is possible to calculate the Mössbauer isomer shift
> using Quantum Espresso?
>
> H. O. Frota
> Federal University of Amazonas - Brazil
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] Mn Norm-Conserving PP (PBE) with GIPAW

[Davide Ceresoli]

I've sent and uploaded couple of Mn pseudos with GIPAW
reconstruction. Please test!

Davide

On 11/12/2014 10:50 PM, Paolo Giannozzi wrote:
> I hadn't noticed that you need GIPAW reconstruction info.
> If so, you will need to generate one. Unfortunately Mn is
> a tough guy. Good luck.
>
> Paolo
>
> On Wed, 2014-11-12 at 11:00 +, roberta pigliapochi wrote:
>> Dear Paolo,
>>
>> Thank you very much for the quick reply and I'm sorry for being
>> stubborn but to me those two PPs don't seem to have the GIPAW
>> reconstruction. Am I talking nonsense?
>>
>> Thank you again.
>> Roberta
>>
>>
>> Roberta Pigliapochi
>> PhD Student | Grey Research Group
>> University of Cambridge
>>
>> On 12 November 2014 10:40, Paolo Giannozzi 
>> wrote:
>>  There are two norm-conserving PBE PP for Mn in the web site.
>>  Presumably they will require one million (for the FHI one)
>>  or one billion (for the HGH one) Ry cutoff.
>>
>>  Paolo
>>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] GIPAW (svn rev. 394) problems with g-tensor

[Davide Ceresoli]

Dear Jakko,
 it used to work in earlier version of Quantum-Espresso.
Please, change line 70 of gipaw_setup.f90 to:

   if (two_fermi_energies .and. lgauss) &

and recompile. I'll commit the change as soon as possible.

Best,
 Davide



On 08/15/2014 11:43 AM, Jarkko V?h?kangas wrote:
> Hi again,
>
> I apologize to bother forum users with this issue again. Has anybody had this 
> particular problem? I just want to have workable gipaw to calculate EPR...
>
> BR, Jarkko
>
> On 13 Aug 2014, at 14:14, Jarkko V?h?kangas  
> wrote:
>
>> Hello QE and GIPAW developers,
>>
>> I get following error message when I try to run GIPAW (svn rev. 394) for EPR 
>> (g-tensor/hyperfine) in QE with svn rev. is 11137:
>>
>> %%
>>  task #  1
>>  from gipaw_setup : error #
>>  GIPAW + two Fermi energies not implemented
>> %%
>>
>> So, have you any idea where is the problem? Otherwise GIPAW works without 
>> errors (e.g. NMR module).
>>
>> I appreciate any help regarding this issue.
>>
>> Regards
>> Jarkko V?h?kangas
>> Ph.D student, University of Oulu, Finland
>>
>>
>>
>> ___
>> Pw_forum mailing list
>> Pw_forum at 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.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] Hyperfine calculations - Extrapolation of spin density

[Davide Ceresoli]

Dear Roberta,
 you can get easily the valence spin_density(r). Inside the PAW spheres
it is calculated only at ion position. However, in GIPAW/src/core_relax.f90
I've left few 'debug' writes. At line 287 I write the reconstructed
densities near the ion in file fort.70..71.. etc.

The core spin density is computed further down and in line 361, I think I
was outputting the contributions to the core spin polarization. As you can
see, at line 367 I only consider the r->0 value.

Best,
 Davide



On 08/11/2014 04:05 PM, roberta pigliapochi wrote:
> Dear all,
> I've been running some NMR calculations via the GIPAW module and I would like 
> to
> ask a question concerning the hyperfine tensor: would it be possible to have 
> the
> difference density of spin-up and spin-down electrons at position r explicitly
> output? I believe the hyperfine coupling constant A is calculated from it - 
> n_s
> (r) - as in Bl/?/chl, Phys. Rev. B, 2000.
> Thank you all for the attention,
> best regards.
> Roberta
>
> Pigliapochi, Roberta
> PhD Candidate | Grey Research Group
> University of Cambridge
>

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] QE-GIPAW capabilities

[Davide Ceresoli]

Dear Kris,
 the orbital shift for metals is in 5.1 and in the SVN. You can try
it on your systems, and it would be great if you report how slow is
the convergence w.r.t. k-points, and if you find any difference
between the smearing methods.

To appreciate the problem, I've attached the convergence of chemical
shift, and orbital susceptibility of Al-fcc as a function of 1/n_k.
The Fermi-Dirac smearing appears to converge faster (e.g. the f-sum
rule is very close to -3), but the susceptibility (chi_bare_pGv) is
negative or vanishing. The bare and para contribution to the chemical
shift of 27Al are very dependent of smearing. Comparing to PARATEC,
I've found that MV and GAUSS smearing are correct for the orbital shift,
but the susceptibility is wrong by orders of magnitude.

Beware, even if there is only one atom, these calculations run for
several hours!

Good luck and let us know! In the meanwhile I'll work on the Knight
shift.

Best,
 Davide



On 06/20/2014 11:49 PM, Kris Harris wrote:
> I'm interested in some 1H shifts for hydroxides on a metal surface, so the
> orbital terms are hopefully(?) not so influenced by the metallic character,
> while the Knight shift is probably important.  Though I'm not sure if the 
> Knight
> shift calculation runs into the same difficulties with sensitivity to smearing
> method.
>
> There are some other nuclei inside the metal itself that would also likely 
> tell
> me something about the structure.  Getting the orbital shift right seems an 
> open
> question still from the old mailing list comments, can I fool around with
> calculation results versus smearing method in the current (5.1) version or is
> that only with developer versions?
>
> thanks,
> Kris
>
>
> On Fri, Jun 20, 2014 at 11:22 AM, Davide Ceresoli  istm.cnr.it
> <mailto:davide.ceresoli at istm.cnr.it>> wrote:
>
> Dear Kris,
>   up to now, only the orbital shift is calculated, but I've found
> very different results depending on the smearing method.
>
> Regarding the Knight shift, I've been quite busy and I could not
> overcome the "activation" barrier.
>
> To the other developers: how about a three days hackathon?
>
> Best,
>   Davide
>
>
>
> On 06/19/2014 05:56 PM, Kris Harris wrote:
>  > Hi,
>  >
>  > I don't think this has been asked since the last revision of the code, 
> so
> I'll
>  > ask for an update: any chance v. 5.1 or the SVN tree can be used for 
> Knight
>  > shifts in metallic systems?
>  >
>  > I've got some interesting experimental shifts in a metallic system, 
> and I'd
>  > really like to use QE-GIPAW to reproduce/understand them and perhaps 
> select
>  > between possible structural models.
>  >
>  > thanks,
>  > Kris
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org <mailto:Pw_forum at 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.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
   Website: http://sites.google.com/site/dceresoli/
+--+
-- next part --
A non-text attachment was scrubbed...
Name: NMR-convergence.pdf
Type: application/pdf
Size: 5791 bytes
Desc: not available
Url : 
http://pwscf.org/pipermail/pw_forum/attachments/20140623/8a53c264/attachment.pdf
 

[Pw_forum] QE-GIPAW capabilities

[Davide Ceresoli]

Dear Kris,
 up to now, only the orbital shift is calculated, but I've found
very different results depending on the smearing method.

Regarding the Knight shift, I've been quite busy and I could not
overcome the "activation" barrier.

To the other developers: how about a three days hackathon?

Best,
 Davide



On 06/19/2014 05:56 PM, Kris Harris wrote:
> Hi,
>
> I don't think this has been asked since the last revision of the code, so I'll
> ask for an update: any chance v. 5.1 or the SVN tree can be used for Knight
> shifts in metallic systems?
>
> I've got some interesting experimental shifts in a metallic system, and I'd
> really like to use QE-GIPAW to reproduce/understand them and perhaps select
> between possible structural models.
>
> thanks,
> Kris

[Pw_forum] Fwd: Re: Re: GIPAW memory problem?

[Davide Ceresoli]

Dear Aleksander,
 I've run you NMR calculation till the end and there was no crash.
I've sent you the output files and everything looks ok to me.

It must a compiler/library problem. Which blas and lapack libraries
are you using? those of MKL or other implementations?

Best,
 Davide



On 06/03/2014 04:58 PM, Davide Ceresoli wrote:
> Dear Aleksander,
>  in this moment I have only 2 CPUs for debugging, and it's
> going really slow.
>
> I suspect that the problem is due to the recent changes to
> GIPAW/src/compute_u_kq.f90, in how u_{k+q} is initialized from
> the wavefunction at k. I think that the orthogonalization
> is lost here.
>
> Maybe the others developers can help me, by telling if this
> is the proper way to diagonalize the hamiltonian at fixed
> KS potential.
>
> Best wishes,
>  Davide
>
>
>
>
> On 06/03/2014 10:11 AM, Paolo Giannozzi wrote:
>> On Mon, 2014-06-02 at 22:39 +0200, Aleksander Jaworski wrote:
>>
>>> I would like to ask you if there are any improvements appearing
>>> on the horizon regarding my gipaw problems :)
>>
>> if the overlap matrix is not positive definite (and if the code
>> says it isn't, it isn't), the solution of the secular equation
>> (H-Se)\psi=0 is not possible, unless you find a way to keep
>> eigenvectors of S with nonpositive eigenvalues out of business.
>>
>> P.
>>
>>> best,
>>> Aleksander
>

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
   Website: http://sites.google.com/site/dceresoli/
+--+

[Pw_forum] Fwd: Re: Re: GIPAW memory problem?

[Davide Ceresoli]

Dear Aleksander,
 in this moment I have only 2 CPUs for debugging, and it's
going really slow.

I suspect that the problem is due to the recent changes to
GIPAW/src/compute_u_kq.f90, in how u_{k+q} is initialized from
the wavefunction at k. I think that the orthogonalization
is lost here.

Maybe the others developers can help me, by telling if this
is the proper way to diagonalize the hamiltonian at fixed
KS potential.

Best wishes,
 Davide




On 06/03/2014 10:11 AM, Paolo Giannozzi wrote:
> On Mon, 2014-06-02 at 22:39 +0200, Aleksander Jaworski wrote:
>
>> I would like to ask you if there are any improvements appearing
>> on the horizon regarding my gipaw problems :)
>
> if the overlap matrix is not positive definite (and if the code
> says it isn't, it isn't), the solution of the secular equation
> (H-Se)\psi=0 is not possible, unless you find a way to keep
> eigenvectors of S with nonpositive eigenvalues out of business.
>
> P.
>
>> best,
>> Aleksander

[Pw_forum] GIPAW memory problem?

[Davide Ceresoli]

Dear Aleksander,
 I've updated 'configure'. Do 'svn update' in qe-gipaw directory.
I've tested with intel xe2011, intel xe2013 and gfortran-4.8 and
both openmpi-1.6.x and mpich-3.x.

Let us know!

Best,
 Davide



On 05/13/2014 08:41 PM, Aleksander Jaworski wrote:
> Thank you very much Davide for your reply and suggestions.
>
> I'm using gfortran and mpif90 compilers.
>
> I have tried to run gipaw.x with '-ndiag 1' but is not changing anything.
>
> I have compiled SVN version of QE and then using
>
> 'svn checkout svn://cvs.qe-forge.org/scmrepos/svn/qe-gipaw/trunk qe-gipaw'
>
> downloaded SVN version of gipaw. But when I'm trying to compile it error
> occurs:
>
>
> checking quantum-Espresso version... 5.1rc2
> configure: error: Cannot compile against this version of quantum-Espresso
>
> how could I go around that?
>
> To be honest, I'm not fully aware of the I/O bound, and I don't know how
> to identify it as a bottleneck.
>
> Thanks for checking my inputs. Fact that they are running on your machine
> means something fishy with my installation.
>
> best,
> Aleksander
>
>
>
> On Tue, 13 May 2014 14:01:43 +0200, Davide Ceresoli
>  wrote:
>> Dear Aleksander,
>>   the gipaw behavior you reported is clearly odd. The initialization
>> phase should last few seconds and do not consume much memory.
>>
>> I've just tested your input files and they work on my machine.
>> In your case, GIPAW appears to be stuck while reading the charge
>> density or in check_para_diag routine. Could you have an I/O problem?
>> Which compiler/MPI are you using?
>>
>> Could you try gipaw with '-ndiag 1'? or, could you try the SVN
>> version (both QE and GIPAW)?
>>
>> Let me know if nothing can work.
>>
>> Best,
>>   Davide
>>
>>
>>
>>
>> On 05/12/2014 05:18 PM, Aleksander Jaworski wrote:
>>> Dear QE users and developers,
>>>
>>>
>>> I'm experiencing issues with running gipaw.x on the glass structures
>>> which
>>> have been created from the classical MD simulations trajectories.
>>> On the glass pw.x is running smoothly and converging properly. Gipaw.x
> is
>>> starting, but showing very strange behavior in terms of memory handling
>>> and
>>> never terminating the job.
>> ___
>> Pw_forum mailing list
>> Pw_forum at 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.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
   Website: http://sites.google.com/site/dceresoli/
+--+

[Pw_forum] GIPAW memory problem?

[Davide Ceresoli]

Dear Aleksander,
 the gipaw behavior you reported is clearly odd. The initialization
phase should last few seconds and do not consume much memory.

I've just tested your input files and they work on my machine.
In your case, GIPAW appears to be stuck while reading the charge
density or in check_para_diag routine. Could you have an I/O problem?
Which compiler/MPI are you using?

Could you try gipaw with '-ndiag 1'? or, could you try the SVN
version (both QE and GIPAW)?

Let me know if nothing can work.

Best,
 Davide




On 05/12/2014 05:18 PM, Aleksander Jaworski wrote:
> Dear QE users and developers,
>
>
> I'm experiencing issues with running gipaw.x on the glass structures which
> have been created from the classical MD simulations trajectories.
> On the glass pw.x is running smoothly and converging properly. Gipaw.x is
> starting, but showing very strange behavior in terms of memory handling and
> never terminating the job.

[Pw_forum] Looking for crashes in gipaw-5.0.x output

[Davide Ceresoli]

Dear gipaw users,
 sometimes it does happen that gipaw-5.0.x will crash in parallel
while computing the NMR chemical shifts in large systems.

The typical error messages are:
  %%
  Error in routine cdiaghg (298):
  S matrix not positive definite
  %%
or:
  %%
  Error in routine cdiaghg (1143):
  problems computing cholesky
  %%

This problem is very annoying and I would like to understand what
causes it, and possibly fix it. gipaw-4.3.1 seems to be unaffected
by this problem. Due to the system sizes (>100 atoms), it is difficult
to debug it in a reasonable time.

Therefore, if you have encountered this problem in a smaller system,
say <40 atoms, I would kindly ask you if you can send me your input
files.

I thank you all in advance.

Best,
 Davide



-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
   Website: http://sites.google.com/site/dceresoli/
+--+

[Pw_forum] GIPAW in QE 5.0.2

[Davide Ceresoli]

Dear Roberta,
 there is qe-gipaw-5.0.3 prepared for the last Cecam tutorial in Zurich.
Here is the link:
https://drive.google.com/folderview?id=0BxmE1NC-2O4wRXVmeXJFdHUwZDg&usp=sharing

It can't handle metals yet. I'm working on it but I've got weird results
depending on the smearing scheme (gaussian vs cold vs fermi-dirac).

Best,
 Davide


On 04/10/2014 01:07 PM, roberta wrote:
> Dear all,
> does a qe-gipaw implementation exist for quantumEspresso 5.0.2 (corrected to
> 5.0.3 through espresso-5.0.2-5.0.3.diff)? If so, can it handle with metallic
> systems?
> Best regards,
> Roberta
> PhD student - University of Cambridge

[Pw_forum] variable cell MD target pressure

[Davide Ceresoli]

On 10/24/2013 10:14 AM, luisen wrote:
>
> Dear Davide,
>
> Thank you very much for your rapid answer. I have just one quick thought about
> the consistency between the pressure obtained from several NVT runs
> and the result obtained directly from the stress tensor.
>
> Did you use the "soft" cutoff method? (ecfixed, qcutz, q2sigma stuff)
I didn't. What are good values for ecfixed, qcutz and q2sigma?

> Did you include in the calculation of the derivative the kinetic energy?
Yes.

> Do you think the entropic term of the Helmholtz free energy may have
> an important impact?
No idea.


> I have another question. In liquids it doesn't really make sense to change the
> shape of the simulation cell. It is only the volume that matters. Moreover, 
> for
> certain magnitudes it is more convenient to have cubic
> cells because of the increased degeneracy in modules of k-vectors in 
> reciprocal
> space, which helps with statistics. However I could not find
> a switch in the input parameters that changes the 3 axes in the same amount, 
> so
> as to preserve the shape of the box. It is possible to keep it
> orthorhombic, but not cubic. Is there any way to do that without modifying the
> code ?
There should be cell_dofree='volume', but it's not implemented. Actually
one would simply need the Andersen barostat (Allen-Tildeslesy page 232),
in addition to Parrinello-Rahman and similar methods.

Anyone willing to implement it?

> Yours,
>
>  Luis Enrique
>
Best,
 Davide

[Pw_forum] variable cell MD target pressure

[Davide Ceresoli]

Dear Luis,
 I'm the culprit who coded output of the kinetic stress, but
without adding it to the total stress. Are you sure it is added
to the total stress?

The issue is that it is not clear whether the "Ion kinetic term"
should be there. In my opinion it should be added to the total stress,
as it is done in classical MD and in the CPV code.

However, I tried to perform NVT MD runs of a liquid metal at different
volumes, and to compare by d^2/dV^2 with the average stress computed
with and without the ions kinetic term. Unfortunately results were
inconclusive.

Therefore, in order not to break the behavior of the code, I decided to
print it, without summing it to the total stress.

Comments on this topic are very welcome.

Best,
 Davide



On 10/23/2013 10:21 AM, luisen wrote:
>
>
>
>   Dear all,
>
>   I am writing to ask for confirmation about a "strange" feature in
>   the program, that concerns molecular dynamics calculations at finite
>   temperature (non-zero) with variable cell.
>   As far as I have experienced it seems to me that the target pressure
>   that one states in the input file is the total pressure, I mean, including
>   the kinetic term coming from the motion of the ions due to the temperature,
>   while the stress tensor and pressure writen in the output file includes only
>   the potential terms, but not the kinetic ones.
>
>   This message is just to request a confirmation from the developers that I am
>   correct about this.
>
>   Note that this feature is very confusing for users; I could spot it because
>   the system I am studying is liquid Be, which has a very high temperature and
>   a very high number density, so that the kinetic part of the pressure is 20
>   kbar. So it is really confusing asking for 0 kbar and obtaining
>   oscillations around -20 kbar in the output file.
>   May I suggest to modify it in the future release of QE?
>
>   Yours,
>   Luis Enrique Gonzalez
>   Universidad de Valladolid
>
>

[Pw_forum] CECAM tutorial announcement

[Davide Ceresoli]

Dear all,
 we are pleased to announce that the CECAM/RMN-GBP Tutorial:

Calculation of Solid-State NMR and EPR Parameters Using the GIPAW Method

will take place from October 7th to 11th, 2013 at ETH Z?rich.

   The purpose of the tutorial is to introduce the computation of NMR and EPR 
spectra to the participants. After the tutorial they will be able to calculate 
NMR and EPR interaction parameters of their interest. The tutorial consists of 
lectures and hands-on terminal sessions. We shall use the DFT-GIPAW package 
implemented in the Quantum Espresso package (http://www.Quantum-ESPRESSO.org/).

   The tutorial is targeted to both NMR and EPR experimentalists and 
theoreticians wanting to calculate NMR and/or EPR properties, and it contains:
  * Short review of the theoretical background of DFT-GIPAW
  * Basics of experimental NMR and EPR and introduction to the measurement of 
those parameters
  * Use of the Quantum ESPRESSO package and the main steps for performing 
reliable NMR and EPR calculations of chemical shift, electric field gradient 
tensors, g tensor
  * Calculation of other experimental observables

   The number of participants is limited. Deadline for application to the 
tutorial is July 14th. To apply for the tutorial please go to the page
http://www.cecam.org/workshop-868.html
and sign up if you haven?t done it already, login in the Restricted User Area, 
go to the web page of the tutorial and press "Apply". Applications for 
participation, will be confirmed shortly after the closing deadline. There is 
no 
participation cost, the accomodation for the participants will be covered for 
five nights, and a small per diem is awarded to cover some of the local costs. 
The tutorial will begin on Monday afternoon after lunch and finishes on Friday 
afternoon.

  Organisers:
  - Ari Paavo Seitsonen (University of Zurich)
  - Davide Ceresoli (CNR-ISTM, Milano)
  - Florent Boucher (CNRS, Nantes)
  - Jonathan Yates (Oxford University)
  - Uwe Gerstmann (University of Paderborn)
  - Thibault Charpentier (CEA Iramis, Saclay)

Financial support:
  * CECAM, http://www.cecam.org/
  * RMN-GBP, http://rmngbp.cnrs-orleans.fr/

[Pw_forum] error of Gipaw calculation for ethonal

[Davide Ceresoli]

Dear Xue,
 I believe the problem is in the O.pbe-van_gipaw.UPF file format.
In fact, this section:


   1


should be added between the "" and the
"" tags in the pseudopotential file.

HTH.

Davide



On 05/09/2013 06:19 AM, Yong Xue wrote:
>
> Dear All
> I am a new user for qe. Since my case study will only take a look at into O
> elment while it contains other element which don't have a gipaw pseudo in QE.
> Then I tried to start the calculation for ethonal with by using
> C.pbe-n-kjpaw_psl.0.1.upf, H.pbe-kjpaw.upf and O.pbe-van_gipaw.upf.
> However, my gipaw calculation stopped at :
>
> negative rho (up, down): 0.369E-01 0.000E+00. Also a error were seen in the 
> log
> file.
>
> Here is my input for gipaw:

[Pw_forum] alignment of computed NMR spectra wrt the experimental one

[Davide Ceresoli]

Dear Prasenjit,
 you can do in both ways!

Best wishes,
 Davide


On 01/29/2013 01:01 PM, Prasenjit Ghosh wrote:
> Dear all,
>
> I had a query regarding comparison of the calculated NMR spectra with that of
> the experimental one. Is it okay to choose the reference value for the sigma
> such that one of the peaks of the calculated spectra is aligned with the
> experimental one or should one do calculations for some reference molecule and
> calculate the shift wrt. to that reference value.
>
> With regards,
>
> Prasenjit

[Pw_forum] Hybrid functionals for GIPAW calculations

[Davide Ceresoli]

Dear Jarkko,
 unfortunately this is not possible. Linear response with Hartree-Fock
is not a piece of cake in QE.

Best wishes,
 Davide

On 01/18/2013 10:21 AM, Jarkko V?h?kangas wrote:
> Hi,
>
> Is it possible in QE to use hybrid functionals for GIPAW calculations? If it 
> is
> where can I find such pseudo potentials?
>
> thanks, Jarkko

[Pw_forum] core-relax in hyperfine calculation (GIPAW)

[Davide Ceresoli]

Dear Jarkko,
 I changed the radial integration bound in 5.0.1. As a consequence
results are slightly different from 4.3.2. The reason is that in 4.3.1 I
got extremely bad HFCC for elements on the right columns in the periodic
table (like oxygen). However the core-relaxation is still not accurate
for such elements, and I'm investigating other relaxation schemes.

Regarding metallic systems, yes for EFG/hyperfine, not yet for NMR/EPR.

Best wishes,
 Davide



On 01/02/2013 02:35 PM, Jarkko V?h?kangas wrote:
> Hi,
>
> I'm starting to use QE 5.0.2 and corresponding GIPAW. I hThe compilation went 
> smoothly but  I'm getting different core-relax contribution compared to GIPAW 
> 4.3.1 in H2O+ example.
>
> So, could tell me that which is correct one? Additionally, is it possible for 
> current GIPAW to calculate NMR/EPR properties to "metallic-like" systems 
> using smearing?
>
> Thanks and Regards
> Jarkko V?h?kangas (PhD cand.)
> University of oulu, Finland
>

[Pw_forum] g-tensor

[Davide Ceresoli]

> from the result, it seems that the output of g-tensor is not in its principle
> axis system. Does it use  the same cart. coord as the crystal?  (the system  I
> calculated is Orthorhombic P, so the x, y, z axis of cart. coord are a, b, c,
> respectively). Is it right?   I would much appreciate your help.
Correct.

>
> Best regards,
> ys zhang
>

Best regards,
 Davide

[Pw_forum] EFG calculation with GIPAW psudopotentials

[Davide Ceresoli]

http://qe-forge.org/gf/project/qe-gipaw/scmsvn/?action=AccessInfo

On 12/14/2012 02:11 AM, Arles V. Gil Rebaza wrote:
> Dear Davide, thanks a lot for your answer. So, i have another question,
> Where I can download the SVN version of GIPAW.?
>
> Thank again
>
> PhD std. Arles V. Gil Rebaza
> IFLP - Argentina
>
> 2012/12/13 Davide Ceresoli  <mailto:davide.ceresoli at istm.cnr.it>>
>
> Dear Arles,
>   it is definitely possible. Beware that in GIPAW-4.3.1 there is
> a bug with USPP and EFG. I strongly advise to use norm-conserving
> pseudos and to switch off symmetry in the SCF calculation (nosym=.true.).
> These problems have been solved in the current SVN version of GIPAW.
>
> Best wishes,
>   Davide
>
>
>
> On 12/13/2012 04:52 PM, Arles V. Gil Rebaza wrote:
>  > Dear QE users
>  >
>  > Is possible calculate the Electric Field Gradient (EFG) in metallic 
> compounds
>  > (specifically with Fe atoms) using gipaw.x code and GIPAW 
> pseudopotentials.??
>  > In QE distribution are some examples to calculate the EFG in 
> molecules. This
>  > procedures is similar for metallic compounds or there is a different 
> way to
>  > calculated it.
>  >
>  > Best
>  >
>  > PhD std. Arles V. Gil Rebaza
>  > IFLP - Argentina
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org <mailto:Pw_forum at pwscf.org>
> http://pwscf.org/mailman/listinfo/pw_forum
>
>
>
>
> --
> ###->   Arles V.   <-###

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] EFG calculation with GIPAW psudopotentials

[Davide Ceresoli]

Dear Arles,
 it is definitely possible. Beware that in GIPAW-4.3.1 there is
a bug with USPP and EFG. I strongly advise to use norm-conserving
pseudos and to switch off symmetry in the SCF calculation (nosym=.true.).
These problems have been solved in the current SVN version of GIPAW.

Best wishes,
 Davide



On 12/13/2012 04:52 PM, Arles V. Gil Rebaza wrote:
> Dear QE users
>
> Is possible calculate the Electric Field Gradient (EFG) in metallic compounds
> (specifically with Fe atoms) using gipaw.x code and GIPAW pseudopotentials.??
> In QE distribution are some examples to calculate the EFG in molecules. This
> procedures is similar for metallic compounds or there is a different way to
> calculated it.
>
> Best
>
> PhD std. Arles V. Gil Rebaza
> IFLP - Argentina

[Pw_forum] Cannot reach the target temperature in vc-md calculation using pwscf; and where I can find the updated velocities?

[Davide Ceresoli]

Dear Tian,
 I'm experiencing the same problem, also in 5.0.2. I think that the
default choice of the cell mass is not appropriate. The kinetic energy of the
cell d.o.f. is added to the ions kinetic energy, then velocities are
rescaled. If ionic temperature is always smaller than tempw, it might be
that the cell d.o.f. suck a consistent fraction of the ionic temperature.
I'm not 100% sure about that. I will perform some test by reducing wmass,
then I'll report the outcome.
I've also reported this problem to QE developers mailing list, and I'm
waiting for suggestions.

HTH.

Best wishes,
 Davide


On 11/30/2012 09:49 PM, Tian Lan wrote:
> Thanks. I want to use vc-md, because it is NPT enemble. I would like to see 
> the
> cell response to temperatures, e.g. . I did not find any explicit comment 
> about
> the bug of temperature control. But I did see one recent message saying a very
> similar problem. So at this point, I am not sure whether the problem comes 
> from
> the setup or from the code itself.
> What I do see is the control commands are not effective at all. The tolp=10 
> and
> tolp=100 almost have the same output, e.g., which is disappointing. When
> tempw=100K, it did converge well, but tempw=300K can only reach 200K. And, a
> smaller cell seems to perform worse in temperature control. So there are a lot
> of phenomena. If someone is familar with this, or knows the relationship 
> between
> those seemingly messy observations, please let me know. Or it is indeed the 
> code
> problem, I will try to use another one. Thanks a lot !
> Tian
>

[Pw_forum] scf_must_converge

[Davide Ceresoli]

Dear Florence,
 on my machine the code prints eigenvalues, energies, and forces
(if I add tprnfor=.true.) and I can do ionic relaxation. What it
the error message, exactly?

convergence NOT achieved after 100 iterations: stopping
or
WARNING: convergence NOT achieved after 100 iterations

The former is when scf_must_converge=.true., the latter
is when scf_must_converge=.false.

Davide


On 11/02/2012 08:06 AM, florence liu wrote:
> Dear all,
> i am trying to do some optimizations with PWSCF v.5.0 and I have the following
> problem.
> I want to let a optimization to continue, even if the scf has not fully
> converged. As I have under stood the QE documentation, one need to set the tag
> scf_must converge, as i have done in my input file:
> (...)
>   &electrons
>   electron_maxstep=100,
>   conv_thr=7.35D-8,
>   scf_must_converge=.false.
> /
> (...)
> however, the optimization calcualtion still terminated with the message:
> "convergence NOT achieved after 100 iterations: stopping" after one scf cycle,
> in whihch the convergence critereriva have not been reached.
> Can anybody tell me, whether I am missing some settings to let the 
> optimization
> not terminate, when a scf cycle has not converged? or does anybody see which
> mistake i have done?
> best wishes,
> florence
> TU Munich
>

[Pw_forum] scf_must_converge

[Davide Ceresoli]

Dear Florence,
 which kind of relaxation are you performing? ions, cell, ions+cell?
are you using hybrid functionals? the logic of PW/src/electrons.f90 is
quite complicated and there are several points in which one can check
if (last_step .and. .not. scf_must_converge). If you send me a fragment
of the output, I can have a look.

Best wishes,
Davide


On 11/02/2012 08:06 AM, florence liu wrote:
> Dear all,
> i am trying to do some optimizations with PWSCF v.5.0 and I have the following
> problem.
> I want to let a optimization to continue, even if the scf has not fully
> converged. As I have under stood the QE documentation, one need to set the tag
> scf_must converge, as i have done in my input file:
> (...)
>   &electrons
>   electron_maxstep=100,
>   conv_thr=7.35D-8,
>   scf_must_converge=.false.
> /
> (...)
> however, the optimization calcualtion still terminated with the message:
> "convergence NOT achieved after 100 iterations: stopping" after one scf cycle,
> in whihch the convergence critereriva have not been reached.
> Can anybody tell me, whether I am missing some settings to let the 
> optimization
> not terminate, when a scf cycle has not converged? or does anybody see which
> mistake i have done?
> best wishes,
> florence
> TU Munich
>

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] NMR calculation of CDCl3

[Davide Ceresoli]

Dear Prasenjit,
 as far you are considering a frozen geometry, there is no
difference between H and D. Only zero point motion will be
affected. Deuterium NMR is exactly the same as H NMR, except
that experimentally the D signal is weak, noisy and broad. In
practice, D substitution is used to suppress selected H resonances.

Best wishes,
 Davide



On 09/21/2012 02:44 PM, Prasenjit Ghosh wrote:
> Dear all,
>
> I want to calculate the 13C NMR spectra of CDCl3, where D is the
> deuterium..How do I incorporate the fact that D has one extra neutron in 
> it?
> Or since we are interested in the C NMR spectra, it will not effect the 
> calculation?
>
> With regards,
>
> Prasenjit
>
> --
> PRASENJIT GHOSH,
> IISER Pune,
> First floor, Central Tower, Sai Trinity Building
> Garware Circle, Sutarwadi, Pashan
> Pune, Maharashtra 411021, India
>
> Phone: +91 (20) 2590 8203
> Fax: +91 (20) 2589 9790

[Pw_forum] quadrupole monents & GIPAW & a problem

[Davide Ceresoli]

Dear Zibi,
 could you check with me whether your crystal is the gamma
phase? experiments report Cq=0.042 MHz and eta=0.0 (Vorotilova,
Dmitrieva and Samoson, 1987). B is an nearly cubic environment
and the tetragonal symmetry should yield an axial tensor, hence
vanishing eta.

Anyway, I recognize that B.pbe-tm-gipaw.UPF has some problems.
It did work for NMR of small molecules, but I never tested it
in solid state systems, I'm sorry.

The last thing to check, is the tensor convention. I think I'm
using the Haeberlen convention, which is the same used by the
Simpson code 
(http://anorganik.uni-tuebingen.de/klaus/nmr/index.php?p=conventions/csa/csa).

HTH.

Best,
 Davide



On 09/11/2012 06:00 PM, Zbigniew Lodziana wrote:
> Dear users & developers,
>
> While calculating quadrupole moments with GIPAW I have experienced a strange
> output that confuses me and it is difficult for interpretation, at least to 
> me.
>
> Performing calculations for LiBO2 (with occupancies = fixed!) efg calculations
> provide for Boron:
> (a)   Cq=   0.0208 MHzeta= 0.0
> (b)   Cq=   2.0747 MHzeta= 0.0
> (c)   Cq=   0.0228 MHzeta= 0.0
>
> Where
> (a) is with TM potential
> [https://sites.google.com/site/dceresoli/pseudopotentials/B.pbe-tm-new-gipaw-dc.UPF?attredirects=0];
>
> (b) also TM
> [https://sites.google.com/site/dceresoli/pseudopotentials/B.pbe-tm-gipaw.UPF?attredirects=0];
>
> (c) with ultrasoft.
>
> Experimental value is Cq=2.56, eta=0.6; theoretical report Cq=2.552, eta=0.54
>
> Test calculations with other more accurate potentials unfortunately do not
> solve problem.
>
> And the problem is that the worst description of the valence states provides
> (at least numerically) best Cq; besides it is difficult to understand how
> small changes in the valence state might result in so large ? two orders of
> magnitude ? changes in the core region. For other systems changes are even 3
> orders.
>
> Structural parameters are reasonable.
>
> For oxygen I did not found such a large variations, for Al Cq is reasonable.
>
> Does anyone experienced similar problems or has any hint where the problem
> could origin form?
>
> Thank you in advance,
> Best regards,
>
> Zibi
>
>
> Pw.x ? 5.0
> Gipaw.x 5.0
> (version 4.3a gives similar results)
> ---
> Pw.x
>
> &control
>  calculation = 'scf'
>  prefix = 'LiBO2'
>  restart_mode = 'from_scratch'
>  pseudo_dir = './pseudo/'
>  outdir = './tmp/'
>  verbosity = 'high'
>  wf_collect=.true.
> /
> &system
>  ibrav = 0
>  celldm(1) = 1.0
>  nat = 16
>  ntyp = 3
>  ecutwfc = 110
>  ecutrho = 1000
>  spline_ps = .true.
>  occupations  =  'fixed'
> /
> &electrons
>  diagonalization = 'david'
>  diago_thr_init = 1e-4
>  mixing_mode = 'plain'
>  mixing_beta = 0.1
>  conv_thr =  1e-10
> /
>
> ATOMIC_SPECIES
> Li 6.941  Li.pbe-tm-gipaw-dc.UPF
> B  10.811 B.pbe-tm-gipaw.UPF
> O  15.999 O.pbe-tm-new-gipaw-dc.UPF
>
> CELL_PARAMETERS (alat=  1.)
> 8.020588949   0.0   0.0
> 0.0   8.020588949   0.0
> 0.0   0.0  12.497695405
>
> ATOMIC_POSITIONS (crystal)
> Li   0.0   0.0   0.5
> Li   0.5   0.0   0.24998
> Li   0.5   0.5   0.0
> Li   0.0   0.5   0.75002
> B0.0   0.0   0.0
> B0.5   0.0   0.75000
> B0.5   0.5   0.5
> B0.0   0.5   0.25000
> O0.154649384   0.249987860   0.125014658
> O0.845350616   0.750012140   0.125014658
> O0.249987860   0.845350616   0.874985342
> O0.750012140   0.154649384   0.874985342
> O0.345350616   0.250012141   0.625014658
> O0.654649384   0.749987859   0.625014658
> O0.749987859   0.345350616   0.374985342
> O0.250012141   0.654649384   0.374985342
>
> K_POINTS automatic
> 4 4 4   1 1 1
> ------
> Gipaw.x
>
> &inputgipaw
>  job = 'efg'
>  prefix = 'LiBO2'
>  tmp_dir = './tmp/'
>  iverbosity = 11
>  spline_ps = .true.
>  Q_efg(1) = 4.06! 7Li
>  Q_efg(2) = 4.06! 11B
>  Q_efg(3) = 2.55! 17O
> !   q_gipaw= 0.01
> /
> Q_efg for Li might not be perfect but shall not matter.
>
>

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] Generation of H and O GIPAW PP

[Davide Ceresoli]

Dear J?r?me,
 I think the atomic code got confused by your input and
classified the 1S as a core state. This is done in ld1_setup.f90,
from line 100. I'll check the code with your input and see
if I can fix it.

Best,
 Davide


On 08/28/2012 10:14 PM, j?r?me cuny wrote:
> Dear Davide,
>
> I have just tried the PPs you sent me and they works perfectly. I also
> understand what I was doing wrong in my initial input.
> So thanks a lot for the help.
>
> However, in my initial e-mail I forget to send the output corresponding to the
> bad H PP, where a core contribution appears. I send it to you now (as well as
> the corresponding PP generation input). Maybe that will help a future pwscf 
> user
> for not doing the same wrong thing as me.
>
> Best Regards,
>
> J?r?me Cuny
>

[Pw_forum] Generation of H and O GIPAW PP

[Davide Ceresoli]

Dear J?r?me,
 the two output files you attached do not show large differences,
The core contribution is only for oxygen, in both cases.

What can lead to wrong/inaccurate results is the linear dependence
between GIPAW projectors (in your "not-good" calculation). Moreover,
I strongly advise to generate always two projectors per angular
momentum in the &test section.

I've never tried to generate hydrogen with 'p' locality. Maybe someone
else can comment. In any case, I'm attaching original the input files
for the hydrogen and oxygen pseudopotentials. You can try to add to them.

Best wishes,
 Davide


On 08/28/2012 02:37 PM, j?r?me cuny wrote:
> Dear quantum-espresso users,
>
> I would like to share with you a problem I have for which I hope you could 
> help me.
>
> I am trying to generate H and O norm-conserving PP to calculate the NMR
> properties of water molecules using the GIPAW module.
> I am using the 4.3.2 version of both quantum-espresso and gipaw (I join to 
> this
> e-mail the make.sys file I used for the compilation).
>
> My problem is that, even if the generation of the PPs seems fine, their use by
> the gipaw module leads to bad results.
> I consider as good results the results I obtain using the H and O PP provided 
> in
> the example folder of the gipaw module (see file water-nmr_1.log).
>
> Using the input file H.pbe-tm_good.in for the PP generation of H, the result I
> obtain for one water molecule in a box is not too bad (see 
> water-nmr_1_good.log)
>
> However, my problem appear when I want to use as local part of the PP, the p
> orbital (see H.pbe-tm_bad.in and water-nmr_1_bad.log). Strangely, when I do
> this, I always obtain a contribution to the total chemical shit coming from 
> some
> core orbitals! The same problem occur when I generate the O PP (in that case I
> use as input, the data I found in a presentation on GIPAW, see fig
> O_PP_Slide.tiff) as the core contribution become really different from the one
> of the reference calculation.
>
> So, does somebody see what I do wrong in my PP generation? Or, of course, is
> there any other source of error that could lead to this problem?
>
> I have checked the previous postings on the subject (GIPAW+PP) and I have not
> find one that answered my question. If I missed the good one, I am sorry.
>
> Best Regards,
>
> J?r?me Cuny
> ETH-Zurich/USI-Campus
>
> 
> J?r?me Cuny
> Department of Chemistry and Applied Biochemistry
> ETH-Zurich
> USI-Campus, Via Giuseppe Buffi 13
> Computational Sciences/Parrinello
> 6900 Lugano, Switzerland
> Tel : +41 (0) 58666-4802   Fax : +41 (0) 58666-4817
> 
>
>

-- next part --
 &input
title = 'H'
prefix = 'h'
zed = 1
dft = 'PBE'
rel = 0
iswitch = 3
beta = 0.2
xmin = -8.0, dx = 0.01
nld = 3, rlderiv = 2.2, eminld  = -5.0, emaxld  = 5.0, deld = 0.005
 /
2
1S  1  0  0.5  1
2S  2  0  0.0  1
 &inputp
pseudotype = 1
lloc = 0
tm = .true.
file_pseudopw = 'H.pbe-tm-new-gipaw.UPF'
lgipaw_reconstruction = .true.
upf_v1_format = .true.
author = 'D.C.'
 /
1
1S  1  0  0.5  0.00  0.90  0.90
 &test
   ecutmin = 60
   ecutmax = 120
   decut   = 10
 /
2
1S  1  0  0.50  0.00  0.90  0.90
2S  2  0  0.00  0.00  0.90  0.90

-- next part --
 &input
title = 'O'
prefix = 'o'
zed = 8
dft = 'PBE'
rel = 1
iswitch = 3
beta = 0.2
xmin = -8.0, dx = 0.01
nld = 3, rlderiv = 2.0, eminld  = -5.0, emaxld  = 5.0, deld = 0.005
 /
5
1S  1  0  2.0  1
2S  2  0  2.0  1
2P  2  1  4.0  1
3S  3  0  0.0  1
3P  3  1 -1.0  1
 &inputp
pseudotype = 1
lloc = 1
tm = .true.
file_pseudopw = 'O.pbe-tm-new-gipaw.UPF'
lgipaw_reconstruction = .true.
upf_v1_format = .true.
author = 'D.C.'
 /
2
2S  1  0  2.0  0.00  1.40  1.40
2P  2  1  4.0  0.00  1.40  1.40
 &test
   ecutmin = 60
   ecutmax = 120
   decut   = 10
 /
4
2S  1  0  2.00  0.00  1.40  1.40
3S  2  0  0.00  0.00  1.40  1.40
2P  2  1  4.00  0.00  1.40  1.40
3P  3  1  0.00 -0.10  1.40  1.40

[Pw_forum] restart flag for nmr calculation using gipaw

[Davide Ceresoli]

Dear Prasenjit,
 by default gipaw should restart interrupted calculation.
You can check if "prefix.recoverNN" files are present in the
scratchdir. If you want instead to start from scratch, you
must manually remove those files.

Davide


On 08/22/2012 03:47 PM, Prasenjit Ghosh wrote:
> Dear all,
>
> I am doing an nmr calculation with gipaw. I need to restart the calculation
> because of restriction in the max cpu hour.
> However, in the manual for the gipaw input file, I could not find any flag to
> restart a calculation from the point where it has stopped.
> Is it possible to restart the nmr calculation using gipaw.x. If so how?
>
> With regards,
>
> Prasenjit
>
> --
> PRASENJIT GHOSH,
> IISER Pune,
> First floor, Central Tower, Sai Trinity Building
> Garware Circle, Sutarwadi, Pashan
> Pune, Maharashtra 411021, India
>
> Phone: +91 (20) 2590 8203
> Fax: +91 (20) 2589 9790

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] Wrong representation in 5.0

[Davide Ceresoli]

Dear all,
 I'm performing a phonon calculation on cubic cell (ibrav=1)
containing 65 atoms (64 + 1 impurity).

With espresso-4.3.2 there are no problems, however, using 5.0, PH
terminates with:

  %%
  Error in routine set_irr_sym (3322):
  wrong representation
  %%

  stopping ...

PW reports that there are 6 symmetry operations. In short:

   6 Sym. Ops. (no inversion) found
   isym =  1 identity
   isym =  2 120 deg rotation - cart. axis [-1,-1,-1]
   isym =  3 120 deg rotation - cart. axis [1,1,1]
   isym =  4 inv. 180 deg rotation - cart. axis [1,-1,0]
   isym =  5 inv. 180 deg rotation - cart. axis [-1,0,1]
   isym =  6 inv. 180 deg rotation - cart. axis [0,1,-1]

  point group C_3v (3m)
  there are  3 classes
  the character table:

E 2C3   3s_v
A_11.00  1.00  1.00
A_21.00  1.00 -1.00
E  2.00 -1.00  0.00

  the symmetry operations in each class:
  E1
  2C3  23
  3s_v 456

I can supply input coordinates and output files to whoever knows
how to fix this problem with PH in version 5.0.

Best regards,
 Davide

[Pw_forum] GIPAW for metallic system

[Davide Ceresoli]

Dear Prasenjit,
 not easy. Are you using only one k-point? could
you try to restart PW with occupations='fixed' or
occupations='from_input'?

Davide



On 07/12/2012 02:52 PM, Prasenjit Ghosh wrote:
> Dear Davide,
>
> Thanks a lot.
>
> Do you have any suggestion then on how to do nmr calculations for magnetic 
> systems?
> Actually I want to calculate the C nmr of Pd cluster on graphene oxide. 
> However,
> the Pd cluster is magnetic.
>
> With regards,
>
> Prasenjit
>
> On 12 July 2012 12:49, Davide Ceresoli  <mailto:davide.ceresoli at istm.cnr.it>> wrote:
>
> Dear Prasenjit,
>   it's not implemented yet.
>
> Davide
>
>
> On 07/12/2012 04:01 AM, Prasenjit Ghosh wrote:
>  > Dear all,
>  >
>  > Has GIPAW been included for calculations using smearing?  Some early
> posts says
>  > that it has not been done.
>  >
>  > I want to calculate the nmr spectra of a system which is magnetic and 
> for
> that I
>  > need to use smearing.
>  >
>  > So I was wondering whether in the latest version of QE, GIPAW with
> occupations
>  > smearing has been implemented or not.
>  >
>  > With regards,
>  >
>  > Prasenjit
>  >
>  > --
>  > PRASENJIT GHOSH,
>  > IISER Pune,
>  > First floor, Central Tower, Sai Trinity Building
>  > Garware Circle, Sutarwadi, Pashan
>  > Pune, Maharashtra 411021, India
>  >
>  > Phone: +91 (20) 2590 8203
>  > Fax: +91 (20) 2589 9790
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org <mailto:Pw_forum at pwscf.org>
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>
>
>
> --
> PRASENJIT GHOSH,
> IISER Pune,
> First floor, Central Tower, Sai Trinity Building
> Garware Circle, Sutarwadi, Pashan
> Pune, Maharashtra 411021, India
>
> Phone: +91 (20) 2590 8203
> Fax: +91 (20) 2589 9790

[Pw_forum] GIPAW for metallic system

[Davide Ceresoli]

Dear Prasenjit,
 it's not implemented yet.

Davide


On 07/12/2012 04:01 AM, Prasenjit Ghosh wrote:
> Dear all,
>
> Has GIPAW been included for calculations using smearing?  Some early posts 
> says
> that it has not been done.
>
> I want to calculate the nmr spectra of a system which is magnetic and for 
> that I
> need to use smearing.
>
> So I was wondering whether in the latest version of QE, GIPAW with occupations
> smearing has been implemented or not.
>
> With regards,
>
> Prasenjit
>
> --
> PRASENJIT GHOSH,
> IISER Pune,
> First floor, Central Tower, Sai Trinity Building
> Garware Circle, Sutarwadi, Pashan
> Pune, Maharashtra 411021, India
>
> Phone: +91 (20) 2590 8203
> Fax: +91 (20) 2589 9790

[Pw_forum] where is qe-gipaw?

[Davide Ceresoli]

Dear Y.C. Cheng,
 I've introduced a bug in qe-gipaw 5.0 with ultrasoft
pseudos and I have removed the archive from qe-forge. It will
be reuploaded asap.

Davide


On 06/26/2012 09:27 AM, ??? wrote:
> Dear all,
> I tried to compile the gipaw for qe4.3.2 and 5.0.
> When I try to make gipaw, both two QE version can not download gipaw from 
> qeforge.
> I checked the QEforge and find that the latest gipaw is for 4.3.1.
> How to compile gipaw for 4.3.2 or 5.0?
> Thank you in advance.
> Best,
> --
> Y. C. Cheng
> Department of Physics
> Nanjing University
> Nanjing 210093
> P. R. China
> Tel: 86-25-83592907
> Email: yccheng.nju at gmail.com 

[Pw_forum] GIPAW and nosymm

[Davide Ceresoli]

Dear Carlo,
can you rotate your cell parameters (using ibrav=0) such
that symmetry operations map cartesian axes into themselves,
like in the quartz example? In that case you can still exploit
symmetry. Otherwise... not with the current implementation.

Davide


On 05/22/2012 01:52 PM, Carlo Nervi wrote:
> Dear PW community,
> using GIPAW, up to now, I always added 'nosym= .true.' to preliminar scf
> calculations with Quantum espresso 4.3.2
> Is the limitation still necessary for GIPAW calculations?
> I'm doing calculations on a rather large system and symmetry could help a lot.
> BTW, the new version QE 5.0 includes some improvements in this respect?
> Thanks,
> Carlo

[Pw_forum] Reduced density gradient

[Davide Ceresoli]

On 05/18/2012 07:28 PM, jiayudai wrote:
> Dear Davide,
>
> Thanks for your reply. So, the technique is depended on the choosing the range
> of the density, and we should try different values to get the rquired 
> information.
Dear Jiayu,
 yes it does. An isovalue of 0.5-0.6 au (bohr^-3) is believed
to show dispersion interaction. A lower isovalue, 0.3-0.4 au is
for ionic polarized bonds. Right now this technique will give you
a qualitative description but there is work in progress to make it
quantitative.

> By the way, for the isofurface, it means that only when the density is lower
> than the isofurface value, the contour line will be plotted. Is it correct?
Actually, only points which have the same value as the isovalue will
be plotted. The density can be larger inside the isosurface.

>
> Thanks
>
> Jiayu
>

Best regards,
 Davide

[Pw_forum] Reduced density gradient

[Davide Ceresoli]

Dear Jiayu Dai,
 I haven't included any example of RDG but I successfully
reproduced all pictures of the JCTC. It works like plot_num=0
(charge density) and you can produce an XSF file. Then open it
with XCrysden and set the isovalue as suggested in the JCTC
paper and in the documentation. You should see a 'lenticular
shape surface' for each non-bonded interaction.

Davide


On 05/17/2012 09:23 AM, jiayudai wrote:
> Dear users,
>
> It's so pleased that the new version of QE code is released, and thanks a lot.
>
> In the new version, i found that the "Reduced density gradient" (J. Chem. 
> Theory
> Comput. 7, 625 (2011)) can be postprocessed using plot_num=9. So, is there any
> example on this new implemention?
>
> Thanks a lot.
>
> Jiayu Dai
>
>
>
> 
> ---
> Jiayu Dai
> Department of PhysicsNational University of Defense Technology,
> Changsha, 410073, P R China
> -----

-- 
+--+
   Davide Ceresoli
   CNR Institute of Molecular Science and Technology (CNR-ISTM)
   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
   Email: davide.ceresoli at istm.cnr.it
   Phone: +39-02-50314276, +39-347-1001570 (mobile)
   Skype: dceresoli
+--+

[Pw_forum] Magnetic susceptibility in GIPAW calculation

[Davide Ceresoli]

Dear Peng Tao,
 let's take PRB 63, 245101 (the famous GIPAW paper by
Pickard and Mauri). Eq. 65. is used to calculate the
magnetic susceptibility, and the sequence of operators is:

 

hence the name 'pGv'. However, the PAW contributions to
the susceptibility are very complicated and have not been
implemented, neither in QE-GIPAW nor in PARATEC. A good
estimate is 'vGv', that is velocity*green's function*velocity.

It is expected that the true susceptibility is bounded
between the two values printed by the code (pGv and vGv).
You can see that the difference in not huge.

Regarding time evolution of susceptibility, I think you mean
during a molecular dynamics run. Well, the only way is to
extract snapshots from MD and computed the susceptibility
for each of them.

HTH.

Best wishes,
 Davide



On 05/07/2012 08:24 AM, Peng Tao wrote:
> Dear all,
>
> I find it is difficult to understand the magnetic susceptibility in GIPAW 
> output files. It is written like this:
>
>   chi_bare pGv (HH) in 10^{-6} cm^3/mol:
> -17.5504  0.  0.
>   0.-18.2449  0.
>   0.  0.-24.3766
>
>
>
>
>   chi_bare vGv (VV) in 10^{-6} cm^3/mol:
> -17.8523  0.  0.
>   0.-15.4914  0.
>   0.  0.-25.0791
>
>
> What is "pGv" or "vGv"?
>
> And, I want to investigate how the susceptibility varies with the time. Is it 
> possible for GIPAW to realize this?
>
> Thank you very much and many regards.
>
> Plato Tao
>
>
> --
> ---
> PH.D. candidate Peng Tao
> Magnetism and Magnetic Materials Division
> National Laboratory for Material Science
> Institute of Metal Research, Chinese Academy of Sciences
> Phone  +86-024-83978751
> ---

[Pw_forum] read_pseudo_gipaw : error # 1

[Davide Ceresoli]

Dear Mohamed,
 if QE issues an error while reading GIPAW pseudopotentials, edit the UPF 
file, search for the  and 
tags and change the version from '0.1' to '1'.

HTH

Davide


On 01/-10/-28163 08:59 PM, mohamed makhyoun wrote:
> Dear all :
>
> Running pw.x for the benzene example found in
> ./qe-gipaw-4.3.2/examples/benzene-USPP/benzene-scf.in I got the following 
> error :
>
>
> 
> from read_pseudo_gipaw : error # 1
> Reading pseudo file
> %%
>
> Since I am interested to do nmr calculations on some complexes containing C, H
>
> I appreciate any help.
>
> Best regard
> Mohamed
>

[Pw_forum] Hybrid functional pressure

[Davide Ceresoli]

Dear Sam,
 I hope I have implemented correctly the formula found in:
Phys. Rev. B 73, 125120 (2006). As suggested by Stefano Baroni
I test it by applying finite deformations to an fcc-silicon cell.

I recall that it worked well for the diagonal components of the
stress, although it converges extremely slowly with respect to
q-points (not k-points, but nq1, nq2, nq3). For the off-diagonal
components (i.e. shear modulus), I couldn't achieve convergence.

The answer to your question is: we need more testing. Maybe you
can help by testing the two approaches (the formula and the finite
deformations) on your system and then let us know.

Best,
 Davide


On 01/-10/-28163 08:59 PM, Azadi, Sam wrote:
> Dear QE users,
>
> As it's written in README file of EXX_examples directory, corresponding 
> formula of stress calculation
> using hybrid functionals have not yet been coded in quantum espresso.
> But by choosing "tstress =true." in scf input file, there is a value for 
> stress in scf output file.
> My question is, is it reliable ?
>
> Yours
> S.A
>
>

-- 
--------
Davide Ceresoli - davide.ceresoli at istm.cnr.it   CNR-ISTM
via Golgi 19, 20133 Milan, Italy  Phone: +39-02-50314276
Skype: dceresoli Mobile: +39-347-1001570

[Pw_forum] GIPAW: error in output

[Davide Ceresoli]

On 01/-10/-28163 08:59 PM, Carlo Nervi wrote:
> The gipaw calculations proceed, apparently ends normally,
> but the output contains several NotaNumber (NaN). Anuone
> have an idea qhat's wrong or could please give some hints
> how to solve the problem?
> Thank you,
>Carlo
Problem found! Change line 356 of qe-gipaw/src/nmr_routines.f90 from:
 call greenfunction(ik,aux1, aux2 , 0.d0)
to:
 call greenfunction(ik,aux1, aux2 , (/0.d0,0.d0,0.d0/))

I've found that the Intel compiler is anyway filling the q array with
zeros, but other compilers don't. As a result q(2) and q(3) contained
random values from the RAM.

I've tested with gfortran and I hope that now it will work with
every compiler.

Best,
 Davide

[Pw_forum] GIPAW: error in output

[Davide Ceresoli]

Dear Carlo,
 if I must guess, 90% that it is a problem of the gfortran
compiler. I recognize that the situation of fortran compilers
and of the floating-point behavior of CPUs is very annoying.

I'm using the Intel compiler with MKL and FFTW3 and I've run
most calculations of x86_64 CPUs. If I will have time, I'll
give a try to gfortran 4.6.

Best,
 Davide


On 01/-10/-28163 08:59 PM, Carlo Nervi wrote:
> Hello,
> I succesfully compiled QE 4.3.2 and the corresponding
> GIPAW module on a Opteron 6168 linux using gfortran 4.6,
> acml 5.0.0 and amdlibm 3.0.1.
>
> I did the benzene-scf.in job in the
> GIPAW/examples/benzene-USPP/ directory. The scf energy is
> the same as the reference output, which is in the same
> directory (apparently all is okay).
> I've compiled the gipaw module by the common way 'make
> gipaw' from the source QE dir. - I hope this was okay...
>
> The gipaw calculations proceed, apparently ends normally,
> but the output contains several NotaNumber (NaN). Anuone
> have an idea qhat's wrong or could please give some hints
> how to solve the problem?
> Thank you,
>Carlo
>
> ...
>   negative rho (up, down):  0.103E-03 0.000E+00
>   init_paw_1: ntyp= 1  rc=1.4000  rs=0.9333
>   init_paw_1: ntyp= 1  rc=1.4000  rs=0.9333
>   init_paw_1: ntyp= 1  rc=1.4000  rs=0.9333
>   init_paw_1: ntyp= 1  rc=1.4000  rs=0.9333
>
>   init_gipaw_1: projectors nearly linearly dependent:
>   ntyp =  1, l/n1/n2 =  0 2 1  0.99622328
>   init_gipaw_1: projectors nearly linearly dependent:
>   ntyp =  1, l/n1/n2 =  1 2 1  0.99789339
>   init_paw_1: ntyp= 2  rc=0.8000  rs=0.5333
>   init_paw_1: ntyp= 2  rc=0.8000  rs=0.5333
>   init_gipaw_1: projectors nearly linearly dependent:
>   ntyp =  2, l/n1/n2 =  0 2 1  0.99987400
>
>   GIPAW: 4.81s CPU10.71s WALL
>
>   Computing the magnetic susceptibility isolve=0
> ethr=0.1000E-13
>   k-point #1 of 1  pool #  1
>   ik   1 ibnd  16 linter: root not converged  0.305E+07
>   ik   1 ibnd  16 linter: root not converged  0.139E+31
>   ik   1 ibnd  16 linter: root not converged  0.122E+27
>   End of magnetic susceptibility calculation
>
>   f-sum rule (1st term):
>   **  0.  0.
>   0.-29.8546  0.
>   0.  0.-29.9120
>
>   f-sum rule (2nd term):
>  -0.3248  0.  0.
>   0. -0.3248  0.
>
> ...
>
>   Contributions to the NMR chemical shifts:
> ---
>
>   Core contribution in ppm:
>
>   Atom  1  C   pos: (  0.00  0.107679  0.00)
> sigma: 200.51
>   Atom  2  C   pos: (  0.093253  0.053840  0.00)
> sigma: 200.51
>   Atom  3  C   pos: (  0.093253 -0.053840  0.00)
> sigma: 200.51
>   Atom  4  C   pos: (  0.00 -0.107679  0.00)
> sigma: 200.51
>   Atom  5  C   pos: ( -0.093253 -0.053840  0.00)
> sigma: 200.51
>   Atom  6  C   pos: ( -0.093253  0.053840  0.00)
> sigma: 200.51
>   Atom  7  H   pos: (  0.00  0.191523  0.00)
> sigma:   0.00
>   Atom  8  H   pos: (  0.165864  0.095761  0.00)
> sigma:   0.00
>   Atom  9  H   pos: (  0.165864 -0.095761  0.00)
> sigma:   0.00
>   Atom 10  H   pos: (  0.00 -0.191523  0.00)
> sigma:   0.00
>   Atom 11  H   pos: ( -0.165864 -0.095761  0.00)
> sigma:   0.00
>   Atom 12  H   pos: ( -0.165864  0.095761  0.00)
> sigma:   0.00
>
>   Bare contribution in ppm:
>
>   Atom  1  C   pos: (  0.00  0.107679  0.00)
> sigma:NaN
>  NaN NaN NaN
>  NaN NaN NaN
>  NaN NaN NaN
>
>   Atom  2  C   pos: (  0.093253  0.053840  0.00)
> sigma:NaN
>  NaN NaN NaN
>  NaN NaN NaN
>  NaN NaN NaN
>
> ...
>   Total NMR chemical shifts in ppm:
> ---
>
>   Atom  1  C   pos: (  0.00  0.107679  0.00)
> sigma:NaN
>   C1anisotropy:   NaNeta:0.
>   C1sigma_xx=   NaNaxis=(   NaN
>NaN  0.00)
>   C1sigma_yy=   NaNaxis=(   NaN
>NaN  0.00)
>   C1sigma_zz=   NaNaxis=(  0.00
> 0.00  1.00)
>
>   Atom  2  C   pos: (  0.093253  0.053840  0.00)
> sigma:NaN
>   C2anisotropy:   NaNeta:0.
>   C2sigma_xx=   NaNaxis=(   NaN
>NaN  0.00)
>   C2sigma_yy=   

[Pw_forum] How to speed up gipaw?

[Davide Ceresoli]

Dear Pengju,
 on possibility is to use pools, in order to distribute k-points on more
CPUs. I always set iverbosity=1 to see some output as the calculation
is running (I suffer of empty-output-phobia).

To get an idea of the computational cost: I have calculated a complicated
silicate mineral with 88 atoms in the unit cell. 4 special k-points. The
calculation took 1 day on 16 CPUs.

Davide

On 01/-10/-28163 08:59 PM, Ren PJ wrote:
> Dear all,
> I'm using gipaw to calculate NMR of a system contain more than 100
> atoms, but the first k point haven't been done after more than 40
> hours. It's so slow for me.
> Here is my input:
> &inputgipaw
>  job =nmr'
>  prefix =pw'
>  tmp_dir =./tmp/'
>  isolve =
>  conv_threshold
-10
>  iverbosity =
>  q_gipaw = .01
>  spline_ps =true.
>  use_nmr_macroscopic_shape =true.
> nmr_macroscopic_shape =.5 0.0 0.0 0.0 0.5 0.0 0.0 0.0 0.6667
> /
> Can anyone figure me out how to improve this?
> PS. My computer is 8 core cpu, and gipaw and QE is compiled with intel
> mkl lib.
> Thanks very much!
> 
> Pengju Ren
> 
> Dalian Institute of Chemical Physics,
> Chinese Academy of Science
> 

[Pw_forum] At line 174 of file paw_gipaw.f90 (unit = 14, file = '')

[Davide Ceresoli]

Dear Daniel,
 this is a fallback situation. When GIPAW pseudopotentials
are not available, the code will try to read the 'Paratec
reconstruction file'. We did this in the beginning in order
to debug the code and make sure we obtained the same results
of Paratec. This feature will be removed soon and a clearer
error message will be printed.

Cheers,
 Davide


On 01/-10/-28163 08:59 PM, Daniel Lima wrote:
> Hi,
> My name is Daniel Aguiar, and I'm a beginner in Theoretical Calculations.
> I'm having some troubles with the gipaw.x calculations.
> The pw.x was sucessed (JOB DONE!!).
> But in gipaw.x the following mensage appear:
>
> At line 174 of file paw_gipaw.f90 (unit = 14, file = '')
> Fortran runtime error: File '' does not exist
>
>
> I verified in paw_gipaw.f90 and the line is:
>
> OPEN ( 14, FILE = filerec_sp )
>
> What's wrong?
>
> My nmr input is following below:
>
> &inputgipaw
> job = 'nmr'
> prefix = 'ADAMANTANE-rev-PBE-vdW-nmr'
> tmp_dir = '/home/daniel/Softwares/espresso-4.3/tmp/'
> isolve = 0
> iverbosity = 1
> q_gipaw = 0.01
> spline_ps = .true.
> use_nmr_macroscopic_shape = .false.
> /

[Pw_forum] GPU-enabled

[Davide Ceresoli]

Dear Ali and Wang,
if you search the pw-forum archives, you will find that on
May 5th, the "First PWscf GPU-enabled beta-release" has been
announced and that there is a mailing list dedicated to this project.

Best,
Davide



On 05/21/2011 10:04 AM, Ali Tavana wrote:
> Or, How is it possible to compile the QE on GPUs?
> (any reference to a detailed tutorial?)
> 
> 
> Ali Tavana
> 
> 
> 2011/5/21 S. D. Wang mailto:sd.wang000 at 
> gmail.com>>
> 
> Dear all:
> Waht does the GPU-enabled mean?
> 
> -- 
> S. D. Wang
> *
> *
> *???*
> *
> *
> 
> 
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org 
> http://www.democritos.it/mailman/listinfo/pw_forum
> 
> 

[Pw_forum] Cohesive Energy of N2 molecule

[Davide Ceresoli]

On 05/03/2011 05:54 PM, Izaak Williamson wrote:
> Dear all,
>
> I am trying to calculate the cohesive energy of the N2 molecule using the
> attached input file (relax.in ) and am getting a value of
> -16.57 eV. I use DFT with GGA and the pseudo-potential N.pbe-rrkjus.UPF. Other
> work [Fuchs et. al., Phys. Rev. B 65, (2002)245212] has performed similar
> calculations and obtained values ~10.5 eV. They even list an experimental 
> value
> of 9.76 eV. Why is my value so much higher? Is there anything in my input file
> that could be giving inaccurate results? Is it my pseudo-potential that is
> causing this problem?
>
> Thanks for any help.
Dear Izaak,
 how much do you get for an isolated N atom, spin polarized, same
cell, same pseudo, same cutoffs?
In an old output file I've got: -39.7039435178 Ry for N2 at equilibrium
and -19.48996768 Ry for the N atom. Therefore: -0.724 Ry = -9.85 eV
(N.pbe-rrkjus.UPF)

Davide

[Pw_forum] Problem to run GIPAW

[Davide Ceresoli]

On 04/01/2011 01:08 PM, Ronaldo Giro wrote:
> Dear all
>
> If a tried to calculate 'efg' - electrical field gradient, everything goes 
> fine.
> But if I tried other options like 'nmr', 'g_tensor', 'f_sum' I got the
Dear Ronaldo,
are you sure you get the error message also with job='nmr'?
There is no such check in suscept_crystal.f90 (which calculates
the NMR shielding), unless you modified the code.

Also, is your system spin polarized? if not it doesn't make sense
to calculate the g-tensor.

Finally, the message is a warning but the code should continue
although results will make no sense. Definitely, it should not
crash with an MPI error. It looks like that there might a
problem with your compiler/libraries.

Cheers,
 Davide

[Pw_forum] iotk error - again

[Davide Ceresoli]

On 02/10/2011 11:32 AM, Lorenzo Paulatto wrote:
> On Thu, 10 Feb 2011 12:31:00 +0100, Davide Ceresoli
>   wrote:
>> Or to upgrade it: the latest Intel compiler (12.0.2, named XE 2011.2.137)
>
> I did a mistake before, the one that gives problems is XE (12.0.0), I know
> nothing about 12.0.x with x>0. If you have experienced no problems, I
> strongly encourage to upgrade.
>
One simple rule I've learned in the past: avoid ".0" releases of the Intel
compiler!

Cheers.