Re: [Wien] Errori in mini
The message does not say anything about the reason. You have to search for other messages with more information. My suggestion: MSR1a is MUCH more stable for an inexperienced user then min_lapw, which has problems when its history contains a bad point. I suggest: cp case.inm case.inm_msr1a edit case.inm_msr1a and put MSR1a (instead of MSR1) in your optimize.job script: comment out the linemin_lapw . instead, activate again runsp -orb -fc 1 -cc 0.001 and insert the following line just BEFORE the runsp line: cp case.inm_msr1a case.inm PS: from your dayfile I can see: lapw1 -dn -orb -c (20:18:44) 1603.746u 24.052s 4:26.95 609.7%0+0k 0+382600io 0pf+0w the 600% tells me that you are using OMP_NUM_THREADS=6 which is completely useless. Set it to 2 and do a k-parallel run (study the UG about parallelization) and test it on a small testcase. I suppose you installed wien2k using shared memory machine ? Then you basically need to create .machines file with 3 lines: 1:localhost 1:localhost 1:localhost (and together with OMP_NUM_THREADS=2 you will use all 6 cores and your time will go down from 4:30 to 1:30 for an lapw1 step. On 04/04/2014 05:55 AM, shamik chakrabarti wrote: Dear Prof. Blaha Sir, Sorry to bother you again. But our calculation again get stopped after 4th iteration with the following message. stop error error: command /usr/local/WIEN2k/mini mini.def failed mini(20:24:31) 0.004u 0.003s 0:00.03 0.0%0+0k 2472+48io 11pf+0w stop :CHARGE convergence: 0 0. .0002465 :ENERGY convergence: 0 0 .07395000 mixer -orb(20:24:29) 7.820u 0.390s 0:01.65 497.5%0+0k 168+40568io 1pf+0w lcore -dn(20:24:29) 0.046u 0.003s 0:00.05 80.0%0+0k 0+656io 0pf+0w lcore -up(20:24:29) 0.045u 0.006s 0:00.05 80.0%0+0k 0+656io 0pf+0w lapwdm -dn -c (20:24:27) 8.644u 0.378s 0:01.64 549.3%0+0k 0+48io 0pf+0w lapwdm -up -c (20:24:25) 9.470u 0.403s 0:01.64 601.8%0+0k 0+48io 0pf+0w lapw2 -dn-c -orb (20:23:35) 282.734u 8.097s 0:49.73 584.7%0+0k 0+9816io 0pf+0w lapw2 -up-c -orb (20:22:53) 226.301u 6.095s 0:42.32 549.1%0+0k 0+9824io 0pf+0w 1524.395u 21.656s 4:09.36 620.0%0+0k 0+385000io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 lapw1 -dn -orb -c (20:18:44) _nb in zhcgst.F 640 128 1603.746u 24.052s 4:26.95 609.7%0+0k 0+382600io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 lapw1 -up -orb -c (20:14:17) _nb in zhcgst.F 640 128 orb -dn (20:14:17) 0.002u 0.002s 0:00.00 0.0%0+0k 0+32io 0pf+0w orb -up (20:14:17) 0.002u 0.000s 0:00.00 0.0%0+0k 0+32io 0pf+0w :FORCE convergence: 1 1.0 .010 XCO .009 XCO .037 XCO .013 XCO .031 XCO .014 XCO lapw0 (20:14:08) 8.316u 0.047s 0:08.36 99.8%0+0k 0+16424io 0pf+0w cycle 4 (Thu Apr 3 20:14:08 IST 2014) (37/96 to go) *We have checked case.scf_mini and the forces
Re: [Wien] Errori in mini
Dear Prof. Blaha Sir, Thank you for your response. We have started the calculation by following your suggestions. But as we are using MSR1a instead of min_lapw...it may now take more time than earlier. We have actually 16 cpus in our system I have set OMP_NUM_THREADS=8 for a single calculation we are getting up to 800% usage. However, if we start another calculation it then takes rest of the cpus and we can get all the cpus running with two simultaneous calculation divided in 16 cpus with 800% for each calculation. I have changed OMP_NUM_THREADS value starting from 8 to 16 with gradual increase, but the cpu usage remain same for all the cases. Yes, we should look for k-parallel run for optimum use of our resourcesbut at the moment I don't have any expertise over that kind of installation. We will try to installed k-parallelization with the help of your suggestions and surely will try to improve calculation speed. Thank you Sirthank your for all your suggestions. with regards, On Fri, Apr 4, 2014 at 12:48 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: The message does not say anything about the reason. You have to search for other messages with more information. My suggestion: MSR1a is MUCH more stable for an inexperienced user then min_lapw, which has problems when its history contains a bad point. I suggest: cp case.inm case.inm_msr1a edit case.inm_msr1a and put MSR1a (instead of MSR1) in your optimize.job script: comment out the linemin_lapw . instead, activate again runsp -orb -fc 1 -cc 0.001 and insert the following line just BEFORE the runsp line: cp case.inm_msr1a case.inm PS: from your dayfile I can see: lapw1 -dn -orb -c (20:18:44) 1603.746u 24.052s 4:26.95 609.7%0+0k 0+382600io 0pf+0w the 600% tells me that you are using OMP_NUM_THREADS=6 which is completely useless. Set it to 2 and do a k-parallel run (study the UG about parallelization) and test it on a small testcase. I suppose you installed wien2k using shared memory machine ? Then you basically need to create .machines file with 3 lines: 1:localhost 1:localhost 1:localhost (and together with OMP_NUM_THREADS=2 you will use all 6 cores and your time will go down from 4:30 to 1:30 for an lapw1 step. On 04/04/2014 05:55 AM, shamik chakrabarti wrote: Dear Prof. Blaha Sir, Sorry to bother you again. But our calculation again get stopped after 4th iteration with the following message. stop error error: command /usr/local/WIEN2k/mini mini.def failed mini(20:24:31) 0.004u 0.003s 0:00.03 0.0%0+0k 2472+48io 11pf+0w stop :CHARGE convergence: 0 0. .0002465 :ENERGY convergence: 0 0 .07395000 mixer -orb(20:24:29) 7.820u 0.390s 0:01.65 497.5%0+0k 168+40568io 1pf+0w lcore -dn(20:24:29) 0.046u 0.003s 0:00.05 80.0%0+0k 0+656io 0pf+0w lcore -up(20:24:29) 0.045u 0.006s 0:00.05 80.0%0+0k 0+656io 0pf+0w lapwdm -dn -c (20:24:27) 8.644u 0.378s 0:01.64 549.3%0+0k 0+48io 0pf+0w lapwdm -up -c (20:24:25) 9.470u 0.403s 0:01.64 601.8%0+0k 0+48io 0pf+0w lapw2 -dn-c -orb (20:23:35) 282.734u 8.097s 0:49.73 584.7%0+0k 0+9816io 0pf+0w lapw2 -up-c -orb (20:22:53) 226.301u 6.095s 0:42.32 549.1%0+0k 0+9824io 0pf+0w 1524.395u 21.656s 4:09.36 620.0%0+0k 0+385000io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 lapw1 -dn -orb -c (20:18:44) _nb in zhcgst.F 640 128 1603.746u 24.052s 4:26.95 609.7%0+0k 0+382600io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640
Re: [Wien] Errori in mini
Of course it is using 600 or 800% of the cpu, BUT it does not run faster at all !!! Compare the timings in case.dayfile. You really can see at what time a step starts and how long it really took. On 04/04/2014 11:23 AM, shamik chakrabarti wrote: Dear Prof. Blaha Sir, Thank you for your response. We have started the calculation by following your suggestions. But as we are using MSR1a instead of min_lapw...it may now take more time than earlier. We have actually 16 cpus in our system I have set OMP_NUM_THREADS=8 for a single calculation we are getting up to 800% usage. However, if we start another calculation it then takes rest of the cpus and we can get all the cpus running with two simultaneous calculation divided in 16 cpus with 800% for each calculation. I have changed OMP_NUM_THREADS value starting from 8 to 16 with gradual increase, but the cpu usage remain same for all the cases. Yes, we should look for k-parallel run for optimum use of our resourcesbut at the moment I don't have any expertise over that kind of installation. We will try to installed k-parallelization with the help of your suggestions and surely will try to improve calculation speed. Thank you Sirthank your for all your suggestions. with regards, On Fri, Apr 4, 2014 at 12:48 PM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: The message does not say anything about the reason. You have to search for other messages with more information. My suggestion: MSR1a is MUCH more stable for an inexperienced user then min_lapw, which has problems when its history contains a bad point. I suggest: cp case.inm case.inm_msr1a edit case.inm_msr1a and put MSR1a (instead of MSR1) in your optimize.job script: comment out the linemin_lapw . instead, activate again runsp -orb -fc 1 -cc 0.001 and insert the following line just BEFORE the runsp line: cp case.inm_msr1a case.inm PS: from your dayfile I can see: lapw1 -dn -orb -c (20:18:44) 1603.746u 24.052s 4:26.95 609.7%0+0k 0+382600io 0pf+0w the 600% tells me that you are using OMP_NUM_THREADS=6 which is completely useless. Set it to 2 and do a k-parallel run (study the UG about parallelization) and test it on a small testcase. I suppose you installed wien2k using shared memory machine ? Then you basically need to create .machines file with 3 lines: 1:localhost 1:localhost 1:localhost (and together with OMP_NUM_THREADS=2 you will use all 6 cores and your time will go down from 4:30 to 1:30 for an lapw1 step. On 04/04/2014 05:55 AM, shamik chakrabarti wrote: Dear Prof. Blaha Sir, Sorry to bother you again. But our calculation again get stopped after 4th iteration with the following message. stop error error: command /usr/local/WIEN2k/mini mini.def failed mini(20:24:31) 0.004u 0.003s 0:00.03 0.0%0+0k 2472+48io 11pf+0w stop :CHARGE convergence: 0 0. .0002465 :ENERGY convergence: 0 0 .07395000 mixer -orb(20:24:29) 7.820u 0.390s 0:01.65 497.5%0+0k 168+40568io 1pf+0w lcore -dn(20:24:29) 0.046u 0.003s 0:00.05 80.0%0+0k 0+656io 0pf+0w lcore -up(20:24:29) 0.045u 0.006s 0:00.05 80.0%0+0k 0+656io 0pf+0w lapwdm -dn -c (20:24:27) 8.644u 0.378s 0:01.64 549.3%0+0k 0+48io 0pf+0w lapwdm -up -c (20:24:25) 9.470u 0.403s 0:01.64 601.8%0+0k 0+48io 0pf+0w lapw2 -dn-c -orb (20:23:35) 282.734u 8.097s 0:49.73 584.7%0+0k 0+9816io 0pf+0w lapw2 -up-c -orb (20:22:53) 226.301u 6.095s 0:42.32 549.1%0+0k 0+9824io 0pf+0w 1524.395u 21.656s 4:09.36 620.0%0+0k 0+385000io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640
Re: [Wien] Errori in mini
Dear Prof. Blaha Sir, To continue from your last suggestions we have noticed the timing of a single iteration. It is 10 minutes for 16 atoms/unit cell calculation. Sir, do you think that this speed is ok considering our system having 16 cpus?.. Yes of course for we have to go for k-parallization. Looking forwards to your comments and suggestion. With regards, On 3 Apr 2014 18:04, shamik chakrabarti shamik...@gmail.com wrote: Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutineLineSource forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7% 0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0% 0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0% 0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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] Errori in mini
Hello, Due to lack of information on what you are simulating and with which settings I think you will find more useful to perform the tests yourself where you vary the amount of CPUs used, that way you can see the actual difference. Kind regards, Michael Sluydts shamik chakrabarti schreef op 4/04/2014 17:02: Dear Prof. Blaha Sir, To continue from your last suggestions we have noticed the timing of a single iteration. It is 10 minutes for 16 atoms/unit cell calculation. Sir, do you think that this speed is ok considering our system having 16 cpus?.. Yes of course for we have to go for k-parallization. Looking forwards to your comments and suggestion. With regards, On 3 Apr 2014 18:04, shamik chakrabarti shamik...@gmail.com mailto:shamik...@gmail.com wrote: Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_ 23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutine LineSource forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7%0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0%0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0%0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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] Errori in mini
Dear Michael, Thank you for your reply. Yes we are going to try for maximizing performance of our system. Thanks once again, With regards, On 4 Apr 2014 20:38, Michael Sluydts michael.sluy...@ugent.be wrote: Hello, Due to lack of information on what you are simulating and with which settings I think you will find more useful to perform the tests yourself where you vary the amount of CPUs used, that way you can see the actual difference. Kind regards, Michael Sluydts shamik chakrabarti schreef op 4/04/2014 17:02: Dear Prof. Blaha Sir, To continue from your last suggestions we have noticed the timing of a single iteration. It is 10 minutes for 16 atoms/unit cell calculation. Sir, do you think that this speed is ok considering our system having 16 cpus?.. Yes of course for we have to go for k-parallization. Looking forwards to your comments and suggestion. With regards, On 3 Apr 2014 18:04, shamik chakrabarti shamik...@gmail.com wrote: Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutineLine Source forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7% 0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0% 0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0% 0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 INDIA ___ Wien mailing listw...@zeus.theochem.tuwien.ac.athttp://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 ___ 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] Errori in mini
Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutineLineSource forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7% 0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0% 0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0% 0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7% 0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7% 0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0% 0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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] Errori in mini
You are using min_lapw ? I suggest: When the scf cycle crashes after a few steps and you restart, you have to remove case.scf before resubmission. Otherwise it attempts to start immediately the min program and generates a new structure (with non-converged forces). On 04/03/2014 02:34 PM, shamik chakrabarti wrote: Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutineLineSource forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7%0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0%0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0%0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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 -- 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] Errori in mini
Dear Prof. Peter Blaha Gavin Abo Sir, Thanks for your responses. Yes Prof. Blaha is right. It was indeed the problem. We have removed case.scf and rerun the calculation now it is running smoothly. Thank you Sir. with regards, On Thu, Apr 3, 2014 at 7:34 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: You are using min_lapw ? I suggest: When the scf cycle crashes after a few steps and you restart, you have to remove case.scf before resubmission. Otherwise it attempts to start immediately the min program and generates a new structure (with non-converged forces). On 04/03/2014 02:34 PM, shamik chakrabarti wrote: Dear wien2k users, We are working on a Li based silicate materials. We are trying to do simultaneous optimization of lattice parameters and atomic coordinates. For that we are using Option 6 in volume optimize program while edited optimized.job to perform simultaneous force minimization. The calculation was run smoothly up to 2 structures i.e, case_abc_1.0 and case_abc_2.0. Then due to power failure the calculation was remain stopped for several hours.. We restarted the calculation by putting # to the two lines corresponding to 1st and 2nd structure in optimize.job...such that the calculation starts from the structure case_abc_3.0However, while running for 3rd structure the following display came in show dayfile option. ERROR status in case_abc___3.0 mini 004035D9 Unknown Unknown Unknown libc.so.6 00349521ECDD Unknown Unknown Unknown mini 004036E6 Unknown Unknown Unknown mini 00412AA6 MAIN__ 25 mini.f mini 0040C6AB haupt_593 haupt.f mini 0041A39F wrtscf_23 wrtscf.f mini 00451F5A Unknown Unknown Unknown mini 00453C1E Unknown Unknown Unknown Image PCRoutineLineSource forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read 3.887u 0.013s 0:03.90 99.7%0+0k 0+11912io 0pf+0w DSTART ENDS 3.879u 0.008s 0:03.88 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.879u 0.011s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS clmextrapol_lapw has generated a new case.clmdn 0.196u 0.007s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.888u 0.015s 0:03.90 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmup 0.196u 0.010s 0:00.20 100.0%0+0k 0+8032io 0pf+0w 3.929u 0.020s 0:03.94 100.0%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode clmextrapol_lapw has generated a new case.clmsum 0.195u 0.004s 0:00.20 95.0%0+0k 0+8032io 0pf+0w 3.923u 0.017s 0:03.94 99.7%0+0k 0+13528io 0pf+0w DSTART ENDS running dstart in single mode 3.888u 0.003s 0:03.89 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.895u 0.010s 0:03.91 99.7%0+0k 0+11904io 0pf+0w DSTART ENDS 3.934u 0.010s 0:03.94 100.0%0+0k 0+11912io 0pf+0w DSTART ENDS we are using wien2k 13.1 What could be the possible reasons for this error?.any response in this regard will be fruitful for us. Thanks in advance. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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 -- 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 -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics Meteorology Material Processing Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 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] Errori in mini
Dear Prof. Blaha Sir, Sorry to bother you again. But our calculation again get stopped after 4th iteration with the following message. stop error error: command /usr/local/WIEN2k/mini mini.def failed mini (20:24:31) 0.004u 0.003s 0:00.03 0.0% 0+0k 2472+48io 11pf+0w stop :CHARGE convergence: 0 0. .0002465 :ENERGY convergence: 0 0 .07395000 mixer -orb (20:24:29) 7.820u 0.390s 0:01.65 497.5% 0+0k 168+40568io 1pf+0w lcore -dn (20:24:29) 0.046u 0.003s 0:00.05 80.0% 0+0k 0+656io 0pf+0w lcore -up (20:24:29) 0.045u 0.006s 0:00.05 80.0% 0+0k 0+656io 0pf+0w lapwdm -dn -c (20:24:27) 8.644u 0.378s 0:01.64 549.3% 0+0k 0+48io 0pf+0w lapwdm -up -c (20:24:25) 9.470u 0.403s 0:01.64 601.8% 0+0k 0+48io 0pf+0w lapw2 -dn-c -orb (20:23:35) 282.734u 8.097s 0:49.73 584.7% 0+0k 0+9816io 0pf+0w lapw2 -up-c -orb (20:22:53) 226.301u 6.095s 0:42.32 549.1% 0+0k 0+9824io 0pf+0w 1524.395u 21.656s 4:09.36 620.0% 0+0k 0+385000io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 lapw1 -dn -orb -c (20:18:44) _nb in zhcgst.F 640 128 1603.746u 24.052s 4:26.95 609.7% 0+0k 0+382600io 0pf+0w _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 _nb in zhcgst.F 640 128 lapw1 -up -orb -c (20:14:17) _nb in zhcgst.F 640 128 orb -dn (20:14:17) 0.002u 0.002s 0:00.00 0.0% 0+0k 0+32io 0pf+0w orb -up (20:14:17) 0.002u 0.000s 0:00.00 0.0% 0+0k 0+32io 0pf+0w :FORCE convergence: 1 1.0 .010 XCO .009 XCO .037 XCO .013 XCO .031 XCO .014 XCO lapw0 (20:14:08) 8.316u 0.047s 0:08.36 99.8% 0+0k 0+16424io 0pf+0w cycle 4 (Thu Apr 3 20:14:08 IST 2014) (37/96 to go) *We have checked case.scf_mini and the forces in the structure are as given below:* TOTAL FORCE IN mRy/a.u. = |F| Fx Fy Fz with/without FOR in :FOR001: 1.ATOM 16.382428 -2.026946 -1.179494 16.213705 total forces :FOR002: 2.ATOM 13.581345 13.580984 0.098977 0.00 total forces :FOR003: 3.ATOM 9.631644 6.298244 7.287022 0.00 total forces :FOR004: 4.ATOM 9.227031 -1.691938 -2.752735 -8.642795 total forces :FOR005: 5.ATOM 3.096054 -1.485397 2.716458 0.00 total forces :FOR006: 6.ATOM 27.808540 -10.866967 -25.597343 0.00 total forces Sir now what could be the reason for this failure. Looking forward to your reply eagerly Thanks in advance, with regards. On Thu, Apr 3, 2014 at 8:19 PM, shamik chakrabarti shamik...@gmail.comwrote: Dear Prof. Peter Blaha Gavin Abo Sir, Thanks for your responses. Yes Prof. Blaha is right. It was indeed the problem. We have removed case.scf and rerun the calculation now it is running smoothly. Thank you Sir. with regards, On Thu, Apr 3, 2014 at 7:34 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: You are using min_lapw ? I suggest: When the scf cycle crashes after a few steps and you
