[Pw_forum] Xspectra
Vedo che nessuno ti si ? filato... In attesa della poppata (ma non ti ci abituare...:-)) ti segnalo che xspectra.x fa assorbimento di raggi X (XAS, o XANES, o NEXAFS), ma non diffrazione (XRD). Ciao G. Quoting Tommy : > Dear all QE user, > I'd like to calculate the XRD spectra of a zirconia supercell... > I've read about the Xspectra package. > Do you know if it runs also with ultrasoft pseudopotential like, > e.g. Zr.pbe-nsp-van.UPF? And otherwise, how do I buil the gipaw > pseudopotential suitable for that? > Thanks in advance, > Tommaso Francese, > Universit? C? Foscari of Venice -- - Article premier - Les hommes naissent et demeurent libres et ?gaux en droits. Les distinctions sociales ne peuvent ?tre fond?es que sur l'utilit? commune - Article 2 - Le but de toute association politique est la conservation des droits naturels et imprescriptibles de l'homme. Ces droits sont la libert?, la propri?t?, la s?ret? et la r?sistance ? l'oppression. Giuseppe Mattioli CNR - ISTITUTO DI STRUTTURA DELLA MATERIA v. Salaria Km 29,300 - C.P. 10 I 00015 - Monterotondo Stazione (RM) Tel + 39 06 90672836 - Fax +39 06 90672316 E-mail:
[Pw_forum] pwscf 5.1 IO open error
Dear Prof. Paolo Giannozzi, Thank you for the quick reply. The workaround of setting initial spin polarization works. It seems if we let the code self consistently to get the result that BCC-Cu is nonmagnetic with a non zero starting_magnetization at the very beginning, the final scf check will runs fine. Well, we set the starting value as zero just want to save some time, because at least for the potential(from GBRV, I forgot to tell last time) we are using now, in different configurations containing Fe and Cu atoms, different value of starting_magnetization for Cu always leads to the same energy and magnetization value as the ones when starting_magnetization=0 for Cu. Seems the current code favors more to find this by itself ;) -- Yi Wang Ph.D candidate at Nanjing University of Science and Technology On Sun, 29 Jun 2014 17:03:07 +0800, Paolo Giannozzi wrote: > It is actually a bug, during the check for the unlikely > but not impossible case of a structural optimization > where the magnetization is lost during the process, > leading to a final nonmagnetic ground state, in a > system whose final configuration is instead magnetic. > Workaround: restart from the final configuration, allowing > an initial spin polarization. Removing the call to "wfcinit" > in move_ions.f90 should also work, but I didn't test it. > > Paolo > > On Fri, 2014-06-27 at 13:49 +0800, Yi Wang wrote: >> (I sent this mail previously, but wrongly used an unsubscribed mail >> address. Please ignore this if it is duplicated. Thank you for >> understanding.) >> >> Hi dear developers, >> >> When I use the 5.1 version, I may found a possible bug during vc-relax. >> I >> didn't see related threads in the listing, so I'm reporting it here. >> I'm using the pwscf version 5.1. For the attached input file >> 'pwscfrxf.rx.in', pw.x will fail at the final scf checking during >> vc-relax, error information is copied into 'errorinfo' file. The same >> input works fine for version 5.0.3. It appears the version 5.1 pw.x trys >> to open a file handler whose unit is already used/opened. Sorry I don't >> have the ability to further debug which file it trys to open again, I >> don't how to debug mpi codes with -g compile option. >> The error seems can be reproduced when there is no magnetization but >> nspin=2, however for magnetic systems--e.g. ferromagnetic alpha-Fe, the >> input runs fine. In my input the nspin is turned to 2 because it is >> automatically generated as one of a series of inputs for exploration in >> Fe-Cu alloys. >> >> >> -- >> Yi Wang >> Ph.D candidate at Nanjing University of Science and Technology >> ___ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://pwscf.org/mailman/listinfo/pw_forum > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] v5.0.2 phcg error (out of memory?)
Hi Prof, Thanks for your reply. ?I will try to recompile with those flags. As a side note, I have tried two other test cases. 1. I tried running my system on 1 processor with 110 GB memory. Phcg.x gave the same error. 2. Changed all potentials from the original PBE to LDA (pz-hgh). ?Phcg.x is running with these LDA potentials. 3. ?Reduced my system from 112 to 12 atoms but used the same PBE for the respective species. ?This reduced the required memory by a lot but Phcg.x gave the same error. Thanks, wee liat On Sunday, June 29, 2014 4:49 AM, Paolo Giannozzi wrote: On Thu, 2014-06-26 at 18:48 -0700, weeliat wrote: > > phcg.x:69448 terminated with signal 11 at PC=4bf379 SP=7fffa63067a0. >? Backtrace: > /home-research/espresso/bin/phcg.x(gradrho_+0x3c9)[0x4bf379] > The scf calculation run well with no errors.? I wonder if it is a PP > problem or out of memory issue? it is impossible to know without some further info. The error is in subroutine "gradrho". If you recompile with debug flags on (-g or something similar) you may discover the exact line number where the error happens Paolo -- Paolo Giannozzi, Dept. Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 -- next part -- An HTML attachment was scrubbed... URL: http://pwscf.org/pipermail/pw_forum/attachments/20140629/b52f53d0/attachment.html
[Pw_forum] pwscf 5.1 IO open error
It is actually a bug, during the check for the unlikely but not impossible case of a structural optimization where the magnetization is lost during the process, leading to a final nonmagnetic ground state, in a system whose final configuration is instead magnetic. Workaround: restart from the final configuration, allowing an initial spin polarization. Removing the call to "wfcinit" in move_ions.f90 should also work, but I didn't test it. Paolo On Fri, 2014-06-27 at 13:49 +0800, Yi Wang wrote: > (I sent this mail previously, but wrongly used an unsubscribed mail > address. Please ignore this if it is duplicated. Thank you for > understanding.) > > Hi dear developers, > > When I use the 5.1 version, I may found a possible bug during vc-relax. I > didn't see related threads in the listing, so I'm reporting it here. > I'm using the pwscf version 5.1. For the attached input file > 'pwscfrxf.rx.in', pw.x will fail at the final scf checking during > vc-relax, error information is copied into 'errorinfo' file. The same > input works fine for version 5.0.3. It appears the version 5.1 pw.x trys > to open a file handler whose unit is already used/opened. Sorry I don't > have the ability to further debug which file it trys to open again, I > don't how to debug mpi codes with -g compile option. > The error seems can be reproduced when there is no magnetization but > nspin=2, however for magnetic systems--e.g. ferromagnetic alpha-Fe, the > input runs fine. In my input the nspin is turned to 2 because it is > automatically generated as one of a series of inputs for exploration in > Fe-Cu alloys. > > > -- > Yi Wang > Ph.D candidate at Nanjing University of Science and Technology > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] Problem with vc-relax with pz pseudo potentials.
Dear Quantum Espresso users, Earlier I had knocked you about "Error in routine stop_exx (1): dft is not hybrid, wrong call" problem. Well the problem was quite solved. Whenever I used pbe pseudo potentials, the optimization converged. But if I use pz pseudo potentials, the simulation terminates saying: "Error in routine scale_h (1): Not enough space allocated for radial FFT: try restarting with a larger cell_factor." I have used larger cell_factor of 2, and tried with lattice parameter of 3 angstrom [The quantum espresso page said to use larger cell factor or larger unit cell] but the problem persists. I would like to mention again that the problem does not arise when I use pbe pseudo potentials. I have attached the input and output files, please let me know whether I am missing something or doing anything wrong. I had tried the simulation with both version 5.1 and 5.0.2. The results are all the same. Thank you in advance. -- next part -- An HTML attachment was scrubbed... URL: http://pwscf.org/pipermail/pw_forum/attachments/20140629/49090800/attachment.html -- next part -- A non-text attachment was scrubbed... Name: GBN1.vc-relax.inp Type: chemical/x-gamess-input Size: 1213 bytes Desc: not available Url : http://pwscf.org/pipermail/pw_forum/attachments/20140629/49090800/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: GBN1.vc-relax.out Type: application/octet-stream Size: 40175 bytes Desc: not available Url : http://pwscf.org/pipermail/pw_forum/attachments/20140629/49090800/attachment.obj
[Pw_forum] Problem about occupation number in elph calculation
On Thu, 2014-06-26 at 16:05 -0800, flying_lw at yeah.net wrote: > While you say the occupation numbers are not actually used, do you > mean that they have no effect to the integrated electron phonon > coupling coefficient? Or you mean the contribution from the k points > that show "NAN" occupation numbers are not counted for the integration > over reciprocal space? the latter you said. > Our Tc for MgB2 is much lower than experiment and previous QE results. > We wonder whether the NAN error for occupation number is part of the > reason. unlikely. Once again: electron-phonon coefficients calculations are tricky P. > > Thank you again for the help. > > > Wei Liu > > > > __ > flying_lw at yeah.net > > From: Paolo Giannozzi > Date: 2014-06-25 03:20 > To: PWSCF Forum > Subject: Re: [Pw_forum] Problem about occupation number in > elph calculation > I don't think that those occupation numbers are actually used. > If they are, you get NaN everywhere > > P. > > On Tue, 2014-06-24 at 10:10 -0800, flying_lw at yeah.net wrote: > > Dear Quantum Espresso users, > > > > > > I am using QE v 5.0.2 to calculate the Tc of MgB2. The job > is done > > normally, but I got one problem when I cheked the output > > file mgb2.elph.out. The occupation numbers of some k points > are 'NaN'. > > I did the same job using QE v 5.1, all the 'NaN' become > '0.'. I'm > > not sure what is happening. Will this cause something wrong > in the > > final results? > > > > > > Part of the output file is as below: > > > > > > % > > End of band structure calculation > > > > k = 0. 0. 0. band energies (ev): > > > > -33.3325 -33.3325 -33.3154 -3.7339 5.7105 9.0432 9.0432 > 10.2941 > > 15.0631 15.0631 16.8819 > > > > occupation numbers > > 1. 1. 1. 1. 1. 0.0368 0.0368 -0.0001 > > -0. -0. -0. > > > > k = 0. 0. 0.1089 band energies (ev): > > > > -33.3324 -33.3324 -33.3165 -3.5997 4.7550 9.0927 9.0927 > 11.5641 > > 15.1063 15.1063 16.8566 > > > > occupation numbers > > NaN NaN NaN NaN NaN NaN NaN NaN > > NaN NaN NaN > > > > k = 0. 0. 0.0363 band energies (ev): > > > > -33.3325 -33.3325 -33.3155 -3.7188 5.5783 9.0489 9.0489 > 10.4614 > > 15.0681 15.0681 16.8790 > > > > occupation numbers > > 1. 1. 1. 1. 1. 0.0333 0.0333 -0. > > -0. -0. -0. > > > > k = 0. 0. 0.1451 band energies (ev): > > > > -33.3324 -33.3324 -33.3172 -3.4981 4.2250 9.1283 9.1283 > 12.3377 > > 15.1375 15.1375 16.8387 > > > > occupation numbers > > NaN NaN NaN NaN NaN NaN NaN NaN > > NaN NaN NaN > > > > > > > > > > > > > > I have attached the input and output files. Thank you for > your help. > > > > > > Best, > > Wei > > > > > > > > > > > > ___ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://pwscf.org/mailman/listinfo/pw_forum > > -- > Paolo Giannozzi, Dept. Chemistry, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://pwscf.org/mailman/listinfo/pw_forum
[Pw_forum] v5.0.2 phcg error (out of memory?)
On Thu, 2014-06-26 at 18:48 -0700, weeliat wrote: > > phcg.x:69448 terminated with signal 11 at PC=4bf379 SP=7fffa63067a0. > Backtrace: > /home-research/espresso/bin/phcg.x(gradrho_+0x3c9)[0x4bf379] > The scf calculation run well with no errors. I wonder if it is a PP > problem or out of memory issue? it is impossible to know without some further info. The error is in subroutine "gradrho". If you recompile with debug flags on (-g or something similar) you may discover the exact line number where the error happens Paolo -- Paolo Giannozzi, Dept. Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] about kind of ibrav, cell parameters and thermo_pw.
On Sun, 2014-06-29 at 02:43 +0300, Mutlu COLAKOGULLARI wrote: > QUESTION: > How can I transform the above cell parameters to the correct kind of > ibrav type and celldm(1,...,6)? some time ago I wrote two routines (attached) that convert between different ways of specifying lattices. Not extensively tested, may not suit your needs etc. A smarter thing to do, however, is to modify the thermo_pw code in such a way that it accepts all QE specifications of the lattice. It should be rather simple, since internally QE only uses the primitive lattice vectors and the corresponding reciprocal lattice vectors (in units of the lattice parameter "a" and of 2pi/a respectively) P. -- Paolo Giannozzi, Dept. Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 -- next part -- A non-text attachment was scrubbed... Name: abc2celldm.f90 Type: text/x-fortran Size: 4797 bytes Desc: not available Url : http://pwscf.org/pipermail/pw_forum/attachments/20140629/b037ac4f/attachment.bin
[Pw_forum] Problem with vc-relax with pz pseudo potentials.
On Sun, 2014-06-29 at 10:56 +0600, Khalid Ibne Masood Khalid wrote: > Not enough space allocated for radial FFT: try restarting with a > larger cell_factor." restart from the last coordinates and cell (they are reprinted in a format that can be directly used in input) > I would like to mention again that the problem does not arise when I > use pbe pseudo potentials layered materials with intralayer vdW interactions behave quite differently with PBE and LDA (and both behave quite differently from reality) P. -- Paolo Giannozzi, Dept. Chemistry, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] about kind of ibrav, cell parameters and thermo_pw.
Hello, MAIN PROBLEM: I want to use thermo_pw code but it does not allow to use of ibrav=0. STORY: The conventional cell of crystalline interested is monoclinic type with Beta angle (ibrav=-12). In order to find primitive cell I used pymatgen code and then aconvasp-online. The final cell is MCLC5 type with cell parameters (W. Setyawan and S. Curtarolo's paper; http://arxiv.org/abs/1004.2974v1) as following: CELL_PARAMETERS angstrom 5.388 5.389500241922250.00 -5.3880005.389500241922250.00 0.002.71796558242205 15.42537623828894 I have tested the MCLC5 cell type with xcrysden-kpath visualization. Everything is looking fine to me. In pw.x code I can use it safely with ibrav=0 but thermo_pw code. The cell vectors are different from ibrav=12,-12,13. If I transform the Niggle form then I get the tricilinic type which is not proper for thermo_pw code, too. Here is the end of my knowledge. QUESTION: How can I transform the above cell parameters to the correct kind of ibrav type and celldm(1,...,6)? with my best wishes, Mutlu. -- PhD. Mutlu ?OLAKO?ULLARI Trakya ?niversitesi Fen Fak?ltesi Fizik B?l?m?
