Re: [Wien] Reg: BerryPI calculation
ForwardedMessage.eml Subject: Re: [Wien] Reg: BerryPI calculation From: Oleg Rubel oru...@lakeheadu.ca Date: 10/13/2013 06:14 PM To: wien@zeus.theochem.tuwien.ac.at If you plan to displace one of the equivalent atoms (MULT 1), you need to split them. This can be done in W2WEB StructGen. The split option becomes available when you select a lattice type (not a space group). I enclosed an example of PbTiO3 (perovskite structure), where two oxygen atoms are equivalent. After splinting you better to call the new oxygen as O 3 in order to avoid problems. I hope this will help Oleg ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Increasing charge density for dense k-mesh.
Dear Prof. Blah and wien2k users, The values of charge density are increasing (diverging), if i am increasing the k-point mesh size. There are two cases i want to present here. *1. converged case.* In this case, I have taken a super cell of 2x2x1 made from a 225 space group which contains 64 number of atoms. The composition is Fe2VAl0.94Sn0.06 (Sn doped at Al-site of Fe2VAl alloy). For a 10 irreducible k-points (2x2x5), the calculations are converged by using a mixxer value of 0.1 (case.inM)and TEMP 0.001 instead of TETRA 0.000 for Brillouin zone sampling (case.2inc). But, after convergence, i want to calculate the transport properties of system using Boltztrap code and for that i need to have a dense k-mesh as suggested by the earlier reports. Hence, i increased the k-mesh size/ irreducible number of k-points to 41 (3x3x9). But, unfortunately, i have got an increase of charge density approximately 2 orders greater for the first cycle of run. Hence, i was waited to get the convergence and allowed to run the calculation further. But, till now i have not get any charge convergence and it is going to be diverge further as shown in below. = [venkatesh@phy Fe2VA94Sn06_SP_SCF]$ grep :DIS Fe2VA94Sn06_SP_SCF.scf :DIS : CHARGE DISTANCE ( 1.1613791 for atom 24 spin 1) 0.9921918 :DIS : CHARGE DISTANCE ( 0.9268038 for atom1 spin 1) 0.7520827 :DIS : CHARGE DISTANCE ( 1.4295105 for atom4 spin 1) 0.8726647 :DIS : CHARGE DISTANCE ( 1.3846340 for atom 17 spin 1) 0.9185441 :DIS : CHARGE DISTANCE ( 1.1669106 for atom 17 spin 2) 0.6507814 :DIS : CHARGE DISTANCE ( 1.0342075 for atom 26 spin 2) 0.8102410 :DIS : CHARGE DISTANCE ( 0.9953830 for atom 17 spin 2) 0.5721908 :DIS : CHARGE DISTANCE ( 1.1871654 for atom 26 spin 2) 0.5983795 :DIS : CHARGE DISTANCE ( 2.2407179 for atom 43 spin 1) 1.0599120 :DIS : CHARGE DISTANCE ( 0.9252437 for atom 10 spin 2) 0.4143075 :DIS : CHARGE DISTANCE ( 0.5971623 for atom3 spin 2) 0.3736421 :DIS : CHARGE DISTANCE ( 0.9657706 for atom3 spin 1) 0.4153846 :DIS : CHARGE DISTANCE ( 0.8263569 for atom 25 spin 2) 0.5691480 :DIS : CHARGE DISTANCE ( 0.9041626 for atom 18 spin 2) 0.3784629 :DIS : CHARGE DISTANCE ( 0.9330161 for atom 25 spin 2) 0.5479255 :DIS : CHARGE DISTANCE ( 0.4917141 for atom 21 spin 2) 0.3249724 :DIS : CHARGE DISTANCE ( 0.6104868 for atom 27 spin 1) 0.3005113 :DIS : CHARGE DISTANCE ( 0.5500539 for atom1 spin 2) 0.3123969 :DIS : CHARGE DISTANCE ( 0.5006123 for atom8 spin 1) 0.2811692 :DIS : CHARGE DISTANCE ( 0.4191734 for atom 28 spin 1) 0.2623780 :DIS : CHARGE DISTANCE ( 0.5076416 for atom 24 spin 1) 0.2240942 :DIS : CHARGE DISTANCE ( 0.3269785 for atom 17 spin 2) 0.1908877 :DIS : CHARGE DISTANCE ( 0.4312143 for atom 32 spin 1) 0.1813363 :DIS : CHARGE DISTANCE ( 0.2811455 for atom 23 spin 1) 0.1468832 :DIS : CHARGE DISTANCE ( 0.3070863 for atom6 spin 1) 0.1403603 :DIS : CHARGE DISTANCE ( 0.2073627 for atom 32 spin 2) 0.1157839 :DIS : CHARGE DISTANCE ( 0.2537000 for atom7 spin 1) 0.1134104 :DIS : CHARGE DISTANCE ( 0.2114046 for atom 32 spin 2) 0.1023255 :DIS : CHARGE DISTANCE ( 0.1765545 for atom 17 spin 2) 0.1027730 :DIS : CHARGE DISTANCE ( 0.2332213 for atom 27 spin 2) 0.1339720 :DIS : CHARGE DISTANCE ( 0.1359126 for atom 24 spin 2) 0.0621740 :DIS : CHARGE DISTANCE ( 0.0777887 for atom 17 spin 2) 0.0432868 :DIS : CHARGE DISTANCE ( 0.0628815 for atom6 spin 2) 0.0430123 :DIS : CHARGE DISTANCE ( 0.0549337 for atom6 spin 1) 0.0335315 :DIS : CHARGE DISTANCE ( 0.0842741 for atom 22 spin 2) 0.0448856 :DIS : CHARGE DISTANCE ( 0.0413700 for atom 32 spin 1) 0.0240587 :DIS : CHARGE DISTANCE ( 0.0516007 for atom 23 spin 2) 0.0226658 :DIS : CHARGE DISTANCE ( 0.0580145 for atom 23 spin 1) 0.0295119 :DIS : CHARGE DISTANCE ( 0.0227645 for atom 42 spin 2) 0.0127768 :DIS : CHARGE DISTANCE ( 0.0283147 for atom 17 spin 2) 0.0166658 :DIS : CHARGE DISTANCE ( 0.0172493 for atom 11 spin 2) 0.0103703 :DIS : CHARGE DISTANCE ( 0.0248151 for atom 20 spin 2) 0.0113135 :DIS : CHARGE DISTANCE ( 0.0213606 for atom1 spin 2) 0.0099210 :DIS : CHARGE DISTANCE ( 0.0232355 for atom2 spin 2) 0.0122684 :DIS : CHARGE DISTANCE ( 0.0211512 for atom6 spin 1) 0.0097885 :DIS : CHARGE DISTANCE ( 0.0140426 for atom 32 spin 2) 0.0064457 :DIS : CHARGE DISTANCE ( 0.0204967 for atom 32 spin 1) 0.0092715 :DIS : CHARGE DISTANCE ( 0.0074469 for atom 22 spin 2) 0.0034723 :DIS : CHARGE DISTANCE ( 0.0063875 for atom 20 spin 1) 0.0035126 :DIS : CHARGE DISTANCE ( 0.0063133
Re: [Wien] Error in *.vectorup and *.vectordn type files unformatted in SCF and Volume Optimization
On 10/11/2013 02:56 PM, Elias Assmann wrote: On 10/09/2013 06:03 PM, Gavin Abo wrote: I think the / in front of /CoFeMnSn.vectordn suggests that SCRATCH might have been set to the root directory were user permission problems can occur instead of the current directory ./ [http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-May/017013.html]. IIRC, that happens when SCRATCH is empty (or unset). If you want to “not use SCRATCH”, it is necessary to ‘set SCRATCH=.’. If you unset SCRATCH it is ok, but setting SCRATCH to empty causes this problem. It should not happen when one uses userconfig_lapw. Anyway, it will be fixed in the next release. -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] (no subject)
First guess: Is your struct file correct ??? Sb is a fairly big atom and usually has large distances to its neighbors. What is your RMT of Sb. If you are forced to use a small RMT for real reasons, lower the core-separation energy to -8.0 Ry. Still core leakage (must be terrible small spheres ???) When using .lcore, your error information is completely unspecific. Nobody can help, but I doubt very much that it has to do with core-leakage, but the problem might be too large basis set due to unphysically small spheres,. On 10/14/2013 06:57 AM, Lawal Mohammed wrote: Dear users and developers, I am a new user trying to initialize calculation for a (20 atoms) in unit cell (a sulfide material) with a Pnma (No.62) spacegroup. My problem is I got this warning. WARNING: 0.254 Sb CORE electrons leak out of MT-sphere I checked the WIEN2k.outputst for which atom/states the core-leakage occurs and rerun lstart with lower core-seperation energy. But still the warning appears, then I try to increase RMT, again the problem persist. And when I neglect the core-leakage error thinking that the .lcore will created and directs the scf-cycle to peform a superposition of core densities, as mentioned in UG. The SCF hangs-up (still hangs-up). Furthermore, I got this (Error in LAPW2) in the the case.output file. HELP PLEASE! Thanks in advance for your response. MOHAMMED Lawal Universiti Technologi Malaysia ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Increasing charge density for dense k-mesh.
*1. converged case.* In this case, I have taken a super cell of 2x2x1 made from a 225 space group which contains 64 number of atoms. The composition is Fe2VAl0.94Sn0.06 (Sn doped at Al-site of Fe2VAl alloy). For a 10 irreducible k-points (2x2x5), the calculations are converged by using a mixxer value of 0.1 (case.inM)and TEMP 0.001 instead of TETRA 0.000 for Brillouin zone sampling (case.2inc). But, after convergence, i want to calculate the transport properties of system using Boltztrap code and for that i need to have a dense k-mesh as suggested by the earlier reports. Hence, i increased the k-mesh size/ irreducible number of k-points to 41 (3x3x9). But, unfortunately, i have got an increase of charge density approximately 2 orders greater for the first cycle of run. Hence, i was waited to get the convergence and allowed to run the calculation further. But, till now i have not get any charge convergence and it is going to be diverge further as shown in below. I'm not sure if I interpret your listings correctly, since it should not look like this. After the first convergence (2x2x5) it seems the scf converged nicely. (if these are the many lines with :DIS : CHARGE DISTANCE ( 0.711 for atom 12 spin 2) 0.358 Then you should save it and continue with a better k-mesh. If your first :DIS is :DIS : CHARGE DISTANCE ( 0.0152057 for atom 44 spin 1) 0.0085165 this seems perfectly ok. It tells you, that the new k-mesh will lead to a (slightly) different density and most likely you have to continue to final scf convergence. It is not unusual that a metal needs a finer k-mesh for a good convergence. If your big :DIS :DIS : CHARGE DISTANCE ( 1.1613791 for atom 24 spin 1) 0.9921918 happens AFTER the first convergence, it tells you that you need a MUCH finer k-mesh. == *2. Non-converged case.* In this case, i am trying to run the calculations for the composition Fe2VAl0.25Sn0.75 (Sn doped at Al-site of Fe2VAl alloy) where Sn concentration is more now. In this case, i have used primitive cell made from 225 space group that contains 16 number of atoms. We run the scf calculations after volume as well as force minimized structures with 32 irreducible BZ k-points (4x4x4). To achieve the convergence, we tried several options as given below. 1. used mixxer values as 0.05 and 0.1, after saving previous calculation by save_lapw If you are using a recent WIEN2k version, you should NOT play with the mixing values, at least NOT for your example. Eventually increase TEMP 0.001 to 0.003 or 0.006 (magnetic ??) When changing k-mesh or TEMP value, save the previous calculation. (It removes broyden files) Systems with transition metals (Fe) can be difficult to converge and not always a very small :DIS can be obtained. Check also :ENE or :FGL In any case, if :DIS is so large (~1.0) starting from a converged calc., it means you need a much better k-mesh Note : Experimentally, i have also prepared these alloys, and got a segregation of pure Sn (extra phase) for higher compositions (Fe2VAl1-xSnx, x0.2). Hence, formation of pure L21 phase is not achieved in the experimental case for higher compositions, while L21 space group have been used for the calculation in the above case where x = 0.75. So, the divergence in the charge density for higher k-mesh size may conclude that it is not possible to get pure phase of L21 structure for this composition (Fe2VAl0.25Sn0.75). kindly, send me the comments on this observation. No, I don't think that this would be a valid conclusion, also a it might be a hint (large DOS at EF) -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] (no subject)
Thank you Sir, I have attached my struct file for you. For RMT I used 2.5 for Sb and 2.0 for S, but when I set automatically RMT and cont.. editing the RMT of the two different atoms become same, i.e. 1.43. Also as you have said I lower the core-separation energy to -8.0 Ry and -10.0 Ry, and I got the same leakage (0.074 for Sb and 0.021 for S). On Monday, October 14, 2013 3:19 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: First guess: Is your struct file correct ??? Sb is a fairly big atom and usually has large distances to its neighbors. What is your RMT of Sb. If you are forced to use a small RMT for real reasons, lower the core-separation energy to -8.0 Ry. Still core leakage (must be terrible small spheres ???) When using .lcore, your error information is completely unspecific. Nobody can help, but I doubt very much that it has to do with core-leakage, but the problem might be too large basis set due to unphysically small spheres,. On 10/14/2013 06:57 AM, Lawal Mohammed wrote: Dear users and developers, I am a new user trying to initialize calculation for a (20 atoms) in unit cell (a sulfide material) with a Pnma (No.62) spacegroup. My problem is I got this warning. WARNING: 0.254 Sb CORE electrons leak out of MT-sphere I checked the WIEN2k.outputst for which atom/states the core-leakage occurs and rerun lstart with lower core-seperation energy. But still the warning appears, then I try to increase RMT, again the problem persist. And when I neglect the core-leakage error thinking that the .lcore will created and directs the scf-cycle to peform a superposition of core densities, as mentioned in UG. The SCF hangs-up (still hangs-up). Furthermore, I got this (Error in LAPW2) in the the case.output file. HELP PLEASE! Thanks in advance for your response. MOHAMMED Lawal Universiti Technologi Malaysia ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html _root_WIEN2k_0021_0021.struct Description: Binary data ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] (no subject)
My guess: You have taken the lattice parameters in Ang and put it into the struct file, where they are supposed to be in bohr. All your spheres are nonphysically small. On 10/14/2013 11:14 AM, Lawal Mohammed wrote: Thank you Sir, I have attached my struct file for you. For RMT I used 2.5 for Sb and 2.0 for S, but when I set automatically RMT and cont.. editing the RMT of the two different atoms become same, i.e. 1.43. Also as you have said I lower the core-separation energy to -8.0 Ry and -10.0 Ry, and I got the same leakage (0.074 for Sb and 0.021 for S). On Monday, October 14, 2013 3:19 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: First guess: Is your struct file correct ??? Sb is a fairly big atom and usually has large distances to its neighbors. What is your RMT of Sb. If you are forced to use a small RMT for real reasons, lower the core-separation energy to -8.0 Ry. Still core leakage (must be terrible small spheres ???) When using .lcore, your error information is completely unspecific. Nobody can help, but I doubt very much that it has to do with core-leakage, but the problem might be too large basis set due to unphysically small spheres,. On 10/14/2013 06:57 AM, Lawal Mohammed wrote: Dear users and developers, I am a new user trying to initialize calculation for a (20 atoms) in unit cell (a sulfide material) with a Pnma (No.62) spacegroup. My problem is I got this warning. WARNING: 0.254 Sb CORE electrons leak out of MT-sphere I checked the WIEN2k.outputst for which atom/states the core-leakage occurs and rerun lstart with lower core-seperation energy. But still the warning appears, then I try to increase RMT, again the problem persist. And when I neglect the core-leakage error thinking that the .lcore will created and directs the scf-cycle to peform a superposition of core densities, as mentioned in UG. The SCF hangs-up (still hangs-up). Furthermore, I got this (Error in LAPW2) in the the case.output file. HELP PLEASE! Thanks in advance for your response. MOHAMMED Lawal Universiti Technologi Malaysia ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Possible bugs from use of uninitialized variables
I was travelling so did not have access to the source. You are correct and it is technically a bug which apparently neither -ftrapuv nor gfortran picked up. I have added ROKMIX = 0.D0 ; ROKSC = 0.D0 ; ROKVL = 0.D0 ; ROKOLD = 0.D0 KVECVL = 0 ; KVECSC = 0 ; KVCOLD = 0 after the allocation, and at some stage will add comparable to other allocations. That said, it should have no effect on the performance of mixer, and if it does then there is a serious bug somewhere else. The test on line 1504 of your version is just for some output of how the PW's are changing for monitoring as Peter has noticed that converging these can sometimes be tricky. There are a few other similar traps just for cleaning things up. Can you please send the lines for LimitDMIX8n.F in your version since it is probably different from mine and I do not see anything relevant at line 135. N.B., concerning valgrind and mixer (for instance) not deallocating everything. There is a routine called cleaner.f which is in SRC_mixer for this purpose. However, with a multiply branching code it is very, very, very hard to trap everything and I have ended up hoping that the compiler does what it is supposed to. It is also very hard to protect for all possible systems and compilers particularly if I have no access to them. And.mpi is much worse. On Thu, Oct 10, 2013 at 10:47 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Čt 10. 10. 2013 v 09:40 -0500: Sorry, but I agree with Peter I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; That is not true. According to ifort docs: -ftrapuv The option sets any uninitialized local variables that are allocated on the _stack_ to a value that is typically interpreted as a very large integer or an invalid address. However the ROKMIX is allocated on the _heap_ Just try the test I've described earlier, set the imaginary part by hand right after allocation and check the value right before the if check either with debugger or just write it to stdout and you will see the value doesn't change. the arrays are not set in mixer.F but elsewhere within some complicated subroutines. This flag forces a fault if an undefined variable is used. --- 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 On Oct 10, 2013 7:23 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200: I'm not very familiar with valgrid, but all those reports seem not relevant to me. It seems to complain about all allocated arrays, which are not set to zero globally. But this does NOT mean that one uses uninitialized variables or assumes that the compiler sets them to zero. Valgrind doesn't complain about uninitialized variables in general. Just when they are used in such way that they can alter the flow of the program or generally alter the externally-visible behavior. I'll take the problem from mixer as an example, because contrary to the rest of the problems, here I'm 99% sure it is a real bug. The complex array ROKMIX in mixer.F, is only partially initialized. The real part of the complex number is initialized somewhere (don't know exactly where, since I haven't tracked it that much), however the imaginary part is not. You can check this by setting the imaginary part to some specific value right after the allocation, and then set a breakpoint or print its value at line mixer.F:1504 if(abs(ROKMIX(J,I)).gt.1D-12)then and you will see, it has the same value as set before, so it wasn't written anywhere. And now basically if real part of ROKMIX(J,I) is lower than 1D-12 we would randomly fail or pass the if test, depending on what stuff is written in the corresponding uninitialized memory. PS: I don't have a variable WS in dergl.f WS=0.0D0 in dergl.f My mistake, this should have been RW We can verify this also with ifort by setting -C in the flags, and in fact doing so would result in an error in f7splt due to the mistake you mentioned before. So the only problem was in f7splt.f and that should be fixed as previously mentioned. Well, this is not what valgrind does. Valgrind doesn't do static code analysis as compilers do during compilation, but it
Re: [Wien] Insufficient virtual memory - LAPW2
= Dear Prof. Blaha, Thank you for your answer, actually, there are no unlimited restriction on the machines. I tested a sample case on multiple (a, b and c) machines which have the same installation of WIEN2K-12 (OS and software), they just differ in CPU, RAM and Diskspeed. The SCF was converged successfully in machine c but it was crashed in the first and third iteration of a and b machines respectively, because of insufficient virtual memory. Convergence successfully in one machine shows the input files are all right and there is no error in the binaries/rights. So, I was wondering why it works in one machine and not in the other. Best regards, Salman = a) 2 Socket, Dual Core AMD Opteron(tm) Processor 270, 8GB RAM b) 2 Socket, (8Core) AMD Opteron(tm) Processor 6320, 64GB RAM c) 2 Socket, (8Core(*2=HT)) Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, 256GB RAM $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 515879 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 515879 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited = on machines (a) and (b) failed (a) failed in the first iteration (b) failed in the third iteration the error message was: forrtl: severe (41): insufficient virtual memory Image PCRoutineLineSource lapw2 0053B8FA Unknown Unknown Unknown lapw2 0053A475 Unknown Unknown Unknown lapw2 004E0646 Unknown Unknown Unknown lapw2 0049D2F6 Unknown Unknown Unknown lapw2 004C69F6 Unknown Unknown Unknown lapw2 0044A6EC fourir_ 112 fourir_tmp_.F lapw2 00475AD5 MAIN__595 lapw2_tmp_.F lapw2 00403FAC Unknown Unknown Unknown libc.so.6 2AB7F8770EAD Unknown Unknown Unknown lapw2 00403EA9 Unknown Unknown Unknown stop error Message: 16 Date: Tue, 08 Oct 2013 20:12:03 +0200 From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Insufficient virtual memory - LAPW2 Message-ID: 52544af3.6020...@theochem.tuwien.ac.at Content-Type: text/plain; charset=ISO-8859-1; format=flowed Eventually your sysadmin (or a special Linux version) has restricted some resources for the users. Use limit or ulimit commands to find out/set these values or ask your sys-admin. Am 08.10.2013 18:54, schrieb Salman Zarrini: == Dear Wien2k user, Wien2k-12 is running in our machines which have enough memory as it is clear below, however, all the jobs (even a very small one)are crashed in LAPW2 either in k-point parallel or nonparallel mode thanks to insufficient virtual memory. So, any helpful comments would be appreciated in advance. Regards, Salman == forrtl: severe (41): insufficient virtual memory Image PCRoutineLineSource lapw2 0053B8FA Unknown Unknown Unknown lapw2 0053A475 Unknown Unknown Unknown lapw2 004E0646 Unknown Unknown Unknown lapw2 0049D2F6 Unknown Unknown Unknown lapw2 004C69F6 Unknown ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671 -- Message: 17 Date: Tue, 08 Oct 2013 20:12:42 +0200 From: Peter Blaha pbl...@theochem.tuwien.ac.at To: A Mailing list for WIEN2k users
Re: [Wien] Possible bugs from use of uninitialized variables
Laurence Marks píše v Po 14. 10. 2013 v 08:46 -0500: I was travelling so did not have access to the source. You are correct and it is technically a bug which apparently neither -ftrapuv nor gfortran picked up. I have added ROKMIX = 0.D0 ; ROKSC = 0.D0 ; ROKVL = 0.D0 ; ROKOLD = 0.D0 This is probably just a typo on your side, however ROKMIX = 0.D0 will initialize just the real part... ROKMIX = (0.D0, 0.D0) is needed (at lest on gfortran and xlf90) KVECVL = 0 ; KVECSC = 0 ; KVCOLD = 0 after the allocation, and at some stage will add comparable to other allocations. That said, it should have no effect on the performance of mixer, and if it does then there is a serious bug somewhere else. The test on line 1504 of your version is just for some output of how the PW's are changing for monitoring as Peter has noticed that converging these can sometimes be tricky. There are a few other similar traps just for cleaning things up. I didn't saw any actual problems except the crash in f7splt, I was just being extra cautious, since I imagine the AIX 5.3 build doesn't see much testing. Can you please send the lines for LimitDMIX8n.F in your version since it is probably different from mine and I do not see anything relevant at line 135. LimitDMIX8n.F:135PM1=min(1.D0,PM1) attached is the stock LimitDMIX8n.F from WIEN2k_13.1 version N.B., concerning valgrind and mixer (for instance) not deallocating everything. There is a routine called cleaner.f which is in SRC_mixer for this purpose. However, with a multiply branching code it is very, very, very hard to trap everything and I have ended up hoping that the compiler does what it is supposed to. It is also very hard to protect for all possible systems and compilers particularly if I have no access to them. And.mpi is much worse. It wasn't actually leaking that much at all, just the small leak in lapw1 (not counting the allocated memory still accessible on exit) Basically even though my platform of interest is AIX 5.3, the testing with valgrind was done on linux with gfortran, because valgrind isn't working on AIX. As I've said before, my main motivation for this vagrind exercise was just that I was really concerned that clearly invalid code wasn't crashing at all neither with ifort (because it is initialized to 0 defaultly) nor with gfortran (it was probably optimized away, because with -O0 it crash in the same way) and I was wondering if there are more similar cases that are not severe enough to result in crash but rather some unwanted behavior. Also all the testing was done just with the TiC sample, so I probably haven't tested that many codepaths at all... Anyway thanks for looking into this and let me know if you need any more info. On Thu, Oct 10, 2013 at 10:47 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Čt 10. 10. 2013 v 09:40 -0500: Sorry, but I agree with Peter I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; That is not true. According to ifort docs: -ftrapuv The option sets any uninitialized local variables that are allocated on the _stack_ to a value that is typically interpreted as a very large integer or an invalid address. However the ROKMIX is allocated on the _heap_ Just try the test I've described earlier, set the imaginary part by hand right after allocation and check the value right before the if check either with debugger or just write it to stdout and you will see the value doesn't change. the arrays are not set in mixer.F but elsewhere within some complicated subroutines. This flag forces a fault if an undefined variable is used. --- 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 On Oct 10, 2013 7:23 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200: I'm not very familiar with valgrid, but all those reports seem not relevant to me. It seems to complain about all allocated arrays, which are not set to zero globally. But this does NOT mean that one uses uninitialized variables or assumes that the compiler sets them to zero. Valgrind doesn't complain about uninitialized variables in general. Just when they are used in such way that they can alter the flow of the program or generally alter the externally-visible behavior. I'll take the problem from mixer as an example, because contrary to the rest of the problems, here I'm 99% sure it is a real bug. The complex array
Re: [Wien] Possible bugs from use of uninitialized variables
Thanks. The line PM1=min(1.D0,PM1) should be commented out, it is a legacy of when I moved some code around and does nothing. N.B., A=0.D0 is the same as A=(0.D0,0.D0) -- there is an implicit conversion at least for ifort and gfortran (and I believe always), e.g. test complex a a=(0.d0,1.d0) write(6,*)a a=0.D0 write(6,*)a end On Mon, Oct 14, 2013 at 10:43 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Po 14. 10. 2013 v 08:46 -0500: I was travelling so did not have access to the source. You are correct and it is technically a bug which apparently neither -ftrapuv nor gfortran picked up. I have added ROKMIX = 0.D0 ; ROKSC = 0.D0 ; ROKVL = 0.D0 ; ROKOLD = 0.D0 This is probably just a typo on your side, however ROKMIX = 0.D0 will initialize just the real part... ROKMIX = (0.D0, 0.D0) is needed (at lest on gfortran and xlf90) KVECVL = 0 ; KVECSC = 0 ; KVCOLD = 0 after the allocation, and at some stage will add comparable to other allocations. That said, it should have no effect on the performance of mixer, and if it does then there is a serious bug somewhere else. The test on line 1504 of your version is just for some output of how the PW's are changing for monitoring as Peter has noticed that converging these can sometimes be tricky. There are a few other similar traps just for cleaning things up. I didn't saw any actual problems except the crash in f7splt, I was just being extra cautious, since I imagine the AIX 5.3 build doesn't see much testing. Can you please send the lines for LimitDMIX8n.F in your version since it is probably different from mine and I do not see anything relevant at line 135. LimitDMIX8n.F:135PM1=min(1.D0,PM1) attached is the stock LimitDMIX8n.F from WIEN2k_13.1 version N.B., concerning valgrind and mixer (for instance) not deallocating everything. There is a routine called cleaner.f which is in SRC_mixer for this purpose. However, with a multiply branching code it is very, very, very hard to trap everything and I have ended up hoping that the compiler does what it is supposed to. It is also very hard to protect for all possible systems and compilers particularly if I have no access to them. And.mpi is much worse. It wasn't actually leaking that much at all, just the small leak in lapw1 (not counting the allocated memory still accessible on exit) Basically even though my platform of interest is AIX 5.3, the testing with valgrind was done on linux with gfortran, because valgrind isn't working on AIX. As I've said before, my main motivation for this vagrind exercise was just that I was really concerned that clearly invalid code wasn't crashing at all neither with ifort (because it is initialized to 0 defaultly) nor with gfortran (it was probably optimized away, because with -O0 it crash in the same way) and I was wondering if there are more similar cases that are not severe enough to result in crash but rather some unwanted behavior. Also all the testing was done just with the TiC sample, so I probably haven't tested that many codepaths at all... Anyway thanks for looking into this and let me know if you need any more info. On Thu, Oct 10, 2013 at 10:47 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Čt 10. 10. 2013 v 09:40 -0500: Sorry, but I agree with Peter I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; That is not true. According to ifort docs: -ftrapuv The option sets any uninitialized local variables that are allocated on the _stack_ to a value that is typically interpreted as a very large integer or an invalid address. However the ROKMIX is allocated on the _heap_ Just try the test I've described earlier, set the imaginary part by hand right after allocation and check the value right before the if check either with debugger or just write it to stdout and you will see the value doesn't change. the arrays are not set in mixer.F but elsewhere within some complicated subroutines. This flag forces a fault if an undefined variable is used. --- 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 On Oct 10, 2013 7:23 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200: I'm not very familiar with valgrid, but all those reports seem not relevant to me. It seems to complain about all allocated arrays, which are not set to zero globally. But this does NOT mean that one uses uninitialized variables or
[Wien] :RTO not present in case.scf (WIEN2k 13.1)
Hello WIEN2k Users: I am using WIEN2k 13.1 to calculate hyperfine parameters in semiconductors samples and I use the related values outputs: :EFG :ETA :HFF :RTO I recently updated to the last WIEN2k version (13.1) and the parameter :RTO is not present in the case.scf file after a complete SCF calculation. Did that parameter name change? I should set other options to get that parameter value? I checked the UserGuide and it is still mentioned in the section 4.4 The history file case.scf. :RTOxxDensity for atom xx at the nucleus (first radial mesh point) So, it is strange that is not present in the case.scf file. Any comment or answer is really appreciated. Best regards. Yamiel. -- div == /div div M.Sc. Yamiel Abreu Alfonso /div div == /div div Lab. de Daño por Irradiación. Departamento de Física. /div div Centro de Aplicaciones Tecnológicas y Desarrollo Nuclear (CEADEN). /div div Calle 30 #502 esq. 5ta Ave. Miramar, Playa, C. Habana, Cuba. CP 11300. /div div P.O.Box: 6122. Tel/Fax: (+53)(7) 202 1518. /div div == /div div /div div e-mail: yab...@ceaden.edu.cu /div div Tel: (+53)(7) 206 6109. /div div /div ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] :RTO not present in case.scf (WIEN2k 13.1)
If SRC_mixer/mixer.F of Wien2k 13.1 is opened in a text editor, it looks like :RTO is printed by line 795. Line 792 seems new: if(.not.useatoms)then This if statement looks like it might not allow printing of :RTO for certain mixing algorithms: MSRxa, where x = 1 or 2 MSECa MSECb :RTO is likely printed for any of the other algorithms (described in the UG or SRC_mixer/README_6.0.pdf) set in case.inm. On 10/14/2013 2:35 PM, Yamiel Abreu Alfonso wrote: Hello WIEN2k Users: I am using WIEN2k 13.1 to calculate hyperfine parameters in semiconductors samples and I use the related values outputs: :EFG :ETA :HFF :RTO I recently updated to the last WIEN2k version (13.1) and the parameter :RTO is not present in the case.scf file after a complete SCF calculation. Did that parameter name change? I should set other options to get that parameter value? I checked the UserGuide and it is still mentioned in the section 4.4 The history file case.scf. :RTOxxDensity for atom xx at the nucleus (first radial mesh point) So, it is strange that is not present in the case.scf file. Any comment or answer is really appreciated. Best regards. Yamiel. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] :RTO not present in case.scf (WIEN2k 13.1)
The line is new -- it did not seem sensible (to me) to calculate :RTO when atom positions are changing, only when converging a density. (I was trying to minimize output a little.) This can be changed (i.e. comment out the if statement and corresponding endif) if people want it. On Mon, Oct 14, 2013 at 7:03 PM, Gavin Abo gs...@crimson.ua.edu wrote: If SRC_mixer/mixer.F of Wien2k 13.1 is opened in a text editor, it looks like :RTO is printed by line 795. Line 792 seems new: if(.not.useatoms)then This if statement looks like it might not allow printing of :RTO for certain mixing algorithms: MSRxa, where x = 1 or 2 MSECa MSECb :RTO is likely printed for any of the other algorithms (described in the UG or SRC_mixer/README_6.0.pdf) set in case.inm. On 10/14/2013 2:35 PM, Yamiel Abreu Alfonso wrote: Hello WIEN2k Users: I am using WIEN2k 13.1 to calculate hyperfine parameters in semiconductors samples and I use the related values outputs: :EFG :ETA :HFF :RTO I recently updated to the last WIEN2k version (13.1) and the parameter :RTO is not present in the case.scf file after a complete SCF calculation. Did that parameter name change? I should set other options to get that parameter value? I checked the UserGuide and it is still mentioned in the section 4.4 The “history“ file case.scf. :RTOxx Density for atom xx at the nucleus (first radial mesh point) So, it is strange that is not present in the case.scf file. Any comment or answer is really appreciated. Best regards. Yamiel. -- 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 ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Reg: BerryPI calculation
Dear wine2k users and developers, Thank you Prof. Sheikh Jamil Ahmed sir, and Prof. Peter Blaha sir, these explanations are so helpful for me. I can able to split the atoms now by selecting the lattice type. In the w2web page i have selected the lattice type as B, it enable the split option then i splitted the A atom and saved the structure, after that it gave some error like incorrect space group symbol, but still i proceeded by setting automatically RMT and continue editing. After that it saved. Similarly i spillted for other elements and all the elements are splitted fine now without any error and the final structure is saved in case.struct_i. Am I going correct? Is the correct way ? can i omit the error incorrect spacegroup symbol . Sir, I am unable to find the PbTiO3 example file in your mail. Thanking you On Mon, Oct 14, 2013 at 12:27 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: ForwardedMessage.eml Subject: Re: [Wien] Reg: BerryPI calculation From: Oleg Rubel oru...@lakeheadu.ca Date: 10/13/2013 06:14 PM To: w...@zeus.theochem.tuwien.ac.**at wien@zeus.theochem.tuwien.ac.at If you plan to displace one of the equivalent atoms (MULT 1), you need to split them. This can be done in W2WEB StructGen. The split option becomes available when you select a lattice type (not a space group). I enclosed an example of PbTiO3 (perovskite structure), where two oxygen atoms are equivalent. After splinting you better to call the new oxygen as O 3 in order to avoid problems. I hope this will help Oleg __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
