[Pw_forum] epsilon.f90 skips transitions involving similarly occupied states (Paolo Giannozzi)
Roberto Gaspari
Roberto.Gaspari at iit.it
Fri May 13 14:20:14 CEST 2016
Dear Paolo,
thank you for your answer. I understand your point - in my case I use some smearing so closely spaced states
at the Fermi level have fractional, slightly different occupancies and may contribute.
Anyway I understand that epsilon.x has been numerically well tested.
I have been also looking at 5.4.0 version and by the way thank you for fixing the problem with restart nspin=2.
Best Regards
Roberto
________________________________________
Da: pw_forum-bounces at pwscf.org [pw_forum-bounces at pwscf.org] per conto di pw_forum-request at pwscf.org [pw_forum-request at pwscf.org]
Inviato: venerdì 13 maggio 2016 12.00
A: pw_forum at pwscf.org
Oggetto: Pw_forum Digest, Vol 106, Issue 13
Send Pw_forum mailing list submissions to
pw_forum at pwscf.org
To subscribe or unsubscribe via the World Wide Web, visit
http://pwscf.org/mailman/listinfo/pw_forum
or, via email, send a message with subject or body 'help' to
pw_forum-request at pwscf.org
You can reach the person managing the list at
pw_forum-owner at pwscf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pw_forum digest..."
Today's Topics:
1. Re: Pw_forum Digest, Vol 106, Issue 12 (?????)
2. Re: [QE-GPU] Maxwell architecture (Filippo SPIGA)
3. Ifort version (Alexander Martins)
4. Re: crmno4 structure is not converging (Giuseppe Mattioli)
5. Re: ATOMIC_POSISTIONS nonexistent when using space groups
(Gunnar Palsson)
6. G vector used to represent wfcs (Ryky Nelson)
7. Re: ATOMIC_POSISTIONS nonexistent when using space groups
(Filippo SPIGA)
8. Re: Ifort version (Filippo SPIGA)
9. Re: Ifort version (Paolo Giannozzi)
10. Re: Ifort version (Alexander Martins)
11. Re: ATOMIC_POSISTIONS nonexistent when using space groups
(Gunnar Palsson)
12. Re: [QE-GPU] Maxwell architecture (Rolly Ng)
13. Re: G vector used to represent wfcs (dario rocca)
14. Grimme C_ij for epitaxial graphene (Matthieu Fortin-Desch?nes)
15. gipaw.x (Manuel Otero)
16. Re: Grimme C_ij for epitaxial graphene (Paolo Giannozzi)
17. Re: Grimme C_ij for epitaxial graphene (Martin Andersson)
18. Re: Fermi Surface Visualization (Paolo Giannozzi)
19. Re: G vector used to represent wfcs (Ryky Nelson)
20. epsilon.f90 skips transitions involving similarly occupied
states (Roberto Gaspari)
21. Re: epsilon.f90 skips transitions involving similarly
occupied states (Paolo Giannozzi)
22. Re: epsilon.f90 skips transitions involving similarly
occupied states (Andrea Ferretti)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 May 2016 13:03:03 +0300
From: "?????" <Antony17 at yandex.ru>
Subject: Re: [Pw_forum] Pw_forum Digest, Vol 106, Issue 12
To: pw_forum at pwscf.org
Message-ID: <15571463047383 at mxfront7o.mail.yandex.net>
Content-Type: text/plain; charset="utf-8"
??????? ??????? ?????!
? ???????? ? ??????? ? 3 ?? 11 ???. ? ????????? ?? ???? ??? ???????? ??????????.
??? ?????? ??????????? ? ??? ??????.
--------------------
? ?????????,
????? ?????
------------------------------
Message: 2
Date: Thu, 12 May 2016 12:19:46 +0200
From: Filippo SPIGA <filippo.spiga at quantum-espresso.org>
Subject: Re: [Pw_forum] [QE-GPU] Maxwell architecture
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<189930A9-7CAB-43B2-A932-1986094CE381 at quantum-espresso.org>
Content-Type: text/plain; charset=us-ascii
Hello Gunnar,
On May 11, 2016, at 4:15 PM, Gunnar Palsson <gunnar.karl at gmail.com> wrote:
> My question is: Is there a way to compile QE-GPU with the Maxwell architecture and if so how? I read on the forum that unfortunately the Maxwell architecture does not do double precision very well.
Maxell is not supported, you can force the compilation but as you pointed already in your email double precision is going to be bad.
> Is it a prohibitive loss of precision if one restricts the calculations to single precision?
Well... for the GPU implementation you simply cannot switch precision on-demand. QE-GPU reflects the QE implementation, if the original code si double precision than the GPU code is double precision. QE is all double precision so the switch cannot be done.
I cannot comment on what it is going to happen if you switch everywhere from double to single (for some part it may work, for other may not), domain experts in the physics can give a proper answer to this. from an implementation point of you, again, cannot be done.
HTH
Cheers
--
Mr. Filippo SPIGA, M.Sc.
Quantum ESPRESSO Foundation
http://www.quantum-espresso.org ~ skype: filippo.spiga
*****
Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and may be privileged or otherwise protected from disclosure. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission."
------------------------------
Message: 3
Date: Thu, 12 May 2016 07:29:46 -0300
From: Alexander Martins <alex.msilva08 at gmail.com>
Subject: [Pw_forum] Ifort version
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAMHC5fkj-3wOd3uADpf=t4xhyF2DztN2GksOO_9aJr5m9L3xAg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I can't get a successful compilation of QE 5.3.0 with ifort 12.0.5? Should
I upgrade ifort?
Thanks in advance,
Alexander.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/68c1fb53/attachment-0001.html
------------------------------
Message: 4
Date: Thu, 12 May 2016 13:01:45 +0200
From: Giuseppe Mattioli <giuseppe.mattioli at ism.cnr.it>
Subject: Re: [Pw_forum] crmno4 structure is not converging
To: pw_forum at pwscf.org
Message-ID: <1847988.60r6U2W5mb at amore2>
Content-Type: text/plain; charset="ISO-8859-1"
Dear Rajkamal.A.
You will hardly perform a calculation such as yours with NC PPs (mt=Martins-Troullier norm-conserving pseudopotentials) and with a 30Ry cutoff on
wavefunctions. Check *always* convergence wrt the basis set *before* starting production runs.
HTH
Giuseppe
On Thursday, May 12, 2016 07:51:56 AM Raj kamal wrote:
> dear QE experts below my input file is attached which is not
> converging....please suggest me how to converge this file.thanks in advance
>
>
> &CONTROL
> calculation = 'vc-relax' ,
> outdir = '/home/
> pseudo_dir = '/home/
> prefix = 'crmno112',
> etot_conv_thr = 1.0D-5,
> forc_conv_thr = 1.0D-4,
> tprnfor=.TRUE.
> /
> &SYSTEM
> ibrav = 0,
> nat = 112,
> ntyp = 3,
> ecutwfc =30.0 ,
> ecutrho =120,
> occupations='smearing',
> smearing='gauss',
> degauss=0.02,
> nspin = 2,
> starting_magnetization(1)= 0.5,
> starting_magnetization(2)= 0.5,
> /
> &ELECTRONS
> electron_maxstep = 500
> mixing_mode = 'plain' ,
> mixing_beta = 0.4,
> diagonalization = 'cg' ,
> conv_thr = 1.0e-6,
>
> /
> &IONS
> ion_dynamics = 'bfgs' ,
> /
> &CELL
> cell_dynamics = 'bfgs',
> cell_dofree = 'all'
> /
> ATOMIC_SPECIES
> Cr 51.9961 Cr.pbe-mt_fhi.UPF
> Mn 54.938049 Mn.pbe-mt_fhi.UPF
> O 15.9997 O.pbe-mt_fhi.UPF
> CELL_PARAMETERS angstrom
> 16.87400 0.00000 0.00000
> -0.00000 8.43700 0.00000
> -0.00000 -0.00000 8.43700
> ATOMIC_POSITIONS angstrom
> Mn 0.00000 0.00000 0.00000
> Mn -0.00000 4.21850 4.21850
> Mn 4.21850 -0.00000 4.21850
> Mn 4.21850 4.21850 0.00000
> Mn 6.32775 2.10925 6.32775
> Mn 2.10925 2.10925 2.10925
> Mn 2.10925 6.32775 6.32775
> Mn 6.32775 6.32775 2.10925
> Cr 5.27312 5.27312 5.27313
> Cr 5.27313 1.05462 1.05463
> Cr 1.05462 5.27313 1.05463
> Cr 1.05462 1.05462 5.27313
********************************************************
- Article premier - Les hommes naissent et demeurent
libres et ?gaux en droits. Les distinctions sociales
ne peuvent ?tre fond?es que sur l'utilit? commune
- Article 2 - Le but de toute association politique
est la conservation des droits naturels et
imprescriptibles de l'homme. Ces droits sont la libert?,
la propri?t?, la s?ret? et la r?sistance ? l'oppression.
********************************************************
Giuseppe Mattioli
CNR - ISTITUTO DI STRUTTURA DELLA MATERIA
v. Salaria Km 29,300 - C.P. 10
I 00015 - Monterotondo Stazione (RM), Italy
Tel + 39 06 90672836 - Fax +39 06 90672316
E-mail: <giuseppe.mattioli at ism.cnr.it>
http://www.ism.cnr.it/en/staff/giuseppe-mattioli/
ResearcherID: F-6308-2012
------------------------------
Message: 5
Date: Thu, 12 May 2016 13:31:35 +0200
From: Gunnar Palsson <gunnar.karl at gmail.com>
Subject: Re: [Pw_forum] ATOMIC_POSISTIONS nonexistent when using space
groups
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID: <B8D80233-2C43-4E00-94A4-F98DE283E5E7 at gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Filippo,
Thank you very much for the quick and informative reply.
It seems that I?m out of luck then. However I would still be interested in testing the double precision capabilities of the two cards with QE-GPU if possible. Is there a workaround for the error I?m getting? Also do you know if there is a plan to support the Maxwell architecture in the future? I?m thinking whether the performance might be improved by ?switching the GPU to TCC mode? as explained in the link below. It seems like TCC mode is supported for QUADRO M5000.
http://arrayfire.com/explaining-fp64-performance-on-gpus/ <http://arrayfire.com/explaining-fp64-performance-on-gpus/>
Best regards,
Gunnar
> On 12 May 2016, at 03:36, Dae Kwang Jun <jdaekwang at gmail.com> wrote:
>
> Hello Gunnar,
>
> On May 11, 2016, at 4:15 PM, Gunnar Palsson <gunnar.karl at gmail.com> wrote:
>> My question is: Is there a way to compile QE-GPU with the Maxwell architecture and if so how? I read on the forum that unfortunately the Maxwell architecture does not do double precision very well.
>
> Maxell is not supported, you can force the compilation but as you pointed already in your email double precision is going to be bad.
>
>
>> Is it a prohibitive loss of precision if one restricts the calculations to single precision?
>
> Well... for the GPU implementation you simply cannot switch precision on-demand. QE-GPU reflects the QE implementation, if the original code si double precision than the GPU code is double precision. QE is all double precision so the switch cannot be done.
>
> I cannot comment on what it is going to happen if you switch everywhere from double to single (for some part it may work, for other may not), domain experts in the physics can give a proper answer to this. from an implementation point of you, again, cannot be done.
>
> HTH
>
> Cheers
>
> --
> Mr. Filippo SPIGA, M.Sc.
> Quantum ESPRESSO Foundation
> http://www.quantum-espresso.org ~ skype: filippo.spiga
>
> *****
> Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and may be privileged or otherwise protected from disclosure. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission."
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/524d8e43/attachment-0001.html
------------------------------
Message: 6
Date: Thu, 12 May 2016 13:38:19 +0200
From: Ryky Nelson <nelson.ryky at gmail.com>
Subject: [Pw_forum] G vector used to represent wfcs
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAMmLhK6Wu3ACFyycFvDfAX6Ka0ndfdNP4R-6xO=WG+29xG1SGg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello QE users and developers,
I'm trying to figure out how G vectors in PWscf are selected to represent
the corresponding wfcs. Could someone tell me if the following is the only
criterion used to determine G vectors?
abs(G+k)^2 * hbar^2 / (2m_e) < E_cut
and does the code basically start from the origin (0,0,0) and scan through
all grid coordinates (positive and negative) and check if the grid agrees
with the above criterion? Also, does the number of G vectors (for each k)
have relation to the FFT dimensions?
Thank you!
Ryky Nelson
Institut f?r Anorganische Chemie
RWTH Aachen University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/5a42f454/attachment-0001.html
------------------------------
Message: 7
Date: Thu, 12 May 2016 14:25:32 +0200
From: Filippo SPIGA <filippo.spiga at quantum-espresso.org>
Subject: Re: [Pw_forum] ATOMIC_POSISTIONS nonexistent when using space
groups
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<93BD3E18-A466-4720-B748-FE066740C4B5 at quantum-espresso.org>
Content-Type: text/plain; charset=utf-8
On May 12, 2016, at 1:31 PM, Gunnar Palsson <gunnar.karl at gmail.com> wrote:
> Is there a workaround for the error I?m getting?
I can pass you a couple of files to swap. Personally I believe it is just a curiosity exercise and nothing great will come out from it but if you insist it isfine for me :-)
> Also do you know if there is a plan to support the Maxwell architecture in the future?
No, the focus will be supporting QE-GPU on Pascal. Future NVIDIA gaming cards based on Pascal architecture will have a huge single precision perfemance (> 5TFlops per card) and a decent double precision one as well (~1.4 TFlops). All of this needs to be assessed and tested but it is going to be substantially better than Maxwell-based cards for codes that need double precision.
Check on google about GTC 1080 for more details. I look forward to try it myself!
> I?m thinking whether the performance might be improved by ?switching the GPU to TCC mode? as explained in the link below. It seems like TCC mode is supported for QUADRO M5000. http://arrayfire.com/explaining-fp64-performance-on-gpus/
Never experimented with TCC mode. I suspect it is something that is possible to use on GEFORCE and QUADRO products. On TESLA product line double precision performance is sadisfactory per se.
--
Mr. Filippo SPIGA, M.Sc.
Quantum ESPRESSO Foundation
http://www.quantum-espresso.org ~ skype: filippo.spiga
*****
Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and may be privileged or otherwise protected from disclosure. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission."
------------------------------
Message: 8
Date: Thu, 12 May 2016 14:27:05 +0200
From: Filippo SPIGA <filippo.spiga at quantum-espresso.org>
Subject: Re: [Pw_forum] Ifort version
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<7A4CDCF3-1653-493E-84C4-60721348A9E8 at quantum-espresso.org>
Content-Type: text/plain; charset=us-ascii
Hello Alexander,
On May 12, 2016, at 12:29 PM, Alexander Martins <alex.msilva08 at gmail.com> wrote:
> I can't get a successful compilation of QE 5.3.0 with ifort 12.0.5? Should I upgrade ifort?
can you tell us the exact version of ifort (ifort --version) and can you give us a bit more details about the error you get?
Upgrade the compiler is a solution and not a bad idea after all. But I am still curious to see and understand the error.
Regards
--
Mr. Filippo SPIGA, M.Sc.
Quantum ESPRESSO Foundation
http://www.quantum-espresso.org ~ skype: filippo.spiga
*****
Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and may be privileged or otherwise protected from disclosure. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission."
------------------------------
Message: 9
Date: Thu, 12 May 2016 14:51:16 +0200
From: Paolo Giannozzi <p.giannozzi at gmail.com>
Subject: Re: [Pw_forum] Ifort version
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAPMgbCttKxB+z8K6LoBuGyqg_ZrDP=uohmidzEbJSgYwLqtJAw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I never had any problem with this version:
$ ifort --version
ifort (IFORT) 12.0.2 20110112
Paolo
On Thu, May 12, 2016 at 12:29 PM, Alexander Martins <alex.msilva08 at gmail.com
> wrote:
> Dear all,
>
>
> I can't get a successful compilation of QE 5.3.0 with ifort 12.0.5? Should
> I upgrade ifort?
>
> Thanks in advance,
>
> Alexander.
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/99353af8/attachment-0001.html
------------------------------
Message: 10
Date: Thu, 12 May 2016 09:57:17 -0300
From: Alexander Martins <alex.msilva08 at gmail.com>
Subject: Re: [Pw_forum] Ifort version
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAMHC5fnFm4-QmV34Y=A7BX_4=8BGHCHoMk3u+YGGy77jYVW3Rg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Paolo,
$ ifort --version
ifort (IFORT) 12.0.5 20110719
Another person was trying to compile the QE 5.3. In this afternoon, I
will try this compilation and report here the possible errors.
Thank you,
Alexander.
2016-05-12 9:51 GMT-03:00 Paolo Giannozzi <p.giannozzi at gmail.com>:
> I never had any problem with this version:
>
> $ ifort --version
> ifort (IFORT) 12.0.2 20110112
>
>
> Paolo
>
> On Thu, May 12, 2016 at 12:29 PM, Alexander Martins <
> alex.msilva08 at gmail.com> wrote:
>
>> Dear all,
>>
>>
>> I can't get a successful compilation of QE 5.3.0 with ifort 12.0.5?
>> Should I upgrade ifort?
>>
>> Thanks in advance,
>>
>> Alexander.
>>
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum
>>
>
>
>
> --
> Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/36d6cc06/attachment-0001.html
------------------------------
Message: 11
Date: Thu, 12 May 2016 15:09:40 +0200
From: Gunnar Palsson <gunnar.karl at gmail.com>
Subject: Re: [Pw_forum] ATOMIC_POSISTIONS nonexistent when using space
groups
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID: <B3CA19DA-BE6E-4FB9-B46A-FA0976BA0D60 at gmail.com>
Content-Type: text/plain; charset=utf-8
Filippo,
I would be very grateful if you could send me the files to swap! I think you are probably right that it is a curiosity exercise but I?d like to take a whack at it. There might be room in our budget to go for a card like the GTC 1080 down the road, which looks very cool indeed.
Best regards,
Gunnar
> On 12 May 2016, at 14:25, Filippo SPIGA <filippo.spiga at quantum-espresso.org> wrote:
>
> On May 12, 2016, at 1:31 PM, Gunnar Palsson <gunnar.karl at gmail.com> wrote:
>> Is there a workaround for the error I?m getting?
>
> I can pass you a couple of files to swap. Personally I believe it is just a curiosity exercise and nothing great will come out from it but if you insist it isfine for me :-)
>
>
>> Also do you know if there is a plan to support the Maxwell architecture in the future?
>
> No, the focus will be supporting QE-GPU on Pascal. Future NVIDIA gaming cards based on Pascal architecture will have a huge single precision perfemance (> 5TFlops per card) and a decent double precision one as well (~1.4 TFlops). All of this needs to be assessed and tested but it is going to be substantially better than Maxwell-based cards for codes that need double precision.
>
> Check on google about GTC 1080 for more details. I look forward to try it myself!
>
>
>> I?m thinking whether the performance might be improved by ?switching the GPU to TCC mode? as explained in the link below. It seems like TCC mode is supported for QUADRO M5000. http://arrayfire.com/explaining-fp64-performance-on-gpus/
>
> Never experimented with TCC mode. I suspect it is something that is possible to use on GEFORCE and QUADRO products. On TESLA product line double precision performance is sadisfactory per se.
>
>
> --
> Mr. Filippo SPIGA, M.Sc.
> Quantum ESPRESSO Foundation
> http://www.quantum-espresso.org ~ skype: filippo.spiga
>
> *****
> Disclaimer: "Please note this message and any attachments are CONFIDENTIAL and may be privileged or otherwise protected from disclosure. The contents are not to be disclosed to anyone other than the addressee. Unauthorized recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission."
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
------------------------------
Message: 12
Date: Thu, 12 May 2016 21:48:59 +0800
From: "Rolly Ng" <rollyng at gmail.com>
Subject: Re: [Pw_forum] [QE-GPU] Maxwell architecture
To: "'PWSCF Forum'" <pw_forum at pwscf.org>
Message-ID: <00c901d1ac55$0a2883c0$1e798b40$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Gunnar,
I would recommend Kepler cards (K80 or K40) or even Fermi cards (m2090 or c2075) for QE.
If you are limited by budget, then it would be worth to try the Titan Z and Titan Black which performs decently on QE. I found that 2x Titan Z can double the scf speed comparing to 4x c2075. I have QE v5.3.0, cuda-6.5 and intel PSXE2015 installed on a OpenSUSE 13.2, it works fine so far.
Please be aware of the environmental variables need to be set persistently.
Regards,
Rolly
-----Original Message-----
From: pw_forum-bounces at pwscf.org [mailto:pw_forum-bounces at pwscf.org] On Behalf Of Gunnar Palsson
Sent: 2016?5?11? 22:16
To: pw_forum at pwscf.org
Subject: [Pw_forum] [QE-GPU] Maxwell architecture
Dear all,
We have 2x NVIDIA QUADRO M5000 8 GB and 2x INTEL XEON E5-2699-V3 16 cores running on ubuntu 16.04. I have managed to install the binary nvidia driver, the NVIDIA CUDA toolkit 7.5 and compiled quantum espresso 5.4.0 successfully with intel MKL. I seem to have also been able to compile the QE-GPU version but when I try to run it, it gives the following error message:
***WARNING: unbalanced configuration (1 MPI per node, 2 GPUs per node)
*** ERROR *** something went wrong inside query_gpu_specs! (rank 0)
The configuration was:
export LIBDIRS=?/opt/intel/lib/intel64 /opt/intel/mkl/lib/intel64"
make -f Makefile.gpu distclean
cd GPU
./configure ?enable-cuda ?enable-parallel ?with-phigemm ?without-magma ?with-gpu-arch=sm_35 cd ..
make -f Makefile.gpu pw-gpu
cd GPU/PW
./pw-gpu.x
I realized that the sm_35 is for the previous generation of cards, so I manually edited the make.sys and changed it to sm_53.
Recompiling with compute_50, sm_50, compute_52, sm_52 or compute_53, sm_53 did not make a difference.
I also manually edited the make.sys and the phigemm.inc and added:
-I/opt/intel/mkl/include -I/opt/intel/mkl/include/intel64/lp64 to IFLAGS
I had to add
NVCCFLAGS += -D_FORCE_INLINES -ccbin=$(CC) -Xcompiler -fPIC $(COMMON_FLAGS)
to make.sys to avoid a memcpy error during compilation. I also tried without phigemm with no effect.
My question is: Is there a way to compile QE-GPU with the Maxwell architecture and if so how? I read on the forum that unfortunately the Maxwell architecture does not do double precision very well. Is it a prohibitive loss of precision if one restricts the calculations to single precision? I?m really interested in seeing how well these graphics cards work together with the CPUs.
Best regards and thanks in advance,
Gunnar Palsson
_______________________________________________
Pw_forum mailing list
Pw_forum at pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum
------------------------------
Message: 13
Date: Thu, 12 May 2016 16:14:02 +0200
From: dario rocca <roccad at gmail.com>
Subject: Re: [Pw_forum] G vector used to represent wfcs
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAAEv5EUhDH79pNarhmJoVEaDsQ1EtuzT=z+wwNoyXPaGD0uf_A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Ryky,
For more details about the G vector generation you can take a look in the
ggen subroutine in Modules/recvec_subs.f90. Take a look also in
n_plane_waves.f90
In gereral the G vectors are determined with the condition
G^2 * hbar^2 / (2m_e) < E_cut(density)=4*E_cut(wfc) (without the k point;
inside QE Rydberg atomic units are used)
This is a sphere in reciprocal space centered in (0,0,0).
Concerning each orbital corresponding to a specific k point you apply the
condition
(G+k)^2 * hbar^2 / (2m_e) < E_cut(wfc)
In this case the G vectors are a subset of the vectors used for the
density. In this case we have a sphere in reciprocal space shifted from the
origin. Depending on k you can have a different set of G vectors included
in the sphere and also their number could differ.
In order to menage the g vectors for each k-point, you can use the arrays
ngk (number of G vectors for each k-point) and igk (index of G
corresponding to a given index of k+G; basically an index that allows you
to identify the G vectors corresponding to a given k and order them).
For example the kinetic energy corresponding to a given k-point ik is
g2kin(1:ngk(ik)) = ( ( xk(1,ik) + g(1,igk(1:ngk(ik))) )**2 + &
( xk(2,ik) + g(2,igk(1:ngk(ik))) )**2 + &
( xk(3,ik) + g(3,igk(1:ngk(ik))) )**2 ) * tpiba2
where tpiba2 = (2\pi/a)^2
There is only one FFT for the wavefunctions so the grid does not depend on
the k-points; however, for a given wavefunction, only the components
corresponding to a G vector that satisfy (G+k)^2 * hbar^2 / (2m_e) <
E_cut(wfc) are different from 0
Best,
Dario
On Thu, May 12, 2016 at 1:38 PM, Ryky Nelson <nelson.ryky at gmail.com> wrote:
> Hello QE users and developers,
>
> I'm trying to figure out how G vectors in PWscf are selected to represent
> the corresponding wfcs. Could someone tell me if the following is the only
> criterion used to determine G vectors?
>
> abs(G+k)^2 * hbar^2 / (2m_e) < E_cut
>
> and does the code basically start from the origin (0,0,0) and scan through
> all grid coordinates (positive and negative) and check if the grid agrees
> with the above criterion? Also, does the number of G vectors (for each k)
> have relation to the FFT dimensions?
>
> Thank you!
>
> Ryky Nelson
> Institut f?r Anorganische Chemie
> RWTH Aachen University
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/80ae96e1/attachment-0001.html
------------------------------
Message: 14
Date: Thu, 12 May 2016 18:22:43 +0000
From: Matthieu Fortin-Desch?nes
<matthieu.fortin-deschenes at polymtl.ca>
Subject: [Pw_forum] Grimme C_ij for epitaxial graphene
To: pw_forum at pwscf.org
Message-ID:
<20160512182243.Horde.NXG2v_3mYwu-yNNc5KyCGbN at www.imp.polymtl.ca>
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Hi all,
I'm trying to calculate some basic properties of graphene on various
substrates using Grimme correction for VdW interactions. The Grimme
corrections seem to deteriorate the results (lattice parameter and
binding energy) of the graphene as well of the substrate compared to
experimental results.
I was wondering if it's possible to set C_ij=0 for i=j (no correction
for C-C interactions, as well as substrate-substrate interaction), but
non-zero C_ij for graphene-substrate interactions. As far as i know,
C_i are defined for each element and C_ij is calculated from
sqrt(C_i*C_j). I would like to set all C_ij by myself.
Thank you
Matthieu Fortin-Desch?nes
Polytechnique Montreal
------------------------------
Message: 15
Date: Thu, 12 May 2016 16:14:49 -0300
From: Manuel Otero <oteromn at gmail.com>
Subject: [Pw_forum] gipaw.x
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAB_rw4cw+VSt6+PXv5KmSQAdr4ecdRDVoBJ5ukbjoZW3DmK7Dg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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:
------------------------------------------------------------------------------------
&inputgipaw
job = 'nmr'
tmp_dir = './'
q_gipaw = 0.01
spline_ps = .true.
use_nmr_macroscopic_shape = .true.
/
-------------------------------------------------------------------------------------
And the output:
-------------------------------------------------------------------------------------
Program QE v.5.4.0 starts on 12May2016 at 8:28:47
This program is part of the open-source Quantum ESPRESSO suite
for quantum simulation of materials; please cite
"P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
URL http://www.quantum-espresso.org",
in publications or presentations arising from this work. More details
at
http://www.quantum-espresso.org/quote
Parallel version (MPI), running on 1 processors
***** This is GIPAW svn revision unknown *****
Parallelizing q-star over 1 images
Reading data from directory:
./pwscf.save
Info: using nr1, nr2, nr3 values from input
Info: using nr1, nr2, nr3 values from input
IMPORTANT: XC functional enforced from input :
Exchange-correlation = SLA PW PBX PBC ( 1 4 3 4 0 0)
Any further DFT definition will be discarded
Please, verify this is what you really want
G-vector sticks info
--------------------
sticks: dense smooth PW G-vecs: dense smooth PW
Sum 641 641 193 12053 12053 2103
Subspace diagonalization in iterative solution of the eigenvalue
problem:
a serial algorithm will be used
GIPAW projectors -----------------------------------------------
atom= H l=0 rc= 1.2000 rs= 0.8000
atom= H l=0 rc= 1.2000 rs= 0.8000
projs nearly linearly dependent: l=0 n1,n2= 1, 2 s= -0.99707079
atom= C l=0 rc= 1.7500 rs= 1.1667
atom= C l=0 rc= 1.7500 rs= 1.1667
atom= C l=1 rc= 1.7500 rs= 1.1667
atom= C l=1 rc= 1.7500 rs= 1.1667
projs nearly linearly dependent: l=1 n1,n2= 1, 2 s= -0.99430547
atom= O l=0 rc= 1.4500 rs= 0.9667
atom= O l=0 rc= 1.4500 rs= 0.9667
atom= O l=1 rc= 1.4500 rs= 0.9667
atom= O l=1 rc= 1.4500 rs= 0.9667
projs nearly linearly dependent: l=1 n1,n2= 1, 2 s= -0.99382826
-----------------------------------------------------------------
smearing ngauss= 0 degauss= 0.0050 Ry
alpha_pv= 27.9815 eV
GIPAW job:
nmr
NMR macroscopic correction: yes
0.6667 0.0000 0.0000
0.0000 0.6667 0.0000
0.0000 0.0000 0.6667
Largest allocated arrays est. size (Mb) dimensions
KS wavefunctions at k 0.31 Mb ( 1472, 14)
KS wavefunctions at k+q 0.31 Mb ( 1472, 14)
First-order wavefunctions 3.14 Mb ( 1472, 14, 10)
Charge/spin density 0.21 Mb ( 27000, 1)
Induced current 1.85 Mb ( 27000, 3,3,1)
Induced magnetic field 1.85 Mb ( 27000, 3,3,1)
NL pseudopotentials 0.07 Mb ( 1472, 3)
GIPAW NL terms 0.81 Mb ( 1472, 36)
Computing the magnetic susceptibility isolve=0 ethr= 0.1000E-13
k-point # 1 of 1 pool # 1 cpu time: 3.1
End of magnetic susceptibility calculation
f-sum rule (1st term):
-20.1385 0.0343 0.0018
0.0396 -20.7667 -0.0482
-0.0279 -0.0556 -19.5381
f-sum rule (2nd term):
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
f-sum rule (should be -20.0000):
-20.1385 0.0343 0.0018
0.0396 -20.7667 -0.0482
-0.0279 -0.0556 -19.5381
chi_bare pGv (HH) in paratec units:
-8.111321 -0.089278 -0.162804
0.084689 -4.403855 -1.881381
-0.019083 -1.907482 -5.571525
-8.111321 -0.089278 -0.162804
0.084689 -4.403855 -1.881381
-0.019083 -1.907482 -5.571525
chi_bare vGv (VV) in paratec units:
-8.396255 0.008744 -0.247577
0.033452 -5.035034 -1.627866
-0.213776 -1.644906 -6.067375
-8.396255 0.008744 -0.247577
0.033452 -5.035034 -1.627866
-0.213776 -1.644906 -6.067375
chi_bare pGv (HH) in 10^{-6} cm^3/mol:
-38.5458 -0.4243 -0.7737
0.4025 -20.9275 -8.9405
-0.0907 -9.0645 -26.4764
chi_bare vGv (VV) in 10^{-6} cm^3/mol:
-39.8998 0.0416 -1.1765
0.1590 -23.9270 -7.7358
-1.0159 -7.8167 -28.8327
Contributions to the NMR chemical shifts:
-------------------------------
Macroscopic shape contribution in ppm: 2.69
3.6186 0.0000 0.0000
-0.0000 1.9646 0.0000
0.0000 0.0000 2.4856
Core contribution in ppm:
Atom 1 H pos: ( 0.752224 0.789592 0.622680) core
sigma: 0.00
Atom 2 H pos: ( 0.951174 0.648257 0.851276) core
sigma: 0.00
Atom 3 H pos: ( 1.080748 0.860252 0.626511) core
sigma: 0.00
Atom 4 H pos: ( 0.703023 1.007130 1.041222) core
sigma: 0.00
Atom 5 H pos: ( 0.833779 1.215769 0.815795) core
sigma: 0.00
Atom 6 H pos: ( 1.117133 0.950964 1.179605) core
sigma: 0.00
Atom 7 C pos: ( 0.915939 0.822150 0.744767) core
sigma: 200.33
Atom 8 C pos: ( 0.869846 1.042890 0.922665) core
sigma: 200.33
Atom 9 O pos: ( 1.085885 1.098442 1.074706) core
sigma: 270.67
Bare contribution in ppm:
Atom 1 H pos: ( 0.752224 0.789592 0.622680) bare
sigma: 25.09
26.0625 1.8273 4.4375
1.7774 23.1239 1.9122
2.5439 2.5552 26.0825
Atom 2 H pos: ( 0.951174 0.648257 0.851276) bare
sigma: 25.76
22.9144 -1.9826 0.3695
-0.9485 30.2608 -2.4861
-0.2162 -1.1068 24.1123
Atom 3 H pos: ( 1.080748 0.860252 0.626511) bare
sigma: 24.69
25.4475 1.3890 -3.8302
-1.4758 21.3844 -0.2736
-4.5261 -0.9285 27.2391
Atom 4 H pos: ( 0.703023 1.007130 1.041222) bare
sigma: 22.75
26.3109 0.0354 -1.9862
1.5735 19.1495 1.7562
-0.4490 1.5663 22.7875
Atom 5 H pos: ( 0.833779 1.215769 0.815795) bare
sigma: 23.69
22.4615 -2.8223 2.1746
-1.2684 24.6928 0.0325
3.0915 -1.9351 23.9174
Atom 6 H pos: ( 1.117133 0.950964 1.179605) bare
sigma: 26.96
24.0411 -2.9849 5.2775
-2.2403 26.3910 -4.4965
5.3174 -4.2014 30.4409
Atom 7 C pos: ( 0.915939 0.822150 0.744767) bare
sigma: 18.21
28.7528 -24.7475 -5.8478
-6.3080 15.1127 21.5440
-4.1815 17.5814 10.7596
Atom 8 C pos: ( 0.869846 1.042890 0.922665) bare
sigma: -20.95
-18.7502 9.8457 21.7863
16.4429 -35.2450 8.1922
21.4969 7.9533 -8.8401
Atom 9 O pos: ( 1.085885 1.098442 1.074706) bare
sigma: 59.24
75.0512 6.2968 37.5933
-19.4634 58.3954 -19.4878
16.3500 5.1516 44.2657
Diamagnetic contribution in ppm:
Atom 1 H pos: ( 0.752224 0.789592 0.622680) dia
sigma: 0.30
0.3018 0.0000 0.0000
0.0000 0.3018 -0.0000
0.0000 -0.0000 0.3018
Atom 2 H pos: ( 0.951174 0.648257 0.851276) dia
sigma: 0.31
0.3081 0.0000 0.0000
0.0000 0.3081 -0.0000
0.0000 -0.0000 0.3081
Atom 3 H pos: ( 1.080748 0.860252 0.626511) dia
sigma: 0.30
0.3040 0.0000 0.0000
0.0000 0.3040 -0.0000
0.0000 -0.0000 0.3040
Atom 4 H pos: ( 0.703023 1.007130 1.041222) dia
sigma: 0.31
0.3147 0.0000 0.0000
0.0000 0.3147 -0.0000
0.0000 -0.0000 0.3147
Atom 5 H pos: ( 0.833779 1.215769 0.815795) dia
sigma: 0.31
0.3139 0.0000 0.0000
0.0000 0.3139 -0.0000
0.0000 -0.0000 0.3139
Atom 6 H pos: ( 1.117133 0.950964 1.179605) dia
sigma: 0.27
0.2700 0.0000 0.0000
0.0000 0.2700 -0.0000
0.0000 -0.0000 0.2700
Atom 7 C pos: ( 0.915939 0.822150 0.744767) dia
sigma: 3.13
3.1353 0.0020 0.0014
0.0020 3.1158 -0.0088
0.0014 -0.0088 3.1262
Atom 8 C pos: ( 0.869846 1.042890 0.922665) dia
sigma: 3.13
3.1388 0.0028 0.0057
0.0028 3.1229 -0.0069
0.0057 -0.0069 3.1372
Atom 9 O pos: ( 1.085885 1.098442 1.074706) dia
sigma: 2.72
2.7126 -0.0097 -0.0161
-0.0097 2.7328 -0.0080
-0.0161 -0.0080 2.7259
Paramagnetic contribution in ppm:
Atom 1 H pos: ( 0.752224 0.789592 0.622680) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 2 H pos: ( 0.951174 0.648257 0.851276) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 3 H pos: ( 1.080748 0.860252 0.626511) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 4 H pos: ( 0.703023 1.007130 1.041222) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 5 H pos: ( 0.833779 1.215769 0.815795) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 6 H pos: ( 1.117133 0.950964 1.179605) para
sigma: 0.00
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
0.0000 0.0000 0.0000
Atom 7 C pos: ( 0.915939 0.822150 0.744767) para
sigma: -24.59
-18.3800 -12.6293 -2.7974
-2.2746 -25.5132 10.7372
-0.7003 7.6236 -29.8855
Atom 8 C pos: ( 0.869846 1.042890 0.922665) para
sigma: -43.39
-43.5635 4.4329 7.3253
8.0071 -48.3291 2.5162
8.2612 2.6681 -38.2718
Atom 9 O pos: ( 1.085885 1.098442 1.074706) para
sigma: -10.83
-4.5779 1.6409 14.5155
-10.5485 -9.9291 -10.1861
3.8350 2.1952 -17.9841
Total NMR chemical shifts in ppm:
---------------------------------------
(adopting the Simpson convention for anisotropy and
asymmetry)-----------
Atom 1 H pos: ( 0.752224 0.789592 0.622680) Total
sigma: 28.08
29.9829 1.8273 4.4375
1.7774 25.3903 1.9122
2.5439 2.5552 28.8698
H 1 anisotropy: 8.73 eta: -0.3008
H 1 sigma_11= 26.0467 axis=( -0.705509 0.279308 0.651341)
H 1 sigma_22= 24.2962 axis=( -0.029258 0.906800 -0.420545)
H 1 sigma_33= 33.9002 axis=( 0.708097 0.315755 0.631583)
Atom 2 H pos: ( 0.951174 0.648257 0.851276) Total
sigma: 28.76
26.8411 -1.9826 0.3695
-0.9485 32.5335 -2.4861
-0.2162 -1.1068 26.9059
H 2 anisotropy: 6.92 eta: -0.1464
H 2 sigma_11= 26.7922 axis=( -0.761295 0.008534 0.648350)
H 2 sigma_22= 26.1171 axis=( -0.612014 -0.339731 -0.714158)
H 2 sigma_33= 33.3712 axis=( 0.214170 -0.940484 0.263858)
Atom 3 H pos: ( 1.080748 0.860252 0.626511) Total
sigma: 27.68
29.3701 1.3890 -3.8302
-1.4758 23.6530 -0.2736
-4.5261 -0.9285 30.0286
H 3 anisotropy: 9.33 eta: -0.3323
H 3 sigma_11= 25.6063 axis=( 0.724076 -0.217504 0.654527)
H 3 sigma_22= 23.5384 axis=( -0.133577 -0.975230 -0.176306)
H 3 sigma_33= 33.9071 axis=( -0.676662 -0.040230 0.735194)
Atom 4 H pos: ( 0.703023 1.007130 1.041222) Total
sigma: 25.75
30.2442 0.0354 -1.9862
1.5735 21.4289 1.7562
-0.4490 1.5663 25.5878
H 4 anisotropy: -7.58 eta: -0.9036
H 4 sigma_11= 25.9970 axis=( 0.191997 0.365094 0.910958)
H 4 sigma_22= 30.5608 axis=( 0.973701 0.045146 -0.223314)
H 4 sigma_33= 20.7031 axis=( 0.122657 -0.929875 0.346824)
Atom 5 H pos: ( 0.833779 1.215769 0.815795) Total
sigma: 26.69
26.3940 -2.8223 2.1746
-1.2684 26.9714 0.0325
3.0915 -1.9351 26.7169
H 5 anisotropy: 5.68 eta: -0.6120
H 5 sigma_11= 25.9592 axis=( 0.114791 0.793597 0.597517)
H 5 sigma_22= 23.6409 axis=( 0.767373 0.311133 -0.560656)
H 5 sigma_33= 30.4821 axis=( 0.630842 -0.522877 0.573270)
Atom 6 H pos: ( 1.117133 0.950964 1.179605) Total
sigma: 29.92
27.9296 -2.9849 5.2775
-2.2403 28.6256 -4.4965
5.3174 -4.2014 33.1964
H 6 anisotropy: 13.58 eta: -0.1652
H 6 sigma_11= 26.1398 axis=( -0.267495 -0.896968 -0.351988)
H 6 sigma_22= 24.6444 axis=( 0.840565 -0.038638 -0.540331)
H 6 sigma_33= 38.9673 axis=( 0.471059 -0.440405 0.764295)
Atom 7 C pos: ( 0.915939 0.822150 0.744767) Total
sigma: 199.76
217.4594 -37.3747 -8.6438
-8.5806 195.0127 32.2724
-4.8805 25.1962 186.8186
C 7 anisotropy: 62.04 eta: -0.9279
C 7 sigma_11= 198.2724 axis=( 0.692401 0.401818 0.599268)
C 7 sigma_22= 159.8972 axis=( -0.195965 -0.694619 0.692172)
C 7 sigma_33= 241.1212 axis=( -0.694391 0.596696 0.402213)
Atom 8 C pos: ( 0.869846 1.042890 0.922665) Total
sigma: 141.82
144.7764 14.2814 29.1172
24.4528 121.8462 10.7015
29.7639 10.6145 158.8435
C 8 anisotropy: 69.89 eta: -0.3743
C 8 sigma_11= 127.2460 axis=( 0.516158 0.541519 -0.663579)
C 8 sigma_22= 109.8058 axis=( 0.589762 -0.786541 -0.183123)
C 8 sigma_33= 188.4143 axis=( 0.621097 0.296833 0.725347)
Atom 9 O pos: ( 1.085885 1.098442 1.074706) Total
sigma: 324.49
347.4733 7.9280 52.0927
-30.0215 323.8325 -29.6819
20.1690 7.3387 302.1619
O 9 anisotropy: 71.54 eta: -0.7953
O 9 sigma_11= 319.6078 axis=( -0.315490 -0.947791 -0.046461)
O 9 sigma_22= 281.6751 axis=( -0.463904 0.111337 0.878861)
O 9 sigma_33= 372.1849 axis=( 0.827804 -0.298825 0.474810)
*** ATTENTION: system is metallic, Knight shift not included ***
Initialization:
gipaw_setup : 0.50s CPU 0.73s WALL ( 1 calls)
Linear response
greenf : 11.23s CPU 12.90s WALL ( 21 calls)
cgsolve : 11.15s CPU 12.82s WALL ( 21 calls)
ch_psi : 10.89s CPU 12.52s WALL ( 588 calls)
h_psiq : 10.04s CPU 11.44s WALL ( 588 calls)
Apply operators
h_psi : 12.95s CPU 14.71s WALL ( 897 calls)
apply_vel : 0.09s CPU 0.11s WALL ( 21 calls)
Induced current
j_para : 1.26s CPU 1.49s WALL ( 12 calls)
biot_savart : 0.03s CPU 0.03s WALL ( 1 calls)
Other routines
General routines
calbec : 0.37s CPU 0.38s WALL ( 2170 calls)
fft : 0.04s CPU 0.18s WALL ( 29 calls)
fftw : 12.62s CPU 14.41s WALL ( 16772 calls)
davcio : 0.00s CPU 0.00s WALL ( 15 calls)
Parallel routines
fft_scatter : 0.65s CPU 1.01s WALL ( 16801 calls)
Plugins
GIPAW : 18.54s CPU 23.44s WALL ( 1 calls)
-------------------------------------------------------------------------------------------------------
I found some helpful slides, but none of them explains how to plot the
spectrum peaks positions, width and intensity.
-
http://media.quantum-espresso.org/santa_barbara_2009_07/slides-exercices/Seitsonen-nmr_lecture.pdf
-
https://github.com/NNemec/quantum-espresso/tree/master/examples/GIPAW_example
Can someone help me with this last step?
Thanks you very much
Manuel Otero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/390c3de9/attachment-0001.html
------------------------------
Message: 16
Date: Thu, 12 May 2016 22:03:59 +0200
From: Paolo Giannozzi <p.giannozzi at gmail.com>
Subject: Re: [Pw_forum] Grimme C_ij for epitaxial graphene
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAPMgbCvAaUGjbpR5pw+eC2cC1zsouJ3ZubA92NEvqaBe+qHjsA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There is no way I think to do what you want other than modifying the code:
Modules/mm_dispersions.f90. It is clearly written and commented so it is
not difficult to locate the places to modify
Paolo
On Thu, May 12, 2016 at 8:22 PM, Matthieu Fortin-Desch?nes <
matthieu.fortin-deschenes at polymtl.ca> wrote:
> Hi all,
>
> I'm trying to calculate some basic properties of graphene on various
> substrates using Grimme correction for VdW interactions. The Grimme
> corrections seem to deteriorate the results (lattice parameter and
> binding energy) of the graphene as well of the substrate compared to
> experimental results.
>
> I was wondering if it's possible to set C_ij=0 for i=j (no correction
> for C-C interactions, as well as substrate-substrate interaction), but
> non-zero C_ij for graphene-substrate interactions. As far as i know,
> C_i are defined for each element and C_ij is calculated from
> sqrt(C_i*C_j). I would like to set all C_ij by myself.
>
> Thank you
>
> Matthieu Fortin-Desch?nes
> Polytechnique Montreal
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/096c5c65/attachment-0001.html
------------------------------
Message: 17
Date: Thu, 12 May 2016 23:15:07 +0200
From: Martin Andersson <ma at nano.ku.dk>
Subject: Re: [Pw_forum] Grimme C_ij for epitaxial graphene
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID: <5BC33C08-AA44-42DF-917E-13AD7DA145A1 at nano.ku.dk>
Content-Type: text/plain; charset="utf-8"
Hi Matthieu,
I was curious as to which substrates you are putting graphene on. Because if you are looking at either ionic solids or metals, the Grimme corrections are going to be a bit too strong, but it can be fixed. We have had success for calculating adsorption energies on minerals by reducing the C6 parameter for the cations in the substrate by about an order of magnitude (we decreased the parameter by 33 for Ca in calcite in (Okhrimenko et al Langmuir 29, 11062-11073,(2013)). The idea came from Ehrlich et al ChemPhysChem 12, 3414-3420,(2011). For cations in ionic solids (e.g. oxides, minerals), the polarisability is significantly smaller because of the smaller electron cloud of a cation compared to the corresponding neutral atom.
For metals, I had good success in Andersson MP Journal of Theoretical Chemistry 2013, Article ID 327839,(2013), where I modified Grimme corrections to make it work better for metals by using a shorter cutoff to simulate screening by the conduction electrons and switching the C6 parameters for the metal to the parameter of the noble gas in the row above.
In either of the two cases, you only need to modify the mm_dispersion.f90 file and recompile. I have a couple of different mm_dispersion.f90 files lying around if you need one...
Or you could of course also switch to a suitable vdw functional if you like instead.
Cheers and good luck,
????????????????????????
Martin P. Andersson
Associate Professor
Nano-Science Center, Department of Chemistry
University of Copenhagen, Denmark
Tel: +45 3532 0280
Mobile: +46 733 893091
E-mail: ma at nano.ku.dk
????????????????????????
> On 12 May 2016, at 20:22, Matthieu Fortin-Desch?nes <matthieu.fortin-deschenes at polymtl.ca> wrote:
>
> Hi all,
>
> I'm trying to calculate some basic properties of graphene on various
> substrates using Grimme correction for VdW interactions. The Grimme
> corrections seem to deteriorate the results (lattice parameter and
> binding energy) of the graphene as well of the substrate compared to
> experimental results.
>
> I was wondering if it's possible to set C_ij=0 for i=j (no correction
> for C-C interactions, as well as substrate-substrate interaction), but
> non-zero C_ij for graphene-substrate interactions. As far as i know,
> C_i are defined for each element and C_ij is calculated from
> sqrt(C_i*C_j). I would like to set all C_ij by myself.
>
> Thank you
>
> Matthieu Fortin-Desch?nes
> Polytechnique Montreal
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160512/4b95d0a5/attachment-0001.html
------------------------------
Message: 18
Date: Fri, 13 May 2016 07:36:45 +0200
From: Paolo Giannozzi <p.giannozzi at gmail.com>
Subject: Re: [Pw_forum] Fermi Surface Visualization
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAPMgbCvMGh-7M7tCSoQzd9BLSdGu=sRtnTZq4LrQx5ncq5CdPQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The code you mention was superseded since v.5.3 by code
PP/src/fermisurface.f90, executable fs.x
Paolo
On Wed, May 11, 2016 at 11:38 PM, Vijay Khanal <vj.khanal20 at gmail.com>
wrote:
> Dear Developers and users,
>
> As a first part of Fermi surface visualization task of Nickel, I have been
> trying to do Spin polarized and non polarized calculations. But for some
> reasons I don't know, the system throws me an error *"At line 77 of file
> bands_FS.f90 (unit = 12, file = 'input_FS') **Fortran runtime error: Bad
> integer for item 1 in list input" *
>
> Attached are the input files. I have seen the same error with both: Spin
> polarized and non polarized calculations.
>
>
> Thank you for your time..
>
>
> Best,
> Vijay Khanal.
> *Vijay Khanal*
> Department of Physics
> University of Nevada, Reno
> Phone:(1-*775-440-7036 <775-440-7036>)*
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160513/cf3beb59/attachment-0001.html
------------------------------
Message: 19
Date: Fri, 13 May 2016 10:08:39 +0200
From: Ryky Nelson <nelson.ryky at gmail.com>
Subject: Re: [Pw_forum] G vector used to represent wfcs
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAMmLhK5dG=ucuWsZonyY17SeVCrfWS9S2ji5EtZZtYrOQ-yLRg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dario,
thank you very much for your explanation, it's so helpful.
Best,
Ryky Nelson
Institut f?r Anorganische Chemie
RWTH Aachen University
On Thu, May 12, 2016 at 4:14 PM, dario rocca <roccad at gmail.com> wrote:
> Dear Ryky,
> For more details about the G vector generation you can take a look in the
> ggen subroutine in Modules/recvec_subs.f90. Take a look also in
> n_plane_waves.f90
> In gereral the G vectors are determined with the condition
> G^2 * hbar^2 / (2m_e) < E_cut(density)=4*E_cut(wfc) (without the k point;
> inside QE Rydberg atomic units are used)
> This is a sphere in reciprocal space centered in (0,0,0).
>
> Concerning each orbital corresponding to a specific k point you apply the
> condition
> (G+k)^2 * hbar^2 / (2m_e) < E_cut(wfc)
> In this case the G vectors are a subset of the vectors used for the
> density. In this case we have a sphere in reciprocal space shifted from the
> origin. Depending on k you can have a different set of G vectors included
> in the sphere and also their number could differ.
>
> In order to menage the g vectors for each k-point, you can use the arrays
> ngk (number of G vectors for each k-point) and igk (index of G
> corresponding to a given index of k+G; basically an index that allows you
> to identify the G vectors corresponding to a given k and order them).
>
> For example the kinetic energy corresponding to a given k-point ik is
> g2kin(1:ngk(ik)) = ( ( xk(1,ik) + g(1,igk(1:ngk(ik))) )**2 + &
> ( xk(2,ik) + g(2,igk(1:ngk(ik))) )**2 + &
> ( xk(3,ik) + g(3,igk(1:ngk(ik))) )**2 ) * tpiba2
> where tpiba2 = (2\pi/a)^2
>
> There is only one FFT for the wavefunctions so the grid does not depend on
> the k-points; however, for a given wavefunction, only the components
> corresponding to a G vector that satisfy (G+k)^2 * hbar^2 / (2m_e) <
> E_cut(wfc) are different from 0
>
> Best,
> Dario
>
>
>
>
>
>
> On Thu, May 12, 2016 at 1:38 PM, Ryky Nelson <nelson.ryky at gmail.com>
> wrote:
>
>> Hello QE users and developers,
>>
>> I'm trying to figure out how G vectors in PWscf are selected to represent
>> the corresponding wfcs. Could someone tell me if the following is the only
>> criterion used to determine G vectors?
>>
>> abs(G+k)^2 * hbar^2 / (2m_e) < E_cut
>>
>> and does the code basically start from the origin (0,0,0) and scan
>> through all grid coordinates (positive and negative) and check if the grid
>> agrees with the above criterion? Also, does the number of G vectors (for
>> each k) have relation to the FFT dimensions?
>>
>> Thank you!
>>
>> Ryky Nelson
>> Institut f?r Anorganische Chemie
>> RWTH Aachen University
>>
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://pwscf.org/mailman/listinfo/pw_forum
>>
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160513/b1dd4938/attachment-0001.html
------------------------------
Message: 20
Date: Fri, 13 May 2016 09:00:08 +0000
From: Roberto Gaspari <Roberto.Gaspari at iit.it>
Subject: [Pw_forum] epsilon.f90 skips transitions involving similarly
occupied states
To: "pw_forum at pwscf.org" <pw_forum at pwscf.org>
Message-ID:
<473C4B124E1103459046646F3CEF568E5E0890BB at IITMXWGE015.iit.local>
Content-Type: text/plain; charset="iso-8859-1"
Dear pwscf community,
I was reading through the epsilon.f90 code and I noticed that (5.2.1 version) at
line 420 we have the following condition
IF (abs(focc(iband2,ik)-focc(iband1,ik))< 1e-3) CYCLE
this basically means that the contribution to the dielectric function due to the transitions between
iband2 and iband1 is neglected if the two states have nearly the same occupation. I removed this
condition and noticed that, in some test case, states close to the Fermi level and closely spaced in energy would otherwise contribute a huge amount. This seems to be due to the fact that the denominator of eq. 10 ( epsilon.x manual ) becomes close to zero.
I would like to ask experts of pwscf and epsilon.x, in particular, if the CYCLE condition was introduced for any specific physical or numerical reason and why it is safe to proceed this way.
Thank you very much for your attention and have a nice day.
Roberto Gaspari
Ph.D.
Compunet-Istituto Italiano di Tecnologia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160513/1e34ab6e/attachment-0001.html
------------------------------
Message: 21
Date: Fri, 13 May 2016 11:37:49 +0200
From: Paolo Giannozzi <p.giannozzi at gmail.com>
Subject: Re: [Pw_forum] epsilon.f90 skips transitions involving
similarly occupied states
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID:
<CAPMgbCt2SmC=YzPv2JsuYhWbwMHRhV193OQ02NXo4+bRfPiNwA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, May 13, 2016 at 11:00 AM, Roberto Gaspari <Roberto.Gaspari at iit.it>
wrote:
>
> I would like to ask experts of pwscf and epsilon.x, in particular, if the
> CYCLE condition was introduced for any specific physical [...] reason
>
the difference between occupation numbers appears in the definition of the
dielectric function, for rather obvious reasons (prevents transitions from
a filled state to another filled state, or from an empty state to another
empty state).
Paolo
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20160513/e02cee46/attachment-0001.html
------------------------------
Message: 22
Date: Fri, 13 May 2016 11:48:45 +0200 (CEST)
From: Andrea Ferretti <andrea.ferretti at unimore.it>
Subject: Re: [Pw_forum] epsilon.f90 skips transitions involving
similarly occupied states
To: PWSCF Forum <pw_forum at pwscf.org>
Message-ID: <alpine.DEB.2.10.1605131145330.31217 at potzie>
Content-Type: text/plain; charset="iso-8859-1"
Dear Roberto,
please note that some bug fixes and other minor changes have been
recently (past few months) included in espilon. I would then
recommend to refer to espresso-5.4.0 for both discussions and actual runs
take care
Andrea
> I was reading through the epsilon.f90 code and I noticed that (5.2.1 version) at
> line 420 we have the following condition
>
> IF (abs(focc(iband2,ik)-focc(iband1,ik))< 1e-3) CYCLE
>
> this basically means that the contribution? to the dielectric function due to the transitions between
> iband2 and iband1 is neglected if the two states have nearly the same occupation. I removed this
> condition and noticed that, in some test case, states close to the Fermi level and closely spaced in energy would otherwise
> contribute a huge amount. This seems to be due to the fact that the denominator of eq. 10 ( epsilon.x manual ) becomes close
> to zero.
>
> I would like to ask experts of pwscf and epsilon.x, in particular, if the CYCLE condition was introduced for any specific
> physical or numerical reason and why it is safe to proceed this way.
>
> Thank you very much for your attention and have a nice day.
>
> Roberto Gaspari
> Ph.D.
> Compunet-Istituto Italiano di Tecnologia
>
>
>
>
--
Andrea Ferretti, PhD
S3 Center, Istituto Nanoscienze, CNR
via Campi 213/A, 41125, Modena, Italy
Tel: +39 059 2055322; Skype: andrea_ferretti
URL: http://www.nano.cnr.it
------------------------------
_______________________________________________
Pw_forum mailing list
Pw_forum at pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum
End of Pw_forum Digest, Vol 106, Issue 13
*****************************************
More information about the users
mailing list