[Wien] Error during mBJ calculation
Dear users and developers, I am using mBJ calculation for NiCo2O4 with a mixed spinel and inverse spinel structure. The calculation is running fine for more than 20 cycles ( i have tried twice) and the stops with the lapw0 error Error in LAPW0 'LAPW0' - case.grr file not present, which is requred for mBJ The case.grr file actually is present but without any values but a line of asterics! I tried manually creating .grr file by inputting the grr28 value from the previous cycle. But when i run scf the line of asterics reappears and the program stops. lapw0 runs fine when i type the command 'x lapw0' without running 'lapw0 -grr'. I think 'lapw0 -grr' is writing the line of asterics corrupting the .grr file which lapw0 cannot read. If anyone knows a solution kindly help. - Dileep Krishnan c/o Dr. Ranjan Datta JNCASR, Jakkur Bangalore, India. ___ 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] Error during mBJ calculation
Hi, The value in case.grr is the average of (grad rho)/rho in the unit cell. Apparently some nonsense large value is obtained. Using a smaller mixing factor in case.inm (e.g., 0.05) may help. F. Tran On Thu, 10 Oct 2013, Dileep Krishnan wrote: Dear users and developers, I am using mBJ calculation for NiCo2O4 with a mixed spinel and inverse spinel structure. The calculation is running fine for more than 20 cycles ( i have tried twice) and the stops with the lapw0 error Error in LAPW0 'LAPW0' - case.grr file not present, which is requred for mBJ The case.grr file actually is present but without any values but a line of asterics! I tried manually creating .grr file by inputting the grr28 value from the previous cycle. But when i run scf the line of asterics reappears and the program stops. lapw0 runs fine when i type the command 'x lapw0' without running 'lapw0 -grr'. I think 'lapw0 -grr' is writing the line of asterics corrupting the .grr file which lapw0 cannot read. If anyone knows a solution kindly help. - Dileep Krishnan c/o Dr. Ranjan Datta JNCASR, Jakkur Bangalore, India. ___ 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 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] DOS for FSM calc - problem
Two remarks to the problems reported below: a) After a runfsm calculation, you do NOT have valid case.vectorup/dn files (only dn), so you cannot calculate QTLs directly, but need to recalculate x lapw1 -up b) Of course, in many cases a FSM calculation will give you the desired moment ONLY by introducing 2 different FERMI energies !. This is not considered when you calculate the QTLs and thus the automatic EF-settings in tetra will not be correct! I have a trouble to calculate the DOS for FSM calculation. I have converged FSM=6.0\mu_B for GGA(PBE) of Co2FeSi using Wien2k 12.1. At the end I checked grep :MMTOT and had a 6\mu_B/unit cell. However, where I make a plot according to UG about FSM I am getting a DOS that is similar to that of pure GGA (i.e. M=5.56\mu_B). Difference of integr. of up and down channels gives me 5.56 like in GGA. Where I could make a step aside? Can someone help to identify it? I am attaching a converged calculation, with *.int and outputting *.dos1ev*. Thanks, Best regards, Dominik Legut - Dominik Legut, tel. +420-597 329 122 Nanotechnology Centre and IT4Innovations VSB University of Technology Ostrava 17 listopadu 15 CZ-70833 Ostrava Czech Republic - -- 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
[Wien] Fromat of positions of Species in Structure File
Respected Community Members, I would be thankful if someone confirms the Format of the position of the atoms. We generated the structure file for a spinel compound ZnAl2O4 by selecting the space group No Fd-3m #227, chosing cubic lattice constant and angles, Selecting positions Zn(0.125,0.125,0.125), Al (0.5,0.5,0.5), O (0.2534,0.2534,0.2534). In return we got the Positions for 14 atoms in the primitive unit cell as mentioned below. Kindly confirm what is the formatt of input positions Zn(0.125,0.125,0.125), Al (0.5,0.5,0.5), O (0.2534,0.2534,0.2534) and other generated positions in the Structure file. Zn 1: X=0.1250 Y=0.1250 Z=0.1250 2: X=0.8750 Y=0.8750 Z=0.8750 Al 1: X=0.5000 Y=0.5000 Z=0.5000 3: X=0.5000 Y=0.7500 Z=0.7500 3: X=0.7500 Y=0.7500 Z=0.5000 4: X=0.7500 Y=0.5000 Z=0.7500 O 1: X=0.2534 Y=0.2534 Z=0.2534 2: X=0.7466 Y=0.7466 Z=0.7466 3: X=0.7466 Y=0.5034 Z=0.5034 4: X=0.2534 Y=0.9966 Z=0.9966 5: X=0.9966 Y=0.9966 Z=0.2534 Best wishes Masood Universiti Tecknologi 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
Re: [Wien] Fromat of positions of Species in Structure File
How ?? did you generate this. the struct editor of w2web or makestruct with: #227, Zn(0.125,0.125,0.125), Al 0.5,0.5,0.5), O (0.2534,0.2534,0.2534) gives you 8 O positions. On 10/10/2013 09:55 AM, Masood Yousaf wrote: Respected Community Members, I would be thankful if someone confirms the Format of the position of the atoms. We generated the structure file for a spinel compound ZnAl2O4 by selecting the space group No Fd-3m #227, chosing cubic lattice constant and angles, Selecting positions Zn(0.125,0.125,0.125), Al (0.5,0.5,0.5), O (0.2534,0.2534,0.2534). In return we got the Positions for 14 atoms in the primitive unit cell as mentioned below. Kindly confirm what is the formatt of input positions Zn(0.125,0.125,0.125), Al (0.5,0.5,0.5), O (0.2534,0.2534,0.2534) and other generated positions in the Structure file. Zn 1: X=0.1250 Y=0.1250 Z=0.1250 2: X=0.8750 Y=0.8750 Z=0.8750 Al1: X=0.5000 Y=0.5000 Z=0.5000 3: X=0.5000 Y=0.7500 Z=0.7500 3: X=0.7500 Y=0.7500 Z=0.5000 4: X=0.7500 Y=0.5000 Z=0.7500 O1: X=0.2534 Y=0.2534 Z=0.2534 2: X=0.7466 Y=0.7466 Z=0.7466 3: X=0.7466 Y=0.5034 Z=0.5034 4: X=0.2534 Y=0.9966 Z=0.9966 5: X=0.9966 Y=0.9966 Z=0.2534 Best wishes Masood Universiti Tecknologi 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] Possible bugs from use of uninitialized variables
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. PS: I don't have a variable WS in dergl.f WS=0.0D0 in dergl.f 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. (PS: I was wrong with my first reply that you need ISPLIT=15 (this relates to an older version). The present if statement is intentional, but still, no result from f7splt will be used (except for ISPLIT=15). On 10/09/2013 01:18 PM, Pavel Ondračka wrote: Dear WIEN2k list, so after I found out, that ifort by default initializes all variables to 0, I got quite paranoid, since this could hide bugs and easily lead to changes in behavior with compilers that doesn't do that. So I fired up valgrind, to see if there are some other occurrences. This is what I found in in the main cycle programs, however I'm not a valgrind expert so I'm hopping someone familiar with the code might have a look. Basically I could just set all the uninitialized variables to 0 manually to mimic ifort behavior, however it would be nice if someone familiar with the code could just check if initialization to 0 is indeed the intended behavior? Lapw2: Here we got a lot of: ==9250== Conditional jump or move depends on uninitialised value(s) ==9250==at 0x30DE027230: cexp (s_cexp.c:57) ==9250==by 0x471758: l2main_ (l2main_tmp_.F:817) ==9250==by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605) ==9250==by 0x48AF6F: main (lapw2_tmp_.F:5) ==9250== Uninitialised value was created by a heap allocation ==9250==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==9250==by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496) ==9250==by 0x46F9C4: l2main_ (l2main_tmp_.F:642) ==9250==by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605) ==9250==by 0x48AF6F: main (lapw2_tmp_.F:5) and ==9250== Conditional jump or move depends on uninitialised value(s) ==9250==at 0x4AFAB0: ylm_ (ylm.f:190) ==9250==by 0x4714EA: l2main_ (l2main_tmp_.F:812) ==9250==by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605) ==9250==by 0x48AF6F: main (lapw2_tmp_.F:5) ==9250== Uninitialised value was created by a heap allocation ==9250==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==9250==by 0x411215: __xa3_MOD_init_xa3 (modules_tmp_.F:496) ==9250==by 0x46F9C4: l2main_ (l2main_tmp_.F:642) ==9250==by 0x48A1AD: MAIN__ (lapw2_tmp_.F:605) ==9250==by 0x48AF6F: main (lapw2_tmp_.F:5) Caused by uninitialized values of kx, ky and kx, that later propagate all over. Can be fixed by adding kx = 0 ky = 0 kz = 0 to init_xa3 subroutine Lapw0: ==9849== Use of uninitialised value of size 8 ==9849==at 0x30DE012FC1: __ieee754_log_sse2 (e_log.c:159) ==9849==by 0x45CF5F: corpbe_ (pbe1.f:337) ==9849==by 0x45F7BE: pbe2_ (pbe2.f:141) ==9849==by 0x480C09: vxclm2_ (vxclm2.f:154) ==9849==by 0x495F34: xcpot1_ (xcpot1.f:382) ==9849==by 0x44A506: MAIN__ (lapw0.F:1875) ==9849==by 0x455122: main (lapw0.F:10) ==9849== Uninitialised value was created by a heap allocation ==9849==at 0xD39887C: malloc (vg_replace_malloc.c:270) ==9849==by 0x40C8DB: dergl_spline_ (dergl.f:134) ==9849==by 0x40BDB2: dergl_ (dergl.f:32) ==9849==by 0x40E42C: drho_ (drho.f:38) ==9849==by 0x493AF4: xcpot1_ (xcpot1.f:195) ==9849==by 0x44A506: MAIN__ (lapw0.F:1875) ==9849==by 0x455122: main (lapw0.F:10) Can be fixed by initializing WS=0.0D0 in dergl.f Mixer: ==4495== Conditional jump or move depends on uninitialised value(s) ==4495==at 0x41F4E3: MAIN__ (mixer.F:1504) ==4495==by 0x424FB5: main (mixer.F:23) ==4495== Uninitialised value was created by a heap allocation ==4495==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==4495==by 0x4160CE: MAIN__ (mixer.F:851) ==4495==by 0x424FB5: main (mixer.F:23) uninitialized variable is ROKMIX (well at least the imaginary part) and we later do stuff like this: mixer.F:1504 if(abs(ROKMIX(J,I)).gt.1D-12)then can also be fixed by initializing to 0 right after allocation (mixer.F:853) ROKMIX = (0.0D0, 0.0D0) And another one in mixer: ==10137== Conditional jump or move depends on uninitialised value(s) ==10137==at 0x45386D: limitdmix8n_ (LimitDMIX8n.F:135) ==10137==by 0x43B2C2: qmix8_ (qmix8.F:631) ==10137==by 0x41D0BB: MAIN__ (mixer.F:1313) ==10137==by 0x42502B: main (mixer.F:23) ==10137== Uninitialised value was created by a stack allocation ==10137==at 0x433A37: qmix8_ (qmix8.F:1) Sadly here I was not able to track down the issue as the function prototype at line qmix8.F:1 where the uninitialised value was tracked to contains over 20 parameters. lapw1: just a small memory leak I
[Wien] Sudden lowering of energy in EOS in SO at V = 0.7V0
Dear WIEN 2K users and Prof Blaha, We are doing EOS calculations (Energy versus Volume) of a 5d late transition metal using spin orbit (SO) interaction. There is no problem upto 25% compression, but beyond this compression the energy value suddenly drops to a very low value. When we checked the corresponding SCF file, we found that the scf file has converged and there is no warning in the scf file, but TOTAL VALENCE CHARGE INSIDE UNIT CELL is not equal to NUMBER OF ELECTRONS. Please note that in the calculations without spin orbit interaction there is no such problem for the same system. I would like to mention that I have gone through the related previous questions and their answers on registered users site. I will be highly obliged if you could kindly spare some time to help me in this problem. Thanks in advance V Mishra ___ 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] Sudden lowering of energy in EOS in SO at V = 0.7V0
It seems you have (at least partly) already figured out, where the problem is. So the next step is to find out why and how this could happen. Unfortunately, I do not really see a possibility to give you a more detailed help. For this I'd need to do these calculations myself. On 10/10/2013 01:34 PM, Vinayak Mishra wrote: Dear WIEN 2K users and Prof Blaha, We are doing EOS calculations (Energy versus Volume) of a 5d late transition metal using spin orbit (SO) interaction. There is no problem upto 25% compression, but beyond this compression the energy value suddenly drops to a very low value. When we checked the corresponding SCF file, we found that the scf file has converged and there is no warning in the scf file, but TOTAL VALENCE CHARGE INSIDE UNIT CELL is not equal to NUMBER OF ELECTRONS. Please note that in the calculations without spin orbit interaction there is no such problem for the same system. I would like to mention that I have gone through the related previous questions and their answers on registered users site. I will be highly obliged if you could kindly spare some time to help me in this problem. Thanks in advance V Mishra ___ 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
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 replaces calls to malloc and similar at runtime with his own versions and tracks the used memory at runtime. To be more specific, I'll try to explain on my previous example why I think it can't be discovered by the ifort checking. Although ifort probably can track, that imaginary part of ROKMIX(J,I) is uninitialized at that point, it has no way of knowing if return value of abs(ROKMIX(J,I)) actually depends on the uninitialized value or not, because abs function has not been linked at that point. (PS: I was wrong with my first reply that you need ISPLIT=15 (this relates to an older version). The present if statement is intentional, but still, no result from f7splt will be used (except for ISPLIT=15). Thanks, this explains it. I'm very grateful and I appreciate it very much, that you are looking into this, even though this is not a problem at your platform. Thanks again. ___ 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
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 ; 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 replaces calls to malloc and similar at runtime with his own versions and tracks the used memory at runtime. To be more specific, I'll try to explain on my previous example why I think it can't be discovered by the ifort checking. Although ifort probably can track, that imaginary part of ROKMIX(J,I) is uninitialized at that point, it has no way of knowing if return value of abs(ROKMIX(J,I)) actually depends on the uninitialized value or not, because abs function has not been linked at that point. (PS: I was wrong with my first reply that you need ISPLIT=15 (this relates to an older version). The present if statement is intentional, but still, no result from f7splt will be used (except for ISPLIT=15). Thanks, this explains it. I'm very grateful and I appreciate it very much, that you are looking into this, even though this is not a problem at your platform. Thanks again. ___ 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 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
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 replaces calls to malloc and similar at runtime with his own versions and tracks the used memory at runtime. To be more specific, I'll try to explain on my previous example why I think it can't be discovered by the ifort checking. Although ifort probably can track, that imaginary part of ROKMIX(J,I) is uninitialized at that point, it has no way of knowing if return value of abs(ROKMIX(J,I)) actually depends on the uninitialized value or not, because abs function has not been linked at that point. (PS: I was wrong with my first reply that you need ISPLIT=15 (this relates to an older version). The present if statement is intentional, but still, no result from f7splt will be used (except for ISPLIT=15). Thanks, this explains it. I'm very grateful and I appreciate it very much, that you are looking into this, even though this is not a problem at your platform. Thanks again. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at:
