[Wien] Hybrid Test on MgO
As suggested I have calculated a hybrid functional for the MgO primitive cell. My .machines file was # lapw0:localhost:2 8:localhost:2 8:draco-ib:2 granularity extrafine:1 and my MgO.inhf file looks like 0.25 alpha Tscreened (T) or unscreened (F) 0.165lambda 9nband 6gmax 3lmaxe 3lmaxv 1d-3 tolu For the regular PBE calculation (just run_lapw -p -in1new 2), a SCF loop took about 15 seconds. For the hybrid calculation with options “run_lapw -hf -p -in1new 2”, with the above case.inhf file (screening off), the calculation on the same structure took about 90 seconds/SCF loop, making the hybrid calculations about a factor of six slower. I encountered no errors with this run unlike my attempts with the 96 atom system. In response to the question asked about the size of aCGT.weighf, the size of the file was 117,020 bytes. Best wishes, Paul Fons On Mar 13, 2015, at 11:37 PM, t...@theochem.tuwien.ac.at wrote: What is the size of aCGT.weighhf? Is it empty? Also, before continuing further with your big system, it would be interesting to know if the same problem occurs with a very small system like MgO (on same machine and in MPI mode). Anyway, I still think that it is hopeless to apply hybrid functionals on such a big system. F. Tran On Fri, 13 Mar 2015, Paul Fons wrote: I attempted to run a SCF loop using a hybrid functional and have run into some problems. In my earlier try I had a incorrectly specified .machines file now I have addressed this problem. I also changed the SCRATCH environment variable to “./“ so that it points to the main directory for the calculation. I have run a PBE SCF loop to normal terminal for an amorphous cluster of 96 atoms of Cu-Ge-Te. I then ran the init_hf script and after setting the number of bands to 770 for my 1526 electron system, I set the MP grid to 2x2x2 for a total of four k-points. I then ran the command run_lapw -hf -p -in1new 2”. The SCF loop ran through lapw0, lapw1, lapw2, core, and then crashed at the program hf. The MPI processes upon crashing reported the following error: forrtl: severe (67): input statement requires too much data, unit 26, file /usr/local/share/wien2k/Fons/aCGT/aCGT.weighhf I have no idea why the program failed this time. I am using the Intel compiler (15) and the Intel MPI environment (e.g. mpiexec.hydra) to launch parallel programs as can be seen in the “parallel_options” file. The only *.error files are those like “hf_1.error” to “hf_4.error” which contain the not particularly useful information “error in hf”. So the error occurred in the routine “hf”. I would be most grateful for any advice as to what to try next. I have included what I hope is relevant debugging information below. My parallel_options files (in all nodes) are mats...@gemini.a04.aist.go.jp:~/Wien2Kcat parallel_options setenv TASKSET no setenv USE_REMOTE 0 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN mpiexec.hydra -n _NP_ -machinefile _HOSTS_ _EXEC_ My .machines files is as follows: lapw0:localhost:12 1:localhost:12 1:localhost:12 1:draco-ib:12 1:draco-ib:12 granularity:1 extrafine:1 CONTENTS of :parallel - starting parallel lapw1 at Thu Mar 12 14:25:13 JST 2015 localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 25254.539u 519.601s 35:44.50 1201.8% 0+0k 8+882304io 0pf+0w localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 24889.112u 585.238s 35:41.95 1189.3% 0+0k 0+719488io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.034u 0.021s 32:40.68 0.0% 0+0k 0+0io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.035u 0.017s 32:39.14 0.0% 0+0k 0+0io 0pf+0w Summary of lapw1para: localhostk=0 user=0 wallclock=0 draco-ib k=0 user=0 wallclock=0 - done at Thu Mar 12 15:01:00 JST 2015 - - starting Fermi on gemini.a04.aist.go.jp at Thu Mar 12 15:28:19 JST 2015 - starting parallel lapw2c at Thu Mar 12 15:28:20 JST 2015 localhost 389.940u 7.565s 0:36.04 1102.9% 0+0k 718416+253704io 0pf+0w localhost 347.944u 5.749s 0:31.67 1116.7% 0+0k 718528+199776io 0pf+0w draco-ib 0.029u 0.026s 0:33.86 0.1% 0+0k 8+0io 0pf+0w draco-ib 0.032u 0.020s 0:33.80 0.1% 0+0k 8+0io 0pf+0w Summary of lapw2para: localhostuser=737.884wallclock=67.71 draco-ib user=0.061 wallclock=67.66 - done at Thu Mar 12 15:28:57 JST 2015
[Wien] Update on hybrid troubles
I attempted to run a SCF loop using a hybrid functional and have run into some problems. In my earlier try I had a incorrectly specified .machines file now I have addressed this problem. I also changed the SCRATCH environment variable to “./“ so that it points to the main directory for the calculation. I have run a PBE SCF loop to normal terminal for an amorphous cluster of 96 atoms of Cu-Ge-Te. I then ran the init_hf script and after setting the number of bands to 770 for my 1526 electron system, I set the MP grid to 2x2x2 for a total of four k-points. I then ran the command run_lapw -hf -p -in1new 2”. The SCF loop ran through lapw0, lapw1, lapw2, core, and then crashed at the program hf. The MPI processes upon crashing reported the following error: forrtl: severe (67): input statement requires too much data, unit 26, file /usr/local/share/wien2k/Fons/aCGT/aCGT.weighhf I have no idea why the program failed this time. I am using the Intel compiler (15) and the Intel MPI environment (e.g. mpiexec.hydra) to launch parallel programs as can be seen in the “parallel_options” file. The only *.error files are those like “hf_1.error” to “hf_4.error” which contain the not particularly useful information “error in hf”. So the error occurred in the routine “hf”. I would be most grateful for any advice as to what to try next. I have included what I hope is relevant debugging information below. My parallel_options files (in all nodes) are mats...@gemini.a04.aist.go.jp:~/Wien2Kcat parallel_options setenv TASKSET no setenv USE_REMOTE 0 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN mpiexec.hydra -n _NP_ -machinefile _HOSTS_ _EXEC_ My .machines files is as follows: lapw0:localhost:12 1:localhost:12 1:localhost:12 1:draco-ib:12 1:draco-ib:12 granularity:1 extrafine:1 CONTENTS of :parallel - starting parallel lapw1 at Thu Mar 12 14:25:13 JST 2015 localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 25254.539u 519.601s 35:44.50 1201.8%0+0k 8+882304io 0pf+0w localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 24889.112u 585.238s 35:41.95 1189.3%0+0k 0+719488io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.034u 0.021s 32:40.68 0.0% 0+0k 0+0io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.035u 0.017s 32:39.14 0.0% 0+0k 0+0io 0pf+0w Summary of lapw1para: localhost k=0 user=0 wallclock=0 draco-ib k=0 user=0 wallclock=0 - done at Thu Mar 12 15:01:00 JST 2015 - - starting Fermi on gemini.a04.aist.go.jp at Thu Mar 12 15:28:19 JST 2015 - starting parallel lapw2c at Thu Mar 12 15:28:20 JST 2015 localhost 389.940u 7.565s 0:36.04 1102.9% 0+0k 718416+253704io 0pf+0w localhost 347.944u 5.749s 0:31.67 1116.7% 0+0k 718528+199776io 0pf+0w draco-ib 0.029u 0.026s 0:33.86 0.1% 0+0k 8+0io 0pf+0w draco-ib 0.032u 0.020s 0:33.80 0.1% 0+0k 8+0io 0pf+0w Summary of lapw2para: localhost user=737.884wallclock=67.71 draco-ib user=0.061 wallclock=67.66 - done at Thu Mar 12 15:28:57 JST 2015 - starting sumpara 4 on gemini.a04.aist.go.jp at Thu Mar 12 15:28:58 JST 2015 - done at Thu Mar 12 15:29:27 JST 2015 - - starting parallel hfc at Thu Mar 12 15:29:35 JST 2015 ** HF crashed at Thu Mar 12 15:29:40 JST 2015 ** check ERROR FILES! DAYFILE mats...@libra.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTcat aCGT.dayfile Calculating aCGT in /usr/local/share/wien2k/Fons/aCGT on gemini.a04.aist.go.jp with PID 46746 using WIEN2k_14.2 (Release 15/10/2014) in /home/matstud/Wien2K start (Thu Mar 12 11:22:09 JST 2015) with lapw0 (40/99 to go) cycle 1 (Thu Mar 12 11:22:09 JST 2015) (40/99 to go) lapw0 -grr -p (11:22:09) starting parallel lapw0 at Thu Mar 12 11:22:09 JST 2015 .machine0 : 12 processors 745.365u 3.350s 1:05.09 1150.2% 0+0k 144+796936io 0pf+0w lapw0 -p(11:23:14) starting parallel lapw0 at Thu Mar 12 11:23:15 JST 2015 .machine0 : 12 processors 620.682u 2.669s 0:54.15 1151.1% 0+0k 40+203264io 0pf+0w lapw1-c (11:24:09) 20736.270u 146.444s 3:01:03.72 192.2% 0+0k 11992+5913840io 0pf+0w lapw1 -p -c (14:25:13) starting parallel lapw1 at Thu Mar 12 14:25:13 JST 2015 - starting parallel LAPW1 jobs at Thu Mar 12 14:25:13 JST 2015 running LAPW1 in parallel mode (using .machines) 4 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost
[Wien] Update on hybrid troubles
I attempted to run a SCF loop using a hybrid functional and have run into some problems. In my earlier try I had a incorrectly specified .machines file now I have addressed this problem. I also changed the SCRATCH environment variable to “./“ so that it points to the main directory for the calculation. I have run a PBE SCF loop to normal terminal for an amorphous cluster of 96 atoms of Cu-Ge-Te. I then ran the init_hf script and after setting the number of bands to 770 for my 1526 electron system, I set the MP grid to 2x2x2 for a total of four k-points. I then ran the command run_lapw -hf -p -in1new 2”. The SCF loop ran through lapw0, lapw1, lapw2, core, and then crashed at the program hf. The MPI processes upon crashing reported the following error: forrtl: severe (67): input statement requires too much data, unit 26, file /usr/local/share/wien2k/Fons/aCGT/aCGT.weighhf I have no idea why the program failed this time. I am using the Intel compiler (15) and the Intel MPI environment (e.g. mpiexec.hydra) to launch parallel programs as can be seen in the “parallel_options” file. The only *.error files are those like “hf_1.error” to “hf_4.error” which contain the not particularly useful information “error in hf”. So the error occurred in the routine “hf”. I would be most grateful for any advice as to what to try next. I have included what I hope is relevant debugging information below. My parallel_options files (in all nodes) are mats...@gemini.a04.aist.go.jp:~/Wien2Kcat parallel_options setenv TASKSET no setenv USE_REMOTE 0 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN mpiexec.hydra -n _NP_ -machinefile _HOSTS_ _EXEC_ My .machines files is as follows: lapw0:localhost:12 1:localhost:12 1:localhost:12 1:draco-ib:12 1:draco-ib:12 granularity:1 extrafine:1 CONTENTS of :parallel - starting parallel lapw1 at Thu Mar 12 14:25:13 JST 2015 localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 25254.539u 519.601s 35:44.50 1201.8%0+0k 8+882304io 0pf+0w localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 24889.112u 585.238s 35:41.95 1189.3%0+0k 0+719488io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.034u 0.021s 32:40.68 0.0% 0+0k 0+0io 0pf+0w draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib draco-ib(1) 0.035u 0.017s 32:39.14 0.0% 0+0k 0+0io 0pf+0w Summary of lapw1para: localhost k=0 user=0 wallclock=0 draco-ib k=0 user=0 wallclock=0 - done at Thu Mar 12 15:01:00 JST 2015 - - starting Fermi on gemini.a04.aist.go.jp at Thu Mar 12 15:28:19 JST 2015 - starting parallel lapw2c at Thu Mar 12 15:28:20 JST 2015 localhost 389.940u 7.565s 0:36.04 1102.9% 0+0k 718416+253704io 0pf+0w localhost 347.944u 5.749s 0:31.67 1116.7% 0+0k 718528+199776io 0pf+0w draco-ib 0.029u 0.026s 0:33.86 0.1% 0+0k 8+0io 0pf+0w draco-ib 0.032u 0.020s 0:33.80 0.1% 0+0k 8+0io 0pf+0w Summary of lapw2para: localhost user=737.884wallclock=67.71 draco-ib user=0.061 wallclock=67.66 - done at Thu Mar 12 15:28:57 JST 2015 - starting sumpara 4 on gemini.a04.aist.go.jp at Thu Mar 12 15:28:58 JST 2015 - done at Thu Mar 12 15:29:27 JST 2015 - - starting parallel hfc at Thu Mar 12 15:29:35 JST 2015 ** HF crashed at Thu Mar 12 15:29:40 JST 2015 ** check ERROR FILES! DAYFILE mats...@libra.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTcat aCGT.dayfile Calculating aCGT in /usr/local/share/wien2k/Fons/aCGT on gemini.a04.aist.go.jp with PID 46746 using WIEN2k_14.2 (Release 15/10/2014) in /home/matstud/Wien2K start (Thu Mar 12 11:22:09 JST 2015) with lapw0 (40/99 to go) cycle 1 (Thu Mar 12 11:22:09 JST 2015) (40/99 to go) lapw0 -grr -p (11:22:09) starting parallel lapw0 at Thu Mar 12 11:22:09 JST 2015 .machine0 : 12 processors 745.365u 3.350s 1:05.09 1150.2% 0+0k 144+796936io 0pf+0w lapw0 -p(11:23:14) starting parallel lapw0 at Thu Mar 12 11:23:15 JST 2015 .machine0 : 12 processors 620.682u 2.669s 0:54.15 1151.1% 0+0k 40+203264io 0pf+0w lapw1-c (11:24:09) 20736.270u 146.444s 3:01:03.72 192.2% 0+0k 11992+5913840io 0pf+0w lapw1 -p -c (14:25:13) starting parallel lapw1 at Thu Mar 12 14:25:13 JST 2015 - starting parallel LAPW1 jobs at Thu Mar 12 14:25:13 JST 2015 running LAPW1 in parallel mode (using .machines) 4 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost
[Wien] Problems with hybrid calculations: case.vectorhf_old file missing
I have an update and some questions on hybrid calculations on a 96 atom cluster. I am running my initial tests with two 24 core machines connected by Infiniband. I have included 4 k-points using a 2x2x2 MP grid. My .machines file is as below. lapw0:localhost:12 1:localhost:12 1:localhost:12 1:draco-ib:12 1:draco-ib:12 granularity:1 extrafine:1 I have done a conventional PBE calculation on the same cluster using the above .machines file and the calculation finished without errors in a few hours. I then initialized a hf calculation using lapw_hf_lapw and specified the same 2x2x2 grid. I specified 770 bands in my case.inhf as I have 1526 electrons. The initialize ran without errors. I then invoked the scf loop using “run_lapw -hf -p” using the same machines file. The lapw0 and the initial part of the scf loop appears to have run without errors, but the calculation stopped on the second iteration of the SCF loop. In particular, the second loop failed due to a missing file /home/matstud/WIENSCRATCH/aCGT.vectorhf_old STATUS: old”. Before I continue, I should add that the WIENSCRATCH environmental variable is correctly set and the directories on both machines exist. I should add that of course the regular parallel PBE run ran without errors as well and I assumed it used the same scratch directories without error. The file in question “aCGT.vectorhf_old” does not exist in either of the WIENSCRATCH directories nor does it exist in the home directory of the calculation. The two nodes are gemini (localhost) and draco-ib (the infini-band connected second node). The contents of the scratch directories on both nodes are listed below as well as the files with vector within the files on the project directory. The current calculation only involves four k-points and I have been careful not to limit the number of MPI jobs to four. I have done the calculation twice now with the same errors. The first time, I tried it immediately after a successful PBE calculation while the second time I tried it after deleting all of the files in the WIENSCRATCH directory thinking it the file error could have been caused by filename confusion. The end result was the same (reprinted below). The run stops because the file aCGT.vectorhf_old cannot be found. Are there any suggestions as to what I might try next to solve the problem? Thanks in advance for any help. The actual run output went as follows: run_lapw -hf -p -in1new 2 LAPW0 END LAPW0 END LAPW1 END mv: cannot stat `aCGT.vector': No such file or directory LAPW1 END LAPW1 END LAPW1 END LAPW1 END mv: cannot stat `aCGT.vectorhf_old': No such file or directory LAPW2 END mv: cannot stat `aCGT.vector': No such file or directory LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END LAPW2 END LAPW2 END SUMPARA END CORE END OPEN FAILED Above message repeats for a total of 48 times error with vector files stop error vector files in the different directories. On gemini (locahost) working directory ls -l aCGT*vector* -rw-rw-r-- 1 matstud matstud 0 Mar 8 19:18 aCGT.vectorhf On gemini (locahost) WIENSCRATCH mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTls -l $HOME/WIENSCRATCH total 3592696 -rw-rw-r-- 1 matstud matstud 2943235040 Mar 9 13:31 aCGT.vector -rw-rw-r-- 1 matstud matstud 367792558 Mar 9 14:11 aCGT.vector_1 -rw-rw-r-- 1 matstud matstud 367877082 Mar 9 14:11 aCGT.vector_2 On draco-ib (remote host) WIENSCRATCH directory mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTssh draco-ib ls -l WIENSCRATCH total 718780 -rw-r--r-- 1 matstud matstud 367646498 Mar 9 14:04 aCGT.vector_3 -rw-r--r-- 1 matstud matstud 368373958 Mar 9 14:04 aCGT.vector_4 DAYFILE cat aCGT.dayfile Calculating aCGT in /usr/local/share/wien2k/Fons/aCGT on gemini.a04.aist.go.jp with PID 45216 using WIEN2k_14.2 (Release 15/10/2014) in /home/matstud/Wien2K start (Mon Mar 9 10:27:54 JST 2015) with lapw0 (40/99 to go) cycle 1 (Mon Mar 9 10:27:55 JST 2015) (40/99 to go) lapw0 -grr -p (10:27:55) starting parallel lapw0 at Mon Mar 9 10:27:55 JST 2015 .machine0 : 12 processors 755.913u 3.546s 1:06.22 1146.8% 0+0k 184+796936io 0pf+0w lapw0 -p(10:29:01) starting parallel lapw0 at Mon Mar 9 10:29:01 JST 2015 .machine0 : 12 processors 622.223u 2.856s 0:54.57 1145.4% 0+0k 48+203264io 0pf+0w lapw1-c (10:29:56) 20873.217u 161.505s 3:01:39.31 192.9% 0+0k 14448+5913840io 0pf+0w lapw1 -p -c (13:31:36) starting parallel lapw1 at Mon Mar 9 13:31:36 JST 2015 - starting parallel LAPW1 jobs at Mon Mar 9 13:31:36 JST 2015 running LAPW1 in parallel mode (using .machines) 4 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 27361.552u 625.141s 39:53.54 1169.2%0+0k 8+882304io 0pf+0w localhost localhost
[Wien] Problems with hybrid calculations: case.vectorhf_old file missing
I have an update and some questions on hybrid calculations on a 96 atom cluster. I am running my initial tests with two 24 core machines connected by Infiniband. I have included 4 k-points using a 2x2x2 MP grid. My .machines file is as below. lapw0:localhost:12 1:localhost:12 1:localhost:12 1:draco-ib:12 1:draco-ib:12 granularity:1 extrafine:1 I have done a conventional PBE calculation on the same cluster using the above .machines file and the calculation finished without errors in a few hours. I then initialized a hf calculation using lapw_hf_lapw and specified the same 2x2x2 grid. I specified 770 bands in my case.inhf as I have 1526 electrons. The initialize ran without errors. I then invoked the scf loop using “run_lapw -hf -p” using the same machines file. The lapw0 and the initial part of the scf loop appears to have run without errors, but the calculation stopped on the second iteration of the SCF loop. In particular, the second loop failed due to a missing file /home/matstud/WIENSCRATCH/aCGT.vectorhf_old STATUS: old”. Before I continue, I should add that the WIENSCRATCH environmental variable is correctly set and the directories on both machines exist. I should add that of course the regular parallel PBE run ran without errors as well and I assumed it used the same scratch directories without error. The file in question “aCGT.vectorhf_old” does not exist in either of the WIENSCRATCH directories nor does it exist in the home directory of the calculation. The two nodes are gemini (localhost) and draco-ib (the infini-band connected second node). The contents of the scratch directories on both nodes are listed below as well as the files with vector within the files on the project directory. The current calculation only involves four k-points. The actual run output went as follows: run_lapw -hf -p -in1new 2 LAPW0 END LAPW0 END LAPW1 END mv: cannot stat `aCGT.vector': No such file or directory LAPW1 END LAPW1 END LAPW1 END LAPW1 END mv: cannot stat `aCGT.vectorhf_old': No such file or directory LAPW2 END mv: cannot stat `aCGT.vector': No such file or directory LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END LAPW2 END LAPW2 END SUMPARA END CORE END OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED OPEN FAILED error with vector files stop error vector files in the different directories. On gemini (locahost) working directory ls -l aCGT*vector* -rw-rw-r-- 1 matstud matstud 0 Mar 8 19:18 aCGT.vectorhf On gemini (locahost) WIENSCRATCH mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTls -l $HOME/WIENSCRATCH total 3592696 -rw-rw-r-- 1 matstud matstud 2943235040 Mar 9 13:31 aCGT.vector -rw-rw-r-- 1 matstud matstud 367792558 Mar 9 14:11 aCGT.vector_1 -rw-rw-r-- 1 matstud matstud 367877082 Mar 9 14:11 aCGT.vector_2 On draco-ib (remote host) WIENSCRATCH directory mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTssh draco-ib ls -l WIENSCRATCH total 718780 -rw-r--r-- 1 matstud matstud 367646498 Mar 9 14:04 aCGT.vector_3 -rw-r--r-- 1 matstud matstud 368373958 Mar 9 14:04 aCGT.vector_4 DAYFILE cat aCGT.dayfile Calculating aCGT in /usr/local/share/wien2k/Fons/aCGT on gemini.a04.aist.go.jp with PID 45216 using WIEN2k_14.2 (Release 15/10/2014) in /home/matstud/Wien2K start (Mon Mar 9 10:27:54 JST 2015) with lapw0 (40/99 to go) cycle 1 (Mon Mar 9 10:27:55 JST 2015) (40/99 to go) lapw0 -grr -p (10:27:55) starting parallel lapw0 at Mon Mar 9 10:27:55 JST 2015 .machine0 : 12 processors 755.913u 3.546s 1:06.22 1146.8% 0+0k 184+796936io 0pf+0w lapw0 -p(10:29:01) starting parallel lapw0 at Mon Mar 9 10:29:01 JST 2015 .machine0 : 12 processors 622.223u 2.856s 0:54.57 1145.4% 0+0k 48+203264io 0pf+0w lapw1-c (10:29:56) 20873.217u 161.505s 3:01:39.31 192.9% 0+0k 14448+5913840io 0pf+0w lapw1 -p -c (13:31:36) starting parallel lapw1 at Mon Mar 9 13:31:36 JST 2015 - starting parallel LAPW1 jobs at Mon Mar 9 13:31:36 JST 2015 running LAPW1 in parallel mode (using .machines) 4 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(1) 27361.552u 625.141s 39:53.54 1169.2%0+0k 8+882304io 0pf+0w localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost
Re: [Wien] Problems with hybrid calculation
Hi I did run init_hf_lapw and I saw no sign of errors upon running it, however, I ran it from the web interface the first time. I just restarted the calculation using bash and have confirmed the ibz and fbz files exist. The reason that I am interested in hybrid mode is that I actually have 96 processors available with infiniband interconnects. Is a 96 atom system too expensive to run with PBE0 even with 96 cores? How much time should I expect such a calculation to take? Paul Fons On Mar 3, 2015, at 4:56 PM, t...@theochem.tuwien.ac.at wrote: Hi, init_hf_lapw executes run_kgenhf_lapw which creates the files case.klist_ibz, case.klist_fbz, case.kgen_ibz and case.kgen_fbz. So, I don't understand why they are not present in your directory. Are you sure that init_hf_lapw ran without problems? Beside this, I really think that you should forget about running hybrid functionals for 96 atoms, in particular with this small number of processors (unless you are willing to wait until retirement). Depending on the system/properties that you are considering, the use of a GGA functional maybe give results which are fairly reliable. F. Tran On Tue, 3 Mar 2015, Paul Fons wrote: Hi All, I am trying to calculate the density of states of a small cluster of 96 atoms. I am using the hybrid mpi/k-point mode. The calculation ran to completion without problems for PBE. My .machines file is listed below. As the cluster is amorphous and roughly cubic in shape, I used a 2x2x2 MP mesh. I then attempted to use the PBE0 hybrid functional. After using the init_hf_lapw script, I started the SCF loop. The calculation ran for several hours and then stopped. I have attached the STDOUT output below. I am using intel ifort (15) as well as the intel mpi environment. I do have a scratch directory set up on this same node. These calculations were run on a single 24 core machine. I have five of these machines connected by Infiband and would like to scale up the calculation to use several nodes if I can find and solve the hybrid problem as I am aware of the cost of the PBE0 calculations. Any advice? Best wishes, Paul Fons .machines lapw0:localhost:24 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 granularity:1 extrafine:1 STDOUT LAPW0 END LAPW0 END cp: cannot stat `aCGT.kgen_fbz': No such file or directory cp: cannot stat `aCGT.klist_fbz': No such file or directory LAPW1 END mv: cannot stat `aCGT.vector': No such file or directory cp: cannot stat `aCGT.kgen_ibz': No such file or directory cp: cannot stat `aCGT.klist_ibz': No such file or directory LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END cp: cannot stat `aCGT.kgen_fbz': No such file or directory cp: cannot stat `aCGT.klist_fbz': No such file or directory mv: cannot stat `aCGT.vectorhf_old': No such file or directory forrtl: severe (24): end-of-file during read, unit 1001, file /usr/local/share/wien2k/Fons/aCGT/031 Image PCRoutineLineSource lapw2c 00648027 Unknown Unknown Unknown lapw2c 00669FF3 Unknown Unknown Unknown lapw2c 00482FEE outp_ 180 outp.f lapw2c 004701EC l2main_ 2125 l2main_tmp_.F lapw2c 0047CEA5 MAIN__607 lapw2_tmp_.F lapw2c 0040407E Unknown Unknown Unknown libc.so.6 00343F61ED5D Unknown Unknown Unknown lapw2c 00403F89 Unknown Unknown Unknown stop error ___ 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 Dr. Paul Fons Senior Research Scientist Functional Nano-phase-change Research Team Nanoelectronics Research Institute National Institute for Advanced Industrial Science TechnologyMETI AIST Central 4, Higashi 1-1-1Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636fax. +81-298-61-2939 email: paul-f...@aist.go.jp mailto:paul-f...@aist.go.jp The following lines are in a Japanese font 〒305-8562 茨城県つくば市つくば中央東 1-1-1 産業技術総合研究所 ナノエレクトロニクス研究部門 相変化新規機能デバイス研究チーム 上級主任研究員 ポール・フォンス ___ 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] Problems with parallel hybrid functional calculation
Hi All, I am trying to run a hybrid functional calculation on a 96 atom system using PBE0. I successfully used a PBE functional using the test machines file below that is a hybrid k-point/MPI parallel job. While I posted a day ago about a failure due to missing ibz fbz files when I attempted to use the web interface, this time, I strictly used the terminal. The output is shown below. There were no problems with the fbz/ibz file generation, however, the run still terminated with an error. The error was that case.vectorhf_old was not found. I am not sure where this file show have been generated or why it was not. I expect this calculation to take some time to run and am planning on using 96-cores for the real PBE0 calculation, but at the moment, I am in troubleshooting mode. Does anyone have any idea of what might have gone wrong. I used a shifted 2x2x2 MP grid and 770 bands as I have 1536 electrons. Thanks, Paul Fons (.machines file) lapw0:localhost:24 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 #1:draco-ib:12 granularity:1 extrafine:1 TERMINAL OUTPUT mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTinit_hf_lapw :GAP : -9. Ry = -.eV ( metallic ) Bandranges (emin - emax) and occupancy: :BAN00759: 7590.3530280.368374 2. :BAN00760: 7600.3540990.369025 2. :BAN00761: 7610.3579440.370696 2. :BAN00762: 7620.3607320.374369 2. :BAN00763: 7630.3628900.377049 2. :BAN00764: 7640.3668570.378864 2. :BAN00765: 7650.3706710.382529 2. :BAN00766: 7660.3743100.386296 2. :BAN00767: 7670.3790370.388138 2. :BAN00768: 7680.3830690.392822 1.61356106 :BAN00769: 7690.3875150.396096 0.38643894 :BAN00770: 7700.3926270.399987 0. :BAN00771: 7710.3960490.406404 0. :BAN00772: 7720.3996870.414211 0. :BAN00773: 7730.4105640.422211 0. :BAN00774: 7740.4191010.430560 0. Energy to separate low and high energystates: -0.09012 :NOE : NUMBER OF ELECTRONS =1536.000 :FER : F E R M I - ENERGY(TETRAH.M.)= 0.3906577224 You must set NBAND to at least NB_occ + 1 and you have 1536.00 electrons edit aCGT.inhf … (SET NUMBER OF BANDS TO 770) PS: For very accurate calc. and large NBAND you may have to increase EMAX in aCGT.in1 by hand Prepare k-mesh for HF. Use identical mesh and shift for IBZ and FBZ Do you want to use a REDUCED k-mesh for HF (saving cpu-time) (Y/n) ? n This script runs x kgen twice and generates equivalent meshes in the IBZ and FBZ. KGEN ENDS KGEN ENDS How many k-points in full BZ? If you type 0 you can give 3 numbers for nx,ny,nz 0 How many in x? 2 How many in y? 2 How many in z? 2 Do you want to shift? (yes=1, no=0) 1 1 symmetry operations without inversion inversion added (non-spinpolarized non-so calculation) NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G) length of reciprocal lattice vectors: 0.246 0.245 0.247 0.000 0.000 0.000 Specify 3 mesh-divisions (n1,n2,n3): Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift) 4 k-points generated, ndiv= 2 2 2 KGEN ENDS 0.002u 0.008s 0:00.07 0.0% 0+0k 24+128io 0pf+0w 1 symmetry operations without inversion NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G) length of reciprocal lattice vectors: 0.246 0.245 0.247 0.000 0.000 0.000 Specify 3 mesh-divisions (n1,n2,n3): Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift) 8 k-points generated, ndiv= 2 2 2 KGEN ENDS 0.000u 0.008s 0:00.39 0.0% 0+0k 72+40io 0pf+0w aCGT.in0_grr and aCGT.inhf and hf-kmesh prepared Now do the hybrid calculation: run_lapw -hf ... mats...@gemini.a04.aist.go.jp:/usr/local/share/wien2k/Fons/aCGTrun_lapw -hf -p LAPW0 END LAPW0 END LAPW1 END mv: cannot stat `aCGT.vector': No such file or directory LAPW1 END LAPW1 END LAPW1 END LAPW1 END mv: cannot stat `aCGT.vectorhf_old': No such file or directory forrtl: severe (24): end-of-file during read, unit 1001, file /usr/local/share/wien2k/Fons/aCGT/031 Image PCRoutineLineSource lapw2c 00648027 Unknown Unknown Unknown lapw2c 00669FF3 Unknown Unknown Unknown lapw2c 00482FEE outp_ 180 outp.f lapw2c 004701EC l2main_ 2125 l2main_tmp_.F lapw2c 0047CEA5 MAIN__607 lapw2_tmp_.F lapw2c
[Wien] Problems with hybrid calculation
Hi All, I am trying to calculate the density of states of a small cluster of 96 atoms. I am using the hybrid mpi/k-point mode. The calculation ran to completion without problems for PBE. My .machines file is listed below. As the cluster is amorphous and roughly cubic in shape, I used a 2x2x2 MP mesh. I then attempted to use the PBE0 hybrid functional. After using the init_hf_lapw script, I started the SCF loop. The calculation ran for several hours and then stopped. I have attached the STDOUT output below. I am using intel ifort (15) as well as the intel mpi environment. I do have a scratch directory set up on this same node. These calculations were run on a single 24 core machine. I have five of these machines connected by Infiband and would like to scale up the calculation to use several nodes if I can find and solve the hybrid problem as I am aware of the cost of the PBE0 calculations. Any advice? Best wishes, Paul Fons .machines lapw0:localhost:24 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 1:localhost:2 granularity:1 extrafine:1 STDOUT LAPW0 END LAPW0 END cp: cannot stat `aCGT.kgen_fbz': No such file or directory cp: cannot stat `aCGT.klist_fbz': No such file or directory LAPW1 END mv: cannot stat `aCGT.vector': No such file or directory cp: cannot stat `aCGT.kgen_ibz': No such file or directory cp: cannot stat `aCGT.klist_ibz': No such file or directory LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END cp: cannot stat `aCGT.kgen_fbz': No such file or directory cp: cannot stat `aCGT.klist_fbz': No such file or directory mv: cannot stat `aCGT.vectorhf_old': No such file or directory forrtl: severe (24): end-of-file during read, unit 1001, file /usr/local/share/wien2k/Fons/aCGT/031 Image PCRoutineLineSource lapw2c 00648027 Unknown Unknown Unknown lapw2c 00669FF3 Unknown Unknown Unknown lapw2c 00482FEE outp_ 180 outp.f lapw2c 004701EC l2main_ 2125 l2main_tmp_.F lapw2c 0047CEA5 MAIN__607 lapw2_tmp_.F lapw2c 0040407E Unknown Unknown Unknown libc.so.6 00343F61ED5D Unknown Unknown Unknown lapw2c 00403F89 Unknown Unknown Unknown stop error___ 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] QTL-B error for Zn K-edge ELNES
Dear Peter, Hello from Japan. Thank you very much for your comment. I have always employed supercells, but the sign of the compensating charge was more subtle. In truth, for the MgO supercell example, I tried both -1 and +1 in case.inm, but I didn't see much different in the XSPEC spectra. Paul On Aug 27, 2014, at 16:11, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: About core-hole calculations for XSPEC or TELNES: 1) You need to make a sizable supercell !!! Maybe start with 16 atoms/cell, but 64 or more are even better. It is WRONG to make a core-hole calculation with just 2 Zn atoms/cell. Why: Consider reality: You excite only VERY few atoms in such a measurements (actually VERY few even means 1 out of 10^10 or less!!!), the majority of atoms remain in the ground state and can contribute to the screening. This is, what we want to simulate. 2) We need to have charge neutrality, i.e. the sum of nuclear charges and electronic charges must cancel. By removing 1 e- from one atom in the cell, you need to add this charge somewhere. 2 possibilities: a) add it as valence electron (increase NE in case.in2; but don't forget to remove this e- AFTER the scf cycle and before calculation the spectra) b) add a background charge in case.inm. MSR1 -1.0 YES (BROYD/PRATT, extra charge (+1 for additional e), norm) As the comment says, you should set this value to +1, when you have added an e-. For core holes, we have REMOVED an electron, thus we must set this to -1.0 !!! You SHOULD ALWAYS CHECK your charge neutrality using grep :NEC01 case.scf. Now which method is better, a) or b) ??? In many cases there is NOT much difference, though in some cases there could be a difference. Again, remember we want to simulate experiment as close as possible: the Zn 1s electron will be excited (dipole rule) into Zn-4p electrons. The electronic structure of ZnO has mainly Zn-s and p character at the conduction band minimum, thus when we use method b), we actually add this e- into Zn-s+p states, which is approximately correct. However, since the Zn-4sp states are very delocalized states with little weight inside the Zn-sphere, I don't think it matters too much when you put the charge into the background. An opposite example would be eg. CeO2, which has very localized Ce-4f states just above EF. When simulating O-K edges, it is NOT a good idea to add the e- into the valence, because it will go into LOCALIZED Ce-4f states and not contribute significantly to screen the core-hole on oxygen. The method b) would be better in this case. Of course, for Ce-M edges obviously method a) should be much better. Hope this clarifies the unclear discussion on the mailing list. Peter Blaha --- Subject: Re: [Wien] QTL-B error for Zn K-edge ELNES From: Paul Fons paul-f...@aist.go.jp Date: 08/27/2014 06:37 AM To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Hi Kevin, Are you sure you are correct for using -1 in case.inm. I can reproduce the example from the Wien2K course (MgO supercell) just fine when I use a +1 in case.inm. The documentation states that 1 adds another electron. From what I understand this is to compensate for the electron that is removed when a core hole is generated by changing the occupancy in case.inc. For the case of MgO.inc 1 0.00 0 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT, IPRINT 1,-1,2 ( N,KAPPA,OCCUP) 1 0.00 0 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT, IPRINT 1,-1,2 ( N,KAPPA,OCCUP) 1 0.00 0 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT, IPRINT 1,-1,2 ( N,KAPPA,OCCUP) 1 0.00 0 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT, IPRINT 1,-1,2 ( N,KAPPA,OCCUP) 1 0.00 0 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT, IPRINT 1,-1,2 ( N,KAPPA,OCCUP) 0 I changed the second line to 1,-1,1 to make a core hole. I then compensated for the missing charge with case.inm to add a +1 background charge via MSR1 1.0 YES (BROYD/PRATT, extra charge (+1 for additional e), norm) 0.20mixing FACTOR for BROYD/PRATT scheme 1.00 1.00 PW and CLM-scaling factors 8 idum, HISTORY After this, I run a SCF calculation. When it is done, I then remove the charge from case.inm and carry out a XSPEC calculation. This is what I learned in the Wien2K course a couple of years ago when the developers had a seminar here in Japan. As I mentioned, the above procedure reproduces the MgO core hole present plot in the exercise notes. I would be very much interested in hearing if I am doing something incorrect. Cheers, Paul -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1
Re: [Wien] Parity determination by group theory analysis question
Hi, Thank you for your note. I am most grateful for some help on the group theory question as there seem to be very few people in general who answer such questions. I should have mentioned I realize in retrospect that the calculation was carried out with spin-orbit coupling. The degeneracy in the spin is presumably due to the presence of inversion symmetry in the crystal structure (the crystal structure does have inversion symmetry). Would it be fair to conclude that this is a case of accidental degeneracy and that there are two sets of states (GM5+ + GM6+) and (GM5- + GM6-) and that the two pairs of states have parity 1 and -1 respectively? Best wishes, Paul On Jun 4, 2014, at 18:08, Juan Manuel Perez Mato wmppe...@lg.ehu.es wrote: Hi, (GM5+ + GM6+ ) and (GM5- + GM6-) form two different physically irreducible representations of even and odd parity of D3d (as double group). Therefore the degeneracy of the bands corresponding to these two physically irreps is not forced by symmetry. Consequently the four-fold degeneracy of the band most probably comes from not considering the spin. I would bet that it will disappear if spin orbit coupling is introduced, and they will then split into two separate two-fold degenerate bands associated with the two different physically irreducible representations of different parity. regards, J. Manuel Perez-Mato Fac. Ciencia y Tecnologia, Universidad del Pais Vasco, UPV 48080 BILBAO, Spain tel. +34 946012473 fax. +34 946013500 *** El 04/06/2014, a las 09:29, Paul Fons escribió: Hi, I have been using the irreducible representations calculated by irrep to determine the parity of the wavefunction for particular k-points for each band. A typical case is shown below for the gamma point.As I am solving the system without spin, each band is at least two-fold degenerate. For most bands, for example the first band, the situation is clear as the irrep is G4+ that the parity is +. This also follows from the character of the (I) class being the same dimension as the irrep. I am a little more confused by what to do a band such as band 9 where there are two irreps spanning the same band, but presumably as the character of the (I) class is the same as that of the dimension of the irrep (and that both irreps are of the same parity, +) that the parity is again +. The situation I am writing to ask about, however is that of band 63 which is four-fold degenerate and is composed of irreps of both parities. How does one interpret the parity from the information below for band 63? Thanks for any advice. The point group is D3d 12 symmetry operations in 6 classes Table 55 on page 58 in Koster et al [7] Table 42.4 on page 371 in Altmann et al [8] E 2C3 3C2 I 2IC3 3IC2 G1+ A1g 1 1 1 1 1 1 G2+ A2g 1 1-1 1 1-1 G3+ Eg2-1 0 2-1 0 G1- A1u 1 1 1-1-1-1 G2- A2u 1 1-1-1-1 1 G3- Eu2-1 0-2 1 0 G4+ E1/2g 2 1 0 2 1 0 G5+ 1E3/2g 1-1 i 1-1 i G6+ 2E3/2g 1-1-i 1-1-i G4- E1/2u 2 1 0-2-1 0 G5- 1E3/2u 1-1 i-1 1-i G6- 2E3/2u 1-1-i-1 1 i class, symmetry ops, exp(-i*k*taui) E 10 (+1.00+0.00i) 2C32 7 (+1.00+0.00i) 3C21 8 9 (+1.00+0.00i) I3 (+1.00+0.00i) 2IC36 11 (+1.00+0.00i) 3IC24 5 12 (+1.00+0.00i) bnd ndg eigval E 2C3 3C2 I2IC3 3IC2 1 2 -7.239676 2.00+0.00i 1.00+0.00i 0.00-0.00i 2.00+0.00i 1.00-0.00i 0.00-0.00i =G4+ 3 2 -7.239533 2.00+0.00i 1.00+0.00i -0.00+0.00i -2.00+0.00i -1.00-0.00i 0.00-0.00i =G4- 5 2 -6.641446 2.00+0.00i 1.00+0.00i 0.00+0.00i 2.00-0.00i 1.00+0.00i 0.00+0.00i =G4+ 7 2 -6.641393 2.00-0.00i 1.00-0.00i -0.00-0.00i -2.00-0.00i -1.00+0.00i 0.00-0.00i =G4- 9 2 -6.641277 2.00+0.00i -2.00-0.00i -0.00+0.00i 2.00+0.00i -2.00-0.00i -0.00-0.00i =G5+ + G6+ 63 4 -1.880979 4.00-0.00i -4.00+0.00i 0.00-0.00i 0.00-0.00i -0.00+0.00i -0.00+0.00i =G5+ + G6+ + G5- + G6- ___ 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] Parity determination by group theory analysis question
Hi, I have been using the irreducible representations calculated by irrep to determine the parity of the wavefunction for particular k-points for each band. A typical case is shown below for the gamma point.As I am solving the system without spin, each band is at least two-fold degenerate. For most bands, for example the first band, the situation is clear as the irrep is G4+ that the parity is +. This also follows from the character of the (I) class being the same dimension as the irrep. I am a little more confused by what to do a band such as band 9 where there are two irreps spanning the same band, but presumably as the character of the (I) class is the same as that of the dimension of the irrep (and that both irreps are of the same parity, +) that the parity is again +. The situation I am writing to ask about, however is that of band 63 which is four-fold degenerate and is composed of irreps of both parities. How does one interpret the parity from the information below for band 63? Thanks for any advice. The point group is D3d 12 symmetry operations in 6 classes Table 55 on page 58 in Koster et al [7] Table 42.4 on page 371 in Altmann et al [8] E 2C3 3C2 I 2IC3 3IC2 G1+ A1g 1 1 1 1 1 1 G2+ A2g 1 1-1 1 1-1 G3+ Eg2-1 0 2-1 0 G1- A1u 1 1 1-1-1-1 G2- A2u 1 1-1-1-1 1 G3- Eu2-1 0-2 1 0 G4+ E1/2g 2 1 0 2 1 0 G5+ 1E3/2g 1-1 i 1-1 i G6+ 2E3/2g 1-1-i 1-1-i G4- E1/2u 2 1 0-2-1 0 G5- 1E3/2u 1-1 i-1 1-i G6- 2E3/2u 1-1-i-1 1 i class, symmetry ops, exp(-i*k*taui) E 10 (+1.00+0.00i) 2C32 7 (+1.00+0.00i) 3C21 8 9 (+1.00+0.00i) I3 (+1.00+0.00i) 2IC36 11 (+1.00+0.00i) 3IC24 5 12 (+1.00+0.00i) bnd ndg eigval E 2C3 3C2 I2IC3 3IC2 1 2 -7.239676 2.00+0.00i 1.00+0.00i 0.00-0.00i 2.00+0.00i 1.00-0.00i 0.00-0.00i =G4+ 3 2 -7.239533 2.00+0.00i 1.00+0.00i -0.00+0.00i -2.00+0.00i -1.00-0.00i 0.00-0.00i =G4- 5 2 -6.641446 2.00+0.00i 1.00+0.00i 0.00+0.00i 2.00-0.00i 1.00+0.00i 0.00+0.00i =G4+ 7 2 -6.641393 2.00-0.00i 1.00-0.00i -0.00-0.00i -2.00-0.00i -1.00+0.00i 0.00-0.00i =G4- 9 2 -6.641277 2.00+0.00i -2.00-0.00i -0.00+0.00i 2.00+0.00i -2.00-0.00i -0.00-0.00i =G5+ + G6+ 63 4 -1.880979 4.00-0.00i -4.00+0.00i 0.00-0.00i 0.00-0.00i -0.00+0.00i -0.00+0.00i =G5+ + G6+ + G5- + G6- ___ 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] Problems with mpi for Wien12.1
I compiled fftw3 using the Intel suite as well. The appropriate line from config.log reads ./configure CC=icc F77=ifort MPICC=mpiicc --prefix=/opt/local --enable-mpi --enable-threads --prefix=/opt/local/fftw3 I note that the configuration file only calls for a mpicc compiler (and I used the Intel compiler) and not a fortran compiler. The compiled code (mpi-bench does work fine with the Intel mpirun). After commenting out the call W2kinit subroutine and recompiling lapw0 (via the siteconfig script), I attempted to run run_lapw in both serial and parallel forms as you can see below. The serial form worked fine Paul matstud at ursa:~/WienDisk/Fons/GaAs run_lapw LAPW0 END LAPW1 END LAPW2 END CORE END MIXER END ec cc and fc_conv 1 1 1 stop matstud at ursa:~/WienDisk/Fons/GaAs run_lapw -p forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred forrtl: severe (174): SIGSEGV, segmentation fault occurred stop error On Aug 28, 2012, at 9:16 AM, Laurence Marks wrote: One suggestion: comment out the line towards the top of lapw0.F call W2kinit You should get a more human readable error message. As an addendum, was fftw3 compiled with mpiifort? I assume from your email that it was, just checking. N.B., there is a small chance that this will hang your computer. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien Dr. Paul Fons Senior Research Scientist Functional Nano-phase-change Research Team Nanoelectronics Research Institute National Institute for Advanced Industrial Science Technology METI AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons at aist.go.jp The following lines are in a Japanese font ?305-8562 ? 1-1-1 ? ?? ? -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120829/98a836c2/attachment.htm
[Wien] Problems with mpi for Wien12.1
if it points to the proper
directory/version of mpi,
Am 24.08.2012 15:35, schrieb Laurence Marks:
In my experience the SIGSEV normally comes from mixing different flavors of
mpif90 and mpirun. Openmpi, mpich2 and Intels mpi all need different
versions of blacs. You can also
have problems if you choose the wrong model for integers in the linking
advisor page. I would check using ldd that lapw0_mpi is linked to the right
version, and that the default
versions are correct (e.g. which mpirun). Often you can minimize problems by
using static linking for mpi.
N.B. The contact developers message is a relic of when some code was added
for fault handlers and to eliminate issues with limits that used to be
pervasive. It should probably
be removed.
---
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu http://www.numis.northwestern.edu 1-847-491-3996
Research is to see what everybody else has seen, and to think what nobody
else has thought
Albert Szent-Gyorgi
On Aug 24, 2012 8:22 AM, Paul Fons paul-fons at aist.go.jp
mailto:paul-fons at aist.go.jp wrote:
Dear Prof. Blaha,
Thank you for your earlier email. Running the command manually gives the
following output (for a GaAs structure that works fine in serial or k-point
parallel form). I am
still not sure what to try next. Any suggestions?
matstud at ursa:~/WienDisk/Fons/GaAs mpirun -np 4 ${WIENROOT}/lapw0_mpi
lapw0.def
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
Child id 0 SIGSEGV, contact developers
Child id 1 SIGSEGV, contact developers
Child id 3 SIGSEGV, contact developers
Child id 2 SIGSEGV, contact developers
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 3
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 2
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 1
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
APPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1)
The MPI compilation options from siteconfig are as follows: (the settings
are from the Intel MKL link advisor plus the fftw3 library)
Current settings:
RP RP_LIB(SCALAPACK+PBLAS): -L$(MKLROOT)/lib/intel64
$(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a
$(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a -lmkl_scalapack_lp64
-lmkl_cdft_core -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
-lmkl_blacs_intelmpi_lp64 -openmp -lpthread -lm -L/opt/local/fftw3/lib/
-lfftw3_mpi -lfftw3 $(R_LIBS)
FP FPOPT(par.comp.options): -I$(MKLROOT)/include/intel64/lp64
-I$(MKLROOT)/include -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
-DFFTW3 -traceback
MP MPIRUN commando: mpirun -np _NP_ -machinefile _HOSTS_
_EXEC_
The file parallel_options now reads
setenv USE_REMOTE 1
setenv MPI_REMOTE 0
setenv WIEN_GRANULARITY 1
setenv WIEN_MPIRUN mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
I changed the MPI_REMOTE to 0 as suggested (I was not sure this applied
to the Intel MPI environment as the siteconfig prompt only mentioned mich2.
As I mentioned the mpirun command seems to work fine. For example, the
fftw3 benchmark program gives with 24 processes
mpirun -np 24 ./mpi-bench 1024x1024
Problem: 1024x1024, setup: 126.32 ms, time: 15.98 ms, ``mflops'': 6562.2
On Aug 24, 2012, at 3:05 PM, Peter Blaha wrote:
Hard to say.
What is in $WIENROOT/parallel_options ?
MPI_REMOTE should be 0 !
Otherwise run lapw0_mpi by hand:
mpirun -np 4 $WIENROOT/lapw0_mpi lapw0.def (or including .machinefile
.machine0)
Am 24.08.2012 02:24, schrieb Paul Fons:
Greetings all,
I have compiled Wien2K 12.1 under OpenSuse 11.4 (and OpenSuse 12.1)
and the latest Intel compilers with identical mpi launch problems and I
am hoping for some suggestions as to where to look to fix things. Note
that the serial and k-point parallel versions of the code run fine (I
have optimized GaAs a lot in my troubleshooting!).
Environment.
I am using the latest intel fort, icc, and impi libraries for linux.
matstud at pyxis:~/Wien2K ifort --version
ifort (IFORT) 12.1.5 20120612
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
matstud at pyxis:~/Wien2K mpirun --version
Intel(R) MPI Library for Linux* OS, Version 4.0 Update 3 Build 20110824
Copyright (C) 2003-2011, Intel Corporation. All rights reserved.
matstud at pyxis:~/Wien2K icc --version
icc (ICC) 12.1.5 20120612
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
My OPTIONS files
[Wien] Problems with mpi for Wien12.1
Greetings all, I have compiled Wien2K 12.1 under OpenSuse 11.4 (and OpenSuse 12.1) and the latest Intel compilers with identical mpi launch problems and I am hoping for some suggestions as to where to look to fix things. Note that the serial and k-point parallel versions of the code run fine (I have optimized GaAs a lot in my troubleshooting!). Environment. I am using the latest intel fort, icc, and impi libraries for linux. matstud at pyxis:~/Wien2K ifort --version ifort (IFORT) 12.1.5 20120612 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. matstud at pyxis:~/Wien2K mpirun --version Intel(R) MPI Library for Linux* OS, Version 4.0 Update 3 Build 20110824 Copyright (C) 2003-2011, Intel Corporation. All rights reserved. matstud at pyxis:~/Wien2K icc --version icc (ICC) 12.1.5 20120612 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. My OPTIONS files from /siteconfig_lapw current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback current:FPOPT:-I$(MKLROOT)/include/intel64/lp64 -I$(MKLROOT)/include -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3 -traceback current:LDFLAGS:$(FOPT) -L$(MKLROOT)/lib/$(MKL_TARGET_ARCH) -pthread current:DPARALLEL:'-DParallel' current:R_LIBS:-lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread current:RP_LIBS:-L$(MKLROOT)/lib/intel64 $(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a $(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a -lmkl_scalapack_lp64 -lmkl_cdft_core -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_intelmpi_lp64 -openmp -lpthread -lm -L/opt/local/fftw3/lib/ -lfftw3_mpi -lfftw3 $(R_LIBS) current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ The code compiles and links without error. It runs fine in serial mode and in k-point parallel mode, e.g. .machines with 1:localhost 1:localhost 1:localhost granularity:1 extrafine:1 This runs fine. When I attempt to run a mpi process with 12 processes (on a 12 core machine), I crash and burn (see below) with a SIGSEV error with instructions to contact the developers. The linking options were derived from Intel's mkl link advisor (the version on the intel site. I should add that the mpi-bench in fftw3 works fine using the intel mpi as do commands like hostname or even abinit so it would appear that that the Intel MPI environment itself is fine. I have wasted a lot of time trying to figure out how to fix this before writing to the list, but at this point, I feel like a monkey at a keyboard attempting to duplicate Shakesphere -- if you know what I mean. Thanks in advance for any heads up that you can offer. .machines lapw0:localhost:12 1:localhost:12 granularity:1 extrafine:1 stop error error: command /home/matstud/Wien2K/lapw0para -c lapw0.def failed 0.029u 0.046s 0:00.93 6.4% 0+0k 0+176io 0pf+0w Child id 2 SIGSEGV, contact developers Child id 8 SIGSEGV, contact developers Child id 7 SIGSEGV, contact developers Child id 11 SIGSEGV, contact developers Child id 10 SIGSEGV, contact developers Child id 9 SIGSEGV, contact developers Child id 6 SIGSEGV, contact developers Child id 5 SIGSEGV, contact developers Child id 4 SIGSEGV, contact developers Child id 3 SIGSEGV, contact developers Child id 1 SIGSEGV, contact developers Child id 0 SIGSEGV, contact developers .machine0 : 12 processors lapw0 -p(09:04:45) starting parallel lapw0 at Fri Aug 24 09:04:45 JST 2012 cycle 1 (Fri Aug 24 09:04:45 JST 2012) (40/99 to go) start (Fri Aug 24 09:04:45 JST 2012) with lapw0 (40/99 to go) using WIEN2k_12.1 (Release 22/7/2012) in /home/matstud/Wien2K on pyxis with PID 15375 Calculating GaAs in /usr/local/share/Wien2K/Fons/GaAs -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120824/1d183071/attachment.htm
[Wien] Problems with mpi for Wien12.1
Dear Prof. Blaha,
Thank you for your earlier email. Running the command manually gives the
following output (for a GaAs structure that works fine in serial or k-point
parallel form). I am still not sure what to try next. Any suggestions?
matstud at ursa:~/WienDisk/Fons/GaAs mpirun -np 4 ${WIENROOT}/lapw0_mpi
lapw0.def
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
w2k_dispatch_signal(): received: Segmentation fault
Child id 0 SIGSEGV, contact developers
Child id 1 SIGSEGV, contact developers
Child id 3 SIGSEGV, contact developers
Child id 2 SIGSEGV, contact developers
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 3
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 2
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 1
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
APPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1)
The MPI compilation options from siteconfig are as follows: (the settings are
from the Intel MKL link advisor plus the fftw3 library)
Current settings:
RP RP_LIB(SCALAPACK+PBLAS): -L$(MKLROOT)/lib/intel64
$(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a
$(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a -lmkl_scalapack_lp64
-lmkl_cdft_core -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
-lmkl_blacs_intelmpi_lp64 -openmp -lpthread -lm -L/opt/local/fftw3/lib/
-lfftw3_mpi -lfftw3 $(R_LIBS)
FP FPOPT(par.comp.options): -I$(MKLROOT)/include/intel64/lp64
-I$(MKLROOT)/include -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3
-traceback
MP MPIRUN commando: mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
The file parallel_options now reads
setenv USE_REMOTE 1
setenv MPI_REMOTE 0
setenv WIEN_GRANULARITY 1
setenv WIEN_MPIRUN mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
I changed the MPI_REMOTE to 0 as suggested (I was not sure this applied to the
Intel MPI environment as the siteconfig prompt only mentioned mich2.
As I mentioned the mpirun command seems to work fine. For example, the fftw3
benchmark program gives with 24 processes
mpirun -np 24 ./mpi-bench 1024x1024
Problem: 1024x1024, setup: 126.32 ms, time: 15.98 ms, ``mflops'': 6562.2
On Aug 24, 2012, at 3:05 PM, Peter Blaha wrote:
Hard to say.
What is in $WIENROOT/parallel_options ?
MPI_REMOTE should be 0 !
Otherwise run lapw0_mpi by hand:
mpirun -np 4 $WIENROOT/lapw0_mpi lapw0.def (or including .machinefile
.machine0)
Am 24.08.2012 02:24, schrieb Paul Fons:
Greetings all,
I have compiled Wien2K 12.1 under OpenSuse 11.4 (and OpenSuse 12.1)
and the latest Intel compilers with identical mpi launch problems and I
am hoping for some suggestions as to where to look to fix things. Note
that the serial and k-point parallel versions of the code run fine (I
have optimized GaAs a lot in my troubleshooting!).
Environment.
I am using the latest intel fort, icc, and impi libraries for linux.
matstud at pyxis:~/Wien2K ifort --version
ifort (IFORT) 12.1.5 20120612
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
matstud at pyxis:~/Wien2K mpirun --version
Intel(R) MPI Library for Linux* OS, Version 4.0 Update 3 Build 20110824
Copyright (C) 2003-2011, Intel Corporation. All rights reserved.
matstud at pyxis:~/Wien2K icc --version
icc (ICC) 12.1.5 20120612
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
My OPTIONS files from /siteconfig_lapw
current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
current:FPOPT:-I$(MKLROOT)/include/intel64/lp64 -I$(MKLROOT)/include -FR
-mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3 -traceback
current:LDFLAGS:$(FOPT) -L$(MKLROOT)/lib/$(MKL_TARGET_ARCH) -pthread
current:DPARALLEL:'-DParallel'
current:R_LIBS:-lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
-lmkl_core -openmp -lpthread
current:RP_LIBS:-L$(MKLROOT)/lib/intel64
$(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a
$(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a -lmkl_scalapack_lp64
-lmkl_cdft_core -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
-lmkl_blacs_intelmpi_lp64 -openmp -lpthread -lm -L/opt/local/fftw3/lib/
-lfftw3_mpi -lfftw3 $(R_LIBS)
current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
The code compiles and links without error. It runs fine in serial mode
and in k-point parallel mode, e.g.
.machines with
1:localhost
1:localhost
1:localhost
granularity:1
extrafine:1
This runs fine. When I attempt to run a mpi process with 12 processes
(on a 12 core machine), I crash and burn (see below) with a SIGSEV error
with instructions to contact the developers.
The linking options were derived from Intel's mkl link advisor (the
version on the intel site. I should add that the mpi-bench in fftw3
works fine using the intel mpi as do commands like hostname or even
abinit
[Wien] Electric Field Effects
Thank you for your quick help with my electric field question. I have a couple of other related questions that I am still puzzled about. The first question is the applicability of the Berry phase approach. From what I understand, the Berry phase approach is usually couched within the density functional perturbation theory paradigm, e.g. in the limit of small E fields. In fact, in the paper you co-authored with Stahn [PRB v63, 165205 (2001)] you actually mentioned the Berry Phase. For a quantum-mechanical description of 'polarization in a crystal' a geometrical Berry's phase approach as been introduced in recent years. Unfortunately, this approach is only valid if there is no external electric field in the crystal, which means that the surfaces of the crystal are short circuited. As the fields we are interested in are fairly large (a factor of ten below the dielectric breakdown voltage), I was not confident about the applicability of a perturbative Berry's phase approach. It was for this reason, I thought that your supercell approach (with the introduction of a vacuum slab at the kink and the fixing of the end atoms to prevent surface relaxation) would be a good approach that could be used even for moderately strong fields (0.01-0.1 V/Angstrom = 0.2-2 mRy). I also noted that in the same paper above, it was stated that calculations at artificially larger fields were necessary to ensure enough numerical precision. In the paper values of 200 times the experimental field values were used (e.g. 1400 kV/mm = 14 V/Angstrom = 2 mRy) to ensure that there was enough numerical precision in the answer as for numerical reasons, the accuracy of the calculated potential Vint is of the order of the maximum potential applied. Is this still the case for the latest revision of the Wien code (Wien12)? Let me close, by thanking you again for your time. I hope my questions are not too naive and can help others as well. I hope to see you in Tokyo next month. Best Wishes, Paul Fons On Aug 6, 2012, at 11:59 PM, Peter Blaha wrote: It depends a bit on what you are looking for. We were interested in GaAs and the relative change of positions of Ga and As atoms under the E-filed. For this question such large cells are necessary, because in this setup we had 2 kinks and the relaxations near the kink are very much influenced by them. In fact, nowadays I would do it differently, namely exactly as you have in mind: In a slab geometry (surface) one can make this kink in the vacuum region and we have now even asymmetric fields, so that you can put the strong variation into the vacuum. In any case, as far as I remember it was a tedious work. Better approaches are now done using a Berry-phase method and as far as I know, Oleg Rubel (rubelo at tbh.net) has such an approach programmed into WIEN2k. Am 06.08.2012 16:38, schrieb Paul Fons: Hi All, I have been studying the work of Stahn, Pietsch, Blaha, and Schwartz on electric field induced charge density variations (in GaAs) [PRB v63, 165205 (2001). I had a couple of quick questions. In the paper a large (22 formula units) of GaAs is used and the field is inverted halfway across the cell in the z-direction (e.g. to maintain the periodic boundary conditions). I am curious to know if such a large number of repeats is necessary or is it simply necessary to have the field applied over a minimum spatial length. First, what is the case for GaAs, can the number of repeats be varied without large changes in the result? The second question has more to do with the sort of systems I wish to calculate E-field-induced effects upon. They are already quite large in size with about 20 layers in a supercell and I would like to avoid making the cell unnecessarily large. Would it make sense to make a vacuum layer between two units cells (and leave the electrostatic inflection! po int there). I assume I would have to fix the positions of the atoms at the end of the cell next to the vacuum layer if I did this. Does this make sense? Any advice on what cell sizes would be appropriate would be gratefully received. Paul Fons ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at
[Wien] Spin Texture
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011). They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands, however, I am unsure how to go about calculating the expectation values for the spin in reciprocal space. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. Paul Fons -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120806/4e5f5e43/attachment.htm
[Wien] Electric Field Effects
Hi All, I have been studying the work of Stahn, Pietsch, Blaha, and Schwartz on electric field induced charge density variations (in GaAs) [PRB v63, 165205 (2001). I had a couple of quick questions. In the paper a large (22 formula units) of GaAs is used and the field is inverted halfway across the cell in the z-direction (e.g. to maintain the periodic boundary conditions). I am curious to know if such a large number of repeats is necessary or is it simply necessary to have the field applied over a minimum spatial length. First, what is the case for GaAs, can the number of repeats be varied without large changes in the result? The second question has more to do with the sort of systems I wish to calculate E-field-induced effects upon. They are already quite large in size with about 20 layers in a supercell and I would like to avoid making the cell unnecessarily large. Would it make sense to make a vacuum layer between two units cells (and leave the electrostatic inflection point there). I assume I would have to fix the positions of the atoms at the end of the cell next to the vacuum layer if I did this. Does this make sense? Any advice on what cell sizes would be appropriate would be gratefully received. Paul Fons
[Wien] Spin texture in reciprocal space
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011) on Bi2T3. They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands so so-far so good. However, I am unsure how to go about calculating the expectation values for the spin in reciprocal space, e.g. what is called spin texture (I must admit I have some additional questions about quantization axes as well due to the lack of commutation among Sx, Sy, and Sz. The plot of the spin texture in the paper showed for the 2D projected surface state, a ring of arrows following a locus of points described by a circle -- e.g. it demonstrated that the spin was helical. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space and only within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120803/3da166f7/attachment.htm
[Wien] Spin texture in reciprocal space
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011). They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands, however, I am unsure how to go about calculating the expectation values for the spin in reciprocal space. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120803/2c89230b/attachment.htm
[Wien] Spin texture in reciprocal space
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011). They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands, however, I am unsure how to go about calculating the expectation values for the spin in reciprocal space. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. Paul Fons -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120802/ea4b0d94/attachment.htm
[Wien] Spin texture in reciprocal space
Dear All, I am trying to reproduce the results of some spin texture calculations on topological insulators in the literature, specifically the work of Basak et al in PRB84, 121401 (2011). They calculated the spin texture (the helical nature) of the in-plane spin components in reciprocal space at the Fermi level (surface) using Wien2K. I have reproduced the slab calculations and can see the surface bands, however, I am unsure how to go about calculating the expectation values for the spin in reciprocal space. I did note the presence of a density matrix routine LAPWDM in section 7.7 of the user guide which allows for the calculation of expectation values including spin, but only apparently in real space within the atomic spheres. Any guidance as to how to go about calculating a spin texture map (e.g. the projected spin direction on the 2D fermi surface in reciprocal space of the above topologically insulating structure) would be greatly appreciated. I have surveyed the literature, but there are no details of how the spin texture maps were calculated in any of the papers I have read. Thanks for any help in advance. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120801/54359b85/attachment.htm
[Wien] Run Wien2k on Mac OS X Lion
The HFS+ file system is historically case insensitive. There is an option in Disk Utility to format a disk with a case sensitive file system (e.g. a traditional unix-like style).While this will not cause any problems for the operating system, it could in principle cause problems for other Mac software in that some developers may assume that case differences are indistinguishable, however, they will be distinguishable for the case sensitive system. Best Wishes, Paul Fons On Jun 2, 2012, at 11:28 PM, Marcelo Barbosa wrote: Hi Gilles Sorry for such a late late response. How can i format the disk with case sensitive option? Mine doesn't seem to be, because doing cd Desktop and cd desktop is exactly the same thing. As far as i know, Macs usually use .profile instead of .bashrc (at least the later ones), however i created a .bashrc file and i call it from .profile. Can this complicate anything? Cheers, Marcelo On Apr 4, 2012, at 6:20 AM, Gilles Hug wrote: Dear Marcelo, I have Wien2k running on the Mac although I don't use it very often. I have not installed Lion. You should first check that the disk is formatted with case sensitive (Unix-like) option. Then try the Wien2k programs and scripts from the Terminal. One problem maybe to find the runtime libraries which are located in a different place compared to other Linux styles, i. e. you need to check that the environment variables in the .bashrc are correct. This changes from versions of OSX and Intel. Bon courage, Gllles Le 4 avr. 2012 ? 06:58, Peter Blaha a ?crit : I've no experience with Macs myself, but I know that some Mac-experts have wien2k running on Macs. When you say, the scripts are not working, you may not have a csh (or tcsh). Am 03.04.2012 13:10, schrieb Marcelo Barbosa: Hello I'm currently using Wien2k on an Ubuntu machine and it's working fine, but i would like to run it on Mac OS X 10.7 Lion. Is there anyone who could help me to compile and run Wien2k on a Mac OS X machine? I have installed the Intel compilers for mac and the compilation runs without any errors. I run w2web on terminal and it starts a session with no problem, but then on the browser i'm only able to create the .struct file, none of the scripts are working (including the RMT calculation when creating the .struct file). Can anyone help me? Best regards, Marcelo Barbosa ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien Dr. Paul Fons Senior Research Scientist Functional Nano-phase-change Research Team Nanoelectronics Research Institute National Institute for Advanced Industrial Science Technology METI AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons at aist.go.jp The following lines are in a Japanese font ?305-8562 ? 1-1-1 ? ?? ? -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120604/8e338f46/attachment.htm
[Wien] MPI Problem
Hi,
I have Wien2K running on a cluster of linux boxes each with 32 cores
and connected by 10Gb ethernet. I have compiled Wien2K by the 3.174 version of
Wien2K (I learned the hard way that bugs in the newer versions of the Intel
compiler lead to crashes in Wien2K). I have also installed Intel's MPI.
First, the single process Wien2K, let's say for the TiC case, works fine. It
also works fine when I use a .machines file like
granulaity:1
localhost:1
localhost:1
? (24 times).
This file leads to parallel execution without error. I can vary the number of
processes by increasing the number of localhost:1 and the number of localhost:1
lines in the file and still everything works fine. When I try to use mpi to
communicate with one process, it works as well.
1:localhost:1
lstarting parallel lapw1 at Mon Jan 23 06:49:16 JST 2012
- starting parallel LAPW1 jobs at Mon Jan 23 06:49:16 JST 2012
running LAPW1 in parallel mode (using .machines)
1 number_of_parallel_jobs
[1] 22417
LAPW1 END
[1] + Done ( cd $PWD; $t $exe ${def}_$loop.def; rm
-f .lock_$lockfile[$p] ) .time1_$loop
localhost(111) 179.004u 4.635s 0:32.73 561.0%0+0k 0+26392io 0pf+0w
Summary of lapw1para:
localhost k=111 user=179.004wallclock=32.73
179.167u 4.791s 0:35.61 516.5%0+0k 0+26624io 0pf+0w
Changing the machine file to use more than one process (the same form of error
occurs for more than 2)
1:localhost:2
lead to a run time error in the MPI subsystem.
starting parallel lapw1 at Mon Jan 23 06:51:04 JST 2012
- starting parallel LAPW1 jobs at Mon Jan 23 06:51:04 JST 2012
running LAPW1 in parallel mode (using .machines)
1 number_of_parallel_jobs
[1] 22673
Fatal error in MPI_Comm_size: Invalid communicator, error stack:
MPI_Comm_size(123): MPI_Comm_size(comm=0x5b, size=0x7ed20c) failed
MPI_Comm_size(76).: Invalid communicator
Fatal error in MPI_Comm_size: Invalid communicator, error stack:
MPI_Comm_size(123): MPI_Comm_size(comm=0x5b, size=0x7ed20c) failed
MPI_Comm_size(76).: Invalid communicator
[1] + Done ( cd $PWD; $t $ttt; rm -f
.lock_$lockfile[$p] ) .time1_$loop
localhost localhost(111) APPLICATION TERMINATED WITH THE EXIT STRING:
Hangup (signal 1)
0.037u 0.036s 0:00.06 100.0% 0+0k 0+0io 0pf+0w
TiC.scf1_1: No such file or directory.
Summary of lapw1para:
localhost k=0 user=111wallclock=0
0.105u 0.168s 0:03.21 8.0%0+0k 0+216io 0pf+0w
I have properly sourced the appropriate runtime environment for the Intel
system. For example, compiling (mpiifort) and running the f90 mpi test program
from intel produces:
mpirun -np 32 /home/paulfons/mpitest/testf90
Hello world: rank0 of 32 running on
asccmp177
Hello world: rank1 of 32 running on(32 times)
Does anyone have any suggestions as to what to try next? I am not sure how to
debug things from here. I have about 512 nodes that I can use for larger
calculations that only can be accessed by mpi (the ssh setup works fine as well
by the way). It would be great to figure out what is wrong.
Thanks.
Dr. Paul Fons
Functional Nano-phase-change Research Team
Team Leader
Nanodevice Innovation Research Center (NIRC)
National Institute for Advanced Industrial Science Technology
METI
AIST Central 4, Higashi 1-1-1
Tsukuba, Ibaraki JAPAN 305-8568
tel. +81-298-61-5636
fax. +81-298-61-2939
email: paul-fons at aist.go.jp
The following lines are in a Japanese font
?305-8562 ? 1-1-1
?
??
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120123/a608980e/attachment.htm
[Wien] MPI Problem
Thank you very much for your suggestion. I actually managed to figure this out
by myself an hour or so ago. At the same time (usually not a good idea) I also
compiled the mkl interface for fftw2 rather than using the standalone version I
had compiled by myself earlier. Thus the RP library line looks like
-lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_intelmpi_lp64
/opt/intel/mkl/lib/intel64/libfftw2x_cdft_DOUBLE.a $(R_LIBS)
All compiles
In the past ten minutes I have been running the TiC example under mpi and I
must say the mpi version seems tricker to use than I first though as each mpi
process seems to use multiple threads and it is easy to over saturate the
number of cores one has. I have been testing the mpi version on a single node
(32 cores) of a 500 core cluster to get a feel for things.
Running the TiC calculation (with 4000 k-points) in serial mode (the mkl
routine uses multiple threads) took about 75 seconds
Running the sample calculation in parallel mode (with 5 mpi processes each
which spawn multiple threads for an average cpu load of 28 in a 32 core
machine) takes longer, specifically 300 seconds.
Carrying out the same calculation with 1:localhost* on six separate lines
(e.g. lapw runs six processes locally and then aggregates without using mpi)
finishes quickest of all in about 60 seconds.
I don't really understand what is going on. Obviously I don't really need to
use the mpi/or parallel calculation for small problems as in the TiC example,
but I would like to use it for larger supercells. Is there some sort of
guiding principle which will help me decide which approach is best? I assume
the parallelization by running multiple jobs is also limited to a single
machine so this won't scale very well.
Thanks for any advice.
Paul
On Jan 23, 2012, at 8:08 AM, Laurence Marks wrote:
A guess: you are using the wrong version of blacs. You need a
-lmkl_blacs_intelmpi_XX
where XX is the one for your system. I have seen this give the same error.
Use http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
For reference, with openmpi it is _openmpi_ instead of _intelmpi_, and
similarly for sgi.
2012/1/22 Paul Fons paul-fons at aist.go.jp:
Hi,
I have Wien2K running on a cluster of linux boxes each with 32 cores and
connected by 10Gb ethernet. I have compiled Wien2K by the 3.174 version of
Wien2K (I learned the hard way that bugs in the newer versions of the Intel
compiler lead to crashes in Wien2K). I have also installed Intel's MPI.
First, the single process Wien2K, let's say for the TiC case, works fine.
It also works fine when I use a .machines file like
granulaity:1
localhost:1
localhost:1
? (24 times).
This file leads to parallel execution without error. I can vary the number
of processes by increasing the number of localhost:1 and the number of
localhost:1 lines in the file and still everything works fine. When I try
to use mpi to communicate with one process, it works as well.
1:localhost:1
lstarting parallel lapw1 at Mon Jan 23 06:49:16 JST 2012
- starting parallel LAPW1 jobs at Mon Jan 23 06:49:16 JST 2012
running LAPW1 in parallel mode (using .machines)
1 number_of_parallel_jobs
[1] 22417
LAPW1 END
[1] + Done ( cd $PWD; $t $exe ${def}_$loop.def; rm
-f .lock_$lockfile[$p] ) .time1_$loop
localhost(111) 179.004u 4.635s 0:32.73 561.0%0+0k 0+26392io 0pf+0w
Summary of lapw1para:
localhost k=111 user=179.004wallclock=32.73
179.167u 4.791s 0:35.61 516.5% 0+0k 0+26624io 0pf+0w
Changing the machine file to use more than one process (the same form of
error occurs for more than 2)
1:localhost:2
lead to a run time error in the MPI subsystem.
starting parallel lapw1 at Mon Jan 23 06:51:04 JST 2012
- starting parallel LAPW1 jobs at Mon Jan 23 06:51:04 JST 2012
running LAPW1 in parallel mode (using .machines)
1 number_of_parallel_jobs
[1] 22673
Fatal error in MPI_Comm_size: Invalid communicator, error stack:
MPI_Comm_size(123): MPI_Comm_size(comm=0x5b, size=0x7ed20c) failed
MPI_Comm_size(76).: Invalid communicator
Fatal error in MPI_Comm_size: Invalid communicator, error stack:
MPI_Comm_size(123): MPI_Comm_size(comm=0x5b, size=0x7ed20c) failed
MPI_Comm_size(76).: Invalid communicator
[1] + Done ( cd $PWD; $t $ttt; rm -f
.lock_$lockfile[$p] ) .time1_$loop
localhost localhost(111) APPLICATION TERMINATED WITH THE EXIT STRING:
Hangup (signal 1)
0.037u 0.036s 0:00.06 100.0% 0+0k 0+0io 0pf+0w
TiC.scf1_1: No such file or directory.
Summary of lapw1para:
localhost k=0 user=111wallclock=0
0.105u 0.168s 0:03.21 8.0% 0+0k 0+216io 0pf+0w
I have properly sourced the appropriate runtime environment for the Intel
system. For example, compiling (mpiifort) and running the f90 mpi test
program from intel produces:
mpirun -np 32 /home/paulfons/mpitest
[Wien] WIEN2k on Xeon 5500 Series
I am trying to compile Wien2K as well with the latest intel compilers. At first I thought it might be a stack overflow problem (of course limit stacksize was set to unlimited) and I tried the suggestion -heap-arrays from intel (http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors/) but it did not help either. Has any progress been made in tracking down the source of this error? The traceback is essentially worthless. Has anyone corresponded with intel with regards to the problem? I am now in the process of downloading an older version of the compiler. I am a little worried about downloading having different versions of the compiler as there is also C code in Wien2K. Exactly which versions of the C, Fortran, and MKL libraries should be used. I have a copy of a Intel Parallel Studio XE for Linux and don't typically download the individual packages hence my confusion.
