[Wien] [WIEN] wn-readbakgen.f for XCrySDen
My previous email was rather misshaped by the mail client. I hope you can read this one more clearly. Please apologize. In $WIENROOT/SRC_kgen there is a file wn_readbakgen.f which may be compiled in order to substitute the corresponding executable in the XCrySDen distribution ($XCRYSDEN_TOPDIR/bin/wn_readbakgen). However the file supplied in SRC_kgen leads to compile errors: lines 110,111 read(line,'(43x,i7,err=111)') nkpt /error: invalid character in format list/ goto 112 /error: label is not defined/ 111 read(line,'(44x,i6)') nkpt ! old format With the following slight modifications, compilation and execution works: read(line,'(43x,i7)',err=111) nkpt !/modified line 110// / goto 112 111 read(line,'(44x,i6)') nkpt ! old format 112 continue ! /added line/ Best regards, Ulrich -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart u.we...@fkf.mpg.de - ___ 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] initso_lapw after SCF with -in1new
Dear colleagues, I'm using WIEN2k 14.2. After a SCF run with the -in1new switch, initso_lapw (make_inso_lapw) doesn't interpret the case.in1 file correctly, due to the following reason: write_in1_lapw, invoked with the -in1new switch, writes line 3 of case.in1 free format. E.g. in my case: .2370444277 4 0 global e-param with N other choices, napw make_inso_lapw, called by initso_lapw, reads case.in1 in a formatted way (line 86 in my version), if RLO should be added: set numberL = `head -$lineint < $filein1 | tail -1 |cut -c 11-13` @ lineint = $numberL + $lineint With the example above, make_inso_lapw sets numberL = 77, i.e assumes 77 lines of exceptions in case.in1. As a consequence, the script tries to read 77 lines, prints all lines with l=1, prints '@: Expression Syntax.' and returns to initso_lapw, continuing this script. case.inso is not finalized beyond line 4. As a workaround I truncated the Etrial values in case.in1 to get the required format. Best regards, Ulrich Wedig -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart u.we...@fkf.mpg.de - ___ 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] Hi
I guess you are facing the problem that I noted in the mailing list on march 29th. Please look for: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-March/014424.html and http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-March/014426.html Best regards, Ulrich Wedig On 04/03/2011 10:42 AM, Rajagopalan Mathrubutham wrote: Dear Dr Blaha, Greeting from Rajagopalan Chennai I have a quad core system with 16 GB RAM I am able to run the parallel job in the system When I am trying to plot DOS I face some problem namely the case.vector file is missing If I run with out parallesation I am able to plot Kindly tell me how to solve this problem Regards and greetings Rajagopalan Dr.M.Rajagopalan Emeritus Scientist ( CSIR ) Crystal Growth Centre Anna University Chennai 600 025, India Phone + 091- 44- 22213023 (R) + 091 -44- 22359208 (O) Cell 9790714283 ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart U.Wedig at fkf.mpg.de -
[Wien] x lapw2 -p -qtl fails with shared memory configuration
Dear Wien community, indeed, the problem I reported in my last mail is solved, when using the vec2old_lapw version that was distributed in the mailing list by Peter Blaha on march, 7th. Best regards, Ulrich Wedig -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart U.Wedig at fkf.mpg.de -
[Wien] tetra produces NaN
Dear colleagues, when using tetra (WIEN2k 9.1), compiled with the Intel Fortran compiler 11.0, occasionally the calculation of DOS and partial DOSs results in 'NaN' for single energy values. This is a matter of numerical precision. When compiling tetra with the option: -fp-model precise , which disables optimization that can change the result of floating-point calculations, the problem wasn't observed up to now. The effect of this compiler option on the performance of the program seems to be marginal. Best regards Ulrich Wedig -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart U.Wedig at fkf.mpg.de -
[Wien] 'l2main' - QTL-B.GT.15.; Ghostbands, check scf files
Dear colleagues, this is not a question, it's just a note. Since 2 weeks I got the following error message when computing several cases with WIEN2k 9.1: 'l2main' - QTL-B.GT.15.; Ghostbands, check scf files There are a lot of hints in the manual, the FAQs and the mailing list about this topic, but none of them helped me to solve the problem. Moreover I was puzzled that even cases that worked some weeks ago, now gave the same error message. Now I found the reason for this behaviour. My WIEN version was compiled with the Intel compiler 11.0, update level 074, using dynamic linking. In our institute the compiler ist provided by the computer group on their server in a directory called ./074 (note, this directory also contains MKL). Two weeks ago, they updated the compiler to level 11.0.083 and stored this version in a directory called ./083. For some reasons, they renamed ./074 to ./074_old and created a link ./074, pointing to ./083. Thereby the WIEN executables (due to my unchanged LD_LIBRARY_PATH) now where linked dynamically with the libraries of level 11.0.083. This fact, which couldn't be noticed when executing the WIEN programs, caused the error mentioned above. When the level 11.0.074 libraries are linked once again, the problem doesn't appear any more. (Of course a new compilation with 11.0.083 also would help.) What did I learn? 1. The Intel libraries 11.0.074 and 11.0.083 seem to be not compatible, at least concerning WIEN2k. 2. If WIEN2k fails, it may not be due the program itself (or the input), but due to some small changes in your institutes network and the software supplied by others. Best regards Ulrich Wedig -- - Dr. Ulrich Wedig Tel. 0711/6891535 Max-Planck-Institut fuer Festkoerperforschung FAX 0711/6891502 Heisenbergstr. 1 70569 Stuttgart U.Wedig at fkf.mpg.de -
