Re: [QE-users] Calculations with van der Waals correction stopped with an error
Hi Jibiao, You can also add DFT-D3 or DFT-D4 corrections using ASE, see https://wiki.fysik.dtu.dk/ase/ase/calculators/dftd3.html and https://github.com/dftd4/dftd4/tree/main/python Thus you won't be limited by the parameters from QE but can use any functional parametrized in the official DFTD3 and DFTD4 codes. Best regards, Michal Krompiec, Merck Electronics On Thu, 8 Apr 2021 at 09:37, Jibiao Li wrote: > Hi, All > > My NEB calculations with the the parameters below go smoothly > vdw_corr = 'grimme-d2' , > but when I tried to perform NEB calculations with the following parameters > vdw_corr = 'grimme-d3' , > but the program stopped and gave the error below. The input file is > listed. How should I resolve this problem? > > > Program NEB v.6.7MaX starts on 8Apr2021 at 16:15:41 > > This program is part of the open-source Quantum ESPRESSO suite > for quantum simulation of materials; please cite > "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009); > "P. Giannozzi et al., J. Phys.:Condens. Matter 29 465901 (2017); > URL http://www.quantum-espresso.org;, > in publications or presentations arising from this work. More details > at > http://www.quantum-espresso.org/quote > > Parallel version (MPI), running on24 processors > > MPI processes distributed on 1 nodes > R & G space division: proc/nbgrp/npool/nimage = 24 > > parsing_file_name: hdw.neb.inp > Reading input from pw_1.in > file O.pbe-n-kjpaw_psl.0.1.UPF: wavefunction(s) 2P renormalized > file H.pbe-kjpaw_psl.0.1.UPF: wavefunction(s) 1S renormalized > file Pd.pbe-n-kjpaw_psl.1.0.0.UPF: wavefunction(s) 5S 4D renormalized > > IMPORTANT: XC functional enforced from input : > Exchange-correlation= SLA+PW+OBK8+P86 >( 1 4 23 1 0 0 0) > Any further DFT definition will be discarded > Please, verify this is what you really want > > > > Parameters for DFT-D3 Dispersion Correction: > >Reference C6 values for interpolation: > > atom Coordination number C6 > H 0.912 6.05 > H 0.00015.18 > O 0.00031.01 > O 0.99325.63 > O 1.98920.74 > Pd 0.000 1217.01 > Pd 1.863 573.90 > Pd 5.710 531.75 > >Values used: > > atom Coordination number R0_AB[au] C6 C8 > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > program stopped due to: functional name unknown > > > BEGIN > BEGIN_PATH_INPUT > > restart_mode = 'from_scratch', > string_method = 'neb', > nstep_path= 198, > ds= 1.D0, > opt_scheme= 'broyden', > first_last_opt= .TRUE., > num_of_images = 11, > k_max = 0.6D0, > k_min = 0.6D0, > CI_scheme = 'auto', > / > END_PATH_INPUT > BEGIN_ENGINE_INPUT > > prefix = 'hdw', > outdir = './', > pseudo_dir = '/GFPS8p/shn003/pseudo' , > / > >ibrav = 4, >celldm(1) = 15.929830662, >celldm(3) = 3.30768592, > nat = 39, > ntyp = 3, > ecutwfc = 49 , > ecutrho = 411 , > occupations = 'smearing' , > degauss = 0.05D0 , > smearing = 'methfessel-paxton' , >
Re: [QE-users] Discrepancy between QE and VASP when including Efield in slab system
Dear Carlos,
First of all, version 5.4 is ancient. Have you tried with the latest QE?
Assuming both calculations are performed correctly, the difference may stem
from different pseudopotentials. Are you using some old norm-conserving
pseudos? Are you sure your cutoff is large enough? Have you tried SSSP
pseudos?
Anyway, are you expecting reasonable results for this system from PBE?
Best regards,
Michal Krompiec, Merck Electronics
On Mon, Mar 8, 2021 at 6:40 PM Carlos Polanco Garcia
wrote:
> Dear all
>
>
>
> *Problem in brief:* My calculations of the change in the bandgap with
> electric filed in bilayer MoS2 using Quantum Espresso (QE) version 5.4.0 do
> not agree with similar calculations in the literature that used VASP.
>
>
>
> *Questions:*
>
>1. Have anyone found discrepancies of the change of dispersion with
>electric filed from QE and VASP in slab systems including Electric fields
>with the sawtooth potential?
>2. Is there any problem with my input?
>
>
>
> *Details of the simulation:* An input for bilayer MoS2 with an Electric
> field of 2V/nm is below. I set the discontinuity of the sawtooth potential
> to be in vacuum and I set the magnitude of the electric filed using the
> conversion factor 1 a.u. = 51.4220632*10^10 V/m.
>
>
>
>
>
> calculation='scf',
>
> outdir = '/home/tmp/MoS2.2L.E2.01/'
>
> prefix='MoS2.2L',
>
> pseudo_dir = '/home/pseudo/',
>
> restart_mode='from_scratch',
>
> tprnfor=.true.
>
> tefield=.true.
>
> /
>
>
>
> ibrav=4,
>
> celldm(1)=6.02820958
>
> celldm(3)= 6.629172038
>
> nat=6,
>
> ntyp= 2,
>
> ecutwfc= 80.0,
>
> nbnd=24
>
> vdw_corr='DFT-D'
>
> edir=3
>
> eamp = 0.00388938
>
> emaxpos=0.60
>
> eopreg=0.10
>
> /
>
>
>
> conv_thr= 1.0d-9,
>
> mixing_beta= 0.6,
>
> /
>
>
>
> ATOMIC_SPECIES
>
> Mo 95.94Mo.pbe-mt_fhi.UPF
>
> S 32.065 S.pbe-mt_fhi.UPF
>
>
>
> ATOMIC_POSITIONS {alat}
>
> Mo 0.0 0.0 0.0
>
> S0.5 0.288675135 -0.492491069
>
> S0.5 0.288675135 0.492515463
>
> Mo 0.5 0.288675135 1.969804069
>
> S -0.0 -0.0 1.477442788
>
> S -0.0 -0.0 2.462449934
>
>
>
> K_POINTS {automatic}
>
> 13 13 1 0 0 0
>
>
>
> *Details of the problem:* Overall the dispersion for Efield=0 agrees
> decently with other calculations in the literature including those using
> VASP. However when I increase the electric field, my calculations predict a
> change in the Bandgap with electric field about four times weaker than that
> predicted from VASP calculations. For instance, from E0=0V/nm to E2=2V/nm,
> my bandgap (Gamma to K) decreases by 0.19 eV. On the other hand, similar
> VASP calculations predict that the bandgap decreases by 0.89 eV (Figure 2,
> red dispersions from [1]), and by 0.73 eV (Figure 5a from [2]). My
> calculations agree better with calculations that do not relay on VASP. An
> independent calculation with QE predicts a similar slope in the change of
> Bandgap with Efield for Efileds larger than 1V/nm (red dots Fig 3a [3]). A
> calculation with Siesta predicts a decrease in bandgap of 1.04 eV when
> increasing Efiled from 0V/nm to 5V/nm (Fig 4 b,d orange lines [4]), while
> my calculations predict a change in bandgap of 0.78 eV (20% difference).
> The agreement of the dispersions at Efield=0V/nm points that the problem is
> in how the Efiled is being included. My input for QE may be missing
> something, or there may be a factor difference in how Efield is included
> between VASP and QE.
>
>
>
> *References:*
>
> [1] Ramasubramaniam A. et al, “Tunable band gaps in bilayer
> transition-metal dichalcogenides”, PHYSICAL REVIEW B 84, 205325 (2011)
>
> [2] Chu T. et al, “Electrically Tunable Bandgaps in Bilayer MoS2”, Nano
> Lett. 2015, 15, 8000−8007
>
> [3] Nguyen C. et al, “Band Gap Modulation of Bilayer MoS2 Under Strain
> Engineering and Electric Field: A Density Functional Theory”, Journal of
> ELECTRONIC MATERIALS, Vol. 45, No. 8, 2016
>
> [4] Santos E., et al, “Electrically Driven Tuning of the Dielectric
> Constant in MoS2 Layers”, ACS NANO, VOL. 7, NO. 12, 10741–10746 ’ 2013
>
>
>
> Carlos Polanco
>
> Scientist at Sivananthan Laboratories
>
>
>
> --
> Carlos Andrés Polanco García
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] [De/hydrogenation] How can I get thermodynamic and activation parameters at some particular T and P using QE or other QE based codes
Dear K C Bhamu,
To get the enthalpy and entropy at T>0 (and the zero-point energy which you
haven't included yet) you need to perform a phonon calculation.
Best regards,
Michal Krompiec
On Mon, 18 Jan 2021 at 10:16, Dr. K. C. Bhamu wrote:
> Dear QE Users,
> [I am using QE_6.4 and 6.6!!]
> I am looking for a QE based good reference and some advice for my work:
> dehydrogenation of a molecule (let's say it is C6H12).
>
> I am trying to calculate dehydrogenation enthalpy of this molecule.
>
> I have obtained my dehydrogenation reaction energy diagram for each step
> but that is at 0K and 0P.
> ΔG = ΔH - T* ΔS
> In QE we have T=0, so ΔG = ΔH.
>
> Now I want to calculate the thermodynamic and activation parameters at
> standard (~25 °C, and 0.1MPa) and experimental conditions (~150 °C, and
> 7MPa) {Please seeTable 1,2 of [1] what I mean for it} with and without the
> solvent.
>
> How can I get these thermodynamic and activation parameters at some
> particular temperature and pressure?
>
> If I am wrong, then I need to use environ code [2] to include the solvent
> effect in my study. Right?
> [1].
> https://www.sciencedirect.com/science/article/pii/S0360319915005753#appsec1
> [2]. https://github.com/environ-developers/Environ/releases
>
> If I missed something to explain my problem, I am sorry and I will share
> it if you suggest the missing information.
>
> Any help will be appreciated.
>
> Thank you very much
>
> Regards
> K C Bhamu
> University of Ulsan
> ROK
>
>
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] reflection-absorption IR spectra
Dear Paolo, Thank you, this is what Lorenzo Paulatto suggested, too: the dynmat.x (not matdyn.x) code computes the IR cross section, if you give it in input the dynamical matrix at Gamma with effective charges. In recent versions of the code, the calculation is done in LR_Modules/dynmat_sub.f90, subroutine RamanIR, and it is quite straightforward. At a certain point the IR cross section is computed as infrared(nu) = 2.d0*(polar(1)**2+polar(2)**2+polar(3)**2)*irfac So, replacing this by: infrared(nu) = 2.d0*(polar(3)**2)*irfac should do what I want (only the Z component of induced dipole is IR active). I'll do some tests soon... Best regards, Michal On Fri, 8 Jan 2021 at 11:43, Paolo Giannozzi wrote: > The dipole induced by a phonon can be computed from phonon displacements > and effective charges: see variable "polar", computed in routine RamanIR, > file LR_Modules/dynmat_sub.f90, called by PHonon/PH/dynmat.f90 > > Paolo > > On Thu, Jan 7, 2021 at 10:58 PM Michal Krompiec > wrote: > >> Hello, >> >> In Reflection-Absorption IR (IR at grazing incidence), only modes that >> induce a nonzero dipole in the direction normal to the surface contribute >> to the spectrum. Is it possible to simulate this in QE? >> In other words: how do I calculate the IR spectrum of flexural phonons of >> a 2D system? >> >> Best regards, >> >> Michal Krompiec, Merck KGaA >> ___ >> 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 > > > > -- > 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) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] reflection-absorption IR spectra
Hello, In Reflection-Absorption IR (IR at grazing incidence), only modes that induce a nonzero dipole in the direction normal to the surface contribute to the spectrum. Is it possible to simulate this in QE? In other words: how do I calculate the IR spectrum of flexural phonons of a 2D system? Best regards, Michal Krompiec, Merck KGaA ___ 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] GHz calculation with QE
Hi Mahdi, Not really. You can get the dielectric function in MHz-THz range from the (temporal) autocorrelation of dipole moment from an MD simulation, but the timescale is way beyond the reach of DFT, by several orders of magnitude. Best regards, Michal Krompiec, Merck KGaA On Fri, Dec 18, 2020 at 9:47 PM Mahdi Faghihnasiri < mahdi.faghihnas...@gmail.com> wrote: > Dear all, > > Is it possible to calculate the real and imaginary part of the dielectric > function in the GHz region with DFT? > Can these calculations be done with QE code? Or does it require a special > or complimentary approximation and method? > > Best regards, > Mahdi > > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] time consuming band structure calculation for a supercell
Dear Lorenzo, Speaking of ppcg, is there any published (or otherwise public) benchmark of ppcg vs Davidson and/or cg? For which cases can ppcg be expected to be faster? Best regards, Michal Krompiec, Merck KGaA On Mon, Dec 14, 2020 at 2:12 PM Lorenzo Paulatto wrote: > p.p.s I mean diagonalization='ppcg' > > On 2020-12-14 15:10, Lorenzo Paulatto wrote: > > p.s. If you can use a newer version of QE that does calculation="ppcg" > > I found it to be much (i.e. 6x) faster in this case > > > > cheers > > > > On 2020-12-14 14:50, Lorenzo Paulatto wrote: > >> Hello, > >> > >> I've had a look at the output, and a part for the cutoff which > >> appears a bit too high (you are probably safe with 50/400Ry of > >> ecutwfc/ecutrho) I only see to small problems: > >> > >> 1. the scf calculation is using 6 pools with 10 k-points, which means > >> that 4 pools have twice as much work to do as the others. In the > >> ideal case, the number of pools should be a divisor of the number of > >> k-points (i.e. 2, 5 or 10 in your case). Also, it is recommended that > >> the number of CPUs in a pool are a divisor of the number of CPUs on > >> each computing node, to avoid too much inter-node communication. In > >> your case, the best choice with 72 CPUs (on two nodes?) could be 2 > >> pools. You may gain a bit of time, but this is not going to change a > >> lot. You should consider using more CPUs if you have the budget. For > >> example, 10 pools of 12 or 18 CPUs each. > >> > >> 2. The bands calculation runs on 12 CPUs and has a single k-point, > >> while each pool of the SCF one has up to 2 k-points. We would expect > >> that the bands calculation take about half as an scf step, i.e. about > >> 50 seconds. However, the bands calculation has some trouble > >> diagonalizing the Hamiltonian, you see it writes: > >> > >> ethr = 2.76E-12, avg # of iterations =120.0 > >> > >> while typically the very last scf diagonalization is > >> > >> ethr = 2.98E-12, avg # of iterations = 3.3 > >> > >> This is because, the scf calculation can start with a very good guess > >> good the wavefunction, while the bands calculation does not. It is > >> still faster than doing the entire scf procedure, but just by a > >> factor ~2.3 > >> > >> Fortunately, you do not usually need the eigenvalues to a precision > >> of 10e-12. You can set the threshold by hand using the keyword > >> diago_thr_init, I guess 1.d-6 should be tight enough. However, double > >> check what you get in output, because I am half-suspecting that it > >> may be over-written by the value in the restart file > >> > >> cheers > >> > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] PBEh-3c, HSE-3c, sHF-3c functional equivalent in Quantum Espresso
Hi Michal, No, -3c functionals aren’t available because they contain additional non-standard correction terms and are designed to work with a specific GTO basis set. You can control the fraction of exact exchange with exx_fraction in the section. Best regards, Michal Krompiec On Fri, 20 Nov 2020 at 20:28, Husak Michal wrote: > Hi > > > I work on a specific problem - study of H proton transfer in molecular > cocrystals. > > Standard functionals (PBE, PBE0, B3LYP) produce incorrect results. > > Details: > > https://onlinelibrary.wiley.com/doi/abs/10.1002/anie.201809381 > > > I would like to test in Qunatum Espresso the suggested functionals with > > higher % of exact exchange ... > > > Namely: > > PBEh-3c, HSE-3c, sHF-3c (implemented in CRYSTAL17 code) > > > I see only "hse" in funct.f90 as supported ... > > Maybe there is some way how to replicate the mentioned functionals > > results in Quantum Espresso ? > > > Michal Husak > > UCT Prague > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users > ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] BLYP hybrid functional
Dear Mohamed, No it isn’t, BLYP is a GGA. TD-DFT with hybrids is implemented only for molecules (0D, gamma only). Best, Michal Krompiec, Merck KGaA On Sat, Nov 14, 2020 at 12:51 PM Mohamed Ahmed Abd-Elati wrote: > Dear all > I want to calculate the absorption coefficient for graphene flake using > TD-B3LYP. Is B3LYP equivalent to BLYP in quantum esspresso?, and where can > finding pseudopotentials related to BLYP hybrid functional? > Thanks in advanced > *Mohammed A. Abdelati* > *Assistant Lecturer* > Laser Applications in Metrology Photochemistry and Agriculture (LAMPA) > Department, National Institute of Laser Enhanced Sciences (NILES), Cairo > University, Giza, Egypt. > Mobile +20 1009752922 > Home+201152605076 > E-mailma198...@yahoo.com > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Running efficiently on multiple nodes
Dear Brad, Fast communications means here Infiniband or other RDMA. Make sure your MPI uses RDMA, I’ve seen systems where it isn’t enabled by default. That said, if you use k-point parallelization you can get away with gigabit ethernet as Paolo mentioned. Best wishes, Michal Krompiec Merck KGaA On Thu, Nov 5, 2020 at 11:40 PM Baer, Bradly via users < users@lists.quantum-espresso.org> wrote: > Paolo, > > I believe the nodes I am using have gigabit connections. There are > additional nodes that have 10 or 25 gigabit connections but I don't think I > would land on one of them without specifically requesting them. What > communication speed would be appropriate for QE's needs? > > I also did consider trying to manually set the parallelization but I don't > currently know enough about SLURM to identify each node and ensure that all > 16 cores assigned from a pool are on the same node. I will keep it in mind > though as a possible future solution. > > Thanks, > Brad > > > Bradly Baer > Graduate Research Assistant, Walker Lab > Interdisciplinary Materials Science > Vanderbilt University > > > -- > *From:* Paolo Giannozzi > *Sent:* Thursday, November 5, 2020 3:54 PM > *To:* Baer, Bradly ; Quantum ESPRESSO users > Forum > > *Subject:* Re: [QE-users] Running efficiently on multiple nodes > > Are there fast communications between the two nodes? if not, the parallel > distributed 3D FFT will be very slow (note the time taken by fft_scatt_yz). > You might find convenient to exploit k-point parallelization, that requires > much less communication: for instance, "mpirun -n 32 pw.x -nk 2" (2 pools > of 16 processors, each pool performing parallel FFT), but you have to > figure out a way to convince the first pool of 16 processors on node 1, the > second on node 2 (or vice versa, as long as FFT parallelization happens > inside a node, k-point parallelization across nodes ) > > Paolo > > On Thu, Nov 5, 2020 at 7:29 PM Baer, Bradly via users < > users@lists.quantum-espresso.org> wrote: > > Paolo, > > Thank you for your suggestion. I will add recompiling to move to 6.6 to > my to do list. For now, I corrected the pseudopotential files as you > indicated and the calculation ran successfully. It has become slightly > faster, but still much slower than running on a single node (3:30s vs > 0:30s). Is there more that I should be doing to improve performance or is > my test problem too small to see the benefits of parallelization? > > Thanks, > Brad > > > Bradly Baer > Graduate Research Assistant, Walker Lab > Interdisciplinary Materials Science > Vanderbilt University > > > -- > *From:* users on behalf of > Paolo Giannozzi > *Sent:* Thursday, November 5, 2020 10:01 AM > *To:* Quantum ESPRESSO users Forum > *Subject:* Re: [QE-users] Running efficiently on multiple nodes > > On Thu, Nov 5, 2020 at 3:05 PM Baer, Bradly > wrote: > > > *Pseudo file Ga.pbe-dn-kjpaw_psl.1.0.0.UPF has been fixed on the fly.* > *To avoid this message in the future, permanently fix * > * your pseudo files following these instructions: * > *https://gitlab.com/QEF/q-e/blob/master/upftools/how_to_fix_upf.md > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2FQEF%2Fq-e%2Fblob%2Fmaster%2Fupftools%2Fhow_to_fix_upf.md=04%7C01%7Cbradly.b.baer%40vanderbilt.edu%7Ca843f95dcbc04eb71ed508d881d5735b%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C637402101063299076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=e33bhAwBlBmEyzlOywulA5VrN6JkxWmXUv6JhSuKtNY%3D=0>* > > > This is a possible source of trouble if the output directory is not > visible to all processors. Please try one of the following: > - do what it is suggested (or simply: edit Ga.pbe-dn-kjpaw_psl.1.0.0.UPF, > replace all occurrences of "&" with "") > - get version 6.6, that reads the pseudopotential file on one processor > and broadcast its contents to all other processes > - get the development version, that in addition is not sensitive to the > presence of nonstandard "&" in the files, > > Paolo > > > > -Brad > > > Bradly Baer > Graduate Research Assistant, Walker Lab > Interdisciplinary Materials Science > Vanderbilt University > > > -- > *From:* users on behalf of > Paolo Giannozzi > *Sent:* Thursday, November 5, 2020 2:33 AM > *To:* Quantum ESPRESSO users Forum > *Su
Re: [QE-users] NEB : path length is increasing
Dear Omar, This: imageenergy (eV)error (eV/A)frozen 1 -92402.49729070.036606T 2 -92402.80086460.020347F 3 -92402.67892020.048720F 4 -92403.27269900.102631F 5 -92403.06428880.050277F 6 -92403.23775990.067121F 7 -92402.80580320.029355T is a proof that you have not relaxed the initial and final structures before NEB (or done so with very lax convergence criteria). If you did, the error would have been close to zero for image 1 and 7. AFAIK the error is the component of the gradient normal to the NEB path, so for your start and end points it should be of similar magnitude as your final gradient during structure optimization. Try minimizing the initial and final structures with, say, forc_conv_thr = 1e-05. Best, Michal Krompiec Merck KGaA, Darmstadt, Germany On Mon, 26 Oct 2020 at 12:40, Antoine Jay wrote: > There is an energy barrier: > the one between your intermediate minima and your final state. > There is no barrier between initial and intermediate minima. > You should wonder why you have an intermediate minima that is lower in > energy (<0.4eV) than the final inserted molecule, this is why I was asking > if it was enough relaxed. > Maybe the first exothermic reaction gives enough energy for the second... > But for sure, when you have such a multi-barriers reaction, a 7 images neb > is not enough. > If you need accurate results, it is better to have 1 neb per barrier, as > you have 1 CI per path. > > Regards, > > Antoine Jay > LAAS-CNRS > Toulouse, France > > Le Lundi, Octobre 26, 2020 09:10 CET, Omer Mutasim > a écrit: > > > > > > Dear Dr. Jay > I have relaxed the initial and final structures before neb. > Regarding simulation box, i'm using sqrt(3)*sqrt(3) supercell, the other > five reaction steps converged well. > However, i have seen in the literature that similar catalyst resulted in > such barrier-less dissociation. > So my question goes like : with this oscillated MEP , can i conclude it is > barrier-less reaction ? or it is even necessary for barrier-less step to > have no oscillation ? > does changing the adsorption site of the reactant (SO2) to less stable > site might solve the issue ? > > Regards > On Monday, October 26, 2020, 11:25:36 AM GMT+4, Antoine Jay > wrote: > > > Dear Omer, > I think your initial and final minima have not been well relaxed. > When you fix the initial and final structures in a neb you must have > relaxed them before, otherwise, you will have negative energy barriers. > Moreover, you may have rotation of molecules that return local minima if > your simulation box is too small. > > Regards, > > Antoine Jay > LAAS-CNRS > Toulouse, France > > > Le Lundi, Octobre 26, 2020 06:39 CET, Omer Mutasim > a écrit: > > > > > > > Thanks a lot Dr. Tamas & Dr. Jay. , it is very efficient procedure, it > worked for me now for all reaction steps. cheers > > However for one elementary step , particularly SO2 dissociation ( SO2 = > SO+O ) i got the following activation barrier, (it hasn't finished yet, but > expected to remain around these values since it doesn't change much): > > -- iteration 297 > -- > > activation energy (->) = 0.00 eV > activation energy (<-) = 0.308512 eV > > imageenergy (eV)error (eV/A)frozen > > 1 -92402.49729070.036606T > 2 -92402.80086460.020347F > 3 -92402.67892020.048720F > 4 -92403.27269900.102631F > 5 -92403.06428880.050277F > 6 -92403.23775990.067121F > 7 -92402.80580320.029355T > activation energy (->) = 0.00 eV > activation energy (<-) = 0.308512 eV > > > Attached is the MEP curve. As you see in MEP graph , there is oscillation > in energies. > is it normal to get this oscillated MEP curve for such barrier-less > reaction step ? if not, how to get rid of this oscillations ? > does using "CI" can increase this barrier a bit ? > > Thanks in advance > > Regards > On Wednesday, October 21, 2020, 11:04:14 PM GMT+4, Omer Mutasim < > omermuta...@ymail.com> wrote: > > > Very helpful ideas. > But after pre-converging with inexpensive parameters, i will get
[QE-users] viewing trajectories in VMD, axsf conversion
Hello, in case someone else struggles with generation of axsf and xsf files from QE outputs, I'd like to share a tip. The pwo2xsf script from XCRYSDEN is much more reliable than the one in PW/tools (in my hands, the latter just dumps the first frame and then complains about not being able to read ATOMIC_POSITIONS records). It is used internally by XCRYSDEN but can also be utilized to save an axsf file. For example, to create an axsf file from a QE trajectory (relaxation or md) of a 2D slab: (-r 2 is the "reduce periodic dimension to 2" functionality familiar to XCRYSDEN users) path-to-xcrysden/bin/pwo2xsf -r 2 -a pw_output.out > movie.axsf Such axsf can then be opened in VMD etc. Best regards, Michal Krompiec Merck KGaA ___ 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] Huge difference between Wall time and CPU time in electron-phonon calculation
Dear Rafaello, Are you using a local (preferably SSD-based) scratch drive, or a very fast parallel file system? Best wishes, Michal Krompiec Merck KGaA On Wed, 30 Sep 2020 at 15:05, Raffaello Bianco < raffaello.bianco...@gmail.com> wrote: > Dear QE users and developers, > > I am doing an electron-phonon coupling calculation in this way (I am > using QE v 6.6). > First, I have done an scf calculation. Then, I have done a phonon > calculation where I have printed the dvscf files, with > >fildvscf = 'dvscf' > > Subsequently, I have done the electron-phonon calculation changing the > k-mesh grid, with > > trans= .false. > electron_phonon = 'simple' > > The calculation ends correctly, but for some q points I have noticed a > huge difference between > CPU and Wall time, like > > PHONON : 15h55m CPU 3d18h56m WALL > > From the report at the end of the output, the I/O davcio routine seems to > be the > "guilty": > > > General routines > davcio :107.89s CPU 263856.08s WALL ( 520331 calls) > > Parallel routines > > Electron-phonon coupling > elphon : 41730.55s CPU 309708.87s WALL ( 1 calls) > elphel : 41671.20s CPU 309625.04s WALL ( 60 calls) > > General routines > davcio :107.89s CPU 263856.08s WALL ( 520331 calls) > > This calculation was done with 10 processors and npool = 10, if I use 40 > processors and npool = 10 it is worse (as can probably be expected due to > the higher number of I / O operations). I have looked at the documentation > but I am not very familiar with these things, thus I still have several > doubts. Any suggestions on tests to do or how to improve performance, or at > least comments to clarify the problem, would be greatly appreciated. > > Thank you for your time, > > Best, > Raffaello Bianco > > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Is there "recommended" values of cutoffs for ONCV pseudopotentials?
See http://www.pseudo-dojo.org/ Best, Michal Krompiec Merck KGaA On Thu, 24 Sep 2020 at 11:53, mkondrin wrote: > Dear QE developers and users, > > I wonder is there recommended values of energy and charge density > cutoffs for norm-conserving pseudopotentials like ONCV ones? For PAW > pseudopotentials which are available at the official QE site these > values are written in the corresponding files but for ONCV > pseudopotentials this information is absent. Or should it be found > experimentally by try and error starting from the rule of thumb value > (70 Ry) ? > > Thanks in advance. > > Sincerely yours, > M. V. Kondrin > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users > ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Which pressure should I report on my work???
ad 1) If I understand correctly, it is because the basis set would change in every step, so the wavefunction from the preceding step couldn’t be used as a starting point for the scf, unless the bands were projected onto the new PW basis. Best, Michal Krompiec Merck KGaA On Sun, 20 Sep 2020 at 17:25, Robert Molt wrote: > If I may ask a question to clarify a point within this thread…I have > always had some confusion on exactly why the the # of basis vectors is not > conserved step-to-step. This is an implicit aspect to the question being > asked, if I understand properly. > > 1.) Why is the *number* of plane waves during vc-relax steps constant? > Why is not held to a constant energy cutoff, like in an energy calculation? > > My understanding is that ecutrho and ecutwfc “constrain” the number of > plane waves during a vc-relax calculation; these two variables completely > specify the number of allowed plane waves consistent with the initial unit > cell volume. Is this correct? > > My understanding is that if you wanted a constant energy cutoff, you have > to vary the number of plane waves, since the volume is changing. Why is > this undesirable to do? Is it because comparing different numbers of plane > waves results in different energies, such that no fair comparison can be > made between calculations with different numbers of basis vectors? > > 2.) On this specific question asked by Mohad, I am slightly confused. Is > the essence of the problem that the pressure calculation threshold is too > low OR is it that you should never use the “properties” other than lattice > constants from a vc-relax for the aforementioned reason? In my head, these > are seemingly independent issues in how the calculations are working? > > Dr. Robert Molt Jr. > Indiana University Purdue University > > > On Sep 20, 2020, at 6:03 AM, Lorenzo Monacelli < > lorenzo.monace...@roma1.infn.it> wrote: > > > > > > > > > > If I interpret correctly the question, you are seeing a P = 6.57 > > kbar and not 7 as in the pw.x input press keyword because, when qe > > relax the unit cell, it constrains the basis defined with ecutwfc > > and ecutrho. This basis, as it is formed by plane waves with > > periodic boundaries, depends on the cell size. So the code will > > relax reaching 7 kbar (within the accuracy you chose in the input, > > usually 0.1 kbar), then it will run a new calculation in the final > > cell recomputing the basis with the new cell. So the value of the > > pressure will be slightly different. > > To be consistent, you should use 6.57 kbar in your plots, as it > > is the final pressure with the cutoffs you used for your > > calculation, and does not depend on the starting cell. If you want > > exactly 7 kbar, you can start a new vc-relax using the final > > structure you have at 6.57 kbar as starting point, and it will get > > to a much closer value. > > Bests, > > Lorenzo > > > > > Il 20/09/20 10:54, Stefano Baroni ha > > scritto: > > > > > > > > > What is difference between the frequencies computed at: i) P=0; > > ii) P=6.57 kbar; iii) 7 kbar? The answer to my question will > > imply that to yours. SB > > > > > > > > > — > > > Stefano Baroni - SISSA, Trieste - http://stefano.baroni.me > , stefanobaroni (Skype) > > > > > > If the prediction that an airplane can stay up depends > > on the difference between Riemann and Lebesgue > > integration, I don’t want to fly in it [Richard W. > > Hammings] > > > > > > > > > > > > > > > > > > > > On 20 Sep 2020, at 10:42, Mohad Abbasnejad > > > > wrote: > > > > > > > > > > > > Hello Dear QE users > > > > > I am studying the effect of pressure on > > the frequencies. > > > In the experimental article, the > > pressure on the solid has been reported to be 7 > > kbar. > > > > > > > > When I put this pressure (7 kbar) on my > > structure and let it relax, the final pressure is > > calculated to be 6.57 kbar as the following. > > Therefore it is not exactly 7 kbar. > > > > > > > > > > Computing stress (Cartesian axis) and > > pressure > > > > > > total stress (Ry/bohr**3) > > (kbar) P=6.57 > > >0.4467 0. -0. > > 6.57 0.00 -0.00 > > >0. 0.4467 -0. > > 0.00 6.57 -0.00 > > > -0. -0. 0.4467 > > -0.00
Re: [QE-users] MPI error using using simple.x
Dear Anibal, It is very likely that you are running out of memory. Best, Michal Krompiec Merck KGaA On Tue, 15 Sep 2020 at 13:42, Anibal Thiago Bezerra < anibal.beze...@unifal-mg.edu.br> wrote: > Dear Quantum Espresso Users and Developers, > > I'm using simple.x to get the dielectric function for a gold-Aluminium > alloy. With pure systems (Au and Al), I had no problems at all. For the > alloy, the supercell has 12 atoms and the calculation ran with the > parameters similar to the ones in the example. However, I got an > anisotropic response. I already evaluate such a structure using epsilon, > and it returned isotropic dielectric function as expected for a cubic > lattice (I had to use as many k-point as I could do the calculation - for a > coarse grid, epsilon.x returned anisotropic response too). > > Therefore, I increased the k-point (from 20 20 20 to 30 30 30, and to 40 40 > 40) in the simple.x and simple_ip.x calculations, and I failed. Simple.x > finished the calculations with no errors (at least no error messages). The > simple_IP, however, was abruptly finished by the MPI manager with the > following message: > k-point block: 1093 > > > === > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = PID 13719 RUNNING AT quantum01= EXIT CODE: 9 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > > === >Intel(R) MPI Library troubleshooting guide: > https://software.intel.com/node/561764 > > === > After a kick search, I've found that such kind of error occurs when some > an exception like division by zero happens. I've tried to tweak the > parameters, the number of bands (I increased the number of bands, I used > the same number of bands as the KS-states, I tried to use the non-local > commutator, I increased the parameter s, and also decreased it). Hence, I > had no success. > > Do you have any hint? Any workaround? > > Thanks a lot for your help!! > > Best! > > Anibal Bezerra > The Federal University of Alfenas > Alfenas > Brazil > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] mBEEF-vdW
Hello, Is it possible to use the MGGA mBEEF-vdW in QE? (via libbeef or libxc) Best regards, Michal Krompiec Merck KGaA ___ 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] GPU Q-E: how to use
Dear Sergey, T4 won’t help you much, even if you manage to compile QE to work with it. You need a GPU with high double-precision performance, such as V100 or P100. Best regards, Michal Krompiec Merck KGaA On Sat, 5 Sep 2020 at 22:03, Sergey Lisenkov wrote: > Dear all, > > I have an access to our new cluster - IBM Power9 (each node has 2 x 20 > cores + 4 Nvidia T4 GPU). It seems it is very similar to Marconi100, which > seems to be very familiar to many of users here. > > Anyway, I'm trying to utilize GPU version of Quantum EspreSSO, but I have > almost no experience with that. I was reading WIKI at QE-GPU, so I was able > to compile it. We have PGI and GNU compilers installed, IBM Spectrum MPI > and OpenMPI, ESSL library. > > According to some templates, I was able to compile PW.x using PGI/IBM > Spectrum MPI, FFTW3, and ESSL. CPU version is quite slow on such cluster > (almost twice slower than on Cray XC40). > > But I'm not sure how to correctly run GPU version. Since each node has 4 > GPU, it means pw.x runs only on 4 GPU, and 40 CPU cores are idle? > Unfortunately, our cluster does not have too much documentation, so I use > google to find out how to utilize such system. We have LSF installed, > unfortunately, because all similar systems use SLURM. > > If somebody runs GPU Q-E, can you share some examples how to correctly run > the code? > > Thanks, > Sergey > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Enabling van der Waal interaction
Dear Yuvam, You have 3 options: 1) Semi-empirical corrections. DFT-D3(BJ) etc, available directly in QE. Negligible computational cost. My first choice if I don’t want to use ASE (see below). Other pairwise corrections in QE (D2 and TS) are less accurate. DFT-D4 is newer and more accurate, esp. for transition metal - containing systems and for salt crystals. Not available in QE, but you can use it via ASE (see examples in the python directory in the DFT-D4 github repo). See also https://s3-eu-west-1.amazonaws.com/itempdf74155353254prod/10299428/Extension_and_Evaluation_of_the_D4_London_Dispersion_Model_for_Periodic_Systems_v1.pdf and references cited therein. 2) XDM. Available in QE. Arguably, not more accurate than D3 or D4, but much more computationally expensive. 3) VdW functionals, like VV10 and composite functionals. Never used them so can’t advise you on this. See this for the most notable example (available in latest QE) https://journals.aps.org/prb/abstract/10.1103/PhysRevB.85.235149 Best, Michal Krompiec Merck KGaA On Fri, Aug 21, 2020 at 2:43 PM Yuvam Bhateja wrote: > Hello experts, > > Can anyone give some valuable information on this? > > Thank you. > > Regards > Yuvam Bhateja > IIEST Shibpur > > On Mon, 17 Aug 2020, 2:04 pm Yuvam Bhateja, wrote: > >> Dear experts, >> >> Hope you are doing well. >> >> I want to enable van der Waal interaction with my heterogeneous system >> having Cr2O3 and graphene stacked. >> The interaction between the layers is week van der Waal interaction but >> it wasn't mentioned what type of van der Waal in previous publications. >> My question is which XC correlation and type of pseudopotential will be >> best or at least better for which type of van der Waal forces? >> >> Thank you in advance. >> >> Regards >> Yuvam Bhateja >> B.Tech. >> E >> IIEST Shibpur >> India >> >> >> > > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] VASP POTCAR into Quantum Espresso formats
But what is the point if you can use D3 in QE directly? (and D4 via ASE) Best regards, Michal Krompiec Merck KGaA On Mon, Aug 17, 2020 at 8:49 PM Ilias Miroslav, doc. RNDr., PhD. < miroslav.il...@umb.sk> wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > there is nice the work of Trombach et al., > > https://doi.org/10.1039/C9CP02455G . > > > > > > > > Authors constructed D3 enhanced PAW potentials for some superheavy > elements, but only in VASP POTCAR format (see them in > http://www.rsc.org/suppdata/c9/cp/c9cp02455g/c9cp02455g3.zip , > > also > > http://www.rsc.org/suppdata/c9/cp/c9cp02455g/c9cp02455g2.pdf) . These 8 > potentials are free to use. > > > > > > > > > > Is there a viable way to convert these POTCAR files into format suitable > for Quantum Espresso ? > > > > > > > > Best, Miro > > > > > > > > PS: I asked similar question on Abinit forum, > https://forum.abinit.org/viewtopic.php?t=4469 . > > > > > > > > > > > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] ParO and PPCG iterative diagonalization algorithms
Hello, The release notes for QE 6.6 mention "ParO and PPCG iterative diagonalization algorithms". Are any benchmarks available? For what cases are these methods faster than CG? Best, Michal Krompiec Merck KGaA ___ 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] Do not reuse previous rho during relaxations
Dear Antoine, You could do it by using an external geometry optimizer. I suppose you could use ASE, and set up the QE calculator in ASE in such a way that the charge density isn't reused. Best regards, Michal Krompiec Merck KGaA On Mon, 3 Aug 2020 at 11:49, Antoine Jay wrote: > Dear all, > Is it possible to perform a relaxation calculation without using the > charge density of the previous geometry? > startingpot and startingwfc have no influence on the second optimized > geometry... > > Best regards, > > Antoine Jay > LAAS-CNRS > Toulouse, France ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Not geeting enough bands
You’ll get this error message if nbnd is less than half the number of valence electrons. Best, Michal Krompiec Merck KGaA On Mon, Jul 27, 2020 at 1:04 PM Poonam Kaushik wrote: > Dear QE Users, > Is there any specific reason for not getting enough bands in the > system for any material. > > Warm regards, > Poonam Sharma > > > > > > - > Poonam Sharma > Research Scholar > Department of Physics > Indian Institute of Technology Bombay > Mumbai - 400076 > India. > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Occupation calculation - epsilon.x code
Dear Andrea, It would be great if you could share the new epsilon.f90 code. If it takes time to merge it with the develop branch, can you put it in a separate one for now? Best regards, Michal Krompiec Merck KGaA, Darmstadt, Germany On Wed, 8 Jul 2020 at 20:31, Andrea Ferretti wrote: > > Dear Anibal, > > you are right, it seems calculation="occ" is documented but no longer > there. As far as I understand, the reason is exactly that it is preferred > to directly compute the quantity of interest and perform convergence > checks on it (epsilon.x should be fast enough, though). > > Regarding the anysotropy: as far as I remember epsilon.x does not > implement symmetries, meaning that kpts need to span the whole BZ. > If you run a scf and a nscf calculation using pw.x and does not pay > attention to this (meaning you have not set nosym=.T. noinv=.T.), kpts > will be symmetrized and only the IBZ wedge will be sampled. In turn this > can lead to spurious anysotropy (besides non-correct results). > > hope it helps > Andrea > > BTW: I have a newer version of epsilon.f90 contributed by Tae-Yun Kim > (Seoul National University, South Korea) which fixes a number of these > issues. Just haven't found the time to include it in the official > distribution. > > > > > The epsilon.x manual (in the PP/DOC folder) shows the possibility of > calculating occupations using the key "occ" within the epsilon.x. It is > > emphasized to be a good tool to analyze convergency against the > broadening parameter and the k points sampling. However, the "occ" > > calculation is not implemented (at least in the version I'm using - > 6.4). Such a calculation was implemented with other packages? > > > > If not, is there a way of verifying the convergence other than > explicitly changing the broadening and k points sampling? > > > > I'm working with an AuAl alloy, trying to evaluate the dielectric > function. Using epsilon.x I've got anisotropic behavior that I was not > > expecting for. Working with pure systems (Au and Al) I concluded that > reducing conv_thr increases the epsilon.x output precision, returning > > the isotropic behavior of the dielectric function. Therefore, to the > alloy (with 12 atoms in the cell), I increased both the conv_thr (1e-13) > > and k points (14 14 14). I still got the anisotropy. Should I go further > (calculations with my actual computing power are becoming very time > > and memory consuming)? > > > > Thanks in advance!! > > > > Anibal Bezerra > > The Federal University of Alfenas > > > > > > -- > 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 > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Ionization energy with HSE
Dear Shivesh, Try GWL (part of the QE distribution), it is perhaps the most economic way to calculate G0W0 quasiparticle energies, the GW energy of the valence band maximum is a much better estimate of IP than HOMO. Best, Michal On Wed, 8 Jul 2020 at 03:45, Shivesh Sivakumar wrote: > Hello users, > > I was wondering whether the ionization energy calculated from a HSE > calculation has any physical relevance. I understand the mixing of exact > exchange gives us a more reliable estimate of the band gap, but is it > possible to comment on the ionization energy? I intend to do this the same > way as PBE, LDA etc - Calculate the vacuum level and then compute I.E. as > Vacuum - HOMO. I also want to know if pp.x and average.x are compatible > with hybrid functional calculations on QE. I've already calculated the IE > using PBE for my material but don't know what to expect for HSE. > > Any comments or insights would be very appreciated. > > Best, > Shivesh Sivakumar > University of Washington-Seattle > WA-98105 > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] memory problem
Dear Neelam, I am by no means an expert, but from my limited experience I can say that 4GB of RAM is not a lot, to put it mildly - but at the same time, your system isn't large. In this case, I wouldn't use any parallelization on k-points (pw.x -npool 1) and make use of symmetry as much as possible (correct ibrav instead of ibrav=0). You can save memory by reducing ecutwfc (at the expense of accuracy) - so try choosing pseudopotentials which give you desired accuracy at the lowest ecutwfc (use https://www.materialscloud.org/discover/sssp to guide you). Best, Michal On Mon, 6 Jul 2020 at 10:27, Neelam Swarnkar wrote: > Dear expert and all > > I am making the supercell of 2x1x1 total 24 no of atoms, and perform scf > calculation .but there is memory related problem currently i am using 4gb > RAM. > > What can i do to solve this problem? > > Thanks in advance > Neelam > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Problem implementing Exact exchange part in HSE calculation
Dear Nawaf, You may be running out of memory. Try setting ecutfock=ecutwfc (or, at most, 2*ecutwfc). Best, Michal Krompiec Merck On Sun, Jul 5, 2020 at 11:58 AM Nawaf A wrote: > Dear QE users. > I am trying to do an HSE calculation of 47 atoms (with 1 defect) > calculation, but the calculations stop after the PBE calculation. The > calculations run through the entire allotted time without printing any > output for the ACE calculation, I think the ACE calculation is not getting > started, > > The output file end like this, > > EXX grid: 205417 G-vectors FFT dimensions: ( 75, 75, 75) > Application 1125244 exit codes: 139 > Application 1125244 resources: utime ~129264s, stime ~216344s, Rss ~60976, > inblocks ~912, outblocks ~0 > > > The calculation is flagging this error, > > pw.x 2027105D us_exx_mp_addusxx 215 > us_exx.f90 > pw.x 200C6956 exx_mp_vexx_k_ 2046 exx.f90 > pw.x 201078C4 exx_mp_vexx_ 1385 exx.f90 > pw.x 20107F95 exx_mp_aceinit_k_5498 exx.f90 > pw.x 2010921A exx_mp_aceinit_ 5333 exx.f90 > pw.x 20010D0D electrons_183 > electrons.f90 > pw.x 201FA364 run_pwscf_116 > run_pwscf.f90 > pw.x 2000E86A MAIN__ 70 > pwscf.f90 > pw.x 2000E6BE Unknown Unknown Unknown > libc.so.6 2AAAB79D96E5 Unknown Unknown Unknown > pw.x 2000E5C9 Unknown Unknown Unknown > _pmiu_daemon(SIGCHLD): [NID 00190] [c0-0c2s15n2] [Mon Jun 22 21:49:28 > 2020] PE RANK 3 exit signal Segmentation fault > _pmiu_daemon(SIGCHLD): [NID 00191] [c0-0c2s15n3] [Mon Jun 22 21:49:28 > 2020] PE RANK 44 exit signal Segmentation fault > > I tried tweaking inputs and resources for the calculation is also well > met, Is it a compiler issue? Where am I going wrong? > > > > Best regards > *Nawaf * > MSc-PhD'18 > Dept. of Energy Science & Engineering > IIT Bombay > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Smearing in metals - what are metals in the context of Quantum espresso - Reg
Dear Singaravelan, You can apply Fermi smearing to anything you want, just it won't always make sense. It is applied to calculations on metals (meaning "anything that has a band gap similar to or lower than kT"), see http://theossrv1.epfl.ch/Main/ElectronicTemperature for a detailed discussion. You can also apply it to insulators/semiconductors to improve convergence - but use gaussian smearing with a small value of degauss. Best, Michal Krompiec Merck Performance Materials Ltd. On Fri, 3 Jul 2020 at 12:25, singaravelan T R wrote: > Dear all, > In the tutorial files, there is lists called occupations and we have > options in that like tetrahedron, smearing etc. > *Question:* > *We can apply smearing in the case of metals right, then what are metals > in the context of Quantum espresso.? * > *is this D and f block elements alone or elements from s and p block also > like Al, Sr etc.* > *Is it mean we cannot apply smearing to Non metals and metalloids in the > periodic table.* > With thanks, > Singaravelan T R > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] Turbo_lanczos and mgga?
Hello, Does turbo_lanczos work with meta-gga? Thanks, Michal Krompiec Merck KGaA ___ 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] turbo_davidson, turbo_lanczos and scissor operator
Dear Iurii, Thanks! It is not described in the docs, but I figured out that the variable scissor is used here: https://gitlab.com/QEF/q-e/-/blob/develop/TDDFPT/src/lr_apply_liouvillian.f90#L557: (and here: https://gitlab.com/QEF/q-e/-/blob/develop/TDDFPT/src/lr_apply_liouvillian.f90#L711 ) DO ibnd = 1,nbnd ! CALL zaxpy(ngk(1), CMPLX(-(et(ibnd,1)-scissor),0.0d0,DP), & & spsi1(:,ibnd), 1, sevc1_new(:,ibnd,1), 1) !ENDDO Can you tell from this bit whether it is in Ry or eV? It seems from lr_readin.f90 that the units aren't converted. Best wishes, Michal On Fri, 5 Jun 2020 at 13:42, Timrov Iurii wrote: > > Is it possible to use the scissor operator in a TDDFT calculation using > turbo_davidson or turbo_lanczos? > > > Yes in turbo_lanczos: the keyword is "scissor" in the lr_control namelist. > But I do not remember if it is in Ry or eV. > > > Cheers, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > -- > *From:* users on behalf of > Michal Krompiec > *Sent:* Friday, June 5, 2020 2:23:26 PM > *To:* Quantum Espresso users Forum > *Subject:* [QE-users] turbo_davidson, turbo_lanczos and scissor operator > > Hello, > Is it possible to use the scissor operator in a TDDFT calculation using > turbo_davidson or turbo_lanczos? > Best regards, > Michal Krompiec > Merck Performance Materials Ltd. > Southampton, UK > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] turbo_davidson, turbo_lanczos and scissor operator
Hello, Is it possible to use the scissor operator in a TDDFT calculation using turbo_davidson or turbo_lanczos? Best regards, Michal Krompiec Merck Performance Materials Ltd. Southampton, UK ___ 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] efficient parallelization on a system without Infiniband
Dear Ye, Dear Paolo, I re-ran the benchmarks for my test case: a single MD step of a smallish supercell of a certain oxide semiconductor, with PBE and PAW (from PSlib). Previous timings were from the start of MD run until the end of the 1st SCF iteration of the 2nd MD step. Interestingly, ELPA gave no advantage over ScaLAPACK, and diago_david_ndim=2 made things significantly slower. The ScaLAPACK build is QE 6.5, the ELPA build is the development version from last month. Both compiled with Intel 2020 and Intel MPI. Here are the numbers: MPI per node npool nodes ELPA/Scalapack diago_david_ndim time / s speedup vs 1 node 56 4 1 ELPA 4 1335 56 4 1 ELPA 2 1931 56 4 1 ScaLAPACK 4 976 56 4 1 ScaLAPACK 2 1486 56 4 4 ELPA 4 367 3.637602 56 4 4 ELPA 2 729 2.648834 56 4 4 ScaLAPACK 4 357 2.733894 56 4 4 ScaLAPACK 2 555 2.677477 Best, Michal On Wed, 27 May 2020 at 15:47, Ye Luo wrote: > 3.26x seems possible to me. It can be caused by load imbalance in the > iterative solver among the 4 k-points. > Could you list the time in seconds with 1 node and 4 nodes? Those you used > to calculate 3.26x. > Could you also try diago_david_ndim=2 under "" and provide 1 and > 4-node time in seconds? > > In addition, you may try ELPA which usually gives better performance than > scalapack. > > Thanks, > Ye > === > Ye Luo, Ph.D. > Computational Science Division & Leadership Computing Facility > Argonne National Laboratory > > > On Wed, May 27, 2020 at 9:27 AM Michal Krompiec > wrote: > >> Hello, >> How can I minimize inter-node MPI communication in a pw.x run? My >> system doesn't have Infiniband and inter-node MPI can easily become >> the bottleneck. >> Let's say, I'm running a calculation with 4 k-points, on 4 nodes, with >> 56 MPI tasks per node. I would then use -npool 4 to create 4 pools for >> the k-point parallelization. However, it seems that the >> diagonalization is by default parallelized imperfectly (or isn't it?): >> Subspace diagonalization in iterative solution of the eigenvalue >> problem: >> one sub-group per band group will be used >> scalapack distributed-memory algorithm (size of sub-group: 7* 7 >> procs) >> So far, speedup on 4 nodes vs 1 node is 3.26x. Is it normal or does it >> look like it can be improved? >> >> Best regards, >> >> Michal Krompiec >> Merck KGaA >> Southampton, UK >> ___ >> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) >> users mailing list users@lists.quantum-espresso.org >> https://lists.quantum-espresso.org/mailman/listinfo/users >> > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] efficient parallelization on a system without Infiniband
Hello, How can I minimize inter-node MPI communication in a pw.x run? My system doesn't have Infiniband and inter-node MPI can easily become the bottleneck. Let's say, I'm running a calculation with 4 k-points, on 4 nodes, with 56 MPI tasks per node. I would then use -npool 4 to create 4 pools for the k-point parallelization. However, it seems that the diagonalization is by default parallelized imperfectly (or isn't it?): Subspace diagonalization in iterative solution of the eigenvalue problem: one sub-group per band group will be used scalapack distributed-memory algorithm (size of sub-group: 7* 7 procs) So far, speedup on 4 nodes vs 1 node is 3.26x. Is it normal or does it look like it can be improved? Best regards, Michal Krompiec Merck KGaA Southampton, UK ___ 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] TB09, TPSS
Dear Reinaldo, Thanks, it worked for me, too! Dear All, This is the corrected patch to PW/src/io_rho_xml.f90, to enable starting a meta-GGA job from a GGA density: 154a155 > LOGICAL :: ekin_density_exists 171,174c172,181 < CALL read_rhog( TRIM(dirname) // "ekin-density", & <root_bgrp, intra_bgrp_comm, & <ig_l2g, nspin_, rho%kin_g, gamma_only ) < WRITE(stdout,'(5x,"Reading meta-gga kinetic term")') --- > INQUIRE( FILE = TRIM(dirname) // "ekin-density.dat", > EXIST=ekin_density_exists) > IF ( ekin_density_exists ) THEN >CALL read_rhog( TRIM(dirname) // "ekin-density", & > root_bgrp, intra_bgrp_comm, & > ig_l2g, nspin_, rho%kin_g, gamma_only ) >WRITE(stdout,'(5x,"Reading meta-gga kinetic term")') > ELSE > WRITE(stdout,'(5x,"Setting meta-gga kinetic term to 0")') >rho%kin_g = 1.0 > ENDIF Best regards, Michal On Thu, 21 May 2020 at 13:54, Reinaldo Pis Diez wrote: > > Dear Michal > > No, there is no need of increasing the resolution of the FFT grid if > the previous SCAN job converges well. And the SCAN job on top the > PBE (or other GGA) converges well with default choices, at least for > the cases I tried. > > Regards, > > Reinaldo > > On 21/5/20 09:35, Michal Krompiec wrote: > > Dear Reinaldo, > > Thanks, this sounds very promising! Did you have to use a tighter FFT > > grid or did the default work fine? > > Best, > > Michal Krompiec > > Merck KGaA > > > > On Thu, 21 May 2020 at 13:20, Reinaldo Pis Diez > > wrote: > >> Dear Michal and folks, > >> > >> A few days ago I've faced exactly the same problem after recompiling > >> QE 6.5 with LibXC 4.3.4 to use TB09 to see its effect on the band > >> gap of some semiconductors. > >> > >> What I saw instead is that an scf run of the SCAN functional, also a > >> metaGGA one, converges smoothly on top of a scf, relax or vc-relax > >> job using PBE, for example. TB09 and the others metaGGA available > >> show the divergent behavior you are mentioning. > >> > >> Then, I tried a TB09 job on top of the converged SCAN calculation > >> using restart_mode = 'restart' and the job converged in a few > >> iterations, no divergence was observed. After the TB09 scf job > >> converged, I was able to run nscf and bands jobs to obtain both DOS > >> and band structures. > >> > >> I understand this is not a solution, but a workaround as a more > >> elegant solution is found. > >> > >> Regards, > >> > >> Reinaldo Pis Diez > >> Center of Inorganic Chemistry > >> National University of La Plata > >> Argentina > >> > >>> Dear Paolo, > >>> I changed io_rho_xml.f90 so that if the kinetic energy density file > >>> isn't found, the array is set to 0: > >>> > >>> 155d144 > >>> < LOGICAL :: ekin_density_exists > >>> 172,180c161,164 > >>> < INQUIRE( FILE=TRIM(dirname) // "ekin-density", > >>> EXIST=ekin_density_exists) > >>> < IF ( ekin_density_exists ) THEN > >>> <CALL read_rhog( TRIM(dirname) // "ekin-density", & > >>> < root_bgrp, intra_bgrp_comm, & > >>> < ig_l2g, nspin_, rho%kin_g, gamma_only ) > >>> <WRITE(stdout,'(5x,"Reading meta-gga kinetic term")') > >>> < ELSE > >>> <rho%kin_g = 1.0 > >>> < ENDIF > >>> > >>> Now I can start a TB09 calculation from a PBE density, but still my > >>> test case diverges immediately (=faster than when starting from > >>> scratch), regardless of diagonalization method. For example: > >>>The initial density is read from file : > >>>./sic.save/charge-density > >>> > >>>Starting wfcs from file > >>> > >>>total cpu time spent up to now is0.3 secs > >>> > >>>Self-consistent Calculation > >>> > >>>iteration # 1 ecut=82.00 Ry beta= 0.40 > >>>CG style diagonalization > >>> > >>> > >>> > >>> %%
Re: [QE-users] TB09, TPSS
Dear Reinaldo,
Thanks, this sounds very promising! Did you have to use a tighter FFT
grid or did the default work fine?
Best,
Michal Krompiec
Merck KGaA
On Thu, 21 May 2020 at 13:20, Reinaldo Pis Diez
wrote:
>
> Dear Michal and folks,
>
> A few days ago I've faced exactly the same problem after recompiling
> QE 6.5 with LibXC 4.3.4 to use TB09 to see its effect on the band
> gap of some semiconductors.
>
> What I saw instead is that an scf run of the SCAN functional, also a
> metaGGA one, converges smoothly on top of a scf, relax or vc-relax
> job using PBE, for example. TB09 and the others metaGGA available
> show the divergent behavior you are mentioning.
>
> Then, I tried a TB09 job on top of the converged SCAN calculation
> using restart_mode = 'restart' and the job converged in a few
> iterations, no divergence was observed. After the TB09 scf job
> converged, I was able to run nscf and bands jobs to obtain both DOS
> and band structures.
>
> I understand this is not a solution, but a workaround as a more
> elegant solution is found.
>
> Regards,
>
> Reinaldo Pis Diez
> Center of Inorganic Chemistry
> National University of La Plata
> Argentina
>
> > Dear Paolo,
> > I changed io_rho_xml.f90 so that if the kinetic energy density file
> > isn't found, the array is set to 0:
> >
> > 155d144
> > < LOGICAL :: ekin_density_exists
> > 172,180c161,164
> > < INQUIRE( FILE=TRIM(dirname) // "ekin-density",
> > EXIST=ekin_density_exists)
> > < IF ( ekin_density_exists ) THEN
> > <CALL read_rhog( TRIM(dirname) // "ekin-density", &
> > < root_bgrp, intra_bgrp_comm, &
> > < ig_l2g, nspin_, rho%kin_g, gamma_only )
> > <WRITE(stdout,'(5x,"Reading meta-gga kinetic term")')
> > < ELSE
> > <rho%kin_g = 1.0
> > < ENDIF
> >
> > Now I can start a TB09 calculation from a PBE density, but still my
> > test case diverges immediately (=faster than when starting from
> > scratch), regardless of diagonalization method. For example:
> > The initial density is read from file :
> > ./sic.save/charge-density
> >
> > Starting wfcs from file
> >
> > total cpu time spent up to now is0.3 secs
> >
> > Self-consistent Calculation
> >
> > iteration # 1 ecut=82.00 Ry beta= 0.40
> > CG style diagonalization
> >
> >
> >
> > %%
> > Error in routine c_bands (1):
> > too many bands are not converged
> >
> > %%
> >
> > I would be very grateful for any suggestions.
> > Best,
> > Michal
> >
> > P.S. This is my input file:
> >
> > calculation = "scf"
> > prefix = "sic"
> > /
> >
> >
> > a = 4.34800e+00
> > ibrav = 1
> > ecutwfc = 82
> > ecutrho = 328
> > nat = 8
> > ntyp= 2
> > occupations = "fixed"
> > input_dft='tb09'
> > /
> >
> > electron_maxstep = 1000
> > conv_thr = 1e-10
> > mixing_mode = 'plain'
> > mixing_beta = 0.4
> >startingpot = 'file'
> >startingwfc = 'file'
> >diagonalization = 'cg'
> > /
> >
> > K_POINTS automatic
> > 8 8 8 1 1 1
> >
> > ATOMIC_SPECIES
> > Si 28.08500 Si.upf
> > C 12.01060 C.upf
> >
> >
> > ATOMIC_POSITIONS {angstrom}
> > Si 0.00 0.00 0.00
> > Si 0.00 2.174000 2.174000
> > Si 2.174000 0.00 2.174000
> > Si 2.174000 2.174000 0.00
> > C 1.087000 1.087000 1.087000
> > C 1.087000 3.261000 3.261000
> > C 3.261000 1.087000 3.261000
> > C 3.261000 3.261000 1.087000
> >
> > On Fri, 8 May 2020 at 09:39, Paolo Giannozzi wrote:
> >> On Thu, May 7, 2020 at 10:33 PM Michal Krompiec
> >> wrote:
> >>
> >>> it was suggested to start from a density calculated with a different
> >>> functional, but when I try to read in PBE density, it complains that it
> >>> cannot read the kinetic energy file (which obviously cannot be there).
> >>
> >> this
Re: [QE-users] TB09, TPSS
Dear Paolo,
I changed io_rho_xml.f90 so that if the kinetic energy density file
isn't found, the array is set to 0:
155d144
< LOGICAL :: ekin_density_exists
172,180c161,164
< INQUIRE( FILE=TRIM(dirname) // "ekin-density",
EXIST=ekin_density_exists)
< IF ( ekin_density_exists ) THEN
<CALL read_rhog( TRIM(dirname) // "ekin-density", &
< root_bgrp, intra_bgrp_comm, &
< ig_l2g, nspin_, rho%kin_g, gamma_only )
<WRITE(stdout,'(5x,"Reading meta-gga kinetic term")')
< ELSE
<rho%kin_g = 1.0
< ENDIF
Now I can start a TB09 calculation from a PBE density, but still my
test case diverges immediately (=faster than when starting from
scratch), regardless of diagonalization method. For example:
The initial density is read from file :
./sic.save/charge-density
Starting wfcs from file
total cpu time spent up to now is0.3 secs
Self-consistent Calculation
iteration # 1 ecut=82.00 Ry beta= 0.40
CG style diagonalization
%%
Error in routine c_bands (1):
too many bands are not converged
%%
I would be very grateful for any suggestions.
Best,
Michal
P.S. This is my input file:
calculation = "scf"
prefix = "sic"
/
a = 4.34800e+00
ibrav = 1
ecutwfc = 82
ecutrho = 328
nat = 8
ntyp= 2
occupations = "fixed"
input_dft='tb09'
/
electron_maxstep = 1000
conv_thr = 1e-10
mixing_mode = 'plain'
mixing_beta = 0.4
startingpot = 'file'
startingwfc = 'file'
diagonalization = 'cg'
/
K_POINTS automatic
8 8 8 1 1 1
ATOMIC_SPECIES
Si 28.08500 Si.upf
C 12.01060 C.upf
ATOMIC_POSITIONS {angstrom}
Si 0.00 0.00 0.00
Si 0.00 2.174000 2.174000
Si 2.174000 0.00 2.174000
Si 2.174000 2.174000 0.00
C 1.087000 1.087000 1.087000
C 1.087000 3.261000 3.261000
C 3.261000 1.087000 3.261000
C 3.261000 3.261000 1.087000
On Fri, 8 May 2020 at 09:39, Paolo Giannozzi wrote:
>
> On Thu, May 7, 2020 at 10:33 PM Michal Krompiec
> wrote:
>
>>
>> it was suggested to start from a density calculated with a different
>> functional, but when I try to read in PBE density, it complains that it
>> cannot read the kinetic energy file (which obviously cannot be there).
>
>
> this can be easily changed, I think: just disable the check and set the
> kinetic energy density to zero
>
>>
>> Should TPSS or SCAN pseudos work better (and where do I get them from)?
>
>
> I don't think the problem is in the pseudos but in the nasty numerical
> behavior of meta-GGAs. See for instance here:
> https://gitlab.com/QEF/q-e/-/issues/32. Note that several bugs have been
> fixed in the development version.
>
> Paolo
>
>> Thanks,
>> Michal Krompiec
>> Merck KGaA
>>
>> ___
>> 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
>
>
>
> --
> 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/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] BURAI GUI
Hello, Does anyone have experience with using the Burai GUI on a different machine than the one on which you run QE? Copying the output files into Burai's project directory doesn't work, it seems that something more is required. Best regards, Michal Krompiec / Merck KGaA ___ 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] NEB calculation
Try running without MPI, you might get a less cryptic error. Sometimes MPI error messages mask the actual errors. Best, Michal Krompiec / Merck On Wed, 13 May 2020 at 11:52, Debashrito Deb wrote: > Dear experts, > I am trying to run the example file of NEB calculation in Cygwin command > prompt. > Once I run the program i am encountering error and the error reads, > > > > executables directory: /home/Administrator/q-e-qe-6.5/bin > pseudo directory: /home/Administrator/q-e-qe-6.5/pseudo > temporary directory: /home/Administrator/q-e-qe-6.5/tempdir > checking that needed directories and files exist... done > running Born-Oppenheimer NEB as: mpirun -np 4 > /home/Administrator/q-e-qe-6.5/bin/neb.x -nk 1 -nd 1 -nb 1 -nt 1 > cleaning /home/Administrator/q-e-qe-6.5/tempdir... done > running Born-Oppenheimer NEB calculation for H2+H => > H+H2...-- > MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD > with errorcode 1. > NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. > You may or may not see output from other processes, depending on > exactly when Open MPI kills them. > -- > [gcumedia02:00414] [[43557,0],0] unable to open debugger attach fifo > [gcumedia02:00414] 3 more processes have sent help message > help-mpi-api.txt / mpi-abort > [gcumedia02:00414] Set MCA parameter "orte_base_help_aggregate" to 0 to > see all help / error messages > Error condition encountered during test: exit status = 1 > Aborting > > What can be the possible reason ? a little help would be great. > > regards, > Deb. > > > *Disclaimer : This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error please > notify the originator of the message.Any views expressed in this message > are those of the individual sender, except where the sender specifies, and > with authority, states them to be the views of Garden City University, > Bangalore. *___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] TB09, TPSS
Dear Lorenzo, Yes, this is exactly what I am doing, and this is the error I'm getting: Error in routine read_rhog (1): error reading file ./s.save/ekin-density Best, Michal On Fri, 8 May 2020 at 10:37, Lorenzo Paulatto wrote: > > I think you can do a restart="from_scratch" with startingpot="file", is > this waht you are doing and causes the error about the missing kinetic > energy? > > cheers > > On 5/7/20 10:33 PM, Michal Krompiec wrote: > > Hello, > > I know this was discussed here before, but I still haven’t found a > > satisfactory solution. Can someone share a nontrivial working example of > > an SCF calculation of a periodic solid with TB09? If I start “from > > scratch”, SCF diverges. Previously it was suggested to start from a > > density calculated with a different functional, but when I try to read > > in PBE density, it complains that it cannot read the kinetic energy file > > (which obviously cannot be there). Same problem with TPSS. I was using > > pseudo-dojo NC pseudos for PBE - could this be the source of the > > problem? Should TPSS or SCAN pseudos work better (and where do I get > > them from)? > > Thanks, > > Michal Krompiec > > Merck KGaA > > > > > > ___ > > 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 > > > > -- > Lorenzo Paulatto - Paris > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] TB09, TPSS
Dear Paolo, On Fri, 8 May 2020 at 09:39, Paolo Giannozzi wrote: >> it was suggested to start from a density calculated with a different >> functional, but when I try to read in PBE density, it complains that it >> cannot read the kinetic energy file (which obviously cannot be there). > this can be easily changed, I think: just disable the check and set the > kinetic energy density to zero This change would be very welcome! >> Should TPSS or SCAN pseudos work better (and where do I get them from)? > I don't think the problem is in the pseudos but in the nasty numerical > behavior of meta-GGAs. See for instance here: > https://gitlab.com/QEF/q-e/-/issues/32. Note that several bugs have been > fixed in the development version. Thanks, I will check on the latest development branch. Best, Michal ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] TB09, TPSS
Hello, I know this was discussed here before, but I still haven’t found a satisfactory solution. Can someone share a nontrivial working example of an SCF calculation of a periodic solid with TB09? If I start “from scratch”, SCF diverges. Previously it was suggested to start from a density calculated with a different functional, but when I try to read in PBE density, it complains that it cannot read the kinetic energy file (which obviously cannot be there). Same problem with TPSS. I was using pseudo-dojo NC pseudos for PBE - could this be the source of the problem? Should TPSS or SCAN pseudos work better (and where do I get them from)? Thanks, Michal Krompiec Merck KGaA ___ 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] [SUSPECT ATTACHMENT REMOVED] Error in routine divide_et_impera (1):
Dear Abdulla,
No need to run on 1 processor. The error is caused by the fact that
the number of k-points (1) is not divisible by the number of MPI pools
(4 in your case). Run with -npool 1 instead of -npool 4.
Best,
Michal Krompiec
Merck KGaA
On Mon, 4 May 2020 at 11:59, Offermans Willem wrote:
>
> Dear Abdulla and Quantum Espresso friend,
>
> From the error message you showed I got the impression that there is
> something wrong in the way
> you run mpi. If you run parallel along kpoints (111), then some nodes will be
> workless.
>
> Run on 1 processor (not parallel) and the error message might disappear.
>
> If I recall correctly, you can also run in parallel along the bands. That
> might be an alternative, if you insist on running in parallel.
>
>
>
> > On 3 May 2020, at 23:21, Abdulla Bin Afif wrote:
> >
> > Hi QE community members,
> >
> >
> > When I conduct scf calculation on an organometallic TMA
> > (trimethylaluminium), it shows an error.
> >
> > For molecules we consider Kpoints 11100, with this its gives the below
> > error and when the Kpoints are changed to 33300 there is no error, I am not
> > sure why it’s not working with 111000.
> >
> > I have a considered TMA compound inside a unit cell of 15A.
> >
> > %%
> > Error in routine divide_et_impera (1):
> > some nodes have no k-points
> > %%
> >
> > calculation = 'scf',
> > outdir = '.',
> > prefix = 'calc',
> > pseudo_dir = '.',
> > tprnfor = .true.,
> > tstress = .true.,
> > /
> >
> > degauss = 0.00734986475817d0,
> > ecutrho = 367.493237909d0,
> > ecutwfc = 36.7493237909d0,
> > ibrav=1,
> > celldm(1)=28.3459,
> > nat = 13,
> > ntyp = 3,
> > occupations = 'smearing',
> > smearing = 'cold',
> > input_dft='PBE',
> > /
> >
> > diagonalization='david',
> > conv_thr=7.34986475817e-07,
> > mixing_mode='plain',
> > electron_maxstep=100,
> > mixing_beta=0.7d0,
> > /
> > ATOMIC_SPECIES
> > Al 26.98154 Al.UPF,
> > C 12.011 C.UPF,
> > H 1.00794 H.UPF,
> > ATOMIC_POSITIONS {crystal}
> > Al 0.534480 0.546680 0.534270
> > C0.424210 0.610350 0.534450
> > C0.644760 0.610350 0.534450
> > C0.534480 0.419350 0.534450
> > H0.403230 0.622650 0.465970
> > H0.373560 0.570980 0.568590
> > H0.432900 0.673750 0.568880
> > H0.665740 0.622270 0.602990
> > H0.695400 0.571180 0.500090
> > H0.636070 0.673940 0.500370
> > H0.534320 0.395030 0.465970
> > H0.593900 0.395180 0.568590
> > H0.475240 0.395180 0.568880
> > K_POINTS (automatic)
> > 1 1 1 0 0 0
> >
> >
> > Output
> >
> > This program is part of the open-source Quantum ESPRESSO suite
> > for quantum simulation of materials; please cite
> > "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
> > "P. Giannozzi et al., J. Phys.:Condens. Matter 29 465901 (2017);
> > URL http://www.quantum-espresso.org;,
> > in publications or presentations arising from this work. More details
> > at
> > http://www.quantum-espresso.org/quote
> >
> > Parallel version (MPI & OpenMP), running on 24 processor cores
> > Number of MPI processes:24
> > Threads/MPI process: 1
> >
> > MPI processes distributed on 1 nodes
> > K-points division: npool = 4
> > R & G space division: proc/nbgrp/npool/nimage = 6
> > Waiting for input...
> > Reading input from standard input
> >
> > Current dimensions of program PWSCF are:
> > Max number of different atomic species (ntypx) = 10
> > Max number of k-points (npk) = 4
> > Max angular momentum in pseudopotentials (lmaxx) = 3
> >
> > IMPORTANT: XC functional enforced from input :
> > Exchange-corre
Re: [QE-users] On the use of the modified Becke-Johnson (TB09) functional
Hello, I cannot reproduce this with current development version. Any attempt of using a PBE density as the starting point for a TB09 calculation ends up with: Error in routine read_rhog (1): error reading file ./s.save/ekin-density This happens if I run scf with PBE and then nscf with TB09, or scf with PBE followed by scf with TB09 (restart_mode='restart'). Any suggestion would be appreciated. Thanks, Michal Krompiec Merck KGaA On Wed, 6 Nov 2019 at 19:36, Fabio Costa wrote: > > Dear users and developers > > After some more attempts to use the TB09 functional, I ended up finding this > previous post: > https://lists.quantum-espresso.org/pipermail/users/2019-April/042619.html , > and after changing v_of_rho.f90, the code is now able to end without any > error. > > In my attempts, I'm performing the calculations as an initial scf run with a > PBE pseudopotencial, and then another scf run, now with restart_mode = > 'restart' and input_dft = 'MGGA_X_TB09'. By following this procedure, as > described in E. Germaneau's paper, the calculations do converge. > > The issue now is that the gap energies I'm finding are very large. For > example, for silicon, the calculations result in a 2.8 eV gap, larger even > than the results presented in the paper, where the values ranged between 1.9 > to 2.3. Despite the large gaps, the band structure and DOS agree well with > the ones obtained with PBE. > > Is there any way to improve these results. My first guess is to adjust the > "c" parameter in the mBJ functional. After some searching through the > routines and Libxc files, I'm still clueless on how to proceed on this matter. > > Any further suggestions will be much appreciated > > Thank you > Fábio Costa > > > > > De: users em nome de Fabio Costa > > Enviado: segunda-feira, 14 de outubro de 2019 13:10 > Para: users@lists.quantum-espresso.org > Assunto: [QE-users] On the use of the modified Becke-Johnson (TB09) functional > > Dear all > > I'm having some difficulties to work with the TB09 functional. After some > reading, I found in some old posts that this can be done by compiling QE > with Libxc, and by adding the line 'input_dft='tb09'' in the pw.x input. > > When I try to use this functional, the scf calculation always ends like this: > > total energy = NaN Ry Harris-Foulkes > estimate = -11.24358313 Ry estimated scf accuracy< > 0.01858366 Ry iteration # 18 ecut= 120.00 Ry beta= 0.10 > Davidson diagonalization with overlap > %% > Error in routine cdiaghg (7): eigenvectors failed to converge > %% > > What draws my attention is that always in the last cycle before the error the > total energy is printed as NaN. The parameters to the calculation seem to be > fine, as it ends smoothly without the input_dft line. > > By searching in the QE user guide, there is a reference to the work of E. > Germaneau, which lead me to his paper (DOI: 10.1016/j.cpc.2013.02.020), where > the results of his implementation are presented. Even though, it is unclear > to me how to use the functional correctly. > > Thanks for any assistance > Fábio Costa > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] error in libxc-enabled QE run: Internal List-Directed Read
Hello, When running an epsilon.x calculation following a (successful) SCF calculation, I am getting this error: Reading xml data from directory: ./sic.save/ forrtl: severe (24): end-of-file during read, unit -5, file Internal List-Directed Read Image PCRoutineLineSource epsilon.x 050AB67B Unknown Unknown Unknown epsilon.x 050D7C32 Unknown Unknown Unknown epsilon.x 050D69B8 Unknown Unknown Unknown epsilon.x 0078B13A Unknown Unknown Unknown epsilon.x 007891EB Unknown Unknown Unknown epsilon.x 00423239 Unknown Unknown Unknown epsilon.x 00427E12 Unknown Unknown Unknown epsilon.x 0040841C Unknown Unknown Unknown epsilon.x 00407D22 Unknown Unknown Unknown libc-2.22.so 2B26D0428725 __libc_start_main Unknown Unknown epsilon.x 00407C29 Unknown Unknown Unknown There is no indication that the wavefunctions weren't saved properly. Exactly the same script (but with the standard QE and PBEsol functional) works fine. I am using QE 6.5 (yesterday's develop branch), linked with libxc 4.3.4. I would be grateful for any advice. Thanks, Michal ___ 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] libxc functionals not listed in Modules/funct.f90, HLE16
Dear Fabrizio, Thank you very much! Best, Michal On Sun, 26 Apr 2020 at 18:31, Fabrizio Ferrari wrote: > Hello, > in general yes, but how depends a bit on the version you are using. In 6.5 > it is sufficient to enforce it from input by putting > input_dft='GGA_XC_HLE16' in in the input file. > However I recommend you to use the develop version of QE, since there is a > quite recent factor 2 correction in one of the gga terms of the potential > that is missing in v6.5 when libxc is used. > Best regards, > Fabrizio > > On Sun, Apr 26, 2020 at 6:40 PM Michal Krompiec > wrote: > >> Dear all, >> is it possible to use libxc functionals not listed in Modules/funct.f90? >> If so, how? >> Specifically, I’d like to try HLE16 (GGA_XC_HLE16 (id=545) in libxc). >> Thanks, >> Michal Krompiec >> Merck KGaA >> > ___ >> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) >> users mailing list users@lists.quantum-espresso.org >> https://lists.quantum-espresso.org/mailman/listinfo/users > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] libxc functionals not listed in Modules/funct.f90, HLE16
Dear all, is it possible to use libxc functionals not listed in Modules/funct.f90? If so, how? Specifically, I’d like to try HLE16 (GGA_XC_HLE16 (id=545) in libxc). Thanks, Michal Krompiec Merck KGaA ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] MPI errors specific to head.x
Hello, I'm using QE 6.5 build with Intel 2020 compilers and ELPA library. I am seeing a weird MPI crash when running head.x (while every other code in QE seems to run just fine!). I would be very grateful if someone could point me in the right direction. Abort(873024773) on node 0 (rank 0 in comm 0): Fatal error in PMPI_Comm_size: Invalid communicator, error stack: PMPI_Comm_size(110): MPI_Comm_size(comm=0x0, size=0x7ffdd7d69e50) failed PMPI_Comm_size(67).: Invalid communicator Error condition encountered during test: exit status = 5 When using QE 6.5 built with GCC 8.3 and Intel MKL 2020, head.x also crashes, but only if the number of MPI processes is above 1, with this message: Error in routine cdiaghg (44): S matrix not positive definite When I run it with only 1 MPI process, it runs fine. Is there any particular reason why head.x would not like to be MPI-parallelized? Can it be because my system is rather small? (8 atoms, so same size as "example05") Best regards, Michal Krompiec Merck KGaA ___ 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] dielectric function from turbo_lanczos
Dear Iurii, Thank you. The patch to turbo_spectrum didn't work for me (it does compile but the results don't look good). But I obtained really nice results with turbo_eels, thanks for recommending it! Best regards, Michal On Tue, 21 Apr 2020 at 14:10, Timrov Iurii wrote: > > Dear Michal, > > > > Unfortunately, the commented-out code from > > tddpft_calculate_spectrum.f90 doesn't compile, and my knowledge of > > Fortran is not nearly good enough to fix this: > > tddfpt_calculate_spectrum.f90(469): error #6366: The shapes of the > > array expressions do not conform. [EPS] > eps(ip,ip2) = (1.d0,0.d0)-(32.d0*pi/omega)*green(ip,ip2) > > > Since it is commented out, there are some mistakes there. If you want you can > try the fix: > > > DO ip=1,n_ipol > >DO ip2=1,n_ipol > > ! > > eps(ip,ip2) = (1.d0,0.d0) - (32.d0*pi/volume) * green(ip,ip2) > > ! > > WRITE(17,'(5x,"chi_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > ip2, ip, start, dble(green(ip,ip2)), aimag(green(ip,ip2)) > > > write(*,'(5x,"eps_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > ip2, ip, rytoev*omeg, dble(eps), aimag(eps) > > ! > > ENDDO > > ENDDO > > > But I haven't tested whether this gives the correct result. > > > > I will go for the turbo_eels route, then. What value of q is low > > enough (to approximate q->0), in your experience? If it needs to be > > determined by a convergence test, what is a good starting point? > > > No need to perform the convergence test w.r.t q. Just try this (should be > ok): > > > _control > >itermax = 2000, <- this has to be checked > >q1 = 0.001, > >q2 = 0.000, > >q3 = 0.000 > > / > > > Regards, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > > From: users on behalf of Michal > Krompiec > Sent: Tuesday, April 21, 2020 2:43:19 PM > To: Quantum ESPRESSO users Forum > Subject: Re: [QE-users] dielectric function from turbo_lanczos > > Dear Iurii, > Unfortunately, the commented-out code from > tddpft_calculate_spectrum.f90 doesn't compile, and my knowledge of > Fortran is not nearly good enough to fix this: > tddfpt_calculate_spectrum.f90(469): error #6366: The shapes of the > array expressions do not conform. [EPS] > eps(ip,ip2) = (1.d0,0.d0)-(32.d0*pi/omega)*green(ip,ip2) > > I will go for the turbo_eels route, then. What value of q is low > enough (to approximate q->0), in your experience? If it needs to be > determined by a convergence test, what is a good starting point? > > Best, > > Michal > > > On Tue, 21 Apr 2020 at 13:20, Timrov Iurii wrote: > > > > Dear Michal, > > > > > > > But I noticed that eps is calculated for the EELS spectrum (line 555) > > > and Re(eps) and Im(eps) are printed to the output file. Would it make > > > sense to use this for the calculation of the refractive index? > > > > > > I think yes. But use turboEELS code in this case. > > > > > > Please note that the susceptibility \chi in the turbo_lanczos code and \chi > > in turbo_eels code are not the same thing. In the former case \chi is > > proportional to \epsilon, while in the latter case \chi is proportional to > > \epsilon^-1. > > > > > > So if you use the turboEELS (turbo_eels) code with q->0, you will obtain > > \chi from which you will obtain \epsilon^-1. Then the code also computes > > \epsilon from \epsilon^-1. > > > > > > Greetings, > > > > Iurii > > > > > > -- > > Dr. Iurii Timrov > > Postdoctoral Researcher > > STI - IMX - THEOS and NCCR - MARVEL > > Swiss Federal Institute of Technology Lausanne (EPFL) > > CH-1015 Lausanne, Switzerland > > +41 21 69 34 881 > > http://people.epfl.ch/265334 > > > > From: users on behalf of Michal > > Krompiec > > Sent: Tuesday, April 21, 2020 12:57:39 PM > > To: Quantum ESPRESSO users Forum > > Subject: Re: [QE-users] dielectric function from turbo_lanczos > > > > Dear Iurii, > > Thanks, I will try that. > > But I noticed that eps is calculated for the EELS spectrum (line 555) > > and Re(eps) and Im(eps) are printed to the
Re: [QE-users] Quantum Espresso results visualization
Hi Aldimar, ChemCraft (http://www.chemcraftprog.com/) has recently added QE support, although it is still very brittle. ADF and Schrodinger's Maestro can read/write QE files and automate calculations. Best, Michal Krompiec Merck KGaA On Tue, 21 Apr 2020 at 18:32, Aldimar Rodrigues wrote: > > hello, I'm looking for a modeling software that allows me to visualize the > results of Quantum Espresso calculations (open your output files). > I'm using Burai, but for some reason it doesn't open the QE output files and > it's also not possible to perform the calculations directly from it. > I also tried P4VASP, but it did not open the QE files. > Could someone please tell me other package options for viewing Quantum > Espresso results? > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] dielectric function from turbo_lanczos
Dear Iurii, Unfortunately, the commented-out code from tddpft_calculate_spectrum.f90 doesn't compile, and my knowledge of Fortran is not nearly good enough to fix this: tddfpt_calculate_spectrum.f90(469): error #6366: The shapes of the array expressions do not conform. [EPS] eps(ip,ip2) = (1.d0,0.d0)-(32.d0*pi/omega)*green(ip,ip2) I will go for the turbo_eels route, then. What value of q is low enough (to approximate q->0), in your experience? If it needs to be determined by a convergence test, what is a good starting point? Best, Michal On Tue, 21 Apr 2020 at 13:20, Timrov Iurii wrote: > > Dear Michal, > > > > But I noticed that eps is calculated for the EELS spectrum (line 555) > > and Re(eps) and Im(eps) are printed to the output file. Would it make > > sense to use this for the calculation of the refractive index? > > > I think yes. But use turboEELS code in this case. > > > Please note that the susceptibility \chi in the turbo_lanczos code and \chi > in turbo_eels code are not the same thing. In the former case \chi is > proportional to \epsilon, while in the latter case \chi is proportional to > \epsilon^-1. > > > So if you use the turboEELS (turbo_eels) code with q->0, you will obtain \chi > from which you will obtain \epsilon^-1. Then the code also computes \epsilon > from \epsilon^-1. > > > Greetings, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > > From: users on behalf of Michal > Krompiec > Sent: Tuesday, April 21, 2020 12:57:39 PM > To: Quantum ESPRESSO users Forum > Subject: Re: [QE-users] dielectric function from turbo_lanczos > > Dear Iurii, > Thanks, I will try that. > But I noticed that eps is calculated for the EELS spectrum (line 555) > and Re(eps) and Im(eps) are printed to the output file. Would it make > sense to use this for the calculation of the refractive index? > > Best, > > Michal > > On Tue, 21 Apr 2020 at 10:43, Timrov Iurii wrote: > > > > Dear Michal, > > > > > > > Now, how do I convert the complex susceptibility chi (from the output of > > > turbo_lanczos) to epsilon? I know that in principle epsilon = 1 + chi, > > > but then the results don’t make sense. Am I missing some unit conversion > > > or something else? > > > Moreover, turbo_lanczos is complaining it hasn’t got enough information > > > to compute S - what could be the cause of this? > > > > > > S is the oscillator strength. Some useful information is written in the > > output file of the turbo_spectrum calculation (for finite systems): > > > > > > chi_i_j: dipole polarizability tensor in units of e^2*a_0^2/energy > > > > S: oscillator strength in units of 1/energy > > > > S(\hbar \omega) = 2m/( 3 \pi e^2 \hbar) \omega sum_j chi_j_j > > > > S(\hbar \omega) satisfies the f-sum rule: \int_0^\infty dE S(E) = N_el > > > > > > In your case you are interested in epsilon for periodic systems, so you may > > look in the code TDDFPT/tools/tddfpt_calculate_spectrum.f90. E.g. on lines > > 463-475 it is written: > > > > > > DO ip=1,n_ipol > > > > DO ip2=1,n_ipol > > > > ! > > > > !eps(ip,ip2) = (1.d0,0.d0)-(32.d0*pi/omega)*green(ip,ip2) > > > > ! > > > > WRITE(17,'(5x,"chi_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > > > ip2, ip, start, dble(green(ip,ip2)), aimag(green(ip,ip2)) > > > > > > ! write(*,'(5x,"eps_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > > > ! ip2, ip, ry*omeg, dble(eps), aimag(eps) > > > > ! > > > > ENDDO > > > > ENDDO > > > > > > What you need is "eps", but it is commented out. So just uncomment it here > > and check in other places in this program and see what you obtain. Since > > this is commented out, one has to be careful and check if the result is > > correct. I do not know where the factor 32 comes from (one has to think). > > It was not me who coded this. You may also check the literature how the > > dielectric matrix is obtained from the susceptibility matrix (i.e. what are > > the prefactors). > > > > > > HTH > > > > > > Iurii > > > > > > -- > > Dr. Iurii Timrov > > Postdoctoral Resea
Re: [QE-users] dielectric function from turbo_lanczos
Dear Iurii, Thanks, I will try that. But I noticed that eps is calculated for the EELS spectrum (line 555) and Re(eps) and Im(eps) are printed to the output file. Would it make sense to use this for the calculation of the refractive index? Best, Michal On Tue, 21 Apr 2020 at 10:43, Timrov Iurii wrote: > > Dear Michal, > > > > Now, how do I convert the complex susceptibility chi (from the output of > > turbo_lanczos) to epsilon? I know that in principle epsilon = 1 + chi, but > > then the results don’t make sense. Am I missing some unit conversion or > > something else? > > Moreover, turbo_lanczos is complaining it hasn’t got enough information to > > compute S - what could be the cause of this? > > > S is the oscillator strength. Some useful information is written in the > output file of the turbo_spectrum calculation (for finite systems): > > > chi_i_j: dipole polarizability tensor in units of e^2*a_0^2/energy > > S: oscillator strength in units of 1/energy > > S(\hbar \omega) = 2m/( 3 \pi e^2 \hbar) \omega sum_j chi_j_j > > S(\hbar \omega) satisfies the f-sum rule: \int_0^\infty dE S(E) = N_el > > > In your case you are interested in epsilon for periodic systems, so you may > look in the code TDDFPT/tools/tddfpt_calculate_spectrum.f90. E.g. on lines > 463-475 it is written: > > > DO ip=1,n_ipol > > DO ip2=1,n_ipol > > ! > > !eps(ip,ip2) = (1.d0,0.d0)-(32.d0*pi/omega)*green(ip,ip2) > > ! > > WRITE(17,'(5x,"chi_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > ip2, ip, start, dble(green(ip,ip2)), aimag(green(ip,ip2)) > > > ! write(*,'(5x,"eps_",i1,"_",i1,"=",2x,3(e21.15,2x))') & > > ! ip2, ip, ry*omeg, dble(eps), aimag(eps) > > ! > > ENDDO > > ENDDO > > > What you need is "eps", but it is commented out. So just uncomment it here > and check in other places in this program and see what you obtain. Since this > is commented out, one has to be careful and check if the result is correct. I > do not know where the factor 32 comes from (one has to think). It was not me > who coded this. You may also check the literature how the dielectric matrix > is obtained from the susceptibility matrix (i.e. what are the prefactors). > > > HTH > > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > > From: users on behalf of Michal > Krompiec > Sent: Monday, April 20, 2020 10:27:29 PM > To: Quantum Espresso users Forum > Subject: [QE-users] dielectric function from turbo_lanczos > > Hello, > I'm trying to compare refractive index spectra calculated with epsilon.x and > TDDFpT with the turbo_lanczos code. My system is a periodic supercell, I am > using PBEsol functional, Gamma-only sampling and norm-conserving PPs. > > From the output of epsilon.x, I calculate refractive index n as follows: > n = > np.sqrt(np.sqrt(np.square(eps_real_iso)+np.square(eps_imag_iso)+eps_real_iso)) > # eps_real_iso and eps_imag_iso are averages of the spatial components of > real and imaginary epsilon > > Now, how do I convert the complex susceptibility chi (from the output of > turbo_lanczos) to epsilon? I know that in principle epsilon = 1 + chi, but > then the results don’t make sense. Am I missing some unit conversion or > something else? > Moreover, turbo_lanczos is complaining it hasn’t got enough information to > compute S - what could be the cause of this? > > Thanks, > Michal Krompiec > Merck KGaA > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] dielectric function from turbo_lanczos
Hello, I'm trying to compare refractive index spectra calculated with epsilon.x and TDDFpT with the turbo_lanczos code. My system is a periodic supercell, I am using PBEsol functional, Gamma-only sampling and norm-conserving PPs. >From the output of epsilon.x, I calculate refractive index n as follows: n = np.sqrt(np.sqrt(np.square(eps_real_iso)+np.square(eps_imag_iso)+eps_real_iso)) # eps_real_iso and eps_imag_iso are averages of the spatial components of real and imaginary epsilon Now, how do I convert the complex susceptibility chi (from the output of turbo_lanczos) to epsilon? I know that in principle epsilon = 1 + chi, but then the results don’t make sense. Am I missing some unit conversion or something else? Moreover, turbo_lanczos is complaining it hasn’t got enough information to compute S - what could be the cause of this? Thanks, Michal Krompiec Merck KGaA ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] GWL: wfc_gamma_real only for GAMMA
Hello, I'm trying to run a GWL calculation on a small (8-atom) cell of a semiconductor, with 10x10x10 k-point sampling. Following the tutorial (and example05), I ran the pw.x scf calculation, then head.x, then a gamma-only nscf calculation, then pw4gww.x. When running pw4gww.x, I'm getting this error: highest occupied, lowest unoccupied level (ev):26.4633 29.3232 MAX_NGM:6979 55515 BG1 1.03 0.000E+000 0.000E+000 BG2 0.000E+000 1.03 0.000E+000 BG3 0.000E+000 0.000E+000 1.03 V(G=0) = 0.594381373677151 wfc_gamma_real only for GAMMA It seems that gamma_only flag is set to .false. even though I have actually ran a gamma-only nscf calculation, and I can see the wavefunction file from it in the main calculation directory. I would be grateful for any advice. Best regards, Michal Krompiec Merck KGaA ___ 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] array index out of bounds error in gww.x
Problem solved, my build (Intel Parallel Studio 2020, xconfigure build script, latest ELPA) was the “culprit”. I switched to GCC 8.3 (also with ELPA and xconfigure, linked with the same Intel MPI and MKL 2020) and now it doesn’t crash anymore. Has anyone else experienced issues with Intel 2020? Oddly enough, all other parts of the QE distribution (well, at least those few I actually have used) seem to work fine for me when built with Intel 2020. Best, Michal ___ 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] array index out of bounds error in gww.x
... after changing max_i, i_min and i_max to the correct numbers, and using a simpler grid, I'm still getting the same error: forrtl: severe (154): array index out of bounds ggwin%prefix='s' ggwin%n=97, ggwin%grid_freq=5 ggwin%n_fit=120, ggwin%max_i=648, ggwin%i_min=270 ggwin%i_max=648 ggwin%l_truncated_coulomb=.true. ggwin%grid_time=3 ggwin%grid_freq=3 ggwin%second_grid_i=1 ggwin%second_grid_n=10 ggwin%omega=20 ggwin%omega_fit=20 ggwin%n_grid_fit=240 ggwin%tau=9.8 ggwin%n_set_pola=16 / Best, Michal Krompiec On Wed, 15 Apr 2020 at 18:48, Michal Krompiec wrote: > > Hello, > I'm trying to run GWL on a ~200-atom system (an insulator), starting > from a pw.x calculation with PBESOL and norm-conserving > pseudopotentials from pseudo dojo. Unfortunately, gww.x crashed > immediately after printing this to stdout (432nd band is the highest > occupied): > > Products in imaginary time: > Loop on KS: 432 1 > Fourier trasform: > Products in imaginary time: > > and the following to stderr: > forrtl: severe (154): array index out of bounds > Image PCRoutineLineSource > gww.x 04E5757B Unknown Unknown Unknown > > What could be the cause of this? Is it because my settings don't make > sense, or have I stumbled upon a bug? > > Some context: > My system has 864 valence electrons, so in pw.x scf calculation I have > nbnds = (864/2)*1.5 = 648, and I'm using Gamma point only (because > this is a supercell). Then I ran pw4gww.x with the following settings: > > prefix='s' > num_nbndv(1)=432 > num_nbnds=648 > l_truncated_coulomb=.true. > truncation_radius=20 > numw_prod=100 > pmat_cutoff=3d0 > s_self_lanczos=1d-8 > l_simple=.true. > / > So far so good. Then I ran gww.x with the following settings (and got > the error mentioned above): > > ggwin%prefix='s' > ggwin%n=97, > ggwin%n_fit=120, > ggwin%max_i=32, > ggwin%i_min=1 > ggwin%i_max=432 > ggwin%l_truncated_coulomb=.true. > ggwin%grid_time=3 > ggwin%grid_freq=5 > ggwin%second_grid_i=1 > ggwin%second_grid_n=10 > ggwin%omega=20 > ggwin%omega_fit=20 > ggwin%n_grid_fit=240 > / > > Thanks in advance, > Michal Krompiec > Merck KGaA ___ 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] safe to enable "k-point algorithm" in turbo_lanczos?
Dear Oleksandr, Dear Iurii,
Thank you very much, I understand that this code should rather stay
disabled. @Iurii: the motivation (or rather - hope) is that TDDFT (or
perhaps even epsilon.x) will give us the correct trend, whilst being
much cheaper than GW/BSE (which we are trying as well).
Best,
Michal
On Wed, 15 Apr 2020 at 18:39, Oleksandr Motornyi
wrote:
>
> Dear Michal,
>
>
> The k-points algorithm of turbo_lanczos.x as it is does not give the correct
> results if there is more than one single k-point. However you can look up the
> Lanczos implementation in the thermo_pw module, which works fine with
> k-points as far as I remember (of course bare in mind what Iurii said about
> Adiabatic TDDFT).
>
>
> Regards,
>
> Oleksandr
>
> On 15/04/2020 19:35, Timrov Iurii wrote:
>
> Dear Michal,
>
>
> The k-points implementation of turbo_lanczos.x was not tested and hence it is
> disabled. But most importantly, very likely there are bugs (I think I know a
> few). Someone has to work on it and fix bugs. But is there a motivation to do
> so? Adiabatic TDDFT with LDA/GGA is known to be not accurate for the optical
> absorption spectroscopy of solids.
>
>
> Greetings,
>
> Iurii
>
>
> --
> Dr. Iurii Timrov
> Postdoctoral Researcher
> STI - IMX - THEOS and NCCR - MARVEL
> Swiss Federal Institute of Technology Lausanne (EPFL)
> CH-1015 Lausanne, Switzerland
> +41 21 69 34 881
> http://people.epfl.ch/265334
>
> From: users on behalf of Michal
> Krompiec
> Sent: Wednesday, April 15, 2020 7:26:09 PM
> To: Quantum Espresso users Forum
> Subject: [QE-users] safe to enable "k-point algorithm" in turbo_lanczos?
>
> Hello,
> I'm trying to compute the spectrum of a crystalline insulator using
> turbo_lanczos. I got the following error:
>
> Error in routine lr_readin (1):
> k-point algorithm is not tested yet
>
>
>
> I guess I could just comment line 477 out in TDDFPT/src/lr_readin.f90
> to disable this error:
>
>! K-points are implemented but still unsupported (use at your own
> risk!)
>!
>IF (.NOT. gamma_only ) CALL errore('lr_readin', 'k-point
> algorithm is not tested yet',1)
>
> But how unstable is this code? Any reason not to try this?
>
> Thanks,
>
> Michal Krompiec
> Merck KGaA
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>
> --
> Oleksandr Motornyi
> PhD candidate
>
> Laboratoire de Solides Irradies
> Ecole Polytechnique (Palaiseau, France)
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] array index out of bounds error in gww.x
Hello, I'm trying to run GWL on a ~200-atom system (an insulator), starting from a pw.x calculation with PBESOL and norm-conserving pseudopotentials from pseudo dojo. Unfortunately, gww.x crashed immediately after printing this to stdout (432nd band is the highest occupied): Products in imaginary time: Loop on KS: 432 1 Fourier trasform: Products in imaginary time: and the following to stderr: forrtl: severe (154): array index out of bounds Image PCRoutineLineSource gww.x 04E5757B Unknown Unknown Unknown What could be the cause of this? Is it because my settings don't make sense, or have I stumbled upon a bug? Some context: My system has 864 valence electrons, so in pw.x scf calculation I have nbnds = (864/2)*1.5 = 648, and I'm using Gamma point only (because this is a supercell). Then I ran pw4gww.x with the following settings: prefix='s' num_nbndv(1)=432 num_nbnds=648 l_truncated_coulomb=.true. truncation_radius=20 numw_prod=100 pmat_cutoff=3d0 s_self_lanczos=1d-8 l_simple=.true. / So far so good. Then I ran gww.x with the following settings (and got the error mentioned above): ggwin%prefix='s' ggwin%n=97, ggwin%n_fit=120, ggwin%max_i=32, ggwin%i_min=1 ggwin%i_max=432 ggwin%l_truncated_coulomb=.true. ggwin%grid_time=3 ggwin%grid_freq=5 ggwin%second_grid_i=1 ggwin%second_grid_n=10 ggwin%omega=20 ggwin%omega_fit=20 ggwin%n_grid_fit=240 / Thanks in advance, Michal Krompiec Merck KGaA ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] safe to enable "k-point algorithm" in turbo_lanczos?
Hello,
I'm trying to compute the spectrum of a crystalline insulator using
turbo_lanczos. I got the following error:
Error in routine lr_readin (1):
k-point algorithm is not tested yet
I guess I could just comment line 477 out in TDDFPT/src/lr_readin.f90
to disable this error:
! K-points are implemented but still unsupported (use at your own risk!)
!
IF (.NOT. gamma_only ) CALL errore('lr_readin', 'k-point
algorithm is not tested yet',1)
But how unstable is this code? Any reason not to try this?
Thanks,
Michal Krompiec
Merck KGaA
___
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] growing string method?
In case anybody else looks for it: Zimmerman's Growing String Method is interfaced with ASE. Their examples use VASP as the compute engine, but changing it to QE would be trivial. https://sites.lsa.umich.edu/zimmerman-lab/tutorial/surface-growing-string-method/ Best, Michal On Tue, 7 Apr 2020 at 11:23, Michal Krompiec wrote: > > Hello, > > Does anyone know of a Growing String Method code interfaced to QE? > > Regards, > Michal Krompiec > Merck KGaA ___ 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] epsilon.x and hybrids
Dear Iurii, thank you very much for the explanation and for the references. Best, Michal On Wed, 8 Apr 2020 at 21:09, Timrov Iurii wrote: > Dear Michal, > > > > BTW would you say that for calculation of the dielectric function of > not-so-large (whatever this means...) periodic systems it is better to try > GW with the GWW code instead? > > > I am not familiar with GWW, but as far as I know it can be used only with > a gamma point (k=0). I do not know what are other limitations, and whether > you can apply it to compute optimal absorption spectra in solids. You may > contact the developer Paolo Umari. > > > > Is it why TDDFT with hybrids for periodic systems is missing in QE - > because GW is better and tractable so why bother with TDDFT? > > > It is a long story, but let me write briefly what I know (please correct > me if I am wrong). I suggest to check the literature on this topic. > > > GW+BSE is the standard approach to compute optical absorption spectra in > periodic systems (semiconductors). This is so because the non-local > interactions are present, and because the dielectric function (r-dependent > and w-dependent) is present in the formalism which describes the > dielectric properties of the periodic system. > > > TDDFT in the adiabatic approximation with local/semilocal functionals > (like LDA/GGA) is not accurate for a description of optical absorption > spectra of periodic solids (please check the literature). However, TDDFT > with non-local functionals is an interesting alternative to GW+BSE. > TDDFT@PBE0 improves considerably w.r.t TDDFT@PBE, but still with just a > constant (alpha=0.25) in the EXX part it is hard to do a descent job for > solids (actually alpha is related to 1/epsilon : Phys. Rev. B 89, 195112 > (2014)). Much better is to use TDDFT in combination with rage-separated > hybrid functionals, where 1/epsilon is not just a constant but a function > 1/epsilon(r) (with models for epsilon(r)), which better represents the > dielectric properties of the solid (Phys. Rev. B 93, 235106 (2016), check > in particular the introduction in this reference about the history of > various non-local XC kernels). > > > Greetings, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > -- > *From:* users on behalf of > Michal Krompiec > *Sent:* Wednesday, April 8, 2020 9:40:01 PM > > *To:* Quantum ESPRESSO users Forum > *Subject:* Re: [QE-users] epsilon.x and hybrids > > BTW would you say that for calculation of the dielectric function of > not-so-large (whatever this means...) periodic systems it is better to try > GW with the GWW code instead? Is it why TDDFT with hybrids for periodic > systems is missing in QE - because GW is better and tractable so why bother > with TDDFT? > Best, > Michal > > On Wed, Apr 8, 2020 at 19:15 Timrov Iurii wrote: > >> Dear All, >> >> >> > Do I remember correctly that epsilon.x also does not take into account >> the nonlocal pseudopotential contribution? >> >> >> Correct >> >> >> > ...there used to be an option in the turbo_davidson.x and >> turbo_lanczos.x codes, namely no_hxc=.true., which permits an >> independent-electron calculation. >> >> >> Correct. By default, the matrix element of the dipole operator is >> computed (in reciprocal space) via the matrix element of the commutator >> that Paolo mentioned [H,x] (see Eq.(14) in S. Baroni and R. Resta, Phys. >> Rev. B 33, 7017 (1986)): but in this case there is a kinetic term and the >> part coming from the non-local part of a pseudopotential. In epsilon.x, >> only the kinetic term is present, while in TDDFT codes both terms are >> present (the second term was implement long ago in the Phonon code to >> compute the dielectric tensor). But still, in the case of hybrid >> functionals, in [H,x] there is another term which is missing - the >> commutator with another non-local potential which is EXX. Stefano Baroni >> and I developed a way how to compute this missing term several years ago: I >> implemented it in QE and it worked well, but I never had time to release it >> and publish some paper about it. But there is a workaround for finite >> systems: the matrix element of the dipole operator can be computed in real >> space based on the observation that the charge density of the finite system >> decays fast outside the finite system, and hence the non-periodicity >> p
Re: [QE-users] epsilon.x and hybrids
BTW would you say that for calculation of the dielectric function of not-so-large (whatever this means...) periodic systems it is better to try GW with the GWW code instead? Is it why TDDFT with hybrids for periodic systems is missing in QE - because GW is better and tractable so why bother with TDDFT? Best, Michal On Wed, Apr 8, 2020 at 19:15 Timrov Iurii wrote: > Dear All, > > > > Do I remember correctly that epsilon.x also does not take into account > the nonlocal pseudopotential contribution? > > > Correct > > > > ...there used to be an option in the turbo_davidson.x and > turbo_lanczos.x codes, namely no_hxc=.true., which permits an > independent-electron calculation. > > > Correct. By default, the matrix element of the dipole operator is computed > (in reciprocal space) via the matrix element of the commutator that Paolo > mentioned [H,x] (see Eq.(14) in S. Baroni and R. Resta, Phys. Rev. B 33, > 7017 (1986)): but in this case there is a kinetic term and the part coming > from the non-local part of a pseudopotential. In epsilon.x, only the > kinetic term is present, while in TDDFT codes both terms are present (the > second term was implement long ago in the Phonon code to compute the > dielectric tensor). But still, in the case of hybrid functionals, in [H,x] > there is another term which is missing - the commutator with another > non-local potential which is EXX. Stefano Baroni and I developed a way how > to compute this missing term several years ago: I implemented it in QE and > it worked well, but I never had time to release it and publish some paper > about it. But there is a workaround for finite systems: the matrix element > of the dipole operator can be computed in real space based on the > observation that the charge density of the finite system decays fast > outside the finite system, and hence the non-periodicity problem of the > dipole operator is no longer a problem. But this trick in real space is not > gonna work for periodic systems, because the charge density if non-zero in > the whole simulation cell. Thus, the only way to overcome this problem is > to implement the missing term for hybrids in [H,x]. > > > Greetings, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > -- > *From:* users on behalf of > Giuseppe Mattioli > *Sent:* Wednesday, April 8, 2020 7:42:35 PM > *To:* Quantum ESPRESSO users Forum > *Subject:* Re: [QE-users] epsilon.x and hybrids > > > Dear all > I don't want to raise the confusion level, so please correct me if I'm > wrong... If you want to calculate a heavily approximate absorption > spectrum of a (large and non-symmetrical) periodic system after a > ground state hybrid calculation, there used to be an option in the > turbo_davidson.x and turbo_lanczos.x codes, namely no_hxc=.true., > which permits an independent-electron calculation. At least, hybrid > functionals and Gamma ground states should be properly treated by such > codes, resulting in an absorption spectrum compatible with those > obtained by using epsilon.x, which, AFAIK, calculates > contributions to the absorption spectrum. > However, I don't know how much this kind of calculation is expensive > for large supercells. Of course if you are not interested in > absorption, then my suggestion is nonsense... > HTH > Giuseppe > > Quoting Lorenzo Paulatto : > > > Also, epsilon.x cannot use symmetry-reduced grids, which would be a > > huge wast of time with hybrids, but you can use open_grid.x after > > the pw.x calculation too obtain the full grid and work around this > > problem. > > > > cheers > > > > On 4/8/20 6:38 PM, Paolo Giannozzi wrote: > >> I think epsilon.x assumes that the dipole element of x can be > >> computed using [H,x]=p\hbar/m. The exchange potential is nonlocal, > >> so its commutator with x will yield an additional term that is not > >> accounted for. Not sure how important it is in practice. Do I > >> remember correctly that epsilon.x also does not take into account > >> the nonlocal pseudopotential contribution? > >> > >> Paolo > >> > >> On Wed, Apr 8, 2020 at 4:29 PM Manu Hegde >> <mailto:mhe...@sfu.ca >> wrote: > >> > >>Hi Michal, > >>Yes, it is possible.I did use both supercell and hybrid > >>calculations. It did work. > >>Manu > >> > >>On Wed, Apr 8, 2020 at 10:08 AM Michal Krompiec >
Re: [QE-users] epsilon.x and hybrids
Dear All, Thank you very much, this explains that it can't be done for my system and closes the case for now :(. It would be great if someone implemented the missing term for hybrids in [H,x]. Best, Michal On Wed, 8 Apr 2020 at 19:15, Timrov Iurii wrote: > > Dear All, > > > > Do I remember correctly that epsilon.x also does not take into account the > > nonlocal pseudopotential contribution? > > > Correct > > > > ...there used to be an option in the turbo_davidson.x and turbo_lanczos.x > > codes, namely no_hxc=.true., which permits an independent-electron > > calculation. > > > Correct. By default, the matrix element of the dipole operator is computed > (in reciprocal space) via the matrix element of the commutator that Paolo > mentioned [H,x] (see Eq.(14) in S. Baroni and R. Resta, Phys. Rev. B 33, 7017 > (1986)): but in this case there is a kinetic term and the part coming from > the non-local part of a pseudopotential. In epsilon.x, only the kinetic term > is present, while in TDDFT codes both terms are present (the second term was > implement long ago in the Phonon code to compute the dielectric tensor). But > still, in the case of hybrid functionals, in [H,x] there is another term > which is missing - the commutator with another non-local potential which is > EXX. Stefano Baroni and I developed a way how to compute this missing term > several years ago: I implemented it in QE and it worked well, but I never had > time to release it and publish some paper about it. But there is a workaround > for finite systems: the matrix element of the dipole operator can be comput ed in re al space based on the observation that the charge density of the finite system decays fast outside the finite system, and hence the non-periodicity problem of the dipole operator is no longer a problem. But this trick in real space is not gonna work for periodic systems, because the charge density if non-zero in the whole simulation cell. Thus, the only way to overcome this problem is to implement the missing term for hybrids in [H,x]. > > > Greetings, > > Iurii > > > -- > Dr. Iurii Timrov > Postdoctoral Researcher > STI - IMX - THEOS and NCCR - MARVEL > Swiss Federal Institute of Technology Lausanne (EPFL) > CH-1015 Lausanne, Switzerland > +41 21 69 34 881 > http://people.epfl.ch/265334 > > From: users on behalf of Giuseppe > Mattioli > Sent: Wednesday, April 8, 2020 7:42:35 PM > To: Quantum ESPRESSO users Forum > Subject: Re: [QE-users] epsilon.x and hybrids > > > Dear all > I don't want to raise the confusion level, so please correct me if I'm > wrong... If you want to calculate a heavily approximate absorption > spectrum of a (large and non-symmetrical) periodic system after a > ground state hybrid calculation, there used to be an option in the > turbo_davidson.x and turbo_lanczos.x codes, namely no_hxc=.true., > which permits an independent-electron calculation. At least, hybrid > functionals and Gamma ground states should be properly treated by such > codes, resulting in an absorption spectrum compatible with those > obtained by using epsilon.x, which, AFAIK, calculates > contributions to the absorption spectrum. > However, I don't know how much this kind of calculation is expensive > for large supercells. Of course if you are not interested in > absorption, then my suggestion is nonsense... > HTH > Giuseppe > > Quoting Lorenzo Paulatto : > > > Also, epsilon.x cannot use symmetry-reduced grids, which would be a > > huge wast of time with hybrids, but you can use open_grid.x after > > the pw.x calculation too obtain the full grid and work around this > > problem. > > > > cheers > > > > On 4/8/20 6:38 PM, Paolo Giannozzi wrote: > >> I think epsilon.x assumes that the dipole element of x can be > >> computed using [H,x]=p\hbar/m. The exchange potential is nonlocal, > >> so its commutator with x will yield an additional term that is not > >> accounted for. Not sure how important it is in practice. Do I > >> remember correctly that epsilon.x also does not take into account > >> the nonlocal pseudopotential contribution? > >> > >> Paolo > >> > >> On Wed, Apr 8, 2020 at 4:29 PM Manu Hegde >> <mailto:mhe...@sfu.ca>> wrote: > >> > >>Hi Michal, > >>Yes, it is possible.I did use both supercell and hybrid > >>calculations. It did work. > >>Manu > >> > >>On Wed, Apr 8, 2020 at 10:08 AM Michal Krompiec > >>mailto:michal.kromp...@gmail.com>> wrote: > >> > >>Hello, > >
[QE-users] epsilon.x and hybrids
Hello, Is it possible to use epsilon.x on results of a calculation with a hybrid functional (supercell, gamma point only)? Thanks, Michal Krompiec Merck KGaA ___ 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] turbo_davidson/turbo_lanczos and hybrids, periodic systems
Dear Oscar, Thank you. So I guess for optical properties of periodic systems, there are only two options: epsilon.x or “going hardcore” with GW and BSE. Regards, Michal On Tue, Apr 7, 2020 at 14:58 Oscar Baseggio wrote: > Dear Michal, > > turbo_lanczos is limited for gamma calculation, so you can't use this > for periodic ssystems. > Only turbo_eels.x works with periodic systems. > > best regards, > > Oscar Baseggio > > > > > Il 2020-04-07 15:54 Michal Krompiec ha scritto: > > Hello, > > Is it possible to calculate optical properties of periodic solids with > > TDDFpT using hybrid functionals? The documentation of d0psi_rs option > > of turbo_lanczos seems to say "no", could someone confirm this? > > Thanks, > > Michal Krompiec > > Merck KGaA > > ___ > > Quantum ESPRESSO is supported by MaX > > (www.max-centre.eu/quantum-espresso) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users > > ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] turbo_davidson/turbo_lanczos and hybrids, periodic systems
Hello, Is it possible to calculate optical properties of periodic solids with TDDFpT using hybrid functionals? The documentation of d0psi_rs option of turbo_lanczos seems to say "no", could someone confirm this? Thanks, Michal Krompiec Merck KGaA ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] growing string method?
Hello, Does anyone know of a Growing String Method code interfaced to QE? Regards, Michal Krompiec Merck KGaA ___ 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] recommended methods for slab calculations
Dear Giuseppe, Thank you! Best, Michal On Fri, 3 Apr 2020 at 12:00, Giuseppe Mattioli wrote: > > > Dear Michal > I'm a fan of esm. If you want to study the adsorption of molecules > inducing a strong vertical dipole you are forced to decouple such > dipole along the z direction of the cell, otherwise you experiment an > horrible "capacitor effect" on the potential curve. To use esm='bc1' > (a vacuum-slab-vacuum geometry) you need to confine the electronic > density of your system (the density, not the atoms...) between -l/4 > and l/4 (you can shift the 0 of the cell if you don't want to shift > the atoms), where l is the z edge of your supercell. I don't know if > you consider this as an "enormous vacuum padding"... > > Moreover, esm produces "for free" a very useful file (in the TMP_DIR), > namely prefix.esm1, where at the end of each scf iteration useful > quantities are plotted, such as the electrostatic potential and the > charge density integrated on x,y planes. You may want to have a look > to this recent paper (J. Phys. Chem. C 2020, 124, 3601) to see what > you can do with such data (e.g., calculate changes in the surface > workfunction upon the adsorption of polar molecules). > > Finally, during the first scf iteration you may experiment a bit of > instability, but it is generally not a dramatic problem... > > HTH > Giuseppe > > > Quoting Michal Krompiec : > > > Hello, > > I was wondering which assume_isolated method is the preferred choice > > for calculation of adsorption energies of small molecules on 2D slabs > > of metals and oxides. > > So far, I've been using assume_isolated='2d', but it requires an > > enormous vacuum padding. Is esm less resource-hungry? Does anyone use > > a less accurate scheme first (e.g. no "assume_isolated" and a small > > vacuum padding) and moves later to the target large cell with > > assume_isolated=2d? > > I understand that it all depends on the system, and that a convergence > > test has to be done anyway, but I would be grateful for any tips. > > > > Thanks, > > Michal Krompiec > > Merck KGaA > > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users > > > > GIUSEPPE MATTIOLI > CNR - ISTITUTO DI STRUTTURA DELLA MATERIA > Via Salaria Km 29,300 - C.P. 10 > I-00015 - Monterotondo Scalo (RM) > Mob (*preferred*) +39 373 7305625 > Tel + 39 06 90672342 - Fax +39 06 90672316 > E-mail: > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] recommended methods for slab calculations
Hello, I was wondering which assume_isolated method is the preferred choice for calculation of adsorption energies of small molecules on 2D slabs of metals and oxides. So far, I've been using assume_isolated='2d', but it requires an enormous vacuum padding. Is esm less resource-hungry? Does anyone use a less accurate scheme first (e.g. no "assume_isolated" and a small vacuum padding) and moves later to the target large cell with assume_isolated=2d? I understand that it all depends on the system, and that a convergence test has to be done anyway, but I would be grateful for any tips. Thanks, Michal Krompiec Merck KGaA ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] recommended math libraries, ELPA and XCONFIGURE
Hello, What is the recommended math library to link to, for highest performance, on a Intel-based HPC? Is it still ELPA (2017? 2019?), built with the XCONFIGURE scripts? Does anyone have experience with building QE+ELPA with gcc using XCONFIGURE scripts? Thanks in advance, Michal Krompiec Merck KGaA, Darmstadt, Germany and University of Southampton, UK ___ 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] Adsorbate: k-points and smearing
Thank you! MK On Sun, 14 Jul 2019 at 16:06, Marzari Nicola wrote: > Same smearing, gamma sampling. This should be identical to same smearing > and same kpoint mesh. Check also no smearing - it’s there for the metal > states, but in case your adsorbate has several levels around the homo or > lumo would be safer to keep the smearing. > > Nicola > > Sent from a tiny keyboard... Contact info: > http://theossrv1.epfl.ch/Main/Contact > > > On 14 Jul 2019, at 17:49, Michal Krompiec > wrote: > > > > Hello, > > I’m calculating adsorption energies of organic molecules on metal > surfaces. Should I use the same k-point mesh and smearing for the adsorbate > as for the slab calculations (bare metal surface and metal+adsorbate)? Or > rather just gamma point and no smearing because it is the only sensible > choice for a closed-shell molecule? > > Thanks, > > Michal Krompiec > > Merck KGaA > > > > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso > ) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] Adsorbate: k-points and smearing
Hello, I’m calculating adsorption energies of organic molecules on metal surfaces. Should I use the same k-point mesh and smearing for the adsorbate as for the slab calculations (bare metal surface and metal+adsorbate)? Or rather just gamma point and no smearing because it is the only sensible choice for a closed-shell molecule? Thanks, Michal Krompiec Merck KGaA ___ 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] Bad scaling on GPU version QE
Dear Milos, Thank you. This definitely helps us make an informed decision. Best, Michal On Wed, 10 Jul 2019 at 08:28, Milos Maric wrote: > Dear Michal, > > > > I run benchmarks on 2x Intel Xeon E5-2698 v4 and 2x Intel E5-2698 v4 + 4x > Nvidia V100 16GB SMX2 (DGX-1V 16GB with only four GPUs enabled). > > > > Depending on the benchmark I normally see 6x to 11x speedup. > > > > Best regards, > > Miloš > > > > *From:* users *On Behalf Of *Michal > Krompiec > *Sent:* Tuesday, July 9, 2019 9:12 PM > *To:* Quantum ESPRESSO users Forum > *Subject:* Re: [QE-users] Bad scaling on GPU version QE > > > > Dear Pietro, > > Thank you very much. Is this implementation restricted to Nvidia GPUs? > > Best regards, > > Michal > > > > On Tue, 9 Jul 2019 at 19:14, Pietro BONFA' wrote: > > Dear Michal, > > I will hopefully be able to share some new benchmarking results in the > wiki soon, but for the time being the most accurate estimate is in this > presentation: > > https://on-demand.gputechconf.com/gtc-eu/2018/pdf/e8340-porting-quantum-espresso-to-gpu-accelerated-systems.pdf > . > > In the slides above you will find a comparison between v6.1 and v6.3. > Depending on the problem size and on the type of simulation, v6.1 can be > substantially faster. > > Our plan is to close the gap with the future releases, since the > difference mainly comes from partially implemented features (for > example, charge density mixing, exchange and correlation, forces and > stress are accelerated in v6.1 but not in v6.4). This, however, must be > done with care in order to keep the GPU development sustainable. > > Hope this helps, > kind regards, > Pietro Bonfa' > > > > On 7/8/19 10:27 PM, Michal Krompiec wrote: > > Dear Pietro, > > What is the typical speed up vs a cpu-only system? Is this > > https://www.dcs.warwick.ac.uk/pmbs/pmbs17/PMBS17/pres/paper3.pdf still > > valid? Can you share any benchmarks on V100? > > Best, > > Michal Krompiec > > Merck KGaA, Darmstadt, Germany > > > > On Mon, 8 Jul 2019 at 20:29, Pietro BONFA' > <mailto:pietro.bo...@unipr.it>> wrote: > > > > Dear Jing, > > > > good point, I'll add the list of accelerated features in the wiki. In > > the mean time you can check page 21 of the first presentation that > you > > can find here: https://gitlab.com/QEF/q-e-gpu/wikis/home#performance > > > > Exact exchange will come with the next release but you can already > try > > it by compiling this develop branch: > > https://gitlab.com/QEF/q-e-gpu/tree/gpu-exx > > > > Kind regards, > > Pietro Bonfa' > > > > On 7/8/19 8:33 PM, JING YANG wrote: > > > I am working on the latest version 6.4-a1. I have followed the > > > instructions on the link you provided during the installation. I > > would > > > like to know which part of the calculation in pw being > accelerated by > > > GPU. For example, is it boosting the matrix diagonalization > > during scf > > > cycles, or boosting the hybrid functional calculations? I am > > hoping to > > > GPU acceleration can boost up the calculation on the exact > > exchange in > > > hybrid functional calculations. Is this the case? > > > > > > Thanks, > > > Jing > > > > > > On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA' > > mailto:pietro.bo...@unipr.it> > > > <mailto:pietro.bo...@unipr.it <mailto:pietro.bo...@unipr.it>>> > wrote: > > > > > > Dear Jing, > > > > > > which GPU-enabled version are you using? > > > GPU support starting from v6.1 is only available when using > PGI > > > compilers (well, in principle, any compiler implementing CUDA > > Fortran). > > > > > > You can find additional information here: > > > > > > https://gitlab.com/QEF/q-e-gpu/wikis/home > > > > > > Kinds regards, > > > Pietro Bonfa' > > > > > > On 7/8/19 5:01 PM, JING YANG wrote: > > > > Hi, > > > > I am trying to test the scaling of GPU version of QE > > recently. I > > > > found out the computational time scaling of the GPU > version is > > > very bad. > > > > Is there any unique flags or keywords I don
Re: [QE-users] Bad scaling on GPU version QE
Dear Pietro, Thank you very much. Is this implementation restricted to Nvidia GPUs? Best regards, Michal On Tue, 9 Jul 2019 at 19:14, Pietro BONFA' wrote: > Dear Michal, > > I will hopefully be able to share some new benchmarking results in the > wiki soon, but for the time being the most accurate estimate is in this > presentation: > > https://on-demand.gputechconf.com/gtc-eu/2018/pdf/e8340-porting-quantum-espresso-to-gpu-accelerated-systems.pdf > . > > In the slides above you will find a comparison between v6.1 and v6.3. > Depending on the problem size and on the type of simulation, v6.1 can be > substantially faster. > > Our plan is to close the gap with the future releases, since the > difference mainly comes from partially implemented features (for > example, charge density mixing, exchange and correlation, forces and > stress are accelerated in v6.1 but not in v6.4). This, however, must be > done with care in order to keep the GPU development sustainable. > > Hope this helps, > kind regards, > Pietro Bonfa' > > > > On 7/8/19 10:27 PM, Michal Krompiec wrote: > > Dear Pietro, > > What is the typical speed up vs a cpu-only system? Is this > > https://www.dcs.warwick.ac.uk/pmbs/pmbs17/PMBS17/pres/paper3.pdf still > > valid? Can you share any benchmarks on V100? > > Best, > > Michal Krompiec > > Merck KGaA, Darmstadt, Germany > > > > On Mon, 8 Jul 2019 at 20:29, Pietro BONFA' > <mailto:pietro.bo...@unipr.it>> wrote: > > > > Dear Jing, > > > > good point, I'll add the list of accelerated features in the wiki. In > > the mean time you can check page 21 of the first presentation that > you > > can find here: https://gitlab.com/QEF/q-e-gpu/wikis/home#performance > > > > Exact exchange will come with the next release but you can already > try > > it by compiling this develop branch: > > https://gitlab.com/QEF/q-e-gpu/tree/gpu-exx > > > > Kind regards, > > Pietro Bonfa' > > > > On 7/8/19 8:33 PM, JING YANG wrote: > > > I am working on the latest version 6.4-a1. I have followed the > > > instructions on the link you provided during the installation. I > > would > > > like to know which part of the calculation in pw being > accelerated by > > > GPU. For example, is it boosting the matrix diagonalization > > during scf > > > cycles, or boosting the hybrid functional calculations? I am > > hoping to > > > GPU acceleration can boost up the calculation on the exact > > exchange in > > > hybrid functional calculations. Is this the case? > > > > > > Thanks, > > > Jing > > > > > > On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA' > > mailto:pietro.bo...@unipr.it> > > > <mailto:pietro.bo...@unipr.it <mailto:pietro.bo...@unipr.it>>> > wrote: > > > > > > Dear Jing, > > > > > > which GPU-enabled version are you using? > > > GPU support starting from v6.1 is only available when using > PGI > > > compilers (well, in principle, any compiler implementing CUDA > > Fortran). > > > > > > You can find additional information here: > > > > > > https://gitlab.com/QEF/q-e-gpu/wikis/home > > > > > > Kinds regards, > > > Pietro Bonfa' > > > > > > On 7/8/19 5:01 PM, JING YANG wrote: > > > > Hi, > > > > I am trying to test the scaling of GPU version of QE > > recently. I > > > > found out the computational time scaling of the GPU > version is > > > very bad. > > > > Is there any unique flags or keywords I don't know about > > the GPU > > > > version? I am using gcc-6.2.0, openmpi-1/8/4, > > > craype-accel-nvidia35. I > > > > know it is not the recommended set up, but I guess if I can > > > compile it > > > > successfully, then it should work normally. > > > > > > > > Thanks, > > > > Jing > > > > > > > > ___ > > > > Quantum ESPRESSO is supported by MaX > > > (www.max-centre.eu/quantum-espresso > > <http://www.max-centre.eu/
Re: [QE-users] segfault with HSE06
Hi Fabrizio, Thanks. Do you mean replacing this: (lines 466-475) IF(DoLoc) then !$omp parallel do collapse(3) default(shared) firstprivate(npol,nrxxs,nkqs,ibnd_buff_start,ibnd_buff_end) private(ir,ibnd,ikq,ipol) DO ikq=1,SIZE(locbuff,3) DO ibnd=1, x_nbnd_occ DO ir=1,nrxxs*npol locbuff(ir,ibnd,ikq)=0.0_DP ENDDO ENDDO ENDDO ELSE with the following: IF(DoLoc) then IF(gamma_only) then !$omp parallel do collapse(3) default(shared) firstprivate(npol,nrxxs,nkqs,ibnd_buff_start,ibnd_buff_end) private(ir,ibnd,ikq,ipol) DO ikq=1,SIZE(locbuff,3) DO ibnd=1, x_nbnd_occ DO ir=1,nrxxs*npol locbuff(ir,ibnd,ikq)=0.0_DP ENDDO ENDDO ENDDO END IF ELSE ? On Tue, 9 Jul 2019 at 11:37, Fabrizio Ferrari wrote: > Hello, > if you put the loop at line 467 of PW/src/exx.f90 inside an > 'IF(gamma_only)', the segfault should disappear. I'm just checking if that > is the only fix needed. > > Fabrizio > > On Tue, Jul 9, 2019 at 12:27 PM Michal Krompiec > wrote: > >> I got a similar segfault using a fresh installation of QE 6.4.1, on a >> different HPC, this time with Intel 2018 compilers and ELPA, with the same >> input file and pseudos (SG15) as previously. >> I noticed that my molecule is a bit too high in the simulation cell (vs. >> the potential added by assume_isolated), but increasing the size of the >> cell in the Z direction changed nothing. >> Switching off assume_isolated also didn't help. >> >> from stdout: >> >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> Image PCRoutineLineSource >> pw.x 056A6D8D Unknown Unknown >> Unknown >> libpthread-2.17.s 2AC70727E5E0 Unknown Unknown >> Unknown >> pw.x 005B3618 Unknown Unknown >> Unknown >> pw.x 005AE060 Unknown Unknown >> Unknown >> pw.x 0040ADFD Unknown Unknown >> Unknown >> pw.x 0059D83D Unknown Unknown >> Unknown >> pw.x 004086C9 Unknown Unknown >> Unknown >> pw.x 0040851E Unknown Unknown >> Unknown >> libc-2.17.so 2AC7077AEC05 __libc_start_main Unknown >> Unknown >> pw.x 00408429 Unknown Unknown >> Unknown >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> >> Last few lines of the log file: >> >> convergence has been achieved in 9 iterations >> >> Using localization algorithm with threshold: 0.50D-02 >> >> Using ACE for calculation of exact exchange >> >> EXX grid: 1427071 G-vectors FFT dimensions: ( 90, 90, 375) >> >> NBands = 15 nks =1 nkqs =9 >> Canonical Orbitals >> >> Any suggestions? >> >> Thanks, >> Michal >> >> >> On Mon, 8 Jul 2019 at 13:27, Michal Krompiec >> wrote: >> >>> Hello, >>> I'm getting a segmentation fault when trying to run a HSE06 SCF >>> calculation in QE 6.4rc (built with gcc and OpenMPI). I got the same result >>> regardless of number of OMP threads (1-2) or MPI processes, it is also not >>> because I'm running out of memory. Increasing OMP_STACK_SIZE didn't help. >>> I'm using SG15 norm-conserving pseudopotentials. >>> This is the error message: >>> >>> Program received signal SIGSEGV: Segmentation fault - invalid memory >>> reference. >>> >>> Backtrace for this error: >>> >>> Backtrace for this error: >>> #0 0x2ba41caf6607 in ??? >>> #1 0x2ba41caf586d in ??? >>> #2 0x2ba41d9d5fdf in ??? >>> #1 0x2ba41caf586d in ??? >>> #2 0x2ba41d9d5fdf in ??? >>> #3 0x481031 in __exx_MOD_exxinit._omp_fn.41 >>> at >>> /home/hpcadmin/Cluster-packages/Apps/QE/q-e-qe-6.4-rc/PW/src/exx.f90:471 >>> >>> >>> And this is the input file: >>> >>>nstep= 150 >>>prefix = 'pz' >>>calculation = 'scf' >>> / >>> >>>ecutwfc = 60 >>>ecutrho = 240 >>>occupations = 'smearing' >>>degauss = 0.03 >>>smearing = 'marzari-vanderbilt' >>>assu
Re: [QE-users] segfault with HSE06
I got a similar segfault using a fresh installation of QE 6.4.1, on a different HPC, this time with Intel 2018 compilers and ELPA, with the same input file and pseudos (SG15) as previously. I noticed that my molecule is a bit too high in the simulation cell (vs. the potential added by assume_isolated), but increasing the size of the cell in the Z direction changed nothing. Switching off assume_isolated also didn't help. from stdout: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource pw.x 056A6D8D Unknown Unknown Unknown libpthread-2.17.s 2AC70727E5E0 Unknown Unknown Unknown pw.x 005B3618 Unknown Unknown Unknown pw.x 005AE060 Unknown Unknown Unknown pw.x 0040ADFD Unknown Unknown Unknown pw.x 0059D83D Unknown Unknown Unknown pw.x 004086C9 Unknown Unknown Unknown pw.x 0040851E Unknown Unknown Unknown libc-2.17.so 2AC7077AEC05 __libc_start_main Unknown Unknown pw.x 00408429 Unknown Unknown Unknown forrtl: severe (174): SIGSEGV, segmentation fault occurred Last few lines of the log file: convergence has been achieved in 9 iterations Using localization algorithm with threshold: 0.50D-02 Using ACE for calculation of exact exchange EXX grid: 1427071 G-vectors FFT dimensions: ( 90, 90, 375) NBands = 15 nks =1 nkqs =9 Canonical Orbitals Any suggestions? Thanks, Michal On Mon, 8 Jul 2019 at 13:27, Michal Krompiec wrote: > Hello, > I'm getting a segmentation fault when trying to run a HSE06 SCF > calculation in QE 6.4rc (built with gcc and OpenMPI). I got the same result > regardless of number of OMP threads (1-2) or MPI processes, it is also not > because I'm running out of memory. Increasing OMP_STACK_SIZE didn't help. > I'm using SG15 norm-conserving pseudopotentials. > This is the error message: > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > > Backtrace for this error: > #0 0x2ba41caf6607 in ??? > #1 0x2ba41caf586d in ??? > #2 0x2ba41d9d5fdf in ??? > #1 0x2ba41caf586d in ??? > #2 0x2ba41d9d5fdf in ??? > #3 0x481031 in __exx_MOD_exxinit._omp_fn.41 > at > /home/hpcadmin/Cluster-packages/Apps/QE/q-e-qe-6.4-rc/PW/src/exx.f90:471 > > > And this is the input file: > >nstep= 150 >prefix = 'pz' >calculation = 'scf' > / > >ecutwfc = 60 >ecutrho = 240 >occupations = 'smearing' >degauss = 0.03 >smearing = 'marzari-vanderbilt' >assume_isolated = '2D' >ntyp = 3 >nat = 10 >ibrav= 0 >vdw_corr='dft-d3' >nosym = .true. >input_dft = 'hse' >localization_thr = 0.005 > > / > > electron_maxstep = 1000 > mixing_mode = 'plain' > mixing_beta = 0.3 > mixing_ndim = 10 > / > > ion_dynamics = 'bfgs' > / > > ATOMIC_SPECIES > H 1 H_ONCV_PBE-1.0.upf > C 12 C_ONCV_PBE-1.0.upf > N 14 N_ONCV_PBE-1.0.upf > > K_POINTS automatic > 3 3 1 0 0 0 > > CELL_PARAMETERS angstrom > 9.45 0.00 0.0 > 0.00 8.90954544295050 0.0 > 0.00 0.00 40.0 > > ATOMIC_POSITIONS angstrom > N3.220157348 4.070243213 7.161850862 > C2.057591707 4.250681378 7.817575738 > C4.333273229 4.171146830 7.913403134 > C2.009345068 4.525337360 9.193044239 > C4.285082283 4.446195607 9.288766365 > N3.122476937 4.626559339 9.944547282 > H1.139008253 4.174089393 7.227702259 > H5.290517910 4.028527369 7.402554504 > H 1.052120461 4.668162403 9.703968061 > H5.203598139 4.523590493 9.878655120 > > > I would be grateful for any suggestions. In the meantime, we are upgrading > to 6.4.1 to see if this helps. > > Best regards, > > Michal Krompiec > > Merck KGaA, Darmstadt, Germany & University of Southampton > ___ 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] Bad scaling on GPU version QE
Dear Pietro, What is the typical speed up vs a cpu-only system? Is this https://www.dcs.warwick.ac.uk/pmbs/pmbs17/PMBS17/pres/paper3.pdf still valid? Can you share any benchmarks on V100? Best, Michal Krompiec Merck KGaA, Darmstadt, Germany On Mon, 8 Jul 2019 at 20:29, Pietro BONFA' wrote: > Dear Jing, > > good point, I'll add the list of accelerated features in the wiki. In > the mean time you can check page 21 of the first presentation that you > can find here: https://gitlab.com/QEF/q-e-gpu/wikis/home#performance > > Exact exchange will come with the next release but you can already try > it by compiling this develop branch: > https://gitlab.com/QEF/q-e-gpu/tree/gpu-exx > > Kind regards, > Pietro Bonfa' > > On 7/8/19 8:33 PM, JING YANG wrote: > > I am working on the latest version 6.4-a1. I have followed the > > instructions on the link you provided during the installation. I would > > like to know which part of the calculation in pw being accelerated by > > GPU. For example, is it boosting the matrix diagonalization during scf > > cycles, or boosting the hybrid functional calculations? I am hoping to > > GPU acceleration can boost up the calculation on the exact exchange in > > hybrid functional calculations. Is this the case? > > > > Thanks, > > Jing > > > > On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA' > <mailto:pietro.bo...@unipr.it>> wrote: > > > > Dear Jing, > > > > which GPU-enabled version are you using? > > GPU support starting from v6.1 is only available when using PGI > > compilers (well, in principle, any compiler implementing CUDA > Fortran). > > > > You can find additional information here: > > > > https://gitlab.com/QEF/q-e-gpu/wikis/home > > > > Kinds regards, > > Pietro Bonfa' > > > > On 7/8/19 5:01 PM, JING YANG wrote: > > > Hi, > > > I am trying to test the scaling of GPU version of QE > recently. I > > > found out the computational time scaling of the GPU version is > > very bad. > > > Is there any unique flags or keywords I don't know about the GPU > > > version? I am using gcc-6.2.0, openmpi-1/8/4, > > craype-accel-nvidia35. I > > > know it is not the recommended set up, but I guess if I can > > compile it > > > successfully, then it should work normally. > > > > > > Thanks, > > > Jing > > > > > > ___ > > > Quantum ESPRESSO is supported by MaX > > (www.max-centre.eu/quantum-espresso > > <http://www.max-centre.eu/quantum-espresso>) > > > users mailing list users@lists.quantum-espresso.org > > <mailto:users@lists.quantum-espresso.org> > > > https://lists.quantum-espresso.org/mailman/listinfo/users > > > > > > > > > -- > > Pietro Bonfà > > Department of Mathematical, Physical and Computer Sciences, > > University of Parma, > > Italy > > > > Firma il tuo 5 per mille all’Università di Parma e aiuta così i > > nostri studenti che vogliono realizzare un’esperienza di studio > > all’estero - Indica 00308780345 nella tua denuncia dei redditi. > > ___ > > Quantum ESPRESSO is supported by MaX > > (www.max-centre.eu/quantum-espresso > > <http://www.max-centre.eu/quantum-espresso>) > > users mailing list users@lists.quantum-espresso.org > > <mailto:users@lists.quantum-espresso.org> > > https://lists.quantum-espresso.org/mailman/listinfo/users > > > > > > ___ > > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso > ) > > users mailing list users@lists.quantum-espresso.org > > https://lists.quantum-espresso.org/mailman/listinfo/users > > > > > -- > Pietro Bonfà > Department of Mathematical, Physical and Computer Sciences, > University of Parma, > Italy > > Firma il tuo 5 per mille all’Università di Parma e aiuta così i nostri > studenti che vogliono realizzare un’esperienza di studio all’estero - > Indica 00308780345 nella tua denuncia dei redditi. > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] segfault with HSE06
Hello, I'm getting a segmentation fault when trying to run a HSE06 SCF calculation in QE 6.4rc (built with gcc and OpenMPI). I got the same result regardless of number of OMP threads (1-2) or MPI processes, it is also not because I'm running out of memory. Increasing OMP_STACK_SIZE didn't help. I'm using SG15 norm-conserving pseudopotentials. This is the error message: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Backtrace for this error: #0 0x2ba41caf6607 in ??? #1 0x2ba41caf586d in ??? #2 0x2ba41d9d5fdf in ??? #1 0x2ba41caf586d in ??? #2 0x2ba41d9d5fdf in ??? #3 0x481031 in __exx_MOD_exxinit._omp_fn.41 at /home/hpcadmin/Cluster-packages/Apps/QE/q-e-qe-6.4-rc/PW/src/exx.f90:471 And this is the input file: nstep= 150 prefix = 'pz' calculation = 'scf' / ecutwfc = 60 ecutrho = 240 occupations = 'smearing' degauss = 0.03 smearing = 'marzari-vanderbilt' assume_isolated = '2D' ntyp = 3 nat = 10 ibrav= 0 vdw_corr='dft-d3' nosym = .true. input_dft = 'hse' localization_thr = 0.005 / electron_maxstep = 1000 mixing_mode = 'plain' mixing_beta = 0.3 mixing_ndim = 10 / ion_dynamics = 'bfgs' / ATOMIC_SPECIES H 1 H_ONCV_PBE-1.0.upf C 12 C_ONCV_PBE-1.0.upf N 14 N_ONCV_PBE-1.0.upf K_POINTS automatic 3 3 1 0 0 0 CELL_PARAMETERS angstrom 9.45 0.00 0.0 0.00 8.90954544295050 0.0 0.00 0.00 40.0 ATOMIC_POSITIONS angstrom N3.220157348 4.070243213 7.161850862 C2.057591707 4.250681378 7.817575738 C4.333273229 4.171146830 7.913403134 C2.009345068 4.525337360 9.193044239 C4.285082283 4.446195607 9.288766365 N3.122476937 4.626559339 9.944547282 H1.139008253 4.174089393 7.227702259 H5.290517910 4.028527369 7.402554504 H1.052120461 4.668162403 9.703968061 H5.203598139 4.523590493 9.878655120 I would be grateful for any suggestions. In the meantime, we are upgrading to 6.4.1 to see if this helps. Best regards, Michal Krompiec Merck KGaA, Darmstadt, Germany & University of Southampton ___ 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] Structure optimization using rvv10-scan
Dear Giovani, That is a great find. Are there any other SCAN (or TPSS, or M06l) pseudopotentials available? Especially for transition metals... Best, Michal Krompiec Merck KGaA On Thu, 6 Jun 2019 at 19:41, Giovani Rech wrote: > Hello all, > > I just wanted to give you an update on this matter in case anyone stumble > upon the same issue in the future. > > The problem with the calculation using the SCAN+rVV10 functional was in > the pseudo-potential that I was using. Previously I was using a PP built > using PBE. When I changed to a PP built using SCAN, the calculation of > pressure as well as the structure optimization seemed to work well. > > Here is a relevant paper on this: Yao, Y. and Kanai, Y., 2017. Plane-wave > pseudopotential implementation and performance of SCAN meta-GGA > exchange-correlation functional for extended systems. The Journal of > chemical physics, 146(22), p.22410 > > And, finally, a few pseudo-potentials built using SCAN can be found here: > https://yaoyi92.github.io/scan-tm-pseudopotentials.html > > Best regards, > Giovani Rech > Universidade de Caxias do Sul > > On Thu, Jun 6, 2019 at 1:04 PM Giuseppe Mattioli < > giuseppe.matti...@ism.cnr.it> wrote: > >> >> Dear José >> I do not know about rvv10, but spin-polarized SCAN (and at least plus >> dft-d2 for sure) is implemented in pw.x AFAIK. In my tests it was >> quite stable but as slow as EXX, anyway... >> HTH >> Giuseppe >> >> >> José Carlos Conesa ha scritto: >> >> > Hi, >> > >> > Are there plans to implement in qe any meta-GGA (or at least >> > rvv10-scan) for the spin-polarized case? >> > >> > José Carlos >> > >> > El 26/04/2019 a las 22:12, Paolo Giannozzi escribió: >> >> Correcting myself: stress for meta-GGA is implemented, but only in >> >> the spin-unpolarized case >> >> >> >> Paolo >> >> >> >> On Thu, Apr 25, 2019 at 8:48 AM Paolo Giannozzi >> >> mailto:p.gianno...@gmail.com>> wrote: >> >> >> >>I am not sure that the calculation of stress is implemented with >> >>meta-GGA. >> >> >> >>SCAN behaves better than other meta-GGA, but still it is >> >>numerically unstable. See for instance here: >> >>https://gitlab.com/QEF/q-e/issues/32. Before trying difficult >> >>calculations with SCAN you should verify whether you can do simple >> >>ones. >> >> >> >>Paolo >> >> >> >> >> >>On Sat, Apr 20, 2019 at 3:33 AM Giovani Rech >> >>mailto:gio.pi.r...@gmail.com>> wrote: >> >> >> >>Hello all, >> >> >> >>Have anyone tried structure optimization using rvv10-scan? >> >> >> >>I'm trying to optimize a structure (graphite) at 0.0 kbar >> >>taking into account van der Waals interactions. For such, I'm >> >>using the SCAN+rVV10 by setting "input_dft = 'rvv10-scan'". >> >>What I'm getting as a result makes no sense, with unreasonable >> >>pressures. Here's a plot of the pressure and volume as a >> >>function of optimization step: >> >>image.png >> >> >> >>When I got this values I was using version 6.4.0 and then >> >>tried again with 6.3 and finally with the latest version, >> >>6.4.1, and got the same values (plotted above). Here's the >> >>input that I used: >> >> >> >> >> >> title = "graphite_rvv10_vcrelax" , >> >> calculation = 'vc-relax' , >> >> restart_mode = "from_scratch" , >> >>outdir = "./" , >> >>pseudo_dir = >> "/home/giovani/graphite/pseudo" , >> >>prefix = "gC" , >> >> disk_io = 'default' , >> >> verbosity = 'default' , >> >> etot_conv_thr = 1.0D-4 , >> >> forc_conv_thr = 1.0D-3 , >> >> nstep = 400 , >> >> tstress = .true. , >> >> tprnfor = .true. , >> >>
Re: [QE-users] norm-conserving pseudopotentials for TPSS?
Hi Lorenzo, Thanks for the tip. Unfortunately, in this case it doesn't seem to help. Best, Michal On Mon, 3 Jun 2019 at 08:55, Lorenzo Paulatto wrote: > > I read in the FAQ that this could be caused by bad pseudopotentials. I > > used norm-conserving pseudos from PseudoDojo, obtained for PBE. Is it > > why my calculation failed? If so, how do I generate (or where do I find) > > pseudos for TPSS? > > Dear Michal, > from my limited experience, meta-GGA functionals are quite unstable, try > to increase the Fourier transform grid a lot, i.e. you take the default > values from the output of pw.x: > Dense grid:32557 G-vectors FFT dimensions: ( 75, 75, 75) > ad set n1,n2 and n3 to something quiet a bit larger, ideally with small > prime factors (2, 3 or 5), in this case it could be 128 > > hth > > > > > Thanks in advance, > > > > Michal Krompiec > > > > Merck KGaA and Univ. of Southampton > > > > ___ > > 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 > > > > -- > Lorenzo Paulatto - Paris > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] norm-conserving pseudopotentials for TPSS?
Dear Paolo, Thanks. The same calculation works perfectly fine with PBE, revPBE and PBEsol. Is SCAN less nasty than TPSS in your experience? Best, Michal On Mon, 3 Jun 2019 at 08:05, Paolo Giannozzi wrote: > Very likely your error is caused by meta-GGA, not by pseudopotentials (try > the same calculation without meta-GGA). TPSS is especially nasty. > > Paolo > > Il sab 1 giu 2019 23:48 Michal Krompiec ha > scritto: > >> Hello, >> I tried calculating a SiO2 slab with some adsorbate (optimized with PBE >> using PAW) with TPSS, but I'm getting the following error: >>task #80 >> from cdiaghg : error # 4 >> eigenvectors failed to converge >> I read in the FAQ that this could be caused by bad pseudopotentials. I >> used norm-conserving pseudos from PseudoDojo, obtained for PBE. Is it why >> my calculation failed? If so, how do I generate (or where do I find) >> pseudos for TPSS? >> >> Thanks in advance, >> >> Michal Krompiec >> >> Merck KGaA and Univ. of Southampton >> ___ >> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) >> users mailing list users@lists.quantum-espresso.org >> https://lists.quantum-espresso.org/mailman/listinfo/users > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] norm-conserving pseudopotentials for TPSS?
Hello, I tried calculating a SiO2 slab with some adsorbate (optimized with PBE using PAW) with TPSS, but I'm getting the following error: task #80 from cdiaghg : error # 4 eigenvectors failed to converge I read in the FAQ that this could be caused by bad pseudopotentials. I used norm-conserving pseudos from PseudoDojo, obtained for PBE. Is it why my calculation failed? If so, how do I generate (or where do I find) pseudos for TPSS? Thanks in advance, Michal Krompiec Merck KGaA and Univ. of Southampton ___ 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] parallelization of pw.x
Dear Pietro, dear Giuseppe, Thanks, indeed my comment on speedup was hasty and didn’t make sense. Thanks for the suggestions regarding increasing number of mpi processes and not using nt. Best, Michal On Thu, 30 May 2019 at 16:18, Pietro Delugas wrote: > Dear Michal > > 3.7x with respect to what ? > > your cut and paste refers to the wall time and the total cpu time per mpi > task, they differ because you are using thread parallelism. > > if you don't have memory issues I would try to increase the number of mpi > processes decreasing the number of thread and usually when the number on > MPI tasks is smaller than the dimesions of the fft grid it is better to > avoid using nt. > > Hope it helps > > regards > > Pietro > On 30/05/19 16:42, Michal Krompiec wrote: > > Hello, > I am trying to run a calculation on a 2D slab with a bit of adsorbate (119 > atoms in total), and I would like to parallelize it as much as possible. I > am using a 3 3 1 Monkhorst-Pack grid (so I have 5 k-points). > I tried using -npool 5 -nt 4 using 20 MPI processes and 5 threads per > process but, as it seems, the speedup was just 3.7x: >PWSCF: 1d 4h27m CPU 7h43m WALL > What could have gone wrong, is there anything "obvious" I can do to > diagnose the problem? I am using QE 6.4rc, compiled with gcc and OpenMPI, > without ELPA. > > Best regards, > > Michal Krompiec > > Merck KGaA and University of Southampton > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list > users@lists.quantum-espresso.orghttps://lists.quantum-espresso.org/mailman/listinfo/users > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ 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] plotting spin polarization with pp.x
Dear Giuseppe, Thanks! But it turned out that my problem had a simpler explanation: missing end-of-line character after the final /. Best, Michal On Fri, 24 May 2019 at 10:02, Giuseppe Mattioli < giuseppe.matti...@ism.cnr.it> wrote: > > dear Michal > In the past I sometimes faced with the same problem. I've found (very > empirically...) that if you break the calculation in two steps the > problem can be solved. Something like this > > export FILEA="yourprefix" > > export INPFILE=$FILEA-pol.inp > export OUTFILE=$FILEA-pol.out > echo " $FILEA" > echo " $INPFILE" > echo " $OUTFILE" > cat > $INPFILE << EOF > > prefix = '$FILEA' > outdir = '$TMP_DIR/' > filplot = '$FILEA-pol.dat' > plot_num= 6 > / > EOF > $PARA_PREFIX $ESPRESSO/pp.x $PARA_POSTFIX < $INPFILE >> $OUTFILE > > export FILE="rho-pol-$FILEA" > export INPFILE=$FILE.inp > export OUTFILE=$FILE.out > echo " $FILE" > echo " $INPFILE" > echo " $OUTFILE" > cat > $INPFILE << EOF > > / > > nfile = 1 > filepp(1) = '$FILEA-pol.dat' > weight(1) = 1.0 > iflag = 3 > output_format = 6 > fileout = '$FILE.cube' > e1(1) =1.0, e1(2)=1.0, e1(3) = 0.0, > e2(1) =0.0, e2(2)=0.0, e2(3) = 1.0, > nx=56, ny=40 > / > EOF > $PARA_PREFIX $ESPRESSO/pp.x $PARA_POSTFIX < $INPFILE >> $OUTFILE > > You may give it a try > HTH > Giuseppe > > Quoting Michal Krompiec : > > > Hello, > > I'm struggling with plotting of spin density with pp.x, from a PAW SCF > > calculation. This is my input to pp.x: > > > > prefix='Si_slab_mo_40', > > plot_num=6, > > / > > > > iflag = 3 , > > output_format = 6, > > fileout = 'spin.cube' > > nx=64 > > ny=64 > > nz=64 > > / > > And this is the error I'm getting: > > Calling punch_plot, plot_num = 6 > > Writing data to file tmp.pp > > Message from routine chdens: > > namelist plot not found or invalid, exiting > > > > I'd be very grateful for any advice. > > > > Best regards, > > Michal Krompiec > > Merck KGaA and University of Southampton > > > > GIUSEPPE MATTIOLI > CNR - ISTITUTO DI STRUTTURA DELLA MATERIA > Via Salaria Km 29,300 - C.P. 10 > I-00015 - Monterotondo Scalo (RM) > Mob (*preferred*) +39 373 7305625 > Tel + 39 06 90672342 - Fax +39 06 90672316 > E-mail: > > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users > ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] plotting spin polarization with pp.x
Hello, I'm struggling with plotting of spin density with pp.x, from a PAW SCF calculation. This is my input to pp.x: prefix='Si_slab_mo_40', plot_num=6, / iflag = 3 , output_format = 6, fileout = 'spin.cube' nx=64 ny=64 nz=64 / And this is the error I'm getting: Calling punch_plot, plot_num = 6 Writing data to file tmp.pp Message from routine chdens: namelist plot not found or invalid, exiting I'd be very grateful for any advice. Best regards, Michal Krompiec Merck KGaA and University of Southampton ___ 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] Choosing convergence criteria for vc-relax
Dear Nicola, Thank you very much! Regards, Michal On Mon, 20 May 2019 at 20:04, Nicola Marzari wrote: > > > Dear Michal, > > > it depends on how smooth is the dependences of the forces on the cutoff, > so one should make an informed decision depending on the > pseudopotentials used. We e.g. look at phonon frequencies as a function > of cutoff, and if you look at silicon, here below, even if we didn't > test below 30Ry, I would bet that at 20 or even 15Ry forces would be > reasonable: > > > https://www.materialscloud.org/discover/data/discover/sssp/convergences_efficiency/Si_8.0_conv_patt.png > > If you try Ga, you can see that the phonons (the solid line) do not > particularly become worse in going down from 70Ry to 45Ry, but then > progressively worsen: > > > https://www.materialscloud.org/discover/data/discover/sssp/convergences_efficiency/Ga_8.0_conv_patt.png > > Still, for many pseudopotentials a decrease in cutoff doesn't worsen the > forces particularly, but there is no 2/3 or 1/2 rule - one just need to > examine the tables above. > > For ecutrho it might be a bit easier, and if you are not having > magnetism often one can use a dual (the ration of ecutrho/ecutwfc) > equalt to 3, or even 2, for normconserving, and 6 or even 4 for ultrasoft. > > All to be tested... > > nicola > > > On 20/05/2019 13:47, Michal Krompiec wrote: > > Dear Nicola, > > I am looking forward to reading the "short thing on this"! > > Can you comment on the widespread (?) practice of using much lower than > > recommended (say, 2/3 or 1/2) ecutwfc for geometry optimization until a > > minimum is found, and then increasing cutoffs until convergence is > > achieved? Is it generally a good idea? > > > > Best regards, > > > > Michal Krompiec > > > > Associate Director at Merck KGaA and Adjunct Prof at University of > > Southampton > > > > > > On Sun, 19 May 2019 at 13:57, Nicola Marzari > <mailto:nicola.marz...@epfl.ch>> wrote: > > > > > > > > Hi Robert, > > > > this issue of optimal parameters is a bit of a neverending story, we > are > > preparing a short thing on this. But in a nutshell - yes, the > > electronic > > convergence should be tighter, especially for a follow-up phonon > > calculation. that number actually depends on the unit cell used, but > > for > > 5 atoms, I would indeed try d-12 and d-14. For ecutwfc and ecutrho, > > well, my advise is to use the SSSP suggestions (google it); and say > if > > you have 30 120, 40 160, 25 300, well, take the max of the ecutwfc > > suggested, for the gloval ecutwfc, and same for ecutrho. > > > > nic > > > > > > On 17/05/2019 21:24, Appleton, Robert J wrote: > > > Hello, > > > > > > I am trying to study the phonons of the material BaZrS3 to > > determine if > > > it is stable for a given structure. I first use phonopy and vasp > and > > > found negative frequency values for phoning band structure. My > > advisor > > > is concerned in the optimization of the structure and so we now > > want to > > > use quantum espresso. I have only used it a few times and mostly > > used > > > default or example inputs. The input I want to make sure is > > sufficient > > > is my criteria for convergence. > > > > > > Under the : > > > force convergence criteria right now is > > > forc_conv_thr = .0001 <— this value seems to big but how do I > > choose a > > > value that is best for optimization but does not take to much > > computer time? > > > > > > Under the : > > > conv_thr = 1.d-9 <— I am considering changing to 1.d-12. Is this > > a good > > > idea? > > > > > > Under : > > > I am using ecutrho = 12 • ecutwfc > > > > > > If you can give me some advice on how best to choose convergence > > > criteria for studying phonons that would be very good thanks. > > > > > > Robert Appleton > > > Cal State LA - MS Physics Student > > > > > > Get Outlook for iOS <https://aka.ms/o0ukef> > > > > > > ___ > > > Quantum ESPRESSO is supported by MaX > > (www.max-cent
Re: [QE-users] Choosing convergence criteria for vc-relax
Dear Nicola, I am looking forward to reading the "short thing on this"! Can you comment on the widespread (?) practice of using much lower than recommended (say, 2/3 or 1/2) ecutwfc for geometry optimization until a minimum is found, and then increasing cutoffs until convergence is achieved? Is it generally a good idea? Best regards, Michal Krompiec Associate Director at Merck KGaA and Adjunct Prof at University of Southampton On Sun, 19 May 2019 at 13:57, Nicola Marzari wrote: > > > Hi Robert, > > this issue of optimal parameters is a bit of a neverending story, we are > preparing a short thing on this. But in a nutshell - yes, the electronic > convergence should be tighter, especially for a follow-up phonon > calculation. that number actually depends on the unit cell used, but for > 5 atoms, I would indeed try d-12 and d-14. For ecutwfc and ecutrho, > well, my advise is to use the SSSP suggestions (google it); and say if > you have 30 120, 40 160, 25 300, well, take the max of the ecutwfc > suggested, for the gloval ecutwfc, and same for ecutrho. > > nic > > > On 17/05/2019 21:24, Appleton, Robert J wrote: > > Hello, > > > > I am trying to study the phonons of the material BaZrS3 to determine if > > it is stable for a given structure. I first use phonopy and vasp and > > found negative frequency values for phoning band structure. My advisor > > is concerned in the optimization of the structure and so we now want to > > use quantum espresso. I have only used it a few times and mostly used > > default or example inputs. The input I want to make sure is sufficient > > is my criteria for convergence. > > > > Under the : > > force convergence criteria right now is > > forc_conv_thr = .0001 <— this value seems to big but how do I choose a > > value that is best for optimization but does not take to much computer > time? > > > > Under the : > > conv_thr = 1.d-9 <— I am considering changing to 1.d-12. Is this a good > > idea? > > > > Under : > > I am using ecutrho = 12 • ecutwfc > > > > If you can give me some advice on how best to choose convergence > > criteria for studying phonons that would be very good thanks. > > > > Robert Appleton > > Cal State LA - MS Physics Student > > > > Get Outlook for iOS <https://aka.ms/o0ukef> > > > > ___ > > 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 > > > > > -- > -- > Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL > Director, National Centre for Competence in Research NCCR MARVEL, EPFL > http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project > ___ > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users > ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] assume_isolated=2D
Thanks Thibault, this is exactly what I was looking for! Michal On Thu, 25 Apr 2019 at 11:17, Thibault Sohier wrote: > Dear Michal, > > The first statement is incorrect: centering the slab around 0 is NOT > necessary for the assume_isolated=‘2D’ flag to work. Somehow, it makes > more sense intuitively, at least to me, but I guess it depends on how you > imagine your cell. Anyway, everything should work fine wherever you put > your slab. > > The second statement is almost correct: “the total thickness of the > system should be less than half of the Z dimension of the simulation cell” > , yes, but the total thickness of the system should also include electrons. > So in your next sentence > > "In other words, if Z_dim is the height of the simulation cell, all atoms > should be within [-Z_dim/4, Z_dim/4]” > > Just replace “all atoms” by "all atoms and all electrons”, and you are > good. > > Of course “all electrons” actually means something more like “until the > electron density is negligible”. > > Thanks, > Thibault > > Post-doc at THEOS, EPFL, Lausanne > > > > On 25 Apr 2019, at 12:00, users-requ...@lists.quantum-espresso.org wrote: > > ------ > > Message: 2 > Date: Wed, 24 Apr 2019 17:43:57 +0100 > From: Michal Krompiec > To: Quantum Espresso users Forum > Subject: [QE-users] assume_isolated=2D > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Dear QE Community, > Could someone clarify if the following is correct: assume_isolated='2D' > implies that the system (2D slab) should be centered around z=0 and the > total thickness of the system should be less than half of the Z dimension > of the simulation cell. In other words, if Z_dim is the height of the > simulation cell, all atoms should be within [-Z_dim/4, Z_dim/4]. > Thanks in advance, > > Michal Krompiec > Merck KGaA & University of Southampton > > > ___ > Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso) > users mailing list users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] assume_isolated=2D
Dear QE Community, Could someone clarify if the following is correct: assume_isolated='2D' implies that the system (2D slab) should be centered around z=0 and the total thickness of the system should be less than half of the Z dimension of the simulation cell. In other words, if Z_dim is the height of the simulation cell, all atoms should be within [-Z_dim/4, Z_dim/4]. Thanks in advance, Michal Krompiec Merck KGaA & University of Southampton On Fri, 12 Apr 2019 at 11:07, Thomas Brumme wrote: > Dear Julien, > > it's actually described indirectly in the paper - in all figures you can > see that the > system is centered a z = 0. Otherwise, the cutoff will cut off some of the > real > Coulomb interactions. Probably this should be added to the description, > but this > should be done by the original author. If he doesn't answer here, I will > contact > him. > > The way you center should be more like (zh+zl)=0 - I don't understand why > you want to divide by 2 (zero divided by 2?!). That the slab isn't > centered should > not be problematic. From your input I also see that the vacuum region > should be > large enough but maybe you can try increasing it a bit more - maybe > increase the > cell dimension in z to 45 or 50 Angstrom? > > Cheerio > > Thomas > > > ___ Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] PBE + rVV10?
Hello, Is it possible to use PBE + rVV10 (or PBE+rVV10L( in QE, as described in https://arxiv.org/abs/1612.03524 ? Thanks, Michal Krompiec University of Southampton & Merck KGaA ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Negatively charged isolated molecule
Dear Ernane, Have you thought of using a more sophisticated method (like GW) on [CO3]- to calculate its EA? This would give you the energy of [CO3]2- in vacuum. Best, Michal Krompiec University of Southampton & Merck KGaA On Fri, 15 Mar 2019 at 18:22, Ernane de Freitas Martins wrote: > Dear Giuseppe, > > I really appreciate your answer. Thank you very much for using your time > to answer my question. > > I'll think on your suggestion about trying hybrid functionals. The point > is that I need to estimate the solvation energy for carbonate ion using the > environ module, then I'll need to run a vacuum calculation using the same > functional I'm already using rVV-10). > > Thank you again for replying. > > Atenciosamente, > > > Dr. Ernane de Freitas Martins > Postdoctoral researcher > IF - USP > São Paulo, SP - Brazil > > Em sex, 15 de mar de 2019 15:04, Giuseppe Mattioli < > giuseppe.matti...@ism.cnr.it> escreveu: > >> >> Dear Ernane >> Your question contains part of the answer! Carbonate ion (CO3 2-) is >> not stable outside water, and calculations of its properties in gas >> phase are likely not so meaningful, but in the case of model >> thermodynamics cycles (e.g. Born-Haber). The excess negative charge is >> unbound when not stabilized by a strongly polar solvent, and this is >> likely responsible for instabilities in the construction of the >> Kohn-Sham potential along scf iterations. Moreover, this happens on >> top of the strong delocalization error you experience when you use a >> standard GGA exchange-correlation functional, when the >> self-interaction of strongly localized electrons in the J[n] Coulomb >> potential is not cancelled by a same term in the semi local exchange >> potential. You may minimize this latter source of error by using a >> hybrid GGA-EXX functional such as B3LYP, where the non local >> Hartree-Fock part of the exchange functional can recover part of the >> delocalization error, but you are not free yet from the instability of >> carbonate in gas phase. >> HTH >> Giuseppe >> >> Ernane de Freitas Martins ha scritto: >> >> > Hello, >> > >> > I'm experiencing a problem to run a negatively charge molecule in >> quantum >> > espresso. The system is CO32-. >> > >> > I try both vacuum and solvated (environ) calculations. The solvated one >> > works fine. >> > >> > The problem is the calculation in vacuum. It never give the first ionic >> > step because the SCF accuracy never reaches the convence criterion. >> > >> > I tried many different solutions (increase cutoffs and box size, use >> assume >> > isolated, decreasing and changing the mixing scheme and etc) and nothing >> > works. >> > >> > The unique calculation that works fine for vacuum is the one with a box >> > size of 7.9 x 7.9 x 7.9 A. I really don't understand why it only works >> for >> > this specific box size. >> > >> > I ran several other charged systems (+1, +2 and -1 total charge) and >> all of >> > them worked fine. The problem appears for -2 total charge in vacuum. >> > >> > Would some of you kindly help me in this? >> > >> > Cheers, >> > >> > Dr. Ernane de Freitas Martins >> > Postdoctoral researcher >> > IF - USP >> > São Paulo, SP - Brazil >> >> >> >> GIUSEPPE MATTIOLI >> CNR - ISTITUTO DI STRUTTURA DELLA MATERIA >> Via Salaria Km 29,300 - C.P. 10 >> I-00015 - Monterotondo Scalo (RM) >> Mob (*preferred*) +39 373 7305625 >> Tel + 39 06 90672342 - Fax +39 06 90672316 >> E-mail: >> >> ___ >> users mailing list >> users@lists.quantum-espresso.org >> https://lists.quantum-espresso.org/mailman/listinfo/users > > ___ > users mailing list > users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] NEB error: End of file
Never mind my post - the line "BEGIN_POSITIONS" was missing.
Michal
On Mon, 11 Mar 2019 at 09:26, Michal Krompiec
wrote:
> Hello,
> I'm struggling with my first NEB calculation, NEB crashes with the
> following error:
> input file: neb1.in, output file: neb1.out
> At line 116 of file path_gen_inputs.f90 (unit = 99, file = 'neb1.in')
> Fortran runtime error: End of file
>
> I understand that this is because the parser can't find something in my
> input file, correct? Can anybody please point me to where the problem is?
> This is my input file (without the actual atom positions):
>
> BEGIN
> BEGIN_PATH_INPUT
>
> restart_mode = 'from_scratch'
> nstep_path= 20,
> opt_scheme= "broyden",
> num_of_images = 10,
> minimum_image = .false.
> /
> END_PATH_INPUT
> BEGIN_ENGINE_INPUT
>
> prefix = "reaction"
> /
>
> dftd3_version = 3,
> vdw_corr = 'dft-d3',
>ecutwfc = 40
>ecutrho = 320
>occupations = 'fixed'
>input_dft= 'pbe'
>assume_isolated = '2D'
>ntyp = 4
>nat = 171
>ibrav= 0
> /
>
>electron_maxstep = 1000
>mixing_mode= 'local-TF'
>conv_thr = 1e-7
> /
>
> ATOMIC_SPECIES
> O 15.999 O.pbe-n-kjpaw_psl.1.0.0.UPF
> Si 28.085 Si.pbe-n-kjpaw_psl.1.0.0.UPF
> H 1.008 H.pbe-kjpaw_psl.1.0.0.UPF
> Cl 35.45 Cl.pbe-n-kjpaw_psl.1.0.0.UPF
>
> FIRST_IMAGE
> ATOMIC_POSITIONS angstrom
> ...atoms go here...
> LAST_IMAGE
> ATOMIC_POSITIONS angstrom
> ...atoms go here...
> END_POSITIONS
> K_POINTS {automatic}
> 3 3 1 0 0 0
> CELL_PARAMETERS {angstrom}
> 17.4304700000 0.00 0.00
> 0.00 10.149460 0.00
> 0.00 0.00 39.00
> END_ENGINE_INPUT
> END
>
> Thanks,
> Michal
>
> Dr. Michal Krompiec
>
> School of Chemistry, University of Southampton & Merck KGaA
>
>
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] NEB error: End of file
Hello,
I'm struggling with my first NEB calculation, NEB crashes with the
following error:
input file: neb1.in, output file: neb1.out
At line 116 of file path_gen_inputs.f90 (unit = 99, file = 'neb1.in')
Fortran runtime error: End of file
I understand that this is because the parser can't find something in my
input file, correct? Can anybody please point me to where the problem is?
This is my input file (without the actual atom positions):
BEGIN
BEGIN_PATH_INPUT
restart_mode = 'from_scratch'
nstep_path= 20,
opt_scheme= "broyden",
num_of_images = 10,
minimum_image = .false.
/
END_PATH_INPUT
BEGIN_ENGINE_INPUT
prefix = "reaction"
/
dftd3_version = 3,
vdw_corr = 'dft-d3',
ecutwfc = 40
ecutrho = 320
occupations = 'fixed'
input_dft= 'pbe'
assume_isolated = '2D'
ntyp = 4
nat = 171
ibrav= 0
/
electron_maxstep = 1000
mixing_mode= 'local-TF'
conv_thr = 1e-7
/
ATOMIC_SPECIES
O 15.999 O.pbe-n-kjpaw_psl.1.0.0.UPF
Si 28.085 Si.pbe-n-kjpaw_psl.1.0.0.UPF
H 1.008 H.pbe-kjpaw_psl.1.0.0.UPF
Cl 35.45 Cl.pbe-n-kjpaw_psl.1.0.0.UPF
FIRST_IMAGE
ATOMIC_POSITIONS angstrom
...atoms go here...
LAST_IMAGE
ATOMIC_POSITIONS angstrom
...atoms go here...
END_POSITIONS
K_POINTS {automatic}
3 3 1 0 0 0
CELL_PARAMETERS {angstrom}
17.430470 0.00 0.00
0.00 10.149460 0.00
0.00 0.00 39.00
END_ENGINE_INPUT
END
Thanks,
Michal
Dr. Michal Krompiec
School of Chemistry, University of Southampton & Merck KGaA
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] turbo_lanczos error
Thanks Pietro, Indeed adding -i8 to FF_FLAGS and FOX_FLAGS in make.inc helped, but I had to comment line 352 in qmmm.f90 which was causing ifort to complain (I don't plan to use qmmm anyway): qmmm.f90(352): warning #6075: The data type of the actual argument does not match the definition. [NAT_MM] CALL ec_fill_radii( aradii, nat_mm, mass, types, ntypes, 1 ) ^ qmmm.f90(352): error #6633: The type of the actual argument differs from the type of the dummy argument. [TYPES] CALL ec_fill_radii( aradii, nat_mm, mass, types, ntypes, 1 ) --^ qmmm.f90(352): warning #6075: The data type of the actual argument does not match the definition. [NTYPES] CALL ec_fill_radii( aradii, nat_mm, mass, types, ntypes, 1 ) -^ compilation aborted for qmmm.f90 (code 1) However, subsequent run of the test suite failed, I get the following error for each test run: Attempting to use an MPI routine before initializing MPI *** error in Message Passing (mp) module *** *** error code: 8000 What could be the cause? Just to double-check, I re-built from the same source (QE 6.4) without -i8 and the tests went OK. Thanks, Michal On Fri, 8 Mar 2019 at 10:14, Pietro Davide Delugas wrote: > hello Michal > > in the make.inc you should add the -i8 flag also to FOX_FLAGS in order > that routines in FoX library are also compiled using long integers > > after editing the make.inc file do a make clean before compiling. > Pietro > > On 03/08/2019 10:55 AM, Michal Krompiec wrote: > > Hello, > I'm trying to run a TDDpFT calculation on a large system, using HSE06 > functional. Turbo_lanczos crashes with the following message: > Error in routine diropn (3): > wrong record length > > I found a similar (?) problem discussed previously ( > https://pw-forum.pwscf.narkive.com/6QjNE4Dw/wrong-record-length ) but the > solution posted there (compilation with the -i8 flag to prevent integer > overflow) doesn't work for me - build fails with the following error: > fox_init_module.f90(22): error #6285: There is no matching specific > subroutine for this generic subroutine call. [SETUP_IO] > CALL setup_io(ERR_CODE = errcodes(1), EOR_CODE = errcodes(2), > EOF_CODE = errcodes(3)) > ---^ > compilation aborted for fox_init_module.f90 (code 1) > > I would be very grateful for any advice. > Thanks, > Michal Krompiec > > > Adjunct Professor > > School of Chemistry, University of Southampton > > Highfield, Southampton SO17 1BJ, UK > > and > > Head of Computational Modelling | Performance Materials | Early Research > and Business Development > > Merck > > > > ___ > users mailing > listusers@lists.quantum-espresso.orghttps://lists.quantum-espresso.org/mailman/listinfo/users > > > ___ > users mailing list > users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] turbo_lanczos error
Hello, I'm trying to run a TDDpFT calculation on a large system, using HSE06 functional. Turbo_lanczos crashes with the following message: Error in routine diropn (3): wrong record length I found a similar (?) problem discussed previously ( https://pw-forum.pwscf.narkive.com/6QjNE4Dw/wrong-record-length ) but the solution posted there (compilation with the -i8 flag to prevent integer overflow) doesn't work for me - build fails with the following error: fox_init_module.f90(22): error #6285: There is no matching specific subroutine for this generic subroutine call. [SETUP_IO] CALL setup_io(ERR_CODE = errcodes(1), EOR_CODE = errcodes(2), EOF_CODE = errcodes(3)) ---^ compilation aborted for fox_init_module.f90 (code 1) I would be very grateful for any advice. Thanks, Michal Krompiec Adjunct Professor School of Chemistry, University of Southampton Highfield, Southampton SO17 1BJ, UK and Head of Computational Modelling | Performance Materials | Early Research and Business Development Merck ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] L-ACE
Thank you very much!
On Mon, 4 Mar 2019 at 15:58, Paolo Giannozzi wrote:
> It is sufficient to specify a nonzero localization threshold
> ("localization_thr"). ACE is the default.
>
> Paolo
>
> On Mon, Mar 4, 2019 at 4:30 PM Michal Krompiec
> wrote:
>
>> Hello,
>> How do I activate L-ACE in QE 6.4? Just by using ACE and specifying
>> non-zero localization_thr, for example 0.004 as in the paper
>> https://doi.org/10.1088/2516-1075/aaf7d4 ?
>> Thanks,
>> Michal Krompiec
>>
>> Adjunct Professor
>>
>> School of Chemistry, University of Southampton
>>
>> Highfield, Southampton SO17 1BJ, UK
>>
>> and
>>
>> Head of Computational Modelling | Performance Materials | Early Research
>> and Business Development
>>
>> Merck
>> ___
>> users mailing list
>> users@lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
>
> --
> Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] L-ACE
Hello, How do I activate L-ACE in QE 6.4? Just by using ACE and specifying non-zero localization_thr, for example 0.004 as in the paper https://doi.org/10.1088/2516-1075/aaf7d4 ? Thanks, Michal Krompiec Adjunct Professor School of Chemistry, University of Southampton Highfield, Southampton SO17 1BJ, UK and Head of Computational Modelling | Performance Materials | Early Research and Business Development Merck ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] weird errors when linking with libxc
Hello, I compiled QE 6.4rc using Intel 2018 (with MPI and MKL), with and without external libxc (built with the same compilers, using either xconfigure recipe or the supplied configure). Without libxc, the tests pass without any problems, but with libxc, at least some pw_atom tests fail, for example atom-occ1.in: grep "total ene" test.out.020319.inp\=atom-occ1.in total energy = -98.61766236 Ry total energy =-100.77127662 Ry total energy =-100.25626050 Ry total energy =-100.02110465 Ry total energy =-100.11405100 Ry total energy =-100.91211312 Ry total energy = -99.79450651 Ry total energy = -99.95305980 Ry total energy =-100.25087371 Ry total energy =-101.34144162 Ry total energy = -99.77500025 Ry total energy =-100.93029825 Ry grep "total ene" benchmark.out.git.inp=atom-occ1.in total energy = -85.44517532 Ry total energy = -85.53996012 Ry total energy = -85.55002653 Ry total energy = -85.55291696 Ry total energy = -85.55383013 Ry total energy = -85.55419500 Ry total energy = -85.55519508 Ry total energy = -85.55467789 Ry total energy = -85.55485046 Ry total energy = -85.55495416 Ry total energy = -85.55500722 Ry total energy = -85.55503257 Ry total energy = -85.55504109 Ry total energy = -85.55505508 Ry total energy = -85.55506021 Ry !total energy = -85.55506477 Ry Any idea what can be wrong? Best, Michal ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] HFX and USPP (QE6.3)
Dear Paolo, Do you mean L-ACE https://arxiv.org/pdf/1801.09263.pdf? Is L-ACE already available in the development branch? Best, Michal Krompiec Merck / U Southampton On Thu, 14 Feb 2019 at 15:21, Paolo Giannozzi wrote: > SCDM is coming (very) soon but not with USPP > > Paolo > > On Thu, Feb 14, 2019 at 12:46 PM Tobias Kloeffel > wrote: > >> Hi Lorenzo, >> >> since no one else noticed it, I guess there is not much interest in >> implementing it? I saw USPP + SCDM on some >> old slides from the development meeting back in 2017. However, if >> forces are not available I guess SCDM is also not on the current todo >> list? >> >> >> >> On 2/13/19 12:34 PM, Lorenzo Paulatto wrote: >> >> The energy minimum is at around 1.249A whereas the force minimum is >> >> at 1.253A, is there something missing in the force evaluation if PBE0 >> >> is used? >> > >> > It is quite likely, I did not implement it and I doubt anybody else >> > did. I think it is more or less a matter of adding the HF >> > contributions to the hamiltonian (deexx from vexx) to the expression >> > of the ultrasoft forces, but there is some complexity with the >> > indexes, I think. >> > >> > Anyway, I confirm it is probably not implemented and should be prevented >> > >> > >> >> -- >> M.Sc. Tobias Klöffel >> === >> Interdisciplinary Center for Molecular Materials (ICMM) >> and Computer-Chemistry-Center (CCC) >> Department Chemie und Pharmazie >> Friedrich-Alexander-Universität Erlangen-Nürnberg >> Nägelsbachstr. 25 >> D-91052 Erlangen, Germany >> >> Room: 2.305 >> Phone: +49 (0) 9131 / 85 - 20423 >> Fax: +49 (0) 9131 / 85 - 26565 >> >> === >> >> E-mail: tobias.kloef...@fau.de >> >> ___ >> users mailing list >> users@lists.quantum-espresso.org >> https://lists.quantum-espresso.org/mailman/listinfo/users > > > > -- > Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > ___ > users mailing list > users@lists.quantum-espresso.org > https://lists.quantum-espresso.org/mailman/listinfo/users ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] GPU version, NVIDIA Tesla P4
Hello, Is there any chance that NVIDIA Tesla P4 will be supported by the GPU version of QE? Thanks, Michal Dr. Michal Krompiec Adjunct Professor School of Chemistry, University of Southampton Highfield, Southampton SO17 1BJ, UK and Head of Computational Modelling | Performance Materials | Early Research and Business Development Merck ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] zincblende structure, SCF convergence
Indeed this is an issue with my QE build (I've just tried with a gcc build
- and all went fine!), so please disregard my previous email.
Best,
MK
On Tue, 9 Oct 2018 at 10:52, Michal Krompiec
wrote:
> Hello,
> I'm struggling with SCF convergence of something that should be a simple
> calculation: InP (zincblende structure taken from a CIF). I tried
> ultra-soft pseudopotentials, PAW, changing the k-point grid, increasing
> ecutwfc and ecutrho, decreasing mixing_beta and every time the SCF energy
> is oscillating instead of converging. I would be grateful for any advice.
> This is an example input file:
>
> calculation = "scf",
> pseudo_dir = ".",
> outdir = ".",
> prefix = "InP",
> verbosity='high'
> restart_mode = "from_scratch"
> /
>
> input_dft = "pbe",
> ibrav = 2,
> nat = 2,
> ntyp= 2,
> ecutwfc = 80,
> ecutrho = 800,
> occupations = "fixed",
> A=5.8687,
>
>
> /
>
> electron_maxstep =1000,
> diagonalization = "cg",
> mixing_beta=0.2,
> mixing_ndim=12,
> mixing_mode="plain"
> /
>
>
> ATOMIC_SPECIES
> In 49 In.pbe-dn-kjpaw_psl.1.0.0.UPF
> P 15 P.pbe-n-kjpaw_psl.1.0.0.UPF
>
> ATOMIC_POSITIONS {alat}
> In 0.0 0.0 0.0
> P 0.25 0.25 0.25
>
> K_POINTS {automatic}
> 9 9 9 0 0 0
>
> Thanks in advance,
>
> Michal
>
>
> *Dr. Michal Krompiec*
>
> Adjunct Professor
>
> School of Chemistry, University of Southampton
>
> Highfield, Southampton SO17 1BJ, UK
>
> and
>
> Head of Computational Modelling | Performance Materials | Early Research
> and Business Development
>
> Merck
>
>
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
