[Wien] problems in wien2k 10 run
I am going to post my solution to similar issues, as maybe it will help others. In parallel_options on a big cluster that uses GPFS I have: setenv USE_REMOTE 1 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN "mpirun -x LD_LIBRARY_PATH -x PATH -np _NP_ -machinefile _HOSTS_ _EXEC_" set a=`grep -e "1:" .machines | grep -v lapw0 | head -1 | cut -f 3 -d: | cut -c 1-2` setenv MKL_NUM_THREADS $a setenv OMP_NUM_THREADS $a setenv MKL_DYNAMIC FALSE if (-e local_options ) source local_options set remote = "/bin/csh $WIENROOT/pbsh" set delay = 0.25 and $WIENROOT/pbsh is just the line mpirun -x LD_LIBRARY_PATH -x PATH -np 1 --host $1 /bin/csh -c " $2 " This combination does several things: a) It sets up the MKL threading environment correctly for the first node, since with qsub/msub etc you don't know exactly what you will have. (I don't know how to do this for others, maybe someone else does.) b) It runs everything using mpirun (rather than ssh) which works better with torque/openmpi and avoids orphans that can happen with ssh when jobs go wrong. Caveat: Please don't start tweaking these things unless you really know what you are doing! N.B., Wien2k is one of the best OS/Hardware fault finder that I know. I have found problems on several different clusters which left sysadmins slightly red-faced On Thu, May 19, 2011 at 11:22 AM, Laurence Marks wrote: > For GPFS (and many NFS) '-assu buff' is needed and in fact I persuaded > the people here to make this default using the environmental parameter > which many other clusters do. Is this GPFS from IBM? If so, there is > in fact a "bug" in it which Wien2k triggers by writing to the same > file from different cores/CPUs. This is fixed with 11, but maybe not > in the version you have. Compare errflg.f in lapw[0-2], it should be > something like > > ? ? ?if(myid.eq.0) then > ? ? ? ? OPEN (99,FILE=FNAME,ERR=900) > ? ? ? ? WRITE (99,9000) MSG > ! ? ? ? ? CLOSE (99) > ? ? ?endif > > in the recent versions. > > There is also a potential bug in terms of how you are running mpi jobs > as Wien2k uses ssh by default and torque does not know to kill this > and many versions of ssh do not propogate kill signals to children. > There is a discussion on this in this that I started at > http://www.open-mpi.org/community/lists/users/2011/04/16085.php . I > have some meetings, but if this is similar to what you have contact me > offline as there is a modification to parallel_options that seems to > work. > > 2011/5/19 saed alazar : >> The code works just fine on the student cluster where we have compiled it >> using the extra '-assu buff' flag to alleviate NFS problems. I think we have >> seen that the optimisation jobs work well there. >> >> There are still problems with the optimisation jobs running on the planck >> cluster though. >> >> It seems that there are 2 main problems: >> >> 1?? One node appears to be doing nearly all the work while the others do >> little... as seen in the dayfile. However if we login to the job nodes while >> the job is running and run the top command, all cores seem to be using ~100% >> cpu, load is normal. Also 'cat /proc/meminfo' shows there is plenty of free >> memory (there should be as these nodes each have 32GB RAM). >> 2?? After some time it becomes impossible to login to your home directory >> and I cannot even login to the job node from the console on the machine. I >> also cannot delete the job from the queues. This means I then have to turn >> the queuing system off (qterm -t quick), remove the job files from the jobs >> directory (rm -rf /usr/local/torque/server_priv/jobs/2627.planck.*) and then >> restart the queuing system (/usr/local/torque/sbin/pbs_server -t warm). I >> then still have to reboot the nodes that were involved with that job. This >> is a problem. >> >> The main difference between the planck cluster and the student cluster is >> that the planck cluster has a GPFS parallel file system and does not use NFS >> (well actually, GPFS uses something like NFS). The problems we were seeing >> on the student clsuter disappeared when we recompiled with the extra '-assu >> buff' flag. I am recompiling wien2k on the planck cluster with this flag but >> it does not fix the problems. >> >> Other than that, both machines are running RHEL5.3 Operating System, and >> openmpi, fftw have been compiled the same way, as has wien2k. >> >> >> >> >> Thanks >> >> Said >> >> ___ >> Wien mailing list >> Wien at zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> >> > > > > -- > Laurence Marks > Department of Materials Science and Engineering > MSE Rm 2036 Cook Hall > 2220 N Campus Drive > Northwestern University > Evanston, IL 60208, USA > Tel: (847) 491-3996 Fax: (847) 491-7820 > email: L-marks at northwestern dot edu > Web: www.numis.northwestern.edu > Chair, Commission on Electron Crystallography of IUCR > www.numis.northwestern.edu/ > Research is
[Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX
Have you converted your structure to B2/m symmetry? _ From: wien-boun...@zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Rostam Golesorkhtabar Sent: Thursday, May 19, 2011 2:07 PM To: Wien at zeus.theochem.tuwien.ac.at Subject: [Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX Dear all WIEN2k user I have a problem during the initialization of very simple structure. this is my structure: Al CXZ LATTICE,NONEQUIV.ATOMS: 1 12 C2/m RELA 7.636043 6.156375 7.636043 90.00 90.0 138.091152 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 8 Al1NPT= 781 R0=0.0001 RMT=2.5000 Z: 13.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0. 0 1 0 0. 0 0 1 0. 1 -1 0 0 0. 0-1 0 0. 0 0 1 0. 2 -1 0 0 0. 0-1 0 0. 0 0-1 0. 3 1 0 0 0. 0 1 0 0. 0 0-1 0. 4 If you execute x symmetry you will see this message at the END of case. outputs file: COULD NOT DETERMINE LOCAL ROTATION MATRIX!!! And suggested struct file of symmetry program is corrupted as well. Please let me know how can solve this problem Thank you very much in advance Rostam -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/371f62b9/attachment.htm>
[Wien] AFM initialization
Dear Wien2k users, I have a 32 atom cell with U, K and Cl (Space Group_Pnma). The Cl atoms are inequivalent (4 different Cl atoms as per the cif) I flipped the spin of 2 Cl atoms ( 2 up and 2 down) in the instgen input. I kept the spin of U and K as up. The command was runafm_lapw -in1ef -cc 0.0001 -ec 0.0001 -i 200 -p It runs fine. Now, my question is The number of equivalent atoms for U is only 1. Howevr, Structgen generates 4 equivalent positions for U during the initialization as per the space group. I paste below ATOM -1: X=0.5064 Y=0.2500 Z=0.0780 MULT= 4 ISPLIT= 8 -1: X=0.4936 Y=0.7500 Z=0.9220 -1: X=0.0064 Y=0.2500 Z=0.4220 -1: X=0.9936 Y=0.7500 Z=0.5780 U 1NPT= 781 R0=0.0001 RMT=2.5000 Z: 92.0 LOCAL ROT MATRIX:0.000 1.000 0.000 0.000 0.000 1.000 1.000 0.000 0.000 I would like to change the spins of these 4 atoms (2 up and 2 down) Is their any way I can do it? My other question is sine U is an heavy element, I would like to use -so. It is mentioned in the UG it is not possible, still I want to check the -so contribution in the total energy. Can we do it? Thanks Regards Suddhasattwa -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/90d6a68d/attachment.htm>
[Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX
Hi, I could verify your problem. Symmetry was not adapted for such a simple monoclinic CXZ case (with only one atom at the origin). Replace rstruc.f in SRC_symmetry by the attached file and recompile. Thanks for reporting Am 19.05.2011 10:36, schrieb Rostam Golesorkhtabar: > Dear all WIEN2k user > I have a problem during the initialization of very simple structure. this is > my structure: > > Al > CXZ LATTICE,NONEQUIV.ATOMS: 1 12 C2/m > RELA >7.636043 6.156375 7.636043 90.00 90.0 138.091152 > ATOM 1: X=0. Y=0. Z=0. >MULT= 1 ISPLIT= 8 > Al1NPT= 781 R0=0.0001 RMT=2.5000 Z: 13.0 > LOCAL ROT MATRIX:1.000 0.000 0.000 > 0.000 1.000 0.000 > 0.000 0.000 1.000 > 0 -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- -- next part -- A non-text attachment was scrubbed... Name: rstruc.f Type: text/x-fortran Size: 20395 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/96ece644/attachment.f>
[Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX
Sorry, I can not understand what do you mean B2/m symmetry? 2011/5/19 Ghosh SUDDHASATTWA > Have you converted your structure to B2/m symmetry? > > > -- > > *From:* wien-bounces at zeus.theochem.tuwien.ac.at [mailto: > wien-bounces at zeus.theochem.tuwien.ac.at] *On Behalf Of *Rostam > Golesorkhtabar > *Sent:* Thursday, May 19, 2011 2:07 PM > *To:* Wien at zeus.theochem.tuwien.ac.at > *Subject:* [Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX > > > > Dear all WIEN2k user > > I have a problem during the initialization of very simple structure. this > is my structure: > > > > Al > > > CXZ LATTICE,NONEQUIV.ATOMS: 1 12 C2/m > > RELA > > 7.636043 6.156375 7.636043 90.00 90.0 138.091152 > > ATOM 1: X=0. Y=0. Z=0. > > MULT= 1 ISPLIT= 8 > > Al1NPT= 781 R0=0.0001 RMT=2.5000 Z: 13.0 > > LOCAL ROT MATRIX:1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > >4 NUMBER OF SYMMETRY OPERATIONS > > 1 0 0 0. > > 0 1 0 0. > > 0 0 1 0. > >1 > > -1 0 0 0. > > 0-1 0 0. > > 0 0 1 0. > >2 > > -1 0 0 0. > > 0-1 0 0. > > 0 0-1 0. > >3 > > 1 0 0 0. > > 0 1 0 0. > > 0 0-1 0. > >4 > > > > If you execute x symmetry you will see this message at the END of > case. outputs file: > > COULD NOT DETERMINE LOCAL ROTATION MATRIX!!! > > And suggested struct file of symmetry program is corrupted as well. > > Please let me know how can solve this problem > > > > Thank you very much in advance > > Rostam > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > > -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/3854d519/attachment-0001.htm>
[Wien] problems in wien2k 10 run
For GPFS (and many NFS) '-assu buff' is needed and in fact I persuaded the people here to make this default using the environmental parameter which many other clusters do. Is this GPFS from IBM? If so, there is in fact a "bug" in it which Wien2k triggers by writing to the same file from different cores/CPUs. This is fixed with 11, but maybe not in the version you have. Compare errflg.f in lapw[0-2], it should be something like if(myid.eq.0) then OPEN (99,FILE=FNAME,ERR=900) WRITE (99,9000) MSG ! CLOSE (99) endif in the recent versions. There is also a potential bug in terms of how you are running mpi jobs as Wien2k uses ssh by default and torque does not know to kill this and many versions of ssh do not propogate kill signals to children. There is a discussion on this in this that I started at http://www.open-mpi.org/community/lists/users/2011/04/16085.php . I have some meetings, but if this is similar to what you have contact me offline as there is a modification to parallel_options that seems to work. 2011/5/19 saed alazar : > The code works just fine on the student cluster where we have compiled it > using the extra '-assu buff' flag to alleviate NFS problems. I think we have > seen that the optimisation jobs work well there. > > There are still problems with the optimisation jobs running on the planck > cluster though. > > It seems that there are 2 main problems: > > 1?? One node appears to be doing nearly all the work while the others do > little... as seen in the dayfile. However if we login to the job nodes while > the job is running and run the top command, all cores seem to be using ~100% > cpu, load is normal. Also 'cat /proc/meminfo' shows there is plenty of free > memory (there should be as these nodes each have 32GB RAM). > 2?? After some time it becomes impossible to login to your home directory > and I cannot even login to the job node from the console on the machine. I > also cannot delete the job from the queues. This means I then have to turn > the queuing system off (qterm -t quick), remove the job files from the jobs > directory (rm -rf /usr/local/torque/server_priv/jobs/2627.planck.*) and then > restart the queuing system (/usr/local/torque/sbin/pbs_server -t warm). I > then still have to reboot the nodes that were involved with that job. This > is a problem. > > The main difference between the planck cluster and the student cluster is > that the planck cluster has a GPFS parallel file system and does not use NFS > (well actually, GPFS uses something like NFS). The problems we were seeing > on the student clsuter disappeared when we recompiled with the extra '-assu > buff' flag. I am recompiling wien2k on the planck cluster with this flag but > it does not fix the problems. > > Other than that, both machines are running RHEL5.3 Operating System, and > openmpi, fftw have been compiled the same way, as has wien2k. > > > > > Thanks > > Said > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > > -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi
[Wien] COULD NOT DETERMINE LOCAL ROTATION MATRIX
Dear all WIEN2k user I have a problem during the initialization of very simple structure. this is my structure: Al CXZ LATTICE,NONEQUIV.ATOMS: 1 12 C2/m RELA 7.636043 6.156375 7.636043 90.00 90.0 138.091152 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 8 Al1NPT= 781 R0=0.0001 RMT=2.5000 Z: 13.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0. 0 1 0 0. 0 0 1 0. 1 -1 0 0 0. 0-1 0 0. 0 0 1 0. 2 -1 0 0 0. 0-1 0 0. 0 0-1 0. 3 1 0 0 0. 0 1 0 0. 0 0-1 0. 4 If you execute x symmetry you will see this message at the END of case. outputs file: COULD NOT DETERMINE LOCAL ROTATION MATRIX!!! And suggested struct file of symmetry program is corrupted as well. Please let me know how can solve this problem Thank you very much in advance Rostam -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/198d9322/attachment.htm>
[Wien] AFM initialization
Search the UG for all places where the string 'afm' appears, and read those sections carefully (not at least Sec. 4.5.4). You might have a look at the FAQ as well (http://www.wien2k.at/reg_user/faq/afm.html). Then reconsider whether what you did was right. For your other question, ponder what it means to break the chemical (crystallographic) symmetry by magnetism (FM or AFM). There might be hints in another FAQ entry as well (http://www.wien2k.at/reg_user/faq/supercells.html). Stefaan On 19/05/2011 8:23, Ghosh SUDDHASATTWA wrote: > Dear Wien2k users, > > I have a 32 atom cell with U, K and Cl (Space Group_Pnma). > > The Cl atoms are inequivalent (4 different Cl atoms as per the cif) > > I flipped the spin of 2 Cl atoms ( 2 up and 2 down) in the instgen > input. I kept the spin of U and K as up. > > The command was > > runafm_lapw ?in1ef ?cc 0.0001 ?ec 0.0001 ?i 200 ?p > > It runs fine. > > Now, my question is > > The number of equivalent atoms for U is only 1. > > Howevr, Structgen generates 4 equivalent positions for U during the > initialization as per the space group. I paste below > > ATOM -1: X=0.5064 Y=0.2500 Z=0.0780 > > MULT= 4 ISPLIT= 8 > > -1: X=0.4936 Y=0.7500 Z=0.9220 > > -1: X=0.0064 Y=0.2500 Z=0.4220 > > -1: X=0.9936 Y=0.7500 Z=0.5780 > > U 1 NPT= 781 R0=0.0001 RMT= 2.5000 Z: 92.0 > > LOCAL ROT MATRIX: 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > 1.000 0.000 0.000 > > I would like to change the spins of these 4 atoms (2 up and 2 down) > > Is their any way I can do it? > > My other question is sine U is an heavy element, I would like to use > ?so. It is mentioned in the UG it is not possible, still I want to check > the ?so contribution in the total energy. > > Can we do it? > > Thanks > > Regards > > Suddhasattwa > > > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] problems in wien2k 10 run
The code works just fine on the student cluster where we have compiled it using the extra '-assu buff' flag to alleviate NFS problems. I think we have seen that the optimisation jobs work well there. There are still problems with the optimisation jobs running on the planck cluster though. It seems that there are 2 main problems: 1?? One node appears to be doing nearly all the work while the others do little... as seen in the dayfile. However if we login to the job nodes while the job is running and run the top command, all cores seem to be using ~100% cpu, load is normal. Also 'cat /proc/meminfo' shows there is plenty of free memory (there should be as these nodes each have 32GB RAM). 2?? After some time it becomes impossible to login to your home directory and I cannot even login to the job node from the console on the machine. I also cannot delete the job from the queues. This means I then have to turn the queuing system off (qterm -t quick), remove the job files from the jobs directory (rm -rf /usr/local/torque/server_priv/jobs/2627.planck.*) and then restart the queuing system (/usr/local/torque/sbin/pbs_server -t warm). I then still have to reboot the nodes that were involved with that job. This is a problem. The main difference between the planck cluster and the student cluster is that the planck cluster has a GPFS parallel file system and does not use NFS (well actually, GPFS uses something like NFS). The problems we were seeing on the student clsuter disappeared when we recompiled with the extra '-assu buff' flag. I am recompiling wien2k on the planck cluster with this flag but it does not fix the problems. Other than that, both machines are running RHEL5.3 Operating System, and openmpi, fftw have been compiled the same way, as has wien2k. Thanks Said -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/127a430a/attachment.htm>
[Wien] mixer error
Dear Prof. P. Balha, Thank you very much for your help. I examined the mixer.error file. mixer.error files are described as follows. 'ROTDEF' - no symmetry operation found. 'ROTDEF' - for jatom, index 1 2 'ROTDEF' - atomposition of jatom 0.000 0.000 0.000 'ROTDEF' - atomposition of index 0.000 0.250 0.250 I read users manual but I do not understand in which part ROTDEF is appeared . Please tell me. Sincerely yours, Masaichiro Mizumaki On 2011/05/18, at 23:18, Peter Blaha wrote: > Sorry, but nobody can help you with this kind of information. > > The error is probably in mixer, not in lapw2 as written below. > > ls -als *.error > examine the content of a non-zero error file. > > Am 18.05.2011 16:09, schrieb ?? ???: >> Dear Prof. P. Balha and WIEN2k users, >> >> Please tell me how to resolve this problem >> I calculate the band structure of Laves phase compound CeFe2. (Space Group >> #277) >> In lapw2 sequence, error occurred and program is stopped. >> And then, error messages were described as follows; >> >> Calculating CeFe2 in /home/mizumaki/WIEN2Kdata/CeFe2 >> on mizuMCD with PID 791 >> using WIEN2k_11.1 (Release 5/4/2011) in /home/mizumaki/Wien2k11 >> >> >> start(Wed May 18 11:40:52 JST 2011) with lapw0 (40/99 to go) >> >> >> cycle 1 (Wed May 18 11:40:52 JST 2011) (40/99 to go) >> >>> lapw0 (11:40:52) 5.965u 0.062s 0:06.12 98.3% 0+0k 0+0io 0pf+0w >>> lapw1 -up(11:40:59) 4.947u 0.640s 0:05.67 98.4% 0+0k 0+0io >>> 0pf+0w >> >>> lapw1 -dn(11:41:04) 5.121u 0.698s 0:05.96 97.4% 0+0k 0+0io >>> 0pf+0w >>> lapw2 -up (11:41:10) 4.304u 0.506s 0:04.85 98.9% 0+0k 0+0io >>> 0pf+0w >>> lapw2 -dn (11:41:15) 3.666u 0.469s 0:04.16 99.0% 0+0k 0+0io >>> 0pf+0w >> >>> lcore -up (11:41:19) 0.009u 0.004s 0:00.01 0.0% 0+0k 0+0io 0pf+0w >>> lcore -dn (11:41:19) 0.010u 0.002s 0:00.01 100.0% 0+0k 0+0io 0pf+0w >>> mixer (11:41:19) 0.015u 0.003s 0:00.01 100.0% 0+0k 0+0io 0pf+0w >> >> >>> stop error >> >> >> Please help me. >> >> Sincerely yours, >> >> Masaiciro Mizumaki >> >> >> >> ?679-51981-1-1 >> >> ?? >> ? >> Tel: 0791-58-0802-3870 >> Fax: 0791-58-0830 >> E-mail: mizumaki at spring8.or.jp <mailto:mizumaki at spring8.or.jp> >> -- >> >> >> >> ___ >> 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-15671 FAX: +43-1-58801-15698 > 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/mailman/listinfo/wien ?679-51981-1-1 ?? ? Tel: 0791-58-0802-3870 Fax: 0791-58-0830 E-mail: mizumaki at spring8.or.jp -- -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2069 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110519/df362ed9/attachment.p7s>
