[Wien] problem
-- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121201/062c86ed/attachment.htm
[Wien] Error in LAPW0
Dear users, can everybody will tell me the reason and how to remove the below error Error in LAPW0 'LAPW0' - IORD .EQ. 0 thanking you ajay -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121201/85095951/attachment.htm
[Wien] Error in LAPW0
It means that there is a problem with the case.struct file. It could not read the NUMBER OF SYMMETRY OPERATIONS. On 12/1/2012 12:45 AM, AJAY SINGH VERMA wrote: Dear users, can everybody will tell me the reason and how to remove the below error Error in LAPW0 'LAPW0' - IORD .EQ. 0 thanking you ajay ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121201/79963b80/attachment.htm
[Wien] problem
You cannot simply IGNORE warnings and errors during init_lapw. Whenever an error occurs, it is quite natural that following steps (like run_lapw) will not work. The first WARNINGS after nn means, that your atoms had wrong equivalency and were automatically regrouped. While this has been fixed automatically, apparently your case.inst file is now wrong (it should not exist at this moment, but somehow (previous steps ???) you have it. rm case.inst Also the message of sgroup needs an investigation ! For man-made structures (which are not simple crystals or imported from cif files,...) I recommend to run manually x nn ! and if there is an error, cp case.struct_nn case.struct x nn ! repeat these two steps until there is no error left. Notice the number of non-equivalent atoms! x sgroup ! check the outputsgroup file. Most likely you should accept case.struct_sgroup, ! unless you know what you are doing (i.e. want to run in a non-standard setting) x symmetry ! check case.outputs: are the number of sym.ops identically to thos from sgroup ? any error popped up because of MULTIPLICITY wrong ??? Once these 3 steps passed, you can initialize also in batch mode init_lapw -b -.. Am 01.12.2012 06:21, schrieb AJAY SINGH VERMA: can any body tell me what is the reason of the below error , i am working in a parallel environment it doesn't occurs in serial. Start for AUTO intialization Styp6__2.0 ## 8 Atoms found: Cu Cu Tl Tl Se Se Se Se generate atomic configuration for atom Cu generate atomic configuration for atom Cu generate atomic configuration for atom Tl generate atomic configuration for atom Tl generate atomic configuration for atom Se generate atomic configuration for atom Se generate atomic configuration for atom Se generate atomic configuration for atom Se next is setrmt specify nn-bondlength factor: (usually=2) [and optionally dlimit (about 1.d-5)] DSTMAX: 20.0 iix,iiy,iiz 2 2 2 ATOM 1 Cu ATOM 8 Se RMT( 1)=2.2 AND RMT( 8)=2.0 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 2 Cu ATOM 5 Se RMT( 2)=2.2 AND RMT( 5)=2.0 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 3 Tl ATOM 8 Se RMT( 3)=2.3 AND RMT( 8)=2.0 SUMS TO 4.3 LT. NN-DIST= 4.90264 ATOM 4 Tl ATOM 5 Se RMT( 4)=2.3 AND RMT( 5)=2.0 SUMS TO 4.3 LT. NN-DIST= 4.90264 ATOM 5 Se ATOM 2 Cu RMT( 5)=2.0 AND RMT( 2)=2.2 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 6 Se ATOM 1 Cu RMT( 6)=2.0 AND RMT( 1)=2.2 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 7 Se ATOM 2 Cu RMT( 7)=2.0 AND RMT( 2)=2.2 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 8 Se ATOM 1 Cu RMT( 8)=2.0 AND RMT( 1)=2.2 SUMS TO 4.2 LT. NN-DIST= 4.73540 WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file WARNING: Mult not equal. PLEASE CHECK outputnn-file WARNING: ityp not equal. PLEASE CHECK outputnn-file NN created a new cutlse2.struct_nn file 0.002u 0.002s 0:01.48 0.0% 0+0k 0+0io 0pf+0w Original struct file is saved to cutlse2.struct_init specify nn-bondlength factor: (usually=2) [and optionally dlimit (about 1.d-5)] DSTMAX: 20.0 iix,iiy,iiz 2 2 2 NAMED ATOM: Cu1 Z changed to IATNR+999 to determine equivalency NAMED ATOM: Tl2 Z changed to IATNR+999 to determine equivalency NAMED ATOM: Se3 Z changed to IATNR+999 to determine equivalency ATOM 1 Cu1ATOM 3 Se3 RMT( 1)=2.2 AND RMT( 3)=2.0 SUMS TO 4.2 LT. NN-DIST= 4.73540 ATOM 2 Tl2ATOM 3 Se3 RMT( 2)=2.3 AND RMT( 3)=2.0 SUMS TO 4.3 LT. NN-DIST= 4.90264 ATOM 3 Se3ATOM 1 Cu1 RMT( 3)=2.0 AND RMT( 1)=2.2 SUMS TO 4.2 LT. NN-DIST= 4.73540 0.000u 0.007s
[Wien] zfft3d.F
In an official WIEN2k installation (unsing siteconfig) Makefile is not used, but we use Makefile.orig. This does not use zfft3.o anymore. PS: The fftw4 interface was done by some student. Unfortunately it introduced severe problems, which I could not even solve so far for all possible combinations of fftpack/fftw2/fftw2 and sequential/parallel (at least not with the latest ifort compiler). I need a couple of silent hours to fix this, but its hard to find ... Am 01.12.2012 01:43, schrieb Laurence Marks: Individual, downloaded (to check) ~20 mins ago. Do you know who wrote the ffftw2/3 interface, it does not look like Peter's style. It has some entertaining matrix transformations which are avoidable by changing the N1,N2,N3 order to N3,N2,N1. On Nov 30, 2012 6:21 PM, Gavin Abo gsabo at crimson.ua.edu mailto:gsabo at crimson.ua.edu wrote: Full or individual package? Wien2k version? My previous response assumed full 12.1. On 11/30/2012 5:09 PM, Laurence Marks wrote: To correct my earlier response, the current web version does have zfft3.o in the Makefile, and I believe zfft3.F should be removed. (I don't want to predict which version a fortran compiler will pick from zfft3.f and zfft3.F.) Peter, can you please confirm? -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu http://www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at mailto:Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] Tr : inst-correct
case.inst looks ok, provided your AFM structure is such that 1st and 3rd atom are up, and 2nd,4th are dn k-points: testing Am 01.12.2012 00:22, schrieb Mourad Karima: Dear All I'm studing a 8 atoms supercell of Antiferromgnetic ,all oxygen is nonmagnetic kgen in ferromagnetic is 1200 (47 point ) for antiferromgnetic, How many points needed taken case.inst Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N END of input (instgen_lapw) I changed by Is this correct case.inst Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,0.0 N 4, 3,1.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,0.0 N 5, 2,1.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,1.0 N 4, 3,0.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N Ce Xe 4 4, 3,0.0 N 4, 3,1.0 N 4,-4,0.0 N 4,-4,0.0 N 5, 2,0.0 N 5, 2,1.0 N 6,-1,1.0 N 6,-1,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N O He 3 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N END of input (instgen_lapw) ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] zfft3d.F
Thanks. There might be a minor bug in line 311-2 of fft_modules.F which are call fftw3d_f77_mpi_create_plan(backward_plan, MPI_COMM_WORLD, N1, N2, N3, FFTW_FORWARD, FFTW_ESTIMATE) FFTW_BACKWARD here is consistent with the earlier versions. The difference is small, in the last two digits of the PW's in case.vns. There is a similar inconsistency in lapw2 although I do not see any difference in the result. On Sat, Dec 1, 2012 at 3:18 AM, Peter Blaha pblaha at theochem.tuwien.ac.atwrote: In an official WIEN2k installation (unsing siteconfig) Makefile is not used, but we use Makefile.orig. This does not use zfft3.o anymore. PS: The fftw4 interface was done by some student. Unfortunately it introduced severe problems, which I could not even solve so far for all possible combinations of fftpack/fftw2/fftw2 and sequential/parallel (at least not with the latest ifort compiler). I need a couple of silent hours to fix this, but its hard to find ... Am 01.12.2012 01:43, schrieb Laurence Marks: Individual, downloaded (to check) ~20 mins ago. Do you know who wrote the ffftw2/3 interface, it does not look like Peter's style. It has some entertaining matrix transformations which are avoidable by changing the N1,N2,N3 order to N3,N2,N1. On Nov 30, 2012 6:21 PM, Gavin Abo gsabo at crimson.ua.edu mailto: gsabo at crimson.ua.edu wrote: Full or individual package? Wien2k version? My previous response assumed full 12.1. On 11/30/2012 5:09 PM, Laurence Marks wrote: To correct my earlier response, the current web version does have zfft3.o in the Makefile, and I believe zfft3.F should be removed. (I don't want to predict which version a fortran compiler will pick from zfft3.f and zfft3.F.) Peter, can you please confirm? -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu http://www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at mailto: Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121201/893a271b/attachment.htm
[Wien] Possible error in LAPW2 code
Hello WIEN2k users, I am using WIEN2k version 11.1. In L2MAIN.F line 747 reads: IF(myid_vec*ibpp*iblock+i-1.GT.n-(nlo+nlon+nlov)) EXIT If I understand what this part of the code is doing properly, I think it should be a .GE. condition rather than a .GT. condition. To explain my line of thinking: I have been reading through the LAPW2 code to help me understand how the (L)APW+LO+lo basis is generated. I was looking at the rotated G + k vectors (in L2MAIN.F the BK, BKROT, BKRLOC vectors), and modified the code for L2MAIN.F slightly to print each vector to the screen after it was rotated by the appropriate matrix (ROTIJ, BR1, ROTLOC). However because of the above .GT. condition there are n - (nlo+nlon+nlov) + 1 vectors generated. (In serial mode, at least, when myid_vec = 0.) This is a problem, I think, because in READ_VEC.F there are only n - (nlo+nlon+nlov) vectors defined. In my test case (fcc MgO, run in serial mode) the gamma point had the most vectors (126 G-vectors in case.vector total, 13 of them are LOs) and L2MAIN went through the i=ii,ii+iblock-1 loop (line 746) 114 times, and the last vector used had some enormous and random-looking components. I do not think the relevant arrays (the KX(), KY(), KZ() arrays) are ever fully initialized (to zero, at least), so it makes sense to me that if only 113 G+k values are determined in READ_VEC.F that the 114th should be gibberish. I did change the condition in L2MAIN.F at line 747 to a .GE., recompiled, and ran an SCF cycle on my test case again, the change was very small (one part in a thousand or smaller). If the .GT. is not an error, then I clearly do not understand something about how these G + k vectors are determined. Regards, John --- To illustrate what I mean, I added this code just after line 752 in L2MAIN.F write(*,*) 'atom',jatom,'site',mu,'kpt',kkk,'vec',i write(*,*) (bk(itmp),itmp=1,3) The last three bk vectors for the gamma point were: atom 1 site 1 kpt 1 vec 112 4.00 0.000E+000 2.00 atom 1 site 1 kpt 1 vec 113 0.000E+000 4.002.00 atom 1 site 1 kpt 1 vec 114 0.000E+000 807411763.00 0.000E+000 I think the vector 114 should not be present, and should not have a ky-component of eight hundred million.
