From swblelia at sw.ehu.es Wed Feb 1 11:14:40 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Wed, 01 Feb 2006 11:14:40 +0100 Subject: [Pw_forum] about kpoints.x Message-ID: <1138788880.29217.66.camel@swpc50.sw.ehu.es> Hello all. I would like to know if the program kpoints.x is 100% reliable. I ask this question because if I create the following grid with kpoints.x: bravais lattice >> 4 filout [mesh_k] >> gg enter celldm(3) >> 6.5 mesh: n1 n2 n3 >> 14 14 1 mesh: k1 k2 k3 (0 no shift, 1 shifted) >> 1 1 0 write all k? [f] >> f # of k-points == 56 of 196 the total sum of the individual weights of each kpoint is 196. While if I create the same grid from an scf calculation the total sum is:2 So the question is, is there any problem behind or it is just a normalization issue. thanks a lot! Aritz From giannozz at nest.sns.it Wed Feb 1 11:59:12 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 1 Feb 2006 11:59:12 +0100 Subject: [Pw_forum] about kpoints.x In-Reply-To: <1138788880.29217.66.camel@swpc50.sw.ehu.es> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> Message-ID: <200602011159.12504.giannozz@nest.sns.it> On Wednesday 01 February 2006 11:14, Aritz Leonardo wrote: > I would like to know if the program kpoints.x is 100% reliable. nothing is 100% reliable, but that specific code is very simple > [...] So the question is, is there any problem behind > or it is just a normalization issue. the latter: the code will renormalize weights to yield the correct number of electrons Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From katalin.gaal-nagy at physik.uni-regensburg.de Wed Feb 1 12:06:34 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Wed, 1 Feb 2006 12:06:34 +0100 (CET) Subject: [Pw_forum] about kpoints.x In-Reply-To: <200602011159.12504.giannozz@nest.sns.it> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <200602011159.12504.giannozz@nest.sns.it> Message-ID: Dear Paolo, related to this issue I would like to add a question: The k-points are also used for phonons. In the past I assumed that I have to normalize the phonon DOS with respect to the sum of the weights. Is there anything similar for the phonons like in electronic calculation the renormalization with respect to the correct number of electrons, which I also should take into account? Best wishes, Katalin > >> I would like to know if the program kpoints.x is 100% reliable. > > nothing is 100% reliable, but that specific code is very simple > >> [...] So the question is, is there any problem behind >> or it is just a normalization issue. > > the latter: the code will renormalize weights to yield the correct > number of electrons > > Paolo > From ustunel at sissa.it Wed Feb 1 18:53:49 2006 From: ustunel at sissa.it (Hande Ustunel) Date: Wed, 1 Feb 2006 18:53:49 +0100 (CET) Subject: [Pw_forum] error using plotrho.x Message-ID: Hi, The message below was posted a little while back and the reply was related to redirection issues. However, I'm running into an identical problem in espresso-3.0 and I think it might be related to negative numbers in the charge density. When I use a preprocessed file that has negative numbers, plotrho.x fails with the identical message as given in the previous post. When I change all those numbers to positive and use the same input with redirection and everything being the same, it works. With my very limited fortran knowledge I couldn't see anything in the code that would fail for negative numbers save the logarithmic option but that seems to be checking for negative numbers already. Has negative numbers ever worked for anyone in the past? Thank you very much in advance for any help. Best wishes, Hande ORIGINAL MESSAGE : > Hi everybody, > HAPPY NEW YEAR .. > well i wanted to use plotrho.x file....but gives error message as: > > input file > r0 : 0.0000 0.0000 0.0000 > tau1 : 1.0000 1.0000 0.0000 > tau2 : 0.0000 0.0000 1.0000 > read 1 atomic positions > output file > Read 56 * 40 grid > Bounds: -0.179800 0.490500 > min, max, # of levels > forrtl: severe (59): list-directed I/O syntax > error, unit 5, file stdinImage PC Routine > Line Source > plotrho.x 084D1939 Unknown Unknown Unknown > plotrho.x 08495191 Unknown Unknown Unknown > plotrho.x 08495788 Unknown Unknown Unknown > plotrho.x 084B1748 Unknown Unknown Unknown > plotrho.x 084B0FD1 Unknown Unknown Unknown > plotrho.x 0804B60C Unknown Unknown Unknown > > Stack trace terminated abnormally. > > > do anybody know the solution to it? > > Thanks > -- > -- > ********************************************************** > BHALCHANDRA S. PUJARI. ------- REPLY > > forrtl: severe (59): list-directed I/O syntax error, unit 5, file stdin > > plotrho.x reads from standard input, i.e. from the terminal > ("unit 5, file stdin": stdin = standard input) and does not find > what it expects ("list-directed I/O syntax error", not exactly the > clearest message one can think of). If you are redirecting the > standard input to a file, as in "plotrho.x < somefile", it might > also mean that file "somefile" did not contain all the needed data. > > > does anybody know the solution to it? > > you have to give the correct input > > Paolo From giannozz at nest.sns.it Wed Feb 1 19:44:10 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 1 Feb 2006 19:44:10 +0100 Subject: [Pw_forum] Espresso and OpenMPI In-Reply-To: <20060131220605.76541.qmail@web52004.mail.yahoo.com> References: <20060131220605.76541.qmail@web52004.mail.yahoo.com> Message-ID: <200602011944.10637.giannozz@nest.sns.it> On Tuesday 31 January 2006 23:06, Konstantin Kudin wrote: > Both QE-3.0 and the latest CVS compiled with either OpenMPI 1.0.1 > or the latest CVS snapshot [1.0.2a4r8848] give the error below [...] > > forrtl: Input/output error > forrtl: severe (39): error during read, unit 5, file /dev/ptmx unit 5, /dev/ptmx ? are you sure it is not some stupid redirection problem ? did you try to read from file ? does it work with one processor? P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From konstantin_kudin at yahoo.com Wed Feb 1 19:55:25 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 1 Feb 2006 10:55:25 -0800 (PST) Subject: [Pw_forum] Espresso and OpenMPI In-Reply-To: <200602011944.10637.giannozz@nest.sns.it> Message-ID: <20060201185525.6145.qmail@web52014.mail.yahoo.com> Yeah, I found where it crashes. It does not like the end of file when reading the input: http://www.open-mpi.org/community/lists/users/2006/02/0553.php Kostya --- Paolo Giannozzi wrote: > On Tuesday 31 January 2006 23:06, Konstantin Kudin wrote: > > > Both QE-3.0 and the latest CVS compiled with either OpenMPI 1.0.1 > > or the latest CVS snapshot [1.0.2a4r8848] give the error below > [...] > > > > forrtl: Input/output error > > forrtl: severe (39): error during read, unit 5, file /dev/ptmx > > unit 5, /dev/ptmx ? are you sure it is not some stupid redirection > problem ? did you try to read from file ? does it work with one > processor? > > P. > > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Wed Feb 1 19:56:41 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 1 Feb 2006 19:56:41 +0100 Subject: [Pw_forum] about kpoints.x In-Reply-To: References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <200602011159.12504.giannozz@nest.sns.it> Message-ID: <200602011956.41756.giannozz@nest.sns.it> On Wednesday 01 February 2006 12:06, Katalin Gaal-Nagy wrote: > The k-points are also used for phonons. In the past I assumed that I have > to normalize the phonon DOS with respect to the sum of the weights. Is > there anything similar for the phonons like in electronic calculation the > renormalization with respect to the correct number of electrons, which I > also should take into account? I am not sure I understand your question. My statement that "the code will renormalize weights to yield the correct number of electrons" was actually misleading. The "weights" that are given as input data depend only on the symmetry: they are the number of k-points in the star of each k-point in the irreducible Brillouin Zone. Since however the code internally calculates \sum_k w_k and renormalises it to 1, it is sufficient that they are proportional to this quantity. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From swblelia at sw.ehu.es Wed Feb 1 20:18:02 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Wed, 01 Feb 2006 20:18:02 +0100 Subject: [Pw_forum] about kpoints.x In-Reply-To: <200602011956.41756.giannozz@nest.sns.it> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <200602011159.12504.giannozz@nest.sns.it> <200602011956.41756.giannozz@nest.sns.it> Message-ID: <1138821482.29217.102.camel@swpc50.sw.ehu.es> I understand that the explicit value of the weight is not important. What really matters is the proportion of each point. This is why I tried to compare the same grid obtained from an scf calculation and from the program kpoints.x The thing is that the obtained kpoints are different so there is no way to compare weights. I use kpoints.x to create grids for phonon calculations and I just wanted to assure that kpoints were correctly chosen using kpoints.x (and specially its weights) thank you again El mi?, 01-02-2006 a las 19:56 +0100, Paolo Giannozzi escribi?: > On Wednesday 01 February 2006 12:06, Katalin Gaal-Nagy wrote: > > > The k-points are also used for phonons. In the past I assumed that I have > > to normalize the phonon DOS with respect to the sum of the weights. Is > > there anything similar for the phonons like in electronic calculation the > > renormalization with respect to the correct number of electrons, which I > > also should take into account? > > I am not sure I understand your question. My statement that "the code > will renormalize weights to yield the correct number of electrons" was > actually misleading. The "weights" that are given as input data > depend only on the symmetry: they are the number of k-points in > the star of each k-point in the irreducible Brillouin Zone. Since > however the code internally calculates \sum_k w_k and renormalises > it to 1, it is sufficient that they are proportional to this quantity. > > Paolo From yay451 at mail.usask.ca Thu Feb 2 03:02:00 2006 From: yay451 at mail.usask.ca (Yansun Yao) Date: Wed, 01 Feb 2006 20:02:00 -0600 Subject: [Pw_forum] atomic displacements Message-ID: <1138845720.43e168181048e@webmail.usask.ca> Dear Pwscf users, I 'd like to confirm one point with you. In the output files of ph.x, e.g. si.dynG, are the atomic displacements written in Bohr? From the molden.out file generated by dynmat.x, it looks like so. Thank you in advance! Yansun University of Saskatchewan From dkorotin at gmail.com Thu Feb 2 07:33:53 2006 From: dkorotin at gmail.com (Dmitry Korotin) Date: Thu, 2 Feb 2006 11:33:53 +0500 Subject: [Pw_forum] real space mesh Message-ID: <2fd252650602012233k92b65e3x@mail.gmail.com> Dear pwscf users and authors, how can I get coordinates of points of FFT mesh in Bohr or Angstrom units? For example, I have an array psic(nrxxs) (which is FT of evc(ik,ibnd)). How can I find point in real space for psic(3) or psic(100)? Thank you in advance, Dmitry Korotin. From katalin.gaal-nagy at physik.uni-regensburg.de Thu Feb 2 09:42:43 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Thu, 2 Feb 2006 09:42:43 +0100 (CET) Subject: [Pw_forum] about kpoints.x In-Reply-To: <200602011956.41756.giannozz@nest.sns.it> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <200602011159.12504.giannozz@nest.sns.it> <200602011956.41756.giannozz@nest.sns.it> Message-ID: >> The k-points are also used for phonons. In the past I assumed that I have >> to normalize the phonon DOS with respect to the sum of the weights. Is >> there anything similar for the phonons like in electronic calculation the >> renormalization with respect to the correct number of electrons, which I >> also should take into account? > I am not sure I understand your question. My statement that "the code > will renormalize weights to yield the correct number of electrons" was > actually misleading. The "weights" that are given as input data > depend only on the symmetry: they are the number of k-points in > the star of each k-point in the irreducible Brillouin Zone. Since > however the code internally calculates \sum_k w_k and renormalises > it to 1, it is sufficient that they are proportional to this quantity. Now it is clear for me. The fact, that the sum of the weights is giving some number (e.g. 2) is just by chance and there is no deep meaning behind. It could have even been 42. Grazie! Katalin From roma at srmp19.saclay.cea.fr Thu Feb 2 10:13:04 2006 From: roma at srmp19.saclay.cea.fr (Guido Roma) Date: Thu, 02 Feb 2006 10:13:04 +0100 Subject: [Pw_forum] about kpoints.x In-Reply-To: <1138821482.29217.102.camel@swpc50.sw.ehu.es> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <200602011159.12504.giannozz@nest.sns.it> <200602011956.41756.giannozz@nest.sns.it> <1138821482.29217.102.camel@swpc50.sw.ehu.es> Message-ID: <1138871584.28983.105.camel@srmp19.saclay.cea.fr> On Wed, 2006-02-01 at 20:18, Aritz Leonardo wrote: > This is why I tried to compare the same grid obtained from an scf > calculation and from the program kpoints.x > > The thing is that the obtained kpoints are different so there is no way > to compare weights. Hello, could you please post the two meshes? I think I recognise in kpoints.f (at least for the main structure) a small program that I wrote several years ago for the hexagonal lattice (and then extended to other lattices) using pwscf modules (latgen, recips, cubicsym, hexsym). So I would be suprised if that bravais lattice, in particular, was buggy. But, as Paolo says, 100% is not given to us ... Guido -- Guido Roma -- CEA-Saclay - DEN/DMN/SRMP Bat.520/130 Phone: [+33]-1-69085738 -- Fax: ...6867 -- Mobile: [+33]-6-20069085 From baroni at sissa.it Thu Feb 2 10:21:43 2006 From: baroni at sissa.it (Stefano Baroni) Date: Thu, 2 Feb 2006 10:21:43 +0100 Subject: [Pw_forum] real space mesh In-Reply-To: <2fd252650602012233k92b65e3x@mail.gmail.com> References: <2fd252650602012233k92b65e3x@mail.gmail.com> Message-ID: The index of arrays used to store functions defined on 3D meshes is actually a shorthand for three indeces, following the FORTRAN convention ("leftmost index runs faster"). An example will explain this better. Suppose you have a 3D array of dimension (nr1,nr2,nr3), say psi(nr1,nr2,nr3). FORTRAN compilers store this array sequentially in the computer RAM in the following way: psi(1,1,1) psi(2,1,1) ... psi(nr1,1,1) psi(1,2,1) psi(2,2,1) ... psi(nr1,2,1) ... psi(nr1,nr2,1) psi(1,1,nr3) etc Let "ind" be the position of the (i,j,k) element in the above list: the relation between ind and (i,j,k) is: ind = i + (j-1)*nr1 + (k-1)*nr2*nr1 This should clarify the relation between 1D and 3D indexing. In real space, the (i,j,k) point of the mesh is (i-1)*tau_1 + (j-1)*tau_2 + (k-1)* tau_3 where the tau's are the basis vectors of the Bravais lattice. The latter are stored row-wise in the "AT" array: tau_1 = at(1,*) tau_2 = at(2,*) tau_3 = at(3,*) (or at least so it was the last time I looked into the code ;-) Hope this helps Stefano B. On Feb 2, 2006, at 7:33 AM, Dmitry Korotin wrote: > Dear pwscf users and authors, > how can I get coordinates of points of FFT mesh in Bohr or > Angstrom units? > For example, I have an array psic(nrxxs) (which is FT of > evc(ik,ibnd)). How can I find point in real space for psic(3) or > psic(100)? > > Thank you in advance, > Dmitry Korotin. > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum --- Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060202/ccda04e9/attachment.htm From giannozz at nest.sns.it Thu Feb 2 10:32:06 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Feb 2006 10:32:06 +0100 Subject: [Pw_forum] about kpoints.x In-Reply-To: <1138871584.28983.105.camel@srmp19.saclay.cea.fr> References: <1138788880.29217.66.camel@swpc50.sw.ehu.es> <1138821482.29217.102.camel@swpc50.sw.ehu.es> <1138871584.28983.105.camel@srmp19.saclay.cea.fr> Message-ID: <200602021032.06498.giannozz@nest.sns.it> On Thursday 02 February 2006 10:13, Guido Roma wrote: > > The thing is that the obtained kpoints are different so there > > is no way to compare weights. > could you please post the two meshes? > I think I recognise in kpoints.f (at least for the main structure) a > small program that I wrote several years ago for the hexagonal lattice > (and then extended to other lattices) using pwscf modules (latgen, > recips, cubicsym, hexsym). So I would be suprised if that bravais > lattice, in particular, was buggy. I agree. K-points produced by kpoints.f should be the same, or an equivalent set, of those produced by the pw.x code. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Feb 2 10:45:59 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Feb 2006 10:45:59 +0100 Subject: [Pw_forum] real space mesh In-Reply-To: References: <2fd252650602012233k92b65e3x@mail.gmail.com> Message-ID: <200602021045.59812.giannozz@nest.sns.it> On Thursday 02 February 2006 10:21, Stefano Baroni wrote: > In real space, the (i,j,k) point of the mesh is > > (i-1)*tau_1 + (j-1)*tau_2 + (k-1)* tau_3 > > where the tau's are the basis vectors of the Bravais lattice. actually it is r(i,j,k) = (i-1)*tau_1/nr1 + (j-1)*tau_2/nr2 + (k-1)* tau_3/nr3 where nr1, nr2, nr3 are the dimensions of the FFT in the three crystal axis. Note that r(nr1,j,k) is equivalent to r(1,j,k) and so on because of periodic boundary conditions. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From swblelia at sw.ehu.es Thu Feb 2 11:13:16 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 02 Feb 2006 11:13:16 +0100 Subject: [Pw_forum] about kpoints.x Message-ID: <1138875196.4715.8.camel@swpc50.sw.ehu.es> Mesh obtained with kpoints.x ibrav:4 c/a:6.5 14 14 1 1 1 0 1 0.0357143 0.0618590 0.0000000 2.00 2 0.1071429 0.1030983 0.0000000 4.00 3 0.1785714 0.1443376 0.0000000 4.00 4 0.2500000 0.1855769 0.0000000 4.00 5 0.3214286 0.2268162 0.0000000 4.00 6 0.3928571 0.2680555 0.0000000 4.00 7 0.4642857 0.3092948 0.0000000 4.00 8 0.5357143 0.3505341 0.0000000 4.00 9 0.6071429 0.3917734 0.0000000 4.00 10 0.6785714 0.4330127 0.0000000 4.00 11 0.7500000 0.4742520 0.0000000 4.00 12 0.8214286 0.5154913 0.0000000 4.00 13 0.8928571 0.5567306 0.0000000 4.00 14 0.9642857 0.5979699 0.0000000 2.00 15 0.1071429 0.1855769 0.0000000 2.00 16 0.1785714 0.2268162 0.0000000 4.00 17 0.2500000 0.2680555 0.0000000 4.00 18 0.3214286 0.3092948 0.0000000 4.00 19 0.3928571 0.3505341 0.0000000 4.00 20 0.4642857 0.3917734 0.0000000 4.00 21 0.5357143 0.4330127 0.0000000 4.00 22 0.6071429 0.4742520 0.0000000 4.00 23 0.6785714 0.5154913 0.0000000 4.00 24 0.7500000 0.5567306 0.0000000 4.00 25 0.8214286 0.5979699 0.0000000 4.00 26 0.8928571 0.6392092 0.0000000 2.00 27 0.1785714 0.3092948 0.0000000 2.00 28 0.2500000 0.3505341 0.0000000 4.00 29 0.3214286 0.3917734 0.0000000 4.00 30 0.3928571 0.4330127 0.0000000 4.00 31 0.4642857 0.4742520 0.0000000 4.00 32 0.5357143 0.5154913 0.0000000 4.00 33 0.6071429 0.5567306 0.0000000 4.00 34 0.6785714 0.5979699 0.0000000 4.00 35 0.7500000 0.6392092 0.0000000 4.00 36 0.8214286 0.6804485 0.0000000 2.00 37 0.2500000 0.4330127 0.0000000 2.00 38 0.3214286 0.4742520 0.0000000 4.00 39 0.3928571 0.5154913 0.0000000 4.00 40 0.4642857 0.5567306 0.0000000 4.00 41 0.5357143 0.5979699 0.0000000 4.00 42 0.6071429 0.6392092 0.0000000 4.00 43 0.6785714 0.6804485 0.0000000 4.00 44 0.7500000 0.7216878 0.0000000 2.00 45 0.3214286 0.5567306 0.0000000 2.00 46 0.3928571 0.5979699 0.0000000 4.00 47 0.4642857 0.6392092 0.0000000 4.00 48 0.5357143 0.6804485 0.0000000 4.00 49 0.6071429 0.7216878 0.0000000 4.00 50 0.6785714 0.7629271 0.0000000 2.00 51 0.3928571 0.6804485 0.0000000 2.00 52 0.4642857 0.7216878 0.0000000 4.00 53 0.5357143 0.7629271 0.0000000 4.00 54 0.6071429 0.8041664 0.0000000 2.00 55 0.4642857 0.8041664 0.0000000 2.00 56 0.5357143 0.8454058 0.0000000 2.00 The same obtained with scf: k( 1) = ( 0.0357143 0.0618590 0.0000000), wk = 0.0204082 k( 2) = ( 0.0357143 0.1443376 0.0000000), wk = 0.0408163 k( 3) = ( 0.0357143 0.2268162 0.0000000), wk = 0.0408163 k( 4) = ( 0.0357143 0.3092948 0.0000000), wk = 0.0408163 k( 5) = ( 0.0357143 0.3917734 0.0000000), wk = 0.0408163 k( 6) = ( 0.0357143 0.4742520 0.0000000), wk = 0.0408163 k( 7) = ( 0.0357143 0.5567306 0.0000000), wk = 0.0408163 k( 8) = ( 0.0357143 -0.5154913 0.0000000), wk = 0.0408163 k( 9) = ( 0.0357143 -0.4330127 0.0000000), wk = 0.0408163 k( 10) = ( 0.0357143 -0.3505341 0.0000000), wk = 0.0408163 k( 11) = ( 0.0357143 -0.2680555 0.0000000), wk = 0.0408163 k( 12) = ( 0.0357143 -0.1855769 0.0000000), wk = 0.0408163 k( 13) = ( 0.0357143 -0.1030983 0.0000000), wk = 0.0408163 k( 14) = ( 0.0357143 -0.0206197 0.0000000), wk = 0.0204082 k( 15) = ( 0.1071429 0.1855769 0.0000000), wk = 0.0204082 k( 16) = ( 0.1071429 0.2680555 0.0000000), wk = 0.0408163 k( 17) = ( 0.1071429 0.3505341 0.0000000), wk = 0.0408163 k( 18) = ( 0.1071429 0.4330127 0.0000000), wk = 0.0408163 k( 19) = ( 0.1071429 0.5154913 0.0000000), wk = 0.0408163 k( 20) = ( 0.1071429 0.5979699 0.0000000), wk = 0.0408163 k( 21) = ( 0.1071429 -0.4742520 0.0000000), wk = 0.0408163 k( 22) = ( 0.1071429 -0.3917734 0.0000000), wk = 0.0408163 k( 23) = ( 0.1071429 -0.3092948 0.0000000), wk = 0.0408163 k( 24) = ( 0.1071429 -0.2268162 0.0000000), wk = 0.0408163 k( 25) = ( 0.1071429 -0.1443376 0.0000000), wk = 0.0408163 k( 26) = ( 0.1071429 -0.0618590 0.0000000), wk = 0.0204082 k( 27) = ( 0.1785714 0.3092948 0.0000000), wk = 0.0204082 k( 28) = ( 0.1785714 0.3917734 0.0000000), wk = 0.0408163 k( 29) = ( 0.1785714 0.4742520 0.0000000), wk = 0.0408163 k( 30) = ( 0.1785714 0.5567306 0.0000000), wk = 0.0408163 k( 31) = ( 0.1785714 0.6392092 0.0000000), wk = 0.0408163 k( 32) = ( 0.1785714 -0.4330127 0.0000000), wk = 0.0408163 k( 33) = ( 0.1785714 -0.3505341 0.0000000), wk = 0.0408163 k( 34) = ( 0.1785714 -0.2680555 0.0000000), wk = 0.0408163 k( 35) = ( 0.1785714 -0.1855769 0.0000000), wk = 0.0408163 k( 36) = ( 0.1785714 -0.1030983 0.0000000), wk = 0.0204082 k( 37) = ( 0.2500000 0.4330127 0.0000000), wk = 0.0204082 k( 38) = ( 0.2500000 0.5154913 0.0000000), wk = 0.0408163 k( 39) = ( 0.2500000 0.5979699 0.0000000), wk = 0.0408163 k( 40) = ( 0.2500000 0.6804485 0.0000000), wk = 0.0408163 k( 41) = ( 0.2500000 -0.3917734 0.0000000), wk = 0.0408163 k( 42) = ( 0.2500000 -0.3092948 0.0000000), wk = 0.0408163 k( 43) = ( 0.2500000 -0.2268162 0.0000000), wk = 0.0408163 k( 44) = ( 0.2500000 -0.1443376 0.0000000), wk = 0.0204082 k( 45) = ( 0.3214286 0.5567306 0.0000000), wk = 0.0204082 k( 46) = ( 0.3214286 0.6392092 0.0000000), wk = 0.0408163 k( 47) = ( 0.3214286 0.7216878 0.0000000), wk = 0.0408163 k( 48) = ( 0.3214286 -0.3505341 0.0000000), wk = 0.0408163 k( 49) = ( 0.3214286 -0.2680555 0.0000000), wk = 0.0408163 k( 50) = ( 0.3214286 -0.1855769 0.0000000), wk = 0.0204082 k( 51) = ( 0.3928571 0.6804485 0.0000000), wk = 0.0204082 k( 52) = ( 0.3928571 0.7629271 0.0000000), wk = 0.0408163 k( 53) = ( 0.3928571 -0.3092948 0.0000000), wk = 0.0408163 k( 54) = ( 0.3928571 -0.2268162 0.0000000), wk = 0.0204082 k( 55) = ( 0.4642857 0.8041664 0.0000000), wk = 0.0204082 k( 56) = ( 0.4642857 -0.2680555 0.0000000), wk = 0.0204082 From giannozz at nest.sns.it Thu Feb 2 11:50:53 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Feb 2006 11:50:53 +0100 Subject: [Pw_forum] error using plotrho.x In-Reply-To: References: Message-ID: <200602021150.53483.giannozz@nest.sns.it> On Wednesday 01 February 2006 18:53, Hande Ustunel wrote: > The message below was posted a little while back and the reply was > related to redirection issues. However, I'm running into an identical > problem if it is an "identical" problem, i.e. with the same error message, the solution is also identical: it is a problem with input data. It cannot be anything else: notice where the code stops, and "unit 5, stdin" : > min, max, # of levels > forrtl: severe (59): list-directed I/O syntax > error, unit 5, file stdin I have used in the past that code to plot charge density differences, so it works with negative numbers as well. One possible source of trouble is the following: if the format of the data to be plotted (in the input file) does not expect negative numbers, and if there is a single space separating different numbers, this could be filled by the "-" . This would cause for sure a failure when reading the data file (unit 1, not unit 5) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From dkorotin at gmail.com Thu Feb 2 11:53:27 2006 From: dkorotin at gmail.com (Dmitry Korotin) Date: Thu, 2 Feb 2006 15:53:27 +0500 Subject: [Pw_forum] real space mesh In-Reply-To: <200602021045.59812.giannozz@nest.sns.it> References: <2fd252650602012233k92b65e3x@mail.gmail.com> <200602021045.59812.giannozz@nest.sns.it> Message-ID: <2fd252650602020253x51095bcdl@mail.gmail.com> Thank you very much for your answers. Dmitry Korotin. From degironc at sissa.it Thu Feb 2 13:00:03 2006 From: degironc at sissa.it (Stefano de Gironcoli) Date: Thu, 02 Feb 2006 13:00:03 +0100 Subject: [Pw_forum] about kpoints.x References: <1138875196.4715.8.camel@swpc50.sw.ehu.es> Message-ID: <43E1F443.1090601@sissa.it> the two mesh should be equivalent even if not identical I include a simple plot of the two meshes in 2D: kpoints.x gives a regular mesh in a triangle (the Irreducible Wedge) pwscf.x gives also a regular mesh in an Irreducible Wedge that looks more complicated but is a reflection of the previous one w.r.t. the line from Gamma to M point (the center of the hexagon side) if the triangle on the (y<0) semiplane is shifted upward by 2/sqrt(3) using periodicity. Beware that in hexagonal lattice shifted grids produce grids that do not have the full hexagonal symmetry. This is why the apparent dimension of the Irreducible Wedge in the plot is larger than one would expect. Try to feed the two meshes to pwscf in a sample calculation with otherwise identical parameters. If the final energy, forces etc are identical the two meshes are likely to be equivalent. stefano -------------- next part -------------- A non-text attachment was scrubbed... Name: kpoints_vs_pwscf.ps Type: application/postscript Size: 13545 bytes Desc: not available Url : /pipermail/attachments/20060202/9bd19154/attachment.ps From giannozz at nest.sns.it Thu Feb 2 16:58:23 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Feb 2006 16:58:23 +0100 Subject: [Pw_forum] atomic displacements In-Reply-To: <1138845720.43e168181048e@webmail.usask.ca> References: <1138845720.43e168181048e@webmail.usask.ca> Message-ID: <200602021658.23213.giannozz@nest.sns.it> On Thursday 02 February 2006 03:02, Yansun Yao wrote: > I 'd like to confirm one point with you. In the output files of ph.x, > e.g. si.dynG, are the atomic displacements written in Bohr? you already asked the same question in December. Once again: normal modes |v> are normalized to 1 (=1); eigendisplacements are |u> = M^(-1/2) | v> and thus are in units of masses^(-1/2). Masses are in atomic rydberg units: mass of one electron = 0.5, one atomic mass unit = 911.444 -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From ustunel at sissa.it Thu Feb 2 17:03:02 2006 From: ustunel at sissa.it (Hande Ustunel) Date: Thu, 2 Feb 2006 17:03:02 +0100 (CET) Subject: [Pw_forum] error using plotrho.x In-Reply-To: <200602021150.53483.giannozz@nest.sns.it> References: <200602021150.53483.giannozz@nest.sns.it> Message-ID: > if it is an "identical" problem, i.e. with the same error message, the > solution is also identical: it is a problem with input data. It cannot be > anything else: notice where the code stops, and "unit 5, stdin" : Indeed, this was the case. When there are negative densities, the (y/n)-sort of selection about the logartihmic display should be skipped in the input if it is being redirected instead of being read from terminal. Thanks a lot for the help. Hande From yay451 at mail.usask.ca Thu Feb 2 17:28:48 2006 From: yay451 at mail.usask.ca (Yansun Yao) Date: Thu, 02 Feb 2006 10:28:48 -0600 Subject: [Pw_forum] atomic displacements In-Reply-To: <200602021658.23213.giannozz@nest.sns.it> References: <1138845720.43e168181048e@webmail.usask.ca> <200602021658.23213.giannozz@nest.sns.it> Message-ID: <1138897728.43e23340336bd@webmail.usask.ca> Hello Paolo, Thank you so much for answering same question. By some reason I couldn't find my previous question. Very sorry for asking again. Yansun From lijun_physics at yahoo.com.cn Sun Feb 5 11:53:49 2006 From: lijun_physics at yahoo.com.cn (Lijun Zhang) Date: Sun, 5 Feb 2006 18:53:49 +0800 (CST) Subject: [Pw_forum] A soft phonon at Gamma point Message-ID: <20060205105349.52789.qmail@web15605.mail.cnb.yahoo.com> Dear all, I am doing some calculations on pressure-induced phase transitions. With increasing pressures, It is found that a mode softens exactly at Gamma point.(higher pressure, more negative value) Does it represent a phonon instability or an elastic instability? Thank you in advance. Lijun Zhang __________________________________________________ ??????????????? http://cn.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060205/7b82e295/attachment.htm From wyxpwscf at yahoo.com Mon Feb 6 07:26:05 2006 From: wyxpwscf at yahoo.com (y wang) Date: Sun, 5 Feb 2006 22:26:05 -0800 (PST) Subject: [Pw_forum] fix lattice constant Message-ID: <20060206062605.53469.qmail@web35108.mail.mud.yahoo.com> Dear all, I want to calculate the strained PbTiO3. How to perform a relaxation with only fixed lattice constant a? In other words, lattice constant a is fixed; c and atomic position will be optimized. How to set parameters in input file? Best Wang Y X --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060205/7a7d0d89/attachment.htm From konstantin_kudin at yahoo.com Mon Feb 6 18:08:42 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 6 Feb 2006 09:08:42 -0800 (PST) Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: Message-ID: <20060206170842.61226.qmail@web52013.mail.yahoo.com> Hi all, I have investigated a bit the FFT issue during parallel runs. The key MPI communication routines are fft_transpose and fft_scatter from the module Modules/fft_base.f90 First, it appears that by default "fft_transpose" uses a bunch of "mpi_isend" and "mpi_irecv" instead of "mpi_alltoall". Most MPI implementations suck a lot more with these isend and irecv as opposed to alltoall (which is way easier to handle efficiently). The routine using mpi_alltoall can be readily enabled in fft_base.f90 by a preprocessing directive, and it appears to work. So why is it not the default ? Another potentially sucky part is "mpi_alltoallv" in the fft_scatter. This one depends on the cleverness of the MPI implementation significantly. There is some hope that Open-MPI people will pay some attention to these performance issues, and so that could become the MPI of choice for the usual circumstances. Finally, has there been any activity on fftw3 ? Since it appears that parallel transforms from fftw2 are not used, then fftw3 should be just as usable ... Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Mon Feb 6 20:44:40 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 6 Feb 2006 20:44:40 +0100 Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: <20060206170842.61226.qmail@web52013.mail.yahoo.com> References: <20060206170842.61226.qmail@web52013.mail.yahoo.com> Message-ID: <200602062044.40116.giannozz@nest.sns.it> On Monday 06 February 2006 18:08, Konstantin Kudin wrote: > Another potentially sucky part is "mpi_alltoallv" in the fft_scatter. > This one depends on the cleverness of the MPI implementation > significantly. "mpi_alltoallv" is used instead of "mpi_alltoall" (without 'v') because the slices into which the r-space grid is cut along direction 3 may not be all of the same size. Of course the special case in which all the slices are equal could be quite easily treated with mpi_alltoall, if it is really useful; or one could do copies and use mpi_alltoall. I would expect the library to take care of this, though. > Finally, has there been any activity on fftw3 ? no, and I don't think there will be any, since fftw3 seems to be no longer actively maintained and the preliminary results were not clearly in favor of fftw3 P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From akohlmey at vitae.cmm.upenn.edu Mon Feb 6 21:04:23 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Mon, 6 Feb 2006 15:04:23 -0500 (EST) Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: <200602062044.40116.giannozz@nest.sns.it> Message-ID: On Mon, 6 Feb 2006, Paolo Giannozzi wrote: PG> On Monday 06 February 2006 18:08, Konstantin Kudin wrote: PG> [...] PG> > Finally, has there been any activity on fftw3 ? PG> PG> no, and I don't think there will be any, since fftw3 seems to be no PG> longer actively maintained and the preliminary results were not PG> clearly in favor of fftw3 hi paolo, i just saw this on the fftw homepage. The FFTW Release Notes This document describes the new features and changes in each release of FFTW. FFTW 3.1 January 28, 2006 * Faster FFTW_ESTIMATE planner. * New (faster) algorithm for REDFT00/RODFT00 (type-I DCT/DST) of odd size. * "4-step" algorithm for faster FFTs of very large sizes (> 2^18). * Faster in-place real-data DFTs (for R2HC and HC2R r2r formats). looks active to me. :-) ciao, axel. PG> PG> P. PG> PG> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From konstantin_kudin at yahoo.com Mon Feb 6 22:06:43 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 6 Feb 2006 13:06:43 -0800 (PST) Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: <200602062044.40116.giannozz@nest.sns.it> Message-ID: <20060206210644.8958.qmail@web52006.mail.yahoo.com> --- Paolo Giannozzi wrote: > > "mpi_alltoallv" is used instead of "mpi_alltoall" (without 'v') > because > the slices into which the r-space grid is cut along direction 3 may > not be all of the same size. Of course the special case in which all > the slices are equal could be quite easily treated with mpi_alltoall, > if it is really useful; or one could do copies and use mpi_alltoall. > I would expect the library to take care of this, though. Well, here is an interesting paper that compares "alltoall" with "alltoallv", and it seems like optimizing the former is way easier because the communication pattern is fully known: http://www.spscicomp.org/ScicomP11/Presentations/User/booth.pdf I've been playing here with the skampi benchmark http://liinwww.ira.uka.de/~skampi/skampi4.1.tar.gz, and both for MPICH and Open-MPI the results suck the least when "alltoall" is employed. This Open-MPI is actually extremely nice for SMP+Gigabit, and behaves a lot more consistently than MPICH1. In their latest CVS the "alltoall" already works reasonably well, while "isend-irecv" and "alltoallv" suck really really badly for 8 cpus. While they promised to look at the issue, I think sticking with "alltoall" is the optimal long term strategy if QE is going to rely mostly on free MPI implementations. MPICH1 also works best with "alltoall". Here are the numbers for this: http://www.princeton.edu/~kkudin/skampi_mpich.txt http://www.princeton.edu/~kkudin/skampi_openmpi.txt Thus going to "alltoall" for everything FFT related could be very helpful for scaling with Gigabit ... Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From baroni at sissa.it Mon Feb 6 22:15:20 2006 From: baroni at sissa.it (Stefano Baroni) Date: Mon, 6 Feb 2006 22:15:20 +0100 Subject: [Pw_forum] A soft phonon at Gamma point In-Reply-To: <20060205105349.52789.qmail@web15605.mail.cnb.yahoo.com> References: <20060205105349.52789.qmail@web15605.mail.cnb.yahoo.com> Message-ID: <3E4100D0-A694-49A2-B89F-CB8146271A23@sissa.it> Hi Lijun Zhang. I would say it is a phonon instability (like the one occurring in ferroelectricity). An elastic instability would be signaled by a sound velocity going to zero. SB On Feb 5, 2006, at 11:53 AM, Lijun Zhang wrote: > Dear all, > I am doing some calculations on pressure-induced phase transitions. > With increasing pressures, It is found that a mode softens exactly > at Gamma > point.(higher pressure, more negative value) Does it represent a > phonon instability or an elastic instability? > Thank you in advance. > > Lijun Zhang > > __________________________________________________ > ??????????????? > http://cn.mail.yahoo.com --- Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060206/08372091/attachment.htm From giannozz at nest.sns.it Tue Feb 7 14:34:30 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 7 Feb 2006 14:34:30 +0100 Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: References: Message-ID: <200602071434.30733.giannozz@nest.sns.it> On Monday 06 February 2006 21:04, Axel Kohlmeyer wrote: > The FFTW Release Notes > This document describes the new features and changes in each release of > FFTW. FFTW 3.1 > January 28, 2006 > [...] > looks active to me. :-) good to know, thank you. I had the impression that the authors of the preliminary support for FFTW3 (Pascal Thibaudeau and Stephane Lefranc) were not enthusiastic about the performances of FFTW3. What they did is available here: http://web1.sns.it/~giannozz/public/fft_scalar_fftw3.f90 Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From afloris at physik.fu-berlin.de Tue Feb 7 20:12:52 2006 From: afloris at physik.fu-berlin.de (Andrea Floris) Date: Tue, 7 Feb 2006 20:12:52 +0100 (CET) Subject: [Pw_forum] band calculation in parallel Message-ID: Dear users, I run in parallel a band structure calculation for MgB2, i.e. giving the explicit path of k-points in a nscf calculation, after a scf calculation. With versions 2.1.5 and 3.0 I have noticed that the nscf calculation does not produce any output, and it is basically stacked (whereas, with the same input, the serial version works off course). This happens *only* when the k-points are given explicitly (with the automatic mode is fine). I am using the following set up: pwscf version: 2.1.5 and 3.0 compiler: pgi 5.2-4 mpi: mpich2 Has anyone else experienced the same problem? thanks, Andrea From afloris at physik.fu-berlin.de Tue Feb 7 21:06:06 2006 From: afloris at physik.fu-berlin.de (Andrea Floris) Date: Tue, 7 Feb 2006 21:06:06 +0100 (CET) Subject: [Pw_forum] forces in parallel espresso 3.0 Message-ID: Dear users, I am running in parallel a scf calculation, with the setup: pwscf version: 3.0 compiler: pgi 5.2-4 mpi: mpich2 system: cluster OPTERON 64-bit I want to report that within my setup, pw.x crashes when it calculates the forces, (i.e. when including tprnfor = .true. in the namelist &control), producing the message: ---------------------- ..... rank 3 in job 1 n34_16977 caused collective abort of all ranks exit status of rank 3: killed by signal 11 rank 2 in job 1 n34_16977 caused collective abort of all ranks exit status of rank 2: killed by signal 11 rank 1 in job 1 n34_16977 caused collective abort of all ranks exit status of rank 1: killed by signal 11 ------------------------ With previous versions this doesn't happen. And it doesn't happen also with version 3.0 running in serial... Has this happened in other setup? many thanks ciao, Andrea From naromero at gmail.com Tue Feb 7 23:31:45 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 7 Feb 2006 17:31:45 -0500 Subject: [Pw_forum] box grid in cp Message-ID: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> Hi, This is in reference to CP in Quantum-Espresso 3.0. What exactly is nr1b, nr2b, nr3b? Are they at all related to ecutwfc or ecutrho? Thanks, -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From akohlmey at vitae.cmm.upenn.edu Wed Feb 8 00:04:41 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Tue, 7 Feb 2006 18:04:41 -0500 (EST) Subject: [Pw_forum] forces in parallel espresso 3.0 In-Reply-To: Message-ID: On Tue, 7 Feb 2006, Andrea Floris wrote: AF> Dear users, AF> I am running in parallel a scf calculation, AF> with the setup: AF> AF> pwscf version: 3.0 AF> compiler: pgi 5.2-4 andrea, can you please try with a different compiler. pgi-5.x, especially the opteron variants are known to miscompile several parts in differnt DFT codes. this may be one of the cases. does the crash also happen in the serial case? ciao, axel. AF> mpi: mpich2 AF> system: cluster OPTERON 64-bit AF> AF> I want to report that within my setup, pw.x crashes when it calculates AF> the forces, (i.e. when including tprnfor = .true. in the namelist AF> &control), producing AF> the message: AF> ---------------------- AF> ..... AF> rank 3 in job 1 n34_16977 caused AF> collective abort of all ranks exit status of rank 3: killed by signal 11 AF> rank 2 in job 1 n34_16977 caused collective abort of all ranks AF> exit status of rank 2: killed by signal 11 AF> rank 1 in job 1 n34_16977 caused collective abort of all ranks AF> exit status of rank 1: killed by signal 11 AF> ------------------------ AF> AF> With previous versions this doesn't happen. And it doesn't happen also AF> with version 3.0 running in serial... AF> Has this happened in other setup? AF> AF> many thanks AF> ciao, AF> Andrea AF> _______________________________________________ AF> Pw_forum mailing list AF> Pw_forum at pwscf.org AF> http://www.democritos.it/mailman/listinfo/pw_forum AF> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From marzari at MIT.EDU Wed Feb 8 03:39:24 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Tue, 07 Feb 2006 21:39:24 -0500 Subject: [Pw_forum] box grid in cp In-Reply-To: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> References: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> Message-ID: <43E959DC.1040103@mit.edu> Dear Nichols, ecutrho defines a corresponding resolution on the real space FFT mesh (as expressed by nr1, nr2 and nr3, that the code left on its own sets automatically). In the ultrasoft case we refer to this mesh as the "hard" mesh, since it is denser than the smooth mesh that is needed to represent the square of the non-norm-conserving wavefunctions. On this "hard", fine-spaced mesh, you need to determine the size of the cube that will encompass the largest of the augmentation charges - this is what nr1b/2b/3b are. So, nr1b is independent of the system size, but dependent on the size of the augmentation charge (that doesn't vary that much) and on the real-space resolution needed by augmentation charges (rule of thumb: ecutrho is between 6 and 12 times ecutwfc). In practice, nr1b et al. are often in the region of 20-24-28; testing seems again a necessity (unless the code started automagically to estimate these). nicola Nichols A. Romero wrote: > Hi, > > This is in reference to CP in Quantum-Espresso 3.0. > > What exactly is nr1b, nr2b, nr3b? > > Are they at all related to ecutwfc or ecutrho? > > Thanks, > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From konstantin_kudin at yahoo.com Wed Feb 8 05:11:58 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 7 Feb 2006 20:11:58 -0800 (PST) Subject: [Pw_forum] parallel FFTs - important MPI considerations In-Reply-To: <200602071434.30733.giannozz@nest.sns.it> Message-ID: <20060208041158.9336.qmail@web52004.mail.yahoo.com> --- Paolo Giannozzi wrote: > good to know, thank you. I had the impression that the authors of > the preliminary support for FFTW3 (Pascal Thibaudeau and Stephane > Lefranc) were not enthusiastic about the performances of FFTW3. > What they did is available here: > http://web1.sns.it/~giannozz/public/fft_scalar_fftw3.f90 Actually it appears that _FFTW preprocessing directives are scattered not only in Modules/, but also in PW/ and CPV/ subdirectories. So it might be tricky to update things cleanly to FFTW3, without looking carefully through all of the _FFTW related stuff in the other subdirectories. Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From silviu at Princeton.EDU Wed Feb 8 07:43:56 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Wed, 08 Feb 2006 08:43:56 +0200 Subject: [Pw_forum] box grid in cp In-Reply-To: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> References: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> Message-ID: <43E9932C.9070602@Princeton.EDU> Dear Nichols, The core charge is in principle finite only at the core region (as defined by r_cut) and vanishes out side the core. Numerically the charge is represented in a Fourier series which may give rise to small charge oscillations outside the core and even to negative charge density, but only if the cut-off is too low. Having these small boxes removes the charge oscillations problem (at least outside the box) and also offers some numerical advantages in going to higher cut-offs. The small boxes should be set as small as possible, but large enough to contain the core of the largest element in your system. The formula for determining the box size is quite simple: nr1b=[(2*r_cut)/Lx*nr1] nr2b=... nr3b=... where r_cut is the cut-off radius for the largest element and Lx is the physical length of your box along the x axis. You have to round your result to the nearest larger integer. Silviu. Nichols A. Romero wrote: > Hi, > > This is in reference to CP in Quantum-Espresso 3.0. > > What exactly is nr1b, nr2b, nr3b? > > Are they at all related to ecutwfc or ecutrho? > > Thanks, > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From giannozz at nest.sns.it Wed Feb 8 09:59:52 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Feb 2006 09:59:52 +0100 Subject: [Pw_forum] forces in parallel espresso 3.0 In-Reply-To: References: Message-ID: <200602080959.52668.giannozz@nest.sns.it> On Tuesday 07 February 2006 21:06, Andrea Floris wrote: > compiler: pgi 5.2-4 from the last version of the users' guide: "Quantum-ESPRESSO does not work reliably, or not at all, with some versions (in particular, 5.2) of the Portland Group compiler. We think that this is due to compiler bugs, not to Quantum-ESPRESSO bugs." > rank 3 in job 1 n34_16977 caused > collective abort of all ranks exit status of rank 3: killed by signal 11 "Random crashes due to MPI errors have often been reported in Linux PC clusters. We cannot rule out the possibility that bugs in Quantum-ESPRESSO cause such behavior, but we are quite confident that the likely explanation is a hardware problem (defective RAM for instance) or a software bug (in MPI libraries, compiler, operating system)." P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From silviu at Princeton.EDU Wed Feb 8 12:18:21 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Wed, 08 Feb 2006 13:18:21 +0200 Subject: [Pw_forum] density files Message-ID: <43E9D37D.30405@Princeton.EDU> Dear All, I have noticed that now the charge density files are saved by default in CP calculations and this is not affected by the disk_io input parameter. Generally this is not a problem, but it can be in certain circumstances, like restricted disk space/quota. I have been running calculations on Lemieux which is an alpha cluster super computer in Pittsburgh. For some reason that is still mysterious to me, writing these density files on the scratch space took very long time, ~30 (!) minutes for a 68MB file. My calculation is spin-polarized and thus I have 3 such density files, and in addition I want to use the string method, which will multiply the number of these files by N-2, where N is the number of images. The mystery is further enhanced by the fact that (a) the wavefinction files (~23 MB) are dumped rather quickly (less than 30 sec) and (b) if I repeat the calculation on our pc-cluster, writing everything takes ~37 sec which is reasonable. I would appreciate your comments on: (a) What is the reasoning behind making the cp code dump density files by default? (b) Did anyone experience such anomalous I/O rates on Lemieux or any other cluster. Thanks, Silviu. From giannozz at nest.sns.it Wed Feb 8 18:52:28 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Feb 2006 18:52:28 +0100 Subject: [Pw_forum] density files In-Reply-To: <43E9D37D.30405@Princeton.EDU> References: <43E9D37D.30405@Princeton.EDU> Message-ID: <200602081852.28426.giannozz@nest.sns.it> On Wednesday 08 February 2006 12:18, Silviu Zilberman wrote: > I have been running calculations on Lemieux which is an alpha cluster > super computer in Pittsburgh. For some reason that is still mysterious > to me, writing these density files on the scratch space took very long > time, ~30 (!) minutes for a 68MB file. maybe you should rename your machine "Lepire" :-) The charge density file should be written only when the wavefunctions are written, every "isave" steps and at the end of the run. If it is written at each time step, this is definitely wrong. The charge density in a parallel calculation is collected to a single node and written from there. Since it is not wise to collect it into a single array, each slice from each processor is collected and written. Maybe this algorithm is not optimal (maybe it is even "pessimal"). You should try to understand where exactly the machine spends all this time and why Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Feb 8 19:03:27 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Feb 2006 19:03:27 +0100 Subject: [Pw_forum] box grid in cp In-Reply-To: <43E9932C.9070602@Princeton.EDU> References: <6ac064b60602071431t4822a68em55eddffc95f6b842@mail.gmail.com> <43E9932C.9070602@Princeton.EDU> Message-ID: <200602081903.27102.giannozz@nest.sns.it> Just a comment about the "box grid": note that this is used for both the "augmentation charge" in Ultrasoft pseudopotentials, and for the "core charge" used for the nonlinear core correction. All boxes are of the same size, so the "larger" charge determines the minimum size of the box. References: Phys. Rev. B 47, 10142 (1993); JCP 120, 5903 (2004) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Feb 8 19:23:22 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Feb 2006 19:23:22 +0100 Subject: [Pw_forum] band calculation in parallel In-Reply-To: References: Message-ID: <200602081923.22610.giannozz@nest.sns.it> On Tuesday 07 February 2006 20:12, Andrea Floris wrote: > the nscf calculation does not produce any output, and it is basically > stacked (whereas, with the same input, the serial version works of > course). This happens *only* when the k-points are given explicitly > (with the automatic mode is fine). I guess you mean "stuck". When a parallel run goes bananas, it can be hard to understand why. Print output to the terminal, not to file. Add print statements (using "write (*, ...", that should actually print something from each process), stop commands (use "call stop_run(.false.)") and try to locate what happens and where. > compiler: pgi 5.2-4 see my previous message Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From silviu at Princeton.EDU Wed Feb 8 21:18:53 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Wed, 08 Feb 2006 22:18:53 +0200 Subject: [Pw_forum] density files In-Reply-To: <200602081852.28426.giannozz@nest.sns.it> References: <43E9D37D.30405@Princeton.EDU> <200602081852.28426.giannozz@nest.sns.it> Message-ID: <43EA522D.4000102@Princeton.EDU> Paolo Giannozzi wrote: > On Wednesday 08 February 2006 12:18, Silviu Zilberman wrote: > > >> I have been running calculations on Lemieux which is an alpha cluster >> super computer in Pittsburgh. For some reason that is still mysterious >> to me, writing these density files on the scratch space took very long >> time, ~30 (!) minutes for a 68MB file. >> > > maybe you should rename your machine "Lepire" :-) > > The charge density file should be written only when the wavefunctions > are written, every "isave" steps and at the end of the run. If it is written > at each time step, this is definitely wrong. > The charge density is written only every isave steps, and I set it to a very large number to avoid this time-consuming i/o. But even if I write it just once at the end of the calculation, it would still require ~90 minutes for 3 files, which is completely crazy, given that the maximal time allocated per job is 12 hours on this supercomputer. > The charge density in a parallel calculation is collected to a single node > and written from there. Since it is not wise to collect it into a single > array, each slice from each processor is collected and written. Maybe > this algorithm is not optimal (maybe it is even "pessimal"). You should > try to understand where exactly the machine spends all this time and > why > I may do it, but for the time being, these files are not very useful for me. I can change the code to respect again the disk_io parameter and avoid writing these files all together. However I would like to know first if there was some reasoning behind dumping these files by default without user control over it. Thanks, Silviu. From akohlmey at vitae.cmm.upenn.edu Wed Feb 8 23:01:18 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Wed, 8 Feb 2006 17:01:18 -0500 (EST) Subject: [Pw_forum] density files In-Reply-To: <43EA522D.4000102@Princeton.EDU> Message-ID: On Wed, 8 Feb 2006, Silviu Zilberman wrote: hi, SZ> Paolo Giannozzi wrote: SZ> > On Wednesday 08 February 2006 12:18, Silviu Zilberman wrote: SZ> > SZ> > SZ> >> I have been running calculations on Lemieux which is an alpha cluster SZ> >> super computer in Pittsburgh. For some reason that is still mysterious SZ> >> to me, writing these density files on the scratch space took very long SZ> >> time, ~30 (!) minutes for a 68MB file. SZ> >> SZ> > SZ> > maybe you should rename your machine "Lepire" :-) paolo, you should be careful with remarks like this. people in pittsburgh take sports _very_ seriously and don't like others making fun of the names of their idol from the pittsburgh penguins. you may get away with it since the steelers just won the superbowl last weekend... SZ> > The charge density file should be written only when the wavefunctions SZ> > are written, every "isave" steps and at the end of the run. If it is written SZ> > at each time step, this is definitely wrong. SZ> > SZ> The charge density is written only every isave steps, and I set it to a SZ> very large number to avoid this time-consuming i/o. But even if I write SZ> it just once at the end of the calculation, it would still require ~90 SZ> minutes for 3 files, which is completely crazy, given that the maximal SZ> time allocated per job is 12 hours on this supercomputer. lemieux is an alpha and the dec compiler has the unfortunate property to do synchronous i/o by default. this will have a desasterous effect on a networked filesystem used by (too) many users. please try compiling with '-assume buffered_io' and let me know if that helps. SZ> > The charge density in a parallel calculation is collected to a single node SZ> > and written from there. Since it is not wise to collect it into a single SZ> > array, each slice from each processor is collected and written. Maybe SZ> > this algorithm is not optimal (maybe it is even "pessimal"). You should SZ> > try to understand where exactly the machine spends all this time and SZ> > why another recommendation from the PSC staff is only use 3 processors per node for the actual job (which generally is the performance limit for memory bandwidth consuming jobs like DFT/PW/PP codes) so that there is some cpu capacity left for asynchrous operation (e.g. kernel i/o and the MPI and NFS threads). regards, axel. SZ> > SZ> I may do it, but for the time being, these files are not very useful for SZ> me. I can change the code to respect again the disk_io parameter and SZ> avoid writing these files all together. However I would like to know SZ> first if there was some reasoning behind dumping these files by default SZ> without user control over it. SZ> SZ> Thanks, Silviu. SZ> SZ> SZ> _______________________________________________ SZ> Pw_forum mailing list SZ> Pw_forum at pwscf.org SZ> http://www.democritos.it/mailman/listinfo/pw_forum SZ> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From silviu at Princeton.EDU Thu Feb 9 00:46:03 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Thu, 09 Feb 2006 01:46:03 +0200 Subject: [Pw_forum] density files In-Reply-To: References: Message-ID: <43EA82BB.4080803@Princeton.EDU> Axel, Thank you so much for the tip, the '-assume buffered_io' did the magic. Now all the restart info is dumped in ~53 sec when I use the 4 processors on each node. Using only 3 processors per node (fixed total number of procs) results in a very minor improvement. Thanks! Silviu. Axel Kohlmeyer wrote: > On Wed, 8 Feb 2006, Silviu Zilberman wrote: > > hi, > > SZ> Paolo Giannozzi wrote: > SZ> > On Wednesday 08 February 2006 12:18, Silviu Zilberman wrote: > SZ> > > SZ> > > SZ> >> I have been running calculations on Lemieux which is an alpha cluster > SZ> >> super computer in Pittsburgh. For some reason that is still mysterious > SZ> >> to me, writing these density files on the scratch space took very long > SZ> >> time, ~30 (!) minutes for a 68MB file. > SZ> >> > SZ> > > SZ> > maybe you should rename your machine "Lepire" :-) > > paolo, you should be careful with remarks like this. > people in pittsburgh take sports _very_ seriously and > don't like others making fun of the names of their idol > from the pittsburgh penguins. you may get away with it > since the steelers just won the superbowl last weekend... > > > SZ> > The charge density file should be written only when the wavefunctions > SZ> > are written, every "isave" steps and at the end of the run. If it is written > SZ> > at each time step, this is definitely wrong. > SZ> > > SZ> The charge density is written only every isave steps, and I set it to a > SZ> very large number to avoid this time-consuming i/o. But even if I write > SZ> it just once at the end of the calculation, it would still require ~90 > SZ> minutes for 3 files, which is completely crazy, given that the maximal > SZ> time allocated per job is 12 hours on this supercomputer. > > lemieux is an alpha and the dec compiler has the unfortunate property > to do synchronous i/o by default. this will have a desasterous effect > on a networked filesystem used by (too) many users. > please try compiling with '-assume buffered_io' and let me know > if that helps. > > SZ> > The charge density in a parallel calculation is collected to a single node > SZ> > and written from there. Since it is not wise to collect it into a single > SZ> > array, each slice from each processor is collected and written. Maybe > SZ> > this algorithm is not optimal (maybe it is even "pessimal"). You should > SZ> > try to understand where exactly the machine spends all this time and > SZ> > why > > another recommendation from the PSC staff is only use 3 processors per > node for the actual job (which generally is the performance limit for > memory bandwidth consuming jobs like DFT/PW/PP codes) so that there is > some cpu capacity left for asynchrous operation (e.g. kernel i/o and > the MPI and NFS threads). > > regards, > axel. > > SZ> > > SZ> I may do it, but for the time being, these files are not very useful for > SZ> me. I can change the code to respect again the disk_io parameter and > SZ> avoid writing these files all together. However I would like to know > SZ> first if there was some reasoning behind dumping these files by default > SZ> without user control over it. > SZ> > SZ> Thanks, Silviu. > SZ> > SZ> > SZ> _______________________________________________ > SZ> Pw_forum mailing list > SZ> Pw_forum at pwscf.org > SZ> http://www.democritos.it/mailman/listinfo/pw_forum > SZ> > > From giannozz at nest.sns.it Thu Feb 9 12:13:43 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 9 Feb 2006 12:13:43 +0100 Subject: [Pw_forum] fix lattice constant In-Reply-To: <20060206062605.53469.qmail@web35108.mail.mud.yahoo.com> References: <20060206062605.53469.qmail@web35108.mail.mud.yahoo.com> Message-ID: <200602091213.43228.giannozz@nest.sns.it> On Monday 06 February 2006 07:26, y wang wrote: > I want to calculate the strained PbTiO3. How to perform a relaxation > with only fixed lattice constant a? > > In other words, lattice constant a is fixed; c and atomic position will > be optimized. a simple way is to fix also c and perform a structural optimization at fixed cell; then vary c. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mass at uniovi.es Fri Feb 10 10:18:55 2006 From: mass at uniovi.es (=?iso-8859-1?Q?Miguel_A._Salvad=F3?=) Date: Fri, 10 Feb 2006 10:18:55 +0100 Subject: [Pw_forum] compilation in SGI Message-ID: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> Dear PWSCF users: I have tried to compile PWSCF 3.0 in a SGI Origin 3800 IRIX 6.5 machine and obtain the following error messages immediately after I do make all. Any suggestion will be welcome. Thanks in advance and best wishes, Miguel Miguel A. Salvad? Dpto. Quimica Fisica y Analitica Universidad de Oviedo Spain % make all test -d bin || mkdir bin if test -d iotk ; then \ ( cd iotk ; if test "make" = "" ; then make TLDEPS= libiotk.a ; \ else make TLDEPS= libiotk.a ; fi ) ; fi cd src ; make libiotk.a f90 -mips4 -64 -O2 -r10000 -r8 -cpp -D__SGI -D__SGI64 -D__ORIGIN -D__FFT W -D__MPI -D__PARA -I../include -I/usr/local/include -I. -I../Modules -I../PW -I ../PH -I../iotk/src -c iotk_base.f90 save ^ f90-855 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 33, Column = 8 The compiler has detected errors in mo file will be created for this module. !--------------------------------------- ^ f90-197 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 55, Column = 40 Unexpected syntax: "operand" was expected but found "_". ^ f90-197 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 56, Column = 40 Unexpected syntax: "operand" was expected but found "_". f90: SGI MIPSpro Fortran 90 Version 7.41 (f14) Fri Feb 10, 2006 10:12:01 f90: 209 source lines f90: 3 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s) cf90: "explain cf90-message number" gives more information about each message *** Error code 2 (bu21) *** Error code 1 (bu21) *** Error code 1 (bu21) -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060210/04c33d04/attachment.htm From giannozz at nest.sns.it Fri Feb 10 15:09:19 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 10 Feb 2006 15:09:19 +0100 Subject: [Pw_forum] compilation in SGI In-Reply-To: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> References: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> Message-ID: <200602101509.19457.giannozz@nest.sns.it> On Friday 10 February 2006 10:18, Miguel A. Salvad? wrote: > I have tried to compile PWSCF 3.0 in a SGI Origin 3800 IRIX 6.5 machine > and obtain the following error messages immediately after I do make all. Giovanni Bussi, the author of iotk, says that it works if you replace the compiler flag "-cpp" with "-ftpp -macro_expand" . You can make the change directly in the make.sys file, or you can try an updated "configure" from here: http://web1.sns.it/~giannozz/public/configure Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From quevedin at gmail.com Fri Feb 10 16:54:11 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Fri, 10 Feb 2006 16:54:11 +0100 Subject: [Pw_forum] compilation in SGI In-Reply-To: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> References: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> Message-ID: <2ebe300a0602100754n7369cd31x8a797f62739fb40e@mail.gmail.com> Hola Miguel Si te puedo ayudar en algo no dudes en preguntarme, aunque b?sicamente yo s?lo lo he compilado en PCs Un saludo ############################################################### # Ph.D. Student Lucas Fern?ndez Seivane Tlf: (+34) 985 102946 # # Departamento de Fisica, Facultad de Ciencias Fax: (+34) 985 102952 # # Universidad de Oviedo Cell:(+34) 645 227396 # # 33007 Oviedo (Asturias) - Spain # ############################################################### On 2/10/06, Miguel A. Salvad? wrote: > > > Dear PWSCF users: > > > I have tried to compile PWSCF 3.0 in a SGI Origin 3800 IRIX 6.5 machine and > obtain the following error messages immediately after I do make all. > > Any suggestion will be welcome. > > > > Thanks in advance and best wishes, > > > > Miguel > > > > Miguel A. Salvad? > > Dpto. Quimica Fisica y Analitica > > Universidad de Oviedo > > Spain > > > > > > % make all > > test -d bin || mkdir bin > > if test -d iotk ; then \ > > ( cd iotk ; if test "make" = "" ; then make TLDEPS= libiotk.a ; \ > > else make TLDEPS= libiotk.a ; fi ) ; fi > > cd src ; make libiotk.a > > f90 -mips4 -64 -O2 -r10000 -r8 -cpp -D__SGI -D__SGI64 -D__ORIGIN > -D__FFT > > W -D__MPI -D__PARA -I../include -I/usr/local/include -I. -I../Modules > -I../PW -I > > ../PH -I../iotk/src -c iotk_base.f90 > > > > save > > ^ > > f90-855 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 33, Column = 8 > > The compiler has detected errors in mo > > file will be created for this module. > > > > !--------------------------------------- > > ^ > > > > f90-197 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 55, Column = 40 > > Unexpected syntax: "operand" was expected but found "_". > > > > > > ^ > > f90-197 f90: ERROR IOTK_BASE, File = iotk_base.f90, Line = 56, Column = 40 > > Unexpected syntax: "operand" was expected but found "_". > > > > f90: SGI MIPSpro Fortran 90 Version 7.41 (f14) Fri Feb 10, 2006 10:12:01 > > f90: 209 source lines > > f90: 3 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s) > > cf90: "explain cf90-message number" gives more information about each > message > > *** Error code 2 (bu21) > > *** Error code 1 (bu21) > > *** Error code 1 (bu21) From quevedin at gmail.com Fri Feb 10 17:09:55 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Fri, 10 Feb 2006 17:09:55 +0100 Subject: [Pw_forum] compilation in SGI In-Reply-To: <2ebe300a0602100754n7369cd31x8a797f62739fb40e@mail.gmail.com> References: <01LYSSYJYP8M00V1HD@fresno.net.uniovi.es> <2ebe300a0602100754n7369cd31x8a797f62739fb40e@mail.gmail.com> Message-ID: <2ebe300a0602100809j2275dce4u2557aff38184b648@mail.gmail.com> Sorry, I just took the emails the wrong way From quevedin at gmail.com Mon Feb 13 14:27:23 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Mon, 13 Feb 2006 14:27:23 +0100 Subject: [Pw_forum] Non-collinear magnetism and gamma Message-ID: <2ebe300a0602130527i7b1d7773v7a12cd1a2fbe2a44@mail.gmail.com> Hi to everybody in the list. Is it possible to calculate a magnetic finite material (let's say a molecule) in PWSCF using the gamma-point optimized algorithms? I have to put K_POINTS 1 0.0 0.0 0.0 1.0 instead of K_POINTS {gamma} in order to get it running Best Wishes Lucas Fern?ndez Seivane Departamento de F?sica, Universidad de Oviedo From mass at uniovi.es Mon Feb 13 19:27:20 2006 From: mass at uniovi.es (=?iso-8859-1?Q?Miguel_A._Salvad=F3?=) Date: Mon, 13 Feb 2006 19:27:20 +0100 Subject: [Pw_forum] compilation in SGI In-Reply-To: <200602101509.19457.giannozz@nest.sns.it> Message-ID: <01LYXIZ9FWQG00VFPB@fresno.net.uniovi.es> Hi PW users: Below are the steps I needed to follow in order to compile PW in a SGI Origin with MIPSpro Fortran 90 7.41 compiler. Perhaps it can be useful to other users. 1) Run ./configure 2) Edit make.sys and replace "-cpp" with "-ftpp -macro_expand" in F90FLAGS and F90FLAGS_NOOPT 3) Edit iotk/include/iotk_config.h and replace "warn" by "error" in Line 84. 4) Edit Modules/path_reparametrisation.f90 and replace the two lines "USE input_parameters, ONLY : num_of_images_inp => num_of_images" by only one identical line before the CONTAINS statement. 5) make pw Best wishes, Miguel Miguel A. Salvad? Dpto. Quimica Fisica y Analitica Universidad de Oviedo Spain -----Mensaje original----- De: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] En nombre de Paolo Giannozzi Enviado el: viernes, 10 de febrero de 2006 15:09 Para: pw_forum at pwscf.org Asunto: Re: [Pw_forum] compilation in SGI On Friday 10 February 2006 10:18, Miguel A. Salvad? wrote: > I have tried to compile PWSCF 3.0 in a SGI Origin 3800 IRIX 6.5 machine > and obtain the following error messages immediately after I do make all. Giovanni Bussi, the author of iotk, says that it works if you replace the compiler flag "-cpp" with "-ftpp -macro_expand" . You can make the change directly in the make.sys file, or you can try an updated "configure" from here: http://web1.sns.it/~giannozz/public/configure Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum From naromero at gmail.com Tue Feb 14 03:47:49 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Mon, 13 Feb 2006 21:47:49 -0500 Subject: [Pw_forum] About neb and smd In-Reply-To: References: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> Message-ID: <6ac064b60602131847r43390ccpad958e019035f4d6@mail.gmail.com> Stefano, This may seem like an ignorant question, but please bear with me I am just a lowly post-doc :^) Your previous statement on simulating first-order phase transitions make sense. However, I am confused at to where NPT type calculations fit into all of this. Are they not often used for simulating pressure-induced phase transitions? Consider for example, the following article: hcp-to-bcc pressure-induced transition in Mg simulated by ab initio molecular dynamics R. M. Wentzcovitch Phys. Rev. B 50, 10358-10361 (1994) Or does your statement pertain to simulating the real ("direct") dynamics that occurs during the first-order phase transition? I hope my question makes sense. Bests, On 1/30/06, Stefano Baroni wrote: > Dear Huiqun Zhou: sorry for the (very) late reply > > > On Dec 31, 2005, at 4:59 AM, Huiqun Zhou wrote: > > Dear list-users, > > Could anyone give me a pointer whether it's theoretically reasonable to > investigate solid state > transition induced by pressure using NEB or string method? > > In principle, it is. In practice, I would have strong reservations. > > The energy difference between two different phases is an extensive quantity, > hence the jump from one structure right to another would require to overcome > an infinite energy barrier in the thermodynamic limit. The way structural > transitions occur in nature is through nucleation: an energy fluctuation of > the order of (K_B T) determines the change of structure in a small portion > of the crystal which then gradually increases its size until it "eats" the > whole system. In order to accomodate two different structures to coexist, a > lot of defects are produced at the interface and the disturbance may extend > far from the nucleaton center due to the long-range nature of the resulting > elastic interactions. The energy barrier results from a delicate balance > between the energy gain due to the phase transformation and the energy loss > due to the creation of defects. As, noticed, the size of the perturbed > region may be large, so that a direct simulation would require large > supercells. > > > Any references are appreciated. > > I am not directly aware of any, but I would not be surprised if a few > existed. Nor would I be surprised if most of them were wrong, just because > of the temptation of simulating a direct jump between two phases just > ignoring the nucleation process. > > > Happy New Year! > > All the same to you > Stefano > > --- > Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste > [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) > > Please, if possible, don't send me MS Word or PowerPoint attachments > Why? See: > http://www.gnu.org/philosophy/no-word-attachments.html > > > > -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From giannozz at nest.sns.it Tue Feb 14 09:04:09 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 14 Feb 2006 09:04:09 +0100 Subject: [Pw_forum] compilation in SGI In-Reply-To: <01LYXIZ9FWQG00VFPB@fresno.net.uniovi.es> References: <01LYXIZ9FWQG00VFPB@fresno.net.uniovi.es> Message-ID: <200602140904.09462.giannozz@nest.sns.it> On Monday 13 February 2006 19:27, Miguel A. Salvad? wrote: > Below are the steps I needed to follow in order to compile PW in a SGI > Origin with MIPSpro Fortran 90 7.41 compiler. Perhaps it can be useful to > other users > [...]. > 4) Edit Modules/path_reparametrisation.f90 and replace the two lines > "USE input_parameters, ONLY : num_of_images_inp => num_of_images" by only > one identical line before the CONTAINS statement. looks like a compiler bug to me. The other problems should already be fixed in the CVS version. Thank you Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From baroni at sissa.it Tue Feb 14 09:33:20 2006 From: baroni at sissa.it (Stefano Baroni) Date: Tue, 14 Feb 2006 09:33:20 +0100 Subject: [Pw_forum] About neb and smd In-Reply-To: <6ac064b60602131847r43390ccpad958e019035f4d6@mail.gmail.com> References: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> <6ac064b60602131847r43390ccpad958e019035f4d6@mail.gmail.com> Message-ID: <309825E4-B445-4557-9F1E-2A796633BF74@sissa.it> Nichols: your question makes sense indeed. NPT dynamics has indeed been designed by Parrinello and Rahman (and somewhat refined by Wentzcovitch) to facilitate the transition from one crystal structure to another. However, although the relative enthalpies of the two phase can obviously be estimated from the simulation, the *barrier* between them have little (if anything) physical, for the reasons that I tried to explain the other time. As a matter of fact, in order to observe a transition in NPT MD run it is known that one has to overpressurize the sample ... Hope this helps. Stefano On Feb 14, 2006, at 3:47 AM, Nichols A. Romero wrote: > Stefano, > > This may seem like an ignorant question, but please bear with me I am > just a lowly post-doc :^) > > Your previous statement on simulating first-order phase transitions > make sense. However, I am confused at to where NPT type calculations > fit into all of this. Are they not often used for simulating > pressure-induced phase transitions? Consider for example, the > following article: > > hcp-to-bcc pressure-induced transition in Mg simulated by ab initio > molecular dynamics > R. M. Wentzcovitch > Phys. Rev. B 50, 10358-10361 (1994) > > Or does your statement pertain to simulating the real ("direct") > dynamics that occurs during the first-order phase transition? > > I hope my question makes sense. > > Bests, > On 1/30/06, Stefano Baroni wrote: >> Dear Huiqun Zhou: sorry for the (very) late reply >> >> >> On Dec 31, 2005, at 4:59 AM, Huiqun Zhou wrote: >> >> Dear list-users, >> >> Could anyone give me a pointer whether it's theoretically >> reasonable to >> investigate solid state >> transition induced by pressure using NEB or string method? >> >> In principle, it is. In practice, I would have strong reservations. >> >> The energy difference between two different phases is an extensive >> quantity, >> hence the jump from one structure right to another would require >> to overcome >> an infinite energy barrier in the thermodynamic limit. The way >> structural >> transitions occur in nature is through nucleation: an energy >> fluctuation of >> the order of (K_B T) determines the change of structure in a small >> portion >> of the crystal which then gradually increases its size until it >> "eats" the >> whole system. In order to accomodate two different structures to >> coexist, a >> lot of defects are produced at the interface and the disturbance >> may extend >> far from the nucleaton center due to the long-range nature of the >> resulting >> elastic interactions. The energy barrier results from a delicate >> balance >> between the energy gain due to the phase transformation and the >> energy loss >> due to the creation of defects. As, noticed, the size of the >> perturbed >> region may be large, so that a direct simulation would require large >> supercells. >> >> >> Any references are appreciated. >> >> I am not directly aware of any, but I would not be surprised if a few >> existed. Nor would I be surprised if most of them were wrong, just >> because >> of the temptation of simulating a direct jump between two phases just >> ignoring the nucleation process. >> >> >> Happy New Year! >> >> All the same to you >> Stefano >> >> --- >> Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - >> Trieste >> [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) >> >> Please, if possible, don't send me MS Word or PowerPoint attachments >> Why? See: >> http://www.gnu.org/philosophy/no-word-attachments.html >> >> >> >> > > > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum --- Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060214/8e17ac15/attachment.htm From wmbmacam at lg.ehu.es Tue Feb 14 11:25:22 2006 From: wmbmacam at lg.ehu.es (Miguel Martinez) Date: Tue, 14 Feb 2006 11:25:22 +0100 Subject: [Pw_forum] Memory question Message-ID: <43F1B012.7040903@lg.ehu.es> Hello everybody, I'm running parallel espresso (v2.1.5) in an Itanium2 cluster. The OS is Red Hat Linux, and the kernel is 2.4.20. The cluster uses mpich 1.2.6, and the jobs are sent using PBS. Compiler is Intel v7. Most nodes use 4Gb, though there are some with 16Gb RAM. The thing is that, when I send a phonon multiprocessor run, while it doesn't use a lot of memory (some 250Mb per thread), it swaps out. I've run two proccessors in a 4 proc node and, to make sure other jobs don't interfere, using all 4 procs for myself. 1) Is it normal that, while it could empty memory from older jobs, my phonon runs are swapping? I personally haven't seen this on my laptop (gfortran instead of ifc)... but I only do low cutoff and kpoints runs in my laptop. 2) Will this affect performance badly? Or are phonon runs more restricted by i/o speeds? 3) This is a bit off topic. Is it OK to use -npools while using processors in the same node or is it dumb? Thank you very much for your time, Miguel -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." Doug Gwyn From rudrabnrj at gmail.com Tue Feb 14 14:45:19 2006 From: rudrabnrj at gmail.com (rudra banerjee) Date: Tue, 14 Feb 2006 19:15:19 +0530 Subject: [Pw_forum] (no subject) Message-ID: <2e36f8e50602140545p46436c0s739b5fee132bc0e5@mail.gmail.com> what is the syntax of plotband input file? whatever i am getting is from the run_example file (i m followin example05);but what these data really means? -- have a good time! -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060214/fbc687ea/attachment.htm From gautes at dsm-mail.saclay.cea.fr Tue Feb 14 16:07:59 2006 From: gautes at dsm-mail.saclay.cea.fr (Gabriel =?iso-8859-1?Q?Aut=E8s?=) Date: Tue, 14 Feb 2006 16:07:59 +0100 (CET) Subject: [Pw_forum] question about pwcond.x Message-ID: <41270.132.166.17.128.1139929679.squirrel@dsm-mail> Hi, I try to calculate the transmission of a monoatomic iron wire with pwcond.x (following example12 Alwire). But the band structure I get from pwcond.x is different from the one obtained with pw.x, which leads to a wrong transmission curve. Actually, the (dxy/dx?-y?) and the (dxz/dyz) bands are shifted of a few eV by the pwcond.x calculation. Any idea why this happens? Maybe I made a mistake in my input: *input file for pw.x: ============================================================== &control calculation='scf' restart_mode='from_scratch', pseudo_dir= '/home/gautes/SOFTWARE/pseudo/', outdir='/home/gautes/WORK/espresso/Tmp' prefix='fe_wire' / &system ibrav = 6, celldm(1) =30.0, celldm(3) =0.143333333, nat= 1, ntyp= 1, nspin= 1, ecutwfc= 25.0, ecutrho= 150.0 occupations='smearing', smearing='methfessel-paxton', degauss=0.01 / &electrons conv_thr = 1.0e-8 mixing_beta = 0.7 / ATOMIC_SPECIES Fe 55.847 Fe_us_gga_d2.1.8.pseudo.UPF ATOMIC_POSITIONS Fe 0.0 0.0 0.000 K_POINTS (automatic) 1 1 100 0 0 0 ==================================================================== *input file for pwcond.x: ==================================================================== &inputcond outdir='/home/gautes/WORK/espresso/Tmp/', prefixl='fe_wire', prefixs='fe_wire', tran_file='trans.fewire', ikind=1, energy0=5.0d0, denergy=-0.1d0, ewind=1.d0, epsproj=1.d-3, nz1 = 1 / 1 #number of k_perp points 0.0 0.0 1.0 #kx, ky ,weight 100 ================================================================= thanks -- ================================================ Gabriel Aut?s | phone:+33 (0)1 69 08 30 07 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email: gautes at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ================================================ From giannozz at nest.sns.it Tue Feb 14 16:13:56 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 14 Feb 2006 16:13:56 +0100 Subject: [Pw_forum] Memory question In-Reply-To: <43F1B012.7040903@lg.ehu.es> References: <43F1B012.7040903@lg.ehu.es> Message-ID: <200602141613.56693.giannozz@nest.sns.it> On Tuesday 14 February 2006 11:25, Miguel Martinez wrote: > I'm running parallel espresso (v2.1.5) in an Itanium2 cluster [...] > Most nodes use 4Gb, though there are some with 16Gb RAM. > > The thing is that, when I send a phonon multiprocessor run, while it > doesn't use a lot of memory (some 250Mb per thread), it swaps out. > I've run two processors in a 4 proc node and, to make sure other > jobs don't interfere, using all 4 procs for myself. if you really use 2*250Mb out of 4Gb, you will not swap, unless your machine is horribly loaded. If you are swapping, you are using more memory than you think. How did you get that number? it is not easy to know how much memory a process is really using. Also note that some recent versions of the code contain rather large statically allocated arrays that are not distributed across processors (i.e. each process has its own copy). Check with command "size ph.x" how big is the so-called "bss". Most of that memory should have been eliminated by now. > I personally haven't seen this on my laptop (gfortran instead of ifc)... you mean g95, or really gfortran? these are two distinct projects > 2) Will this affect performance badly? if you swap all the time, it will, for sure > 3) This is a bit off topic. Is it OK to use -npools while using > processors in the same node or is it dumb? it is ok, but it won't save any memory: each process will allocate the entire memory Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From dalcorso at sissa.it Tue Feb 14 16:17:28 2006 From: dalcorso at sissa.it (Andrea Dal Corso) Date: Tue, 14 Feb 2006 16:17:28 +0100 Subject: [Pw_forum] question about pwcond.x In-Reply-To: <41270.132.166.17.128.1139929679.squirrel@dsm-mail> References: <41270.132.166.17.128.1139929679.squirrel@dsm-mail> Message-ID: <1139930249.32461.45.camel@dhpc-5-30.sissa.it> On Tue, 2006-02-14 at 16:07 +0100, Gabriel Aut?s wrote: > Hi, > > I try to calculate the transmission of a monoatomic iron wire with > pwcond.x (following example12 Alwire). > But the band structure I get from pwcond.x is different from the one > obtained with pw.x, which leads to a wrong transmission curve. > Actually, the (dxy/dx?-y?) and the (dxz/dyz) bands are shifted of a few eV > by the pwcond.x calculation. > > Any idea why this happens? > > > Maybe I made a mistake in my input: > *input file for pw.x: > ============================================================== > &control > calculation='scf' > restart_mode='from_scratch', > pseudo_dir= '/home/gautes/SOFTWARE/pseudo/', > outdir='/home/gautes/WORK/espresso/Tmp' > prefix='fe_wire' > / > &system > ibrav = 6, > celldm(1) =30.0, > celldm(3) =0.143333333, > nat= 1, > ntyp= 1, > nspin= 1, > ecutwfc= 25.0, > ecutrho= 150.0 > occupations='smearing', > smearing='methfessel-paxton', > degauss=0.01 > / > &electrons > conv_thr = 1.0e-8 > mixing_beta = 0.7 > / > ATOMIC_SPECIES > Fe 55.847 Fe_us_gga_d2.1.8.pseudo.UPF > ATOMIC_POSITIONS > Fe 0.0 0.0 0.000 > K_POINTS (automatic) > 1 1 100 0 0 0 > ==================================================================== > > > *input file for pwcond.x: > ==================================================================== > &inputcond > outdir='/home/gautes/WORK/espresso/Tmp/', > prefixl='fe_wire', > prefixs='fe_wire', > tran_file='trans.fewire', > ikind=1, > energy0=5.0d0, > denergy=-0.1d0, > ewind=1.d0, > epsproj=1.d-3, > nz1 = 1 Most probably the calculation is not converged with respect to these three parameters. Try increasing ewind, decreasing epsproj and increasing nz1. Typical values are ewind=3.d0, epsproj=1.d-6, nz1=5 or 10 Andrea > / > 1 #number of k_perp points > 0.0 0.0 1.0 #kx, ky ,weight > 100 > ================================================================= > > thanks > -- Andrea Dal Corso Tel. 0039-040-3787428 SISSA, Via Beirut 2/4 Fax. 0039-040-3787528 34014 Trieste (Italy) e-mail: dalcorso at sissa.it From wmbmacam at lg.ehu.es Tue Feb 14 16:35:22 2006 From: wmbmacam at lg.ehu.es (Miguel Martinez) Date: Tue, 14 Feb 2006 16:35:22 +0100 Subject: [Pw_forum] Memory question In-Reply-To: <200602141613.56693.giannozz@nest.sns.it> References: <43F1B012.7040903@lg.ehu.es> <200602141613.56693.giannozz@nest.sns.it> Message-ID: <43F1F8BA.8010001@lg.ehu.es> Good afternoon Paolo, > if you really use 2*250Mb out of 4Gb, you will not swap, unless your > machine is horribly loaded. If you are swapping, you are using more > memory than you think. How did you get that number? it is not easy > to know how much memory a process is really using. I got it with top. "ps aux | grep ph.x" would also report that size. What really worries me is that, although the only processes using over 100Mb are mine (top again), and they are the only active ones, the kernel swaps memory instead of dumping some old memory. The cache page was about 300Mb. > Check with command "size ph.x" how big is the so-called "bss". I will follow your suggestion. > you mean g95, or really gfortran? these are two distinct projects Yes, g95, sorry. >>3) This is a bit off topic. Is it OK to use -npools while using >>processors in the same node or is it dumb? > > it is ok, but it won't save any memory: each process will allocate > the entire memory If there were enough memory... would that perform better than not using -npools? What I understood from the guide is that espresso will parallelise in kpoints according to npools and on wavefunctions on nprocessors/npools. It also seemed to imply that, as long as -npools divides the total number of kpoints, the performance increase should be linear. But maybe I am totally wrong. Thanks again for your time, Miguel -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." Doug Gwyn From akohlmey at vitae.cmm.upenn.edu Tue Feb 14 17:13:41 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Tue, 14 Feb 2006 11:13:41 -0500 (EST) Subject: [Pw_forum] Memory question In-Reply-To: <43F1B012.7040903@lg.ehu.es> Message-ID: On Tue, 14 Feb 2006, Miguel Martinez wrote: hi, MM> Hello everybody, MM> MM> I'm running parallel espresso (v2.1.5) in an Itanium2 cluster. The OS is MM> Red Hat Linux, and the kernel is 2.4.20. The cluster uses mpich 1.2.6, MM> and the jobs are sent using PBS. Compiler is Intel v7. Most nodes use MM> 4Gb, though there are some with 16Gb RAM. MM> MM> The thing is that, when I send a phonon multiprocessor run, while it MM> doesn't use a lot of memory (some 250Mb per thread), it swaps out. I've MM> run two proccessors in a 4 proc node and, to make sure other jobs don't MM> interfere, using all 4 procs for myself. you have to take into account, that linux also uses the memory for disk caching, so if you have a lot of disk i/o, then the buffering of it will add 'pressure' to enlarge the pool of memory used for i/o buffering and less used memory will be swapped out. the linux kernel memory management of the default desktop distributions is tuned towards good interactive performance and that will interfere with high i/o jobs. one example, i experienced some time ago, was on a four way 4GB alpha machine, where a small memory (50MB) conventional SCF program using a 20GB integrals file would require at least 2GB for i/o buffering. we had two of those SCF programs running when somebody submitted a large memory job (as there was seemingly not much memory used) and the machine immediately started swapping like mad and performance went down the drain. MM> MM> 1) Is it normal that, while it could empty memory from older jobs, my MM> phonon runs are swapping? MM> MM> I personally haven't seen this on my laptop (gfortran instead of ifc)... MM> but I only do low cutoff and kpoints runs in my laptop. MM> MM> 2) Will this affect performance badly? Or are phonon runs more MM> restricted by i/o speeds? MM> MM> 3) This is a bit off topic. Is it OK to use -npools while using MM> processors in the same node or is it dumb? well, you have to experiment. if my assertions from above apply to your setup, then probably using a -npools option that would result in using one pool per node, might be the best setting (make sure that the nodes are properly listed in the machinefile, so that MPICH can group them as you need them). generally, parallelization via -npools should be much more efficient, as there is much less communication, but then each pool requires the full memory and the overlapping i/o on the nodes is another issue. you also have to watch out, that you are using local scratch. hope this helps, axel. MM> MM> Thank you very much for your time, MM> MM> Miguel MM> MM> MM> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Tue Feb 14 17:28:26 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 14 Feb 2006 17:28:26 +0100 Subject: [Pw_forum] (no subject) In-Reply-To: <200602141718.15469.p.giannozzi@sns.it> References: <2e36f8e50602140545p46436c0s739b5fee132bc0e5@mail.gmail.com> <200602141718.15469.p.giannozzi@sns.it> Message-ID: <200602141728.26811.giannozz@nest.sns.it> On Tuesday 14 February 2006 14:45, rudra banerjee wrote: > what is the syntax of plotband input file? run it interactively: plotband.x prompts for some data (file name, energy range for the plot, and little else) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From emenendez at macul.ciencias.uchile.cl Tue Feb 14 22:33:06 2006 From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P) Date: Tue, 14 Feb 2006 18:33:06 -0300 (CLST) Subject: [Pw_forum] (no subject) Message-ID: Hello, I have a strange situation. For a system of 32 Cd and 32 Te atoms y have calculated the ground energy with pw.x and cp.x For pw ! total energy = -4194.76510666 ryd i. e., -2097.382 Ha For cp total energy = -2097.04257 The difference is 0.005 Ha/atom, then it seems that I have convergence. ekinc in cp is also small. ekinc ekin epot etot tempp 0.02666 183.66406 -1213.20570 -960.95069 0.0 b.t.w, what is ekin? Is it the run average of ekinc? The problem that does not let my sleep is that for CP I read System Density [g/cm^3] : 5.8563 ................. Total stress (GPa) -102.55028826 0.41139812 0.07268107 0.41139812 -103.87561021 -0.18220224 0.07268108 -0.18220224 -102.86279720 but for pw total stress (ryd/bohr**3) (kbar) P= 21.33 0.00019794 0.00002107 -0.00003053 29.12 3.10 -4.49 0.00002107 0.00011087 -0.00003514 3.10 16.31 -5.17 -0.00003053 -0.00003514 0.00012620 -4.49 -5.17 18.57 Then, who can I believe? These are the input files &CONTROL calculation = 'cp' , restart_mode = 'restart' , outdir = '/home/eduardo/Compilaciones/Espresso/MD-CP/' , pseudo_dir = '/home/eduardo/Compilaciones/Espresso/MD-CP/', prefix = 'cdte64' , dt = 4.0, nstep = 100,iprint=20,isave=20, tstress=.true.,tprnfor=.true., ndr=91, ndw=91, etot_conv_thr = 1.d-9,ekin_conv_thr = 1.d-5, / &SYSTEM ibrav = 14, celldm(1) = 24.4946, celldm(2) = 1.0,celldm(3) = 1.0,celldm(4) = 0.0,celldm(5) = 0.0,celldm(6) = 0.0, nat = 64, ntyp = 2, nbnd=288,nelec=576,nspin=1, ecutwfc = 30.0 , ecutrho = 240 , occupations = 'fixed' , xc_type = 'PBE', smearing = 'fd' , nosym = .true., nr1b=25 , nr2b=25 , nr3b=25 , qcutz=150., q2sigma=2.0, ecfixed=24.0, / &ELECTRONS electron_dynamics='damp',electron_damping=0.2, emass=500.d0, emass_cutoff=3.d0, orthogonalization = 'ortho', ortho_eps = 5.d-8, ortho_max = 15, electron_velocities = 'zero', electron_temperature = 'not_controlled' / &IONS ion_dynamics='none', ion_radius(1)=1.0, ion_radius(2)=1.0, ion_temperature = 'rescaling' , tempw = 2000 , tolp = 1.D-2 , / &CELL cell_dynamics = 'none', cell_velocities = 'zero', press = 0.0d0, wmass = 70000.0d0 / ATOMIC_SPECIES Cd 112.41000 Cd.pbe-van.UPF Te 127.60000 Te.pbe-rkkjus-d.UPF ATOMIC_POSITIONS crystal Cd 0.799931907 0.974912544 0.697391927 Cd 0.339731787 0.485213972 0.488653125 Cd 0.326213429 0.979344037 0.953936392 Cd 0.978723474 0.518658890 0.592764013 Cd 0.512960735 0.225083702 0.205121248 Cd 0.504718742 0.949695475 0.300711498 Cd 0.528281712 0.460727001 0.945214043 Cd 0.371675507 0.676544170 0.282806590 Cd 0.329150304 0.022517629 0.742724558 Cd 0.620086766 0.980168732 0.070357853 Cd 0.410888793 0.640098908 0.077411417 Cd 0.900000914 0.195415374 0.164073912 Cd 0.142737788 0.802988157 0.295814360 Cd 0.700835563 0.780238184 0.012946118 Cd 0.965746574 0.273927387 0.749811767 Cd 0.433591384 0.430872378 0.248205777 Cd 0.353512363 0.392686878 0.009102935 Cd 0.030806872 0.821852186 0.854504546 Cd 0.256438307 0.792563151 0.076754873 Cd 0.311716809 0.962012129 0.192918432 Cd 0.801452499 0.280229074 0.894348353 Cd 0.469099445 0.657689919 0.606255798 Cd 0.923310403 0.735926292 0.050534466 Cd 0.864922505 0.298235092 0.503667180 Cd 0.473110345 0.840355934 0.099473451 Cd 0.023003560 0.604166994 0.886398219 Cd 0.033306065 0.802019466 0.478744543 Cd 0.633762672 0.752830911 0.701276949 Cd 0.160456487 0.085695753 0.429505853 Cd 0.970333828 0.446302302 0.265849690 Cd 0.166559738 0.451689978 0.706150745 Cd 0.481729865 0.869961855 0.816958764 Te 0.545419637 0.461788417 0.540644179 Te 0.824494447 0.846560441 0.338108257 Te 0.581822000 0.607706225 0.302282816 Te 0.127474436 0.951149047 0.013009348 Te 0.134564155 0.707972617 0.674908901 Te 0.363501489 0.508832198 0.759528997 Te 0.716705448 0.528102204 0.879270488 Te 0.740153467 0.264048511 0.304963913 Te 0.123130594 0.271798189 0.239442782 Te 0.928535961 0.106132238 0.580554296 Te 0.097787132 0.363801484 0.437662623 Te 0.858266187 0.046642655 0.003033062 Te 0.936424501 0.631195138 0.376781667 Te 0.324476914 0.193844771 0.015340039 Te 0.182531951 0.581862885 0.365474428 Te 0.577495739 0.221237266 0.011022996 Te 0.332403368 0.254487710 0.559232473 Te 0.780209598 0.488873559 0.586767375 Te 0.046525880 0.911410064 0.667752369 Te 0.676579297 0.257794687 0.685827840 Te 0.212187663 0.540764460 0.088827859 Te 0.536330325 0.856113031 0.475234109 Te 0.358640689 0.120924635 0.341589581 Te 0.913344616 0.508030873 0.043675568 Te 0.290133474 0.813533577 0.595525549 Te 0.689952869 0.566294694 0.080938740 Te 0.743331484 0.671509972 0.494435792 Te 0.794130924 0.804183946 0.824547896 Te 0.600429222 0.011752483 0.634246079 Te 0.741465064 0.055758011 0.390921089 Te 0.183887405 0.151777249 0.662226385 Te 0.106564251 0.367940618 0.888589564 and for cp &CONTROL calculation = 'md' , restart_mode = 'from_scratch' , outdir = '.' , pseudo_dir = '.' , prefix = 'cdte64-ea' , tstress = .true. , tprnfor = .true. , dt = 10 / &SYSTEM ibrav = 1, celldm(1) = 24.4946, nat = 64, ntyp = 2, ecutwfc = 30.0 , ecutrho = 240 , occupations = 'smearing' , degauss = 0.02 , smearing = 'fermi-dirac' , / &ELECTRONS electron_maxstep = 60, conv_thr = 1.0D-7 , startingpot = 'atomic' , startingwfc = 'random' , mixing_mode = 'plain' , diagonalization = 'david' , / &IONS ion_dynamics = 'verlet' , upscale = 10.D0 , ion_temperature = 'rescaling' , tempw = 2000 , tolp = 1.D-2 , / ATOMIC_SPECIES Cd 112.41000 Cd.pbe-van.UPF Te 127.60000 Te.pbe-rkkjus-d.UPF ATOMIC_POSITIONS crystal Cd 0.799931907 0.974912544 0.697391927 Cd 0.339731787 0.485213972 0.488653125 Cd 0.326213429 0.979344037 0.953936392 Cd 0.978723474 0.518658890 0.592764013 Cd 0.512960735 0.225083702 0.205121248 Cd 0.504718742 0.949695475 0.300711498 Cd 0.528281712 0.460727001 0.945214043 Cd 0.371675507 0.676544170 0.282806590 Cd 0.329150304 0.022517629 0.742724558 Cd 0.620086766 0.980168732 0.070357853 Cd 0.410888793 0.640098908 0.077411417 Cd 0.900000914 0.195415374 0.164073912 Cd 0.142737788 0.802988157 0.295814360 Cd 0.700835563 0.780238184 0.012946118 Cd 0.965746574 0.273927387 0.749811767 Cd 0.433591384 0.430872378 0.248205777 Cd 0.353512363 0.392686878 0.009102935 Cd 0.030806872 0.821852186 0.854504546 Cd 0.256438307 0.792563151 0.076754873 Cd 0.311716809 0.962012129 0.192918432 Cd 0.801452499 0.280229074 0.894348353 Cd 0.469099445 0.657689919 0.606255798 Cd 0.923310403 0.735926292 0.050534466 Cd 0.864922505 0.298235092 0.503667180 Cd 0.473110345 0.840355934 0.099473451 Cd 0.023003560 0.604166994 0.886398219 Cd 0.033306065 0.802019466 0.478744543 Cd 0.633762672 0.752830911 0.701276949 Cd 0.160456487 0.085695753 0.429505853 Cd 0.970333828 0.446302302 0.265849690 Cd 0.166559738 0.451689978 0.706150745 Cd 0.481729865 0.869961855 0.816958764 Te 0.545419637 0.461788417 0.540644179 Te 0.824494447 0.846560441 0.338108257 Te 0.581822000 0.607706225 0.302282816 Te 0.127474436 0.951149047 0.013009348 Te 0.134564155 0.707972617 0.674908901 Te 0.363501489 0.508832198 0.759528997 Te 0.716705448 0.528102204 0.879270488 Te 0.740153467 0.264048511 0.304963913 Te 0.123130594 0.271798189 0.239442782 Te 0.928535961 0.106132238 0.580554296 Te 0.097787132 0.363801484 0.437662623 Te 0.858266187 0.046642655 0.003033062 Te 0.936424501 0.631195138 0.376781667 Te 0.324476914 0.193844771 0.015340039 Te 0.182531951 0.581862885 0.365474428 Te 0.577495739 0.221237266 0.011022996 Te 0.332403368 0.254487710 0.559232473 Te 0.780209598 0.488873559 0.586767375 Te 0.046525880 0.911410064 0.667752369 Te 0.676579297 0.257794687 0.685827840 Te 0.212187663 0.540764460 0.088827859 Te 0.536330325 0.856113031 0.475234109 Te 0.358640689 0.120924635 0.341589581 Te 0.913344616 0.508030873 0.043675568 Te 0.290133474 0.813533577 0.595525549 Te 0.689952869 0.566294694 0.080938740 Te 0.743331484 0.671509972 0.494435792 Te 0.794130924 0.804183946 0.824547896 Te 0.600429222 0.011752483 0.634246079 Te 0.741465064 0.055758011 0.390921089 Te 0.183887405 0.151777249 0.662226385 Te 0.106564251 0.367940618 0.888589564 K_POINTS gamma The pseudo potential Te.pbe-rkkjus-d.UPF was generated by me using the utility of Espresso. Maybe thisis the problem. With it I could reproduce bands, lattice constant and DOS for CdTe and TeO2 using pw.x . The Cd pseudo was taken form the web table. I also tested it and generated one myself, but the one of the table performs better (surprise :-) ). Hoping to sleep soon Regards And happy St Valentin !! Eduardo A. Menendez Proupin Department of Physics Faculty of Science University of Chile Las Palmeras 3425 ?u?oa, Santiago Chile Phone: 56+2+978 74 11 http://fisica.ciencias.uchile.cl/~emenendez/ From degironc at sissa.it Wed Feb 15 09:23:03 2006 From: degironc at sissa.it (degironc) Date: Wed, 15 Feb 2006 09:23:03 +0100 Subject: [Pw_forum] (no subject) In-Reply-To: References: Message-ID: <43F2E4E7.4090506@sissa.it> stress converges slowly with cutoff and if you are not at full convergence setting the variables qcutz=150., q2sigma=2.0, ecfixed=24.0, modifies the kinetic energy of the electrons beyond 24 ry adding a large penalty function and the "effective" cutoff of your calculation is something around 24 ry. This affects the total energy and the stress. Also having smearing instead of fixed occupation makes a difference but if your system is gapped it should not be large. In order to compare output of the two codes you should use the same setting in both. stefano CP> > &SYSTEM > ibrav = 14, > celldm(1) = 24.4946, > celldm(2) = 1.0,celldm(3) = 1.0,celldm(4) = 0.0,celldm(5) = 0.0,celldm(6) = 0.0, > nat = 64, > ntyp = 2, > nbnd=288,nelec=576,nspin=1, > ecutwfc = 30.0 , > ecutrho = 240 , > occupations = 'fixed' , > xc_type = 'PBE', > > qcutz=150., q2sigma=2.0, ecfixed=24.0, > / > PW> > &SYSTEM > ibrav = 1, > celldm(1) = 24.4946, > nat = 64, > ntyp = 2, > ecutwfc = 30.0 , > ecutrho = 240 , > occupations = 'smearing' , > degauss = 0.02 , > smearing = 'fermi-dirac' , > / > &ELECTRONS > > From hqzhou at nju.edu.cn Wed Feb 15 10:36:09 2006 From: hqzhou at nju.edu.cn (Huiqun Zhou) Date: Wed, 15 Feb 2006 17:36:09 +0800 Subject: [Pw_forum] Where to get CVS version of Q-Espresso? Message-ID: <003701c63213$40e191d0$1d00a8c0@solarflare> Dear list-users, I just checked the list archive and found there are quite some modifications in the cvs version, which can solve some problems I encountered. Where can I get the cvs version? Huiqun Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060215/8512b3fe/attachment.htm From hqzhou at nju.edu.cn Wed Feb 15 10:39:19 2006 From: hqzhou at nju.edu.cn (Huiqun Zhou) Date: Wed, 15 Feb 2006 17:39:19 +0800 Subject: [Pw_forum] Total number of d electrons of cobalt Message-ID: <004e01c63213$b1a0a320$1d00a8c0@solarflare> dear developers and list users, Just a simple question. What's the reason for setting cobalt's total number of d electrons to 9.0 but 7.0 in tabd.f90? Is it a typo, or a setting on purpose? Huiqun Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060215/568eddf9/attachment.htm From wmbmacam at lg.ehu.es Wed Feb 15 11:54:30 2006 From: wmbmacam at lg.ehu.es (Miguel Martinez) Date: Wed, 15 Feb 2006 11:54:30 +0100 Subject: [Pw_forum] Where to get CVS version of Q-Espresso? In-Reply-To: <003701c63213$40e191d0$1d00a8c0@solarflare> References: <003701c63213$40e191d0$1d00a8c0@solarflare> Message-ID: <43F30866.7040008@lg.ehu.es> Dear Huiqun Zhou, > Where can I get the cvs version? As far as I know, you will need cvs installed in your machine to get cvs. If you already have it, just follow the instructions in the file README.cvs, located in the espresso root directory. -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." Doug Gwyn From gautes at dsm-mail.saclay.cea.fr Wed Feb 15 13:35:43 2006 From: gautes at dsm-mail.saclay.cea.fr (Gabriel =?iso-8859-1?Q?Aut=E8s?=) Date: Wed, 15 Feb 2006 13:35:43 +0100 (CET) Subject: [Pw_forum] question about pwcond.x In-Reply-To: <1139930249.32461.45.camel@dhpc-5-30.sissa.it> References: <41270.132.166.17.128.1139929679.squirrel@dsm-mail> <1139930249.32461.45.camel@dhpc-5-30.sissa.it> Message-ID: <42269.132.166.17.128.1140006943.squirrel@dsm-mail> > >> ewind=1.d0, >> epsproj=1.d-3, >> nz1 = 1 > > Most probably the calculation is not converged with respect to these > three parameters. Try increasing ewind, decreasing epsproj and > increasing nz1. Typical values are ewind=3.d0, epsproj=1.d-6, nz1=5 or > 10 > > Andrea > Ok, the calculation with these parameters gives a better band structure. Thanks -- ================================================ Gabriel Aut?s | phone:+33 (0)1 69 08 30 07 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email: gautes at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ================================================ From matteoc at MIT.EDU Wed Feb 15 17:10:03 2006 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Wed, 15 Feb 2006 11:10:03 -0500 (EST) Subject: [Pw_forum] Total number of d electrons of cobalt In-Reply-To: <004e01c63213$b1a0a320$1d00a8c0@solarflare> References: <004e01c63213$b1a0a320$1d00a8c0@solarflare> Message-ID: Dear all I'm sending this message for the second time because the first apparently didn't work. Apologies to those of you who have received it twice. Matteo %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dear Huiqun, I think you are right: the number of d electrons for Co should be set to 7, not 9. Unless this was changed for some particular reason (that I don't know) it is a typo (of mine probably) in the code. Anyway it shouldn't be terribly important because these data (about the number of d electrons) are only used to produce an initial guess of the on-site occupations needed for LDA+U calculations. These quantities are then recomputed at each iteration of your run so the effect of setting the number of d electrons to 9 instead of 7 will disappear very quickly. Regards, Matteo On Wed, 15 Feb 2006, Huiqun Zhou wrote: > dear developers and list users, > > Just a simple question. What's the reason for setting cobalt's total number of d electrons > to 9.0 but 7.0 in tabd.f90? Is it a typo, or a setting on purpose? > > > Huiqun Zhou From quevedin at gmail.com Wed Feb 15 19:17:07 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Wed, 15 Feb 2006 19:17:07 +0100 Subject: [Pw_forum] Problem relaxing cluster Message-ID: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> Hi to all I am trying to relax a system of 2 atoms, but each time I do it I get IOS = 39 2 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from davcio : error # 10 i/o error in davcio %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... the input is Pt Pt &control calculation = 'relax' restart_mode='from_scratch', prefix='Pt.relax', tprnfor = .true. pseudo_dir = '/home/quevedin/espresso-3.0/pseudo/', / &system ibrav = 1, celldm(1) = 25.D0, nat= 2, ntyp= 1, lspinorb=.true., noncolin=.true., starting_magnetization(1)=1.0, angle1(1)=90.0 angle2(1)= 0.0 starting_magnetization(2)=1.0, angle1(2)=90.0 angle2(2)= 0.0 ecutwfc =25.0, ecutrho =250.0, nosym=.true., / &electrons mixing_beta = 0.7, conv_thr = 1.0d-8 / &IONS pot_extrapolation = "second_order", wfc_extrapolation = "second_order", / ATOMIC_SPECIES Pt 79.90 Ptrel.RRKJ3.UPF ATOMIC_POSITIONS {angstrom} Pt 0.00000000 0.00000000 0.0000 Pt 2.28134450 0.00000000 0.0 K_POINTS 1 0.0 0.0 0.0 1.0 May somebody have this happened to before? I use ifort9 + mkl 8.0.1 on x86_64 thanks to all P.S.: I know that the ecuts may be a bit low, but I wanted to check if it was some kind of problem related to these parameters From silviu at Princeton.EDU Wed Feb 15 21:12:09 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Wed, 15 Feb 2006 22:12:09 +0200 Subject: [Pw_forum] Problem relaxing cluster In-Reply-To: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> References: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> Message-ID: <43F38B19.6090106@Princeton.EDU> I am not sure if that's the reason, but one error in the input is the specification of starting_magnetization(j). This variable defines the magnetization per species. In your case you have only one species (Pt) so starting_magnetization(2) is meaningless. The only way to define different magnetization for each of the two Pt atoms is to define them as two different species such as Pt1 and Pt2 (ntyp=2), and use the same pseudo-potential for each. Silviu. Lucas Fernandez Seivane wrote: > Hi to all > > I am trying to relax a system of 2 atoms, but each time I do it I get > IOS = 39 > > 2 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from davcio : error # 10 > i/o error in davcio > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > > the input is > Pt > Pt > &control > calculation = 'relax' > restart_mode='from_scratch', > prefix='Pt.relax', > tprnfor = .true. > pseudo_dir = '/home/quevedin/espresso-3.0/pseudo/', > / > &system > ibrav = 1, > celldm(1) = 25.D0, > nat= 2, ntyp= 1, > lspinorb=.true., > noncolin=.true., > starting_magnetization(1)=1.0, > angle1(1)=90.0 > angle2(1)= 0.0 > starting_magnetization(2)=1.0, > angle1(2)=90.0 > angle2(2)= 0.0 > ecutwfc =25.0, > ecutrho =250.0, > nosym=.true., > / > &electrons > mixing_beta = 0.7, > conv_thr = 1.0d-8 > / > &IONS > pot_extrapolation = "second_order", > wfc_extrapolation = "second_order", > / > ATOMIC_SPECIES > Pt 79.90 Ptrel.RRKJ3.UPF > ATOMIC_POSITIONS {angstrom} > Pt 0.00000000 0.00000000 0.0000 > Pt 2.28134450 0.00000000 0.0 > K_POINTS > 1 > 0.0 0.0 0.0 1.0 > > > May somebody have this happened to before? I use ifort9 + mkl 8.0.1 on x86_64 > thanks to all > > P.S.: I know that the ecuts may be a bit low, but I wanted to check if > it was some kind of problem related to these parameters > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From degironc at sissa.it Thu Feb 16 09:07:56 2006 From: degironc at sissa.it (degironc) Date: Thu, 16 Feb 2006 09:07:56 +0100 Subject: [Pw_forum] Total number of d electrons of cobalt In-Reply-To: References: <004e01c63213$b1a0a320$1d00a8c0@solarflare> Message-ID: <43F432DC.7010307@sissa.it> Dear all, I also think that it is probably a typo. I corrected it in the CVS version. stefano Matteo Cococcioni wrote: > Dear Huiqun, > > I think you are right: the number of d electrons for Co should be set > to 7, not 9. Unless this was changed for some particular reason (that > I don't know) it is a typo (of mine probably) in the code. > Anyway it shouldn't be terribly important because these data (about > the number of d electrons) are only used to produce an initial guess > of the on-site occupations needed for LDA+U calculations. These > quantities are then recomputed at each iteration of your run so the > effect of setting the number of d electrons to 9 instead of 7 will > disappear very quickly. > > Regards, > > Matteo > > > On Wed, 15 Feb 2006, Huiqun Zhou wrote: > >> dear developers and list users, >> >> Just a simple question. What's the reason for setting cobalt's total >> number of d electrons >> to 9.0 but 7.0 in tabd.f90? Is it a typo, or a setting on purpose? >> >> >> Huiqun Zhou > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From dalcorso at sissa.it Thu Feb 16 10:53:41 2006 From: dalcorso at sissa.it (Andrea Dal Corso) Date: Thu, 16 Feb 2006 10:53:41 +0100 Subject: [Pw_forum] Problem relaxing cluster In-Reply-To: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> References: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> Message-ID: <1140083621.3740.6.camel@dhpc-5-30.sissa.it> On Wed, 2006-02-15 at 19:17 +0100, Lucas Fernandez Seivane wrote: > Hi to all > > I am trying to relax a system of 2 atoms, but each time I do it I get > IOS = 39 > > 2 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from davcio : error # 10 > i/o error in davcio > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > > the input is > Pt > Pt > &control > calculation = 'relax' > restart_mode='from_scratch', > prefix='Pt.relax', > tprnfor = .true. > pseudo_dir = '/home/quevedin/espresso-3.0/pseudo/', > / > &system > ibrav = 1, > celldm(1) = 25.D0, > nat= 2, ntyp= 1, > lspinorb=.true., > noncolin=.true., > starting_magnetization(1)=1.0, > angle1(1)=90.0 > angle2(1)= 0.0 > starting_magnetization(2)=1.0, > angle1(2)=90.0 > angle2(2)= 0.0 > ecutwfc =25.0, > ecutrho =250.0, > nosym=.true., > / > &electrons > mixing_beta = 0.7, > conv_thr = 1.0d-8 > / > &IONS > pot_extrapolation = "second_order", > wfc_extrapolation = "second_order", Wave functions extrapolation is not implemented in the non collinear/spin-orbit case. Andrea > / > ATOMIC_SPECIES > Pt 79.90 Ptrel.RRKJ3.UPF > ATOMIC_POSITIONS {angstrom} > Pt 0.00000000 0.00000000 0.0000 > Pt 2.28134450 0.00000000 0.0 > K_POINTS > 1 > 0.0 0.0 0.0 1.0 > > > May somebody have this happened to before? I use ifort9 + mkl 8.0.1 on x86_64 > thanks to all > > P.S.: I know that the ecuts may be a bit low, but I wanted to check if > it was some kind of problem related to these parameters > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -- Andrea Dal Corso Tel. 0039-040-3787428 SISSA, Via Beirut 2/4 Fax. 0039-040-3787528 34014 Trieste (Italy) e-mail: dalcorso at sissa.it From jasonsun98 at hotmail.com Thu Feb 16 14:29:17 2006 From: jasonsun98 at hotmail.com (sun jason) Date: Thu, 16 Feb 2006 13:29:17 +0000 Subject: [Pw_forum] about the convergence of ph.x In-Reply-To: <20060216063509.22965.25724.Mailman@democritos.sissa.it> Message-ID: dear all, I will very appreciate the one who help me about following question, the ph.x is not convergence when I calculate the second order response. the message is like this: Computing Second order response kpoint 4 ibnd 41 pcgreen: root not converged 0.274E+01 kpoint 4 ibnd 41 pcgreen: root not converged 0.424E+04 kpoint 4 ibnd 41 pcgreen: root not converged 0.479E+02 kpoint 4 ibnd 41 pcgreen: root not converged 0.162E+07 iter # 1 av.it.: 50.3 thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.472E+28 kpoint 4 ibnd 41 pcgreen: root not converged 0.819E+01 kpoint 4 ibnd 41 pcgreen: root not converged 0.160E-01 kpoint 4 ibnd 41 pcgreen: root not converged 0.167E+00 iter # 2 av.it.: 54.0 thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.653E+30 kpoint 4 ibnd 41 pcgreen: root not converged 0.214E+04 kpoint 4 ibnd 41 pcgreen: root not converged 0.151E+02 kpoint 4 ibnd 41 pcgreen: root not converged 0.740E+03 ...... I've change the mixing_beta to 0.1, but the situation is not change to better. should I change the nbnd ? the default nbnd=40. does this message mean the number of bands is not enough ? Thank you in advance! Best regards, =============================================== Jian SUN Physics Dept. of Nanjing University National Lab. of Solid State Microstructures 22 Hankou Road, Gulou District Nanjing, Jiangsu Province 210093 China =============================================== From hplan at pku.edu.cn Thu Feb 16 14:27:24 2006 From: hplan at pku.edu.cn (Hai-Ping Lan) Date: Thu, 16 Feb 2006 21:27:24 +0800 Subject: [Pw_forum] Compiling problem about PGI Message-ID: <0IUS00ANV868CF@water.pku.edu.cn> Dear Colleagues: I tried to compile espresso-3.0 with PGI compilor 5.1 under RedHatWS-4.0 ,and the CPUs are AMD operon 248. When i ran the shell command ./configure within ~/espresso-3.0/, and it gave information below: The following libraries have been found: BLAS_LIBS=-lblas LAPACK_LIBS= -llapack FFT_LIBS= Please check if that is correct. If any libraries are missing, you may specify a list of directories to search and retry, as follows: ./configure LIBDIRS="list of directories, separated by spaces" Parallel environment detected successfully. Configured for compilation of parallel executables. Then i typed command "make all", but it gave errors below: PGF90-S-0034-Syntax error at or near identifier iotk_str_clean (iotk_str_interf.F90: 257) PGF90-S-0310-Missing ENDINTERFACE statement (iotk_str_interf.F90: 259) 0 inform, 0 warnings, 2 severes, 0 fatal for iotk_str_interf make[2]: *** [iotk_str_interf.o] Error 2 i think these error may be due to PGI compilor because no problem occured when i use Intel ifort.. Would anyone help me out of these problems? Best wishes, Hai-Ping Lan hplan at pku.edu.cn 2006-02-16 From quevedin at gmail.com Thu Feb 16 16:17:06 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Thu, 16 Feb 2006 16:17:06 +0100 Subject: [Pw_forum] Problem relaxing cluster In-Reply-To: <1140083621.3740.6.camel@dhpc-5-30.sissa.it> References: <2ebe300a0602151017o517f48a8raaba50b4c4da7454@mail.gmail.com> <1140083621.3740.6.camel@dhpc-5-30.sissa.it> Message-ID: <2ebe300a0602160717t75ffe1beqd6c2a4cbae9578aa@mail.gmail.com> Now it works. Thanks! On 2/16/06, Andrea Dal Corso wrote: > On Wed, 2006-02-15 at 19:17 +0100, Lucas Fernandez Seivane wrote: > > Hi to all > > > > I am trying to relax a system of 2 atoms, but each time I do it I get > > IOS = 39 > > > > 2 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > from davcio : error # 10 > > i/o error in davcio > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > stopping ... > > > > the input is > > Pt > > Pt > > &control > > calculation = 'relax' > > restart_mode='from_scratch', > > prefix='Pt.relax', > > tprnfor = .true. > > pseudo_dir = '/home/quevedin/espresso-3.0/pseudo/', > > / > > &system > > ibrav = 1, > > celldm(1) = 25.D0, > > nat= 2, ntyp= 1, > > lspinorb=.true., > > noncolin=.true., > > starting_magnetization(1)=1.0, > > angle1(1)=90.0 > > angle2(1)= 0.0 > > starting_magnetization(2)=1.0, > > angle1(2)=90.0 > > angle2(2)= 0.0 > > ecutwfc =25.0, > > ecutrho =250.0, > > nosym=.true., > > / > > &electrons > > mixing_beta = 0.7, > > conv_thr = 1.0d-8 > > / > > &IONS > > pot_extrapolation = "second_order", > > wfc_extrapolation = "second_order", > > Wave functions extrapolation is not implemented in the non > collinear/spin-orbit case. > > Andrea > > > / > > ATOMIC_SPECIES > > Pt 79.90 Ptrel.RRKJ3.UPF > > ATOMIC_POSITIONS {angstrom} > > Pt 0.00000000 0.00000000 0.0000 > > Pt 2.28134450 0.00000000 0.0 > > K_POINTS > > 1 > > 0.0 0.0 0.0 1.0 > > > > > > May somebody have this happened to before? I use ifort9 + mkl 8.0.1 on x86_64 > > thanks to all > > > > P.S.: I know that the ecuts may be a bit low, but I wanted to check if > > it was some kind of problem related to these parameters > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > -- > Andrea Dal Corso Tel. 0039-040-3787428 > SISSA, Via Beirut 2/4 Fax. 0039-040-3787528 > 34014 Trieste (Italy) e-mail: dalcorso at sissa.it > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From emenendez at macul.ciencias.uchile.cl Thu Feb 16 20:51:20 2006 From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P) Date: Thu, 16 Feb 2006 16:51:20 -0300 (CLST) Subject: [Pw_forum] stress in CP vs PW, previously no subject In-Reply-To: <20060216063509.22965.25724.Mailman@democritos.sissa.it> References: <20060216063509.22965.25724.Mailman@democritos.sissa.it> Message-ID: <1140119480.43f4d7b84f640@macul.ciencias.uchile.cl> Thank you Stefano for your prompt advise. I repeated the CP minimization commenting qcutz=150., q2sigma=2.0, ecfixed=24.0. I read that default value is ecfixed=40, which is larger than my cutoff for the wavefunction, then I guess that this does not affect the calculation. There is no much difference in the stress nor in the energy with respect to the calculation using qcutz=150., q2sigma=2.0, ecfixed=24.0. I also changed the occupation to fixed with pwscf, and set ecfixed, qcutz and q2sigma. I also set ibrav=14 to match the CP job. The numbers with pw.x also change little change. Then I have a significant difference in the pressure of 29 kbar with pw vs -100 GPa with CP. Below is the summary of the last steps of CP miinimization with damped dynamics (I pasted it wrongly in the previous mail) nfi ekinc temph tempp etot enthal econs econt vnhh xnhh0 vnhp xnhp0 200 0.00772 0.0 0.0 -2096.99556 -2096.99556 -2096.99556 -2096.98785 0.0000 0.0000 0.0000 0.0000 writing restart file: .//cdte64_91.save restart file written in 24.895 sec. 201 0.00753 0.0 0.0 -2096.99846 -2096.99846 -2096.99846 -2096.99093 0.0000 0.0000 0.0000 0.0000 202 0.00735 0.0 0.0 -2097.00129 -2097.00129 -2097.00129 -2096.99394 0.0000 0.0000 0.0000 0.0000 203 0.00717 0.0 0.0 -2097.00405 -2097.00405 -2097.00405 -2096.99687 0.0000 0.0000 0.0000 0.0000 204 0.00700 0.0 0.0 -2097.00675 -2097.00675 -2097.00675 -2096.99974 0.0000 0.0000 0.0000 0.0000 205 0.00684 0.0 0.0 -2097.00938 -2097.00938 -2097.00938 -2097.00254 0.0000 0.0000 0.0000 0.0000 206 0.00668 0.0 0.0 -2097.01196 -2097.01196 -2097.01196 -2097.00527 0.0000 0.0000 0.0000 0.0000 207 0.00653 0.0 0.0 -2097.01447 -2097.01447 -2097.01447 -2097.00794 0.0000 0.0000 0.0000 0.0000 208 0.00638 0.0 0.0 -2097.01693 -2097.01693 -2097.01693 -2097.01055 0.0000 0.0000 0.0000 0.0000 209 0.00623 0.0 0.0 -2097.01934 -2097.01934 -2097.01934 -2097.01310 0.0000 0.0000 0.0000 0.0000 210 0.00609 0.0 0.0 -2097.02169 -2097.02169 -2097.02169 -2097.01559 0.0000 0.0000 0.0000 0.0000 211 0.00596 0.0 0.0 -2097.02399 -2097.02399 -2097.02399 -2097.01803 0.0000 0.0000 0.0000 0.0000 212 0.00582 0.0 0.0 -2097.02623 -2097.02623 -2097.02623 -2097.02041 0.0000 0.0000 0.0000 0.0000 213 0.00570 0.0 0.0 -2097.02843 -2097.02843 -2097.02843 -2097.02274 0.0000 0.0000 0.0000 0.0000 214 0.00557 0.0 0.0 -2097.03059 -2097.03059 -2097.03059 -2097.02501 0.0000 0.0000 0.0000 0.0000 215 0.00545 0.0 0.0 -2097.03269 -2097.03269 -2097.03269 -2097.02724 0.0000 0.0000 0.0000 0.0000 216 0.00533 0.0 0.0 -2097.03475 -2097.03475 -2097.03475 -2097.02942 0.0000 0.0000 0.0000 0.0000 217 0.00522 0.0 0.0 -2097.03677 -2097.03677 -2097.03677 -2097.03155 0.0000 0.0000 0.0000 0.0000 218 0.00511 0.0 0.0 -2097.03875 -2097.03875 -2097.03875 -2097.03364 0.0000 0.0000 0.0000 0.0000 219 0.00500 0.0 0.0 -2097.04068 -2097.04068 -2097.04068 -2097.03568 0.0000 0.0000 0.0000 0.0000 nfi ekinc temph tempp etot enthal econs econt vnhh xnhh0 vnhp xnhp0 220 0.00490 0.0 0.0 -2097.04257 -2097.04257 -2097.04257 -2097.03768 0.0000 0.0000 0.0000 0.0000 This was with the default values of ecfixed, etc. The corresponding pwscf energy (occupation=fixed) is -2097.047 Ha. Eduardo > > Today's Topics: > > 1. Re: (no subject) (degironc) > 2. Where to get CVS version of Q-Espresso? (Huiqun Zhou) > 3. Total number of d electrons of cobalt (Huiqun Zhou) > 4. Re: Where to get CVS version of Q-Espresso? (Miguel Martinez) > 5. Re: question about pwcond.x (Gabriel =?iso-8859-1?Q?Aut=E8s?=) > 6. Re: Total number of d electrons of cobalt (Matteo Cococcioni) > 7. Problem relaxing cluster (Lucas Fernandez Seivane) > 8. Re: Problem relaxing cluster (Silviu Zilberman) > > --__--__-- > > Message: 1 > Date: Wed, 15 Feb 2006 09:23:03 +0100 > From: degironc > To: pw_forum at pwscf.org > Subject: Re: [Pw_forum] (no subject) > Reply-To: pw_forum at pwscf.org > > stress converges slowly with cutoff and if you are not at full > convergence > setting the variables qcutz=150., q2sigma=2.0, ecfixed=24.0, modifies > the kinetic energy > of the electrons beyond 24 ry adding a large penalty function and the > "effective" cutoff of your > calculation is something around 24 ry. > This affects the total energy and the stress. > Also having smearing instead of fixed occupation makes a difference but > > if your system is gapped it should not be large. > In order to compare output of the two codes you should use the same > setting in both. > > stefano > > > CP> > > > &SYSTEM > > ibrav = 14, > > celldm(1) = 24.4946, > > celldm(2) = 1.0,celldm(3) = 1.0,celldm(4) = > 0.0,celldm(5) = 0.0,celldm(6) = 0.0, > > nat = 64, > > ntyp = 2, > > nbnd=288,nelec=576,nspin=1, > > ecutwfc = 30.0 , > > ecutrho = 240 , > > occupations = 'fixed' , > > xc_type = 'PBE', > > > > qcutz=150., q2sigma=2.0, ecfixed=24.0, > > / > > > PW> > > > &SYSTEM > > ibrav = 1, > > celldm(1) = 24.4946, > > nat = 64, > > ntyp = 2, > > ecutwfc = 30.0 , > > ecutrho = 240 , > > occupations = 'smearing' , > > degauss = 0.02 , > > smearing = 'fermi-dirac' , > > / > > &ELECTRONS > > > > > From giannozz at nest.sns.it Fri Feb 17 10:28:31 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Feb 2006 10:28:31 +0100 Subject: [Pw_forum] stress in CP vs PW, previously no subject In-Reply-To: <1140119480.43f4d7b84f640@macul.ciencias.uchile.cl> References: <20060216063509.22965.25724.Mailman@democritos.sissa.it> <1140119480.43f4d7b84f640@macul.ciencias.uchile.cl> Message-ID: <200602171028.31573.giannozz@nest.sns.it> On Thursday 16 February 2006 20:51, Eduardo Ariel Menendez P wrote: > Then I have a significant difference in the pressure of 29 kbar > with pw vs -100 GPa with CP. you are not the first who claims that CP and PW yield different results for the same system. I have heard many such claims in the past, and almost all of them turned out to be fake: the comparison was not correct. You will have better chances to be taken seriously :-) if you find a simpler system, calculated with as little options as possible, showing a difference. If there is really one, it will show up in a simple system as well. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Feb 17 10:31:25 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Feb 2006 10:31:25 +0100 Subject: [Pw_forum] (no subject) In-Reply-To: References: Message-ID: <200602171031.25642.giannozz@nest.sns.it> On Tuesday 14 February 2006 22:33, Eduardo Ariel Menendez P wrote: > ekinc ekin epot etot tempp > 0.02666 183.66406 -1213.20570 -960.95069 0.0 > b.t.w, what is ekin? Is it the run average of ekinc? it should be the Kohn-Sham kinetic energy of electrons: \sum_i <\psi_|\nabla^2|\psi_i> P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Feb 17 10:34:33 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Feb 2006 10:34:33 +0100 Subject: [Pw_forum] about the convergence of ph.x In-Reply-To: References: Message-ID: <200602171034.34031.giannozz@nest.sns.it> On Thursday 16 February 2006 14:29, sun jason wrote: > I will very appreciate the one who help me about following question, > > the ph.x is not convergence when I calculate the second order response. it is impossible to say anything unless you better specify what you are doing (which system etc) P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From wmbmacam at lg.ehu.es Fri Feb 17 12:12:35 2006 From: wmbmacam at lg.ehu.es (=?UTF-8?B?TWlndWVsIE1hcnTDrW5leiBDYW5hbGVz?=) Date: Fri, 17 Feb 2006 12:12:35 +0100 Subject: [Pw_forum] Possible small Bug in ph.x? Message-ID: <43F5AFA3.6030702@lg.ehu.es> Hello everybody, I was doing some phonon runs in espresso 3.0. I was doing the run with ldisp=.true. and found the following (a 666 grid for a fcc): $ cat ge.dyn0 ... 0.333333333333333E+00 0.277555756156289E-16 0.333333333333333E+00 .... 0.666666666666667E+00 -0.555111512312578E-16 0.666666666666667E+00 .... Well, I'm not that worried, as these deviations are very small from 0. However, I'm suspecting these two q points won't use full symmetry as if q(2)=0. Furthermore, the kpoints.x binary generated nice q points (zero was exactly zero). Any comments on this? The machine I run this into was a Itanium2 CPU. Espresso version 3.0 (not cvs). Both CC and FC were Intel v8. MKL8 was also used. No fancy compiler flags, only -O2 -tpp2 (Itanium2 optimizer) and -mcpu=itanium2 for icc. I just tried this on a P4 2.6, compiled with g95 and SSE2 optimized atlas. And the same numbers appear. So I shouldn't worry, should I? Thank you for your comments, Miguel -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "I don't think that Debian can really compete with Gentoo. [...] Or is there something like portage in the Debian world as well?" Annonymous From jibiaoli at gmail.com Fri Feb 17 12:21:04 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Fri, 17 Feb 2006 19:21:04 +0800 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <20060111203036.18305.qmail@xuxa.iecc.com> References: <20060111195637.5386.qmail@xuxa.iecc.com> <43C564DD.000006.12909@webmail9.yandex.ru> <20060111203036.18305.qmail@xuxa.iecc.com> Message-ID: Hi, Derek! I followed your suggestions, however, the problem is still here: Program PWSCF v.3.0 starts ... Today is 17Feb2006 at 16:45:33 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx = 10 npk = 40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 gamma-point specific algorithms are used bravais-lattice index = 1 lattice parameter (a_0) = 12.0000 a.u. unit-cell volume = 1728.0000 (a.u.)^3 number of atoms/cell = 2 number of atomic types = 2 kinetic-energy cutoff = 24.0000 Ry charge density cutoff = 144.0000 Ry convergence threshold = 1.0E-07 beta = 0.7000 number of iterations used = 8 plain mixing Exchange-correlation = SLA PZ NOGX NOGC (1100) nstep = 50 celldm(1)= 12.000000 celldm(2)= 0.000000 celldm(3)= 0.000000 celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000 crystal axes: (cart. coord. in units of a_0) a(1) = ( 1.000000 0.000000 0.000000 ) a(2) = ( 0.000000 1.000000 0.000000 ) a(3) = ( 0.000000 0.000000 1.000000 ) reciprocal axes: (cart. coord. in units 2 pi/a_0) b(1) = ( 1.000000 0.000000 0.000000 ) b(2) = ( 0.000000 1.000000 0.000000 ) b(3) = ( 0.000000 0.000000 1.000000 ) PSEUDO 1 is O (US) zval = 6.0 lmax= 2 lloc= 0 Version 0 0 0 of US pseudo code Using log mesh of 1269 points The pseudopotential has 4 beta functions with: l(1) = 0 l(2) = 0 l(3) = 1 l(4) = 1 Q(r) pseudized with 0 coefficients, rinner = 0.000 0.000 0.000 0.000 0.000 PSEUDO 2 is C (US) zval = 4.0 lmax= 2 lloc= 0 Version 0 0 0 of US pseudo code Using log mesh of 1425 points The pseudopotential has 4 beta functions with: l(1) = 0 l(2) = 0 l(3) = 1 l(4) = 1 Q(r) pseudized with 0 coefficients, rinner = 0.000 0.000 0.000 0.000 0.000 atomic species valence mass pseudopotential O 6.00 1.00000 O ( 1.00) C 4.00 1.00000 C ( 1.00) 8 Sym.Ops. (no inversion) Cartesian axes site n. atom positions (a_0 units) 1 C tau( 1) = ( 0.1880000 0.0000000 0.0000000 ) 2 O tau( 2) = ( 0.0000000 0.0000000 0.0000000 ) number of k points= 1 cart. coord. in units 2pi/a_0 k( 1) = ( 0.0000000 0.0000000 0.0000000), wk = 2.0000000 G cutoff = 525.2490 ( 25271 G-vectors) FFT grid: ( 48, 48, 48) G cutoff = 350.1660 ( 13805 G-vectors) smooth grid: ( 40, 40, 40) nbndx = 20 nbnd = 5 natomwfc = 8 npwx = 1704 nelec = 10.00 nkb = 16 ngl = 440 Initial potential from superposition of free atoms Check: negative starting charge= -0.003991 starting charge 9.99996, renormalised to 10.00000 negative rho (up, down): 0.399E-02 0.000E+00 Starting wfc are atomic %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from cfts_3 : error # 1 routine called by wrong architecture %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060217/2e9ead6d/attachment.htm From giannozz at nest.sns.it Fri Feb 17 12:26:03 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Feb 2006 12:26:03 +0100 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: References: <20060111203036.18305.qmail@xuxa.iecc.com> Message-ID: <200602171226.03096.giannozz@nest.sns.it> On Friday 17 February 2006 12:21, Clark Lee wrote: > from cfts_3 : error # 1 > routine called by wrong architecture it is a known problem with intel 9. From the manual (development version): \paragraph{ifort v.9} At least some versions of ifort 9 have a buggy preprocessor that either prevents compilation of \texttt{iotk}, or produces runtime errors in \texttt{cft3}. Workaround: modify \texttt{make.sys} to explicitly perform preprocessing using \texttt{/lib/cpp}, as in the following example (courtesy from Sergei Lysenkov): \begin{verbatim} .f90.o: $(CPP) $(CPPFLAGS) $< -o $*.F90 $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o CPP = /lib/cpp CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) \end{verbatim} On some versions of RedHat Linux, you may get an obscure error: \texttt{IPO link: can not find "(" ... }, due to a bad system configuration. Add option \texttt{-no-ipo} to \texttt{LDFLAGS} in file \texttt{make.sys}. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Feb 17 12:31:05 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Feb 2006 12:31:05 +0100 Subject: [Pw_forum] Possible small Bug in ph.x? In-Reply-To: <43F5AFA3.6030702@lg.ehu.es> References: <43F5AFA3.6030702@lg.ehu.es> Message-ID: <200602171231.06022.giannozz@nest.sns.it> On Friday 17 February 2006 12:12, Miguel Mart?nez Canales wrote: > 0.333333333333333E+00 0.277555756156289E-16 0.333333333333333E+00 > .... > 0.666666666666667E+00 -0.555111512312578E-16 0.666666666666667E+00 > > Well, I'm not that worried, as these deviations are very small from 0. > However, I'm suspecting these two q points won't use full symmetry as if > q(2)=0. all symmetries are checked up to a finite small threshold, so 10^{-16} == 0 for all purposes P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From jibiaoli at gmail.com Fri Feb 17 12:47:10 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Fri, 17 Feb 2006 19:47:10 +0800 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <200602171226.03096.giannozz@nest.sns.it> References: <20060111203036.18305.qmail@xuxa.iecc.com> <200602171226.03096.giannozz@nest.sns.it> Message-ID: > > Thank you for the fast reply,Paolo Giannozzi. Unfortunately, even i used > the code in Make.sys: f90.o: $(CPP) $(CPPFLAGS) $< -o $*.F90 $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o CPP = /lib/cpp CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) the following message was obtained: ... ar: creating libiotk.a ar: iotk_attr+CHARACTER1_0.o: No such file or directory make[2]: *** [libiotk.a] Error 1 make[2]: Leaving directory `/usr/src/espresso-3.0/iotk/src' make[1]: *** [libiotk.a] Error 2 make[1]: Leaving directory `/usr/src/espresso-3.0/iotk' make: *** [libiotk] Error 2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060217/7e3fba52/attachment.htm From ceresoli at sissa.it Fri Feb 17 12:55:35 2006 From: ceresoli at sissa.it (Davide Ceresoli) Date: Fri, 17 Feb 2006 12:55:35 +0100 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: References: <20060111203036.18305.qmail@xuxa.iecc.com> <200602171226.03096.giannozz@nest.sns.it> Message-ID: <43F5B9B7.9070705@sissa.it> Clark Lee wrote: > Thank you for the fast reply,Paolo Giannozzi. Unfortunately, even i > used the code in Make.sys: > > f90.o: > $(CPP) $(CPPFLAGS) $< -o $*.F90 > $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o > > CPP = /lib/cpp > CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) > > > the following message was obtained: > > ... > > > ar: creating libiotk.a > ar: iotk_attr+CHARACTER1_0.o: No such file or directory > make[2]: *** [ libiotk.a] Error 1 > make[2]: Leaving directory `/usr/src/espresso- 3.0/iotk/src' > make[1]: *** [ libiotk.a] Error 2 > make[1]: Leaving directory `/usr/src/espresso- 3.0/iotk' > make: *** [libiotk] Error 2 Dear Clark, my hack was to substitute the fpp executable (/opt/intel/fc/9.0/bin/fpp) with that from version 8.1. HTH Davide From akohlmey at vitae.cmm.upenn.edu Fri Feb 17 13:39:12 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Fri, 17 Feb 2006 07:39:12 -0500 (EST) Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <43F5B9B7.9070705@sissa.it> Message-ID: On Fri, 17 Feb 2006, Davide Ceresoli wrote: > > ar: iotk_attr+CHARACTER1_0.o: No such file or directory > > make[2]: *** [ libiotk.a] Error 1 > > make[2]: Leaving directory `/usr/src/espresso- 3.0/iotk/src' > > make[1]: *** [ libiotk.a] Error 2 > > make[1]: Leaving directory `/usr/src/espresso- 3.0/iotk' > > make: *** [libiotk] Error 2 > > Dear Clark, > my hack was to substitute the fpp executable (/opt/intel/fc/9.0/bin/fpp) > with that from version 8.1. > HTH or better yet, register your license with intel premier support (it works for the non-commercial license as well) and download the update from intel. no need to mess up your system, if you can get a working compiler for free. there are some other problems with the v9.0 compilers fixed as well. axel > > Davide > > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From jibiaoli at gmail.com Fri Feb 17 13:58:55 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Fri, 17 Feb 2006 20:58:55 +0800 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <43F5B9B7.9070705@sissa.it> References: <20060111203036.18305.qmail@xuxa.iecc.com> <200602171226.03096.giannozz@nest.sns.it> <43F5B9B7.9070705@sissa.it> Message-ID: Yes, the program is now running correctly with intel compiler 8.1. Many thanks to Davide and Paolo Fiannozzi. Dear Clark, > my hack was to substitute the fpp executable > (/opt/intel/fc/9.0/bin/fpp) > with that from version 8.1. > HTH > > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060217/49f023bc/attachment.htm From jibiaoli at gmail.com Fri Feb 17 14:05:24 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Fri, 17 Feb 2006 21:05:24 +0800 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: References: <43F5B9B7.9070705@sissa.it> Message-ID: Ok, thank you. That's a better solution and i will try that later On 2/17/06, Axel Kohlmeyer wrote: > > On Fri, 17 Feb 2006, Davide Ceresoli wrote: > > > > ar: iotk_attr+CHARACTER1_0.o: No such file or directory > > > make[2]: *** [ libiotk.a] Error 1 > > > make[2]: Leaving directory `/usr/src/espresso- 3.0/iotk/src' > > > make[1]: *** [ libiotk.a] Error 2 > > > make[1]: Leaving directory `/usr/src/espresso- 3.0/iotk' > > > make: *** [libiotk] Error 2 > > > > Dear Clark, > > my hack was to substitute the fpp executable > (/opt/intel/fc/9.0/bin/fpp) > > with that from version 8.1. > > HTH > > > or better yet, register your license with intel premier support (it > works for the non-commercial license as well) and download the > update from intel. no need to mess up your system, if you can get > a working compiler for free. there are some other problems with > the v9.0 compilers fixed as well. > > axel > > > > > Davide > > -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060217/b38486f5/attachment.htm From konstantin_kudin at yahoo.com Fri Feb 17 21:40:01 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 17 Feb 2006 12:40:01 -0800 (PST) Subject: [Pw_forum] stress in CP vs PW, previously no subject In-Reply-To: <1140119480.43f4d7b84f640@macul.ciencias.uchile.cl> Message-ID: <20060217204001.84450.qmail@web52015.mail.yahoo.com> > The numbers with pw.x also change little change. Then I have a > significant > difference in the pressure of 29 kbar with pw vs -100 GPa with CP. ... > nfi ekinc temph tempp etot enthal econs > econt > vnhh xnhh0 vnhp xnhp0 > 220 0.00490 0.0 0.0 -2097.04257 -2097.04257 -2097.04257 > -2097.03768 > 0.0000 0.0000 0.0000 0.0000 > This was with the default values of ecfixed, etc. The corresponding > pwscf > energy (occupation=fixed) is -2097.047 Ha. Well, the biggest problem here is that the CP wavefunction appears to be unconverged. Have you actually tried to converge it fully? There is an option now, electron_dynamics='cg', which should take the guesswork out of the CP convergence. Remember, that stress is the 1st derivative of the energy, and any noise in the density will be greatly multiplied when taking derivatives. Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hqzhou at nju.edu.cn Sun Feb 19 11:28:09 2006 From: hqzhou at nju.edu.cn (Huiqun Zhou) Date: Sun, 19 Feb 2006 18:28:09 +0800 Subject: [Pw_forum] questions about vc-relax Message-ID: <003301c6353f$2ea2a2a0$1d00a8c0@solarflare> dear list-users, I'm trying to run vc-relax or vc-md calculation on a mineral using pw.x, and my purpose is to investigate what kind of structrues it would evolve into upon applying a serise of pressures. I know that because of finite-size effect the transition pressure determined this way is meaningless. I just want to get the possible structures and then use total energy calculations for different phases to determine the transition pressures at 0K. But firstly I need to make clear the following questions: (1) I think, for my purpose, I may need to use vc-relax, but what's the differences between vc-relax and vc-md method in the implementation because the PR dynamics is the same for both methods (am I wrong)? (2) Should I always set ibrav = 14 (trilinic system) for variable cell calculation? (3) Although in the manual INPUT_PW, tempw in &ION, press, wmass in &CELL are said to be used in MD runs, they also can be used in vc-relax runs (for controlling temperature), right? Thanks! Huiqun Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060219/889b9b08/attachment.htm From lyu7 at ncsu.edu Mon Feb 20 04:41:07 2006 From: lyu7 at ncsu.edu (Liping YU) Date: Sun, 19 Feb 2006 22:41:07 -0500 Subject: [Pw_forum] how to output electrostatic potential? Message-ID: <43F93A53.4060201@ncsu.edu> Dear PWSCF users, Does anybody know how to write out electrostatic potential from PWSCF quickly? Thanks! liping From akohlmey at vitae.cmm.upenn.edu Mon Feb 20 05:07:12 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Sun, 19 Feb 2006 23:07:12 -0500 (EST) Subject: [Pw_forum] how to output electrostatic potential? In-Reply-To: <43F93A53.4060201@ncsu.edu> Message-ID: On Sun, 19 Feb 2006, Liping YU wrote: LY> Dear PWSCF users, LY> Does anybody know how to write out electrostatic potential from PWSCF LY> quickly? Thanks! please have a look at example05 (where the charge density is written out) and then just look up the corresponding plot number in Doc/INPUT_PP. a. LY> liping LY> _______________________________________________ LY> Pw_forum mailing list LY> Pw_forum at pwscf.org LY> http://www.democritos.it/mailman/listinfo/pw_forum LY> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From jibiaoli at gmail.com Mon Feb 20 11:16:26 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Mon, 20 Feb 2006 18:16:26 +0800 Subject: [Pw_forum] Question on Construction of Cu(111) surface Message-ID: Dear all, I aimed to construct a five-layered Cu(111) surface of (3*3) size, by the following atomic positions(ibrav=4). But the XCRYSDEN visualized model was totally not the surface with hexagonal symmetry that i expected. Any idea about the right construction of (111) surfaces? ATOMIC_POSITIONS alat Cu 0.000000000 0.000000000 1.633014073 Cu 0.333333333 0.000000000 1.633014073 Cu 0.666666667 0.000000000 1.633014073 Cu 0.000000000 0.333333333 1.633014073 Cu 0.333333333 0.333333333 1.633014073 Cu 0.666666667 0.333333333 1.633014073 Cu 0.000000000 0.666666667 1.633014073 Cu 0.333333333 0.666666667 1.633014073 Cu 0.666666667 0.666666667 1.633014073 Cu 0.222222222 0.222222222 1.224760555 Cu 0.555555555 0.222222222 1.224760555 Cu 0.888888888 0.222222222 1.224760555 Cu 0.222222222 0.555555555 1.224760555 Cu 0.555555555 0.555555555 1.224760555 Cu 0.888888888 0.555555555 1.224760555 Cu 0.222222222 0.888888888 1.224760555 Cu 0.555555555 0.888888888 1.224760555 Cu 0.888888888 0.888888888 1.224760555 Cu 0.111111111 0.111111111 0.816507036 Cu 0.444444444 0.111111111 0.816507036 Cu 0.777777777 0.111111111 0.816507036 Cu 0.111111111 0.444444444 0.816507036 Cu 0.444444444 0.444444444 0.816507036 Cu 0.777777777 0.444444444 0.816507036 Cu 0.111111111 0.777777777 0.816507036 Cu 0.444444444 0.777777777 0.816507036 Cu 0.777777777 0.777777777 0.816507036 Cu 0.000000000 0.000000000 0.408253518 Cu 0.333333333 0.000000000 0.408253518 Cu 0.666666667 0.000000000 0.408253518 Cu 0.000000000 0.333333333 0.408253518 Cu 0.333333333 0.333333333 0.408253518 Cu 0.666666667 0.333333333 0.408253518 Cu 0.000000000 0.666666667 0.408253518 Cu 0.333333333 0.666666667 0.408253518 Cu 0.666666667 0.666666667 0.408253518 Cu 0.222222222 0.222222222 0.000000000 Cu 0.555555555 0.222222222 0.000000000 Cu 0.888888888 0.222222222 0.000000000 Cu 0.222222222 0.555555555 0.000000000 Cu 0.555555555 0.555555555 0.000000000 Cu 0.888888888 0.555555555 0.000000000 Cu 0.222222222 0.888888888 0.000000000 Cu 0.555555555 0.888888888 0.000000000 Cu 0.888888888 0.888888888 0.000000000 -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060220/e167ae52/attachment.htm From degironc at sissa.it Mon Feb 20 13:32:27 2006 From: degironc at sissa.it (degironc) Date: Mon, 20 Feb 2006 13:32:27 +0100 Subject: [Pw_forum] Question on Construction of Cu(111) surface In-Reply-To: References: Message-ID: <43F9B6DB.2030105@sissa.it> ATOMIC_POSITIONS alat means that what follows are atomic positions in CARTESIAN COORDINATES in units of alat (i.e. celldm(1)) ATOMIC_POSITIONS crystal means atomic positions given in crystal coordinates (i.e: as fraction of the fundamental lattice vectors). Your positions look like "crystal" one except that the third component (fraction along at_3) is certainly wrong and should be divided, i guess, by celldm(3) (i.e. c/a) stefano Clark Lee wrote: > Dear all, > I aimed to construct a five-layered Cu(111) surface of (3*3) size, by > the following atomic positions(ibrav=4). But the XCRYSDEN visualized > model was totally not the surface with hexagonal symmetry that i > expected. Any idea about the right construction of (111) surfaces? > > ATOMIC_POSITIONS alat > Cu 0.000000000 0.000000000 1.633014073 > Cu 0.333333333 0.000000000 1.633014073 > Cu 0.666666667 0.000000000 1.633014073 > Cu 0.000000000 0.333333333 1.633014073 > Cu 0.333333333 0.333333333 1.633014073 > Cu 0.666666667 0.333333333 1.633014073 > Cu 0.000000000 0.666666667 1.633014073 > Cu 0.333333333 0.666666667 1.633014073 > Cu 0.666666667 0.666666667 1.633014073 > Cu 0.222222222 0.222222222 1.224760555 > Cu 0.555555555 0.222222222 1.224760555 > Cu 0.888888888 0.222222222 1.224760555 > Cu 0.222222222 0.555555555 1.224760555 > Cu 0.555555555 0.555555555 1.224760555 > Cu 0.888888888 0.555555555 1.224760555 > Cu 0.222222222 0.888888888 1.224760555 > Cu 0.555555555 0.888888888 1.224760555 > Cu 0.888888888 0.888888888 1.224760555 > Cu 0.111111111 0.111111111 0.816507036 > Cu 0.444444444 0.111111111 0.816507036 > Cu 0.777777777 0.111111111 0.816507036 > Cu 0.111111111 0.444444444 0.816507036 > Cu 0.444444444 0.444444444 0.816507036 > Cu 0.777777777 0.444444444 0.816507036 > Cu 0.111111111 0.777777777 0.816507036 > Cu 0.444444444 0.777777777 0.816507036 > Cu 0.777777777 0.777777777 0.816507036 > Cu 0.000000000 0.000000000 0.408253518 > Cu 0.333333333 0.000000000 0.408253518 > Cu 0.666666667 0.000000000 0.408253518 > Cu 0.000000000 0.333333333 0.408253518 > Cu 0.333333333 0.333333333 0.408253518 > Cu 0.666666667 0.333333333 0.408253518 > Cu 0.000000000 0.666666667 0.408253518 > Cu 0.333333333 0.666666667 0.408253518 > Cu 0.666666667 0.666666667 0.408253518 > Cu 0.222222222 0.222222222 0.000000000 > Cu 0.555555555 0.222222222 0.000000000 > Cu 0.888888888 0.222222222 0.000000000 > Cu 0.222222222 0.555555555 0.000000000 > Cu 0.555555555 0.555555555 0.000000000 > Cu 0.888888888 0.555555555 0.000000000 > Cu 0.222222222 0.888888888 0.000000000 > Cu 0.555555555 0.888888888 0.000000000 > Cu 0.888888888 0.888888888 0.000000000 > > From lyu7 at ncsu.edu Mon Feb 20 16:57:04 2006 From: lyu7 at ncsu.edu (Liping YU) Date: Mon, 20 Feb 2006 10:57:04 -0500 Subject: [Pw_forum] how to output electrostatic potential? In-Reply-To: References: Message-ID: <43F9E6D0.5010406@ncsu.edu> Thanks! If I am right, the electrostatic potential should be V_h + V_ion-ion + V_core (the potential due to the core of atom, -Z*erf(|r-R|/R)/|r-R|). In the PW code, I can find vrs, vr, V_loc, V_ltot, V_h, V_xc and so on. But I can't find the variables defining corresponding potentials of V_ion-ion and V_core. has anyone ever done this before? Thank you! liping Axel Kohlmeyer wrote: >On Sun, 19 Feb 2006, Liping YU wrote: > >LY> Dear PWSCF users, >LY> Does anybody know how to write out electrostatic potential from PWSCF >LY> quickly? Thanks! > >please have a look at example05 (where the charge density is written >out) and then just look up the corresponding plot number in >Doc/INPUT_PP. > >a. > > >LY> liping >LY> _______________________________________________ >LY> Pw_forum mailing list >LY> Pw_forum at pwscf.org >LY> http://www.democritos.it/mailman/listinfo/pw_forum >LY> > > > From jibiaoli at gmail.com Tue Feb 21 04:57:22 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Tue, 21 Feb 2006 11:57:22 +0800 Subject: [Pw_forum] Question on Construction of Cu(111) surface In-Reply-To: <43F9B6DB.2030105@sissa.it> References: <43F9B6DB.2030105@sissa.it> Message-ID: Thank you for your suggestion. I created a (111) surface correctely, however, when i run scf calculation it stoped withour any error message. And the programe also stoped for the case of 'nscf' calculation with the error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from potinit : error # 1 starting and expected charges differ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... Need your advise. my input file is &CONTROL title = 'pd111scf' , calculation = 'scf' , restart_mode = 'from_scratch' , outdir = '/home/tmp/' , pseudo_dir = '/usr/src/PWSCF3/pseudo/' , prefix = 'pd111' , verbosity = 'high' , / &SYSTEM ibrav = 4, celldm(1) = 15.595908584, celldm(3) = 3, nat = 45, ntyp = 1, ecutwfc = 10 , ecutrho = 300 , nosym = .false. , occupations = 'smearing' , degauss = 0.05 , smearing = 'methfessel-paxton' , nspin = 1 , / &ELECTRONS conv_thr = 1.0d-6 , mixing_beta = 0.3 , / ATOMIC_SPECIES Pd 106.42000 Pd.pbe-nd-rrkjus.UPF.txt ATOMIC_POSITIONS crystal Pd -0.000000000 0.000000000 0.090727951 0 0 0 Pd -0.000000000 0.333333333 0.090727951 0 0 0 Pd -0.000000000 0.666666667 0.090727951 0 0 0 Pd 0.333333333 0.000000000 0.090727951 0 0 0 Pd 0.333333333 0.333333333 0.090727951 0 0 0 Pd 0.333333333 0.666666667 0.090727951 0 0 0 Pd 0.666666667 0.000000000 0.090727951 0 0 0 Pd 0.666666667 0.333333333 0.090727951 0 0 0 Pd 0.666666667 0.666666667 0.090727951 0 0 0 Pd -0.000000000 0.000000000 0.362911803 0 0 0 Pd -0.000000000 0.333333333 0.362911803 0 0 0 Pd -0.000000000 0.666666667 0.362911803 0 0 0 Pd 0.333333333 0.000000000 0.362911803 0 0 0 Pd 0.333333333 0.333333333 0.362911803 0 0 0 Pd 0.333333333 0.666666667 0.362911803 0 0 0 Pd 0.666666667 0.000000000 0.362911803 0 0 0 Pd 0.666666667 0.333333333 0.362911803 0 0 0 Pd 0.666666667 0.666666667 0.362911803 0 0 0 Pd 0.222222222 0.111111111 -0.000000000 0 0 0 Pd 0.222222222 0.444444444 -0.000000000 0 0 0 Pd 0.222222222 0.777777778 -0.000000000 0 0 0 Pd 0.555555556 0.111111111 -0.000000000 0 0 0 Pd 0.555555556 0.444444444 -0.000000000 0 0 0 Pd 0.555555556 0.777777778 -0.000000000 0 0 0 Pd 0.888888889 0.111111111 -0.000000000 0 0 0 Pd 0.888888889 0.444444444 -0.000000000 0 0 0 Pd 0.888888889 0.777777778 -0.000000000 0 0 0 Pd 0.222222222 0.111111111 0.272183852 0 0 0 Pd 0.222222222 0.444444444 0.272183852 0 0 0 Pd 0.222222222 0.777777778 0.272183852 0 0 0 Pd 0.555555556 0.111111111 0.272183852 0 0 0 Pd 0.555555556 0.444444444 0.272183852 0 0 0 Pd 0.555555556 0.777777778 0.272183852 0 0 0 Pd 0.888888889 0.111111111 0.272183852 0 0 0 Pd 0.888888889 0.444444444 0.272183852 0 0 0 Pd 0.888888889 0.777777778 0.272183852 0 0 0 Pd 0.111111111 0.222222222 0.181455902 0 0 0 Pd 0.111111111 0.555555556 0.181455902 0 0 0 Pd 0.111111111 0.888888889 0.181455902 0 0 0 Pd 0.444444444 0.222222222 0.181455902 0 0 0 Pd 0.444444444 0.555555556 0.181455902 0 0 0 Pd 0.444444444 0.888888889 0.181455902 0 0 0 Pd 0.777777778 0.222222222 0.181455902 0 0 0 Pd 0.777777778 0.555555556 0.181455902 0 0 0 Pd 0.777777778 0.888888889 0.181455902 0 0 0 K_POINTS automatic 4 4 1 0 0 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060221/5bdc1cbb/attachment.htm From giannozz at nest.sns.it Tue Feb 21 10:56:25 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Feb 2006 10:56:25 +0100 Subject: [Pw_forum] Question on Construction of Cu(111) surface In-Reply-To: References: <43F9B6DB.2030105@sissa.it> Message-ID: <200602211056.25561.giannozz@nest.sns.it> On Tuesday 21 February 2006 04:57, Clark Lee wrote: > Thank you for your suggestion. I created a (111) surface correctely, > however, when i run scf calculation it stoped withour any error message. possible reasons for this are listed the manual > And the programe also stoped for the case of 'nscf' calculation with > the error: the non-scf calculation should be run AFTER a successful scf one. It is possible to do a non-scf calculation using the potential generated by a superposition of atomic charge densities, but more often than not the resulting charge will not integrate to the expected value and you will get an error message (that you may easily remove, if you want) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mverissi at ictp.it Tue Feb 21 17:48:55 2006 From: mverissi at ictp.it (Marcos Verissimo Alves) Date: Tue, 21 Feb 2006 17:48:55 +0100 (CET) Subject: [Pw_forum] Error in spin-polarized calculation In-Reply-To: <200602211056.25561.giannozz@nest.sns.it> References: <43F9B6DB.2030105@sissa.it> <200602211056.25561.giannozz@nest.sns.it> Message-ID: <38091.10.50.40.120.1140540535.squirrel@webmail2.ictp.trieste.it> Hi all, I am trying to run a spin-polarized calculation on a carbon + hydrogen system using two US pseudos from the pwscf page. However, the calculation stops in the very beginning, with the following error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from cdiaghg : error # 126 info =/= 0 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% What could be the trouble? I am attaching the input and output files for your examination. Thanks, Marcos -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Condensed Matter and Statistical Physics Sector International Centre for Theoretical Physics Trieste, Italy -------- "So long and thanks for all the fish!" Quoted from the dolphins of "The Hitchhiker's Guide to the Galaxy". -------------- next part -------------- A non-text attachment was scrubbed... Name: graph.h.vaca.in Type: application/octet-stream Size: 2359 bytes Desc: not available Url : /pipermail/attachments/20060221/2780954e/attachment.obj From mverissi at ictp.it Tue Feb 21 17:49:44 2006 From: mverissi at ictp.it (Marcos Verissimo Alves) Date: Tue, 21 Feb 2006 17:49:44 +0100 (CET) Subject: [Pw_forum] Error in spin-polarized calculation In-Reply-To: <200602211056.25561.giannozz@nest.sns.it> References: <43F9B6DB.2030105@sissa.it> <200602211056.25561.giannozz@nest.sns.it> Message-ID: <38092.10.50.40.120.1140540584.squirrel@webmail2.ictp.trieste.it> Hi all, I am trying to run a spin-polarized calculation on a carbon + hydrogen system using two US pseudos from the pwscf page. However, the calculation stops in the very beginning, with the following error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from cdiaghg : error # 126 info =/= 0 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% What could be the trouble? I am attaching the input and output files for your examination. Thanks, Marcos -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Condensed Matter and Statistical Physics Sector International Centre for Theoretical Physics Trieste, Italy -------- "So long and thanks for all the fish!" Quoted from the dolphins of "The Hitchhiker's Guide to the Galaxy". -------------- next part -------------- A non-text attachment was scrubbed... Name: graph.h.vaca.in Type: application/octet-stream Size: 2359 bytes Desc: not available Url : /pipermail/attachments/20060221/46bc777b/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: errore.out Type: application/octet-stream Size: 12224 bytes Desc: not available Url : /pipermail/attachments/20060221/46bc777b/attachment-0001.obj From giannozz at nest.sns.it Tue Feb 21 18:51:24 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Feb 2006 18:51:24 +0100 Subject: [Pw_forum] Error in spin-polarized calculation In-Reply-To: <38092.10.50.40.120.1140540584.squirrel@webmail2.ictp.trieste.it> References: <200602211056.25561.giannozz@nest.sns.it> <38092.10.50.40.120.1140540584.squirrel@webmail2.ictp.trieste.it> Message-ID: <200602211851.24926.giannozz@nest.sns.it> On Tuesday 21 February 2006 17:49, Marcos Verissimo Alves wrote: > from cdiaghg : error # 126 > info =/= 0 > What could be the trouble? from the manual: ----------- - pw.x stops with error in cdiagh or cdiaghg. Possible reasons: - serious error in data, such as bad atomic positions or bad crystal structure/supercell; - ... ----------- I checked your data with the (in)utility "dist.x" (see the header of pwtools/dist.f) and it says that the shortest C-C distance is 0.00362A Paoo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mverissi at ictp.it Tue Feb 21 18:52:58 2006 From: mverissi at ictp.it (Marcos Verissimo Alves) Date: Tue, 21 Feb 2006 18:52:58 +0100 (CET) Subject: [Pw_forum] Error in spin-polarized calculation In-Reply-To: <200602211851.24926.giannozz@nest.sns.it> References: <200602211056.25561.giannozz@nest.sns.it> <38092.10.50.40.120.1140540584.squirrel@webmail2.ictp.trieste.it> <200602211851.24926.giannozz@nest.sns.it> Message-ID: <38238.10.50.40.120.1140544378.squirrel@webmail2.ictp.trieste.it> Thanks... Obviously I did not check the manual carefully enough. I will also check the positions. Marcos > On Tuesday 21 February 2006 17:49, Marcos Verissimo Alves wrote: > >> from cdiaghg : error # 126 >> info =/= 0 > >> What could be the trouble? > > from the manual: > ----------- > - pw.x stops with error in cdiagh or cdiaghg. > Possible reasons: > - serious error in data, such as bad atomic positions or bad crystal > structure/supercell; > - ... > ----------- > I checked your data with the (in)utility "dist.x" (see the > header of pwtools/dist.f) and it says that the shortest C-C > distance is 0.00362A > > Paoo > > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From tveloz at gmail.com Tue Feb 21 19:08:59 2006 From: tveloz at gmail.com (TOMAS VELOZ) Date: Tue, 21 Feb 2006 15:08:59 -0300 Subject: [Pw_forum] gvect Message-ID: <613d5f450602211008t2018639jda81905d70f51f72@mail.gmail.com> Hi: i'm trying to edit PP/voronoy.f90 and i can't find the meaning of some variables which are in gvect.mod (because i can't read it). what can i do? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060221/12e9ba77/attachment.htm From naromero at gmail.com Tue Feb 21 19:46:41 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 21 Feb 2006 13:46:41 -0500 Subject: [Pw_forum] real space non-local pseudopotential projectors Message-ID: <6ac064b60602211046j7a74cc7cpe3b9da5ff5a80036@mail.gmail.com> Hi, Does PWSCF use real space non-local pseudopotential projectors using the method of King-Smith et. al? What are the largest system that people have treated using PWSCF? Given excellent computer resources, could it handle 1000 atom systems (lighter elements)? Thanks, -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From swblelia at sw.ehu.es Tue Feb 21 20:36:20 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Tue, 21 Feb 2006 20:36:20 +0100 Subject: [Pw_forum] error: npert > max_irr_dim Message-ID: <1140550580.12009.45.camel@swpc50.sw.ehu.es> Hello all. While performing a phonon calculation on a monolayer of C I got the following error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% task # 1 from set_irr : error # 0 npert > max_irr_dim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Searching the pw_forum archive, the solution seems to be to recompile the code using a bigger value for max_irr_dim parameter. But.... from the archive:"The parameter defines maximum allowed number of degeneracy of modes" Could somebody tell me what does this mean? By the way, I have made exactly the same calculation (all the parameters being identical and with the same list of q vectors) but changing ecutwfc from 35 ryd to 32. In this case there was no error. Am I going beyond any kind of limit? thank a lot From giannozz at nest.sns.it Tue Feb 21 20:49:17 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Feb 2006 20:49:17 +0100 Subject: [Pw_forum] real space non-local pseudopotential projectors In-Reply-To: <6ac064b60602211046j7a74cc7cpe3b9da5ff5a80036@mail.gmail.com> References: <6ac064b60602211046j7a74cc7cpe3b9da5ff5a80036@mail.gmail.com> Message-ID: <200602212049.17800.giannozz@nest.sns.it> On Tuesday 21 February 2006 19:46, Nichols A. Romero wrote: > Does PWSCF use real space non-local pseudopotential projectors > using the method of King-Smith et. al presently it doesn't Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From marzari at MIT.EDU Tue Feb 21 21:30:23 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Tue, 21 Feb 2006 15:30:23 -0500 Subject: [Pw_forum] real space non-local pseudopotential projectors In-Reply-To: <6ac064b60602211046j7a74cc7cpe3b9da5ff5a80036@mail.gmail.com> References: <6ac064b60602211046j7a74cc7cpe3b9da5ff5a80036@mail.gmail.com> Message-ID: <43FB785F.5020803@mit.edu> Dear Nichols, We don't really have much experience with PWSCF and very large systems, but 1000 atoms with CP (inside quantum-espresso) seems doable (of course, it depends on how many electrons you have). Note that the CP steps mentioned below are damped dynamics - CVS CP can now do the ground state relaxation with conjugate-gradients, as well, that is more efficient (in practice, even if in theory they are comparable). ------ On 8 dual-xeon motherboards, 3.4 GHz (16 cpu, although the second CPU on each motherboard is close to useless): PWSCF (10,10) CNT - (49bohr*49*14 , 125 atoms, 3 k-points) electronic relax - 3 hours ionic relax - it really depends on the initial configuration. Between 5 and 10 days. CP (10,10) CNT - (43bohr*43*37, 325 atoms) electronic relax - 17 hours (310 damped dynamics steps) -------- On 4 PIV 3.2 GHz CP (5,5) CNT - (36bohr*36*56, 248 atoms, ) electronic relax - 44 hours (260 damped dyanmics steps) On the same machine (4 PIV, 16GB) a spin-unpolarized protein, with ~340 atoms, took ~10 minutes per CP step. -------- Let us know what you get ! Best, nicola Nichols A. Romero wrote: > Hi, > > Does PWSCF use real space non-local pseudopotential projectors using > the method of King-Smith et. al? > > What are the largest system that people have treated using PWSCF? > Given excellent computer resources, could it handle 1000 atom systems > (lighter elements)? > > Thanks, > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From giannozz at nest.sns.it Tue Feb 21 22:26:58 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Feb 2006 22:26:58 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <1140550580.12009.45.camel@swpc50.sw.ehu.es> References: <1140550580.12009.45.camel@swpc50.sw.ehu.es> Message-ID: <200602212226.58933.giannozz@nest.sns.it> On Tuesday 21 February 2006 20:36, Aritz Leonardo wrote: > While performing a phonon calculation on a monolayer of C > I got the following error: > from set_irr : error # 0 > npert > max_irr_dim this shouldn't happen. Could you please send a job demonstrating such behavior? Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Tue Feb 21 22:29:56 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Feb 2006 22:29:56 +0100 Subject: [Pw_forum] gvect In-Reply-To: <613d5f450602211008t2018639jda81905d70f51f72@mail.gmail.com> References: <613d5f450602211008t2018639jda81905d70f51f72@mail.gmail.com> Message-ID: <200602212229.56052.giannozz@nest.sns.it> On Tuesday 21 February 2006 19:08, TOMAS VELOZ wrote: > i'm trying to edit PP/voronoy.f90 and i can't find the meaning of some > variables which are in gvect.mod (because i can't read it). I hope you are not trying to read a compiled module file! Module "gvect" is in PW/pwcom.f90 and the meaning of the variables is explained (sort of) there Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From pwscfklt at gmail.com Tue Feb 21 22:36:25 2006 From: pwscfklt at gmail.com (Konzern) Date: Tue, 21 Feb 2006 16:36:25 -0500 Subject: [Pw_forum] question about q-point and eigenvector from ph.x Message-ID: Dear all, There is one question always puzzles me. If my understanding is correct, for lattice dynamics, the q-point denotes the propagation direction of the lattice wave, while the eigenvector represents the vibration direction of a specific atom. Waves whose eigenvectors are perpendicular to the q-point are transverse waves while parallel are longitudial wave. Moreover, there should be 2N transverse modes and N longitudial ones. However, I checked the results from ph.x, there did not seem to exist such relations. I am afraid if my understanding was wrong or I have used the wrong interpretation of the eigenvectors. Anyone can help me out? Besides, the eigenvectors given by ph.x should be in cartesian coordination, right? Thanks. Konzern -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060221/b393e77c/attachment.htm From degironc at sissa.it Tue Feb 21 22:55:45 2006 From: degironc at sissa.it (Stefano de Gironcoli) Date: Tue, 21 Feb 2006 22:55:45 +0100 (CET) Subject: [Pw_forum] question about q-point and eigenvector from ph.x In-Reply-To: References: Message-ID: In general eigenmodes are neither transverse nor longitudinal. Only when the symmetry of the small group of q is sufficiently high eigenmodes can be labeled as T or L. stefano On Tue, 21 Feb 2006, Konzern wrote: > Dear all, > > There is one question always puzzles me. If my understanding is correct, > for lattice dynamics, the q-point denotes the propagation direction of the > lattice wave, while the eigenvector represents the vibration direction of > a specific atom. Waves whose eigenvectors are perpendicular to the > q-point are transverse waves while parallel are longitudial wave. Moreover, > there should be 2N transverse modes and N longitudial ones. > > However, I checked the results from ph.x, there did not seem to exist > such relations. I am afraid if my understanding was wrong or I have used > the wrong interpretation of the eigenvectors. > > Anyone can help me out? > > Besides, the eigenvectors given by ph.x should be in cartesian coordination, > right? > > Thanks. > > Konzern > From wanjianyin at gmail.com Wed Feb 22 07:15:31 2006 From: wanjianyin at gmail.com (Yin Wanjian) Date: Wed, 22 Feb 2006 14:15:31 +0800 Subject: [Pw_forum] (no subject) Message-ID: Hi, All, Quantum-Espresso could use old BHS pseudopotential, but I could not find any of this old type in directory of ~/pseudo , anyway, I have tried to generate some along with the the subroutine readbhs(is,iunps) in ~/CPV/cplib.f90 file . But I can't understand the following lines, ! ------------------------------------------------------------------ ! wavefunctions are read from file iunps ! ------------------------------------------------------------------ do il=1,nbeta(is) read(iunps,*) mesh(is),cmesh(is) ! ! kkbeta is for compatibility with Vanderbilt PP ! kkbeta(is)=mesh(is) do j=1,mesh(is) read(iunps,*) jj,r(j,is),betar(j,il,is) end do end do ! -------------------------------------------------------------------- It seems to translate BHS type to Vanderbilt type! What does it mean? Your help will be greatly appreciated! Yin Wanjian From wanjianyin at gmail.com Wed Feb 22 07:16:54 2006 From: wanjianyin at gmail.com (Yin Wanjian) Date: Wed, 22 Feb 2006 14:16:54 +0800 Subject: [Pw_forum] BHS pseudopotential for Quantum-Espresso! Message-ID: Hi, All, Quantum-Espresso could use old BHS pseudopotential, but I could not find any of this old type in directory of ~/pseudo , anyway, I have tried to generate some along with the the subroutine readbhs(is,iunps) in ~/CPV/cplib.f90 file . But I can't understand the following lines, ! ------------------------------------------------------------------ ! wavefunctions are read from file iunps ! ------------------------------------------------------------------ do il=1,nbeta(is) read(iunps,*) mesh(is),cmesh(is) ! ! kkbeta is for compatibility with Vanderbilt PP ! kkbeta(is)=mesh(is) do j=1,mesh(is) read(iunps,*) jj,r(j,is),betar(j,il,is) end do end do ! -------------------------------------------------------------------- It seems to translate BHS type to Vanderbilt type! What does it mean? Your help will be greatly appreciated! Yin Wanjian From jibiaoli at gmail.com Wed Feb 22 08:29:50 2006 From: jibiaoli at gmail.com (Clark Lee) Date: Wed, 22 Feb 2006 15:29:50 +0800 Subject: [Pw_forum] Question about system size of PW calculation Message-ID: Dear Palo The mannual states that "pw.x works for simple systems, but not for large systems". Does that mean a system with 40 more atoms could lead to failure? Please give more information about that. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060222/d2388a2a/attachment.htm From giannozz at nest.sns.it Wed Feb 22 09:38:01 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 22 Feb 2006 09:38:01 +0100 Subject: [Pw_forum] Question about system size of PW calculation In-Reply-To: References: Message-ID: <200602220938.01596.giannozz@nest.sns.it> On Wednesday 22 February 2006 08:29, Clark Lee wrote: > The mannual states that "pw.x works for simple systems, > but not for large systems". the manual doesn't say anything like this. IF (and I repeat: IF) this happens, it explains what to do. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From swblelia at sw.ehu.es Wed Feb 22 10:14:22 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Wed, 22 Feb 2006 10:14:22 +0100 Subject: [Pw_forum] error: npert > max_irr_dim Message-ID: <1140599662.12009.53.camel@swpc50.sw.ehu.es> Hello: This is the job that crashes. From a list of Q vectors q=0.30,0.211695,0.0 gives the mentioned error I am running the job in a parallel cluster of OPTERONs with portlan 6.0 compiler. I repeat that the same calculation with E=32 ended ok! Thanks a lot. E=35.0 ca=6.5 a=4.65 # %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5 for PARAM in `cat qELPH1`; do QX="`echo $PARAM | awk -F: '{print $1}'`"; QY="`echo $PARAM | awk -F: '{print $2}'`"; QZ="`echo $PARAM | awk -F: '{print $3}'`"; echo "$QX , $QY , $QZ ,$a"; # # self-consistent calculation # cat > $a.scf.in << EOF &control calculation='scf', title='C MONOLAYER surface phonons' restart_mode='from_scratch', prefix='C', pseudo_dir = './', outdir='$TMP_DIR/', tprnfor = .true. tstress = .true. / &system ibrav=4,celldm(1)=$a celldm(3)=$ca,nat=2,ntyp= 1, ecutwfc=$E,occupations='smearing', smearing='m-p',degauss=0.0075 / &electrons conv_thr = 1.0d-8 mixing_beta= 0.5 / ATOMIC_SPECIES C 12.01 C.pz-vbc.UPF ATOMIC_POSITIONS C 0.0000 0.00000000 0.000 C 0.0000 0.577350269 0.000 K_POINTS {automatic} 20 20 1 1 1 0 EOF # # non self-consistent calculation # cat > $a.nscf.in << EOF &control calculation='phonon' restart_mode='from_scratch', pseudo_dir = './', outdir='$TMP_DIR/', prefix='C' / &system ibrav=4,celldm(1)=$a, celldm(3)=$ca,nat=2,ntyp=1, ecutwfc=$E,occupations='smearing', smearing='m-p',degauss=0.0075 / &electrons conv_thr = 1.0d-8 mixing_beta = 0.5 / &phonon xqq(1)=$QX, xqq(2)=$QY, xqq(3)=$QZ / ATOMIC_SPECIES C 12.01 C.pz-vbc.UPF ATOMIC_POSITIONS C 0.0000 0.000000000 0.000 C 0.0000 0.577350269 0.000 K_POINTS {automatic} 20 20 1 1 1 0 EOF # # phonon calculation # cat > $a.ph.in << EOF ESTA LINEA ES NECESARIA &inputph alpha_mix(1)=0.2 tr2_ph=1.0d-13, prefix='C', amass(1)=12.01, outdir='$TMP_DIR/' fildyn='C.dyn' fildvscf='Cdv' / $QX $QY $QZ EOF From giannozz at nest.sns.it Wed Feb 22 10:25:57 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 22 Feb 2006 10:25:57 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <1140599662.12009.53.camel@swpc50.sw.ehu.es> References: <1140599662.12009.53.camel@swpc50.sw.ehu.es> Message-ID: <200602221025.57162.giannozz@nest.sns.it> On Wednesday 22 February 2006 10:14, Aritz Leonardo wrote: > I am running the job in a parallel cluster of OPTERONs > with portlan 6.0 compiler. you better try with g95 or ifort ... P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From swblelia at sw.ehu.es Wed Feb 22 10:43:44 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Wed, 22 Feb 2006 10:43:44 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <200602221025.57162.giannozz@nest.sns.it> References: <1140599662.12009.53.camel@swpc50.sw.ehu.es> <200602221025.57162.giannozz@nest.sns.it> Message-ID: <1140601424.12009.56.camel@swpc50.sw.ehu.es> So, it is only a problem of the compiler? Did it work with ifort? El mi?, 22-02-2006 a las 10:25 +0100, Paolo Giannozzi escribi?: > On Wednesday 22 February 2006 10:14, Aritz Leonardo wrote: > > > I am running the job in a parallel cluster of OPTERONs > > with portlan 6.0 compiler. > > you better try with g95 or ifort ... > > P. > > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From giannozz at nest.sns.it Wed Feb 22 11:09:02 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 22 Feb 2006 11:09:02 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <1140601424.12009.56.camel@swpc50.sw.ehu.es> References: <1140599662.12009.53.camel@swpc50.sw.ehu.es> <200602221025.57162.giannozz@nest.sns.it> <1140601424.12009.56.camel@swpc50.sw.ehu.es> Message-ID: <200602221109.02352.giannozz@nest.sns.it> On Wednesday 22 February 2006 10:43, Aritz Leonardo wrote: > So, it is only a problem of the compiler? Did it work with ifort? it takes some time to run a job that requires 2400 k-points, you know... I have seen all kind of problems with pgi compilers, so when I see a weird problem in a code compiled with pgi, I blame the compiler, unless there is evidence of the contrary Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Feb 23 09:36:35 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 23 Feb 2006 09:36:35 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <1140601424.12009.56.camel@swpc50.sw.ehu.es> References: <1140599662.12009.53.camel@swpc50.sw.ehu.es> <200602221025.57162.giannozz@nest.sns.it> <1140601424.12009.56.camel@swpc50.sw.ehu.es> Message-ID: <200602230936.36005.giannozz@nest.sns.it> On Wednesday 22 February 2006 10:43, Aritz Leonardo wrote: > So, it is only a problem of the compiler? Did it work with ifort? it did: see http://web1.sns.it/~giannozz/public/irreps.tgz Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From swblelia at sw.ehu.es Thu Feb 23 10:00:03 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 23 Feb 2006 10:00:03 +0100 Subject: [Pw_forum] error: npert > max_irr_dim In-Reply-To: <200602230936.36005.giannozz@nest.sns.it> References: <1140599662.12009.53.camel@swpc50.sw.ehu.es> <200602221025.57162.giannozz@nest.sns.it> <1140601424.12009.56.camel@swpc50.sw.ehu.es> <200602230936.36005.giannozz@nest.sns.it> Message-ID: <1140685203.5659.0.camel@swpc50.sw.ehu.es> Thanks a lot Paolo. El jue, 23-02-2006 a las 09:36 +0100, Paolo Giannozzi escribi?: > On Wednesday 22 February 2006 10:43, Aritz Leonardo wrote: > > > So, it is only a problem of the compiler? Did it work with ifort? > > it did: see http://web1.sns.it/~giannozz/public/irreps.tgz > > Paolo From tveloz at gmail.com Fri Feb 24 01:12:29 2006 From: tveloz at gmail.com (TOMAS VELOZ) Date: Thu, 23 Feb 2006 21:12:29 -0300 Subject: [Pw_forum] voronoy input file Message-ID: <613d5f450602231612v76a63939mf6a5bceb9efdb6b0@mail.gmail.com> Hi: i'm trying to edit voronoy.f90. i can't understand how plot_io reads rho grid, you must to write it in the input file or it reads from scf output like pp.x?? if somebody have a voronoy.x input file will be very useful for me. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060223/99fd51d4/attachment.htm From giannozz at nest.sns.it Fri Feb 24 09:34:34 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 24 Feb 2006 09:34:34 +0100 Subject: [Pw_forum] voronoy input file In-Reply-To: <613d5f450602231612v76a63939mf6a5bceb9efdb6b0@mail.gmail.com> References: <613d5f450602231612v76a63939mf6a5bceb9efdb6b0@mail.gmail.com> Message-ID: <200602240934.34511.giannozz@nest.sns.it> On Friday 24 February 2006 01:12, TOMAS VELOZ wrote: > i'm trying to edit voronoy.f90. > i can't understand how plot_io reads rho grid, you must to write it in the > input file or it reads from scf output like pp.x?? it reads from the data file ("filplot") produced by pp.x Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Feb 24 11:08:51 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 24 Feb 2006 11:08:51 +0100 Subject: [Pw_forum] BHS pseudopotential for Quantum-Espresso! In-Reply-To: References: Message-ID: <200602241108.51548.giannozz@nest.sns.it> On Wednesday 22 February 2006 07:16, Yin Wanjian wrote: > I can't understand the following lines [...] > It seems to translate BHS type to Vanderbilt type! What does it mean? BHS pseudopotentials in separable (Kleinman-Bylander) form are a special case of ultrasoft (Vanderbilt) pseudopotentials. It is easier to deal with all types of pseudopotentials in the same way. Note however that the 'old BHS format' read in CP and FPMD does not contain BHS pseudopotentials in separable form, but in the standard semi-local form. They are subsequently converted. The new 'UPF' format instead contains only pseudopotentials in separable form Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From Conor.Hogan at roma2.infn.it Fri Feb 24 14:07:22 2006 From: Conor.Hogan at roma2.infn.it (Conor Hogan) Date: Fri, 24 Feb 2006 14:07:22 +0100 (GMT+0100) Subject: [Pw_forum] configure for XD1 In-Reply-To: Message-ID: Dear forum, Can someone supply me with the best configure options for pw.x for the Cray XD1 in Cineca? I'm sure someone on this list has already done this...! The problems being the somewhat buggy PGI compiler and the AMD architecture. Apologies if this is more suited to Cineca support. Cheers Conor Dr. Conor Hogan Dipartimento di Fisica e CNR-INFM Universita' di Roma "Tor Vergata" Tel: +39 06 72594548 Fax: +39 06 2023507 http://www.fisica.uniroma2.it/~cmtheo-group/ The early bird gets the worm, but the second mouse gets the cheese. - S. Wright If you go through a lot of hammers each month, I don't think it necessarily means you're a hard worker. It may just mean that you have a lot to learn about proper hammer maintenance - J. Handey From akohlmey at vitae.cmm.upenn.edu Fri Feb 24 14:28:36 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Fri, 24 Feb 2006 08:28:36 -0500 (EST) Subject: [Pw_forum] configure for XD1 In-Reply-To: Message-ID: On Fri, 24 Feb 2006, Conor Hogan wrote: conor, please try the pathscale compilers. also PGI 6.0.5 is somewhat decent, but at least on the xt3 here, cray seems to default to the more broken 6.0.1 version. try playing with the module command... good luck, axel. CH> Dear forum, CH> Can someone supply me with the best configure options for pw.x CH> for the Cray XD1 in Cineca? I'm sure someone on this list has already done CH> this...! The problems being the somewhat buggy PGI compiler and the AMD CH> architecture. CH> Apologies if this is more suited to Cineca support. CH> Cheers CH> Conor CH> CH> CH> Dr. Conor Hogan CH> Dipartimento di Fisica e CNR-INFM CH> Universita' di Roma "Tor Vergata" CH> Tel: +39 06 72594548 CH> Fax: +39 06 2023507 CH> http://www.fisica.uniroma2.it/~cmtheo-group/ CH> CH> The early bird gets the worm, but the second mouse gets the cheese. - S. Wright CH> CH> If you go through a lot of hammers each month, I don't think it necessarily CH> means you're a hard worker. It may just mean that you have a lot to learn CH> about proper hammer maintenance - J. Handey CH> CH> CH> _______________________________________________ CH> Pw_forum mailing list CH> Pw_forum at pwscf.org CH> http://www.democritos.it/mailman/listinfo/pw_forum CH> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From wanjianyin at gmail.com Sat Feb 25 09:19:08 2006 From: wanjianyin at gmail.com (Yin Wanjian) Date: Sat, 25 Feb 2006 16:19:08 +0800 Subject: [Pw_forum] BHS pseudopotential for Quantum-Espresso! Message-ID: Prof. Giannozzi, Thanks for your instant reply! However, I don't understand your following words clearly! > however that the 'old BHS format' read in CP and FPMD does not > contain BHS pseudopotentials in separable form, but in the standard > semi-local form. They are subsequently converted. The new 'UPF' > format instead contains only pseudopotentials in separable form Can Quantum-Espresso use BHS pseudopotential ? Best Regards! Yin Wanjian From degironc at sissa.it Sat Feb 25 10:31:33 2006 From: degironc at sissa.it (Stefano de Gironcoli) Date: Sat, 25 Feb 2006 10:31:33 +0100 (CET) Subject: [Pw_forum] BHS pseudopotential for Quantum-Espresso! In-Reply-To: References: Message-ID: Not in the original semilocal form but only in the KB fully non local form: even when the semilocal form is read (as in the "old" format Paolo Giannozzi was referring to) they are internally converted to KB from. It would be possible to write a tool that write semilocal pseudopotential in multy-projector KB-like pseudo in UPF formata and that would be dealt with by all QE codes since they allow for more than one projector per channel. This tool is however presently not available in the distribution. And anyone interested can contibute it to the community. stefano On Sat, 25 Feb 2006, Yin Wanjian wrote: > Prof. Giannozzi, > Thanks for your instant reply! > However, I don't understand your following words clearly! > >> however that the 'old BHS format' read in CP and FPMD does not >> contain BHS pseudopotentials in separable form, but in the standard >> semi-local form. They are subsequently converted. The new 'UPF' >> format instead contains only pseudopotentials in separable form > > Can Quantum-Espresso use BHS pseudopotential ? > Best Regards! > > Yin Wanjian > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From mpayami at aeoi.org.ir Tue Feb 28 05:52:45 2006 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 28 Feb 2006 08:22:45 +0330 Subject: [Pw_forum] I am receiving spams from this mailing list Message-ID: <002b01c63c22$d0b6e6c0$6e6910ac@mahmoudctpm> Dear Administrator of ESPRESSO Mailing, Kindly, it is for a few months that I am receiving from this mailing facility some messages containing viruses with subjects as: show, photo, .... I would be grateful if you please consider filtering such messages. With kindest regards, Mahmoud Payami ------------------------------------------------ Mahmoud Payami Associate Professor of Physics Center for Theoretical Physics and Mathematics Atomic Energy Organization of Iran P. O. Box 11365-8486 Tehran-Iran E-mail: mpayami at aeoi.org.ir Phone: +98 (0)21 82064393 Fax: +98 (0)21 8003796 Fax: +98 (0)21 8021412 ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060228/b2665d27/attachment.htm From akohlmey at vitae.cmm.upenn.edu Tue Feb 28 06:14:11 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Tue, 28 Feb 2006 00:14:11 -0500 (EST) Subject: [Pw_forum] I am receiving spams from this mailing list In-Reply-To: <002b01c63c22$d0b6e6c0$6e6910ac@mahmoudctpm> Message-ID: On Tue, 28 Feb 2006, Mahmoud Payami wrote: dear professor payami, kindly note, that i am not the administrator of the quantum espresso mailing list, but please consider the fact, that most spams and virusses nowadays send mails with fake sender addresses found in other people's mailboxes. so the spam/virusses may be originating from a fellow subscriber of the mailing list and not been routed through the mailing list itself. only a look at the full mail header section with the detailed mail routing information will tell you (or us) the difference. best regards, axel kohlmeyer. MP> Dear Administrator of ESPRESSO Mailing, MP> MP> Kindly, it is for a few months that I am receiving from this mailing facility some messages containing viruses with subjects as: show, photo, .... I would be grateful if you please consider filtering such messages. MP> With kindest regards, MP> Mahmoud Payami MP> MP> ------------------------------------------------ MP> Mahmoud Payami MP> Associate Professor of Physics MP> Center for Theoretical Physics and Mathematics MP> Atomic Energy Organization of Iran MP> P. O. Box 11365-8486 MP> Tehran-Iran MP> MP> E-mail: mpayami at aeoi.org.ir MP> Phone: +98 (0)21 82064393 MP> Fax: +98 (0)21 8003796 MP> Fax: +98 (0)21 8021412 MP> ----------------------------------------------------------- -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Tue Feb 28 10:00:32 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 28 Feb 2006 10:00:32 +0100 Subject: [Pw_forum] I am receiving spams from this mailing list In-Reply-To: <002b01c63c22$d0b6e6c0$6e6910ac@mahmoudctpm> References: <002b01c63c22$d0b6e6c0$6e6910ac@mahmoudctpm> Message-ID: <200602281000.32382.giannozz@nest.sns.it> On Tuesday 28 February 2006 05:52, Mahmoud Payami wrote: > Dear Administrator of ESPRESSO Mailing, > > Kindly, it is for a few months that I am receiving from this mailing > facility some messages containing viruses with subjects as: show, photo, > .... I would be grateful if you please consider filtering such messages. Hi Mahmoud all messages to pw_forum not coming from registered users are blocked. Today's log message says that yesterday 298 unauthorized messages were blocked. [ these, by the way, may also include legitimate e-mails not coming from the very same e-mail used for registration. Since all blocked messages are automatically deleted, don't wait for "moderator approval": there will be none ] The spam you receive is not coming via pw_forum, as explained by Axel, but most likely from viruses on other people's computers. Unfortunately there is little that can be done, as long as there are people using Windows and getting viruses all the time. If in the future we'll notice spam messages going through the mailing list, we'll take (or try to take) appropriate actions. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mpayami at aeoi.org.ir Tue Feb 28 11:54:47 2006 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 28 Feb 2006 14:24:47 +0330 Subject: [Pw_forum] I am receiving spams from this mailing list References: <002b01c63c22$d0b6e6c0$6e6910ac@mahmoudctpm> <200602281000.32382.giannozz@nest.sns.it> Message-ID: <000a01c63c55$64259870$6e6910ac@mahmoudctpm> Hi Paolo, Thank you very much for your reply. Actually, as suggested by Axel, I traced the route of the messages and found it is from iut-4a20081cc1d [ 217.219.18.117]. It is from Isfahan Univ. of Tech. I sent a meesage to their admin. Thank you again! mahmoud > Hi Mahmoud > > all messages to pw_forum not coming from registered users are blocked. > Today's log message says that yesterday 298 unauthorized messages > were blocked. [ these, by the way, may also include legitimate e-mails > not coming from the very same e-mail used for registration. Since all > blocked messages are automatically deleted, don't wait for "moderator > approval": there will be none ] > > The spam you receive is not coming via pw_forum, as explained > by Axel, but most likely from viruses on other people's computers. > Unfortunately there is little that can be done, as long as there are > people using Windows and getting viruses all the time. > > If in the future we'll notice spam messages going through the mailing > list, we'll take (or try to take) appropriate actions. > > Paolo > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > >