From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #27 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, July 18 2002 Volume 2002 : Number 027 ---------------------------------------------------------------------- Date: Thu, 11 Jul 2002 12:19:24 +0800 From: "wan liu" Subject: Re: [WIEN]: About Total Energy ==== "wan liu" submitted the following contribution: ==== Dear Prof. Blaha Thank you. Best Wish Liu >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: About Total Energy >Date: Mon, 8 Jul 2002 11:55:45 +0200 (MEST) > >==== >Peter Blaha >submitted the following contribution: >==== > > > I want to know whether or not I can find the values of BAND ENERGY, CORE > > ENERGY, KINETIC ENERGY, and COULOMB ENERGY in WIEN. > >Kinetic and coulomb energy is not seperated in WIEN: > >:DEN : DENSITY INTEGRALS = -690.575068 (Ry) >Contains the contribution of all integrals rho * (V + E_xc) > >:SUM : SUM OF EIGENVALUES = -9.384373 >(contains sum of band energies) > > 1.ATOM Ti 4 CORE STATES >:1S 01: 1S -363.121745 Ry >:2S 01: 2S -42.906536 Ry >Core energies for all atoms and core states seperately > > > > > The reason why I want to see it is that > > > > I find difference between the two crystal structure is very small, but the > > difference of :ENE is very large about 2Ry. I want know if the result is > > reasonable? Where the difference comin from? > >If the two structures are really similar, 2 Ry is a really large number. > >In order to compare you must have: >Same atomic sphere sizes for both cases >same RKMAX value (also effective) >same GMAX >compatible (or converged) k-mesh (But this should account only for some mRy) > >For more help you must provide more info (struct files, last iteration scf-file) > >Regards > > 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 11 Jul 2002 02:43:29 +0100 From: Ian Morrison Subject: [WIEN]: ice cmc2_1 ==== Ian Morrison submitted the following contribution: ==== - --------------42AA47A1600B2A8ACB9FB027 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl, could you use cerius to make a picture of the cmc2_1 unit cell - both eps and jpeg (alex knows how to do eps -> jpeg). If you could also insert some arrows showing the movement of molecules in the phono we mapped would be useful. Ian Xiangyuan Cui wrote: > Dear Professor Blaha and other Wien2k users, We are trying to analysis > the phonon frequency of hydrogen bond in ICE crystal by comparing the > GGA and meta-GGA. We use R_O=1.2, R_H=0.6, R*K=5. For GGA, Gmax=22 > gives reasonable answer.For meta-GGA, when we used Gmax=24, the > results is not as good as we expected. Then we tried Gmax=25 and > continue running the job, all the calculations (5 single-point > calculations) finished with one or two extra iterations.But something > happens here: For 2 cases, the total energy remains nearly unchanged. > But for the other 3 cases, the energy got higher (typically 0.025 Ry, > which is too large for our purpose). I noticed your warning in > January: Warning: Use GMAX as large as possible (24), even though it > might be > numerically unstable. > Note: The meta-GGA uses the GGA potential, only the total Energy is > changed! > It seems it is necessary to use Gmax=25 here.My question is: how to > overcome this instability? any remedy? Many Thanks! > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002 - -- Dr Ian Morrison Joule Physics Laboratory and Institute for Materials Research University of Salford, M5 4WT, UK email: i.morrison@salford.ac.uk tel: +44 161 2955303 - --------------42AA47A1600B2A8ACB9FB027 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Carl,

   could you use cerius to make a picture of the cmc2_1 unit cell  - both eps and
jpeg (alex knows how to do eps -> jpeg).

   If you could also insert some arrows showing the movement of molecules in
the phono we mapped would be useful.

  Ian

Xiangyuan Cui wrote:

Dear Professor Blaha and other Wien2k users, We are trying to analysis the phonon frequency of hydrogen bond in ICE crystal by comparing the GGA and meta-GGA. We use R_O=1.2, R_H=0.6, R*K=5. For GGA, Gmax=22 gives reasonable answer.For meta-GGA, when we used Gmax=24, the results is not as good as we expected. Then we tried Gmax=25 and continue running the job, all the calculations (5 single-point calculations) finished with one or two extra iterations.But something happens here: For 2 cases, the total energy remains nearly unchanged. But for the other 3 cases, the energy got higher (typically 0.025 Ry, which is too large for our purpose). I noticed your warning in January: Warning: Use GMAX as large as possible (24), even though it might be
numerically unstable.
Note: The meta-GGA uses the GGA potential, only the total Energy is changed! 
It seems it is necessary to use Gmax=25 here.My question is: how to overcome this instability? any remedy? Many Thanks!  
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002

--
Dr Ian Morrison
Joule Physics Laboratory and Institute for Materials Research
University of Salford, M5 4WT, UK
email: i.morrison@salford.ac.uk  tel: +44 161 2955303
  - --------------42AA47A1600B2A8ACB9FB027-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 11 Jul 2002 02:45:00 +0100 From: Ian Morrison Subject: Re: [WIEN]: Meta-GGA (unstability) ==== Ian Morrison submitted the following contribution: ==== - --------------0E9BC3018782EA13382112D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ignore my last message - I replied to the wrong email !! sorry Xiangyuan Cui wrote: > Dear Professor Blaha and other Wien2k users, We are trying to analysis > the phonon frequency of hydrogen bond in ICE crystal by comparing the > GGA and meta-GGA. We use R_O=1.2, R_H=0.6, R*K=5. For GGA, Gmax=22 > gives reasonable answer.For meta-GGA, when we used Gmax=24, the > results is not as good as we expected. Then we tried Gmax=25 and > continue running the job, all the calculations (5 single-point > calculations) finished with one or two extra iterations.But something > happens here: For 2 cases, the total energy remains nearly unchanged. > But for the other 3 cases, the energy got higher (typically 0.025 Ry, > which is too large for our purpose). I noticed your warning in > January: Warning: Use GMAX as large as possible (24), even though it > might be > numerically unstable. > Note: The meta-GGA uses the GGA potential, only the total Energy is > changed! > It seems it is necessary to use Gmax=25 here.My question is: how to > overcome this instability? any remedy? Many Thanks! > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002 - -- Dr Ian Morrison Joule Physics Laboratory and Institute for Materials Research University of Salford, M5 4WT, UK email: i.morrison@salford.ac.uk tel: +44 161 2955303 - --------------0E9BC3018782EA13382112D7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ignore my last message - I replied to the wrong email !!

sorry

Xiangyuan Cui wrote:

Dear Professor Blaha and other Wien2k users, We are trying to analysis the phonon frequency of hydrogen bond in ICE crystal by comparing the GGA and meta-GGA. We use R_O=1.2, R_H=0.6, R*K=5. For GGA, Gmax=22 gives reasonable answer.For meta-GGA, when we used Gmax=24, the results is not as good as we expected. Then we tried Gmax=25 and continue running the job, all the calculations (5 single-point calculations) finished with one or two extra iterations.But something happens here: For 2 cases, the total energy remains nearly unchanged. But for the other 3 cases, the energy got higher (typically 0.025 Ry, which is too large for our purpose). I noticed your warning in January: Warning: Use GMAX as large as possible (24), even though it might be
numerically unstable.
Note: The meta-GGA uses the GGA potential, only the total Energy is changed! 
It seems it is necessary to use Gmax=25 here.My question is: how to overcome this instability? any remedy? Many Thanks!  
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002

--
Dr Ian Morrison
Joule Physics Laboratory and Institute for Materials Research
University of Salford, M5 4WT, UK
email: i.morrison@salford.ac.uk  tel: +44 161 2955303
  - --------------0E9BC3018782EA13382112D7-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 11 Jul 2002 15:52:39 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: [WIEN]: about contour plotting ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Dear WIEN users I want to know that whether any body has developed any program for viewing the contour plots in detail and willing to share the program with the users of WIEN? Also, if some one will be able to tell me how to use the XCRYSDEN for plottting utilities, I will be very grateful (as no user manual is available for the functions and so far I have been able to generate only a single straight line in XCRYSDEN while trying to plot the contours). I am calculating the electron density for CuV2O5 which is monoclinic system and I want to plot the electron density in the local axis and not in cartesian axis which is required for using rhoplot and gnuplot. Dr. Sharat Chandra %%%%%%%% _ %%%%%%%%%%%% ___ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Materials Science Division (_) ___ ___ / _ \ ___ Indira Gandhi Centre for | |/ _ \ / __\| |_| |' _ \ 183, Central Avenue Atomic Research | | (_) | |__,| _ | | \| DAE Township, Kalpakkam Kalpakkam 603102 TN INDIA |_|\__/ |\___/|_| |_|_| 603102 TN INDIA Ph. & FAX: 91 4114 480081 / /| | %%%%%%%%%%%%%%%% 91 4114 481521 email: sharat@igcar.ernet.in | |_| | %%%%%%%%%%%%%%%% sharat_c@yahoo.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%% \___/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 12 Jul 2002 08:27:32 +0800 (CST) From: =?gb2312?q?Weidong=20zou?= Subject: [WIEN]: fmt:read unexpected character ==== =?gb2312?q?Weidong=20zou?= submitted the following contribution: ==== Dear wien users, When I implement SCF cycle, I have obtained the error message in cycle 5 : "fmt: read unexpected character apparent state:unit 45 named ./CuCl.help45up" and the error file write:"Error in LAPW2". In the file CuCl.help45up, I find: BAND# 1 E= -6.9918 WEIGHT=0.40000 L=0 23.42762 ********17895.491***********-1779.157 L=1 0.0004 0.000 0.000 0.000 0.000 0.000 BAND# 2 E= -6.9946 WEIGHT=0.40000 L=0 23.37931 ********178525.491**********-1779.157 L=1 0.0007 0.000 0.000 0.000 0.000 0.0000 I don't know how to adjust this error .could anyone help me? I am desperate. I would very heartily appreciate any help. Best regardes! W.D.Zou _________________________________________________________ Do You Yahoo!? ÒøÐоÞÍ·¾Û»áÖÐÔ­ ´óÀËÌÔ¡®½ð¡¯Ë­½«Ð¦°Á http://sweepstakes.yahoo.com/bank_surveywave2/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 14 Jul 2002 12:00:25 +0800 From: "wan liu" Subject: [WIEN]: about mini ==== "wan liu" submitted the following contribution: ==== Dear Wien users and developers Now I try to use min_lapw to optimize the internal parameter of crystal. I have two questions. (1) According the space-group symmetry, the position is (0.5, 0.25, x), so I write the case.inM as (0.0 0.0 1.0 0.5). It is right? (2) The min_lapw is working. But first the total energy decrease, after about four iteration the total energy will increase(now the force is still large), on the other hand, the force will decrease. My question is I can take which structure as the ground state? The structure has minimal total ernergy and large force; or the structure has minimal force but not minimal total ernergy? Best wish! Liu _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 14 Jul 2002 10:29:08 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi wien users I am doing calculations for the CuV2O5 in base centered monoclinic phase. My problem concerns the band structure calculations. When I try to generate the case.klist file with XCrysden, it shows a B.Z. similar to base centered Orthorhombic, rather than base centered monoclinic. So, I have just taken the B.Z. for base centered monoclinic and generated my own klist, which does the integration along the V->Z->Gamma->A->M->L path (Bradley & Cracknell). I want to know is it OK to do so? Dear Prof. Holzwarth: thanks for the information and the 3D program. I am trying to learn the open DX these days. Regards Sharat Chandra - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="cuv2o5.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: case structure file VjJPNS1DbSg4KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ1haIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOjIzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDI4LjgxODMzNSAxOS4wOTE5MTEgIDYuODU1 OTI5IDkwLjAwMDAwMCA5MC4wMDAwMDAxMDYuNzEzMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4zMzcwMDAwMCBZPTAuMDk0NDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNClYgMSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMS41NjAwICAgWjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuMTIwMzAwMDAgWT0w LjExNjcwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpWIDIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAwNTAwMCBSTVQ9ICAgIDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjI5 NjYwMDAwIFk9MC40MDY1MDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViAzICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTQ6IFg9MC4yMjE5MDAwMCBZPTAuNTkxOTAwMDAgWj0wLjUwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNClYgNCAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMS41NjAwICAg WjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009IC01OiBYPTAuMTc0MDAwMDAgWT0wLjkwMTgwMDAwIFo9MC41 MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpWIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPSAtNjogWD0wLjM5MzUwMDAwIFk9MC44NzY2 MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KViA2ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUw MDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTc6IFg9MC45OTUwMDAw MCBZPTAuOTg3MDAwMDAgWj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMSAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC04OiBY PTAuMTg2MDAwMDAgWT0wLjk1MTAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDIgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtOTogWD0wLjM2OTAwMDAwIFk9MC45MDAwMDAwMCBaPTAuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAz ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTA6IFg9MC40MjkwMDAwMCBZPTAuMTkyMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gNCAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTExOiBYPTAuMjY3MDAwMDAgWT0w LjIxODAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjA5 NjAwMDAwIFk9MC4yNjIwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA2ICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MTM6IFg9MC4yNTMwMDAwMCBZPTAuNTg4MDAwMDAgWj0wLjAwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCk8gNyAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDguMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTE0OiBYPTAuNDA0MDAwMDAgWT0wLjQ1NjAwMDAwIFo9MC4w MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpPIDggICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPS0xNTogWD0wLjI2NTAwMDAwIFk9MC40Mzcw MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KTyA5ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0tMTY6IFg9MC4xMTEwMDAw MCBZPTAuNTQ0MDAwMDAgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMTAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTE3OiBY PTAuMDcwMDAwMDAgWT0wLjc4NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDExICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0xODogWD0wLjI0NTAwMDAwIFk9MC43NzkwMDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAx MiAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTk6IFg9MC40MDgwMDAwMCBZPTAuNzEyMDAwMDAg Wj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gMTMgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTIwOiBYPTAuMTM0MDAwMDAgWT0w LjA3NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDE0ICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0yMTogWD0wLjMx NTAwMDAwIFk9MC4wMzgwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxNSAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MjI6IFg9MC41MjY5MDAwMCBZPTAuMzY1MDAwMDAgWj0wLjEwMjAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCkN1MSAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMi4wMDAwICAg WjogMjkuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTIzOiBYPTAuNDYzMjAwMDAgWT0wLjY1NTAwMDAwIFo9MC45 MTgwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpDdTIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDIuMDAwMCAgIFo6IDI5LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQogICAxICAgICAgTlVNQkVSIE9GIFNZTU1FVFJZIE9Q RVJBVElPTlMNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDAN CiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICAxDQo= - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="monoclinic.klist" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ViAgICAgICAgICAgICAwICAgIDAgICAzOCAgIDc2ICAxLjAgLTEuNSAgMS41 DQogICAgICAgICAgICAgIDAgICAtMiAgIDM4ICAgNzYgIDEuMA0KICAgICAg ICAgICAgICAwICAgLTQgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAg MCAgIC02ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgICAtOCAg IDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMTAgICAzOCAgIDc2 ICAxLjANCiAgICAgICAgICAgICAgMCAgLTEyICAgMzggICA3NiAgMS4wDQog ICAgICAgICAgICAgIDAgIC0xNCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAg ICAgICAwICAtMTYgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAg LTE4ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0yMCAgIDM4 ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMjIgICAzOCAgIDc2ICAx LjANCiAgICAgICAgICAgICAgMCAgLTI0ICAgMzggICA3NiAgMS4wDQogICAg ICAgICAgICAgIDAgIC0yNiAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAg ICAwICAtMjggICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTMw ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0zMiAgIDM4ICAg NzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMzQgICAzOCAgIDc2ICAxLjAN CiAgICAgICAgICAgICAgMCAgLTM2ICAgMzggICA3NiAgMS4wDQpaICAgICAg ICAgICAgIDAgIC0zOCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAw ICAtMzYgICAzNiAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTM0ICAg MzQgICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0zMiAgIDMyICAgNzYg IDEuMA0KICAgICAgICAgICAgICAwICAtMzAgICAzMCAgIDc2ICAxLjANCiAg ICAgICAgICAgICAgMCAgLTI4ICAgMjggICA3NiAgMS4wDQogICAgICAgICAg ICAgIDAgIC0yNiAgIDI2ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAt MjQgICAyNCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTIyICAgMjIg ICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0yMCAgIDIwICAgNzYgIDEu MA0KICAgICAgICAgICAgICAwICAtMTggICAxOCAgIDc2ICAxLjANCiAgICAg ICAgICAgICAgMCAgLTE2ICAgMTYgICA3NiAgMS4wDQogICAgICAgICAgICAg IDAgIC0xNCAgIDE0ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMTIg ICAxMiAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTEwICAgMTAgICA3 NiAgMS4wDQogICAgICAgICAgICAgIDAgICAtOCAgICA4ICAgNzYgIDEuMA0K ICAgICAgICAgICAgICAwICAgLTYgICAgNiAgIDc2ICAxLjANCiAgICAgICAg ICAgICAgMCAgIC00ICAgIDQgICA3NiAgMS4wDQogICAgICAgICAgICAgIDAg ICAtMiAgICAyICAgNzYgIDEuMA0KRyAgICAgICAgICAgICAwICAgIDAgICAg MCAgIDc2ICAxLjANCiAgICAgICAgICAgICAtMiAgICAwICAgIDAgICA3NiAg MS4wDQogICAgICAgICAgICAgLTQgICAgMCAgICAwICAgNzYgIDEuMA0KICAg ICAgICAgICAgIC02ICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAg ICAtOCAgICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMTAgICAg MCAgICAwICAgNzYgIDEuMA0KICAgICAgICAgICAgLTEyICAgIDAgICAgMCAg IDc2ICAxLjANCiAgICAgICAgICAgIC0xNCAgICAwICAgIDAgICA3NiAgMS4w DQogICAgICAgICAgICAtMTYgICAgMCAgICAwICAgNzYgIDEuMA0KICAgICAg ICAgICAgLTE4ICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0y MCAgICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMjIgICAgMCAg ICAwICAgNzYgIDEuMA0KICAgICAgICAgICAgLTI0ICAgIDAgICAgMCAgIDc2 ICAxLjANCiAgICAgICAgICAgIC0yNiAgICAwICAgIDAgICA3NiAgMS4wDQog ICAgICAgICAgICAtMjggICAgMCAgICAwICAgNzYgIDEuMA0KICAgICAgICAg ICAgLTMwICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zMiAg ICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMzQgICAgMCAgICAw ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM2ICAgIDAgICAgMCAgIDc2ICAx LjANCkEgICAgICAgICAgIC0zOCAgICAwICAgIDAgICA3NiAgMS4wDQogICAg ICAgICAgICAtMzggICAtMiAgICAyICAgNzYgIDEuMA0KICAgICAgICAgICAg LTM4ICAgLTQgICAgNCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgIC02 ICAgIDYgICA3NiAgMS4wDQogICAgICAgICAgICAtMzggICAtOCAgICA4ICAg NzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMTAgICAxMCAgIDc2ICAxLjAN CiAgICAgICAgICAgIC0zOCAgLTEyICAgMTIgICA3NiAgMS4wDQogICAgICAg ICAgICAtMzggIC0xNCAgIDE0ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4 ICAtMTYgICAxNiAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTE4ICAg MTggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0yMCAgIDIwICAgNzYg IDEuMA0KICAgICAgICAgICAgLTM4ICAtMjIgICAyMiAgIDc2ICAxLjANCiAg ICAgICAgICAgIC0zOCAgLTI0ICAgMjQgICA3NiAgMS4wDQogICAgICAgICAg ICAtMzggIC0yNiAgIDI2ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAt MjggICAyOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTMwICAgMzAg ICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0zMiAgIDMyICAgNzYgIDEu MA0KICAgICAgICAgICAgLTM4ICAtMzQgICAzNCAgIDc2ICAxLjANCiAgICAg ICAgICAgIC0zOCAgLTM2ICAgMzYgICA3NiAgMS4wDQpNICAgICAgICAgICAt MzggIC0zOCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMzYg ICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTM0ICAgMzggICA3 NiAgMS4wDQogICAgICAgICAgICAtMzggIC0zMiAgIDM4ICAgNzYgIDEuMA0K ICAgICAgICAgICAgLTM4ICAtMzAgICAzOCAgIDc2ICAxLjANCiAgICAgICAg ICAgIC0zOCAgLTI4ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzgg IC0yNiAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMjQgICAz OCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTIyICAgMzggICA3NiAg MS4wDQogICAgICAgICAgICAtMzggIC0yMCAgIDM4ICAgNzYgIDEuMA0KICAg ICAgICAgICAgLTM4ICAtMTggICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAg IC0zOCAgLTE2ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0x NCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMTIgICAzOCAg IDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTEwICAgMzggICA3NiAgMS4w DQogICAgICAgICAgICAtMzggICAtOCAgIDM4ICAgNzYgIDEuMA0KICAgICAg ICAgICAgLTM4ICAgLTYgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0z OCAgIC00ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggICAtMiAg IDM4ICAgNzYgIDEuMA0KTCAgICAgICAgICAgLTM4ICAgIDAgICAzOCAgIDc2 ICAxLjANCkVORA0K - ---559023410-851401618-1026660194=:506-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 14 Jul 2002 10:17:55 +0200 (CEST) From: =?iso-8859-1?q?fafa=20chiker?= Subject: [WIEN]: thank's Msr Blaha ==== =?iso-8859-1?q?fafa=20chiker?= submitted the following contribution: ==== Dear Prof.Blaha i am very happy to your answer, so i have found the solution to my problem and I am very grateful, sir,to your help, also to my chairman B.Abbar. the solution is to make the -c in x dstart command in the three jobs: eos.job, rhomb.job and tetra.job. thank you very much, yours ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 09:54:23 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi all This is in continuation of the previous mail. I have calculated the band structure without the band character plotting and I get a band structure with gaps in between with the attached klist. This can only mean that this klist is incorrect. Can anybody please tell me what can be the problem? Or should I calculate the band structure with the base centered Orthorhombic klist? In which case will it be the correct one anyway? Regards Sharat Chandra - ---------- Forwarded message ---------- I am doing calculations for the CuV2O5 in base centered monoclinic phase. My problem concerns the band structure calculations. When I try to generate the case.klist file with XCrysden, it shows a B.Z. similar to base centered Orthorhombic, rather than base centered monoclinic. So, I have just taken the B.Z. for base centered monoclinic and generated my own klist, which does the integration along the V->Z->Gamma->A->M->L path (Bradley & Cracknell). I want to know is it OK to do so? Regards Sharat Chandra - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="cuv2o5.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: case structure file VjJPNS1DbSg4KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ1haIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOjIzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDI4LjgxODMzNSAxOS4wOTE5MTEgIDYuODU1 OTI5IDkwLjAwMDAwMCA5MC4wMDAwMDAxMDYuNzEzMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4zMzcwMDAwMCBZPTAuMDk0NDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNClYgMSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMS41NjAwICAgWjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuMTIwMzAwMDAgWT0w LjExNjcwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpWIDIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAwNTAwMCBSTVQ9ICAgIDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjI5 NjYwMDAwIFk9MC40MDY1MDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViAzICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTQ6IFg9MC4yMjE5MDAwMCBZPTAuNTkxOTAwMDAgWj0wLjUwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNClYgNCAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMS41NjAwICAg WjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009IC01OiBYPTAuMTc0MDAwMDAgWT0wLjkwMTgwMDAwIFo9MC41 MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpWIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPSAtNjogWD0wLjM5MzUwMDAwIFk9MC44NzY2 MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KViA2ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUw MDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTc6IFg9MC45OTUwMDAw MCBZPTAuOTg3MDAwMDAgWj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMSAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC04OiBY PTAuMTg2MDAwMDAgWT0wLjk1MTAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDIgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtOTogWD0wLjM2OTAwMDAwIFk9MC45MDAwMDAwMCBaPTAuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAz ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTA6IFg9MC40MjkwMDAwMCBZPTAuMTkyMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gNCAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTExOiBYPTAuMjY3MDAwMDAgWT0w LjIxODAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjA5 NjAwMDAwIFk9MC4yNjIwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA2ICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MTM6IFg9MC4yNTMwMDAwMCBZPTAuNTg4MDAwMDAgWj0wLjAwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCk8gNyAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDguMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTE0OiBYPTAuNDA0MDAwMDAgWT0wLjQ1NjAwMDAwIFo9MC4w MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpPIDggICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPS0xNTogWD0wLjI2NTAwMDAwIFk9MC40Mzcw MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KTyA5ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0tMTY6IFg9MC4xMTEwMDAw MCBZPTAuNTQ0MDAwMDAgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMTAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTE3OiBY PTAuMDcwMDAwMDAgWT0wLjc4NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDExICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0xODogWD0wLjI0NTAwMDAwIFk9MC43NzkwMDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAx MiAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTk6IFg9MC40MDgwMDAwMCBZPTAuNzEyMDAwMDAg Wj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gMTMgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTIwOiBYPTAuMTM0MDAwMDAgWT0w LjA3NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDE0ICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0yMTogWD0wLjMx NTAwMDAwIFk9MC4wMzgwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxNSAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MjI6IFg9MC41MjY5MDAwMCBZPTAuMzY1MDAwMDAgWj0wLjEwMjAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCkN1MSAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMi4wMDAwICAg WjogMjkuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTIzOiBYPTAuNDYzMjAwMDAgWT0wLjY1NTAwMDAwIFo9MC45 MTgwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpDdTIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDIuMDAwMCAgIFo6IDI5LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQogICAxICAgICAgTlVNQkVSIE9GIFNZTU1FVFJZIE9Q RVJBVElPTlMNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDAN CiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICAxDQo= - ---559023410-851401618-1026660194=:506 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="monoclinic.klist" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ViAgICAgICAgICAgICAwICAgIDAgICAzOCAgIDc2ICAxLjAgLTEuNSAgMS41 DQogICAgICAgICAgICAgIDAgICAtMiAgIDM4ICAgNzYgIDEuMA0KICAgICAg ICAgICAgICAwICAgLTQgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAg MCAgIC02ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgICAtOCAg IDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMTAgICAzOCAgIDc2 ICAxLjANCiAgICAgICAgICAgICAgMCAgLTEyICAgMzggICA3NiAgMS4wDQog ICAgICAgICAgICAgIDAgIC0xNCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAg ICAgICAwICAtMTYgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAg LTE4ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0yMCAgIDM4 ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMjIgICAzOCAgIDc2ICAx LjANCiAgICAgICAgICAgICAgMCAgLTI0ICAgMzggICA3NiAgMS4wDQogICAg ICAgICAgICAgIDAgIC0yNiAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAg ICAwICAtMjggICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTMw ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0zMiAgIDM4ICAg NzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMzQgICAzOCAgIDc2ICAxLjAN CiAgICAgICAgICAgICAgMCAgLTM2ICAgMzggICA3NiAgMS4wDQpaICAgICAg ICAgICAgIDAgIC0zOCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAw ICAtMzYgICAzNiAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTM0ICAg MzQgICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0zMiAgIDMyICAgNzYg IDEuMA0KICAgICAgICAgICAgICAwICAtMzAgICAzMCAgIDc2ICAxLjANCiAg ICAgICAgICAgICAgMCAgLTI4ICAgMjggICA3NiAgMS4wDQogICAgICAgICAg ICAgIDAgIC0yNiAgIDI2ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAt MjQgICAyNCAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTIyICAgMjIg ICA3NiAgMS4wDQogICAgICAgICAgICAgIDAgIC0yMCAgIDIwICAgNzYgIDEu MA0KICAgICAgICAgICAgICAwICAtMTggICAxOCAgIDc2ICAxLjANCiAgICAg ICAgICAgICAgMCAgLTE2ICAgMTYgICA3NiAgMS4wDQogICAgICAgICAgICAg IDAgIC0xNCAgIDE0ICAgNzYgIDEuMA0KICAgICAgICAgICAgICAwICAtMTIg ICAxMiAgIDc2ICAxLjANCiAgICAgICAgICAgICAgMCAgLTEwICAgMTAgICA3 NiAgMS4wDQogICAgICAgICAgICAgIDAgICAtOCAgICA4ICAgNzYgIDEuMA0K ICAgICAgICAgICAgICAwICAgLTYgICAgNiAgIDc2ICAxLjANCiAgICAgICAg ICAgICAgMCAgIC00ICAgIDQgICA3NiAgMS4wDQogICAgICAgICAgICAgIDAg ICAtMiAgICAyICAgNzYgIDEuMA0KRyAgICAgICAgICAgICAwICAgIDAgICAg MCAgIDc2ICAxLjANCiAgICAgICAgICAgICAtMiAgICAwICAgIDAgICA3NiAg MS4wDQogICAgICAgICAgICAgLTQgICAgMCAgICAwICAgNzYgIDEuMA0KICAg ICAgICAgICAgIC02ICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAg ICAtOCAgICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMTAgICAg MCAgICAwICAgNzYgIDEuMA0KICAgICAgICAgICAgLTEyICAgIDAgICAgMCAg IDc2ICAxLjANCiAgICAgICAgICAgIC0xNCAgICAwICAgIDAgICA3NiAgMS4w DQogICAgICAgICAgICAtMTYgICAgMCAgICAwICAgNzYgIDEuMA0KICAgICAg ICAgICAgLTE4ICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0y MCAgICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMjIgICAgMCAg ICAwICAgNzYgIDEuMA0KICAgICAgICAgICAgLTI0ICAgIDAgICAgMCAgIDc2 ICAxLjANCiAgICAgICAgICAgIC0yNiAgICAwICAgIDAgICA3NiAgMS4wDQog ICAgICAgICAgICAtMjggICAgMCAgICAwICAgNzYgIDEuMA0KICAgICAgICAg ICAgLTMwICAgIDAgICAgMCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zMiAg ICAwICAgIDAgICA3NiAgMS4wDQogICAgICAgICAgICAtMzQgICAgMCAgICAw ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM2ICAgIDAgICAgMCAgIDc2ICAx LjANCkEgICAgICAgICAgIC0zOCAgICAwICAgIDAgICA3NiAgMS4wDQogICAg ICAgICAgICAtMzggICAtMiAgICAyICAgNzYgIDEuMA0KICAgICAgICAgICAg LTM4ICAgLTQgICAgNCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgIC02 ICAgIDYgICA3NiAgMS4wDQogICAgICAgICAgICAtMzggICAtOCAgICA4ICAg NzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMTAgICAxMCAgIDc2ICAxLjAN CiAgICAgICAgICAgIC0zOCAgLTEyICAgMTIgICA3NiAgMS4wDQogICAgICAg ICAgICAtMzggIC0xNCAgIDE0ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4 ICAtMTYgICAxNiAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTE4ICAg MTggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0yMCAgIDIwICAgNzYg IDEuMA0KICAgICAgICAgICAgLTM4ICAtMjIgICAyMiAgIDc2ICAxLjANCiAg ICAgICAgICAgIC0zOCAgLTI0ICAgMjQgICA3NiAgMS4wDQogICAgICAgICAg ICAtMzggIC0yNiAgIDI2ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAt MjggICAyOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTMwICAgMzAg ICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0zMiAgIDMyICAgNzYgIDEu MA0KICAgICAgICAgICAgLTM4ICAtMzQgICAzNCAgIDc2ICAxLjANCiAgICAg ICAgICAgIC0zOCAgLTM2ICAgMzYgICA3NiAgMS4wDQpNICAgICAgICAgICAt MzggIC0zOCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMzYg ICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTM0ICAgMzggICA3 NiAgMS4wDQogICAgICAgICAgICAtMzggIC0zMiAgIDM4ICAgNzYgIDEuMA0K ICAgICAgICAgICAgLTM4ICAtMzAgICAzOCAgIDc2ICAxLjANCiAgICAgICAg ICAgIC0zOCAgLTI4ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzgg IC0yNiAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMjQgICAz OCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTIyICAgMzggICA3NiAg MS4wDQogICAgICAgICAgICAtMzggIC0yMCAgIDM4ICAgNzYgIDEuMA0KICAg ICAgICAgICAgLTM4ICAtMTggICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAg IC0zOCAgLTE2ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggIC0x NCAgIDM4ICAgNzYgIDEuMA0KICAgICAgICAgICAgLTM4ICAtMTIgICAzOCAg IDc2ICAxLjANCiAgICAgICAgICAgIC0zOCAgLTEwICAgMzggICA3NiAgMS4w DQogICAgICAgICAgICAtMzggICAtOCAgIDM4ICAgNzYgIDEuMA0KICAgICAg ICAgICAgLTM4ICAgLTYgICAzOCAgIDc2ICAxLjANCiAgICAgICAgICAgIC0z OCAgIC00ICAgMzggICA3NiAgMS4wDQogICAgICAgICAgICAtMzggICAtMiAg IDM4ICAgNzYgIDEuMA0KTCAgICAgICAgICAgLTM4ICAgIDAgICAzOCAgIDc2 ICAxLjANCkVORA0K - ---559023410-851401618-1026660194=:506-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 15:12:52 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: k-list ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, I am a beginner with Wien97.10, and I have 2 questions, 1) Where can I find some resources for generating a k-list for a slab of Li2O (antifluorite unit cells separated by a vacuum region) with XCrysDen, as I seek a band structure calculation. 2) What are the maximum Dimensional Parameters, or what stops me from enlarging the parameters so that I have plenty of room for my slab calculation... is it a bad idea to increase the parameters so they are much larger than the minimum requirements of a calc.? Thanks for your time, sorry to ask such basic questions! Cheng Chen Nonours student Flinders University of South Australia ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 10:37:13 +0100 From: "Xiangyuan Cui" Subject: Re: [WIEN]: about mini ==== "Xiangyuan Cui" submitted the following contribution: ==== Hi, Liu > Dear Wien users and developers > > Now I try to use min_lapw to optimize the internal parameter of crystal. I > have two questions. > > (1) According the space-group symmetry, the position is (0.5, 0.25, x), so > I write the case.inM as > (0.0 0.0 1.0 0.5). It is right? Right! > (2) The min_lapw is working. But first the total energy decrease, after > about four iteration the total energy will increase(now the force is still > large), on the other hand, the force will decrease. My question is I can > take which structure as the ground state? The structure has minimal total > ernergy and large force; or the structure has minimal force but not minimal A coorect mini process will creat several or quite a lot converged *.scf files (case_1.scf, case_2.scf, etc). I wonder the energies you compared have not converged yet (since you just compare four ITERATION). Of course, the optimal geometry corresponds minimum total energy on ground state. Otherwise, you may need to refine other parameters. regards, xiangyuan Cui > - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 15:48:22 +0300 From: "B. Yanchitsky" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "B. Yanchitsky" submitted the following contribution: ==== "Dr. Sharat Chandra" wrote: > > Hi all > > This is in continuation of the previous mail. I have calculated the band > structure without the band character plotting and I get a band structure > with gaps in between with the attached klist. This can only mean that this > klist is incorrect. Can anybody please tell me what can be the problem? Or > should I calculate the band structure with the base centered Orthorhombic > klist? In which case will it be the correct one anyway? > Probably the problem is due to wrong struct file. The following portion ATOM=-22: X=0.52690000 Y=0.36500000 Z=0.10200000 MULT= 1 ISPLIT= 8 ATOM=-23: X=0.46320000 Y=0.65500000 Z=0.91800000 MULT= 1 ISPLIT= 8 is not consistent with any monoclinic space group. Regards, Bogdan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 10:55:56 -0400 From: Jeff Spirko Subject: [WIEN]: Re: about mini ==== Jeff Spirko submitted the following contribution: ==== On Mon, Jul 15, 2002 at 10:37:13AM +0100, Xiangyuan Cui wrote: > Hi, Liu > > (2) The min_lapw is working. But first the total energy decrease, after > > about four iteration the total energy will increase(now the force is still > > large), on the other hand, the force will decrease. My question is I can > > take which structure as the ground state? The structure has minimal total > > ernergy and large force; or the structure has minimal force but not > > minimal > A coorect mini process will creat several or quite a lot converged *.scf > files (case_1.scf, case_2.scf, etc). I wonder the energies you compared have > not converged yet (since you just compare four ITERATION). Of course, the > optimal geometry corresponds minimum total energy on ground state. > Otherwise, you may need to refine other parameters. Also, on the last iteration at any geometry, FOR should be set in the *.in2[c] file. This can be done by using the force convergence criterion (-fc 0.5, for example) or manually. As a question to the experts, is it okay to do something like the following: $ run_lapw -ec 0.001 -it -I # -I sets TOT in *.in2c file $ emacs *.in2c # Manually change to FOR $ run_lapw -i 1 -s lapw2c I'm hoping this will converge the calculation, then re-calculate the total forces on the last iteration without having to run lapw1c again. - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 15 Jul 2002 18:55:57 +0200 (CEST) From: =?iso-8859-1?q?Houda=20Imene?= Subject: [WIEN]: boron space group ==== =?iso-8859-1?q?Houda=20Imene?= submitted the following contribution: ==== - --0-1560328206-1026752157=:26338 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear wien user; I'm interested in structural properties of Boron, and it has the space group 166 (R-3m) with alpha=beta=gama different from 90°, with tow internal parmeters that I want to optimize. The problem is that when I choose 166 as space group, I'm asked if I want hexagonal or rhombohedral structure, and both answers lead to floating point error displayed on the window and the lines of atomic positions on the case.struct are simply deleeted! I don't know if it is a bug corresponding to this special space group or I done some mistake, since I started with an ad-hoc internal parameters. Any suggestion will be appreciated! Regards Houda Imane - --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! - --0-1560328206-1026752157=:26338 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Dear wien user;

I'm interested in structural properties of Boron, and it has the space group 166 (R-3m) with alpha=beta=gama different from 90°, with tow internal parmeters that I want to optimize.

The problem is that when I choose 166 as space group, I'm asked if I want hexagonal or rhombohedral structure, and both answers lead to floating point error displayed on the window and the lines of atomic positions on the case.struct are simply deleeted! I don't know if it is a bug corresponding to this special space group or I done some mistake, since I started with an ad-hoc internal parameters.

Any suggestion will be appreciated!

Regards

Houda Imane


Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !
- --0-1560328206-1026752157=:26338-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 10:27:32 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Dear Dr. Yanchitsky These two atom positions correspond to the 4b Wyckoff positions (x,y,z and x,-y,z) and all the other atoms correspond to the 2a positions (x,0,z). The problem is that If I give both x,y,z and x,-y,z positions for the Cu atoms, it puts them very very close to each other, so I have given only one of the two positions. I know that in this material only one of the positions is supposed to be occupied. Also, I have checked the BZ problem with a simple monoclinic structure and there also I get a BZ which corresponds to the base centered Orthorhombic structure. Regards Shara Chandra On Mon, 15 Jul 2002, B. Yanchitsky wrote: > Probably the problem is due to wrong struct file. > The following portion > > ATOM=-22: X=0.52690000 Y=0.36500000 Z=0.10200000 > MULT= 1 ISPLIT= 8 > > ATOM=-23: X=0.46320000 Y=0.65500000 Z=0.91800000 > MULT= 1 ISPLIT= 8 > > is not consistent with any monoclinic space group. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 07:18:50 +0000 From: "tayeb Meftah" Subject: Re: [WIEN]: boron space group ==== "tayeb Meftah" submitted the following contribution: ====

Bonjour Imene;

J'ai recu de votre part un grand nombre de mail concernant votre sujet de recherche.

C'est un domaine qui interesse notre equipe de recherche installée en Algerie. Je transmetterai

vos mails aux membres du laboratoires. Vous etes en quel Laboratoire actuellement?

Merci et a la prochaine

>From: Houda Imene
>Reply-To: wien@zeus.theochem.tuwien.ac.at
>To: wien@zeus.theochem.tuwien.ac.at
>Subject: [WIEN]: boron space group
>Date: Mon, 15 Jul 2002 18:55:57 +0200 (CEST)
>
>
>Dear wien user;
>
>I'm interested in structural properties of Boron, and it has the space group 166 (R-3m) with alpha=beta=gama different from 90°, with tow internal parmeters that I want to optimize.
>
>The problem is that when I choose 166 as space group, I'm asked if I want hexagonal or rhombohedral structure, and both answers lead to floating point error displayed on the window and the lines of atomic positions on the case.struct are simply deleeted! I don't know if it is a bug corresponding to this special space group or I done some mistake, since I started with an ad-hoc internal parameters.
>
>Any suggestion will be appreciated!
>
>Regards
>
>Houda Imane
>
>
>
>---------------------------------
>Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

MSN Photos is the easiest way to share and print your photos: Click Here
==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 15:30:28 +0800 From: "wan liu" Subject: Re: [WIEN]: Re: about mini ==== "wan liu" submitted the following contribution: ==== >From: Jeff Spirko >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: wien@zeus.theochem.tuwien.ac.at >Subject: [WIEN]: Re: about mini >Date: Mon, 15 Jul 2002 10:55:56 -0400 > >==== >Jeff Spirko >submitted the following contribution: >==== > >On Mon, Jul 15, 2002 at 10:37:13AM +0100, Xiangyuan Cui wrote: > > Hi, Liu > > > (2) The min_lapw is working. But first the total energy decrease, after > > > about four iteration the total energy will increase(now the force is still > > > large), on the other hand, the force will decrease. My question is I can > > > take which structure as the ground state? The structure has minimal total > > > ernergy and large force; or the structure has minimal force but not > > > minimal > > A coorect mini process will creat several or quite a lot converged *.scf > > files (case_1.scf, case_2.scf, etc). I wonder the energies you compared have > > not converged yet (since you just compare four ITERATION). Of course, the > > optimal geometry corresponds minimum total energy on ground state. > > Otherwise, you may need to refine other parameters. > >Also, on the last iteration at any geometry, FOR should be set in >the *.in2[c] file. This can be done by using the force convergence >criterion (-fc 0.5, for example) or manually. > >As a question to the experts, is it okay to do something like the >following: > > $ run_lapw -ec 0.001 -it -I # -I sets TOT in *.in2c file > $ emacs *.in2c # Manually change to FOR > $ run_lapw -i 1 -s lapw2c > >I'm hoping this will converge the calculation, then re-calculate the >total forces on the last iteration without having to run lapw1c again. Thank you very much! First I run init_lapw, then run min_lapw. From case.scf_mini, I find the total energy isn't decrease, on the other hand the force will decrease. Your suggestion is to set FOR in the case.in2c to improve the calculated force. The default term in min_lapw is "run_lapw -I -fc 1." As you said that the I-option in run_lapw sets TOT in case.in2c file. So, I want to delete the -I-option in min_lapw, and set FOR in case.in2c, and run the min_lapw directly. I don't know if it is right? Best wish! Liu > >-- >Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> > >The study of non-linear physics is like the study of non-elephant biology. > >All theoretical chemistry is really physics; >and all theoretical chemists know it. -- Richard P. Feynman >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 00:42:43 -0700 (PDT) From: sayede adlane Subject: Re: [WIEN]: boron space group ==== sayede adlane submitted the following contribution: ==== Hi houda, send me your struct file Adlane. - --- Houda Imene wrote: > > Dear wien user; > > I'm interested in structural properties of Boron, > and it has the space group 166 (R-3m) with > alpha=beta=gama different from 90°, with tow > internal parmeters that I want to optimize. > > The problem is that when I choose 166 as space > group, I'm asked if I want hexagonal or rhombohedral > structure, and both answers lead to floating point > error displayed on the window and the lines of > atomic positions on the case.struct are simply > deleeted! I don't know if it is a bug corresponding > to this special space group or I done some mistake, > since I started with an ad-hoc internal parameters. > > Any suggestion will be appreciated! > > Regards > > Houda Imane > > > > --------------------------------- > Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en > français ! > __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 10:32:15 +0200 (CEST) From: =?iso-8859-1?q?Houda=20Imene?= Subject: Re: [WIEN]: boron space group ==== =?iso-8859-1?q?Houda=20Imene?= submitted the following contribution: ==== - --0-1445261461-1026808335=:67074 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Adlane; In fact the mane problem is the struct file generation. Since i have no idea about the values of internal parameters, I usually start with any random values (close to physical tolerance) and optimize... In this case, the wien utility to generate the space group 166 do not help! It only display an error message (floatin point error) to learn more about Boron structure go to http://cst-www.nrl.navy.mil/lattice/struk/alphaB.html Thanks sayede adlane a écrit : ==== sayede adlane submitted the following contribution: ==== Hi houda, send me your struct file Adlane. - --- Houda Imene wrote: > > Dear wien user; > > I'm interested in structural properties of Boron, > and it has the space group 166 (R-3m) with > alpha=beta=gama different from 90°, with tow > internal parmeters that I want to optimize. > > The problem is that when I choose 166 as space > group, I'm asked if I want hexagonal or rhombohedral > structure, and both answers lead to floating point > error displayed on the window and the lines of > atomic positions on the case.struct are simply > deleeted! I don't know if it is a bug corresponding > to this special space group or I done some mistake, > since I started with an ad-hoc internal parameters. > > Any suggestion will be appreciated! > > Regards > > Houda Imane > > > > --------------------------------- > Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en > français ! > __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! - --0-1445261461-1026808335=:67074 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Adlane;

In fact the mane problem is the struct file generation. Since i have no idea about the values of internal parameters, I usually start with any random values (close to physical tolerance) and optimize... In this case, the wien utility to generate the space group 166 do not help! It only display an error message (floatin point error)

to learn more about Boron structure go to http://cst-www.nrl.navy.mil/lattice/struk/alphaB.html

Thanks

  sayede adlane <dft22000@yahoo.fr> a écrit :

====
sayede adlane
submitted the following contribution:
====

Hi houda, send me your struct file
Adlane.
--- Houda Imene wrote:
>
> Dear wien user;
>
> I'm interested in structural properties of Boron,
> and it has the space group 166 (R-3m) with
> alpha=beta=gama different from 90°, with tow
> internal parmeters that I want to optimize.
>
> The problem is that when I choose 166 as space
> group, I'm asked if I want hexagonal or rhombohedral
> structure, and both answers lead to floating point
> error displayed on the window and the lines of
> atomic positions on the case.struct are simply
> deleeted! I don't know if it is a bug corresponding
> to this special space group or I done some mistake,
> since I started with an ad-hoc ! internal parameters.
>
> Any suggestion will be appreciated!
>
> Regards
>
> Houda Imane
>
>
>
> ---------------------------------
> Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en
> français !
>


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !
- --0-1445261461-1026808335=:67074-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 20:50:28 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: about mini ==== Peter Blaha submitted the following contribution: ==== > Now I try to use min_lapw to optimize the internal parameter of crystal. I > have two questions. > > (1) According the space-group symmetry, the position is (0.5, 0.25, x), so > I write the case.inM as > (0.0 0.0 1.0 0.5). It is right? Most likely (local rotations?), but it is not necessary to restrict the other positions to zero (since they have no forces anyway) > (2) The min_lapw is working. But first the total energy decrease, after > about four iteration the total energy will increase(now the force is still > large), on the other hand, the force will decrease. My question is I can > take which structure as the ground state? The structure has minimal total > ernergy and large force; or the structure has minimal force but not minimal > total ernergy? If your calculations are done properly, zero force and lowest E-tot must coincide. If this does not happen, something is wrong. Either the symmetry or too small RKmax, GMAX, k-mesh ? Send: grep :ENE *mini grep :FORxx *mini (where xx is the atom in question) grep :POSxx *mini In a regular nonmagnetic case it is not necessary to change anything and just jun min_lapw The default switches -fc 1.0 and -I should be ok. Make sure your case converges within the default 20 iterations. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 20:56:27 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Re: about mini ==== Peter Blaha submitted the following contribution: ==== > As a question to the experts, is it okay to do something like the > following: > > $ run_lapw -ec 0.001 -it -I # -I sets TOT in *.in2c file > $ emacs *.in2c # Manually change to FOR > $ run_lapw -i 1 -s lapw2c > > I'm hoping this will converge the calculation, then re-calculate the > total forces on the last iteration without having to run lapw1c again. No. Two reasons: mixer will be totally confused, since it gets twice the same density for mixing and also the scf file will be strange, since you the iteration number is twice the same (wrong e-tot, forces). Secondly: There"s no guarantee that your forces are converged. A total energy convergence of 1 mRy only may give absolute nonsense for the forces. You can first converge the energy (-ec 0.0001( and then the forces (-fc 1.0). With this you are sure that both quantities are converged, since there are (few) strange cases, where the forces may be converged before E-tot is. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 20:59:24 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: about monoclinic brillouin zone ==== Peter Blaha submitted the following contribution: ==== > These two atom positions correspond to the 4b Wyckoff positions (x,y,z and > x,-y,z) and all the other atoms correspond to the 2a positions (x,0,z). > The problem is that If I give both x,y,z and x,-y,z positions for the Cu > atoms, it puts them very very close to each other, so I have given only > one of the two positions. I know that in this material only one of the > positions is supposed to be occupied. Also, I have checked the BZ problem > with a simple monoclinic structure and there also I get a BZ which > corresponds to the base centered Orthorhombic structure. You cannot do partial occupations in WIEN2k. You must reduce symmetry and then occupy only one of those two positions, but this cannot be done in this spacegroup. 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 21:03:46 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: boron space group ==== Peter Blaha submitted the following contribution: ==== > I'm interested in structural properties of Boron, and it has the space group 166 (R-3m) with alpha=beta=gama different from 90°, with tow internal parmeters that I want to optimize. > > The problem is that when I choose 166 as space group, I'm asked if I want hexagonal or rhombohedral structure, and both answers lead to floating point error displayed on the window and the lines of atomic positions on the case.struct are simply deleeted! I don't know if it is a bug corresponding to this special space group or I done some mistake, since I started with an ad-hoc internal parameters. A rhombohedral space group requires the hexagonal lattice parameters !!!! (There is a rhombohedral and a hexagonal setting please check a good book on crystallography). The UG tells you how to convert rhombohedral lattice parameters into hexagonal ones. Strangly enough, WIEN requires rhombohedral positions, but a program can automatically convert this for you, but you must tell the program if you entered R or hex coordinates. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 16 Jul 2002 21:08:20 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: k-list ==== Peter Blaha submitted the following contribution: ==== > I am a beginner with Wien97.10, and I have 2 questions, > > 1) Where can I find some resources for generating a k-list for a slab of Li2O > (antifluorite unit cells separated by a vacuum region) with XCrysDen, as I seek > a band structure calculation. You just need to plot them in 2 dimensions. Xcrysden shows you a very flat cell. Just ignore the dispersion in the z-direction. > 2) What are the maximum Dimensional Parameters, or what stops me from enlarging > the parameters so that I have plenty of room for my slab calculation... is it a > bad idea to increase the parameters so they are much larger than the minimum > requirements of a calc.? The memory of your computer! Larger parameters means large memory requirements. If your computer is large enough, you can of course use large Parameters even for a small case. (WIEN2k with dynamic allocation does this automatically). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 11:33:51 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: k-list ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Peter, Thanks for your response, but I am not sure what you mean by plotting them in 2 dimensions... I actually have very little idea how to generate a k list, sorry to be so vague, could you give me some 'idiots' advice? Thanks, Cheng Quoting Peter Blaha : > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I am a beginner with Wien97.10, and I have 2 questions, > > > > 1) Where can I find some resources for generating a k-list for a slab of > Li2O > > (antifluorite unit cells separated by a vacuum region) with XCrysDen, as I > seek > > a band structure calculation. > > You just need to plot them in 2 dimensions. Xcrysden shows you a very flat > cell. Just ignore the dispersion in the z-direction. > > > 2) What are the maximum Dimensional Parameters, or what stops me from > enlarging > > the parameters so that I have plenty of room for my slab calculation... is > it a > > bad idea to increase the parameters so they are much larger than the > minimum > > requirements of a calc.? > > The memory of your computer! Larger parameters means large memory > requirements. If your computer is large enough, you can of course use > large Parameters even for a small case. (WIEN2k with dynamic allocation > does this automatically). > > Regards > > > 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@theochem.tuwien.ac.at WWW: > http://www.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 14:04:59 +0800 From: "wan liu" Subject: Re: [WIEN]: about mini ==== "wan liu" submitted the following contribution: ==== >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: about mini >Date: Tue, 16 Jul 2002 20:50:28 +0200 (MEST) > >==== >Peter Blaha >submitted the following contribution: >==== > > > Now I try to use min_lapw to optimize the internal parameter of crystal. I > > have two questions. > > > > (1) According the space-group symmetry, the position is (0.5, 0.25, x), so > > I write the case.inM as > > (0.0 0.0 1.0 0.5). It is right? > >Most likely (local rotations?), but it is not necessary to restrict the >other positions to zero (since they have no forces anyway) If they have forces, it means the structure file is wrong? > > > (2) The min_lapw is working. But first the total energy decrease, after > > about four iteration the total energy will increase(now the force is still > > large), on the other hand, the force will decrease. My question is I can > > take which structure as the ground state? The structure has minimal total > > ernergy and large force; or the structure has minimal force but not minimal > > total ernergy? > >If your calculations are done properly, zero force and lowest E-tot must >coincide. If this does not happen, something is wrong. Either the symmetry >or too small RKmax, GMAX, k-mesh ? > >Send: > >grep :ENE *mini >grep :FORxx *mini (where xx is the atom in question) >grep :POSxx *mini > >In a regular nonmagnetic case it is not necessary to change anything >and just jun min_lapw >The default switches -fc 1.0 and -I should be ok. Make sure your case >converges within the default 20 iterations. > >Regards > 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£http://www.hotmail.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 15:39:38 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Dear Prof. Blaha What you say is true. I can not reduce the symmetry for this spacegroup. But to be able to calculate the band structure, I want to know, whether it is all right to shift the Cu atoms a little apart manually to satisfy the occupancy conditions (to positions which are different from those I get from the Rietveldt refinement of the structure) and what effect is it expected have on the ultimate band structure? I am asking this as it takes almost a month to complete the SCF iteration on my 2 processor server. Regards Sharat Chandra > You cannot do partial occupations in WIEN2k. You must reduce symmetry and > then occupy only one of those two positions, but this cannot be done in > this spacegroup. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 16:44:08 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1026942248=:8621 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Prof. Blaha I have tried the CuV2O5 structure with the Cu atoms shifted a little from their actual positions but with Cu atoms having multiplicity 2. Even now I find that the XCrysden shows the BZ to be base centered Orthorhombic type rather than base centered monoclinic. I have also found that the struct file now has zero number of symmetry operations instead of the usual one. If you have any ideas about how to prepare the correct input file for this compound, I will be very grateful. Regards Sharat Chandra > > > These two atom positions correspond to the 4b Wyckoff positions (x,y,z and > > x,-y,z) and all the other atoms correspond to the 2a positions (x,0,z). > > The problem is that If I give both x,y,z and x,-y,z positions for the Cu > > atoms, it puts them very very close to each other, so I have given only > > one of the two positions. I know that in this material only one of the > > positions is supposed to be occupied. Also, I have checked the BZ problem > > with a simple monoclinic structure and there also I get a BZ which > > corresponds to the base centered Orthorhombic structure. - ---559023410-851401618-1026942248=:8621 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="lapw.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: new struct file Q3VWMk81LUNtKDgpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQpDWFogTEFUVElDRSxOT05FUVVJVi4gQVRPTVM6 MjM4X0JtICAgICAgICAgICAgICAgICAgICAgICAgICANCk1PREUgT0YgQ0FM Qz1SRUxBIHVuaXQ9Ym9ocg0KIDI4LjgxODMzNSAxOS4wOTE5MTEgIDYuODU1 OTI5IDkwLjAwMDAwMCA5MC4wMDAwMDAxMDYuNzEzMDAwDQpBVE9NPSAtMTog WD0wLjMzNzAwMDAwIFk9MC4wOTQ0MDAwMCBaPTAuMDAwMDAwMDANCiAgICAg ICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViAxICAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAy My4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMjogWD0wLjEyMDMw MDAwIFk9MC4xMTY3MDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxU PSAxICAgICAgICAgIElTUExJVD0gOA0KViAyICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wDQpMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjI5NjYwMDAwIFk9MC40 MDY1MDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAg ICAgIElTUExJVD0gOA0KViAzICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAw MDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wDQpMT0NBTCBST1QgTUFU UklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAN CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwDQpBVE9NPSAtNDogWD0wLjIyMTkwMDAwIFk9MC41OTE5MDAwMCBa PTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJ VD0gOA0KViA0ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUwMDAgUk1U PSAgICAxLjU2MDAgICBaOiAyMy4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtNTogWD0wLjE3NDAwMDAwIFk9MC45MDE4MDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViA1 ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2 MDAgICBaOiAyMy4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtNjog WD0wLjM5MzUwMDAwIFk9MC44NzY2MDAwMCBaPTAuNTAwMDAwMDANCiAgICAg ICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViA2ICAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAy My4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtNzogWD0wLjk5NTAw MDAwIFk9MC45ODcwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxU PSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtODogWD0wLjE4NjAwMDAwIFk9MC45 NTEwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAg ICAgIElTUExJVD0gOA0KTyAyICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAw MTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFU UklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAN CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwDQpBVE9NPSAtOTogWD0wLjM2OTAwMDAwIFk9MC45MDAwMDAwMCBa PTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJ VD0gOA0KTyAzICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0xMDogWD0wLjQyOTAwMDAwIFk9MC4xOTIwMDAwMCBaPTAuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA0 ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMTog WD0wLjI2NzAwMDAwIFk9MC4yMTgwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAg ICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA1ICAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAg OC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjA5NjAw MDAwIFk9MC4yNjIwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxU PSAxICAgICAgICAgIElTUExJVD0gOA0KTyA2ICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMzogWD0wLjI1MzAwMDAwIFk9MC41 ODgwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAg ICAgIElTUExJVD0gOA0KTyA3ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAw MTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFU UklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAN CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwDQpBVE9NPS0xNDogWD0wLjQwNDAwMDAwIFk9MC40NTYwMDAwMCBa PTAuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJ VD0gOA0KTyA4ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0xNTogWD0wLjI2NTAwMDAwIFk9MC40MzcwMDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA5 ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xNjog WD0wLjExMTAwMDAwIFk9MC41NDQwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAg ICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxMCAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAg OC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xNzogWD0wLjA3MDAw MDAwIFk9MC43ODUwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxU PSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxMSAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xODogWD0wLjI0NTAwMDAwIFk9MC43 NzkwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAg ICAgIElTUExJVD0gOA0KTyAxMiAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAw MTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFU UklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAN CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwDQpBVE9NPS0xOTogWD0wLjQwODAwMDAwIFk9MC43MTIwMDAwMCBa PTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJ VD0gOA0KTyAxMyAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjIwMDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0yMDogWD0wLjEzNDAwMDAwIFk9MC4wNzUwMDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAx NCAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0yMTog WD0wLjMxNTAwMDAwIFk9MC4wMzgwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAg ICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxNSAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAg OC4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0yMjogWD0wLjUyMzgw MDAwIFk9MC4zNTg4MDAwMCBaPTAuMjAwMDAwMDANCiAgICAgICAgICBNVUxU PSAyICAgICAgICAgIElTUExJVD0gMA0KQVRPTT0tMjI6WD0gMC41MjM4MDAw MCBZPTAuMzU4ODAwMDAgWj0wLjgwMDAwMDAwDQpDdTEgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDA1MDAwMCBSTVQ9ICAgIDIuMDAwMCAgIFo6IDI5LjAN CkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAwLjAwMDAwMDANCkFUT009LTIzOiBYPTAuNDYwMjAwMDAg WT0wLjY0OTkwMDAwIFo9MC4yMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDIg ICAgICAgICAgSVNQTElUPSAwDQpBVE9NPS0yMzpYPSAwLjQ2MDIwMDAwIFk9 MC42NDk5MDAwMCBaPTAuODAwMDAwMDANCkN1MiAgICAgICAgTlBUPSAgNzgx ICBSMD0wLjAwMDUwMDAwIFJNVD0gICAgMi4wMDAwICAgWjogMjkuMA0KTE9D QUwgUk9UIE1BVFJJWDogICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAw MDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4w MDAwMDAwIDAuMDAwMDAwMA0KICAgMCAgICAgIE5VTUJFUiBPRiBTWU1NRVRS WSBPUEVSQVRJT05TDQo= - ---559023410-851401618-1026942248=:8621 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="cuv2o5.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: old struct file VjJPNS1DbSg4KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ1haIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOjIzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDI4LjgxODMzNSAxOS4wOTE5MTEgIDYuODU1 OTI5IDkwLjAwMDAwMCA5MC4wMDAwMDAxMDYuNzEzMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4zMzcwMDAwMCBZPTAuMDk0NDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNClYgMSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMS41NjAwICAgWjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuMTIwMzAwMDAgWT0w LjExNjcwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpWIDIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAwNTAwMCBSTVQ9ICAgIDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjI5 NjYwMDAwIFk9MC40MDY1MDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KViAzICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTQ6IFg9MC4yMjE5MDAwMCBZPTAuNTkxOTAwMDAgWj0wLjUwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNClYgNCAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMS41NjAwICAg WjogMjMuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009IC01OiBYPTAuMTc0MDAwMDAgWT0wLjkwMTgwMDAwIFo9MC41 MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpWIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDEuNTYwMCAgIFo6IDIzLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPSAtNjogWD0wLjM5MzUwMDAwIFk9MC44NzY2 MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KViA2ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUw MDAgUk1UPSAgICAxLjU2MDAgICBaOiAyMy4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTc6IFg9MC45OTUwMDAw MCBZPTAuOTg3MDAwMDAgWj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMSAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC04OiBY PTAuMTg2MDAwMDAgWT0wLjk1MTAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDIgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtOTogWD0wLjM2OTAwMDAwIFk9MC45MDAwMDAwMCBaPTAuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAz ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTA6IFg9MC40MjkwMDAwMCBZPTAuMTkyMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gNCAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTExOiBYPTAuMjY3MDAwMDAgWT0w LjIxODAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDUgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjA5 NjAwMDAwIFk9MC4yNjIwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyA2ICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MTM6IFg9MC4yNTMwMDAwMCBZPTAuNTg4MDAwMDAgWj0wLjAwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCk8gNyAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDguMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTE0OiBYPTAuNDA0MDAwMDAgWT0wLjQ1NjAwMDAwIFo9MC4w MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpPIDggICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPS0xNTogWD0wLjI2NTAwMDAwIFk9MC40Mzcw MDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAg IElTUExJVD0gOA0KTyA5ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0tMTY6IFg9MC4xMTEwMDAw MCBZPTAuNTQ0MDAwMDAgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0g MSAgICAgICAgICBJU1BMSVQ9IDgNCk8gMTAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTE3OiBY PTAuMDcwMDAwMDAgWT0wLjc4NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPIDExICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPS0xODogWD0wLjI0NTAwMDAwIFk9MC43NzkwMDAwMCBaPTAuNTAwMDAw MDANCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAx MiAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIw MDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTk6IFg9MC40MDgwMDAwMCBZPTAuNzEyMDAwMDAg Wj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk8gMTMgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTIwOiBYPTAuMTM0MDAwMDAgWT0w LjA3NTAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpPIDE0ICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPS0yMTogWD0wLjMx NTAwMDAwIFk9MC4wMzgwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBN VUxUPSAxICAgICAgICAgIElTUExJVD0gOA0KTyAxNSAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgOC4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0t MjI6IFg9MC41MjY5MDAwMCBZPTAuMzY1MDAwMDAgWj0wLjEwMjAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgNCkN1MSAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMi4wMDAwICAg WjogMjkuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009LTIzOiBYPTAuNDYzMjAwMDAgWT0wLjY1NTAwMDAwIFo9MC45 MTgwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpDdTIgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDIuMDAwMCAgIFo6IDI5LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQogICAxICAgICAgTlVNQkVSIE9GIFNZTU1FVFJZIE9Q RVJBVElPTlMNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDAN CiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICAxDQo= - ---559023410-851401618-1026942248=:8621-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 04:45:50 -0700 (PDT) From: hamid salehi Subject: [WIEN]: band structure ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started Band structure and in Xspaghetti-C, got this message "case.insp.1st line should started with ### what it the mean? and not derived band structure figure. Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 06:10:10 -0700 (PDT) From: hamid salehi Subject: [none] ==== hamid salehi submitted the following contribution: ==== Dear wien2k users; with best wishes for all you .When the "run Scf"in wien2k,the " Stop error" in Lapw1 displayed.What does it mean?Thank or what is its reason? What should be done for eliminating it? best wishes H-Salehi dept of physics Ferdowsi university Mashhad IRAN post boxs 1436 postcode 91775 __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 15:56:05 +0200 (CEST) From: =?iso-8859-1?q?Houda=20Imene?= Subject: [WIEN]: Re: ==== =?iso-8859-1?q?Houda=20Imene?= submitted the following contribution: ==== - --0-830740164-1026914165=:11453 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit May be you must give more details... the lapw1.error for example! Regards hamid salehi a écrit : ==== hamid salehi submitted the following contribution: ==== Dear wien2k users; with best wishes for all you .When the "run Scf"in wien2k,the " Stop error" in Lapw1 displayed.What does it mean?Thank or what is its reason? What should be done for eliminating it? best wishes H-Salehi dept of physics Ferdowsi university Mashhad IRAN post boxs 1436 postcode 91775 __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------------------------------- Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français ! - --0-830740164-1026914165=:11453 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

May be you must give more details... the lapw1.error for example!

Regards

  hamid salehi <salehihamid@yahoo.com> a écrit :

====
hamid salehi
submitted the following contribution:
====

Dear wien2k users;


with best wishes for all you .When the "run Scf"in
wien2k,the " Stop error" in Lapw1 displayed.What
does it mean?Thank or what is its reason?
What should be done for eliminating it?
best wishes
H-Salehi
dept of physics
Ferdowsi university
Mashhad IRAN
post boxs 1436
postcode 91775



__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !
- --0-830740164-1026914165=:11453-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 22:12:01 +0300 From: "B. Yanchitsky" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "B. Yanchitsky" submitted the following contribution: ==== "Dr. Sharat Chandra" wrote: > > Dear Prof. Blaha > > I have tried the CuV2O5 structure with the Cu atoms shifted a little from > their actual positions but with Cu atoms having multiplicity 2. Even now I > find that the XCrysden shows the BZ to be base centered Orthorhombic type > rather than base centered monoclinic. I have also found that the struct > file now has zero number of symmetry operations instead of the usual one. > If you have any ideas about how to prepare the correct input file for this > compound, I will be very grateful. > Dear Sharat, lapw.struct is correct (after x symmetry, *.struct_st file contains 2 operations as it should be.) It is still being unclear for me what is your problem. If z is very small (Z=0.10200000) and the cell has monoclinic symmetry, then it would be a reasonable guess that z=0. with z=0 4b is transformed to 2a with mult=1 and no problem with extremely small distance between atoms. Regards, Bogdan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 17 Jul 2002 23:57:07 +0200 (CEST) From: Stefaan.Cottenier@fys.kuleuven.ac.be Subject: Re: [WIEN]: band structure ==== Stefaan.Cottenier@fys.kuleuven.ac.be submitted the following contribution: ==== > ==== > hamid salehi > submitted the following contribution: > ==== > > Dear wien users. > Ihave started Band structure and in Xspaghetti-C, got > this message "case.insp.1st line should started with > ### what it the mean? and not derived band structure > figure. In wien2k, the format of the input file for spaghetti has changed compared to wien97. You are using a wien97-file. Look for a template of the new case.insp in SRC_templates. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 18 Jul 2002 10:17:58 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: Re: [WIEN]: about monoclinic brillouin zone ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Dear Prof. Bogdan My problem is that I am not able to get the correct base centered monoclinic BZ with this file. Instead I get a BZ which looks like that of base centered Orthorhombic. Base centered Monoclinic has a parallopiped BZ whereas base centered Orthorhombic has one which looks like a hexagonal traversed along the z direction (Bradley and Kracknell). I want to know how this problem can be solved, because if I do the band structure calculations with the base centered monoclinic klist, after running spaghetti I get a band structure with gaps in between different directions. If I just use the klist generated by XCrysden, will it be correct band structure? Regards Sharat Chandra > lapw.struct is correct (after x symmetry, *.struct_st file contains > 2 operations as it should be.) > It is still being unclear for me what is your problem. If z is very small > (Z=0.10200000) and the cell has monoclinic symmetry, > then it would be a reasonable guess that z=0. with z=0 > 4b is transformed to 2a with mult=1 and no problem > with extremely small distance between atoms. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #27 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #28 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, July 25 2002 Volume 2002 : Number 028 ---------------------------------------------------------------------- Date: Thu, 18 Jul 2002 16:28:08 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: Generating a k-list ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, I have a very elementary question, I have no idea how to generate a k-list through xcrysden, I was wondering if someone could point me i some direction as to resources, I have a Li2O slab, and the BZ is a rectangular prism, I am not sure what process is required to select points in this 3D zone, Thanks! Cheng Chen honours student Flinders University of South Australia ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 19 Jul 2002 12:13:56 +0100 (BST) From: pauhar@chem.gla.ac.uk Subject: [WIEN]: Unoccupied DOS ==== pauhar@chem.gla.ac.uk submitted the following contribution: ==== Dear Wien Users, I am using wien97 to calculate a supercell with a core-hole. When l look at the unoccupied DOS it is calculated up to 18eV, whereas l am able to investigate up to 40 or 50 eV beyond the fermi level if the calculation is done using a normal unit cell in the .struct file. I have increased the value of Emax set in .in1 and .klist but this makes no difference. Also the value of Emax in .int is set to the lowest energy of the highest band in .outputt to make sure that there is no problem with the range being plotted. Is there some other parameter that l could alter which is limiting the calculation? Thanks in advance for your help, Paula ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 19 Jul 2002 15:08:18 +0200 From: Florent Boucher Subject: Re: [WIEN]: Unoccupied DOS ==== Florent Boucher submitted the following contribution: ==== Dear Paula, it seems that your problem is directly corralated to the value of NUME. This a parameter for the compilation and by default the value is 300 (for WIEN97). It defines the maximum number of eigen velues that can be computed. Using siteconfig your can increase it and then recompile WIEN97. Regards Florent pauhar@chem.gla.ac.uk wrote: >==== >pauhar@chem.gla.ac.uk >submitted the following contribution: >==== > >Dear Wien Users, > >I am using wien97 to calculate a supercell with a core-hole. When l look at the >unoccupied DOS it is calculated up to 18eV, whereas l am able to investigate up >to 40 or 50 eV beyond the fermi level if the calculation is done using a normal >unit cell in the .struct file. I have increased the value of Emax set in .in1 >and .klist but this makes no difference. Also the value of Emax in .int is set >to the lowest energy of the highest band in .outputt to make sure that there is >no problem with the range being plotted. Is there some other parameter that l >could alter which is limiting the calculation? > >Thanks in advance for your help, >Paula >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > - -- -------------------------------------------------------------------------- | Florent BOUCHER | | | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 20 Jul 2002 00:02:36 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Generating a k-list ==== Peter Blaha submitted the following contribution: ==== > I have a very elementary question, I have no idea how to generate a k-list > through xcrysden, > > I was wondering if someone could point me i some direction as to resources, I > have a Li2O slab, and the BZ is a rectangular prism, I am not sure what process > is required to select points in this 3D zone, If you do a slab, usually this means you want to simulate a surface. A surface has only 2D periodicity and thus a 2D BZ. In xcrysden your BZ should be very small along the z direction (when a cell is large in direct space, it is very small in reciprocal space.) First click on "display reciprocal lattice vectors". Just click at the red dot (this is the center of the BZ, i.e. Gamma) and then at some other points at the border of the BZ. This will define lines along which the bands are calculated. There is no "rule" which directions to go. Either you want to compare with a destinct experiment and thus choose the experimental directions, or just go in 100 and 110 direction. It also depends on symmetry,.... Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 20 Jul 2002 00:11:33 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: about mini ==== Peter Blaha submitted the following contribution: ==== > > > Now I try to use min_lapw to optimize the internal parameter of > crystal. I > > > have two questions. > > > > > > (1) According the space-group symmetry, the position is (0.5, 0.25, x), > >Most likely (local rotations?), but it is not necessary to restrict the > >other positions to zero (since they have no forces anyway) > > If they have forces, it means the structure file is wrong? Usually 0.5 or 0.25 means a special position in a spacegroup and these positions must not change. (Of course x could still be a free parameter and x=0.5 is just an experimental estimate or so. You must check your specific spacegroup.). If you have a local rotation matrix different from the unit matrix (see your struct file), than it is posible to have forces in other directions. But normally I would say: Yes if you have forces in x or y direction, something is wrong in your struct file.... Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 22 Jul 2002 16:37:24 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: Generating a k-list ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Prof Blaha, Thanks so much for your valuable advice. I am now comfortable to work with generating a k -list! My conventional BZ is the same as the primitive BZ, I was seeking some advice about how many k-paths (points) is 'reasonable'... Thanks for the starting point! Cheng Quoting Peter Blaha : > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I have a very elementary question, I have no idea how to generate a > k-list > > through xcrysden, > > > > I was wondering if someone could point me i some direction as to resources, > I > > have a Li2O slab, and the BZ is a rectangular prism, I am not sure what > process > > is required to select points in this 3D zone, > > If you do a slab, usually this means you want to simulate a surface. > A surface has only 2D periodicity and thus a 2D BZ. > > In xcrysden your BZ should be very small along the z direction (when a > cell is large in direct space, it is very small in reciprocal space.) > First click on "display reciprocal lattice vectors". > Just click at the red dot (this is the center of the BZ, i.e. Gamma) and > then at some other points at the border of the BZ. This will define lines > along which the bands are calculated. > There is no "rule" which directions to go. Either you want to compare with > a destinct experiment and thus choose the experimental directions, or just > go in 100 and 110 direction. It also depends on symmetry,.... > > Regards > > 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@theochem.tuwien.ac.at WWW: > http://www.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 22 Jul 2002 16:51:48 +0200 (MEST) From: Pio =?ISO-8859-1?Q?B=E4ttig?= Subject: [WIEN]: Problems compiling Wien2k with IFC ==== Pio =?ISO-8859-1?Q?B=E4ttig?= submitted the following contribution: ==== Dear Wien-users I encountered a small problem while trying to compile wien2k_02 with IFC 6.0 on a PIII/800. I obtain the following errors. I retried to compile on another machine (AMD Duron 1200), with the same effects. I managed to compile it without errors on a DEC Alpha with Tru64 and the Compaq compilers. Thank you very much for any hints Pio Bättig done. Compile messages for each SRC_* directory can be found in the file "compile.msg". Compile time errors (if any) were: SRC_lapw3/compile.msg:Error FCE22 : Module KGRID USEd by subroutine RECPR in work.pc not found SRC_lapw3/compile.msg:Error 24 at (25:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (25:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (25:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (41:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (41:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 395 at (113:recpr.f) : This entity is not an array and must not be subscripted SRC_lapw3/compile.msg:Error 43 at (115:recpr.f) : Label 6 refers to a non-executable statement at (114:recpr.f) SRC_lapw3/compile.msg:Error 43 at (115:recpr.f) : Label 6 refers to a non-executable statement at (111:recpr.f) SRC_lapw3/compile.msg:Error 65 at (115:recpr.f) : This statement cannot terminate a DO loop SRC_lapw3/compile.msg:Error 24 at (115:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (115:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (115:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 43 at (116:recpr.f) : Label 7 refers to a non-executable statement at (99:recpr.f) SRC_lapw3/compile.msg:Error 43 at (116:recpr.f) : Label 7 refers to a non-executable statement at (83:recpr.f) SRC_lapw3/compile.msg:Error 24 at (116:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (116:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 43 at (119:recpr.f) : Label 8 refers to a non-executable statement at (118:recpr.f) SRC_lapw3/compile.msg:Error 65 at (119:recpr.f) : This statement cannot terminate a DO loop SRC_lapw3/compile.msg:Error 24 at (119:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (119:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 24 at (119:recpr.f) : syntax error SRC_lapw3/compile.msg:Error 395 at (137:recpr.f) : This entity is not an array and must not be subscripted SRC_lapw3/compile.msg:Error 395 at (149:recpr.f) : This entity is not an array and must not be subscripted SRC_lapw3/compile.msg:Error 395 at (151:recpr.f) : This entity is not an array and must not be subscripted SRC_lapw3/compile.msg:25 Errors SRC_lapw3/compile.msg:make[1]: *** [recpr.o] Error 1 SRC_lapw3/compile.msg:make: *** [complex] Error 2 Here the full messages from SRC_lapw3/compile.msg: external subroutine RECPR Error FCE22 : Module KGRID USEd by subroutine RECPR in work.pc not found allocate (absk(nkd+1), kzz(3,nkd+1),inst(nkd)) ^ Error 24 at (25:recpr.f) : syntax error allocate (absk(nkd+1), kzz(3,nkd+1),inst(nkd)) ^ Error 24 at (25:recpr.f) : syntax error allocate (absk(nkd+1), kzz(3,nkd+1),inst(nkd)) ^ Error 24 at (25:recpr.f) : syntax error allocate ( TAUK(NFK),KREC(3,NFK)) ^ Error 24 at (41:recpr.f) : syntax error allocate ( TAUK(NFK),KREC(3,NFK)) ^ Error 24 at (41:recpr.f) : syntax error entry RECPR2 ABSK(NJJ+1)=ABSK(NJJ) ^ Error 395 at (113:recpr.f) : This entity is not an array and must not be subscripted 6 KZZ(N,NJJ+1)=KZZ(N,NJJ) ^ Error 43 at (115:recpr.f) : Label 6 refers to a non-executable statement at (114:recpr.f) ^ Error 43 at (115:recpr.f) : Label 6 refers to a non-executable statement at (111:recpr.f) ^ Error 65 at (115:recpr.f) : This statement cannot terminate a DO loop ^ Error 24 at (115:recpr.f) : syntax error 6 KZZ(N,NJJ+1)=KZZ(N,NJJ) ^ Error 24 at (115:recpr.f) : syntax error 6 KZZ(N,NJJ+1)=KZZ(N,NJJ) ^ Error 24 at (115:recpr.f) : syntax error 7 ABSK(J)=ABSM ^ Error 43 at (116:recpr.f) : Label 7 refers to a non-executable statement at (99:recpr.f) ^ Error 43 at (116:recpr.f) : Label 7 refers to a non-executable statement at (83:recpr.f) ^ Error 24 at (116:recpr.f) : syntax error 7 ABSK(J)=ABSM ^ Error 24 at (116:recpr.f) : syntax error 8 KZZ(N,J)=IM(N) ^ Error 43 at (119:recpr.f) : Label 8 refers to a non-executable statement at (118:recpr.f) ^ Error 65 at (119:recpr.f) : This statement cannot terminate a DO loop ^ Error 24 at (119:recpr.f) : syntax error 8 KZZ(N,J)=IM(N) ^ Error 24 at (119:recpr.f) : syntax error 8 KZZ(N,J)=IM(N) ^ Error 24 at (119:recpr.f) : syntax error INST(I)=NST ^ Error 395 at (137:recpr.f) : This entity is not an array and must not be subscripted TAUK(IND)=TAUP(JJ) ^ Error 395 at (149:recpr.f) : This entity is not an array and must not be subscripted KREC(JJJ,IND)=ISTM(JJJ,JJ) ^ Error 395 at (151:recpr.f) : This entity is not an array and must not be subscripted 25 Errors compilation aborted for recpr.f (code 1) make[1]: *** [recpr.o] Error 1 make[1]: Leaving directory `/mnt/1/home/baettigp/wien2k_02/SRC_lapw3' make: *** [complex] Error 2 - -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 22 Jul 2002 17:12:52 +0200 From: Torsten Andersen Subject: [WIEN]: Re: ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Salehi, this error usually comes when lapw1 has exited with an error... - then the error message is in [up|dn]lapw1.error . Alternatively, there is a problem with the compilation. Insert "status='replace'" in "errclr.f", i.e., replace OPEN (99,FILE=FNAME) by OPEN (99,FILE=FNAME,STATUS='REPLACE') and recompile. This removes that error on some sun machines. Best regards, Torsten Andersen. hamid salehi wrote: >==== >hamid salehi >submitted the following contribution: >==== > >Dear wien2k users; > > >with best wishes for all you .When the "run Scf"in >wien2k,the " Stop error" in Lapw1 displayed.What >does it mean?Thank or what is its reason? >What should be done for eliminating it? >best wishes >H-Salehi >dept of physics >Ferdowsi university >Mashhad IRAN >post boxs 1436 >postcode 91775 > > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Autos - Get free new car price quotes >http://autos.yahoo.com >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 23 Jul 2002 13:25:45 +0800 (CST) From: music@theory.issp.ac.cn Subject: [WIEN]: Stoner parameter ==== music@theory.issp.ac.cn submitted the following contribution: ==== Dear wien users, I want to calculate stoner parameter in wien2k program ? How can I do it ? Could anyone help me ? many thanks !!!!! - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 23 Jul 2002 10:10:30 -0400 From: Igor Mazin Subject: Re: [WIEN]: Stoner parameter ==== Igor Mazin submitted the following contribution: ==== The only way is to make fixed-spin-moment calculations and then fit them with the stoner formula, Delta E=(M^2/4)(1/N-I), where N is the nonmagnetic DOS per spin, M is the fixed spin moment. I found that for small M's, M \lessim 0.1, the Energy calculated by WIEN2k is noisy (as opposed to my earlier experience with WIEN-97, but I have not done systematic tests), so I either use the field, that is, EF_up-EF_dn, which is the derivative of E, namely (M/2)(1/N-I), or use Andersen's extended Stoner formula (see Krasko, Phys. Rev. B, around 1985, and refs therein), which allows to use M's up to 1 uB. Good luck, Igor P.S. Note I always speak about the TOTAL Stoner factor, which for compounds is defined as (I_A N_A^2+I_B N_B^2+...)/N^2 At 13:25 7/23/2002 +0800, you wrote: >==== >music@theory.issp.ac.cn >submitted the following contribution: >==== > > >Dear wien users, > I want to calculate stoner parameter in wien2k program ? > How can I do it ? > Could anyone help me ? many thanks !!!!! > > >-- > > > > > >sincerely yours > >Ying.X > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== ***************************************************************************** Igor Mazin, NRL, code 6391, 4555 Overlook Ave, Was., DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; e-mail mazin@nrl.navy.mil Home Page (under construction) http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 23 Jul 2002 16:56:57 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problems compiling Wien2k with IFC ==== Peter Blaha submitted the following contribution: ==== > I encountered a small problem while trying to compile wien2k_02 with IFC 6.0 > on a PIII/800. I obtain the following errors. I retried to compile on > another machine (AMD Duron 1200), with the same effects. > Compile time errors (if any) were: > SRC_lapw3/compile.msg:Error FCE22 : Module KGRID USEd by subroutine RECPR in > work.pc not found > SRC_lapw3/compile.msg:Error 24 at (25:recpr.f) : syntax error Change into SR_lapw3, type make clean make make clean make complex It should do the job. Regards ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 23 Jul 2002 21:03:01 -0400 From: Fred Nastos Subject: [WIEN]: Intel fortran compiler on a cluster ==== Fred Nastos submitted the following contribution: ==== Dear Wien2k Experts, I am about to obtain a new linux cluster and was wondering if someone could comment on the quality of the Intel compiler. I have only been running simple cases on a single cpu using the Portland compiler until now. Do the perfomance gains from parallelization depend on the compiler (I know next to nothing about practical parallel computing except what was taught in my comp. sci. theory class). If the Portland compiler is still the better option, do we need to purchase one of their "cluster" versions? Thank you for any responses, Fred ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 24 Jul 2002 10:09:03 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: Re: [WIEN]: Problems compiling Wien2k with IFC ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Hi In addition to make clean, you will need to delete the work.pc, work.pcl and *.d files too before running make complex command. regards Sharat Chandra > > I encountered a small problem while trying to compile wien2k_02 with IFC 6.0 > > on a PIII/800. I obtain the following errors. I retried to compile on > > another machine (AMD Duron 1200), with the same effects. > > > Compile time errors (if any) were: > > SRC_lapw3/compile.msg:Error FCE22 : Module KGRID USEd by subroutine RECPR in > > work.pc not found > > SRC_lapw3/compile.msg:Error 24 at (25:recpr.f) : syntax error > > Change into SR_lapw3, type > make clean > make > make clean > make complex > > It should do the job. > > Regards > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 24 Jul 2002 09:31:26 +0200 (CEST) From: Stefaan.Cottenier@fys.kuleuven.ac.be Subject: Re: [WIEN]: Intel fortran compiler on a cluster ==== Stefaan.Cottenier@fys.kuleuven.ac.be submitted the following contribution: ==== > ==== > Fred Nastos > submitted the following contribution: > ==== > > I am about to obtain a new linux cluster and was wondering if someone > could comment on the quality of the Intel compiler. I have only been > running simple cases on a single cpu using the Portland compiler until > now. Do the perfomance gains from parallelization depend on the > compiler (I know next to nothing about practical parallel computing except > what was taught in my comp. sci. theory class). If the Portland compiler > is still the better option, do we need to purchase one of their "cluster" > versions? Dear Fred, For this problem, you can even forget what has been taught in your computer classes. It's easier than that. In order to use k-point parallelization with wien2k, you can use any serial (f90) compiler. Wien2k itself takes care of the "parallelization": it distributes the k-points over the different machines, where they are all treated by *serial* code (this can be done as in order to do the diagonalization for 1 k-point, no information about the others is needed). Afterwards, all individual results are pasted together. This scheme works as long as you have a reasonably large number of k-points (at least as many as the number of computers you have). If you have very large unit cells that need only a few k-points, than it becomes useful to consider true parallelization (where the diagonalization of 1 matrix is distributed over different machines, which cannot operate independently any more). This is possible in wien2k, but you need MPI installed (and have fast communication). Most likely, you will not need this. In any case, the regular (serial) Portland compiler will do the job (although I hear rumours that the free Intel f90 is currently faster). Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 24 Jul 2002 10:50:44 +0200 (CEST) From: =?iso-8859-1?q?jonny=20sham?= Subject: [WIEN]: problem in struct of alloy ==== =?iso-8859-1?q?jonny=20sham?= submitted the following contribution: ==== please help me to understand why to generate the case.struct for the alloy materials. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 25 Jul 2002 03:41:15 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien users: I want to calcualte system like AB, where A is a f-element and B is p-element, because A has localized f orbit, so I want to add ORB to the system. But there are some questions I cann't solve My procedure is list below: 1: run init_lapw. 2: run initso_lapw 3: copy case.indm and case.inorb to my case directory, and modified them 4: run runsp_lapw -orb -so there is error after the lapw2 ............ >>:lapw2 -c -dn -so >>: stop error but there are no error can be find in my error files. It is obvious that the lapwdm can't been executed. I have also execute the fourth step like these two: runsp_lapw -orb runsp_lapw -so they are all ok. So it is not the problem of input file. I don't know how to solve this problem. now I give som input files, I hope someone can help me. (My system has a spacegroup Fm3m, 48 kinds of operation) after the normal init_lapw: case.in2: ToT -9.0 17.0 0.50 0.05 TETRA 0.000 0 0 4 0 4 4 6 0 6 4----------------------------- line 4 0 0 4 0 4 4 6 0 6 4----------------------------- line5 FILE FILE/NOFILE Write recrplist case.klist: 1 0 0 0 4 1.0 -7.0 1.5----> 2 1 1 -1 4 8.0 3 2 2 -2 4 4.0 4 2 0 0 4 6.0 5 3 1 -1 4 24.0 6 4 2 -2 4 12.0 7 4 0 0 4 3.0 8 4 2 0 4 6.0 after initso_lapw , case.in1 : I change emax from 1.5 to 8.5(I believe the SO is strong) case.in2c(case.in2 doesn't change,in SO it will no use) : Line 4--------------> 0 0 2 0 4 0 4 4 6 0 6 4 Line 5--------------> 0 0 2 0 4 0 4 4 6 0 6 4 case.inso: WFFIL 4 1 0 -10.000 1.5000---->if this energy also change according to case.in1? 0. 0. 1------------>magnetization direction(001) 1 2 -4.97 0.005---->according to userguide ,these energy parameter should agree with the energy parameter of p-orbit in case.in1,but what : just El for P or E_LO for P? 1 1----------->p-element is my first atom and I don't want to add SO on it case.indm: -9 1 2 1 3-------------------> f-element is my second atom, I want to add ORB on its f electron 0 0 case.inorb is empty, then I change case.inorb like this: 1 1 0 PRATT 1.0 2 1 3------------>f-element f orbit 0 0.59 0.07 case.klist is the same as above.(but if I run initso_lapw again , I found the case.klist will change to follow, is this a bug?) 1 0 0 0 4 1.0 -7.0 1.5 100k div(4x4x4)-->Does this also should be 8.5 like case.in1? 2 1 1 -1 4 8.0 3 2 2 -2 4 4.0 4 2 0 0 4 4.0 5 3 1 -1 4 16.0 6 4 2 -2 4 8.0 7 4 0 0 4 2.0 8 0 0 2 4 2.0 9 2 2 0 4 4.0 10 3 3 -1 4 8.0 11 4 2 0 4 4.0 12 4 0 2 4 2.0 13 0 0 4 4 1.0 case.struct file is still Cubic ,but the kinds of operation reduce from 48 to 16(accoring to the userguide, the Cubic system with magnetization direction (001) should change to tetragonal, why in my case still Cubic system? In my structure a=b=c) and another question: because my system has inversion symmetry , after initso_lapw , it also preserve inversion, so in my case , the input file should be case.in1 and case.in2c, but when during initso_lapw , at rerun kgen, it always show the messages: cp: can not stat "case.in1c_so", no such file or directory cp: can not stat "case.in2c_so", no such file or directory but the case.in1 and case.in2c can stil be created So I hope some one can help me, I was confused by these all _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 25 Jul 2002 14:07:15 +0200 (CEST) From: Stefaan.Cottenier@fys.kuleuven.ac.be Subject: [WIEN]: textbook: correction ==== Stefaan.Cottenier@fys.kuleuven.ac.be submitted the following contribution: ==== Dear Wien-users, Something got mixed up in section 6.1 of "DFT and the family of (L)APW methods" (*). In this section, some output lines where referring to a different example, used in a trial version of the text. It has been corrected now. The new version carries number 1.03 in the header of the odd pages. Thanks to Michel Jaouen for indicating the problem, and sorry to the people that have been searching in vain for what they where doing wrong... Stefaan (*) http://www.wien2k.at/reg_user/textbooks ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #28 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #29 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, August 1 2002 Volume 2002 : Number 029 ---------------------------------------------------------------------- Date: Thu, 25 Jul 2002 14:07:49 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== > I want to calcualte system like AB, where A is a f-element and B is > p-element, > because A has localized f orbit, so I want to add ORB to the system. But > there are some > questions I cann't solve > > My procedure is list below: > > 1: run init_lapw. > 2: run initso_lapw > 3: copy case.indm and case.inorb to my case directory, and modified > them > 4: run runsp_lapw -orb -so > > there is error after the lapw2 > > ............ > >>:lapw2 -c -dn -so > >>: stop error > > but there are no error can be find in my error files. It is obvious that > the lapwdm > can't been executed. I have also execute the fourth step like these two: > runsp_lapw -orb > runsp_lapw -so > they are all ok. So it is not the problem of input file. I don't know how The reason is quite simply: SO calculation require complex lapw2 and lapwdm, so you are missing a case.indmc file. Just copy your indm file to indmc. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 25 Jul 2002 09:36:50 -0400 From: Igor Mazin Subject: [WIEN]: Re: ==== Igor Mazin submitted the following contribution: ==== A few comments to this point: 1) With magnetism and SO, your symmetry has to be broken. Just make c.ne.a,b slightly, it will do the job. Correspondingly, if you want to get the right orbital moment, you have to use the complex version of lapw1 (in Wien2k. Apparently Wien2k_02 is organized differently) 2) I have a neat script to create indm and inorb. See http://cst-www.nrl.navy.mil/~mazin/, scroll down to CCMS WIEN LAPW tips. 3) There can be different opinions, but I am very confident that for f-electrons you want to use the localized version of LDA+U, nicknamed SIC in WIEN2k. 4) U for f-electrons is large, at least 0.4 Ry, therefore different valence state of the rare earth may be stabilized in LDA+U. Be careful to find the right ground state. The -orbc option is great for steering the calculations into a given valence state. 5) I can send you input files for SmZn (a well behaving calculation), if you want to compare with yours. Good luck, Igor ==== ***************************************************************************** Igor Mazin, NRL, code 6391, 4555 Overlook Ave, Was., DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; e-mail mazin@nrl.navy.mil Home Page (under construction) http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 25 Jul 2002 18:24:48 +0200 (MEST) From: Pio =?ISO-8859-1?Q?B=E4ttig?= Subject: [WIEN]: Calculation crashes with LAPW2 ==== Pio =?ISO-8859-1?Q?B=E4ttig?= submitted the following contribution: ==== Dear Wien users I am trying to calculate a ferromagnetically coupled system, a perovskite in which the small cations are alternatingly Fe and Cr (resulting in (111)planes) with Wien2k_02 For the atomic calculations I chose the PBE96 XC and -6.0 eV to separate core and valence states. I chose RKmax=8.0, 256 kpoints, spinpolarized, everything else was standard. The .struct file looks as follows: Title F LATTICE,NONEQUIV. ATOMS: 4 225 Fm-3m MODE OF CALC=RELA unit=bohr 14.739900 14.739900 14.739900 90.000000 90.000000 90.000000 ATOM= 1: X=0.75000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 2 1: X=0.25000000 Y=0.75000000 Z=0.75000000 Bi1 NPT= 781 R0=0.00000500 RMT= 1.8000 Z: 83.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= 2: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Fe1 NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 26.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= 3: X=0.50000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Cr1 NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 24.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -4: X=0.50000000 Y=0.25000000 Z=0.00000000 MULT= 6 ISPLIT=-2 -4: X=0.50000000 Y=0.75000000 Z=0.00000000 -4: X=0.00000000 Y=0.50000000 Z=0.25000000 -4: X=0.00000000 Y=0.50000000 Z=0.75000000 -4: X=0.25000000 Y=0.00000000 Z=0.50000000 -4: X=0.75000000 Y=0.00000000 Z=0.50000000 O 1 NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 8.0 LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 1.0000000 0.0000000 0.0000000 48 NUMBER OF SYMMETRY OPERATIONS . . . I checked the geometry in xcrysdens and everything should be correct. The .inst looks as follows: Bi Xe 7 5 4, 3,3.0 N 4, 3,3.0 N 4,-4,4.0 N 4,-4,4.0 N 5, 2,2.0 N 5, 2,2.0 N 5,-3,3.0 N 5,-3,3.0 N 6,-1,1.0 N 6,-1,1.0 N 6, 1,1.0 N 6, 1,1.0 N 6,-2,1.0 N 6,-2,0.0 N Fe Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,0.0 N 4,-1,1.0 N 4,-1,0.0 N Cr Ar 3 5 3, 2,2.0 N 3, 2,1.0 N 3,-3,2.0 N 3,-3,0.0 N 4,-1,1.0 N 4,-1,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N **** **** END of input (instgen_lapw) The SCF breaks down in LAPW2 with the following error message: forrtl: severe (64): input conversion error, unit 1001, file /usr/tmp/baettigp/b2.helpup031 0: __FINI_00_remove_gp_range [0x3ff81a6c374] 1: __FINI_00_remove_gp_range [0x3ff81a6c8f4] 2: __FINI_00_remove_gp_range [0x3ff81a93b84] 3: outp_ [outp.f: 179, 0x120068b30] 4: l2main_ [l2main_tmp_.F: 1230, 0x12005f7a8] 5: lapw2_ [lapw2_tmp_.F: 465, 0x120064c18] 6: main [for_main.c: 203, 0x12007e32c] 7: __start [0x1200084c8] In b2.helpup031 are some lines as the following: BAND# 8 E= -1.47073 WEIGHT= 0.0046296 L= 0 50.00000 ********** 18741.993********************-18658.372 L= 1 0.00000 0.000 0.000 0.000 0.000 0.000 L= 2 0.00000 0.000 0.000 0.000 0.000 0.000 D-EG: 0.00000 0.000 0.000 0.000 0.000 0.000 D-T2G: 0.00000 0.000 0.000 0.000 0.000 0.000 L= 3 0.00000 0.000 0.000 0.000 0.000 0.000 L= 4 0.00000 0.000 0.000 0.000 0.000 0.000 L= 5 0.00000 0.000 0.000 0.000 0.000 0.000 L= 6 0.00000 0.000 0.000 0.000 0.000 0.000 BAND# 9 E= -1.47073 WEIGHT= 0.0046296 L= 0 50.00000 ********** 18741.993********************-18658.371 I can run the testcase (eg TiO2), and it converges: cycle 3 (18/18 to go) ... > mixer (15:19:19) 0.82u 0.28s 0:01 99% 0+50k 0+183io 0pf+0w :ENERGY convergence: 1 0.0001 .0000040000000000 I would be grateful for any hint. Thank you very much Kind regards Pio Bättig - -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 26 Jul 2002 15:27:16 +0200 (CEST) From: Georg Madsen Subject: [WIEN]: Re: your mail (Yue Hai) ==== Georg Madsen submitted the following contribution: ==== > 1: run init_lapw. > 2: run initso_lapw > 3: copy case.indm and case.inorb to my case directory, and modified > them > 4: run runsp_lapw -orb -so > > there is error after the lapw2 > > ............ > >>:lapw2 -c -dn -so > >>: stop error Have you copied your in2 file to in2c? Georg > > but there are no error can be find in my error files. It is obvious that > the lapwdm > can't been executed. I have also execute the fourth step like these two: > runsp_lapw -orb > runsp_lapw -so > they are all ok. So it is not the problem of input file. I don't know how > to solve this > problem. > > > now I give som input files, I hope someone can help me. > > (My system has a spacegroup Fm3m, 48 kinds of operation) > > after the normal init_lapw: > > case.in2: > > ToT > -9.0 17.0 0.50 0.05 > TETRA 0.000 > 0 0 4 0 4 4 6 0 6 4----------------------------- line 4 > 0 0 4 0 4 4 6 0 6 4----------------------------- line5 > FILE FILE/NOFILE Write recrplist > > case.klist: > > 1 0 0 0 4 1.0 -7.0 1.5----> > 2 1 1 -1 4 8.0 > 3 2 2 -2 4 4.0 > 4 2 0 0 4 6.0 > 5 3 1 -1 4 24.0 > 6 4 2 -2 4 12.0 > 7 4 0 0 4 3.0 > 8 4 2 0 4 6.0 > > after initso_lapw , > > case.in1 : I change emax from 1.5 to 8.5(I believe the SO is strong) > > case.in2c(case.in2 doesn't change,in SO it will no use) : > Line 4--------------> 0 0 2 0 4 0 4 4 6 0 6 4 > Line 5--------------> 0 0 2 0 4 0 4 4 6 0 6 4 > > case.inso: > > WFFIL > 4 1 0 > -10.000 1.5000---->if this energy also change according to > case.in1? > 0. 0. 1------------>magnetization direction(001) > 1 > 2 -4.97 0.005---->according to userguide ,these energy > parameter > should agree with the energy parameter of > p-orbit > in case.in1,but what : just El for P or > E_LO for P? > > 1 1----------->p-element is my first atom and I don't want > to add SO on it > > case.indm: > > -9 > 1 > 2 1 3-------------------> f-element is my second atom, I want to > add ORB on its f electron > 0 0 > > case.inorb is empty, then I change case.inorb like this: > > 1 1 0 > PRATT 1.0 > 2 1 3------------>f-element f orbit > 0 > 0.59 0.07 > > case.klist is the same as above.(but if I run initso_lapw again , I found > the case.klist > will change to follow, is this a bug?) > 1 0 0 0 4 1.0 -7.0 1.5 100k div(4x4x4)-->Does this also > should be 8.5 like case.in1? > 2 1 1 -1 4 8.0 > 3 2 2 -2 4 4.0 > 4 2 0 0 4 4.0 > 5 3 1 -1 4 16.0 > 6 4 2 -2 4 8.0 > 7 4 0 0 4 2.0 > 8 0 0 2 4 2.0 > 9 2 2 0 4 4.0 > 10 3 3 -1 4 8.0 > 11 4 2 0 4 4.0 > 12 4 0 2 4 2.0 > 13 0 0 4 4 1.0 > > case.struct file is still Cubic ,but the kinds of operation reduce from > 48 to 16(accoring to the userguide, the Cubic system with magnetization > direction (001) should change to tetragonal, why in my case still Cubic > system? In my structure a=b=c) > > and another question: because my system has inversion symmetry , after > initso_lapw , > it also preserve inversion, so in my case , the input file should be > case.in1 and case.in2c, > but when during initso_lapw , at rerun kgen, it always show the messages: > > cp: can not stat "case.in1c_so", no such file or directory > cp: can not stat "case.in2c_so", no such file or directory > > but the case.in1 and case.in2c can stil be created > > So I hope some one can help me, I was confused by these all > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: > http://messenger.microsoft.com/cn/ > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 26 Jul 2002 15:51:25 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Calculation crashes with LAPW2 ==== Peter Blaha submitted the following contribution: ==== > I am trying to calculate a ferromagnetically coupled system, > a perovskite in which the small cations are alternatingly > Fe and Cr (resulting in (111)planes) with Wien2k_02 > > The SCF breaks down in LAPW2 with the following error message: > > forrtl: severe (64): input conversion error, unit 1001, file > /usr/tmp/baettigp/b2.helpup031 > 0: __FINI_00_remove_gp_range [0x3ff81a6c374] > 1: __FINI_00_remove_gp_range [0x3ff81a6c8f4] > 2: __FINI_00_remove_gp_range [0x3ff81a93b84] > 3: outp_ [outp.f: 179, 0x120068b30] > 4: l2main_ [l2main_tmp_.F: 1230, 0x12005f7a8] > 5: lapw2_ [lapw2_tmp_.F: 465, 0x120064c18] > 6: main [for_main.c: 203, 0x12007e32c] > 7: __start [0x1200084c8] > > In b2.helpup031 are some lines as the following: > > BAND# 8 E= -1.47073 WEIGHT= 0.0046296 > L= 0 50.00000 ********** 18741.993********************-18658.372 > L= 1 0.00000 0.000 0.000 0.000 0.000 0.000 Most likely the energy parameters are not ok and you got ghostbands. Check the scf cycle. In what iteration did it happen ? Was :DIS decreasing or diverging ? Check the energy parameters (case.scf1) and the respective eigenvalues. I suppose for the first atom the l=0 (s) LO and APW energies are too close to each other. Most likely you will have to clean, run dstart (up/dn) again, reduce the mixing and change energy parameters in case.in1 Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 26 Jul 2002 09:28:50 -0700 From: David Clatterbuck Subject: [WIEN]: stress in WIEN2k? ==== David Clatterbuck submitted the following contribution: ==== Is WIEN2k able to compute stresses (not forces) on the unit cell directly as is possible with most planewave codes? One can get the stress by computing the energy of a unit cell before and after a small strain and using sigma~(delta energy)/(delta strain), but I'm wondering if one can get the entire stress tensor from a single computation. I don't think this was possible with WIEN97 but am wondering if WIEN2K has this feature. Thanks, David Clatterbuck Lawrence Berkeley National Lab ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 01:48:26 +0000 From: "zhang YS Zhang" Subject: Re: [WIEN]: Re: ==== "zhang YS Zhang" submitted the following contribution: ==== Dear Igor Mazin: Thanks for your help. Now I use Wine2k_02, According to the useguide ,it maybe also to use the real version lapw1 if a system has inversion, but I am not sure. I just use the real lapw1 > >==== >Igor Mazin >submitted the following contribution: >==== > >A few comments to this point: > >1) With magnetism and SO, your symmetry has to be broken. Just make >c.ne.a,b >slightly, it will do the job. my origin system Fm3m(a=b=c=5.932), you mean I make c.ne.a,b slightly(a=b=5.932, c=5.940),can this correct when my system cubic Fm3m? > Correspondingly, if you want to get >the right >orbital moment, you have to use the complex version of lapw1 (in >Wien2k. >Apparently Wien2k_02 is organized differently) Now I use Wine2k_02, According to the useguide ,it maybe also useful to use the real version lapw1 if a system has inversion and I just use the real lapw1. but I am not sure if this is true?. According to the situation of my case, the orbit moment can also be obtained in my recent calculation.(but there has osciallation unfortunately). And I also want to know if the real lapw1 in LDA+U calculation can be used, is it still necessary to make the lattice parameter c.ne.a and b? >2) I have a neat script to create indm and inorb. See >http://cst-www.nrl.navy.mil/~mazin/, scroll down to >CCMS WIEN LAPW tips. >3) There can be different opinions, but I am very confident that for >f-electrons you want to use the localized version of LDA+U, >nicknamed SIC in WIEN2k. Oh this may be a stupid question , but I really want to know the difference between the three kinds of LDA+U: SIC, AMF,HMF? And I want to know the difference between LDA+U and OP? How can I choose them in different case? >4) U for f-electrons is large, at least 0.4 Ry, therefore different >valence state of the rare earth may be stabilized in LDA+U. Be >careful >to find the right ground state. The -orbc option is great for >steering the calculations into a given valence state. >5) I can send you input files for SmZn (a well behaving >calculation), if you want to compare with yours. If you can send it to me , I will great thankful! > >==== > > >***************************************************************************** >Igor Mazin, NRL, code 6391, 4555 Overlook Ave, Was., DC 20375 >Ph.: 202 767-6990; Fax: 202 404-7546; e-mail mazin@nrl.navy.mil >Home Page (under construction) http://cst-www.nrl.navy.mil/~mazin >***************************************************************************** > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 02:37:13 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Re: your mail ==== "Yue Hai" submitted the following contribution: ==== >==== >Peter Blaha >submitted the following contribution: >==== > > > I want to calcualte system like AB, where A is a f-element and B is > > p-element, > > because A has localized f orbit, so I want to add ORB to the system. But > > there are some > > questions I cann't solve >The reason is quite simply: SO calculation require complex lapw2 and >lapwdm, so you are missing a case.indmc file. Just copy your indm file to >indmc. > Dear Peter and Georg Madsen: Thanks for your help , yes I cp case.indm to case.indmc .It is ok now. but there are still qeustions I want to know: 1 .Now I use wien2k_02, why my system with a cubic Fm3m (a=b=c=5.932)did't change to tetragonal system when the initso_lapw has been executed(still a=b=c=5.932)? According to the userguide this change will occur. But just the number of symmetry operation reduce from 48 to 16. Is this correct? If this is not correct, it mean that I must change parameter c slightly not equal to a and b just as Mr Igor Mazin has suggested to ? 2. In Wien2k_02, we use real lapw1 also can obtain orbit moment, is this right? If it is not correct, and I want to obtain the orbit moment of a system with inversion ,how can I handle it? Just cp case.in1 to case.in1c or broke the system by hand?(for example add extra atom or change slightly the parameter of system) 3. when I use initso_lapw first ,when it ask if rerun kgen, I select yes but the file case.klist did't change , it is the same as the case.klist during the init_lapw. But when I run initso_lapw again ,after kgen ,the file changed. If I run initso_lapw for the third time , the file din't change again. If this means that we must run initso_lapw two times to obtain the correct case.klist file? Is this a bug in wien2k_02? >-------------------------------------------------------------------------- >Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna >Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 >Email: blaha@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£http://www.hotmail.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 10:56:58 -0400 (EDT) From: Igor Mazin Subject: Re: [WIEN]: Re: ==== Igor Mazin submitted the following contribution: ==== Hi, I'm leaving for vacations, will be away from my mail for a week. > > my origin system Fm3m(a=b=c=5.932), you mean I make c.ne.a,b > slightly(a=b=5.932, c=5.940),can this correct when my system cubic Fm3m? Peter should know better, but my understanding is, what really matters, is that the Number of operations reduces from 48 to 16. This should jhappen. > Oh this may be a stupid question , but I really want to know the difference > between the three kinds of LDA+U: SIC, AMF,HMF? And I want to know the > difference between LDA+U and OP? How can I choose them in different case? There are many opinions. Mine is expressed in a recent cond-mat, cond-mat/0206548. Briefly, for localized systems I believe SIC is in place, (although I say this name is a misnomer), for weakly localized systems no LDA+U is good, but if anything, AMF is better, and HMF should never be used. Re OP my personal opinion is it is not physically justifiable, there is a good deal of discussion of that in an older PRL by Soloviev and Lichtenstein, and a little bit in an even older PRB by Anisimov and myself. > > If you can send it to me , I will great thankful! I did. - -- ***************************************************************************** Igor Mazin, NRL, code 6391, 4555 Overlook Ave SW, Washington, DC 20375-5320 Phone: (202) 767-6990; Fax: (202) 404-7546; e-mail mazin@dave.nrl.navy.mil Home Page (under construction) http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 18:21:41 -0400 (EDT) From: Neme Nnolim Subject: [WIEN]: Calculated DOS consists of single spike and nothing else? ==== Neme Nnolim submitted the following contribution: ==== Dear WIEN users, I am trying to calculate density of states for compressed unit cells of tantalum. However,the calculated total DOS consists of a single narrow pike going up to 200 states/eV.cell and nothing else. I have changed the EMIN parameter in case.in2, tried using TEMP and GAUSS instead of TETRA with EVAL = 0.002, tried using 100,000 k-points ( ~ 6500 irreducible k-points), tried changing energy limits in case.in1, all to no avail. I have also tried using GMAX of 10 and 14 with GGA option of 13. There doesn't seem to be anything about this in the digest of previous questions. Below is a truncated version of my struct file (4th to 16th symmetry operations are not shown). - ---struct file begin----------------------------------------- Ta-10_9 B LATTICE,NONEQUIV. ATOMS: 1 MODE OF CALC=RELA 6.280500 6.280500 6.155520 90.000000 90.000000 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT=-2 Ta NPT= 781 R0=0.00000500 RMT= 1.9000 Z: 73.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 16 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 1 0-1 0 0.0000000 1 0 0 0.0000000 0 0-1 0.0000000 2 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 3 0 1 0 0.0000000 1 0 0 0.0000000 0 0-1 0.0000000 - --struct file end--------------------------------------------- - --begin case.in1 --------------------------------------------- WFFIL (WFPRI, SUPWF) 10.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 7 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 0 -5.03 0.005 STOP 1 -2.41 0.010 CONT 1 0.30 0.000 CONT 3 0.30 0.000 CONT 3 -1.42 0.010 CONT 2 0.30 0.010 CONT K-VECTORS FROM UNIT:4 -9.0 2.5 emin/emax window - ---end case.in1 ----------------------------------------------- Any ideas? Thanks and regards, Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 23:07:12 -0400 From: Fred Nastos Subject: Re: [WIEN]: Calculated DOS consists of single spike and nothing else? ==== Fred Nastos submitted the following contribution: ==== > I am trying to calculate density of states for compressed unit cells of > tantalum. However,the calculated total DOS consists of a single > narrow pike going up to 200 states/eV.cell and nothing else. Since you kindly provided a structure file, I tried the same calculation and also got a single spike, except that mine went up to 2000! Mine may be higher because I used a very coarse k-mesh. Anyway, I tried the calculation again, but I used a larger RMT (2.5) and got something that looks reasonable, with the same k-mesh that I used for the RMT=1.9 run. I'm not sure if it makes sense that the RMT value could do that, but that's what I found. I am emailing you the DOS and the Bandstructure. Fred Nastos Department of Physics University of Toronto ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 28 Jul 2002 01:07:52 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Calculated DOS consists of single spike and nothing else? ==== Neme Nnolim submitted the following contribution: ==== Fred, Thanks for the insight. I will try to play around with the RMT values. I should have tried doing that first. Thanks. Regards, Neme On Sat, 27 Jul 2002, Fred Nastos wrote: > Date: Sat, 27 Jul 2002 23:07:12 -0400 > From: Fred Nastos > Reply-To: wien@zeus.theochem.tuwien.ac.at > To: wien@zeus.theochem.tuwien.ac.at > Subject: Re: [WIEN]: Calculated DOS consists of single spike and nothing > else? > Since you kindly provided a structure file, I tried the same calculation and > also got a single spike, except that mine went up to 2000! Mine may be > higher because I used a very coarse k-mesh. Anyway, I tried the calculation > again, but I used a larger RMT (2.5) and got something that looks reasonable, > with the same k-mesh that I used for the RMT=1.9 run. I'm not sure if it > makes sense that the RMT value could do that, but that's what I found. I am > emailing you the DOS and the Bandstructure. > > Fred Nastos > Department of Physics > University of Toronto - -- - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 27 Jul 2002 22:47:25 -0700 (PDT) From: Rose makine Subject: [WIEN]: problem on DOS ==== Rose makine submitted the following contribution: ==== Dear WIEN Users when I calculate DOS,lapw2 is not run.This error is appear: PGFIO-F-252/list-directed read/unit=29/operation attempted after end of file. File name = LDA.energydn formatted, sequential access record = 5000 In source file fermi.f, at line number 63 0.040u 0.000s 0:00.10 40.0% 0+0k 0+0io 214pf+0w Why?How I solve it? Thanks. R. Makine. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 08:48:37 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== > 1 .Now I use wien2k_02, why my system with a cubic Fm3m > (a=b=c=5.932)did't change to tetragonal system when the initso_lapw has > been executed(still a=b=c=5.932)? According to the userguide this change > will occur. But just the number of symmetry operation reduce from 48 to 16. > Is this correct? If this is not correct, it mean that I must change > parameter c slightly not equal to a and b just as Mr Igor Mazin has > suggested to ? No, you don't need to change the c parameter. symmetso can now reduce the symmetry without further tricks. > 2. In Wien2k_02, we use real lapw1 also can obtain orbit moment, is > this right? If it is not correct, and I want to obtain the orbit moment > of a system with inversion ,how can I handle it? Just cp case.in1 to > case.in1c or broke the system by hand?(for example add extra atom or change > slightly the parameter of system) If you have inversion, you can always keep lapw1, but after lapwso even in this case the complex lapw2c and lapwdmc must be used. > 3. when I use initso_lapw first ,when it ask if rerun kgen, I select > yes but the file case.klist did't change , it is the same as the case.klist > during the init_lapw. But when I run initso_lapw again ,after kgen ,the > file changed. If I run initso_lapw for the third time , the file din't > change again. If this means that we must run initso_lapw two times to > obtain the correct case.klist file? Is this a bug in wien2k_02? This is a bug in initso_lapw. It runs first kgen and oly then will update the struct file. Thus one should rerun kgen later on as you did. I'll fix this very soon. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 09:00:53 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: problem on DOS ==== Peter Blaha submitted the following contribution: ==== > when I calculate DOS,lapw2 is not run.This error is > appear: > PGFIO-F-252/list-directed read/unit=29/operation > attempted after end of file. > File name = LDA.energydn formatted, sequential > access record = 5000 > In source file fermi.f, at line number 63 > 0.040u 0.000s 0:00.10 40.0% 0+0k 0+0io When running a spinpolarized case, you must have both, spin-up AND dn vectors. I.e.: x lapw1 -up x lapw1 -dn x lapw2 -up -qtl x lapw2 -dn -qtl Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 09:02:21 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: stress in WIEN2k? ==== Peter Blaha submitted the following contribution: ==== > Is WIEN2k able to compute stresses (not forces) on the unit cell > directly as is possible with most planewave codes? One can get the > stress by computing the energy of a unit cell before and after a small > strain and using sigma~(delta energy)/(delta strain), but I'm wondering > if one can get the entire stress tensor from a single computation. I > don't think this was possible with WIEN97 but am wondering if WIEN2K has > this feature. No, the stress tensor is not part of WIEN2k. C.Ambrosch-Draxl is working on that. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 02:43:55 -0700 (PDT) From: Rose makine Subject: Re: [WIEN]: problem on DOS ==== Rose makine submitted the following contribution: ==== - --0-886712059-1027935835=:41827 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Prof.Blaha Thanks for your answer,but I have both, spin-up AND spin-dn vectors.My DAYSFILE is attachment. Sincerely. R_Makine. - --- Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > when I calculate DOS,lapw2 is not run.This error > is > > appear: > > PGFIO-F-252/list-directed read/unit=29/operation > > attempted after end of file. > > File name = LDA.energydn formatted, > sequential > > access record = 5000 > > In source file fermi.f, at line number 63 > > 0.040u 0.000s 0:00.10 40.0% 0+0k 0+0io > > When running a spinpolarized case, you must have > both, spin-up AND dn vectors. > I.e.: > > x lapw1 -up > x lapw1 -dn > x lapw2 -up -qtl > x lapw2 -dn -qtl > > Regards > > 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@theochem.tuwien.ac.at WWW: > http://www.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com - --0-886712059-1027935835=:41827 Content-Type: text/plain; name=20 Content-Description: 20 Content-Disposition: inline; filename=20 Calculating LDA in /home/makine/LDA on CondMat6 start (Tue Mar 19 14:33:08 IRT 2002) with lapw0 (200/20 to go) > lapw0 (14:33:08) 8.570u 0.040s 0:08.77 98.1% 0+0k 0+0io 279pf+0w > lapw1 -up (14:33:17) 441.270u 11.690s 7:42.36 97.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (14:40:59) 438.200u 11.720s 7:40.63 97.6% 0+0k 0+0io 401pf+0w > lapw2 -up (14:48:40) 147.570u 0.810s 2:33.20 96.8% 0+0k 0+0io 331pf+0w > lapw2 -dn (14:51:13) 127.520u 0.550s 2:21.32 90.6% 0+0k 0+0io 329pf+0w > lcore -up (14:53:35) 0.240u 0.010s 0:00.24 104.1% 0+0k 0+0io 191pf+0w > lcore -dn (14:53:35) 0.240u 0.000s 0:00.24 100.0% 0+0k 0+0io 191pf+0w > mixer (14:53:35) 1.790u 0.020s 0:01.90 95.2% 0+0k 0+0io 214pf+0w :ENERGY convergence: 0 0.00001 0 :CHARGE convergence: 0 0 0 199/19 to go > lapw0 (14:53:37) 8.510u 0.050s 0:08.93 95.8% 0+0k 0+0io 279pf+0w > lapw1 -up (14:53:46) 439.180u 11.380s 14:25.15 52.0% 0+0k 0+0io 401pf+0w > lapw1 -dn (15:08:11) 439.660u 11.370s 17:49.40 42.1% 0+0k 0+0io 401pf+0w > lapw2 -up (15:26:01) 152.930u 0.580s 7:46.78 32.8% 0+0k 0+0io 329pf+0w > lapw2 -dn (15:33:48) 126.490u 0.580s 5:15.99 40.2% 0+0k 0+0io 329pf+0w > lcore -up (15:39:04) 0.230u 0.010s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (15:39:04) 0.240u 0.010s 0:00.45 55.5% 0+0k 0+0io 191pf+0w > mixer (15:39:05) 1.780u 0.050s 0:03.92 46.6% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 0 :CHARGE convergence: 0 0 0 198/18 to go > lapw0 (15:39:09) 8.770u 0.060s 0:18.04 48.9% 0+0k 0+0io 279pf+0w > lapw1 -up (15:39:27) 444.280u 12.160s 15:37.55 48.6% 0+0k 0+0io 401pf+0w > lapw1 -dn (15:55:05) 444.650u 11.790s 15:20.68 49.5% 0+0k 0+0io 401pf+0w > lapw2 -up (16:10:25) 150.680u 0.540s 5:02.35 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (16:15:28) 125.640u 0.510s 4:12.23 50.0% 0+0k 0+0io 329pf+0w > lcore -up (16:19:40) 0.230u 0.010s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (16:19:41) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (16:19:41) 1.810u 0.000s 0:03.61 50.1% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .1699260000000000 :CHARGE convergence: 0 0 .5900908 197/17 to go > lapw0 (16:19:45) 8.980u 0.060s 0:18.10 49.9% 0+0k 0+0io 279pf+0w > lapw1 -up (16:20:03) 436.510u 12.000s 14:57.11 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (16:35:01) 439.780u 11.350s 15:02.23 50.0% 0+0k 0+0io 401pf+0w > lapw2 -up (16:50:03) 154.850u 0.500s 5:10.76 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (16:55:14) 121.900u 0.500s 4:04.80 50.0% 0+0k 0+0io 329pf+0w > lcore -up (16:59:18) 0.220u 0.020s 0:00.44 54.5% 0+0k 0+0io 191pf+0w > lcore -dn (16:59:19) 0.230u 0.010s 0:00.43 55.8% 0+0k 0+0io 191pf+0w > mixer (16:59:20) 1.790u 0.020s 0:03.61 50.1% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0409075000000000 :CHARGE convergence: 0 0 .8151462 196/16 to go > lapw0 (16:59:24) 8.510u 0.050s 0:17.09 50.0% 0+0k 0+0io 279pf+0w > lapw1 -up (16:59:41) 436.710u 11.910s 14:57.37 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (17:14:38) 436.580u 11.510s 14:56.29 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (17:29:34) 150.240u 0.550s 5:01.51 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (17:34:36) 125.140u 0.500s 4:11.21 50.0% 0+0k 0+0io 329pf+0w > lcore -up (17:38:47) 0.250u 0.000s 0:00.42 59.5% 0+0k 0+0io 191pf+0w > lcore -dn (17:38:48) 0.250u 0.000s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > mixer (17:38:48) 1.780u 0.030s 0:03.55 50.9% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0554370000000000 :CHARGE convergence: 0 0 .3410092 195/15 to go > lapw0 (17:38:52) 8.940u 0.030s 0:17.97 49.9% 0+0k 0+0io 279pf+0w > lapw1 -up (17:39:10) 436.820u 11.260s 14:56.21 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (17:54:07) 441.570u 11.620s 15:06.38 50.0% 0+0k 0+0io 401pf+0w > lapw2 -up (18:09:13) 148.760u 0.380s 4:58.29 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (18:14:11) 127.980u 0.520s 4:17.06 49.9% 0+0k 0+0io 329pf+0w > lcore -up (18:18:29) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (18:18:29) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > mixer (18:18:30) 1.800u 0.020s 0:03.62 50.2% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0388500000000000 :CHARGE convergence: 0 0 .4987429 194/14 to go > lapw0 (18:18:34) 8.430u 0.050s 0:16.93 50.0% 0+0k 0+0io 279pf+0w > lapw1 -up (18:18:51) 436.960u 11.470s 14:56.94 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (18:33:48) 436.650u 11.650s 14:56.66 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (18:48:44) 148.820u 0.400s 4:58.50 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (18:53:43) 127.740u 0.510s 4:16.40 50.0% 0+0k 0+0io 329pf+0w > lcore -up (18:57:59) 0.230u 0.020s 0:00.42 59.5% 0+0k 0+0io 191pf+0w > lcore -dn (18:58:00) 0.250u 0.000s 0:00.42 59.5% 0+0k 0+0io 191pf+0w > mixer (18:58:00) 1.790u 0.040s 0:03.68 49.7% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0380310000000000 :CHARGE convergence: 0 0 .4860822 193/13 to go > lapw0 (18:58:04) 8.920u 0.040s 0:17.83 50.2% 0+0k 0+0io 279pf+0w > lapw1 -up (18:58:22) 436.670u 11.620s 14:56.63 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (19:13:19) 436.630u 11.500s 14:56.43 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (19:28:16) 149.290u 0.470s 4:59.53 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (19:33:15) 127.160u 0.640s 4:15.54 50.0% 0+0k 0+0io 329pf+0w > lcore -up (19:37:31) 0.250u 0.000s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (19:37:31) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (19:37:32) 1.810u 0.020s 0:03.68 49.7% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0217865000000000 :CHARGE convergence: 0 0 .5817786 192/12 to go > lapw0 (19:37:36) 8.930u 0.050s 0:17.98 49.9% 0+0k 0+0io 279pf+0w > lapw1 -up (19:37:54) 436.670u 11.460s 14:56.45 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (19:52:50) 436.850u 11.550s 14:56.83 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (20:07:47) 147.560u 0.450s 4:56.05 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (20:12:43) 129.580u 0.490s 4:20.26 49.9% 0+0k 0+0io 329pf+0w > lcore -up (20:17:04) 0.230u 0.020s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (20:17:04) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (20:17:05) 1.810u 0.030s 0:03.69 49.8% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0272660000000000 :CHARGE convergence: 0 0 .3020233 191/11 to go > lapw0 (20:17:09) 8.890u 0.040s 0:17.87 49.9% 0+0k 0+0io 279pf+0w > lapw1 -up (20:17:27) 436.040u 12.210s 14:56.50 50.0% 0+0k 0+0io 401pf+0w > lapw1 -dn (20:32:23) 440.320u 11.830s 15:04.43 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (20:47:28) 145.090u 0.590s 4:51.30 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (20:52:19) 130.680u 0.440s 4:22.12 50.0% 0+0k 0+0io 329pf+0w > lcore -up (20:56:41) 0.250u 0.000s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (20:56:42) 0.240u 0.000s 0:00.42 57.1% 0+0k 0+0io 191pf+0w > mixer (20:56:42) 1.800u 0.040s 0:03.69 49.8% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0194925000000000 :CHARGE convergence: 0 0 .2735661 190/10 to go > lapw0 (20:56:46) 8.800u 0.060s 0:17.68 50.1% 0+0k 0+0io 279pf+0w > lapw1 -up (20:57:04) 436.020u 11.940s 14:56.13 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (21:12:00) 436.370u 11.400s 14:55.49 50.0% 0+0k 0+0io 401pf+0w > lapw2 -up (21:26:56) 144.400u 0.570s 4:49.92 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (21:31:46) 131.130u 0.470s 4:23.10 50.0% 0+0k 0+0io 329pf+0w > lcore -up (21:36:09) 0.250u 0.000s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (21:36:10) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (21:36:10) 1.820u 0.030s 0:03.71 49.8% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0273845000000000 :CHARGE convergence: 0 0 .3820988 189/9 to go > lapw0 (21:36:14) 8.710u 0.040s 0:17.50 50.0% 0+0k 0+0io 279pf+0w > lapw1 -up (21:36:32) 436.510u 11.760s 14:56.55 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (21:51:28) 436.780u 11.470s 14:56.67 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (22:06:25) 145.370u 0.470s 4:51.70 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (22:11:17) 130.850u 0.520s 4:22.66 50.0% 0+0k 0+0io 329pf+0w > lcore -up (22:15:40) 0.240u 0.000s 0:00.42 57.1% 0+0k 0+0io 191pf+0w > lcore -dn (22:15:40) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > mixer (22:15:41) 1.820u 0.030s 0:03.65 50.6% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0205370000000000 :CHARGE convergence: 0 0 .1625775 188/8 to go > lapw0 (22:15:45) 8.780u 0.090s 0:17.74 50.0% 0+0k 0+0io 279pf+0w > lapw1 -up (22:16:03) 437.060u 11.240s 14:56.75 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (22:30:59) 437.750u 11.490s 14:58.52 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (22:45:58) 145.090u 0.590s 4:51.25 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (22:50:49) 130.740u 0.580s 4:22.64 50.0% 0+0k 0+0io 329pf+0w > lcore -up (22:55:12) 0.240u 0.000s 0:00.44 54.5% 0+0k 0+0io 191pf+0w > lcore -dn (22:55:12) 0.240u 0.010s 0:00.42 59.5% 0+0k 0+0io 191pf+0w > mixer (22:55:13) 1.800u 0.050s 0:03.66 50.5% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0166900000000000 :CHARGE convergence: 0 0 .1073723 187/7 to go > lapw0 (22:55:17) 8.430u 0.070s 0:16.95 50.1% 0+0k 0+0io 279pf+0w > lapw1 -up (22:55:34) 438.560u 11.300s 14:59.81 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (23:10:34) 437.060u 11.070s 14:56.23 50.0% 0+0k 0+0io 401pf+0w > lapw2 -up (23:25:30) 145.100u 0.470s 4:51.12 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (23:30:22) 130.760u 0.490s 4:22.43 50.0% 0+0k 0+0io 329pf+0w > lcore -up (23:34:44) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (23:34:45) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (23:34:45) 1.820u 0.040s 0:03.70 50.2% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0048560000000000 :CHARGE convergence: 0 0 .0964901 186/6 to go > lapw0 (23:34:49) 8.990u 0.050s 0:18.04 50.1% 0+0k 0+0io 279pf+0w > lapw1 -up (23:35:07) 438.530u 11.940s 15:00.95 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (23:50:08) 436.720u 11.430s 14:56.39 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (00:05:05) 145.210u 0.490s 4:51.31 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (00:09:56) 130.690u 0.480s 4:22.32 50.0% 0+0k 0+0io 329pf+0w > lcore -up (00:14:19) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (00:14:19) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (00:14:20) 1.840u 0.020s 0:03.65 50.9% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0031690000000000 :CHARGE convergence: 0 0 .0540543 185/5 to go > lapw0 (00:14:24) 8.900u 0.050s 0:17.84 50.1% 0+0k 0+0io 279pf+0w > lapw1 -up (00:14:42) 436.630u 12.050s 14:57.43 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (00:29:39) 436.930u 11.140s 14:56.15 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (00:44:35) 145.260u 0.590s 4:51.80 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (00:49:27) 130.890u 0.510s 4:22.78 50.0% 0+0k 0+0io 329pf+0w > lcore -up (00:53:50) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (00:53:51) 0.240u 0.000s 0:00.44 54.5% 0+0k 0+0io 191pf+0w > mixer (00:53:51) 1.830u 0.040s 0:03.67 50.9% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0006150000000000 :CHARGE convergence: 0 0 .0345955 184/4 to go > lapw0 (00:53:55) 9.070u 0.030s 0:18.22 49.9% 0+0k 0+0io 279pf+0w > lapw1 -up (00:54:13) 436.600u 11.350s 14:55.96 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (01:09:09) 437.220u 11.430s 14:57.58 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (01:24:07) 145.200u 0.400s 4:51.21 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (01:28:58) 131.100u 0.500s 4:23.22 49.9% 0+0k 0+0io 329pf+0w > lcore -up (01:33:21) 0.230u 0.010s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > lcore -dn (01:33:22) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (01:33:23) 1.810u 0.060s 0:03.72 50.2% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0003090000000000 :CHARGE convergence: 0 0 .0285507 183/3 to go > lapw0 (01:33:27) 8.870u 0.030s 0:17.84 49.8% 0+0k 0+0io 279pf+0w > lapw1 -up (01:33:44) 436.100u 11.870s 14:56.01 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (01:48:40) 436.460u 11.300s 14:55.51 50.0% 0+0k 0+0io 401pf+0w > lapw2 -up (02:03:36) 145.180u 0.420s 4:51.15 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (02:08:27) 130.790u 0.450s 4:22.43 50.0% 0+0k 0+0io 329pf+0w > lcore -up (02:12:50) 0.230u 0.020s 0:00.42 59.5% 0+0k 0+0io 191pf+0w > lcore -dn (02:12:50) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > mixer (02:12:51) 1.840u 0.020s 0:03.66 50.8% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0003735000000000 :CHARGE convergence: 0 0 .0197750 182/2 to go > lapw0 (02:12:55) 8.670u 0.040s 0:17.34 50.2% 0+0k 0+0io 279pf+0w > lapw1 -up (02:13:12) 437.020u 11.230s 14:56.57 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (02:28:09) 436.940u 11.410s 14:56.88 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (02:43:06) 145.190u 0.450s 4:51.19 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (02:47:57) 130.500u 0.480s 4:21.90 50.0% 0+0k 0+0io 329pf+0w > lcore -up (02:52:19) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (02:52:20) 0.240u 0.000s 0:00.42 57.1% 0+0k 0+0io 191pf+0w > mixer (02:52:20) 1.830u 0.040s 0:03.73 50.1% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0003920000000000 :CHARGE convergence: 0 0 .0080772 181/1 to go > lapw0 (02:52:24) 9.000u 0.060s 0:18.11 50.0% 0+0k 0+0io 279pf+0w > lapw1 -up (02:52:43) 437.860u 11.290s 14:58.42 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (03:07:41) 437.100u 11.230s 14:56.71 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (03:22:38) 145.690u 0.530s 4:52.43 50.0% 0+0k 0+0io 329pf+0w > lapw2 -dn (03:27:30) 130.700u 0.410s 4:22.24 49.9% 0+0k 0+0io 329pf+0w > lcore -up (03:31:53) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (03:31:53) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (03:31:54) 1.870u 0.020s 0:03.80 49.7% 0+0k 0+0io 215pf+0w :ENERGY convergence: 0 0.00001 .0003285000000000 :CHARGE convergence: 0 0 .0065214 restart 180/20 to go > lapw0 (03:31:58) 8.460u 0.050s 0:16.97 50.1% 0+0k 0+0io 279pf+0w > lapw1 -up (03:32:15) 436.650u 11.280s 14:55.99 49.9% 0+0k 0+0io 401pf+0w > lapw1 -dn (03:47:11) 437.040u 11.700s 14:59.27 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (04:02:10) 145.860u 0.490s 4:52.87 49.9% 0+0k 0+0io 329pf+0w > lapw2 -dn (04:07:03) 131.350u 0.570s 4:24.31 49.9% 0+0k 0+0io 329pf+0w > lcore -up (04:11:27) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (04:11:28) 0.240u 0.000s 0:00.42 57.1% 0+0k 0+0io 191pf+0w > mixer (04:11:28) 1.820u 0.030s 0:03.65 50.6% 0+0k 0+0io 214pf+0w :ENERGY convergence: 0 0.00001 .0000385000000000 :CHARGE convergence: 0 0 .0042511 179/19 to go > lapw0 (04:11:33) 8.500u 0.090s 0:17.10 50.2% 0+0k 0+0io 279pf+0w > lapw1 -up (04:11:50) 437.140u 12.020s 14:58.27 50.0% 0+0k 0+0io 401pf+0w > lapw1 -dn (04:26:48) 437.500u 11.510s 14:58.06 49.9% 0+0k 0+0io 401pf+0w > lapw2 -up (04:41:46) 145.200u 0.480s 4:51.98 49.8% 0+0k 0+0io 329pf+0w > lapw2 -dn (04:46:38) 130.260u 0.480s 4:22.14 49.8% 0+0k 0+0io 329pf+0w > lcore -up (04:51:00) 0.240u 0.010s 0:00.48 52.0% 0+0k 0+0io 191pf+0w > lcore -dn (04:51:01) 0.240u 0.000s 0:00.48 50.0% 0+0k 0+0io 191pf+0w > mixer (04:51:02) 1.840u 0.010s 0:03.82 48.4% 0+0k 0+0io 215pf+0w :ENERGY convergence: 1 0.00001 .0000055000000000 :CHARGE convergence: 0 0 .0045833 0/18 to go > stop - --0-886712059-1027935835=:41827-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 04:11:00 -0700 From: "Saeid Jalali" Subject: [WIEN]: Does P1/2 basis also improve EFG? ==== "Saeid Jalali" submitted the following contribution: ==== Dear all, Band structure calculation of fcc Th has shown that additional p1/2 local orbitals improve the description of actinide. This improvement is demonstrated by a reduction of second variation cutoff energy or E_max from 8 Ry within GGA+SO to 3 Ry within GGA+SO+P1/2 to calculate ENE. It is also shown that p1/2 modification does not change the distribution of valence bands, and hence any quantities related to the valence band. This means that p1/2 modification just a bit increases the separation between the pick of p1/2 DOS and the pick p3/2 DOS (~1eV), but does not change the total DOS in vicinity the Fermi energy. As a result of this fact, one does not expect to see a significant difference between two calculated equilibrium volumes within GGA+SO and GGA+SO+P1/2. Even though our calculated total energies of some actinide compounds for various second variation cutoff energies confirm such an reduction and thus the improvement of p1/2 basis, our calculated electric field gradient (EFG) does not follow the story at all. The later one means that EFG is in contrast with the reported improvement of P1/2 modification. We know that EFG mainly originates from valence band and a bit from semi core states. Therefore, one expects to observe a comparable behavior of EFG with other quantity relative to valence bands, say equilibrium volume. So, the question is the subject of this mail: Does P1/2 local orbitals improve the calculated EFG of actinide compounds or Does one just calculating EFG say that additional p1/2 local orbitals improve the description of actinide? Thank you for your attention to this matter. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 08:54:12 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Re: (Igor) ==== "Saeid Jalali" submitted the following contribution: ==== Dear Igor, I know you are on vocation and away from your mail for a week. I followed your recent discussion with Yue, and Peter in the mailing list during last week, and heard about your nice presented poster on SmZn. > 5) I can send you input files for SmZn (a well behaving calculation), if you > want to compare with yours. It will be appreciated not only sending the input files, but also a copy of your results (if possible). I am looking forward for your coming back to work. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 29 Jul 2002 18:59:12 -0500 (CDT) From: Bing Zhou Subject: [none] ==== Bing Zhou submitted the following contribution: ==== Dear All: My lapws crashed for my crystal calcultion for many times, I was told "STOP: SELECT - Error" even I changed the mixing factor from 0.5 to 0.01 and BROYD to PRATT, could you please let me know the possible reasons for it and how to remedy it? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 08:48:42 +0800 From: caij@ihpc.a-star.edu.sg Subject: [WIEN]: sorry just for test ==== caij@ihpc.a-star.edu.sg submitted the following contribution: ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 08:33:58 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Does P1/2 basis also improve EFG? ==== Peter Blaha submitted the following contribution: ==== > quantity relative to valence bands, say equilibrium volume. So, the question > is the subject of this mail: Does P1/2 local orbitals improve the calculated > EFG of actinide compounds or Does one just calculating EFG say that > additional p1/2 local orbitals improve the description of actinide? NO!!! We are working on that. The p1/2 basis should only contribute to the spherical part of the electron density, but so far we do not force this. Thus very small nonspherical contributions can occur and since the p1/2 function is non-zero at the nucleus, it leads to a diverging contribution to the EFG. So far, you MUST NOT use p1/2 LOs when you are interested in EFGs on that nucleus. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 01:33:04 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Does P1/2 basis also improve EFG? ==== "Saeid Jalali" submitted the following contribution: ==== I am thankful to Peter for his accurate contribution to the matter of added p1/2 function. > So far, you MUST NOT use p1/2 LOs when you are interested in EFGs on that > nucleus. We are calculating EFG at a tin nucleus, where even SO can be switched off. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 13:24:01 +0430 From: "Mahmoud Payami" Subject: [WIEN]: GETARG ==== "Mahmoud Payami" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_000D_01C237CC.5E4A2A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Wien users and developers, When running "x nn", "x symmetry", "x lstart", "x kgen", "x dstart", I = encounter the message: GETARG: argument index (2) out of range. This message is continued in each cycle of the scf calculation. The file "lapw0.error" contains the message: error in lapw0. Any suggestions is highly welcome. Kind regards, M. Payami - ------=_NextPart_000_000D_01C237CC.5E4A2A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Wien users and = developers,
When running "x nn", "x symmetry", "x = lstart", "x=20 kgen", "x dstart", I encounter the message:
 
GETARG: argument index (2) out of=20 range.
 
This message is continued in each cycle = of the scf=20 calculation.
The file "lapw0.error" contains the = message: error=20 in lapw0.
 
Any suggestions is highly = welcome.
 
Kind regards,
 
M. Payami
 
- ------=_NextPart_000_000D_01C237CC.5E4A2A10-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 10:17:00 -0400 From: "Dadi Dai" Subject: [WIEN]: How to determine the space-group in AFM calculations? ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0040_01C237B2.3DFAFB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WIEN authors and users, I wish to carry antiferrimagnetic (AFM) calculation of CdVO3, which is = orthorhombic Pnma (group #62) with a=3D14.301, b=3D3.598, c=3D5.204. = The fractional coordinates are: Cd 0.3184 1/4 0.1383 V 0.0806 1/4 0.0826 O-1 0.1096 1/4 0.3930 O-2 -0.0579 1/4 0.0421 O-3 0.1941 1/4 -0.1064 In my calculations, the AFM chain is along c direction. Therefore, I = have to double the unit cell along c direction, namely, to make a = super-unit-cell 1*1*2. In this case, I can have two sets of V atoms, = and I can put up-spin in one set of V while putting down-spin in another = set of V. My question is, what space-group should I specify in struct-generation = for the AFM super-cell? (It seems to me that the new super-cell does not satisfy #62 any more, = after there are two sets of V.) Thank you very much. Dadi Dai - ------=_NextPart_000_0040_01C237B2.3DFAFB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear WIEN authors and users,
 
I wish to carry antiferrimagnetic (AFM) calculation of CdVO3, = which is=20 orthorhombic Pnma (group #62) with a=3D14.301, b=3D3.598, = c=3D5.204.  The=20 fractional coordinates are:
 
Cd    0.3184    1/4    = 0.1383
V     0.0806    = 1/4   =20 0.0826
O-1    0.1096    = 1/4   =20 0.3930
O-2    -0.0579    = 1/4   =20 0.0421
O-3    0.1941    = 1/4   =20 - -0.1064
 
In my calculations, the AFM chain is along c direction. =20 Therefore, I have to double the unit cell along c direction, = namely, to=20 make a super-unit-cell 1*1*2.  In this case, I can have two sets of = V=20 atoms, and I can put up-spin in one set of V while putting down-spin in = another=20 set of V.
 
My question is, what space-group should I specify in = struct-generation for=20 the AFM super-cell?
 
(It seems to me that the new super-cell does not satisfy #62 any = more,=20 after there are two sets of V.)
 
Thank you very much.
 
Dadi Dai
 - ------=_NextPart_000_0040_01C237B2.3DFAFB00-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 20:14:42 +0300 From: "B. Yanchitsky" Subject: Re: [WIEN]: How to determine the space-group in AFM calculations? ==== "B. Yanchitsky" submitted the following contribution: ==== This is a multi-part message in MIME format. - --------------C785FA1BCAA842715597B471 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit >Cd 0.3184 1/4 0.1383 >V 0.0806 1/4 0.0826 >O-1 0.1096 1/4 0.3930 >O-2 -0.0579 1/4 0.0421 >O-3 0.1941 1/4 -0.1064 >In my calculations, the AFM chain is along c direction. Therefore, I have to >double the unit cell along c direction, namely, to make a super-unit-cell 1*1*2. >In this case, I can have two sets of V atoms, and I can put up-spin in one set of >V while putting down-spin in another set of V. >My question is, what space-group should I specify in struct-generation for the >AFM super-cell? >(It seems to me that the new super-cell does not satisfy #62 any more, after >there are two sets of V.) It's quite simple, but with a lot of typing. The main idea - construct 1x1x2 supercell and introduce manually split for V atoms only, and find new cupercell with "x sgroup". Below is attached 1x1x2 cupercell (with sgroup output), (if no split for V) then sgroup finds reduced supercell with #62 Pnma as it should be. With split for V atoms, new cell is monoclinic and space group is #11, but note that new 001 direction is 010 old one. ps it appears a small problem. Actually sgroup treats only 1-2 literal positions for an atom name and appends digits to it if any. But with such treatment it is not clear where are up and dn atoms in output file. So to split V atoms i changed V -> Vu for up, and V -> Vd for down. Make a check for initial CdVO3 file of course :) Regards, Bogdan Yanchitsky - --------------C785FA1BCAA842715597B471 Content-Type: application/octet-stream; name="CdVO3.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CdVO3.tar.gz" H4sIAC8lOTwCA+1dbW/jNhLOZ/0KFvelBuqUHJGiZFwOSNMUyCGJc0m6193D4eC1nY0Bx079 stv++9N79DKUOHZ3sauYH2JbGY6Gw0d6OKOxeTZ5M3R/PPqsjXPJtVLhKxdaedErF1LGr2k7 4loKD1wXIjkhOFdHTB19gbZdb0Yrxo4e5qPnT41y09X6qHPtLJ7/+O/xerPajjefYf7D6fSS +cbmX3M3mn8FQklXCR3KuyI8xPhh/j97u59t5lPnhjF2eXp/f3F2/sP18Pr8X79evDlmp/fD q7sB85yr4c/nbPgLOzu9PDu5Pb88dZiQx240r5wx91gFfvxO8GPJw7cs4MfJ3GLvnNPN8umE 9cWA/XbCj13hy1jgbfgBVCr9LvzAvUBEnx2Wt6tfL+9PmP9y4OLu5vIiOlTR6vnCy7Xqolbp cl/VzfCNZggf7SCMZ3BFarftQJWHdjCPIaCOwaOOwc/GcDbJfX19EzqaaV8wdstPkumMIXB7 Ff2DMYgPhW/eDZj0j4sTV2gixQFnvP4O7/IiKOhdkM6ZGyBxQ4hZzwBBGd6JMAjKBgimWgMR SAMEla8RM5TRDOBoB2k8AwSp3W+2jdOnTNMH7jcwfW7b9Kldps9tm76gMn1u2/RpjnYwT5/O p2/S4emT6U2IBwa/icBTnEoAqVY/4AbnutxViBme0Qyu0A6u8QxSeoo0UC9AO5jH4FPHoKhj CLIxDFkTBAU3QZB9CwSg0mtdgjDMffgP8hok1cqVDgwA0X6g6mZIoxkAaAdlPAPo1G7bgSpA O5jHEFDHoKlj0NkYOg1BL705BNLgt/Bu4pPvgqlWnyuDc8ObGiBmeEYzwtsm1sE1niG8e/uk gQYS7WAeg6KOwaeOwcvG0E0IRgLs7u3V1fn97Vs2vDm/Pb2/GF7fDZyjQ3sVLcn/DObLD58x /9ec/wmXsVDN/ymtDvmfL9Gulgv2z9EivJ8xrgauGLiSnZ3fs/A2Cf9g3//RY+sPq+X2mR3u CB2+/pP873K7ed5ukvn+cte/CvnWq1z/MiTww/X/Jdqn0WoxW3wYsO+++45db5/eT1ds+cBm i+nv29nH0Xy62LBRuFhas8fRmo0fR4sP08nxy1oj6jacT1goup2eMC9ZIU0/ZQeAO07pHP9e LRcf2NN2vpk9z2fj2eZP9rBcxedgoqz3Ln4ewR5m8ymbrdliuWHj5WI9W28iqz7NNo9s/Twa T1lyh3pYbhehaU7/L2mO89Nq9HEUnnc+2mxm4+mAhffK5Xg+W8zG7Hk1e5ptZh+nTmLyqLTo el/8MC4ky+NVYZ4mTz5m6fNsBTeaPz++qHs/3bx8+DB6eho5L5n0RF35Y+GT4zgnUWM/T8fL p+flOrQ4vN2H07sIJ+j9KPQk+zgdb5arNVt+DCd+tgiv//QfcU+nn60VC0vJ4ru/h56Kpo1j YqIsBiUxYdLmJlYXwJjgb7Zg4+l8PmCSJwLRGp5lo1oPnEh9njKP1GZ5+Oh9FgY47GzisEIy nrGX7Hj0XlcERVFj9uwA0+gXNWYZfUxjyUbf1kZha2NgayM32RhJ5tnPWE2ajiyrfLONJzTL esZq0kRnWWUiKIsasww4plEVNWYZ3JrGmpEaN3JSMxJwIyc1IwPcyEnNSI4bmXgyT+LF406z amWVw3gSs9xdPOw0XVfWGMu5RX1ZLhPR5xX1ZQlGRF/JvsDSPm5pn29pnzDbl2egYh1pSgjR l6e2Yh1prgnRp4r6skQcok8W9WXZsTb7tKV9YGlfYGkfN9uXp09SHPim+c2yJimuwDS/RX1Z Bgab36K+LIfVZp+wtM+3tI9b2hcY7KtS0WJZXBitl6vNehCtcRKxZW3V9ENIULPwQ7ZCWbHp aPwYdxzEFOs4d+F7tojPMIhXQNejp+k6Olmh64A9JUuA9OVs7STLrDKLRyfYPIYHil2dl2xT Ts8vrxmDF/6VC5dkoCyTvRHHZe5mVV5OOlpRcziuCfte9JxUppWi8w5lL0J3vWixHEmcAqkX LZYleYeyF91XgkW/AYsuhkXRgEW36kX5SrAYNGBRYljkDViUVS+q7nrRYqXNwgXvy33RYsWd dyh70euuFy2ii8Qp2X3RIsrIO5S9qF8JFrUJixMDFsGERYyj/VeCxcCExYkBi9yERYyjg+56 0SJuZmz4AkWL+DmTr6y5eXedaJEsiJ2SIdEiaZDJV5woXgkSAzMSXQyJ3IzE2lpRwCtBom9G osSQKMxIrC0VRYfjFotcWOwUlTrRIieWyVec2OGwxSIBGDvFS51okQjM5CtOVK8EidqMRI0h EcxI1DUneq8EiYEZiT6GRG5Gol9zYodjFov8duyUIGPn9jx3Jl9xYodDFoukfrJ45hk9t2f3 8w4VNwavBIvCjEUhMDD6ZjCKeo6bvxI08gY0AobGoAGNUdxy8pc0x0mfCo0WE7YI5yGahkI5 ShQSse9vGIgfn3rsP9vF7PftlI3+CD0+/q/TZ3eP0Wz22S/b+Tx8uRs/LqeLh/ksnM9+rK82 rw6DH+M5TV/O4DE3Ijr3n09P083qT7Z8nq5GqUOlM8w+xQ+XwilInJr9jefGSY8Iw/HCf5Pj Ra0QF4mYtfattKqKVncvrX2DrXIvD/SLtu6HnZPKc8XwGljP3s+nbP04e9hkF+mA+WkdTiJ/ OVtv4qkuCTn1Ky19g/9HVf+jjH1UtY8ynkcZz6OM51H4eZzSOKeTuO4nKvA5C1/Z3wQLr+a7 ggsGrGGc2FNZ1lIsVKyGSRJMDU8joSrcWDVUVg29xsohqAo3lg+VVbu9xhIiqAo31hGVVcte Yy0RVIUb64mKRT2Zr41POKAq3FhYVFad+NqY9oeqcGOBUbHKB7UacKsnuNUBbvUEtZrjVr8g xJg5LVQ2ZEYbs6ZQkW0sPSopTkw2ZhKhIttYg1RS7PYa65CgIttYjFRSLHuNBUlQkW2sSiop Vr3GyiSoyDaWJ5UUe73GEiWoyDbWKZUU615jrRJUZBsLlkqK/V5j0RJUZBsrl0qKg15j9RJU ZBtLmMoXCO811jFBVbixmqmsWvQaS5qgKtxY2FRWDb3G6iaoCqesCs2sWuFuW1Y1lbeirGoq ccVZ1VTnirKqqdYVZ1XXaLXbsy4exllVGq2WPesqYpxVDQWw21Z+0q2saqiE3bbyk25lVUNt 8aR1LaBbWdVQZDxpXQvoVlY11MmirGqolcVZ1VAwi7KqoWi2fR0ALayqTBa7LesAaGFVz2Sx bOEoaGFVQz0tzqqGolqUVQ2FtTirgsli3bOtUMZZVZos9nu2pco4qxrqbVFWNdTc4qxqKLzF WdVQfWtgVc9kM8aqrslolFWV0Wro2dY0l1jVtWRVtTOragqrAolVNYVVgcSqmsKqQGJVTWFV ILGqprAqkFhVU1gVSKyqKawKJFbVFFYFEqtqAqsChVU1gVWBwqqawKpAYVVNYFWgsKomsCpQ WFUTWBUorKoJrAoUVtUEVgUKq2oCqwKFVTWFVYHEqprCqkBiVU1hVVOsKlFWNeWmG1hV2EV9 ok4iXlus6tlFfVCnPtUWqwq7CNutWy3aYlXPLsKWdat5W6wqbb5Rmvla2XyrNPd1YPPV0szX 3Obrpbmvpc1XTFGroS1WDWy+a4pazdtiVdcq8hN1KlEtsapvFflBnfy8lljVtYqu3brFvCVW 9a2ia1m3WLTEqsoq8lN1KtEtsSq3ivy8OvmpllhVWUXXum4xtMSq3Cq69usW85ZY1bWK+4I6 i7gtsapvF/XxOvXJtljVtYqvU1b1rALsjFV9uwgb6lYHFrGqsmRVtTOragqrAolVNYVVgcSq msKqQGJVTWFVILGqprAqkFhVU1gVSKyqKawKJFbVFFYFEqtqAqsChVU1gVWBwqqawKpAYVVN YFWgsKomsCpQWFUTWBUorKoJrAoUVtUEVgUKq2oCqwKFVTWFVYHEqprCqkBiVU1hVVOs6jWz qtotVvUpsaogxaoBJVblpFjVpcSqHilWlZRYVZFiVU2JVYEUqwaUWJWTYlWgxKqaFKtKSqyq SLFqQIhVOSVW9QmxqqDEqpIQqypKrOoSYlWPEqtqQqwKlFg1IMSqnBKrAiFW1ZRYVRJiVUWJ VQUhVvUpsSqnxKoBKVb1KLGqS4pVFSVWtXmuqi1ZVe3MqprCqkBiVU1hVSCxqqawKpBYVVNY FUisqimsCiRW1RRWBRKragqrAolVNYVVgcSqmsCqQGFVTWBVoLCqJrAqUFhVE1gVKKyqCawK FFbVBFYFCqtqAqsChVU1gVWBwqqawKpAYVVNYVUgsaqmsCqQWFVTWLVGwYffQT/8/nu2/+f/ /vIfgG/+/Xfhua6o/v67Cg8dfv/9q9j/E3j0Tdab6HuszRuB5j9rXtgStGUj0PAEJ4xh213m i9p3J+Wv/ZZ2QAJsB6Rsfx1k18189fuusNGPczYRu29xeTkMncFuh/fs6vT+9uK3wVezvVTi XEB2+syX9Ts7F5ANR/P1f8W50F3nughy/b2R6yLIFQbkut11rkSQG+yNXIkglxuQK7vrXIVs cpoHtzs7VyEbsuZRcMm5b7Zi941Nv3bnesj+rnl4v7NzPWSb2TwPUHEudNe5Gtued2/kamwr YRy5zffcb9u5PoLcYG/k+ghyOY7c5nvut+3cANnVN0907ezcANlcOE+JlZw7ZGL3PSy/cucK jmxonCf7dnVuprW0r3KeFqw4F7rrXIEgN9gXuZnWEnK5Ablud50LCHL9vZELCHKFAbmyu851 kW2s88T3zs51kd208xR5xbmqu86VyA7eefJ/Z+dKZCPx/DFBxbled52LbsC+N3LRfeANyNXd da6HIDfYG7keglxuQK7fXedqZN/2/DHYzs7VyPbx+fOyinOD7jrXR7aszx8E7uzcVKtXdG7+ xLAaRPDOOjdAkCv2Rm6AINc3IFeIrjoXOIJcvi9yM60l5AYm5EL3nBultNNB/Xr10/lt9Hju 7u3V1fn97Vs2vDm/Pb2/GF7fOWHsz1npXDw5VDwQH6paI5x+vW/f0LcyhWDZt4+c17W0uY+c Vx5KGg7t0A7t0A7t0A7t0A7t0Ort/w3tZF0AoAAA - --------------C785FA1BCAA842715597B471-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 30 Jul 2002 11:27:06 -0700 From: "Saeid Jalali" Subject: [WIEN]: Does -so split automatically p to its partial relativistic states? ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_002E_01C237BC.0956FBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Is not it assumed that p-orbital of an actinide metal, e.g. fcc-Th, = should automatically split to p1/2 and p3/2 after turning on the = spin-orbit coupling or one needs to do something special? We have = accidentally looking for something else found that p of fcc-Th is not = splitted to its partial relativistic orbitals within GGA+SO or = GGA+SO+p1/2 with and without spin polarization. Thus, we at this stage = conclude that one needs to do something special. Are we in a right = stage?! Spin intrinsically introduces itself solving fully relativistic = Dirac equation, and so one thinks SO also cannot be independent of spin = as it is. Indeed SO as an approximation to take into acount relativistic = effect is a term proportional to a dot product of spin and orbit = vectors. It looks all these are telling us one does not need to do such = an special job to split p-orbital to p1/2 and p3/2 provided that SO does = its job correctly. So, my questions are as follows: Why is not p-orbital = of fcc-Th in the energy interval (-25eV, -13eV) within GGA+SO splitted = to p1/2 and p3/2, and how can it be done? Why is not the command of = "run_lapw -so" meaningless, although imposing magnetic moment also has = not shown an effect on splitting? Thank you for your attention to this problem. Your, S. Jalali. =20 =20 - ------=_NextPart_000_002E_01C237BC.0956FBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = all,

Is not it assumed that = p-orbital of=20 an actinide metal, e.g. fcc-Th, should automatically split to p1/2 = and p3/2=20 after turning on the spin-orbit coupling or one needs to = do something=20 special? We have accidentally looking for something else found that p of = fcc-Th=20 is not splitted to its partial relativistic orbitals within GGA+SO or=20 GGA+SO+p1/2 with and without spin polarization. Thus, we at this stage = conclude=20 that one needs to do something special. Are we in a right = stage?! Spin=20 intrinsically introduces itself solving fully relativistic Dirac = equation, and=20 so one thinks SO also cannot be independent of spin as it is. Indeed = SO as=20 an approximation to take into acount relativistic effect = is a=20 term proportional to a dot product of spin and orbit vectors. It looks = all these=20 are telling us one does not need to do such an special job to split = p-orbital to p1/2 and p3/2 provided that SO does its job = correctly.=20 So, my questions are as follows: Why is not p-orbital of = fcc-Th in the=20 energy interval (-25eV, -13eV) within GGA+SO splitted to p1/2 and = p3/2, and=20 how can it be done?  Why is not the command of "run_lapw -so"=20 meaningless, although imposing magnetic moment also has not shown = an effect=20 on splitting?

Thank you for your = attention to this=20 problem.

Your,

S. = Jalali.

 

 

 

- ------=_NextPart_000_002E_01C237BC.0956FBB0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 31 Jul 2002 20:35:05 +0900 From: =?ks_c_5601-1987?B?wMy9wsO2?= Subject: [WIEN]: lattice parameter and bulk modulus of hcp & fcc WC ==== =?ks_c_5601-1987?B?wMy9wsO2?= submitted the following contribution: ==== Dear WIEN2k users, I am novice in ab initio calculation. Now, I'm trying tocalculate energetics of hexagonal and fcc(NaCl) WC system. After lattice parameter optimization, I compared the equilibrium lattice parameter of both cases to experimental results. 1) hcp WC: lattice parameter a=5.49 au(Exp.) 5.43 (This Calculation) c=5.30 bulk modulus 329GPa (Exp.) 382 (This Calculation) 2) fcc WC: lattice paramter a = 8.00 au (Exp.) 8.28 au (This Calculation) bulk modulus 319 GPa (LMTO) 378 GPa (This Calculation) I think this discrepancy with the experimetal result is somehow large. To check the reliability of my calculation, I calculated hexagonal and fcc TiC that is the same strucure with the WC. In the TiC case, experiments and calculation results showed 0.1 % or less discrepancy. Is there another additional parameter should be included in WC case? As a reference, my initial condition is as follows, W RMT=2.0, C RMT= 1.7 700 kpoints RKmax=7 Energy window Emin= -7.0 Emax=3.5 in case.in1 Other parameters are the same as a standard input. In my personal experiences, W is a difficult material to treat. It convergence properties were poor. Thank you in advance. Seung-Cheol Lee, Ph. D. Research Scientist Supercomputational Materials Simulation Lab. Future Technology Research Division Korea Institute of Science and Technology PO Box 131, Cheongryang, Seoul 130-650, KOREA Tel) 82-2-958-6759 Fax) 82-2-958-5509 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 01 Aug 2002 15:17:48 +0800 From: Kulkova Subject: Re: [WIEN]: lattice parameter and bulk modulus of hcp & fcc WC ==== Kulkova submitted the following contribution: ==== Dear Dr.Lee,

In order to get good bulk modulus for hcp system the additional c/a optimization for every volume must be also performed. I checked this procedure for hcp BN.

Regards

Svetlana Kulkova

 
Prof. Dr. Svetlana E. Kulkova
Russian Academy of Science
Institute of Strength Physics and Material Science
Russia, 634021 Tomsk
pr.Akademichesky 2/1
E-mail : kulkova@ispms.tsc.ru, kulkova@ms.tsc.ru
My website:
http://www.ispms.tsc.ru/eng/kulkova.shtml
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/_/
  ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 1 Aug 2002 16:03:28 +0200 (CEST) From: =?iso-8859-1?q?youcef=20cherchab?= Subject: [WIEN]: helpfull ==== =?iso-8859-1?q?youcef=20cherchab?= submitted the following contribution: ==== Hello , I had a question about the ZnO -DOS I've had some problems with input data for getting a best result Idon't know what I can do for this my list input:RMT(Zn)=2.1 RMT(o)=1.5 R*Kmax=8 Lmax=10 for wurzite and zinc blend structure is wonder if anyone had somesuggestions/input. Any suggestions or help? Thanks in advance, Cherchab ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #29 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #30 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Saturday, August 10 2002 Volume 2002 : Number 030 ---------------------------------------------------------------------- Date: Thu, 1 Aug 2002 20:50:38 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: Electron density plotting ==== Bing Zhou submitted the following contribution: ==== Dear All: When I used w2web to plot the electron density for my crystal tugtupite after the SCF was done using parallization mode (11 cycles), I found that there was no the file "tugtupite.in2" although there exists the following files: tugtupite.in2_ls tugtupite.in2_st tugtupite.in2_sy tugtupite.in2c Then, I copied tugtupite.in2_st as "tugtupite.in2" file and run other steps such as lapw2, lapw5. Finally I run rhoplot, however, I was told there was no "tugtupite.vector" file although there exist the following files: tugtupite.vector tugtupite.vector_2 tugtupite.vector_4 tugtupite.vector_6 tugtupite.vector_1 tugtupite.vector_3 tugtupite.vector_5 tugtupite.vector_7 After I checked the file "tugtupite.vector", I found it was a empty file, nothing there. So my questions are: 1. why are there no files tugtupite.in2 and tugtupite.vector? 2. How can I get the electron density plot for tugtupite? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 2 Aug 2002 13:21:56 +0900 From: ARAI Masao Subject: [WIEN]: sumpara (Intel Fortran on Linux/x86) ==== ARAI Masao submitted the following contribution: ==== Dear Wien users and developers, The sumpara fails to execute on my environment(Intel Fortran on Linux/x86). On other enviroments(Compaq Fortran/Alpha), it works without problems. If I understand correctly, It occurs due to undefined strings in sumpara.f and/or bug in the Intel Fortran Compiler. From lapw2para, sumpara is executed twice. First time as % sumpara sumpara.def 2 and second time as % sumpara sumpara_vresp.def 2 (Here, I assume parallel execution on two machines.) In second execution, the content of sumara_vresp.def is as follows. 6,'case.outputsum', 'unknown','formatted',0 17,'case.vrespval', 'unknown','formatted',0 20,'case.struct', 'old', 'formatted',0 21,'case.scf2', 'unknown','formatted',0 22,'case.scf2p', 'unknown','formatted',0 In sumpara,f line 98 to 113, 98 idu=0 99 783 CONTINUE 100 READ (1,*,END=784,ERR=960) IUNIT,FNAME,STATUS,FORM,IRECL 101 OPEN (IUNIT,FILE=FNAME,STATUS=STATUS,FORM=FORM,ERR=920) 102 IF(IUNIT.EQ.8) scfdmatFN=FNAME 103 IF(IUNIT.EQ.17) CLMFN=FNAME 104 IF(IUNIT.EQ.21) SCFFN=FNAME 105 IF(IUNIT.EQ.22) SCFALL=FNAME 106 107 IF(IUNIT.EQ.10) dmatFN10=FNAME 108 IF(IUNIT.EQ.11) dmatFN11=FNAME 109 IF(IUNIT.EQ.12) dmatFN12=FNAME 110 IF(IUNIT.EQ.11) idu=2 111 GOTO 783 112 784 CONTINUE 113 CLOSE (1) the statements from line 107 to 110 are not executed because file numbers 10,11,12 are not defined. Therefore, dmatFN10, dmatFN11, dmatFN12 are undefined. From line 313 to 321, 313 DO II=1,IPROC 314 write(6,*)'DMAT summation of file ',II 315 DO ifile=0,idu 316 close(10+ifile) 317 IF(ifile==0) dmatfn=dmatfn10 318 IF(ifile==1) dmatfn=dmatfn11 319 IF(ifile==2) dmatfn=dmatfn12 320 call mknam(FNAME,dmatFN,II) 321 OPEN(10+ifile,FILE=FNAME,STATUS='unknown',FORM='formatted',err=200) 322 write(6,*)FNAME The undefined dmatfn10 is used here, which seems to cause trouble on my enviroment (Intel Fortran Compiler onf Linux/x86). On other enviroments, I think that undefined FNAME causes I/O error on 321 and execution moves to "200". But it is not the case for Intel Fortran and the execution continues to next lines. If I insert initialization of dmatFN10 before line 99, sumpara executes without errors. 98 idu=0 99 dmatFN10 = "This_file_should_not_exist" 100 783 CONTINUE - -- Masao ARAI National Institute for Materials Science (NIMS) Tel: 0298-51-3354 ext.504 (+81-298-51-3354 ext.504) Fax: 0298-52-7449 (+81-298-52-7449) mail: arai.masao@nims.go.jp ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 02 Aug 2002 12:41:39 -0500 From: Pablo de la Mora Subject: [WIEN]: Total energy ==== Pablo de la Mora submitted the following contribution: ==== Dear Wien Users, Many timies that I am running a case the total energy jumps to a crazy value, for example :ENE : ********** TOTAL ENERGY IN Ry = -85889.063569 :ENE : ********** TOTAL ENERGY IN Ry = -85888.376196 ... :ENE : ********** TOTAL ENERGY IN Ry = -85914.716059 :ENE : ********** TOTAL ENERGY IN Ry = -85899.505409 :ENE : ********** TOTAL ENERGY IN Ry = -1129079.435723 :ENE : ********** TOTAL ENERGY IN Ry = -1129079.071157 ... :ENE : ********** TOTAL ENERGY IN Ry = -1129163.301102 :ENE : ********** TOTAL ENERGY IN Ry = -1129103.852864 The jump happened when after noticing that the run was not converging, then I cleaned the directory (clean_lapw) and did a 'restore - -f -d conv init' (I had done a 'save_lapw' of the initial files). I changed the Broyden mixing factor and restarted the run, then the energy value had jumped. after this the energy stayed around this arbitrary large value. This has happened in many other cases. Yours Pablo de la Mora ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 2 Aug 2002 16:33:21 -0400 From: Pierre Carrier Subject: [WIEN]: Physical units of .m1 and .m2 ==== Pierre Carrier submitted the following contribution: ==== Dear Wien users, The two files .m1 and .m2 give (the square of) the l+1 and l-1 energy dependent dipole matrix elements, as explained in the manual. What are the physical units of these files ? I don't find it in the manual. The first column is very likely in eV, but the second ? Thanks in advance, Best regards, Pierre - --------------------------------------------------------------------- Pierre Carrier Tel: 514-343-6111 #4226 Bureau A-407 Fax: 514-343-2071 Département de physique Boite vocale: 514-409-2238 Université de Montréal C.P. 6128, succursale Centre-ville Montréal, QC, H3C 3J7 Canada Pierre.Carrier@UMontreal.CA http://www.esi.umontreal.ca/~carriepi - --------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 02 Aug 2002 18:06:48 -0500 From: Pablo de la Mora Subject: Re: [WIEN]: Total energy ==== Pablo de la Mora submitted the following contribution: ==== Dear Wien Users, I updated the WIEN version from WIEN2k_01 WIEN2k_02 and rerun a cycle and the normal energy returned. So it seems that it was a problem of older versions. If this problem returns I will bother you again. Pablo de la Mora Pablo de la Mora wrote: > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > Dear Wien Users, > Many timies that I am running a case the total energy jumps to a > crazy value, for example > :ENE : ********** TOTAL ENERGY IN Ry = -85889.063569 > :ENE : ********** TOTAL ENERGY IN Ry = -85888.376196 > ... > :ENE : ********** TOTAL ENERGY IN Ry = -85914.716059 > :ENE : ********** TOTAL ENERGY IN Ry = -85899.505409 > :ENE : ********** TOTAL ENERGY IN Ry = -1129079.435723 > :ENE : ********** TOTAL ENERGY IN Ry = -1129079.071157 > ... > :ENE : ********** TOTAL ENERGY IN Ry = -1129163.301102 > :ENE : ********** TOTAL ENERGY IN Ry = -1129103.852864 > > The jump happened when after noticing that the run was not > converging, then I cleaned the directory (clean_lapw) and did a > 'restore -f -d conv init' (I had done a 'save_lapw' of the initial > files). I changed the Broyden mixing factor and restarted the run, > then the energy value had jumped. after this the energy stayed around > this arbitrary large value. > This has happened in many other cases. > Yours > > Pablo de la Mora > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 2 Aug 2002 22:39:10 -0400 (EDT) From: Igor Mazin Subject: Re: [WIEN]:Spam alert ==== Igor Mazin submitted the following contribution: ==== For many years I was careful not to have my e-mail address accessible for spammers' harvesting robots. Last month I signed up for the WIEN list, having forgotten that thetraffic is being posted on the web. Sure enough, as of today my mailbox receives up to 12 spam messages which makes my life miserable. I travel a lot, often have bad connection to the Internet, and now I cannot get to my mail because ofthe flood spam. SOMETHING HAS TO BE DONE! I do not know what, I'll think, let's think together, but our mails SHOULD NOT APPEAR on the web! For the moment being, I will really, really appreciate, if Peter or Georg would make %s/dave.nrl.navy.mil/dave\.nrl\.navy\.ml, or something similar. Then at least I have a chance that this spam flood will dry out in few months. Please, please!i Sorry, sorry for an offtopic, Igor ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 2 Aug 2002 08:54:16 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Does -so split automatically p to its partial relativistic states? ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0012_01C23A02.2ED76990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear wien users, This is to answer the following dirty question of mine! >Why is not p-orbital of fcc-Th in the energy interval (-25eV, -13eV) = within GGA+SO splitted to p1/2 and p3/2, and how can it be >done? It is if one does not FORGET to add -so switch to lapw2 -qtl command: x = lapw2 -qtl -so!!! Your, S. Jalali. - ------=_NextPart_000_0012_01C23A02.2ED76990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear wien users,
This is to answer the following dirty question = of=20 mine!
>Why is not = p-orbital of=20 fcc-Th in the energy interval (-25eV, -13eV) within GGA+SO splitted = to p1/2=20 and p3/2, and how can it be >done?
It is if one does not = FORGET to add=20 - -so switch to lapw2 -qtl command: x lapw2 -qtl = - -so!!!
Your,
S.=20 Jalali.
- ------=_NextPart_000_0012_01C23A02.2ED76990-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 2 Aug 2002 23:22:34 -0700 (PDT) From: hamid salehi Subject: [WIEN]: STDOUT ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started "Electron density" and got this message in "X Lapw2-up" LAPW2-Error. what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 04:29:11 -0700 (PDT) From: hamid salehi Subject: Re: [WIEN]: STDOUT ==== hamid salehi submitted the following contribution: ==== - --- hamid salehi wrote: > ==== > hamid salehi > submitted the following contribution: > ==== > > Dear wien users. > Ihave started "Electron density" and got this > message > in "X Lapw2-up" LAPW2-Error. what dose it mean? > Thank you for the guide. > H-Salehi > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 14:15:42 +0200 From: "Dr. Alexander Hofmann" Subject: Re: [WIEN]:Spam alert ==== "Dr. Alexander Hofmann" submitted the following contribution: ==== Dear Igor, I'm also subscribed to WIEN list (since ~3 months with my new email adress) and I'm receiving NO spam. Perhaps for two reasons (additions are welcome): - - My top level domain is another (.de). So robots are 'intelligent' - - The source of your email address is another than WIEN. With best regards Alex - -- Dr. Alexander Hofmann Humboldt-Universitaet zu Berlin Institut fuer Chemie Arbeitsgruppe Quantenchemie Brook-Taylor-Strasse 2 12489 Berlin ah@chemie.hu-berlin.de Tel.: +49-30-2093-7138 Fax.: +49-30-2093-7136 http://www.chemie.hu-berlin.de/ag_sauer/index.html PGP-Key: wwwkeys.de.pgp.net ID: D9D62D35 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 06:12:22 -0700 (PDT) From: hamid salehi Subject: [WIEN]: DOs ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started DOs and got this message in LAPW2-qtl Error. what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 15:16:49 +0200 (MEST) From: Ravindran Ponniah Subject: Re: [WIEN]:Spam alert ==== Ravindran Ponniah submitted the following contribution: ==== On Fri, 2 Aug 2002, Igor Mazin wrote: > ==== > Igor Mazin > submitted the following contribution: > ==== > > For many years I was careful not to have my e-mail address accessible > for spammers' harvesting robots. Last month I signed up for the WIEN > list, having forgotten that thetraffic is being posted on the web. > Sure enough, as of today my mailbox receives up to 12 spam messages > which makes my life miserable. I travel a lot, often have bad connection > to the Internet, and now I cannot get to my mail because ofthe flood spam. > > SOMETHING HAS TO BE DONE! I do not know what, I'll think, > let's think together, but our mails SHOULD NOT APPEAR on the web! > > For the moment being, I will really, really appreciate, if Peter > or Georg would make %s/dave.nrl.navy.mil/dave\.nrl\.navy\.ml, > or something similar. Then at least I have a chance that this > spam flood will dry out in few months. Please, please!i > > Sorry, sorry for an offtopic, Dear Igor, I am also having the problem of receiving almost 10 spam mails per day. Using exim filter I am able to solve the problem (i.e. morethan 90% of the spam mails are filtered out). If you are interested to filter out your spam mails, I can send to you the necessary instructions in a seperate email. I feel that one of the possibility of getting the email address by the spammers from the papers we publish with our email address. Best regards Ravi *********************************************************** Dr.P.Ravindran, Department of Chemistry|Tel: +47 22 85 56 06 University of Oslo, PO Box 1033 |Fax: +47 22 85 54 41/55 65 Blindern, N-0315 OSLO, NORWAY | Email: ravindran.ponniah@kjemi.uio.no | URL : http://folk.uio.no/~ravi/ | ************************************************************ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 12:01:47 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: lapw1 problem ==== Bing Zhou submitted the following contribution: ==== Dear All: After the first SCF calculation, it always crashed in running lapw1 in second cycle no matter how hard I tried using WIEN2k_02. I tried the parallization and single mode, the results are same, both crashed at the same place, and I was told "STOP SELECT Error". I changed the mixer vaule to 0.001 and switched BROYD to PRATT, but the calculation was still crashed with the same problem. So my questions are: 1. what might be the reasons caused the crashing in lapw1 with the message "STOP SELECT Error"? 2. How can I remede the problem? Thanks in advance! Best wishes! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 5 Aug 2002 11:55:11 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: Some questions ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien, I have some general simple questions, 1) I haven't been able to have SCF run more than 20 iterations, can I extend this by some parameter, or is this the max that Wien will do. I haven't been able to find any clues on this yet. 2) In my slab calculation, the total energy has :WARNING: befor announcing the value. Can anyone tell me what this means, eg :ENE : *WARNING** TOTAL ENERGY IN Ry = -1745.650010 Thanks, Cheng Chen ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 4 Aug 2002 23:12:53 -0400 From: Fred Nastos Subject: Re: [WIEN]: Some questions -- answer to 1) ==== Fred Nastos submitted the following contribution: ==== > 1) I haven't been able to have SCF run more than 20 iterations, can I > extend this by some parameter, or is this the max that Wien will do. I > haven't been able to find any clues on this yet. Yes. This is in the userguide in Chapter 5: Shell scripts for running programs. More specifically, it is page 50-51 in my version of the userguide. You control the maximum number of iterations with the flag -i for run_lapw. So, if you wanted a maximum of 100 iterations you would run run_lapw -i 100 and all the other options you would add. In w2web I believe you can pass these through the "expert options" in the run SCF menu. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 05 Aug 2002 14:36:23 +0430 From: Payami Mahmoud Subject: [WIEN]: PGFIO error ==== Payami Mahmoud submitted the following contribution: ==== Dear Wieners, In execution of "xdstart" for Al_2 O_3 struct-file contained in exaples, I encountered the message: " PGFIO-F-231 /formatted read /unit=15 /error on data conversion" Any suggestion is highly appreciated. M. Payami ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 5 Aug 2002 11:20:29 +0100 From: Andrew Scott Subject: Re: [WIEN]: PGFIO error ==== Andrew Scott submitted the following contribution: ==== I believe this may be a problem with the compiler. See Dave Pankhurst's contribution to the FAQ on the WIEN2K web-site. Andrew. ________________________________________________ Dr. Andrew Scott, Department of Materials, School of Process, Environmental and Materials Engineering, University of Leeds, Leeds LS2 9JT, U.K. E-mail: a.j.scott@leeds.ac.uk Tel: 44 + (0)113 233 2573 http://www.lemas.co.uk http://www.materials.leeds.ac.uk/lemas ________________________________________________ On Mon, 5 Aug 2002, Payami Mahmoud wrote: > ==== > Payami Mahmoud > submitted the following contribution: > ==== > > Dear Wieners, > > In execution of "xdstart" for Al_2 O_3 struct-file contained in exaples, > I encountered the message: > " PGFIO-F-231 /formatted read /unit=15 /error on data conversion" > > Any suggestion is highly appreciated. > > M. Payami > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 05 Aug 2002 17:30:39 +0430 From: Payami Mahmoud Subject: Re: [WIEN]: PGFIO error ==== Payami Mahmoud submitted the following contribution: ==== Dear Andrew, Thank you very much for your suggestion. I checked the ftp-site mentioned in FAQ and downloaded the patch files. I try to manage fixing this problem. Kind regards, M. Payami Andrew Scott wrote: >==== >Andrew Scott >submitted the following contribution: >==== > >I believe this may be a problem with the compiler. See Dave Pankhurst's >contribution to the FAQ on the WIEN2K web-site. > >Andrew. > > ________________________________________________ > Dr. Andrew Scott, > Department of Materials, > School of Process, Environmental and Materials Engineering, > University of Leeds, > Leeds LS2 9JT, U.K. > > E-mail: a.j.scott@leeds.ac.uk > Tel: 44 + (0)113 233 2573 > > http://www.lemas.co.uk > http://www.materials.leeds.ac.uk/lemas > ________________________________________________ > > >On Mon, 5 Aug 2002, Payami Mahmoud wrote: > >>==== >>Payami Mahmoud >>submitted the following contribution: >>==== >> >>Dear Wieners, >> >>In execution of "xdstart" for Al_2 O_3 struct-file contained in exaples, >>I encountered the message: >> " PGFIO-F-231 /formatted read /unit=15 /error on data conversion" >> >>Any suggestion is highly appreciated. >> >>M. Payami >> >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 06 Aug 2002 08:05:36 +0430 From: Payami Mahmoud Subject: Re: [WIEN]: PGFIO error ==== Payami Mahmoud submitted the following contribution: ==== Dear Andrew, There was a small error in the symbol used for oxygen in the "case.struct". It was similar to a prolate one. The "case.inst" was: Al Ne 2 5 3, -1, 1.0 N 3, -1, 1.0 N 3, 1, 1.0 N 3, 1, 0.0 N Warning: Specified Element not in database! **** End of input **** End of input But after retyping the symbol "O", the information of the oxygen atom was added to this file and the "PGFIO-error" was disappeared. Thank you again! Mahmoud Andrew Scott wrote: >==== >Andrew Scott >submitted the following contribution: >==== > >I believe this may be a problem with the compiler. See Dave Pankhurst's >contribution to the FAQ on the WIEN2K web-site. > >Andrew. > > ________________________________________________ > Dr. Andrew Scott, > Department of Materials, > School of Process, Environmental and Materials Engineering, > University of Leeds, > Leeds LS2 9JT, U.K. > > E-mail: a.j.scott@leeds.ac.uk > Tel: 44 + (0)113 233 2573 > > http://www.lemas.co.uk > http://www.materials.leeds.ac.uk/lemas > ________________________________________________ > > >On Mon, 5 Aug 2002, Payami Mahmoud wrote: > >>==== >>Payami Mahmoud >>submitted the following contribution: >>==== >> >>Dear Wieners, >> >>In execution of "xdstart" for Al_2 O_3 struct-file contained in exaples, >>I encountered the message: >> " PGFIO-F-231 /formatted read /unit=15 /error on data conversion" >> >>Any suggestion is highly appreciated. >> >>M. Payami >> >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 01:05:08 -0700 From: "saeid Jalali" Subject: Re: [WIEN]: Some questions -- answer to 2 ==== "saeid Jalali" submitted the following contribution: ==== > 2) In my slab calculation, the total energy has :WARNING: befor announcing the > value. Can anyone tell me what this means, > > eg :ENE : *WARNING** TOTAL ENERGY IN Ry = -1745.650010 You would try to look for in the mailing-list an e-mail from Stefaan with the subject of Jumps, and the responses to him from Torsten and Pavel. I paste below a related part of them: ">I don't know it that is a hint, but the warning in the :ENE line I had >the other day. Increasing NMATMAX removed it. Don't you have a warning >that rkmax is reduced somewhere in your scf file? No. There are two reasons why there can be printed a **WARNING** in the :ENE line: Rkmax which is reduced, and a bad integration which produces a :WAR line. My :RKM line stays the same everywhere, and I have the **WARNING** only in that iteration where there is also a :WAR present. Obviously this is due to the second reason, bad integration." Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 06 Aug 2002 16:04:30 +0430 From: Payami Mahmoud Subject: [WIEN]: Problem with plot ==== Payami Mahmoud submitted the following contribution: ==== Dear Wieners, Using Wien2k-02, I have never succeeded in "Click & Plot" of the density or DOS and always I receive the message: "Error- File not found or temporary file does not exist anymore". But it is possible to call from a command shell the gnuplot and plot them. Should I configure my W2WEB or something else? How? Suggestions are highly appreciated. Best regards, M. Payami ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 14:35:26 +0200 (MEST) From: buero@luitz.at Subject: Re: [WIEN]: Problem with plot ==== buero@luitz.at submitted the following contribution: ==== On Tue, 6 Aug 2002, Payami Mahmoud wrote: > "Error- File not found or temporary file does not exist anymore". > But it is possible to call from a command shell the gnuplot and plot them. > Should I configure my W2WEB or something else? How? Can your gnuplot version produce PNG graphics? If not, it is clear it cannot find the appropriate file. Running gnuplot from the commandline produces graphics on your X11 device. In gnuplot try help set terminal png If you get an answer like "Sorry, no help for 'set terminal png', you should upgrade your gnuplot. Regards Joachim /---------------------------------------------------------\ ( luitz.at - Interfacing Art, Science and Technology ) )---------------------------------------------------------( ( Büro für Informationstechnologie \ ) und Technisches Büro für Technische Chemie ) ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( ) Wohlmuthgasse 18 0676 31 61254 ) ( A-3003 Gablitz Fax: 022 31 67443 ( \ http://www.luitz.at buero@luitz.at ) \---------------------------------------------------------/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 15:05:53 -0400 (EDT) From: Igor Mazin Subject: Re: [WIEN]:Spam alert ==== Igor Mazin submitted the following contribution: ==== Hi, I never publish my e-mail with my papers, but I do not think the papers are normally accessible by robots. These are mostly primitive and do not serach the pdf files. I do use procmail, but I found it rather annoying to tune to all possible spam patterns. Igor > > ==== > Ravindran Ponniah > submitted the following contribution: > ==== > > On Fri, 2 Aug 2002, Igor Mazin wrote: > > > ==== > > Igor Mazin > > submitted the following contribution: > > ==== > > > > For many years I was careful not to have my e-mail address accessible > > for spammers' harvesting robots. Last month I signed up for the WIEN > > list, having forgotten that thetraffic is being posted on the web. > > Sure enough, as of today my mailbox receives up to 12 spam messages > > which makes my life miserable. I travel a lot, often have bad connection > > to the Internet, and now I cannot get to my mail because ofthe flood spam. > > > > SOMETHING HAS TO BE DONE! I do not know what, I'll think, > > let's think together, but our mails SHOULD NOT APPEAR on the web! > > > > For the moment being, I will really, really appreciate, if Peter > > or Georg would make %s/dave.nrl.navy.mil/dave\.nrl\.navy\.ml, > > or something similar. Then at least I have a chance that this > > spam flood will dry out in few months. Please, please!i > > > > Sorry, sorry for an offtopic, > > Dear Igor, > > I am also having the problem of receiving almost 10 spam > mails per day. Using exim filter I am able to solve the problem > (i.e. morethan 90% of the spam mails are filtered out). If you > are interested to filter out your spam mails, I can send to you the > necessary instructions in a seperate email. > > I feel that one of the possibility of getting the email > address by the spammers from the papers we publish with our email address. > > Best regards > Ravi > > *********************************************************** > Dr.P.Ravindran, Department of Chemistry|Tel: +47 22 85 56 06 > University of Oslo, PO Box 1033 |Fax: +47 22 85 54 41/55 65 > Blindern, N-0315 OSLO, NORWAY | > Email: ravindran.ponniah@kjemi.uio.no | > URL : http://folk.uio.no/~ravi/ | > ************************************************************ > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- ***************************************************************************** Igor Mazin, NRL, code 6391, 4555 Overlook Ave SW, Washington, DC 20375-5320 Phone: (202) 767-6990; Fax: (202) 404-7546; e-mail mazin@dave.nrl.navy.mil Home Page (under construction) http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 18:46:46 -0300 (ARST) From: Fabian Dominguez Subject: [WIEN]: Ndfeb - convergence ==== Fabian Dominguez submitted the following contribution: ==== Dear Dr. Blaha: Trying to run ndfeb, with 68 atoms per unit cell I found that I can't do :DIS lower than 0.0055 or 0.0056 but energies values are like this, this the las cycle done where 3 iterations are done and then It stops :ENE : ********** TOTAL ENERGY IN Ry = -296439.449779 :ENE : ********** TOTAL ENERGY IN Ry = -296439.449790 :ENE : ********** TOTAL ENERGY IN Ry = -296439.449775 Dr Blaha: I use rkmax =5 and 6 point in IBZ, corrisponding 40 points in total BZ. I know this is not the best choice but greater values of these parameters makes lapw1 rather longer or if I try with rkmax =7 u 8 even 6. or more k-points. I comment this in a previous mail before starting calculation and you sugest me to do this , I mean get lower rkmax and get higher the number of k-points. Is is possible that the best convergence degree reached with these parameters is this order... best regards, Fabian ============================***================================= Lic. Fabian Alfredo Dominguez Avenalle. Instituto de Fisica de Liquidos y Sistemas Biologicos (IFLYSIB). Universidad Nacional de La Plata (UNLP). Calle 59 N 789 La Plata CP. 1900 BUENOS AIRES ARGENTINA CC. 565 TE: 0221-4233283 TELEFAX: 0221-4257317 E-MAIL: fabian@iflysib.unlp.edu.ar ============================***================================= ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 10:39:00 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: Some questions -- thankyou ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks saeid Jalali so much for you help, and also to Fred Nastos for answer to my first question! Gratefully yours Cheng Chen Quoting saeid Jalali : > ==== > "saeid Jalali" > submitted the following contribution: > ==== > > > 2) In my slab calculation, the total energy has :WARNING: befor > announcing > the > > value. Can anyone tell me what this means, > > > > eg :ENE : *WARNING** TOTAL ENERGY IN Ry = -1745.650010 > > You would try to look for in the mailing-list an e-mail from Stefaan with > the subject of Jumps, and the responses to him from Torsten and Pavel. > I paste below a related part of them: > > ">I don't know it that is a hint, but the warning in the :ENE line I had > >the other day. Increasing NMATMAX removed it. Don't you have a warning > >that rkmax is reduced somewhere in your scf file? > No. There are two reasons why there can be printed a **WARNING** in the > :ENE > line: Rkmax which is reduced, and a bad integration which produces a :WAR > line. My :RKM line stays the same everywhere, and I have the **WARNING** > only > in that iteration where there is also a :WAR present. Obviously this is due > to > the second reason, bad integration." > > Your, > S. Jalali. > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 21:28:41 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: Electron Density ==== Bing Zhou submitted the following contribution: ==== Dear All: After the running the SCF cycles using parallization mode, I tried to draw the electronic density map. However, I found that there is no case.in2 file in the directory although there are files such as: tugtupite.in2_ls, tugtupite.in2_st, tugtupite.in2_sy, tugtupite.in2c Then I found nothing in the file case.vector, i.e., it is empty, but the following files are not empty: tugtupite.vector tugtupite.vector_2 tugtupite.vector_4 tugtupite.vector_6 tugtupite.vector_1 tugtupite.vector_3 tugtupite.vector_5 tugtupite.vector_7 So my question is: how can I get my electronic density map for my crystal? Thanks in advance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 6 Aug 2002 23:48:17 -0400 From: Fred Nastos Subject: Re: [WIEN]: Electron Density ==== Fred Nastos submitted the following contribution: ==== > However, I found that there is no case.in2 file in the directory > although there are files such as: > tugtupite.in2c Having a .in2c ending usually means that the crystal class does not have inversion symmetry. The 'c' stands for complex and "reminds" you that the caclulation is using complex wavefunctions. > Then I found nothing in the file case.vector, i.e., it is empty, but the > following files are not empty: > tugtupite.vector From what I gather from the furts part of your post, tugtupite.vector is your case.vector file. I think if you actually have a file called 'case.vector' there is something wrong... unless you purposely named a calculation 'case'. The term case is used as a generic label throughout the manual. > So my question is: how can I get my electronic density map for my crystal? Use w2web, and page 22-24 of the manual. The interface knows to use the correct files (tugtupite.in2c and tugtupite.vector in your case). At least it does for me. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 07 Aug 2002 08:27:32 +0200 From: Torsten Andersen Subject: Re: [WIEN]:Spam alert ==== Torsten Andersen submitted the following contribution: ==== Hi, I find this discussion rather bizarre, as all mailing lists and most e-mails are transferred through several servers/routers/switches on their way from sender to recipient. Each of these places, a sniffer program can take out e-mail addresses, and I have not noticed any increase in junk mail because of the wien mailing list. Furthermore, I have set up a filter that takes about 9 out of 10 junk mails, since they usually fit a very simple pattern. Most of them are not adressed to me, so the first rule of the filter is that everything not addressed to me goes directly to trash. Next rules are exceptions from that... it also has the advantage that all wien mailing list postings come to a separate inbox. I think using e-mail has it's risks of spamming, mostly due to people that could be taken out via US legislation, which they don't want to do... so you being in the US should contact your congressman. Unsolicited e-mail is already forbidden in most European countries, but we can't enforce it since most of that comes from the US where it is "free speech" although without any content. Don't blame the mailing list maintainers! Sincerely, Torsten Andersen. Igor Mazin wrote: >==== >Igor Mazin >submitted the following contribution: >==== > >Hi, > >I never publish my e-mail with my papers, but I do not >think the papers are normally accessible by robots. These are >mostly primitive and do not serach the pdf files. > >I do use procmail, but I found it rather annoying >to tune to all possible spam patterns. > >Igor > >>==== >>Ravindran Ponniah >>submitted the following contribution: >>==== >> >>On Fri, 2 Aug 2002, Igor Mazin wrote: >> >>>==== >>>Igor Mazin >>>submitted the following contribution: >>>==== >>> >>>For many years I was careful not to have my e-mail address accessible >>>for spammers' harvesting robots. Last month I signed up for the WIEN >>>list, having forgotten that thetraffic is being posted on the web. >>>Sure enough, as of today my mailbox receives up to 12 spam messages >>>which makes my life miserable. I travel a lot, often have bad connection >>>to the Internet, and now I cannot get to my mail because ofthe flood spam. >>> >>>SOMETHING HAS TO BE DONE! I do not know what, I'll think, >>>let's think together, but our mails SHOULD NOT APPEAR on the web! >>> >>>For the moment being, I will really, really appreciate, if Peter >>>or Georg would make %s/dave.nrl.navy.mil/dave\.nrl\.navy\.ml, >>>or something similar. Then at least I have a chance that this >>>spam flood will dry out in few months. Please, please!i >>> >>>Sorry, sorry for an offtopic, >>> >>Dear Igor, >> >> I am also having the problem of receiving almost 10 spam >>mails per day. Using exim filter I am able to solve the problem >>(i.e. morethan 90% of the spam mails are filtered out). If you >>are interested to filter out your spam mails, I can send to you the >>necessary instructions in a seperate email. >> >> I feel that one of the possibility of getting the email >>address by the spammers from the papers we publish with our email address. >> >>Best regards >>Ravi >> >>*********************************************************** >>Dr.P.Ravindran, Department of Chemistry|Tel: +47 22 85 56 06 >>University of Oslo, PO Box 1033 |Fax: +47 22 85 54 41/55 65 >>Blindern, N-0315 OSLO, NORWAY | >>Email: ravindran.ponniah@kjemi.uio.no | >>URL : http://folk.uio.no/~ravi/ | >>************************************************************ >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 07 Aug 2002 15:46:08 +0430 From: Payami Mahmoud Subject: Re: [WIEN]: Problem with plot ==== Payami Mahmoud submitted the following contribution: ==== Dear Joachim, Thank you very much for your suggestion. I checked if my "gnuplot" supports "png" and the answer is yes. I can set the terminal to png when I call the gnuplot in a command shell. The "libpng" and "zlib" had been installed. It should be mentioned that I had no "click & plot" problems when using the previous version, W2k_01. The steps that I follow are: x lapw2 -qtl x tetra DOSplot The outcome is: We are in Dosplotmode column 1 selected Plot from atom: total DOS (file case.dos1ev) ....and no plot! When I click "Download hardcopy in PS format", then the mentioned error appears. Should I check further for other requirements? With best regards, Mahmoud Payami buero@luitz.at wrote: >==== >buero@luitz.at >submitted the following contribution: >==== > >On Tue, 6 Aug 2002, Payami Mahmoud wrote: > >>"Error- File not found or temporary file does not exist anymore". >>But it is possible to call from a command shell the gnuplot and plot them. >>Should I configure my W2WEB or something else? How? >> > > >Can your gnuplot version produce PNG graphics? If not, it is clear it >cannot find the appropriate file. Running gnuplot from the commandline >produces graphics on your X11 device. > >In gnuplot try >help set terminal png > >If you get an answer like "Sorry, no help for 'set terminal png', you >should upgrade your gnuplot. > >Regards > Joachim > > /---------------------------------------------------------\ >( luitz.at - Interfacing Art, Science and Technology ) > )---------------------------------------------------------( >( Büro für Informationstechnologie \ > ) und Technisches Büro für Technische Chemie ) >( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( > ) Wohlmuthgasse 18 0676 31 61254 ) >( A-3003 Gablitz Fax: 022 31 67443 ( > \ http://www.luitz.at buero@luitz.at ) > \---------------------------------------------------------/ > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 20:38:55 +0800 From: Wenhui Xie Subject: [WIEN]: The problem in band character plot ==== Wenhui Xie submitted the following contribution: ==== Dear Sir, I download the new version of WIEN2K, and everything is good. However, I do not plot the band and charater band like before. I found that the figures of band are color figure, which is not similar with the fig3.15 and 3.16 shown in User's Guide. Also, I do not plot the Ti t2g-like character bands. Unfortunely, I have deleted the old version, now I do not know what's wrong happened in TiC case. Thanks for any advise. Best Regards. Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 20:48:40 +0800 From: Wenhui Xie Subject: [WIEN]: How to get the hyperfine field ==== Wenhui Xie submitted the following contribution: ==== Dear Sir, From the web site of WIEN2K, I know that the properties of electric field gradients, isomer shifts, hyperfine fields can be obtined from WIEN2K package. However, I do not know how to do. Please tell me more detals. Thanks very much! yours sincerely Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 08:09:58 -0700 (PDT) From: Igor Mazin Subject: [none] ==== Igor Mazin submitted the following contribution: ==== __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 08:53:33 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]:Spam alert ==== Igor Mazin submitted the following contribution: ==== Hi, I also find this discussion quite bizzare, and particularly your reaction. If you are inetersted in discussion of American and European political systems, I suggest the proper avenue is via private e-mail. To wrap it up, let me make a few points. 1) You both over- and underestimate the level of sophistication of a typical spammer. They do not use sniffers and similar devices reqiring hacking. They use relatively primitive robots (crawlers) which simply harvest e-mails from publicly availabel html pages. While most, but not all spammers reside in the US (and so does the overwhelming majority of legitimate Internet businesses) they usually do not use traceable American providers, since many states have laws agains unsolicited e-mails, some at the opt-out and some at the opt-in level. The main anti-spam organisation in Europe is BTW EuroCAUCE, a European branch of CAUCE, an antispam organization originated in the US, more at http://www.euro.cauce.org/en/index.html and http://www.cauce.org/index.phtml. Unfortunately the absolute majority of spam messages is coming with faked headers (this is why you think they are send from American providers) and are relayed via proxies in China, Russia and other counries. This makes it extremely difficult to fight scam by legal means, as you suggest. 2)So far with the spam basic. Now, I do NOT blame the list maintainers. There is nothing they can do. I asked for a personal favor of having my address cleaned out from the website. However, I do believe that a newsgroup/discussion-club format is better, for (i) you can follow messages by thread and (ii) you can always give your address in a form understandable by humans, but not robots. I know Peter is of different opinion, and he has his own reasons. 3) You use Netscape 6.1 mailer agent, which does indeed have a very nice filtering engine. For reasons that are not interesting for the readeres, I use elm, with the only option of procmailing. 4) I just set up two test accounts, one subscribed to the list, and one not. I will post (only once, don't be afraid!) a message regarding the junk traffic in both after a week or two. Igor ==== Torsten Andersen submitted the following contribution: ==== Hi, I find this discussion rather bizarre, as all mailing lists and most e-mails are transferred through several servers/routers/switches on their way from sender to recipient. Each of these places, a sniffer program can take out e-mail addresses, and I have not noticed any increase in junk mail because of the wien mailing list. Furthermore, I have set up a filter that takes about 9 out of 10 junk mails, since they usually fit a very simple pattern. Most of them are not adressed to me, so the first rule of the filter is that everything not addressed to me goes directly to trash. Next rules are exceptions from that... it also has the advantage that all wien mailing list postings come to a separate inbox. I think using e-mail has it's risks of spamming, mostly due to people that could be taken out via US legislation, which they don't want to do... so you being in the US should contact your congressman. Unsolicited e-mail is already forbidden in most European countries, but we can't enforce it since most of that comes from the US where it is "free speech" although without any content. Don't blame the mailing list maintainers! Sincerely, Torsten Andersen. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 13:20:44 -0500 (CDT) From: Bing Zhou Subject: Re: [WIEN]: Electron Density ==== Bing Zhou submitted the following contribution: ==== Dear Fred: Thank you for your help! 1. During the process of init_lapw, I already set "center version" for my crystal tugtupite, so I don't know why the tugtupite.in2 file was still not created. 2. Yes, my case.vector is tugtupite.vector, and there also exists the file with name "tugtupite.vector", however, it is an empty file! i.e., - -rw------- 1 umbingz student 0 Jun 22 02:42 tugtupite.vector 3. I did use w2web for the electron density calculation and plotting, I met the following problems: (1) no file of tugtupite.in2; (2) after I copied tugtupite.in2_st as my tugtupite.in2 file and run "x lapw2", the following information was shown: ****** FORTRAN RUN-TIME SYSTEM ****** End-of-file: -1 Location: the READ statement at line 40 of "fermi.f" Unit: 30 File: tugtupite.energy Abort 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w (3) Then I run the following steps, after "x -lapw5", the following information was shown on the webpage: 39.0u 0.0s 0:39 98% 0+0k 0+0io 0pf+0w (5) Finally I run "rhoplot", it keeps running and nothing came out on the webpage, I am still waiting for any message from the program. So I don't know why lapw2 is aborted, and is my EMIN=-1.0 in tugtupite.in2 too high for my tugtupite? I will try lower EMIN to see what happens. Thank you again! Have a nice day! On Tue, 6 Aug 2002, Fred Nastos wrote: submitted the following contribution: > > However, I found that there is no case.in2 file in the directory > > although there are files such as: > > tugtupite.in2c > > Having a .in2c ending usually means that the crystal class does > not have inversion symmetry. The 'c' stands for complex and "reminds" > you that the caclulation is using complex wavefunctions. > > > Then I found nothing in the file case.vector, i.e., it is empty, but the > > following files are not empty: > > tugtupite.vector > > From what I gather from the furts part of your post, tugtupite.vector > is your case.vector file. I think if you actually have a file called > 'case.vector' there is something wrong... unless you purposely named > a calculation 'case'. The term case is used as a generic label throughout the > manual. > > > So my question is: how can I get my electronic density map for my crystal? > > Use w2web, and page 22-24 of the manual. The interface knows to use the > correct files (tugtupite.in2c and tugtupite.vector in your case). At least it > does for me. > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 15:57:59 -0400 From: Jeff Spirko Subject: [WIEN]: Bug in restore_lapw ==== Jeff Spirko submitted the following contribution: ==== restore_lapw will sometimes fail saying, "arg list too long". It is related to a limitation in tcsh. The line: set count = `ls $savedir/$savefile*|wc -l` will fail if savedir is long and there are many files in the job. A better way of counting the files might be: set count = `echo $savedir/$savefile* | wc -w` This uses the shell builtin command echo (and wc -w), so it doesn't encounter the same limitations. - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 16:13:42 -0400 From: Fred Nastos Subject: Re: [WIEN]: Electron Density ==== Fred Nastos submitted the following contribution: ==== > 1. During the process of init_lapw, I already set "center version" for my > crystal tugtupite, so I don't know why the tugtupite.in2 file was > still not created. I'm not sure what you mean by 'I already set "center version" for my crystal'. I believe the WIEN2k package will determine if your crystal has inversion symmetry or not. Could you type the following at the command prompt: grep INVERSION tugtupite.output.s A typical output from this is: PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION or PGBSYM: SPACE GROUP CONTAINS INVERSION Could you indicate more precisely, where/how you 'set "center version"'? > 2. Yes, my case.vector is tugtupite.vector, and there also exists the file > with name "tugtupite.vector", however, it is an empty file! i.e., > > -rw------- 1 umbingz student 0 Jun 22 02:42 tugtupite.vector I'm not sure why that would be empty, unless it was accidentally written over. I'm not an expert (and barely a beginner) on the internals of lapw1/lapw2, but it could be that since lapw2 was abnormally aborted (as you say below) your .vector file was left in an empty state. > 3. I did use w2web for the electron density calculation and plotting, I > met the following problems: > (1) no file of tugtupite.in2; > (2) after I copied tugtupite.in2_st as my tugtupite.in2 file and run > "x lapw2" I don't think that it is a good idea to create, by hand, files that WIEN2k provides just so that you can continue the calculation. There is an old saying from mine workers "figure out what killed the canary before you continue mining." > the following information was shown: > > ****** FORTRAN RUN-TIME SYSTEM ****** > End-of-file: -1 Location: the READ statement at line 40 of "fermi.f" > Unit: 30 > File: tugtupite.energy > Abort > 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > > (3) Then I run the following steps, after "x -lapw5", the following > information was shown on the webpage: > > 39.0u 0.0s 0:39 98% 0+0k 0+0io 0pf+0w Which just means the program exectued, and no abnormal exit statement was picked up by the w2web perl script. > (5) Finally I run "rhoplot", it keeps running and nothing came out on the > webpage, I am still waiting for any message from the program. You will probably not get anything, since lapw2 aborted. > So I don't know why lapw2 is aborted, and is my EMIN=-1.0 in > tugtupite.in2 too high for my tugtupite? That just depends on what range of bands you want to include in the plots. The density is, of course, Tr(rho), and Emin just allows you to truncate the the tracing sum. > I will try lower EMIN to see what happens. I suggest, that instead, you find out what "killed the canary". Fred > Thank you again! > > > Have a nice day! > > On Tue, 6 Aug 2002, Fred Nastos wrote: > > submitted the following contribution: > > > However, I found that there is no case.in2 file in the directory > > > although there are files such as: > > > tugtupite.in2c > > > > Having a .in2c ending usually means that the crystal class does > > not have inversion symmetry. The 'c' stands for complex and "reminds" > > you that the caclulation is using complex wavefunctions. > > > > > Then I found nothing in the file case.vector, i.e., it is empty, but > > > the following files are not empty: > > > tugtupite.vector > > > > From what I gather from the furts part of your post, tugtupite.vector > > is your case.vector file. I think if you actually have a file called > > 'case.vector' there is something wrong... unless you purposely named > > a calculation 'case'. The term case is used as a generic label throughout > > the manual. > > > > > So my question is: how can I get my electronic density map for my > > > crystal? > > > > Use w2web, and page 22-24 of the manual. The interface knows to use the > > correct files (tugtupite.in2c and tugtupite.vector in your case). At > > least it does for me. > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > Bing Zhou > Dept. of Geological Sc. > The Univ. of Manitoba > Canada R3T 2N2 > Tel: (204)474-8395 > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 21:25:49 -0500 (CDT) From: Bing Zhou Subject: Re: [WIEN]: Electron Density ==== Bing Zhou submitted the following contribution: ==== Dear Fred: Thanks! I write my answer after your email, could you pleae take a look? thank you for your help and patience. > ==== > Fred Nastos > submitted the following contribution: > ==== > > > 1. During the process of init_lapw, I already set "center version" for my > > crystal tugtupite, so I don't know why the tugtupite.in2 file was > > still not created. > > I'm not sure what you mean by 'I already set "center version" for my > crystal'. I believe the WIEN2k package will determine if your crystal > has inversion symmetry or not. During init_lapw0, after "x kgen", there occurred the following information on the screen: > inputfiles prepared (21:07:33) > inputfiles for lapw1c/2c prepared, no inversion present (21:07:34) > kgen (21:07:34) 4 symmetry operations without inversion Do you want to add inversion: No=0, Yes=1 (0/1) Then I chose 1 for "yes", i.e., add the inversion. > > Could you type the following at the command prompt: > > grep INVERSION tugtupite.output.s > > A typical output from this is: > > PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION > > or > > PGBSYM: SPACE GROUP CONTAINS INVERSION > > Could you indicate more precisely, where/how you 'set "center version"'? As mentioned above, I chose 1 for adding inversion. After the command "grep INVERSION tugtupite.output.s", I got the following informaiton: polaris:10>grep INVERSION tugtupite.output.s grep: can't open tugtupite.output.s so what does it mean? > > > 2. Yes, my case.vector is tugtupite.vector, and there also exists the file > > with name "tugtupite.vector", however, it is an empty file! i.e., > > > > -rw------- 1 umbingz student 0 Jun 22 02:42 tugtupite.vector > > I'm not sure why that would be empty, unless it was accidentally written > over. I'm not an expert (and barely a beginner) on the internals of > lapw1/lapw2, but it could be that since lapw2 was abnormally aborted > (as you say below) your .vector file was left in an empty state. I plan to run one more SCF to see if I can get a tugtupite.vector file. > > > 3. I did use w2web for the electron density calculation and plotting, I > > met the following problems: > > (1) no file of tugtupite.in2; > > (2) after I copied tugtupite.in2_st as my tugtupite.in2 file and run > > "x lapw2" > > I don't think that it is a good idea to create, by hand, files that WIEN2k > provides just so that you can continue the calculation. There is an old > saying from mine workers "figure out what killed the canary before you > continue mining." > > > the following information was shown: > > > > ****** FORTRAN RUN-TIME SYSTEM ****** > > End-of-file: -1 Location: the READ statement at line 40 of "fermi.f" > > Unit: 30 > > File: tugtupite.energy > > Abort > > 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > > > > (3) Then I run the following steps, after "x -lapw5", the following > > information was shown on the webpage: > > > > 39.0u 0.0s 0:39 98% 0+0k 0+0io 0pf+0w > > Which just means the program exectued, and no abnormal exit > statement was picked up by the w2web perl script. > > > (5) Finally I run "rhoplot", it keeps running and nothing came out on the > > webpage, I am still waiting for any message from the program. > > You will probably not get anything, since lapw2 aborted. > > > So I don't know why lapw2 is aborted, and is my EMIN=-1.0 in > > tugtupite.in2 too high for my tugtupite? > > That just depends on what range of bands you want to include in > the plots. The density is, of course, Tr(rho), and Emin just allows you > to truncate the the tracing sum. > > > I will try lower EMIN to see what happens. > > I suggest, that instead, you find out what "killed the canary". Thank you for your help, I try my best to the reason to kill the canary. I hope you can give me more help. Thanks! > > Fred > > > Thank you again! > > > > > > Have a nice day! > > > > On Tue, 6 Aug 2002, Fred Nastos wrote: > > > > submitted the following contribution: > > > > However, I found that there is no case.in2 file in the directory > > > > although there are files such as: > > > > tugtupite.in2c > > > > > > Having a .in2c ending usually means that the crystal class does > > > not have inversion symmetry. The 'c' stands for complex and "reminds" > > > you that the caclulation is using complex wavefunctions. > > > > > > > Then I found nothing in the file case.vector, i.e., it is empty, but > > > > the following files are not empty: > > > > tugtupite.vector > > > > > > From what I gather from the furts part of your post, tugtupite.vector > > > is your case.vector file. I think if you actually have a file called > > > 'case.vector' there is something wrong... unless you purposely named > > > a calculation 'case'. The term case is used as a generic label throughout > > > the manual. > > > > > > > So my question is: how can I get my electronic density map for my > > > > crystal? > > > > > > Use w2web, and page 22-24 of the manual. The interface knows to use the > > > correct files (tugtupite.in2c and tugtupite.vector in your case). At > > > least it does for me. > > > ==== > > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > > To (un)subscribe send mail to > > > majordomo@zeus.theochem.tuwien.ac.at > > > ==== > > > > Bing Zhou > > Dept. of Geological Sc. > > The Univ. of Manitoba > > Canada R3T 2N2 > > Tel: (204)474-8395 > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 8 Aug 2002 00:18:22 -0400 From: Fred Nastos Subject: Re: [WIEN]: Electron Density ==== Fred Nastos submitted the following contribution: ==== > Do you want to add inversion: No=0, Yes=1 (0/1) > > Then I chose 1 for "yes", i.e., add the inversion. O.K. You have told the WIEN2k package that you want it to use the inversion of the k-space. Explanation: Your crystal has certain symmetry relations (4 of them). These relations transform the crystal strutcure and electron density to itself. I won't write out the details here, but essentially there is a matrix R[i, j] for each for each symmetry operation that takes r[ i ] to some new r'[ i ], by r' [ i ] = R[ i, j ] * r[ j ]. These operations, applied to lattice coordinates, leave the crystal unchanged (though there are small details not worth going into now). Now, the cool thing is, that in k-space the energy e_n(k) of the block state |nk> satisfies the same symmetry properties, in the sense that e_n(k') = e_n(k) where k' is R[i, j]*k[j] (i.e. the transformed k-vector). The wavefunctions also have nice symmetry relations = which help reduce computation time. Here r'' = transpose(R[ i, j ])*r[ j ]. Unless you are interested in spin-orbit effects and magnetic fields, there is an additional bonus! In k-space you also have inversion symmetry which means that e_n(-k) = e_n(k). This is just a consequence of the single-particle Schroedinger equation. End of sloppy explanation. Now, the reason I went through that is, when kgen asks you if you want to add inversion symmetry it is only asking if you want to use inversion in the BZ. Another way it could ask you (which would probably be suitable for all low-end users like me) is: "Are going to do a spin-orbit and spin-polarized calculation?" If your answer is no, then you probably want to add inversion symmetry. This is in the manual though. > > Could you type the following at the command prompt: > > > > grep INVERSION tugtupite.output.s > > After the command "grep INVERSION tugtupite.output.s", I got the following > informaiton: > > polaris:10>grep INVERSION tugtupite.output.s > grep: can't open tugtupite.output.s > so what does it mean? It means I made a typo. Try this instead: grep INVERSION tugtupite.outputs In any case, you sent me your struct file and the answer is: PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION Which means that your crystal does not have inversion symmetry. > I plan to run one more SCF to see if I can get a tugtupite.vector file. Yes. Run the scf. Include inversion symmetry in the BZ. Do the calculation only for a few kpts and make sure you are producing a tugtupite.vector file. Fred ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 23:00:24 -0700 (PDT) From: hamid salehi Subject: [WIEN]: XSPES ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPEs and Not plot XSpes.what is it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 08 Aug 2002 08:06:55 +0200 From: Torsten Andersen Subject: [WIEN]: Spam alert and protection against other abuse of the mailing list ==== Torsten Andersen submitted the following contribution: ==== Dear Igor, I am not afraid, just puzzled about the two facts (i) that I post many messages on the mailing list, yet do not get any more spam than I have always gotten, and (ii) we don't get spam on the mailing list itself. Regarding politics, I have tried the "opt-out" on my hotmail account once. It floods the inbox with spam... plus I get a lot of spam that claim to be "opt-in" although I never "opt-in"... most of the spam I get actually comes from U.S. adresses. Of course, since the code is only obtainable by license and password, they could put the mailing list postings on the web behind that password, too. Actually, maybe for privacy among licensed users of the Wien code they should, since research topics are discussed and revealed before they are concluded. So, although I disagree with your spam conclusion, I agree that our postings should be protected from the general public on the web. Best regards, Torsten. Igor Mazin wrote: >==== >Igor Mazin >submitted the following contribution: >==== > >Hi, > >I also find this discussion quite bizzare, and >particularly your reaction. If you are inetersted in >discussion of American and European political systems, >I suggest the proper avenue is via private e-mail. > >To wrap it up, let me make a few points. > >1) You both over- and underestimate the level of >sophistication of a typical spammer. They do not use >sniffers and similar devices reqiring hacking. They >use relatively primitive robots (crawlers) which >simply harvest e-mails from publicly availabel html >pages. While most, but not all spammers reside in the >US (and so does the overwhelming majority of >legitimate Internet businesses) they usually do not >use traceable American providers, since many states >have laws agains unsolicited e-mails, some at the >opt-out and some at the opt-in level. The main >anti-spam organisation in Europe is BTW EuroCAUCE, a >European branch of CAUCE, an antispam organization >originated in the US, more at >http://www.euro.cauce.org/en/index.html and >http://www.cauce.org/index.phtml. Unfortunately the >absolute majority of spam messages is coming with >faked headers (this is why you think they are send >from American providers) and are relayed via proxies >in China, Russia and other counries. This makes it >extremely difficult to fight scam by legal means, as >you suggest. > >2)So far with the spam basic. Now, I do NOT blame the >list maintainers. There is nothing they can do. I >asked for a personal favor of having my address >cleaned out from the website. However, I do believe >that a newsgroup/discussion-club format is better, for >(i) you can follow messages by thread and (ii) you can >always give your address in a form understandable by >humans, but not robots. I know Peter is of different >opinion, and he has his own reasons. > >3) You use Netscape 6.1 mailer agent, which does >indeed have a very nice filtering engine. For reasons >that are not interesting for the readeres, I use elm, >with the only option of procmailing. > >4) I just set up two test accounts, one subscribed to >the list, and one not. I will post (only once, don't >be afraid!) a message regarding the junk traffic in >both after a week or two. > >Igor > >==== >Torsten Andersen >submitted the following contribution: >==== > >Hi, > >I find this discussion rather bizarre, as all mailing >lists and most e-mails are transferred through several >servers/routers/switches on their way from sender to >recipient. Each of these places, a sniffer program can >take out e-mail addresses, and I have not noticed any >increase in junk mail because of the wien mailing >list. Furthermore, I have set up a filter that takes >about 9 out of 10 junk mails, since they usually fit a >very simple pattern. Most of them are not adressed to >me, so the first rule of the filter is that everything >not addressed to me goes directly to trash. Next rules >are exceptions from that... it also has the advantage >that all wien mailing list postings come to a separate >inbox. > >I think using e-mail has it's risks of spamming, >mostly due to people that could be taken out via US >legislation, which they don't want to do... so you >being in the US should contact your congressman. >Unsolicited e-mail is already forbidden in most >European countries, but we can't enforce it since most >of that comes from the US where it is "free speech" >although without any content. Don't blame the mailing >list maintainers! > >Sincerely, >Torsten Andersen. > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Health - Feel better, live better >http://health.yahoo.com >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 7 Aug 2002 23:30:04 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2-up ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 08 Aug 2002 11:21:28 +0200 From: Thomas Claesson Subject: [WIEN]: NiO bandstructure ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am doing bandstructure calculations on AFM NiO. This is the struct file I am using: NiO R LATTICE,NONEQUIV. ATOMS: 3 MODE OF CALC=RELA 5.605236 5.605236 27.459934 90.000000 90.000000 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 4 Ni1 NPT= 781 R0=0.00050000 RMT= 2.0000 Z: 28.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.50000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 4 Ni2 NPT= 781 R0=0.00050000 RMT= 2.0000 Z: 28.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.25000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 4 - -3: X=0.75000000 Y=0.75000000 Z=0.75000000 O NPT= 781 R0=0.00050000 RMT= 1.7500 Z: 8.0 My problem is that when I calculate the band strucutre along the GAMMA-X direction I get something which not at all looks like results from calculations done by others, see for instance S. Massidda et al., Phys. Rev. B 55, 13494 (1997). At the GAMMA-point and close to it it looks fairly OK, but then it looks strange. I have followed the instructions in section 4.5.4 of the userguide for treatment of AFM compounds and tried to run with both runafm_lapw and runsp_lapw, but the result is the same. Does anyone know what the reason could be? Perhaps I am doing some silly mistake. Thanks for your replies! Best regards, Thomas Claesson. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 8 Aug 2002 13:55:55 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: NiO bandstructure ==== Igor Mazin submitted the following contribution: ==== > ==== > Thomas Claesson > submitted the following contribution: > ==== > > Dear Wien users and developers! > > I am doing bandstructure calculations on AFM NiO. > This is the struct > file I am using: > > NiO > R LATTICE,NONEQUIV. ATOMS: 3 > MODE OF CALC=RELA > 5.605236 5.605236 27.459934 90.000000 90.000000 > 90.000000 There is something fishy here. AFM NiO is rhombohedral, not tetragonal. The usual choice og the unit cell is 1 .5 .5 .5 1 .5 .5 .5 1 in units of the cubic lattice parameter. Experimental structure has a small rhombohedral distortion, around %. Check a paper by Isaak, Cohen and Singh on FeO in PRB around 1990. They have a nice description of the crystallography of FeO (NiO is the same, but not CoO). __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 10 Aug 2002 00:23:40 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2- ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion or PGFIO-F-217/list-directed read /unit=30/attempt to read past end of file: filename=home.energyup formatted,sequential access record=285) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #30 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #31 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, August 16 2002 Volume 2002 : Number 031 ---------------------------------------------------------------------- Date: Mon, 12 Aug 2002 07:02:01 -0700 (PDT) From: yanming Ma Subject: [WIEN]: About AIM ==== yanming Ma submitted the following contribution: ==== - --0-388034923-1029160921=:52419 Content-Type: text/plain; charset=us-ascii Dear wien2k users, I am interested in the function of AIM (atoms in molecules) in WIEN2k. Can someone provide me the useful references for the basic Bader's theory of AIM. I will appreciate your helps. Yanming - --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs - --0-388034923-1029160921=:52419 Content-Type: text/html; charset=us-ascii

Dear wien2k users,

I am interested in the function of AIM (atoms in molecules) in WIEN2k.

Can someone provide me the useful references for the basic Bader's theory of  AIM.

I will appreciate your helps.

Yanming

 


Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs - --0-388034923-1029160921=:52419-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 15:53:19 +0100 (BST) From: Dave Pankhurst Subject: [WIEN]: bug in lapwdm Makefile ==== Dave Pankhurst submitted the following contribution: ==== Dear wien users, There is a bug in the SRC_lapwdm/Makefile which causes lapwdm to fail to compile. On line 134 changing the leading 8 spaces to a tab corrects this. best regards, Dave Pankhurst +---------------------------------+------------------------------------+ | Dr David Pankhurst, | Tel : +44 1865 283325/283326 | | Department of Materials, | Fax : +44 1865 273789 | | University of Oxford, | | | Parks Road, Oxford OX1 3PH, UK | david.pankhurst@materials.ox.ac.uk | +---------------------------------+------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 23:01:49 +0800 From: Wenhui Xie Subject: [WIEN]: help, Fe3O4.struct ==== Wenhui Xie submitted the following contribution: ==== Dear WIEN Users, I want to calculate Fe3O4, which have a spinel crystal structure. But I always do not generate the right structure file. Who can help me, or tell me the struct file of Fe3O4. Thank you very much. Looking forwards in here. Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 11:10:42 -0400 From: "Jorge O. Sofo" Subject: RE: [WIEN]: About AIM ==== "Jorge O. Sofo" submitted the following contribution: ==== You can find more information in R. Bader's page: http://www.chemistry.mcmaster.ca/faculty/bader/aim/ Regards, Jorge - -----Original Message----- From: owner-wien@zeus.theochem.tuwien.ac.at [mailto:owner-wien@zeus.theochem.tuwien.ac.at] On Behalf Of yanming Ma Sent: Monday, August 12, 2002 10:02 AM To: wien@zeus.theochem.tuwien.ac.at Subject: [WIEN]: About AIM Dear wien2k users, I am interested in the function of AIM (atoms in molecules) in WIEN2k. Can someone provide me the useful references for the basic Bader's theory of AIM. I will appreciate your helps. Yanming Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 17:48:49 +0200 From: Torsten Andersen Subject: Re: [WIEN]: About AIM ==== Torsten Andersen submitted the following contribution: ==== Dear Ms. Ma, you can follow the link below: http://www.chemistry.mcmaster.ca/faculty/bader/aim/ which is also proviuded ion the users guide. Best regards, Torsten Andersen. yanming Ma wrote: > Dear wien2k users, > > I am interested in the function of AIM (atoms in molecules) in WIEN2k. > > Can someone provide me the useful references for the basic Bader's > theory of AIM. > > I will appreciate your helps. > > Yanming > > > > > ------------------------------------------------------------------------ > Do You Yahoo!? > HotJobs, a Yahoo! service > - > Search Thousands of New Jobs - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 17:50:59 +0200 From: "Dr. Alexander Hofmann" Subject: Re: [WIEN]: About AIM ==== "Dr. Alexander Hofmann" submitted the following contribution: ==== - --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Yanming, The basic articles are attached below. For some reasons I made in my molecular life tests with Baders program (PROAIMV) on the water molecule with different basis sets. I did the same with the Mulliken analysis (very common in molecular chemistry) and the Gaussian98 NPA (=Natural Population Analysis). And it turned out that the NPA is the most stable analysis with respect to varying basis sets. We can learn at least a couple of things from this (comments welcome): - - Even the conceptually best analysis (Bader) gives widely spreaded _absolute_ numbers. - - charge difference are quite reliable - - NPA is best for water, but it seems this due to some error cancellation. My take home message is: Carefully with absolute charges, trends are surely ok. with best regards Alex PS: attached the mentioned table (TeX-Format) @article{bader81, TITLE={Quantum Theory of Atoms in Molecules - Dalton Revisited}, AUTHOR={R. F. W. Bader and T. T. Nguyen-Dang}, JOURNAL={Adv. Quantum Chem.}, YEAR={1981}, VOLUME={14}, PAGES={63} } @book{bader90, TITLE={Atoms in Molecules - A Quantum Theory}, AUTHOR={R. F. W. Bader}, PUBLISHER={Oxford University Press}, YEAR={1990}, address={Oxford}, } @article{bader91, TITLE={A Quantum Theory of Molecular Structure and Its Applications}, AUTHOR={R. F. W. Bader}, JOURNAL={Chem. Rev.}, YEAR={1991}, VOLUME={91}, PAGES={893} } - -- Dr. Alexander Hofmann Humboldt-Universitaet zu Berlin Institut fuer Chemie Arbeitsgruppe Quantenchemie Brook-Taylor-Strasse 2 12489 Berlin ah@chemie.hu-berlin.de Tel.: +49-30-2093-7138 Fax.: +49-30-2093-7136 http://www.chemie.hu-berlin.de/ag_sauer/index.html PGP-Key: wwwkeys.de.pgp.net ID: D9D62D35 - --UlVJffcvxoiEqYs2 Content-Type: application/x-tex Content-Disposition: attachment; filename="topologische.Ladungsdichteanalyse.tex" \begin{center}\begin{tabular}{lqqq} \hline &\multicolumn{1}{c}{Mulliken}&\multicolumn{1}{c}{NPA}&\multicolumn{1}{c}{PROAIMV}\\ \hline H$_2$O (lanl2dz) & -0.792 & -0.975 & -1.048 \\ % O % & 0.396 & 0.488 & 0.524 \\ % H H$_2$O (6-31G) & -0.811 & -0.966 & -1.043 \\ % O % & 0.406 & 0.483 & 0.521 \\ % H H$_2$O (6-31G*) & -0.869 & -0.955 & -1.181 \\ % O % & 0.434 & 0.477 & 0.590 \\ % H H$_2$O (6-31G**) & -0.673 & -0.974 & -1.242 \\ % O % & 0.336 & 0.487 & 0.621 \\ % H H$_2$O (6-31$^{++}$G**) & -0.717 & -0.983 & -1.259 \\ % O % & 0.358 & 0.491 & 0.630 \\ % H H$_2$O (6-311$^{++}$G**) & -0.515 & -0.916 & -1.225 \\ % O % & 0.258 & 0.458 & 0.613 \\ % H \hline H$_2$O (lanl2dz B3LYP) & -0.711 & -0.963 & -0.987 \\ % O % & 0.356 & 0.481 & 0.493 \\ % H H$_2$O (lanl2dz MP2) & -0.745 & -0.965 & -0.989 \\ % O % & 0.373 & 0.483 & 0.494 \\ % H H$_2$O (lanl2dz MP4SDQ) & -0.733 & -0.948 & -0.960 \\ % O % & 0.366 & 0.474 & 0.480 \\ % H \hline H$_2$O (6-311$^{++}$G** B3LYP) & -0.502 & -0.916 & -1.097 \\ % O % & 0.251 & 0.458 & 0.548 \\ % H H$_2$O (6-311$^{++}$G** MP2) & -0.496 & -0.898 & -1.133 \\ % O % & 0.248 & 0.448 & 0.566 \\ % H H$_2$O (6-311$^{++}$G** MP4SDQ) & -0.483 & -0.880 & -1.109 \\ % O % & 0.242 & 0.440 & 0.554 \\ % H \hline \hline H$_3$O$^+$ (lanl2dz) & -0.745 & -0.865 & -1.117 \\ % O % & 0.582 & 0.622 & 0.706 \\ % H \hline \hline OH$^-$ (lanl2dz) & -1.184 & -1.325 & -1.280 \\ % O % & 0.184 & 0.325 & 0.280 \\ % H \hline \end{tabular}\end{center} - --UlVJffcvxoiEqYs2-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 17:09:13 +0100 From: "Xiangyuan Cui" Subject: Re: [WIEN]: About AIM ==== "Xiangyuan Cui" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0008_01C24222.FBB09450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Dear Yanming, you can visit the webpage on: http://www.chemistry.mcmaster.ca/faculty/bader/aim/ or for the full reference, see the book: "Atom in molecules" by R.F.W. Bader. (the book name may be not very = accurate) regards, Xiangyuan ----- Original Message -----=20 From: yanming Ma=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Monday, August 12, 2002 3:02 PM Subject: [WIEN]: About AIM=20 Dear wien2k users, I am interested in the function of AIM (atoms in molecules) in WIEN2k. Can someone provide me the useful references for the basic Bader's = theory of AIM. I will appreciate your helps. Yanming - -------------------------------------------------------------------------= - ----- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs Hi, Dear Yanming, you can visit the webpage on: http://www.chemistry.mcmaster.ca/faculty/bader/aim/ or for the full reference, see the book: "Atom in molecules" by R.F.W. Bader. (the book name may be not very = accurate) regards, Xiangyuan ----- Original Message -----=20 From: yanming Ma=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Monday, August 12, 2002 3:02 PM Subject: [WIEN]: About AIM=20 Dear wien2k users, I am interested in the function of AIM (atoms in molecules) in = WIEN2k. Can someone provide me the useful references for the basic Bader's = theory of AIM. I will appreciate your helps. Yanming - -------------------------------------------------------------------------= - --- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs - ------=_NextPart_000_0008_01C24222.FBB09450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Dear Yanming,
 
you can visit the webpage = on:
 
http://www.c= hemistry.mcmaster.ca/faculty/bader/aim/
 
or for the full reference, = see the=20 book:
 
"Atom in molecules" by R.F.W. Bader. = (the book name=20 may be not very accurate)
 
regards,
Xiangyuan
 
----- Original Message -----
From:=20 yanming = Ma
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Monday, August 12, 2002 = 3:02=20 PM
Subject: [WIEN]: About AIM =

Dear wien2k users,

I am interested in the function of AIM (atoms in molecules) in = WIEN2k.

Can someone provide me the useful references for the basic Bader's = theory=20 of  AIM.

I will appreciate your helps.

Yanming

 


Do You Yahoo!?
= HotJobs,=20 a Yahoo! service - Search Thousands of New Jobs
Hi, Dear Yanming,
 
you can visit the webpage = on:
 
http://www.c= hemistry.mcmaster.ca/faculty/bader/aim/
 
or for the full reference, = see the=20 book:
 
"Atom in molecules" by R.F.W. Bader. = (the book=20 name may be not very accurate)
 
regards,
Xiangyuan
 
----- Original Message -----
From:=20 yanming = Ma=20
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Monday, August 12, 2002 = 3:02=20 PM
Subject: [WIEN]: About AIM =

Dear wien2k users,

I am interested in the function of AIM (atoms in molecules) in=20 WIEN2k.

Can someone provide me the useful references for the basic = Bader's theory=20 of  AIM.

I will appreciate your helps.

Yanming

 


Do You Yahoo!?
= HotJobs,=20 a Yahoo! service - Search Thousands of New=20 Jobs - ------=_NextPart_000_0008_01C24222.FBB09450-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 10:24:24 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: help, Fe3O4.struct ==== Igor Mazin submitted the following contribution: ==== Here is a struct file for a spinel: Title F LATTICE,NONEQUIV. ATOMS: 3 MODE OF CALC=RELA 19.111531 19.111531 19.111531 90.000000 90.000000 90.000000 ATOM= 1: X=0.12500000 Y=0.12500000 Z=0.12500000 MULT= 2 ISPLIT= 2 1: X=0.87500000 Y=0.87500000 Z=0.87500000 Mn NPT= 781 R0=0.00005000 RMT= 2.0000 Z: 25.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.50000000 Y=0.75000000 Z=0.75000000 MULT= 4 ISPLIT= 4 -2: X=0.75000000 Y=0.50000000 Z=0.75000000 -2: X=0.75000000 Y=0.75000000 Z=0.50000000 -2: X=0.50000000 Y=0.50000000 Z=0.50000000 Cr NPT= 781 R0=0.00005000 RMT= 2.0000 Z: 24.0 LOCAL ROT MATRIX: 0.4082483 0.7071068 0.5773503 -0.4082483 0.7071068-0.5773503 -0.8164966 0.0000000 0.5773503 ATOM= -3: X=0.01130000 Y=0.01130000 Z=0.73870000 MULT= 8 ISPLIT= 4 -3: X=0.01130000 Y=0.73870000 Z=0.01130000 serene<211>%cat /scratch/mazin/SPINEL/SPINEL.struct Title F LATTICE,NONEQUIV. ATOMS: 3 MODE OF CALC=RELA 19.111531 19.111531 19.111531 90.000000 90.000000 90.000000 ATOM= 1: X=0.12500000 Y=0.12500000 Z=0.12500000 MULT= 2 ISPLIT= 2 1: X=0.87500000 Y=0.87500000 Z=0.87500000 Mn NPT= 781 R0=0.00005000 RMT= 2.0000 Z: 25.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.50000000 Y=0.75000000 Z=0.75000000 MULT= 4 ISPLIT= 4 -2: X=0.75000000 Y=0.50000000 Z=0.75000000 -2: X=0.75000000 Y=0.75000000 Z=0.50000000 -2: X=0.50000000 Y=0.50000000 Z=0.50000000 Cr NPT= 781 R0=0.00005000 RMT= 2.0000 Z: 24.0 LOCAL ROT MATRIX: 0.4082483 0.7071068 0.5773503 -0.4082483 0.7071068-0.5773503 -0.8164966 0.0000000 0.5773503 ATOM= -3: X=0.01130000 Y=0.01130000 Z=0.73870000 MULT= 8 ISPLIT= 4 -3: X=0.01130000 Y=0.73870000 Z=0.01130000 -3: X=0.73870000 Y=0.01130000 Z=0.01130000 -3: X=0.26130000 Y=0.98870000 Z=0.98870000 -3: X=0.98870000 Y=0.26130000 Z=0.98870000 -3: X=0.98870000 Y=0.98870000 Z=0.26130000 -3: X=0.73870000 Y=0.73870000 Z=0.73870000 -3: X=0.26130000 Y=0.26130000 Z=0.26130000 S NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 16.0 LOCAL ROT MATRIX: -0.4082483-0.7071068 0.5773503 -0.4082483 0.7071068 0.5773503 -0.8164966 0.0000000-0.5773503 48 NUMBER OF SYMMETRY OPERATIONS - --- Wenhui Xie wrote: > ==== > Wenhui Xie > submitted the following contribution: > ==== > > Dear WIEN Users, > > I want to calculate Fe3O4, which have a spinel > crystal structure. > But I always do not generate the right structure > file. > Who can help me, or tell me the struct file of > Fe3O4. > Thank you very much. > > Looking forwards in here. > > Wenhui Xie > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 13:54:22 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: min_lapw ==== Bing Zhou submitted the following contribution: ==== Dear all: I was aked "max. number of structure change---" when I run min_lapw with w2web, so could you please let me know what the max. number is in general? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 13:57:59 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: min_lapw ==== Bing Zhou submitted the following contribution: ==== Dear all: I was aked "max. number of structure change---" when I run min_lapw with w2web, so could you please let me know what the max. number is in general? I also asked the "save every ___ iterations", so what should I put in the blank box? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 13:41:53 -0700 (PDT) From: Michelle Johannes Subject: [WIEN]: single vs. double cells ==== Michelle Johannes submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---307652566-192031902-1029184913=:22883 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Wien users: I am investigating a AFM compound and therefore have to double my unit cell. In the compound I am looking at the single cell is the cubic space group #221 (Pm-3m). This is a peroskite structure and the afm order is along the (111) axis and therefore I end up with a rhombohedral cell which is space group #166 (R-3m). The problem is that if I calculate the ferromagnetic solution in the doubled cell, my energy doesn't look anything like that of double the single cell energy. In fact, there is an approximately 30 Ryd difference!! I compared my energies with another full-potential program (FPLO from IFW Dresden) and my single cell energy differs from the FPLO energy by only 1 or 2 mHartree per atom, which is acceptable. The doubled cell energy is not even comparable. Wien and FPLO are usually quite comparable in terms of total energy. So I wonder what makes this huge energy difference. I am concerned that something about the rhombohedral cell is not being handled right, either in the way that I set it up or the way that it is calculated. Since the sgroup finds the right space group and xcrysden gives me the picture I want, it seems like I have the right .struct file, but I would be happy if someone could point out a mistake. I am including both the single and doubled cell .struct files in case someone would be kind enough to look them over. Any other explanations of energy difference would also be most welcome. Thank you for your help, Michelle - ---307652566-192031902-1029184913=:22883 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="single.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="single.struct" UGFyYSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUCAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiAzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICA3LjM0NzQwMCAgNy4zNDc0MDAgIDcuMzQ3 NDAwIDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gIDE6IFg9MC41MDAwMDAwMCBZPTAuNTAwMDAwMDAg Wj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDINCkdhICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMi4wMDAwICAgWjogMzEuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009ICAyOiBYPTAuMDAwMDAwMDAgWT0w LjAwMDAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSAyDQpDICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuNTAwMCAgIFo6ICA2LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjAw MDAwMDAwIFk9MC4wMDAwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgICAgICBN VUxUPSAzICAgICAgICAgIElTUExJVD0tMg0KICAgICAgLTM6IFg9MC4wMDAw MDAwMCBZPTAuNTAwMDAwMDAgWj0wLjAwMDAwMDAwDQogICAgICAtMzogWD0w LjUwMDAwMDAwIFk9MC4wMDAwMDAwMCBaPTAuMDAwMDAwMDANCk1uICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJNVD0gICAgMi4xMDAgICBa OiAyNS4wICAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCiAgNDggICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUw0K LTEgMCAwIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAu MDAwMDAwMA0KICAgICAgIDENCi0xIDAgMCAwLjAwMDAwMDANCiAwLTEgMCAw LjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICAyDQotMSAwIDAg MC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAwMDAw DQogICAgICAgMw0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAw MA0KIDAtMSAwIDAuMDAwMDAwMA0KICAgICAgIDQNCi0xIDAgMCAwLjAwMDAw MDANCiAwIDAtMSAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAgICAg ICA1DQotMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogMCAx IDAgMC4wMDAwMDAwDQogICAgICAgNg0KLTEgMCAwIDAuMDAwMDAwMA0KIDAg MSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAgIDcNCi0x IDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAw MDAwMDANCiAgICAgICA4DQogMC0xIDAgMC4wMDAwMDAwDQotMSAwIDAgMC4w MDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogICAgICAgOQ0KIDAtMSAwIDAu MDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0K ICAgICAgMTANCiAwIDAtMSAwLjAwMDAwMDANCi0xIDAgMCAwLjAwMDAwMDAN CiAwLTEgMCAwLjAwMDAwMDANCiAgICAgIDExDQogMCAwIDEgMC4wMDAwMDAw DQotMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogICAgICAx Mg0KIDAgMC0xIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMSAw IDAuMDAwMDAwMA0KICAgICAgMTMNCiAwIDAgMSAwLjAwMDAwMDANCi0xIDAg MCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAgICAgIDE0DQogMCAx IDAgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAw MDAwDQogICAgICAxNQ0KIDAgMSAwIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAw MDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgMTYNCiAwLTEgMCAwLjAw MDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCi0xIDAgMCAwLjAwMDAwMDANCiAg ICAgIDE3DQogMC0xIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQot MSAwIDAgMC4wMDAwMDAwDQogICAgICAxOA0KIDAgMC0xIDAuMDAwMDAwMA0K IDAtMSAwIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KICAgICAgMTkN CiAwIDAgMSAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCi0xIDAgMCAw LjAwMDAwMDANCiAgICAgIDIwDQogMCAwLTEgMC4wMDAwMDAwDQogMCAxIDAg MC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogICAgICAyMQ0KIDAgMCAx IDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAw MA0KICAgICAgMjINCiAwIDEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAw MDANCi0xIDAgMCAwLjAwMDAwMDANCiAgICAgIDIzDQogMCAxIDAgMC4wMDAw MDAwDQogMCAwIDEgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogICAg ICAyNA0KIDAtMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0KIDEg MCAwIDAuMDAwMDAwMA0KICAgICAgMjUNCiAwLTEgMCAwLjAwMDAwMDANCiAw IDAgMSAwLjAwMDAwMDANCiAxIDAgMCAwLjAwMDAwMDANCiAgICAgIDI2DQog MCAwLTEgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogMSAwIDAgMC4w MDAwMDAwDQogICAgICAyNw0KIDAgMCAxIDAuMDAwMDAwMA0KIDAtMSAwIDAu MDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0KICAgICAgMjgNCiAwIDAtMSAw LjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAxIDAgMCAwLjAwMDAwMDAN CiAgICAgIDI5DQogMCAwIDEgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAw DQogMSAwIDAgMC4wMDAwMDAwDQogICAgICAzMA0KIDAgMSAwIDAuMDAwMDAw MA0KIDAgMC0xIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0KICAgICAg MzENCiAwIDEgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAxIDAg MCAwLjAwMDAwMDANCiAgICAgIDMyDQogMC0xIDAgMC4wMDAwMDAwDQogMSAw IDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogICAgICAzMw0KIDAt MSAwIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAw MDAwMA0KICAgICAgMzQNCiAwIDAtMSAwLjAwMDAwMDANCiAxIDAgMCAwLjAw MDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCiAgICAgIDM1DQogMCAwIDEgMC4w MDAwMDAwDQogMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQog ICAgICAzNg0KIDAgMC0xIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0K IDAgMSAwIDAuMDAwMDAwMA0KICAgICAgMzcNCiAwIDAgMSAwLjAwMDAwMDAN CiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAgICAgIDM4 DQogMCAxIDAgMC4wMDAwMDAwDQogMSAwIDAgMC4wMDAwMDAwDQogMCAwLTEg MC4wMDAwMDAwDQogICAgICAzOQ0KIDAgMSAwIDAuMDAwMDAwMA0KIDEgMCAw IDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgNDANCiAxIDAg MCAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAw MDANCiAgICAgIDQxDQogMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAw MDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICA0Mg0KIDEgMCAwIDAuMDAw MDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAwMA0KICAg ICAgNDMNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAw LTEgMCAwLjAwMDAwMDANCiAgICAgIDQ0DQogMSAwIDAgMC4wMDAwMDAwDQog MCAwLTEgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogICAgICA0NQ0K IDEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KIDAgMSAwIDAu MDAwMDAwMA0KICAgICAgNDYNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAw LjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAgIDQ3DQogMSAwIDAg MC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAw DQogICAgICA0OA0K - ---307652566-192031902-1029184913=:22883 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="double.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="double.struct" R2FDTW4zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUiAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiA1ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDEwLjM5MTAwMCAxMC4zOTEwMDAgMjUuNDUw NzUwIDkwLjAwMDAwMCA5MC4wMDAwMDAxMjAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDQNCkdhMSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMi4yMDAwICAgWjogMzEuMSAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuMjUwMDAwMDAgWT0w LjI1MDAwMDAwIFo9MC4yNTAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDIgICAg ICAgICAgSVNQTElUPSA0DQogICAgICAtMjogWD0wLjc1MDAwMDAwIFk9MC43 NTAwMDAwMCBaPTAuNzUwMDAwMDANCkMgICAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS40MDAwICAgWjogIDYuMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0zOiBY PTAuNTAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDMgICAgICAgICAgSVNQTElUPSA4DQogICAgICAtMzogWD0w LjAwMDAwMDAwIFk9MC41MDAwMDAwMCBaPTAuMDAwMDAwMDANCiAgICAgIC0z OiBYPTAuMDAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9MC41MDAwMDAwMA0KTW4x ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAyLjI1 MDAgICBaOiAyNS4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMC4wMDAwMDAwIDAuNTAwMDAwMCAwLjg2NjAyNTQNCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMC0wLjg2NjAyNTQgMC41MDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAu MDAwMDAwMA0KQVRPTT0gLTQ6IFg9MC41MDAwMDAwMCBZPTAuNTAwMDAwMDAg Wj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDQNCkdhMiAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDA1MDAwIFJN VD0gICAgMi4yMDAwICAgWjogMzEuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC01OiBYPTAuNTAwMDAwMDAgWT0w LjUwMDAwMDAwIFo9MC4wMDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDMgICAg ICAgICAgSVNQTElUPSA4DQogICAgICAtNTogWD0wLjUwMDAwMDAwIFk9MC4w MDAwMDAwMCBaPTAuNTAwMDAwMDANCiAgICAgIC01OiBYPTAuMDAwMDAwMDAg WT0wLjUwMDAwMDAwIFo9MC41MDAwMDAwMA0KTW4yICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMDUwMDAgUk1UPSAgICAyLjI1MDAgICBaOiAyNS4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMC4wMDAw MDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAxMiAg ICAgIE5VTUJFUiBPRiBTWU1NRVRSWSBPUEVSQVRJT05TDQotMSAwIDAgMC4w MDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQog ICAgICAgMQ0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0K IDAtMSAwIDAuMDAwMDAwMA0KICAgICAgIDINCiAwLTEgMCAwLjAwMDAwMDAN Ci0xIDAgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAgICAz DQogMCAwLTEgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAg MC4wMDAwMDAwDQogICAgICAgNA0KIDAtMSAwIDAuMDAwMDAwMA0KIDAgMC0x IDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KICAgICAgIDUNCiAwIDAt MSAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCi0xIDAgMCAwLjAwMDAw MDANCiAgICAgICA2DQogMCAwIDEgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAw MDAwDQogMSAwIDAgMC4wMDAwMDAwDQogICAgICAgNw0KIDAgMSAwIDAuMDAw MDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0KICAg ICAgIDgNCiAwIDAgMSAwLjAwMDAwMDANCiAxIDAgMCAwLjAwMDAwMDANCiAw IDEgMCAwLjAwMDAwMDANCiAgICAgICA5DQogMCAxIDAgMC4wMDAwMDAwDQog MSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICAxMA0K IDEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KIDAgMSAwIDAu MDAwMDAwMA0KICAgICAgMTENCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAw LjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAgIDEyDQo= - ---307652566-192031902-1029184913=:22883-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 19:26:32 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: EFG tensors direction ==== Bing Zhou submitted the following contribution: ==== Dear all: After the SCF cycles, how can I correlate the calculated EFG tensor directions in PAS with the crystal directions (a, b, c)? can I find it in the case.scf file or other files? Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 03:18:58 +0200 From: Victor Lua~na Cabal Subject: Re: [WIEN]: About AIM ==== Victor Lua~na Cabal submitted the following contribution: ==== > Date: Mon, 12 Aug 2002 17:50:59 +0200 > From: "Dr. Alexander Hofmann" > Subject: Re: [WIEN]: About AIM > > ==== > "Dr. Alexander Hofmann" > submitted the following contribution: > ==== > For some reasons I made in my molecular life tests with Baders program > (PROAIMV) on the water molecule with different basis sets. I did the same > with the Mulliken analysis (very common in molecular chemistry) and the > Gaussian98 NPA (=Natural Population Analysis). And it turned out that > the NPA is the most stable analysis with respect to varying basis sets. > We can learn at least a couple of things from this (comments welcome): > - Even the conceptually best analysis (Bader) gives widely spreaded > _absolute_ numbers. I'm affraid that some of the calculations that you do compare can be misleading with respect to the topological (Bader's) charges: (1) Bader's charges do, in fact, converge quite well with respect to the basis set quality and theory level. To ensure a reasonable quality on your wavefunction you need to include polarization functions and, in the case of very electronegative atoms (O, F, etc), diffuse functions as well. Poor bases produce a poor wavefunction and, consequently, poor topological properties. (2) Bader's techniques do work on all electron wavefunctions. The use of ECP's, like in your LANL2DZ calculations, excludes, in principle, the topological analysis. There have been some attempts to recover the complete electron density from the pseudodensity obtained in a pseudopotential calculation (see the references below). PROAIMV results for a valence electron pseudodensity are, in principle, a numerical freak. Best regards, Victor Lua~na victor@carbono.quimica.uniovi.es @Article{AIM-VS97, author = { S. F. Vyboishchikov and A. Sierraalta and G. Frenking }, title = { Topological Analysis of Electron-Density Distribution Taken from a Pseudopotential Calculation }, journal = { J. Comput. Chem. }, year = { 1997 }, volume = { 18 }, pages = { 416-429 }, address = { UNIV-MARBURG, FACHBEREICH CHEM, D-35032 MARBURG, GERMANY } } @Article{AIM-CP96, author = { J. Cioslowski and P. Piskorz }, title = { Properties of Atoms in Molecules from Valence-Electron Densities Augmented with Core-Electron Contributions }, journal = { Chem. Phys. Lett. }, year = { 1996 }, volume = { 255 }, pages = { 315-319 }, address = { FLORIDA-STATE-UNIV, DEPT COMP, TALLAHASSEE, FL 32306, USA; FLORIDA-STATE-UNIV, SUPERCOMP COMPUTAT RES INST, TALLAHASSEE, FL 32306, USA; } } ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 12 Aug 2002 20:50:43 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: EFG tensors direction ==== "Saeid Jalali" submitted the following contribution: ==== > After the SCF cycles, how can I correlate the calculated EFG tensor > directions in PAS with the crystal directions (a, b, c)? can I find it in > the case.scf file or other files? One interested to analyze EFG needs after a well converged SCF to first change TOT to EFG in case.in2 file, and then run lapw2 program: x lapw2 (with the appropriate switch, e.g. -up/dn -so ..., if necessary). After the step outlined above, the EFG component before transformation in general axis system and after transformation in principal axis system (PAS), where the tensor is diagonal, can be found in case.output2 (up/dn). Bing, I am sure you will enjoy reading the nice written description manuscript by Stefaan: http://www.wien2k.at/reg_user/faq/efg.html/efg.pdf Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 14:39:40 +0900 From: "Ichiro Nagano" Subject: Re: [WIEN]: The problem in band character plot ==== "Ichiro Nagano" submitted the following contribution: ==== Dear Dr. Wenhui Xie and WIEN2k users, I have a same problem. I tried TiC Bandstructure (with band character) as routine manner. (Generate k-list, edit tic.in1, lapw1 -up, edit tic.in2, and lapw2 -up -qtl.) When I start lapw2 with -up spin option, the program seems to search opposite down spin (tic.energydn) file. (see below) executing: x lapw2 -up -qtl PGFIO-F-252/list-directed read/unit=29/operation attempted after end of file. File name = tic.energydn formatted, sequential access record = 698 In source file fermi.f, at line number 63 0.040u 0.020s 0:00.15 40.0% 0+0k 0+0io 443pf+0w RETURN key to continue ... In case of with -dn spin option, lapw2 program seems to search opposite upper spin (tic.energyup) file. (see below) executing: x lapw2 -dn -qtl PGFIO-F-252/list-directed read/unit=29/operation attempted after end of file. File name = tic.energyup formatted, sequential access record = 697 In source file fermi.f, at line number 63 0.030u 0.020s 0:00.19 26.3% 0+0k 0+0io 192pf+0w RETURN key to continue ... I recompiled with HP-Fortran90, it seemed no problem. Though I recompiled with PGI, Intel, Absoft and Lahey, they caused same error. Thanks for any help. Ichiro Nagano Advanced Technology Research Center, Mitsubishi Heavy Industries, Ltd. 1-8-1, Sachiura, Kanazawa-ku, Yokohama, 236-8515, Japan Ichiro Nagano e-mail: TEL: + 81 (45) 771-1222 FAX: + 81 (45) 771-3879 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 15:01:47 +0800 From: Wenhui Xie Subject: Re: [WIEN]: help, Fe3O4.struct ==== Wenhui Xie submitted the following contribution: ==== Dear Mazin, Thank you very much. How to understant the u parameter in Spinel, which is not shown in your structure file? Best Regard. Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 06:33:31 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: help, Fe3O4.struct ==== Igor Mazin submitted the following contribution: ==== Hi, You need to change the line ATOM= -3: X=0.01130000 Y=0.01130000 Z=0.73870000 and the other "-3" lines according to your parameter u. X=a Y=a Z=0.75-a, where a is the internal structural parameter (your u may be defined differently, but it is easy to figure out the correspondence). Good luck. - --- Wenhui Xie wrote: > ==== > Wenhui Xie > submitted the following contribution: > ==== > > Dear Mazin, > > Thank you very much. > How to understant the u parameter in Spinel, which > is not shown in your > structure file? > > Best Regard. > > Wenhui Xie > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 07:27:35 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2- ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion or PGFIO-F-217/list-directed read /unit=30/attempt to read past end of file: filename=home.energyup formatted,sequential access record=285) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 07:28:07 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2 ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 07:43:10 -0700 (PDT) From: hamid salehi Subject: [WIEN]: XLstart ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started Initializ cale and got this message(Xlstart:ERROR In OPENING UNIT:5 FILE Name: home inst STATUS:Old FORM:Formated 0.000u,0.000s.... 0+0k 167pf+0w and in "view outputstin" disappear System Error). what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 12:32:49 -0400 From: Fred Nastos Subject: Re: [WIEN]: Xlape2- ==== Fred Nastos submitted the following contribution: ==== Hamid, Please supply more information. It is rarely enough that anyone can figure out your mistake if you only give the runtime error message. On August 13, 2002 10:27 am, hamid salehi wrote: > ==== > hamid salehi > submitted the following contribution: > ==== > > Dear wien users. > Ihave started XSPES and got this > message(PGFIO-F-231/formated read /unit=1001/error on > data conversion or PGFIO-F-217/list-directed read > /unit=30/attempt to read past end of file: > filename=home.energyup formatted,sequential access > record=285) in "Xlapw2-qtl-up". what dose it mean? > Thank you for the guide. > H-Salehi > > > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 16:53:04 -0400 (EDT) From: Neme Nnolim Subject: [WIEN]: Struct file for Ta_2O_5? ==== Neme Nnolim submitted the following contribution: ==== Dear Wien users, I have been trying to build a struct file for Tantalum (V) oxide. Of course this would require a knowledge of all atomic positions. I have so far not come across a reference from which I can obtain this information. Does anyone have a struct file for this material already built, or can they point me to a good reference? I have ordered the relevant Landolt-Bornstein series through our library but it will be a while before I receive it. Regards, Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 18:17:49 -0400 From: Fred Nastos Subject: Re: [WIEN]: Struct file for Ta_2O_5? ==== Fred Nastos submitted the following contribution: ==== My understanding is that Tantalum (V) Oxide has the chemical formula Ta_{2}O_{5}, so I'd start with PRB 55, 11155 (1997). On August 13, 2002 04:53 pm, Neme Nnolim wrote: > ==== > Neme Nnolim > submitted the following contribution: > ==== > > Dear Wien users, > > I have been trying to build a struct file for Tantalum (V) oxide. Of > course this would require a knowledge of all atomic positions. I have so > far not come across a reference from which I can obtain this > information. > > Does anyone have a struct file for this material already > built, or can they point me to a good reference? I have ordered the > relevant Landolt-Bornstein series through our library but it will be a > while before I receive it. > > > Regards, > > Neme > --------------------------------------------------------------------------- >--- Neme Okechukwu Nnolim > Department of Materials Science, New Jersey Institute of Technology > Room 302, Tiernan Hall, 161 Warren Street, University Heights > Newark, New Jersey 07102-1982 > Tel: (973) 596-8283, FAX: (973) 596-5794 > --------------------------------------------------------------------------- >---- > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 13 Aug 2002 19:50:41 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Struct file for Ta_2O_5? ==== Neme Nnolim submitted the following contribution: ==== Actually, I have seen that paper before, and the structure given there is a highly hypothetical structure of one type of Ta_2O_5, thought to be present in thin films. I was looking for a recent structure determination more based on experimental methods. Thanks for your trouble anyway. On Tue, 13 Aug 2002, Fred Nastos wrote: > Date: Tue, 13 Aug 2002 18:17:49 -0400 > From: Fred Nastos > Reply-To: wien@zeus.theochem.tuwien.ac.at > To: wien@zeus.theochem.tuwien.ac.at > Subject: Re: [WIEN]: Struct file for Ta_2O_5? > > ==== > Fred Nastos > submitted the following contribution: > ==== > > > My understanding is that Tantalum (V) Oxide has the chemical > formula Ta_{2}O_{5}, so I'd start with PRB 55, 11155 (1997). > > On August 13, 2002 04:53 pm, Neme Nnolim wrote: > > ==== > > Neme Nnolim > > submitted the following contribution: > > ==== > > > > Dear Wien users, > > > > I have been trying to build a struct file for Tantalum (V) oxide. Of > > course this would require a knowledge of all atomic positions. I have so > > far not come across a reference from which I can obtain this > > information. > > > > Does anyone have a struct file for this material already > > built, or can they point me to a good reference? I have ordered the > > relevant Landolt-Bornstein series through our library but it will be a > > while before I receive it. > > > > > > Regards, > > > > Neme > > --------------------------------------------------------------------------- > >--- Neme Okechukwu Nnolim > > Department of Materials Science, New Jersey Institute of Technology > > Room 302, Tiernan Hall, 161 Warren Street, University Heights > > Newark, New Jersey 07102-1982 > > Tel: (973) 596-8283, FAX: (973) 596-5794 > > --------------------------------------------------------------------------- > >---- > > > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 10:23:48 +0800 From: Wenhui Xie Subject: Re: [WIEN]: The problem in band character plot ==== Wenhui Xie submitted the following contribution: ==== Dear Naqano, I just run lapw1 again to produce the case.energy. Best Regards Wenhui Xie On Tuesday 13 August 2002 01:39 pm, Ichiro Nagano wrote: > ==== > "Ichiro Nagano" > submitted the following contribution: > ==== > > Dear Dr. Wenhui Xie and WIEN2k users, > > I have a same problem. > > I tried TiC Bandstructure (with band character) as routine manner. > (Generate k-list, edit tic.in1, lapw1 -up, edit tic.in2, and > lapw2 -up -qtl.) > > When I start lapw2 with -up spin option, the program seems to search > opposite down spin (tic.energydn) file. (see below) > > executing: x lapw2 -up -qtl > PGFIO-F-252/list-directed read/unit=29/operation attempted after end of > file. > File name = tic.energydn formatted, sequential access record = 698 > In source file fermi.f, at line number 63 > 0.040u 0.020s 0:00.15 40.0% 0+0k 0+0io 443pf+0w > RETURN key to continue ... ............................. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 15:03:23 +0200 From: Thomas Claesson Subject: [WIEN]: Two questions ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I have two different questions that I would appreciate your help with: 1. I am working on a case where I add LDA+U to the calculation. When comparing the bandstructures calculated with and without LDA+U, I can see that the Fermi energy has changed drastically. Without ordinary LDA (no U) there is a lot bands below the Fermi energy, but when LDA+U is added about half of the number of bands that were below E_f are instead above it. This seems strange! I am loosing electrons here or what happens? 2. When I reach self-consistency I always save my case in a separate directory (save_lapw -d) before calculating properties. I suppose I should not change (cd) to this new directory before starting to calculate properties like bandstructure and DOS. I always calculate properties from the original case directory where I started the SCF cycle. It this the correct approach? Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 15:29:40 +0200 From: Thomas Claesson Subject: [WIEN]: kgen crashes with segmentation fault ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am running Wien2k on an AIX multiprocessor system. Some days ago I found out that every time I try to run kgen (with x kgen) it crashes with an error message like Segmentation fault (core dumped) 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w I tried downloading kgen again and it compiles just fine without any errors. I have used the xlf90 compiler. All the other programs seem to run fine. What could this mean and what can I do to avoid it? Any suggestions are welcome! Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 16:16:37 +0200 From: Thomas Claesson Subject: [WIEN]: A question and a comment ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! First a comment: I really liked the new introductory text about DFT and LAPW-methods written by S. Cottenier and available at http://www.wien2k.at/reg_user/textbooks/. I downloaded the ps file version of the text, which was OK, but pdf-file is obviously not working. It would be usefull to have it pdf format as well, so I would appreciate it if Stefaan and/or the Wien people could fix that. Then my question: I wonder about the Fermi energy calculated in the SCF cycle. Suppose my case.scf file says that the Fermi energy is 0.52 Ry, where is the zero of that energy scale? In the above mentioned text it says that: "whenever an energy is expressed in Ry it is relative to a scale where the zero corresponds to the average potential in the interstitial region". Is this really true also for the Fermi energy itself? Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 16:29:02 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Two questions - answer to the second one ==== Torsten Andersen submitted the following contribution: ==== Dear Thomas, I have no real clue to the first question... I would guess it has something to do with how you select the U. But to the second question... it is probably correct. You can always restore from your saved calculation if something fails. However, I usually save everything before doing properties, just to be sure I can reproduce them and that I will not get results related to the next (or next-next) cycle in stead. In the ideal case it should not matter. However, I don't do ideal cases. Best regards, Torsten. Thomas Claesson wrote: > ==== > Thomas Claesson > submitted the following contribution: > ==== > > Dear Wien users and developers! > > I have two different questions that I would appreciate your help with: > > 1. I am working on a case where I add LDA+U to the calculation. When > comparing the bandstructures calculated with and without LDA+U, I can > see that the Fermi energy has changed drastically. Without ordinary > LDA (no U) there is a lot bands below the Fermi energy, but when LDA+U > is added about half of the number of bands that were below E_f are > instead above it. This seems strange! I am loosing electrons here or > what happens? > > 2. When I reach self-consistency I always save my case in a separate > directory (save_lapw -d) before calculating properties. I suppose I > should not change (cd) to this new directory before starting to > calculate properties like bandstructure and DOS. I always calculate > properties from the original case directory where I started the SCF > cycle. It this the correct approach? > > Best regards, > Thomas Claesson > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 07:32:01 -0700 (PDT) From: hamid salehi Subject: [WIEN]: XLstart ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started Initializ cale and got this message(Xlstart:ERROR In OPENING UNIT:5 FILE Name: home inst STATUS:Old FORM:Formated 0.000u,0.000s.... 0+0k 167pf+0w and in "view outputstin" disappear System Error). what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 07:34:13 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2- ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion or PGFIO-F-217/list-directed read /unit=30/attempt to read past end of file: filename=home.energyup formatted,sequential access record=285) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 07:35:31 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xlape2 ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started XSPES and got this message(PGFIO-F-231/formated read /unit=1001/error on data conversion) in "Xlapw2-qtl-up". what dose it mean? Thank you for the guide. H-Salehi __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 07:39:53 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Two questions ==== "Saeid Jalali" submitted the following contribution: ==== > 1. I am working on a case where I add LDA+U to the calculation. When > comparing the bandstructures calculated with and without LDA+U, I can > see that the Fermi energy has changed drastically. Without ordinary LDA > (no U) there is a lot bands below the Fermi energy, but when LDA+U is > added about half of the number of bands that were below E_f are instead > above it. This seems strange! I am loosing electrons here or what happens? Although it is beloved that LDA+U is not a pure ab initio calculation, it is still an all electronic calculation. It is not as we add an extra potential and so mix the initial DFT Hamiltonian with a given term of a model Hamiltonian. It is still as the system under LDA+U study should not be charged or inversely discharged by electrons. Thus, the total number of electrons must within LDA+U remains constant changing the U value from zero to any other positive value. Therefore, one would first check this role integrating from the total DOS in the valence bands and semicore bands, analyze total :QTL value, or look at in2 file. After this, one would look at inc file to find the number of core electrons, and then plus it to total number of valence electrons (semi core + valence). I am sure it will rich a same value both for U=0 and U<>0, as number of electrons is independent of U value. But Tomas, please consider this fact that U may change the bands drastically depending on how the system is strongly correlated, as it is its task to rich what DOS's or physics one is looking for. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 10:48:57 -0400 From: Jeff Spirko Subject: Re: [WIEN]: kgen crashes with segmentation fault ==== Jeff Spirko submitted the following contribution: ==== On Wed, Aug 14, 2002 at 03:29:40PM +0200, Thomas Claesson wrote: > I am running Wien2k on an AIX multiprocessor system. Some days ago I > found out that every time I try to run kgen (with x kgen) it crashes > with an error message like > > Segmentation fault (core dumped) > 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w > > I tried downloading kgen again and it compiles just fine without any > errors. I have used the xlf90 compiler. All the other programs seem to > run fine. What could this mean and what can I do to avoid it? Any > suggestions are welcome! Try increasing your stack size before running kgen. 128MB seems to be enough for kgen. Choose from the following: bash> ulimit -s unlimited # automatically chooses hard limit ksh> ulimit -s 131072 csh> limit stacksize 131072 - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 08:08:27 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== - --- Thomas Claesson wrote: > ==== > Thomas Claesson > submitted the following contribution: > ==== >"whenever an energy is expressed in Ry it is relative >to a scale where >the zero corresponds to the average potential in the >interstitial >region". Is this really true also for the Fermi >energy itself? Yes > 2. When I reach self-consistency I always save my > case in a separate > directory (save_lapw -d) before calculating > properties. I suppose I > should not change (cd) to this new directory before > starting to > calculate properties like bandstructure and DOS. I > always calculate > properties from the original case directory where I > started the SCF > cycle. It this the correct approach? Yes > 1. I am working on a case where I add LDA+U to the > calculation. When > comparing the bandstructures calculated with and > without LDA+U, I can > see that the Fermi energy has changed drastically. > Without ordinary LDA > (no U) there is a lot bands below the Fermi energy, > but when LDA+U is > added about half of the number of bands that were > below E_f are instead > above it. This seems strange! I am loosing electrons > here or what happens? The short answer is no, you are probably splitting a correlated band into a lower Hubbard band and an upper Hubbard band. A long answer is: ideologically, LDA+U is very much not the same as DFT. DFT is a well defined approximation, which (with many reservations) can be used by a knowledgeble solid state physicist without previous experience in the field. LDA+U is NOT a well defined approximation. First, it includes something missing in LDA and misses something included in LDA. It may be substantially inferior to straight LDA. Second, it is not unique. It involves poorly defined parameters U and J and a selection of different double counting terms, all reflecting diferent physics. Third, unlike LDA, it has much more often metastable solutions which are not the ground state, but can be easily mistaken for one. For these reasons, before indulging in LDA+U calculations even a highly qualified theorist, in my opininon, should thoroughly study the literature and the theory of correlated systems, to have a clear idea what kind of physics he or she expects to describe using LDA+U, and WHY this physics requires specifically LDA+U approach. Good luck. Igor ===== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 10:58:40 -0700 (PDT) From: Javad Hashemifar Subject: Re: [WIEN]: Xlape2- ==== Javad Hashemifar submitted the following contribution: ==== - --- hamid salehi wrote: > ==== > hamid salehi > submitted the following contribution: > ==== > > Dear wien users. > Ihave started XSPES and got this > message(PGFIO-F-231/formated read /unit=1001/error > on > data conversion or PGFIO-F-217/list-directed read > /unit=30/attempt to read past end of file: > filename=home.energyup formatted,sequential access > record=285) in "Xlapw2-qtl-up". what dose it mean? > Thank you for the guide. > H-Salehi > I think that you have a spin polarized system but you are trying to plot a non spin polarized band structure. May be the up and down switches aren't active in your w2web interface. May be your problem solved if you run "x lapw2 -up(dn) -qtl" in command box or terminal. Bests. J. Hashemifar Isfahan univ. of Tech., Isfahan, Iran > > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 11:07:52 -0700 (PDT) From: Javad Hashemifar Subject: Re: [WIEN]: XLstart ==== Javad Hashemifar submitted the following contribution: ==== - --- hamid salehi wrote: > ==== > hamid salehi > submitted the following contribution: > ==== > > Dear wien users. > Ihave started Initializ cale and got this > message(Xlstart:ERROR In OPENING UNIT:5 > FILE Name: > home inst > STATUS:Old FORM:Formated > 0.000u,0.000s.... 0+0k 167pf+0w > and in "view outputstin" disappear System Error). > what > dose it mean?or What is its reason? > What should be done for eliminating it? > Thank you for the guide. > H-Salehi > Dept of physics > Ferdowsi University > MASHHAD IRAN > dear Hamid, Are you sure that you have a case.inst file. A problem that may be occured is thta after struct generelization and saving it you didn't click on "save file and clean up". After clicking it, the case.inst file will produced. Bests. J. Hashemifar Isfahan Univ. of Tech. Isfahan. Iran > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 102 19:39:31 -0300 (EST) From: Luiz Alberto Terrazo Subject: [WIEN]: intel IFC compiler ==== Luiz Alberto Terrazo submitted the following contribution: ==== Dear Wien users I installed the wien2k code in a cluster machine (PIII) with Linux . I would like to know where I can download the IFC intel compiler. best regards luis ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 11:01:51 +0900 From: Hiroshi Tanaka Subject: Re: [WIEN]: intel IFC compiler ==== Hiroshi Tanaka submitted the following contribution: ==== Dear Luis, At 19:39 02/08/14 -0300, you wrote: >I would like to know where I can download the IFC intel compiler. >best regards You can download it from, http://www.intel.com/software/products/global/eval.htm Regards, Hiroshi Hiroshi Tanaka Dept. of Material Science, Faculty of Sci. & Eng. Shimane Univ. E-mail:tanakah@riko.shimane-u.ac.jp Phone :+81-852-32-6386 $BEg:,Bg3XAm9gM}9)3XItJ* Subject: [WIEN]: can antiferromagnetic be mimicked by U? ==== "Saeid Jalali" submitted the following contribution: ==== Dear all, It is shown that TOTMM of FeAl within LDA+(U=5eV) calculation drops to zero from the value obtained, 0.73mB, within LDA+(U=0) calculation. It is an indication of LDA+U capability to predict paramagnetic behavior which is in excellent agreement with experiment and in contrast to predicted ferromagnetic behavior by pure LDA. Consider a highly correlated paramagnetic compound at room temperature. However, suppose it is an antiferromagnetic system at low temperature with a small moment around 0.2mB. So to calculate low temperature properties, one would first make a super cell with a known oriented spin directions classifying/indexing equivalent atoms to non equivalent atoms to reproduce the experimental values changing the external U parameter. This is one natural way, but I am not sure if the following way also is a reasonable physical way or not: Instead of making antiferromagnetic super cell, going through the problem ferromagnetically within the primitive cell without assuming any initial spin directions just changing the U value to regenerate the small experimental moment. Then, keeping the obtained U value, try to find another physical quantity taking still the ferromagnetic treatment into account. Please notice that the obtained U values within antiferromagnetic and ferromagnetic treatments can be different. Now my two questions are as follows: Can the obtained U value of a natural antiferromagnetic system within a ferromagneticaly magnetic moment calculation mimic the antiferromagnetic situation? Can the obtained U value of a natural antiferromagnetic system within a ferromagneticaly magnetic moment calculation mimic the paramagnetic situation considering the small moment 0.2mB? This means that can the calculation be extended to the room temperature? ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 17:13:02 +0200 From: Thomas Claesson Subject: Re: [WIEN]: Two questions ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! Many thanks for your replies, Igor and Saeid. However I am still a bit confused about the results I get. I have compared running LDA+U where U is very small U (0.0001 Ry) and ordinary LDA (no U). The strange thing is that the bands look almost the same in these two cases but the Fermi energy shifts drastically. This surprises me, how can the Fermi energy shift so much with U so close to zero? The case I am workning on is NiO in the AF II configuration. Any suggestions are welcome! Thanks for yuor replies! Best regards, Thomas Claesson >==== >Igor Mazin >submitted the following contribution: >==== > > >--- Thomas Claesson wrote: > >>==== >>Thomas Claesson >>submitted the following contribution: >>==== >>"whenever an energy is expressed in Ry it is relative >>to a scale where >>the zero corresponds to the average potential in the >>interstitial >>region". Is this really true also for the Fermi >>energy itself? >> > >Yes > >>2. When I reach self-consistency I always save my >>case in a separate >>directory (save_lapw -d) before calculating >>properties. I suppose I >>should not change (cd) to this new directory before >>starting to >>calculate properties like bandstructure and DOS. I >>always calculate >>properties from the original case directory where I >>started the SCF >>cycle. It this the correct approach? >> > >Yes > >>1. I am working on a case where I add LDA+U to the >>calculation. When >>comparing the bandstructures calculated with and >>without LDA+U, I can >>see that the Fermi energy has changed drastically. >>Without ordinary LDA >>(no U) there is a lot bands below the Fermi energy, >>but when LDA+U is >>added about half of the number of bands that were >>below E_f are instead >>above it. This seems strange! I am loosing electrons >>here or what happens? >> > >The short answer is no, you are probably splitting >a correlated band into a lower Hubbard band and an >upper Hubbard band. > >A long answer is: ideologically, LDA+U is very much >not the same as DFT. DFT is a well defined >approximation, which (with many reservations) can be >used by a knowledgeble solid state physicist without >previous experience in the field. LDA+U is NOT a well >defined approximation. First, it includes something >missing in LDA and misses something included in LDA. >It may be substantially inferior to straight LDA. >Second, it is not unique. It involves poorly defined >parameters U and J and a selection of different double >counting terms, all reflecting diferent physics. >Third, unlike LDA, it has much more often metastable >solutions which are not the ground state, but can be >easily mistaken for one. For these reasons, before >indulging in LDA+U calculations even a highly >qualified theorist, in my opininon, should thoroughly >study the literature and the theory of correlated >systems, to have a clear idea what kind of physics he >or she expects to describe using LDA+U, and WHY this >physics requires specifically LDA+U approach. > >Good luck. >Igor > >===== > > >__________________________________________________ >Do You Yahoo!? >HotJobs - Search Thousands of New Jobs >http://www.hotjobs.com >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > Although it is beloved that LDA+U is not a pure ab initio calculation, it is still an all electronic calculation. It is not as we add an extra potential and so mix the initial DFT Hamiltonian with a given term of a model Hamiltonian. It is still as the system under LDA+U study should not be charged or inversely discharged by electrons. Thus, the total number of electrons must within LDA+U remains constant changing the U value from zero to any other positive value. Therefore, one would first check this role integrating from the total DOS in the valence bands and semicore bands, analyze total :QTL value, or look at in2 file. After this, one would look at inc file to find the number of core electrons, and then plus it to total number of valence electrons (semi core + valence). I am sure it will rich a same value both for U=0 and U<>0, as number of electrons is independent of U value. But Tomas, please consider this fact that U may change the bands drastically depending on how the system is strongly correlated, as it is its task to rich what DOS's or physics one is looking for. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 13:37:36 -0300 (ARST) From: Fabian Dominguez Subject: [WIEN]: TEMP-TETRA option / question for IGOR MAZIN ==== Fabian Dominguez submitted the following contribution: ==== Dear Wien users, I'm trying to run Fe-Nd and as if the case in previous Fe-Nd-B runnings I have problems of oscilations, and I get :DIS not lower than 0.02, getting this value doing oscilations. Questions are two: I did these running using TETRA and after TEMP option, last one with eval in 0.002, question is: In a previous WIEN mails I saw thar somebody was told to use TEMP option, BUT finally convergence MUST be got using TETRA, Is this true? or I can do convergence till the end using TEMP or GAUSS option...? Question 2: How could I do to use TETRA option which I think is the best and get through these problemas of converging? IGOR...I need to say that in big cell NdFeB I use TEMP option and after I didn't turn to TETRA option to get final convergence It's necessary to say now I'm doing a running of NdFeB but with TETRA, and apparently nothing strange happens, I mean oscilations.. Regards, Fabian ============================***================================= Lic. Fabian Alfredo Dominguez Avenalle. Instituto de Fisica de Liquidos y Sistemas Biologicos (IFLYSIB). Universidad Nacional de La Plata (UNLP). Calle 59 N 789 La Plata CP. 1900 BUENOS AIRES ARGENTINA CC. 565 TE: 0221-4233283 TELEFAX: 0221-4257317 E-MAIL: fabian@iflysib.unlp.edu.ar ============================***================================= ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 14 Aug 2002 22:46:40 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Two questions ==== "Saeid Jalali" submitted the following contribution: ==== > energy shifts drastically. This surprises me, how can the Fermi energy > shift so much with U so close to zero? As far as I remember, it is recommended by the authors to use LDA for LDA+U calculation and not any more advanced extended approximations for the exchange correlation potential. This says that one should not compare GGA+U with GGA or LDA+U with GGA and so on. I suggest to first check your LDA+U calculation for a rather simple example, for instance fcc-Sm. Perhaps it is better to wait to see if Igor would give us some insights in this respect. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 11:30:35 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== When you plot bands, do you not forget to add -orb to lapw? - --- Thomas Claesson wrote: > ==== > Thomas Claesson > submitted the following contribution: > ==== > > Dear Wien users and developers! > > Many thanks for your replies, Igor and Saeid. > However I am still a bit > confused about the results I get. I have compared > running LDA+U where U > is very small U (0.0001 Ry) and ordinary LDA (no U). > The strange thing > is that the bands look almost the same in these two > cases but the Fermi > energy shifts drastically. This surprises me, how > can the Fermi energy > shift so much with U so close to zero? The case I am > workning on is NiO > in the AF II configuration. Any suggestions are > welcome! > > Thanks for yuor replies! > > Best regards, > Thomas Claesson > > >==== > >Igor Mazin > >submitted the following contribution: > >==== > > > > > >--- Thomas Claesson wrote: > > > >>==== > >>Thomas Claesson > >>submitted the following contribution: > >>==== > >>"whenever an energy is expressed in Ry it is > relative > >>to a scale where > >>the zero corresponds to the average potential in > the > >>interstitial > >>region". Is this really true also for the Fermi > >>energy itself? > >> > > > >Yes > > > >>2. When I reach self-consistency I always save my > >>case in a separate > >>directory (save_lapw -d) before calculating > >>properties. I suppose I > >>should not change (cd) to this new directory > before > >>starting to > >>calculate properties like bandstructure and DOS. I > >>always calculate > >>properties from the original case directory where > I > >>started the SCF > >>cycle. It this the correct approach? > >> > > > >Yes > > > >>1. I am working on a case where I add LDA+U to the > >>calculation. When > >>comparing the bandstructures calculated with and > >>without LDA+U, I can > >>see that the Fermi energy has changed drastically. > >>Without ordinary LDA > >>(no U) there is a lot bands below the Fermi > energy, > >>but when LDA+U is > >>added about half of the number of bands that were > >>below E_f are instead > >>above it. This seems strange! I am loosing > electrons > >>here or what happens? > >> > > > >The short answer is no, you are probably splitting > >a correlated band into a lower Hubbard band and an > >upper Hubbard band. > > > >A long answer is: ideologically, LDA+U is very much > >not the same as DFT. DFT is a well defined > >approximation, which (with many reservations) can > be > >used by a knowledgeble solid state physicist > without > >previous experience in the field. LDA+U is NOT a > well > >defined approximation. First, it includes something > >missing in LDA and misses something included in > LDA. > >It may be substantially inferior to straight LDA. > >Second, it is not unique. It involves poorly > defined > >parameters U and J and a selection of different > double > >counting terms, all reflecting diferent physics. > >Third, unlike LDA, it has much more often > metastable > >solutions which are not the ground state, but can > be > >easily mistaken for one. For these reasons, before > >indulging in LDA+U calculations even a highly > >qualified theorist, in my opininon, should > thoroughly > >study the literature and the theory of correlated > >systems, to have a clear idea what kind of physics > he > >or she expects to describe using LDA+U, and WHY > this > >physics requires specifically LDA+U approach. > > > >Good luck. > >Igor > > > >===== > > > > > >__________________________________________________ > >Do You Yahoo!? > >HotJobs - Search Thousands of New Jobs > >http://www.hotjobs.com > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > > > Although it is beloved that LDA+U is not a pure ab > initio calculation, it is > still an all electronic calculation. It is not as we > add an extra potential > and so mix the initial DFT Hamiltonian with a given > term of a model > Hamiltonian. It is still as the system under LDA+U > study should not be > charged or inversely discharged by electrons. Thus, > the total number of > electrons must within LDA+U remains constant > changing the U value from zero > to any other positive value. Therefore, one would > first check this role > integrating from the total DOS in the valence bands > and semicore bands, > analyze total :QTL value, or look at in2 file. After > this, one would look at > inc file to find the number of core electrons, and > then plus it to total > number of valence electrons (semi core + valence). I > am sure it will rich a > same value both for U=0 and U<>0, as number of > electrons is independent of U > value. But Tomas, please consider this fact that U > may change the bands > drastically depending on how the system is strongly > correlated, as it is its > task to rich what DOS's or physics one is looking > for. > > Your, > S. Jalali. > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 11:34:30 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: TEMP-TETRA option / question for IGOR MAZIN ==== Igor Mazin submitted the following contribution: ==== - --- Fabian Dominguez wrote: > ==== > Fabian Dominguez > submitted the following contribution: > ==== > > > In a previous WIEN mails I saw thar somebody was > told to use TEMP option, > BUT finally convergence MUST be got using TETRA, Is > this true? or I can do Yes. > It's necessary to say now I'm doing a running of > NdFeB but with TETRA, and > apparently nothing strange happens, I mean > oscilations.. Sure. If you use temp smearing, you converge faster and smoother, but to a wrong result. The more wrong the larger T, and the better convergence the larger T. Fermi or Gauss, does not matter. There were many papers on this, for instance Paxton and Methfessel around 1990. ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 13:08:25 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== - --- Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > As far as I remember, it is recommended by the > authors to use LDA for LDA+U > calculation and not any more advanced extended > approximations for the > exchange correlation potential. This says that one > should not compare GGA+U > with GGA I do not see any reason why not. > better to wait to see if Igor would give us some > insights in this respect. Thanks, but I have none. My earlier question was irrelevant. With U that small it should not matter whatsoever whether you put -orb in or not. Case.scf has Fermi energy in it, from iteration to iteration. Make several iterations with U=0.0001 and J=0.0001 and then one without -orb. If you are converged, nothing should change, including Fermi. If this is so, but your bands are plotted with an incorrect Ef, you will know were to look then. Igor > Your, > S. Jalali. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 15 Aug 2002 11:38:08 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Two questions ==== "Saeid Jalali" submitted the following contribution: ==== > > As far as I remember, it is recommended by the > > authors to use LDA for LDA+U > > calculation and not any more advanced extended > > approximations for the > > exchange correlation potential. This says that one > > should not compare GGA+U > > with GGA > I do not see any reason why not. Let's below give it a try: Basically, taking the LDA+U into account, (T+Vei+VH+VXC+VLDA+U) ji = ei ji , and comparing obtained total energy with the regular DFT equation, where the later LDA+U potential is not there, allows to utilize any versions of exchange correlation approximations. This means that in general comparing GGA+U and GGA is also permitted. Why it is recommended to only use LDA turning on the light of U, maybe is to not take into account further correction in correlation potential. This means that any correlation corrections have been entrusted to U and J parameters. Using GGA+U leads to a U which may differ from the U value obtained via LDA+U. Thus maybe to find a U and a J for a case at least employing wien code it is recommended to use one version of exchange correlation potential which is selected to be LDA by the wien author. Although U and J are considered as external parameters, they are not so far from experiment within LDA. > Case.scf has Fermi energy in it, from iteration to > iteration. Make several iterations with U=0.0001 and > J=0.0001 and then one without -orb. If you are > converged, nothing should change, including Fermi. > > If this is so, but your bands are plotted with an > incorrect Ef, you will know were to look then. Here you touch a good point, and Thomas would pay attention to put manually the correct Ef from the last iteration: grepline :FER *.scf 1. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #31 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #32 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, August 23 2002 Volume 2002 : Number 032 ---------------------------------------------------------------------- Date: Thu, 15 Aug 2002 08:20:12 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: can antiferromagnetic be mimicked by U? ==== Igor Mazin submitted the following contribution: ==== > "Saeid Jalali" > submitted the following contribution: > ==== > It is shown that TOTMM of FeAl within LDA+(U=5eV) > calculation drops to zero > from the value obtained, 0.73mB, within LDA+(U=0) > calculation. Correct. > It is an indication of LDA+U capability to predict > paramagnetic behavior which is in > excellent agreement with experiment Not really. This is an indication that a particular implementation of LDA+U accidentally has a regime (for an unphysically large U) where the nonmagnetic solution is lower in energy. In LDA-ASA+U, which is likely better than LAPW+U for FeAl, due to close packing and only moderate localization of Fe d's, the region of nonmagnetic ground state disappears (Andre Petukhov, unpublished). DMFT calculations stabilize the nonmagnetic state for FeAl at reasonable U's, independent of implementation, and without DOS reduction (Lichtenstein and Chioncel, unpublished, partially included in the cond-mat below). More in http://www.arxiv.org/abs/cond-mat/0206548. "There is infinite number of incorrect theories, correctly describing a finite number of correct experiments" - Bohr. > suppose it is an > antiferromagnetic system at low temperature with a > small moment around > 0.2mB. So to calculate low temperature properties, > one would first make a > super cell with a known oriented spin directions > classifying/indexing > equivalent atoms to non equivalent atoms to > reproduce the experimental > values changing the external U parameter. This is > one natural way, but I am This the right way, except U should not, generally speaking, be used as an adjustable parameter (there are exceptions, though). At least not outside a reasonable range given, say, by constrained DFT calculations of Anisimov-Gunnarsson type, or similar. > not sure if the following way also is a reasonable > physical way or not: Not. First, all physics associated with the superexchange, usually of utmost importance, is lost this way. Second, U is not an adjustable parameter. It is a prameter which is difficult to calculate, but it does not mean one is permitted to use it as a knob disregarding its physical meaning. > Instead of making antiferromagnetic super cell, > going through the problem > ferromagnetically within the primitive cell without > assuming any initial > spin directions just changing the U value to > regenerate the small > experimental moment. Then, keeping the obtained U > value, try to find another > physical quantity taking still the ferromagnetic > treatment into account. > Please notice that the obtained U values within > antiferromagnetic and > ferromagnetic treatments can be different. I do not understand either of these following questions. > > Now my two questions are as follows: > > Can the obtained U value of a natural > antiferromagnetic system within a > ferromagneticaly magnetic moment calculation mimic > the antiferromagnetic > situation? > > Can the obtained U value of a natural > antiferromagnetic system within a > ferromagneticaly magnetic moment calculation mimic > the paramagnetic > situation considering the small moment 0.2mB? This > means that can the > calculation be extended to the room temperature? > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 16 Aug 2002 07:23:10 -0700 (PDT) From: Ivan Oleynik Subject: Re: [WIEN]: intel IFC compiler ==== Ivan Oleynik submitted the following contribution: ==== Go to http://www.intel.com/software/products/compilers/ They provide free unsupported licenses for C++ and Fortran compilers for academics. - --- Luiz Alberto Terrazo wrote: > ==== > Luiz Alberto Terrazo > submitted the following contribution: > ==== > > Dear Wien users > I installed the wien2k code in a cluster machine (PIII) with > Linux . I would like to know where I can download the IFC > intel compiler. > best regards > luis > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 16 Aug 2002 07:43:04 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== 1. I did not find anywhere any recommendation from the authors of WIEN2k not to use GGA with U. 2. I would be surprised to find one, for Vienna people just started with LDA+U and if from anywhere, I'd expect practical recommendation of this sort from Ekaterinburg group etc. 3. I am not aware of any statistics showing GGA+U to be more inferior/superior to LDA+U than GGA to LDA. 4. If such statistics existed, it'd be strange, for GGA and +U strive to correct entirely different and unrelated deficiencies in LDA. It does not mean I say it is impossible, just it'd be unexpected, and I never heard about such situation being systematically observed. I myself did GGA+U with WIEN2k and did not not notice any problem. - --- Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > > As far as I remember, it is recommended by the > > > authors to use LDA for LDA+U > > > calculation and not any more advanced extended > > > approximations for the > > > exchange correlation potential. This says that > one > > > should not compare GGA+U > > > with GGA > > > I do not see any reason why not. > Let's below give it a try: > Basically, taking the LDA+U into account, > (T+Vei+VH+VXC+VLDA+U) ji = ei ji , > and comparing obtained total energy with the regular > DFT equation, where the > later LDA+U potential is not there, allows to > utilize any versions of > exchange correlation approximations. This means that > in general comparing > GGA+U and GGA is also permitted. Why it is > recommended to only use LDA > turning on the light of U, maybe is to not take into > account further > correction in correlation potential. This means that > any correlation > corrections have been entrusted to U and J > parameters. Using GGA+U leads to > a U which may differ from the U value obtained via > LDA+U. Thus maybe to find > a U and a J for a case at least employing wien code > it is recommended to use > one version of exchange correlation potential which > is selected to be LDA by > the wien author. Although U and J are considered as > external parameters, > they are not so far from experiment within LDA. > > > Case.scf has Fermi energy in it, from iteration to > > iteration. Make several iterations with U=0.0001 > and > > J=0.0001 and then one without -orb. If you are > > converged, nothing should change, including Fermi. > > > > If this is so, but your bands are plotted with an > > incorrect Ef, you will know were to look then. > > Here you touch a good point, and Thomas would pay > attention to put manually > the correct Ef from the last iteration: grepline > :FER *.scf 1. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 16 Aug 2002 02:12:26 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: Two questions ==== "Saeid Jalali" submitted the following contribution: ==== > 3. I am not aware of any statistics showing GGA+U to > be more inferior/superior to LDA+U than GGA to LDA. > 4. If such statistics existed, it'd be strange, for > GGA and +U strive to correct entirely different and > unrelated deficiencies in LDA. It'd be strange for striving of neither GGA nor +U, as GGA calculation is an ab initio calculation but +U calculation. For more realization, one would consider an ideal case and suppose that there is an exact analytical expression for the exchange correlation potential, say Vxc, but still would keep the +U potential, say Vexact+u. Now in this ideal case with exact Vxc keeping V_(exact+u), one may ask what the U and J values are and would know what the difference between V_(lda+u) and V_(exact+u) is. It'd be surprised too if one says that after a self consistent calculation within such a Vxc+V_(exact+u) calculation the values of U and J can remain those used values in Vlda+V_(lda+u) calculation with one expression for V(+u) potential. It is obvious that U and J are two physical quantities referring to splitting of lower and upper bands: U+6J, but they depend on our interpration: model we are using. Please let me ask you a question: What will be your further attempts to put your model U-potential into the regular Kohen-Sham equation when you are going from LDA to GGA? If the answer is nothing, so how can the further correction of GGA be compensated by a fixed model U-potential? Else, I am interested to know that further attempts. Although I am not an expert and afraid to come closer, but I would say that: The story of +U is different from GGA or other systematic approximations for exchange-correlation potential. In one sight, U is coming to improve LDA, but in the other hand U is attacking to the original concept of density functional theory, as U is bringing with itself a new guest, Yankee, for DFT to show DFT should be replaced by a model Hamiltonian which is another approach. One may believe that U cannot be instead of stoner I. Stoner I is less than U: I=~0.1*U. But this is in LDA. This means that if one can improve LDA systematically, then stoner I will be again instead of U. As far as I know many are trying successfully to improve LDA systematically, see M. Nekovee, W. M. C. Foulkes, and R. J. Needs Phys. Rev. Lett. 87, 036401 (2001), http://link.aps.org/doi/10.1103/PhysRevLett.87.036401 . So, we can wait to see. > It does not mean I say > it is impossible, just it'd be unexpected, and I never > heard about such situation being systematically > observed. I don't understand what you want to say here. > I myself did GGA+U with WIEN2k and did not > not notice any problem. I saw that in your SmZn case (GGA92 but not 13!), and would like here to appreciate you a lot for those files. > 1. I did not find anywhere any recommendation from the > authors of WIEN2k not to use GGA with U. I heard this. > 2. I would be surprised to find one, for Vienna people > just started with LDA+U and if from anywhere, I'd > expect practical recommendation of this sort from > Ekaterinburg group etc. Your, S. Jalali PS: I am reading your recent submitted letter: cond-mat/0206548, thank you for that! ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 16 Aug 2002 16:03:12 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== Saeid, You touched upon several serious conceptual problems of the LDA+U and of the DFT. I believe that many of your thoughts are in the right direction, but this is probably not an appropriate topic for a discussion board like ours. Maybe we will have chance in the future to talk about this in person. I realize this is a remote prospective for you in Iran; unfortunately, there are things beyond our control. But the future may be brighter than we think. Limiting ourselves to simpler issues, given loose and shaky foundation of the LDA+U formalism, the difference between LDA and GGA seems, to me, of very secondary importance, and not worth more profound consideration. - --- Saeid Jalali wrote: > > heard about such situation being systematically > > observed. > I don't understand what you want to say here. Just that there is no practical evidence that GGA+U is worse than LDA+U. Good luck, Igor ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 18 Aug 2002 14:10:35 +0800 From: Wenhui Xie Subject: [WIEN]: The problem in compiling lapw1_mpi ==== Wenhui Xie submitted the following contribution: ==== Dear Wien Users, Please help me to find the problem in parallel compiling. I am compiling WIEN2K in a 2-P4(XEON) CPU computer. The mahterboard is Tyan S2720(shipset INTEL E7500) The lib MPI+SCALAPACK+BLACS have been installed, and the BLAS lib is pgf3.2 libblas.a, OS is LINUX REDHAT7.3 Fortran compiler is pgi3.2. Some config informations are listed below: 1.The config paramater for MPI ./configure --with-device=ch_shmem -prefix=/usr/local/mpich - --with-comm-prefix=/usr/local/mpich -c++=pgCC -cc=pgcc -fc=pgf77 - -cflags="-Msignextend" -opt=-fast -fflags="-fast -Kieee" - -c++flags="-fast -Kieee" -f90flags="-fast -Kieee" -f90=pgf90 - -prefix=/usr/local/mpich 2.The Bmake.inc file to build BLACS lib SHELL = /bin/sh BTOPdir = /usr/local/BLACS COMMLIB = MPI PLAT = LINUX BLACSdir = $(BTOPdir)/LIB BLACSDBGLVL = 0 BLACSFINIT = $(BLACSdir)/blacsF77init_$(COMMLIB)-$(PLAT)-$(BLACSDBGLVL).a BLACSCINIT = $(BLACSdir)/blacsCinit_$(COMMLIB)-$(PLAT)-$(BLACSDBGLVL).a BLACSLIB = $(BLACSdir)/blacs_$(COMMLIB)-$(PLAT)-$(BLACSDBGLVL).a MPIdir = /usr/local/mpich MPILIBdir = $(MPIdir)/lib MPIINCdir = $(MPIdir)/include MPILIB = $(MPILIBdir)/libmpich.a BTLIBS = $(BLACSFINIT) $(BLACSLIB) $(BLACSFINIT) $(MPILIB) INSTdir = $(BTOPdir)/INSTALL/EXE TESTdir = $(BTOPdir)/TESTING/EXE FTESTexe = $(TESTdir)/xFbtest_$(COMMLIB)-$(PLAT)-$(BLACSDBGLVL) CTESTexe = $(TESTdir)/xCbtest_$(COMMLIB)-$(PLAT)-$(BLACSDBGLVL) SYSINC = -I$(MPIINCdir) INTFACE = -DAdd_ SENDIS = BUFF = TRANSCOMM = WHATMPI = SYSERRORS = DEBUGLVL = -DBlacsDebugLvl=$(BLACSDBGLVL) DEFS1 = -DSYSINC $(SYSINC) $(INTFACE) $(DEFBSTOP) $(DEFCOMBTOP) $(DEBUGLVL) BLACSDEFS = $(DEFS1) $(SENDIS) $(BUFF) $(TRANSCOMM) $(WHATMPI) $(SYSERRORS) F77 = pgf77 F77NO_OPTFLAGS = F77FLAGS = $(F77NO_OPTFLAGS) -fast -Kieee F77LOADER = $(F77) F77LOADFLAGS = CC = pgcc CCFLAGS = -fast -Kieee CCLOADER = $(CC) CCLOADFLAGS = ARCH = ar ARCHFLAGS = r RANLIB = ranlib 3.The SLmake.inc file used to build SCALAPACK Lib SHELL = /bin/sh home = /usr/local/SCALAPACK PLAT = LINUX BLACSDBGLVL = 0 BLACSdir = /usr/local/BLACS/LIB USEMPI = -DUsingMpiBlacs SMPLIB = /usr/local/mpich/lib/libmpich.a BLACSFINIT = $(BLACSdir)/blacsF77init_MPI-$(PLAT)-$(BLACSDBGLVL).a BLACSCINIT = $(BLACSdir)/blacsCinit_MPI-$(PLAT)-$(BLACSDBGLVL).a BLACSLIB = $(BLACSdir)/blacs_MPI-$(PLAT)-$(BLACSDBGLVL).a TESTINGdir = $(home)/TESTING CBLACSLIB = $(BLACSCINIT) $(BLACSLIB) $(BLACSCINIT) FBLACSLIB = $(BLACSFINIT) $(BLACSLIB) $(BLACSFINIT) PBLASdir = $(home)/PBLAS SRCdir = $(home)/SRC TESTdir = $(home)/TESTING PBLASTSTdir = $(TESTINGdir) TOOLSdir = $(home)/TOOLS REDISTdir = $(home)/REDIST REDISTTSTdir = $(TESTINGdir) F77 = mpif77 CC = mpicc NOOPT = F77FLAGS = -fast -Kieee DRVOPTS = $(F77FLAGS) CCFLAGS = -fast -Kieee SRCFLAG = F77LOADER = $(F77) CCLOADER = $(CC) F77LOADFLAGS = CCLOADFLAGS = CDEFS = -DAdd_ -DNO_IEEE $(USEMPI) ARCH = ar ARCHFLAGS = cr RANLIB = ranlib SCALAPACKLIB = $(home)/libscalapack.a BLASLIB = /usr/local/pgi/linux86/lib/libblas.a PBLIBS = $(SCALAPACKLIB) $(FBLACSLIB) $(BLASLIB) $(SMPLIB) PRLIBS = $(SCALAPACKLIB) $(CBLACSLIB) $(SMPLIB) RLIBS = $(SCALAPACKLIB) $(FBLACSLIB) $(CBLACSLIB) $(BLASLIB) $(SMPLIB) LIBS = $(PBLIBS) 4. the compiler parameter of WIEN2k Current settings: RP RP_LIB(SCALAPACK+PBLAS): /usr/local/mpich/lib/libmpich.a /usr/local/SCALAPACK/libscalapack.a /usr/local/BLACS/LIB/blacs_MPI-LINUX-0.a /usr/local/BLACS/LIB/blacsF77init_MPI-LINUX-0.a FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee MP MPIRUN commando : mpirun -np 4 -machinefile .machine executable 5. the error information given by wien2k installer: mpif90 -o ./lapw1c_mpi abc.o atpar.o bandv1.o calkpt.o cbcomb.o coors.o cputim.o dblr2k.o dgeqrl.o dgewy.o dgewyg.o dlbrfg.o dsbein1.o dscgst.o dstebz2.o dsyevx2.o dsymm2.o dsyr2m.o dsyrb4.o dsyrb5l.o dsyrdt4.o dsytrd2.o dsywyv.o dsyxev4.o dvbes1.o eisps.o errclr.o errflg.o forfhs.o gaunt1.o gaunt2.o gbass.o gtfnam.o hamilt.o hns.o horb.o inikpt.o inilpw.o lapw1.o latgen.o lmsort.o locdef.o lohns.o lopw.o matmm.o modules.o nn.o outerr.o outwin.o pdsyevx16.o prtkpt.o prtres.o pzheevx16.o rdswar.o rint13.o rotate.o rotdef.o seclit.o seclr4.o seclr5.o select.o service.o setkpt.o setwar.o sphbes.o stern.o tapewf.o ustphx.o vectf.o warpin.o wfpnt.o wfpnt1.o ylm.o zhcgst.o zheevx2.o zhemm2.o zher2m.o zhetrd2.o pdsyr2m.o pzher2m.o - -L../SRC_lib -llapack_lapw -lblas /usr/local/mpich/lib/libmpich.a /usr/local/SCALAPACK/libscalapack.a /usr/local/BLACS/LIB/blacs_MPI-LINUX-0.a /usr/local/BLACS/LIB/blacsF77init_MPI-LINUX-0.a /usr/local/SCALAPACK/libscalapack.a(PB_Cdtypeset.o): In function `PB_Cdtypeset': PB_Cdtypeset.o(.text+0x1f4): undefined reference to `dsyr_' /usr/local/SCALAPACK/libscalapack.a(PB_Cztypeset.o): In function `PB_Cztypeset': PB_Cztypeset.o(.text+0x21f): undefined reference to `zgeru_' PB_Cztypeset.o(.text+0x235): undefined reference to `zher_' PB_Cztypeset.o(.text+0x25f): undefined reference to `zsymm_' PB_Cztypeset.o(.text+0x275): undefined reference to `zsyrk_' PB_Cztypeset.o(.text+0x28a): undefined reference to `zsyr2k_' /usr/local/SCALAPACK/libscalapack.a(zvvdotu.o): In function `zvvdotu_': zvvdotu.o(.text+0x47): undefined reference to `zdotu_' /usr/local/BLACS/LIB/blacsF77init_MPI-LINUX-0.a(blacs_pinfo_.o): In function `blacs_pinfo_': blacs_pinfo_.o(.text+0x37): undefined reference to `bi_f77_init_' blacs_pinfo_.o(.text+0x82): undefined reference to `bi_f77_get_constants_' /usr/local/BLACS/LIB/blacsF77init_MPI-LINUX-0.a(Cblacs_pinfo.o): In function `Cblacs_pinfo': Cblacs_pinfo.o(.text+0x37): undefined reference to `bi_f77_init_' Thanks very much. Look forward to your reply! Yours Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 18 Aug 2002 10:38:58 +0200 (MET DST) From: Pavel Novak Subject: Re: [WIEN]: Two questions ==== Pavel Novak submitted the following contribution: ==== Dear Saeid and Igor, from our experience follows that GGA contains more correlation than LDA. As a consequence using GGA+U (U=UGGA) would give, as a rule, similar results as LDA+U (U=ULDA) for UGGA ==== > Igor Mazin > submitted the following contribution: > ==== > > 1. I did not find anywhere any recommendation from the > authors of WIEN2k not to use GGA with U. > 2. I would be surprised to find one, for Vienna people > just started with LDA+U and if from anywhere, I'd > expect practical recommendation of this sort from > Ekaterinburg group etc. > 3. I am not aware of any statistics showing GGA+U to > be more inferior/superior to LDA+U than GGA to LDA. > 4. If such statistics existed, it'd be strange, for > GGA and +U strive to correct entirely different and > unrelated deficiencies in LDA. It does not mean I say > it is impossible, just it'd be unexpected, and I never > heard about such situation being systematically > observed. I myself did GGA+U with WIEN2k and did not > not notice any problem. > > --- Saeid Jalali wrote: > > ==== > > "Saeid Jalali" > > submitted the following contribution: > > ==== > > > > > > As far as I remember, it is recommended by the > > > > authors to use LDA for LDA+U > > > > calculation and not any more advanced extended > > > > approximations for the > > > > exchange correlation potential. This says that > > one > > > > should not compare GGA+U > > > > with GGA > > > > > I do not see any reason why not. > > Let's below give it a try: > > Basically, taking the LDA+U into account, > > (T+Vei+VH+VXC+VLDA+U) ji = ei ji , > > and comparing obtained total energy with the regular > > DFT equation, where the > > later LDA+U potential is not there, allows to > > utilize any versions of > > exchange correlation approximations. This means that > > in general comparing > > GGA+U and GGA is also permitted. Why it is > > recommended to only use LDA > > turning on the light of U, maybe is to not take into > > account further > > correction in correlation potential. This means that > > any correlation > > corrections have been entrusted to U and J > > parameters. Using GGA+U leads to > > a U which may differ from the U value obtained via > > LDA+U. Thus maybe to find > > a U and a J for a case at least employing wien code > > it is recommended to use > > one version of exchange correlation potential which > > is selected to be LDA by > > the wien author. Although U and J are considered as > > external parameters, > > they are not so far from experiment within LDA. > > > > > Case.scf has Fermi energy in it, from iteration to > > > iteration. Make several iterations with U=0.0001 > > and > > > J=0.0001 and then one without -orb. If you are > > > converged, nothing should change, including Fermi. > > > > > > If this is so, but your bands are plotted with an > > > incorrect Ef, you will know were to look then. > > > > Here you touch a good point, and Thomas would pay > > attention to put manually > > the correct Ef from the last iteration: grepline > > :FER *.scf 1. > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > ===== > ***************************************************************************** > Igor Mazin, Naval Research Laboratory, Washington, DC 20375 > Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin > ***************************************************************************** > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 17:01:05 +0800 From: gyguo Subject: [WIEN]: LDA+U for systems without inversion symmetry ==== gyguo submitted the following contribution: ==== Dear Prof. Blaha and WIEN users, We have been trying to perform LDA+U calculations without SO for systems without inversion symmetry, and we have failed. We have used both runsp_lapw -orb and runsp_c_lapw -orb. I think that the problem is due to the fact that lapwdm -dn -c is not executed, as one can see from the 'dayfile' and 'error message' enclosed below. We have no problem for systems with inversion symmetry or for LDA+U+SO calculations. I don't know runsp_lapw and x_lapw well enough to modify it. Could anyone modify runsp_lapw and x_lapw so that we can do LDA+U calculations for systems without inversion symmetry (no SO) in both serial and parallel executions? Thank you very much in advance. Regards, Guang-Yu Guo - ---------------- dayfile - ------------------------------------------------------------------------ start (Sat Aug 17 16:17:44 CST 2002) with lapw0 (20/20 to go) > lapw0 (16:17:44) 48.210u 0.560s 0:50.68 96.2% 0+0k 0+0io 274pf+0w > lapw1 -c -up -orb (16:18:35) 1649.100u 20.790s 27:56.19 99.6% 0+0k 0+0io 390pf+0w > lapw2 -c -up (16:46:32) 118.960u 7.450s 2:14.88 93.7% 0+0k 0+0 io 318pf+0w > lapw2 -c -dn (16:48:47) 61.270u 3.420s 1:05.48 98.7% 0+0k 0+0io 316pf +0w > lapwdm -up -c (16:49:53) 2.600u 0.870s 0:04.00 86.7% 0+0k 0+0io 233pf +0w > lcore -up (16:49:57) 0.580u 0.010s 0:00.71 83.0% 0+0k 0+0io 176pf+0w > lcore -dn (16:49:58) 0.600u 0.000s 0:00.63 95.2% 0+0k 0+0io 176pf+0w > mixer (16:49:59) 6.730u 0.450s 0:10.18 70.5% 0+0k 0+0io 201pf+0w :ENERGY convergence: 0 0 1.2786595000000000 :CHARGE convergence: 0 0.00001 .5435234 - ------------------- error message - ------------------------------------------------------------ LAPW0 END LAPW1 END LAPW2 END LAPW2 END lapwdm END total_exec: Command not found. CORE END CORE END MIXER END in cycle 2 ETEST: 1.2786595000000000 CTEST: .5435234 LAPW0 END PGFIO-F-217/list-directed read/unit=9/attempt to read past end of file. File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 In source file init.f, at line number 226 PGFIO-F-217/list-directed read/unit=10/attempt to read past end of file. File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 In source file init.f, at line number 226 LAPW1 END LAPW2 END LAPW2 END lapwdm END - -- Dr. G.Y. Guo Professor Department of Physics National Taiwan University 1 Roosevelt Road, Sec. 4 Taipei 106, Taiwan, R.O.C. Tel. ++886-2-33665180 Fax. ++886-2-23639984 E-mail: gyguo@phys.ntu.edu.tw ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 18:26:28 +0800 From: gyguo Subject: [WIEN]: errors from lapwdm in parallel ==== gyguo submitted the following contribution: ==== Dear Prof. Blaha and WIEN users, We found that lapwdm does not work in parallel, as shown in the following error message. We use a PC cluster with MPI and PGI compiler. We did go into the SRC_lapwdm directory, trying to solve the problem. However, we cannot find the 'dmatscf.f' program. Any help to solve the problem will be highly appreciated. Regards, Guang-Yu Guo - -------- error message --------------------------------------- x lapwdm -so -up -p running LAPWDM in parallel mode [1] 17142 [2] 17157 [3] 17179 [4] 17184 [5] 17189 [6] 17195 [7] 17226 lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END [7] Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [6] - Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [5] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [4] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [3] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [2] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [1] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... node10 4.970u 0.370s 0:26.09 20.4% 0+0k 0+0io 235pf+0w node11 5.020u 0.390s 0:27.77 19.4% 0+0k 0+0io 234pf+0w node12 4.950u 0.400s 0:27.04 19.7% 0+0k 0+0io 235pf+0w node13 5.090u 0.280s 0:26.56 20.2% 0+0k 0+0io 235pf+0w node14 5.040u 0.320s 0:26.09 20.5% 0+0k 0+0io 235pf+0w node15 4.940u 0.320s 0:25.32 20.7% 0+0k 0+0io 235pf+0w node16 4.970u 0.330s 0:24.48 21.6% 0+0k 0+0io 235pf+0w Summary of lapwdmpara: node10 user=4.97 wallclock=26.09 node11 user=5.02 wallclock=27.77 node12 user=4.95 wallclock=27.04 node13 user=5.09 wallclock=26.56 node14 user=5.04 wallclock=26.09 node15 user=4.94 wallclock=25.32 node16 user=4.97 wallclock=24.48 PGFIO-F-231/formatted read/internal file/error on data conversion. In source file dmatscf.f, at line number 69 35.220u 2.680s 0:32.19 117.7% 0+0k 0+0io 26239pf+0w - -- Dr. G.Y. Guo Professor Department of Physics National Taiwan University 1 Roosevelt Road, Sec. 4 Taipei 106, Taiwan, R.O.C. Tel. ++886-2-33665180 Fax. ++886-2-23639984 E-mail: gyguo@phys.ntu.edu.tw ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 14:39:38 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: LDA+U for systems without inversion symmetry ==== Peter Blaha submitted the following contribution: ==== > We have been trying to perform LDA+U calculations without SO > for systems without inversion symmetry, and we have failed. > We have used both runsp_lapw -orb and runsp_c_lapw -orb. > I think that the problem is due to the fact that lapwdm -dn -c > is not executed, as one can see from the 'dayfile' and 'error message' > enclosed below. We have no problem for systems with inversion > symmetry or for LDA+U+SO calculations. I don't know runsp_lapw > and x_lapw well enough to modify it. > > Could anyone modify runsp_lapw and x_lapw so that we can > do LDA+U calculations for systems without inversion symmetry > (no SO) in both serial and parallel executions? Please download the latest WIEN2k versions. These problems have been fixed some time ago. 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 10:13:47 -0400 From: gpzhang Subject: [WIEN]: problem with band structure ==== gpzhang submitted the following contribution: ==== Dear Wien Users and Developers, I thought that I know how to calculate the band structure with wien97, but clearly not. I tried several different schemes but failed. So, I wonder whether you could help me. I succeeded to calculate TiC and MgB2 band structures, but when I tried to calculate the potassium vanadate, the band structure looks messy, meaning that the lines do not form a clear continuous curve. I should note that my present compound has no inversion symmetry and appears a little frustrated. Here is what I did. I first created a special K-list and attached it to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, is there a way to run this in parallel? The code complains if I do x lapw1 -c -p). After I finished it, I edited case.insp by inserting Ef (from case.scf). Then do x spaghetti -c. I got an error message like `1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io 21pf+0w RETURN key to continue ...' In addition, I found that my case.qtl has zero bytes in it. I can attach both case.klist and case.spaghetti_ps if necessary though both files are big. Many thanks in advance! Guoping ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 09:49:45 -0700 From: "Saeid Jalali" Subject: [WIEN]: bct-U ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_003A_01C24765.BF944730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, There was a discussion in the mailing-list some times ago about the = bct-U (a=3Db=3D7.5 au, c=3D8.5 au). Since the problem was not closed = clearly, I worked on it as my interesting subject and would like here to = share the results to use your possibly expert comments. First, let's = below paste the discussion to see/remember the problem: ">I tried exactly the same now (bct-U, a=3Db=3D7.5 au, c=3D8.5=20 > au, case.inm=3D0.1+BROYD, U=3D0.45 Ry, J=3D0.05 Ry) with the newest = version. I used=20 > RKM=3D7 and 99 k-points in IBZ (not much, just to see whether it = works). These=20 > cases converge both with and without -orb (in both cases -so is used). = It=20 > takes many iterations however (>250). Are these results comparable = with what=20 > you found : >=20 > :HFF01 :MMI01 :EFG01 > -so -in1new 1 -283.949 2.64145 6.15215 > -so -in1new 1 -orb -39.481 0.00698 1.93274=20 Actually I get rather different results. I've attached scf files from = the three runs. Maybe you'll find the differences. My calculations converge in just 20 cycles. I used only 18 k-points so maybe it's because of k-mesh, but the differences seem to be to big.=20 I can only think of two things 1) Try not using the -in1new switch. The standard scheme should be ok = for a case like this. 2) Try changing your inst to=20 U=20 Rn 3 5=20 5, 3,3.0 N=20 5, 3,0.0 N=20 6, 2,0.5 N=20 6, 2,0.5 N=20 7,-1,1.0 N=20 7,-1,1.0 N ****=20 When you start from a configuration where only the f-electrons are spin polarized sometimes improves convergence tremendiously." So, you see the problem is to obtain different results by two individual = expert persons. Comparing the above reported results of (:HFF01, :MMI01, = :EFG01) Shows that there are also dramatic differences between the = results before and after adding -orb switch, which is expectable after = 250 iterations. Here we believe that the role of -so is marginal for = this problem. Hence, we go through the problem using the default = parameters of wien2k_02 (updated 30-July-2002) and get the following = self-consistent results: 1) runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE37)=3D=3D> :HFF01=3D-404.991,:MMI01=3D1.50924,:EFG01=3D3.38281. 2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE24)=3D=3D> :HFF01=3D0.000,:MMI01=3D0.00000,:EFG01=3D-7.62824. 3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested = case.inst; (:ITE21)=3D=3D> :HFF01=3D0.000,:MMI01=3D0.00001,:EFG01=3D-7.55947. 4) run_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE13)=3D=3D> :HFF01=3D---,:MMI01=3D---,:EFG01=3D3.26087. 5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE=3D13)=3D=3D> :HFF01=3D-350.370,:MMI01=3D1.95919,:EFG01=3D+7.04996. Now my questions are as follows: 1.Why the calculated EFG within step 1 (imposing magnetic) and 2 = (forcing zero magnet) are not alike with identical initial conditions, = same case.indmup&dn for each cases regarding the same EFG's within step1 = and 4? The later same EFG's (comparing 1 and 4) show that the EFG has not been = substantially affected by -orb and sp (spin-polarization). But Steps 4 = and 5 show the effect of sp! Step 2 and 3 show the suggestion about = case.inst is not the case. From 2 and 4 we also see the effect of U = parameter. 2.Why these counted evidences are not agree with each other? Anyway, I am at least willing to inform that all my calculations are = well converged in a few iterations in contrast to the 250 reported = iterations: maybe due to the latest wien2k version. In addition such = substantially different reported results with and without -orb are not = observed. Thank you for your attention in this respect, Your, S. Jalali. - ------=_NextPart_000_003A_01C24765.BF944730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
There was a discussion in the = mailing-list some=20 times ago about the bct-U (a=3Db=3D7.5 au, c=3D8.5 au). Since the = problem was not=20 closed clearly, I worked on it as my interesting subject and would like = here to=20 share the results to use your possibly expert comments. First, let's = below paste=20 the discussion to see/remember the problem:
 
">I tried exactly the same now = (bct-U, a=3Db=3D7.5=20 au, c=3D8.5
> au, case.inm=3D0.1+BROYD, U=3D0.45 Ry, J=3D0.05 Ry) = with the newest=20 version. I used
> RKM=3D7 and 99 k-points in IBZ (not much, just = to see=20 whether it works). These
> cases converge both with and without = - -orb (in=20 both cases -so is used). It
> takes many iterations however = (>250).=20 Are these results comparable with what
> you found :
> =
>=20 :HFF01 :MMI01 :EFG01
> -so -in1new 1 -283.949 2.64145 = 6.15215
> -so=20 - -in1new 1 -orb -39.481 0.00698 1.93274
Actually I get rather = different=20 results. I've attached scf files from the
three runs. Maybe you'll = find the=20 differences.
My calculations converge in just 20 cycles. I used only = 18=20 k-points so
maybe it's because of k-mesh, but the differences seem to = be to=20 big.
I can only think of two things
1) Try not using the -in1new = switch.=20 The standard scheme should be ok for
a case like this.
 
2) Try changing your inst to
U =
Rn 3 5=20
5, 3,3.0 N
5, 3,0.0 N
6, 2,0.5 N
6, 2,0.5 N
7,-1,1.0 = N=20
7,-1,1.0 N
****
When you start from a configuration where = only the=20 f-electrons are spin
polarized sometimes improves convergence=20 tremendiously."
 

So, you see the problem is to obtain different results by two=20 individual expert persons. Comparing the above reported results of = (:HFF01,=20 :MMI01, :EFG01) Shows that there are also dramatic differences between = the=20 results before and after adding -orb switch, which is expectable after = 250=20 iterations. Here we believe that the role of -so is marginal for this = problem.=20 Hence, we go through the problem using the default parameters of = wien2k_02=20 (updated 30-July-2002) and get the following self-consistent = results:
1)=20 runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE37)=3D=3D>
:HFF01=3D-404.991,:MMI01=3D1.50924,:EFG01=3D3.38281= .
 
2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE24)=3D=3D>
:HFF01=3D0.000,:MMI01=3D0.00000,:EFG01=3D-7.62824.<= /DIV>
 
3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested=20 case.inst; =20 (:ITE21)=3D=3D>
:HFF01=3D0.000,:MMI01=3D0.00001,:EFG01=3D-7.55947.<= /DIV>
 
4) run_lapw -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE13)=3D=3D>
:HFF01=3D---,:MMI01=3D---,:EFG01=3D3.26087.
 
5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE=3D13)=3D=3D>
:HFF01=3D-350.370,:MMI01=3D1.95919,:EFG01=3D+7.0= 4996.
 
Now my questions are as follows:
 
1.Why the calculated EFG within step 1 (imposing magnetic) = and 2=20 (forcing zero magnet) are not alike with identical initial = conditions,=20 same case.indmup&dn for each cases regarding the same EFG's = within=20 step1 and 4?
 
The later same EFG's (comparing 1 and 4) show that the EFG has=20 not been substantially affected by -orb and sp (spin-polarization). = But=20 Steps 4 and 5 show the effect of sp! Step 2 and 3 show the = suggestion about=20 case.inst is not the case. From 2 and 4 we also see the effect of U=20 parameter.
2.Why these counted evidences are not agree with each other?
 
Anyway, I am at least willing to inform that all my calculations = are well=20 converged in a few iterations in contrast to the 250 reported = iterations:=20 maybe due to the latest wien2k version. In addition = such substantially=20 different reported results with and without -orb are not = observed.
Thank you for your attention in this respect,
Your,
S. Jalali.
- ------=_NextPart_000_003A_01C24765.BF944730-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 10:32:58 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: Coulomb interaction strengths ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all Did anyone know how to calculate the nearest-neighbour Coulomb interaction strengths between different orbitals ? - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 10:24:00 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: The problem in band character plot ==== Peter Blaha submitted the following contribution: ==== > I tried TiC Bandstructure (with band character) as routine manner. > (Generate k-list, edit tic.in1, lapw1 -up, edit tic.in2, and > lapw2 -up -qtl.) > > When I start lapw2 with -up spin option, the program seems to search > opposite down spin (tic.energydn) file. (see below) Of course it does! You must not use the -up switch. I suppose you tried TiC (as in the manual) WITHOUT spinpolarization, i.e. using run_lapw Why would you then use x lapw1/2 -up ??? The -up switch is just for spinpolarized cases, but this requires that you also run a spinpolarized scf cycle (runsp_lapw). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 14:05:00 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: single vs. double cells ==== Peter Blaha submitted the following contribution: ==== > I am investigating a AFM compound and therefore have to double my > unit cell. In the compound I am looking at the single cell is the cubic > space group #221 (Pm-3m). This is a peroskite structure and the afm order > is along the (111) axis and therefore I end up with a rhombohedral cell > which is space group #166 (R-3m). The problem is that if I calculate the > ferromagnetic solution in the doubled cell, my energy doesn't look > anything like that of double the single cell energy. In fact, there is an > approximately 30 Ryd difference!! Hi! I guess you own me a beer should we ever meet at a conference!!!!! It took me 3 hours to find out that your atttched struct file had a Ga-Z of 31.1 instead of 31.0 and then of course the total energies are off by 30 Ry. PS: You also had different RMT values, but this does not account for 30 Ry. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 14:20:42 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: bct-U ==== Peter Blaha submitted the following contribution: ==== > There was a discussion in the mailing-list some times ago about the bct-U The inital reason for the problem with U (AND spin-orbit!!) was that a filename with just ONE character (like u.struct) lead to a problem with the normalization of the SO-charge density. This also explains why different tests lead to different results (all doing bct-U, but some called the directory just u, others bctu). The problem was in lapw2, but this has been fixed in the latest version. > 1) runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE37)==> > :HFF01=-404.991,:MMI01=1.50924,:EFG01=3.38281. > > 2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE24)==> > :HFF01=0.000,:MMI01=0.00000,:EFG01=-7.62824. > > 3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested case.inst; (:ITE21)==> > :HFF01=0.000,:MMI01=0.00001,:EFG01=-7.55947. > > 4) run_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE13)==> > :HFF01=---,:MMI01=---,:EFG01=3.26087. > > 5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE=13)==> > :HFF01=-350.370,:MMI01=1.95919,:EFG01=+7.04996. > > 1.Why the calculated EFG within step 1 (imposing magnetic) and 2 (forcing zero magnet) are not alike with identical initial conditions, same case.indmup&dn for each cases regarding the same EFG's within step1 and 4? Why should it be ??? Agreement between 1 and 4 is just accidental and not perfect either. Similar (but not identical) EFGs do not mean that all the results are identical under all circumstances. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 15:13:03 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: problem with band structure ==== Peter Blaha submitted the following contribution: ==== > Here is what I did. I first created a special K-list and attached it > to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, > is there a way to run this in parallel? The code complains if I do x > lapw1 -c -p). I guess the code also tells you, that you can run in parallel only with a klist from unit 4, not 5 !!! You could insert the special k-mesh into case.klist, leave unit=4 and run x lapw1 -p -c Then concatenate all output1_x files into one single file. > After I finished it, I edited case.insp by inserting Ef > (from case.scf). Then do x spaghetti -c. You should not use the -c PS: If the options are not clear, always use: x spaghetti -h It tells you all allowed options for this program. > `1525-097 A READ statement using decimal base input found the invalid > digit '.' in the input file. The program will recover by assuming a > zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io > 21pf+0w RETURN key to continue ...' I suggest to remove case.insp and recreate it from the template. > In addition, I found that my case.qtl has zero bytes in it. This should be ok, since you did not x lapw2 -qtl -c (and you don't need it unless you want a "character-plot"). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 07:56:09 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Coulomb interaction strengths ==== Igor Mazin submitted the following contribution: ==== You first want to define orbitals - in LAPW it's hardly possible. In LMTO-TB, where orbitals are well defined, this was addressed about 15 years ago by Pawlowska (sp?) and Andersen. Igor - --- yshzhang@theory.issp.ac.cn wrote: > ==== > yshzhang@theory.issp.ac.cn > submitted the following contribution: > ==== > > Dear all > > Did anyone know how to calculate the > nearest-neighbour Coulomb interaction > strengths between different orbitals ? > > -- > Best Regards > YS Zhang > > - ------------------------------------------------------------------------ > Address: Institute of Solid State Physics > Chinese Academy of Sciences > P.O.BOX 1129,230031 Hefei > P.R~China > Tel: 086-551-5591464(Office) > 086-551-5592837(Home) > Fax: 086-551-5591434 > WWW: http://theory.issp.ac.cn/~yshzhang > - ------------------------------------------------------------------------ > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 08:23:53 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== Hi Pavel, It depends on waht kind of similarity do you seek: say, in the elastic properties (equilibrium lattice structure, phonons), magnetic properties, excitations. The physics is different in all cases. For instance, re magnetism, I can making the following predictions (I honestly never tried this): 1) Since Stoner I is larger in GGA, and DFT+U has additional I prop to (U-J), to keep the same magnetic moment in GGA+U as in LDA+U you need to decreas U *or* increase J (the latter makes more sense). Needed changes are smaller in the FLL (SIC) than in the AMF. 2) The UHB-LHB splitting is defined by U-J, but in an AFM Mott insulator like NiO part of the splitting comes from I, so again similar changes are need to reproduce the same splitting in GGA+U as in LDA+U. 3) I still fail to see any reasin why DC is more questionable in GGA than in LDA. I disagree with both your asessments: that GGA includes more [Hubbard] correlations than LDA, and, even if it did, that DC procedure would have been in any sense more questionable because of that. Best, Igor - --- Pavel Novak wrote: > ==== > Pavel Novak > submitted the following contribution: > ==== > > Dear Saeid and Igor, > > from our experience follows that GGA contains more > correlation than LDA. > As a consequence using GGA+U (U=UGGA) would give, as > a rule, similar > results as LDA+U (U=ULDA) for UGGA the double counting > term GGA+U is more questionable than LDA+U. To my > knowledge the only GGA+U > paper is by Savrasov and Kotliar: PRL 84, 3670 > (2000). Note that these > authors use the original (Anisimov 1991) approach > denoted as LDA+U(MFH) in > WIEN2k. > > Regards > Pavel Novak > ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 17:35:25 +0200 From: Thomas Claesson Subject: Re: [WIEN]: Two questions ==== Thomas Claesson submitted the following contribution: ==== Dear Wien developers and users! Thanks for your advice, Igor! I followed your instructions below and found out that starting from a converged case run without -orb the following happend when I made one extra iteration with -orb added (U=0.0001, J=0.0001). The Fermi energy changed from 0.41860 Ry to 0.62029 and the total energy from -6387.862958 to -6384.289129. The changes in the bandstructure plot were also quite drastic, so I am still a bit puzzled about what is going on. Perhaps I should add that I have not used too many k-points, 600 in whole BZ, 65 in IBZ, RKmax=7.0. I would really appreciate it if some could explain to me what happens here. Best regards, Thomas Claesson Igor Mazin wrote: >> >Case.scf has Fermi energy in it, from iteration to >iteration. Make several iterations with U=0.0001 and >J=0.0001 and then one without -orb. If you are >converged, nothing should change, including Fermi. > >If this is so, but your bands are plotted with an >incorrect Ef, you will know were to look then. > >Igor > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 09:05:49 -0700 (PDT) From: Michelle Johannes Subject: Re: [WIEN]: single vs. double cells ==== Michelle Johannes submitted the following contribution: ==== Peter- Wow, I'm really sorry about that. I have no idea why my z would have been increased so I never even checked it. I ran this calculation quite a few times to make sure the problem wasn't something spurious but I never thought to remake the .struct file from scratch. If its any consolation, I am very, very happy to have the answer. Michelle On Tue, 20 Aug 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I am investigating a AFM compound and therefore have to double my > > unit cell. In the compound I am looking at the single cell is the cubic > > space group #221 (Pm-3m). This is a peroskite structure and the afm order > > is along the (111) axis and therefore I end up with a rhombohedral cell > > which is space group #166 (R-3m). The problem is that if I calculate the > > ferromagnetic solution in the doubled cell, my energy doesn't look > > anything like that of double the single cell energy. In fact, there is an > > approximately 30 Ryd difference!! > > Hi! > > I guess you own me a beer should we ever meet at a conference!!!!! > > It took me 3 hours to find out that your atttched struct file had a Ga-Z > of 31.1 instead of 31.0 and then of course the total energies are off by > 30 Ry. > > PS: You also had different RMT values, but this does not account for 30 Ry. > > Regards > > 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 17:01:05 +0800 From: gyguo Subject: [WIEN]: LDA+U for systems without inversion symmetry ==== gyguo submitted the following contribution: ==== ==== gyguo submitted the following contribution: ==== Dear Prof. Blaha and WIEN users, We have been trying to perform LDA+U calculations without SO for systems without inversion symmetry, and we have failed. We have used both runsp_lapw -orb and runsp_c_lapw -orb. I think that the problem is due to the fact that lapwdm -dn -c is not executed, as one can see from the 'dayfile' and 'error message' enclosed below. We have no problem for systems with inversion symmetry or for LDA+U+SO calculations. I don't know runsp_lapw and x_lapw well enough to modify it. Could anyone modify runsp_lapw and x_lapw so that we can do LDA+U calculations for systems without inversion symmetry (no SO) in both serial and parallel executions? Thank you very much in advance. Regards, Guang-Yu Guo - ---------------- dayfile - ------------------------------------------------------------------------ start (Sat Aug 17 16:17:44 CST 2002) with lapw0 (20/20 to go) > lapw0 (16:17:44) 48.210u 0.560s 0:50.68 96.2% 0+0k 0+0io 274pf+0w > lapw1 -c -up -orb (16:18:35) 1649.100u 20.790s 27:56.19 99.6% 0+0k 0+0io 390pf+0w > lapw2 -c -up (16:46:32) 118.960u 7.450s 2:14.88 93.7% 0+0k 0+0 io 318pf+0w > lapw2 -c -dn (16:48:47) 61.270u 3.420s 1:05.48 98.7% 0+0k 0+0io 316pf +0w > lapwdm -up -c (16:49:53) 2.600u 0.870s 0:04.00 86.7% 0+0k 0+0io 233pf +0w > lcore -up (16:49:57) 0.580u 0.010s 0:00.71 83.0% 0+0k 0+0io 176pf+0w > lcore -dn (16:49:58) 0.600u 0.000s 0:00.63 95.2% 0+0k 0+0io 176pf+0w > mixer (16:49:59) 6.730u 0.450s 0:10.18 70.5% 0+0k 0+0io 201pf+0w :ENERGY convergence: 0 0 1.2786595000000000 :CHARGE convergence: 0 0.00001 .5435234 - ------------------- error message - ------------------------------------------------------------ LAPW0 END LAPW1 END LAPW2 END LAPW2 END lapwdm END total_exec: Command not found. CORE END CORE END MIXER END in cycle 2 ETEST: 1.2786595000000000 CTEST: .5435234 LAPW0 END PGFIO-F-217/list-directed read/unit=9/attempt to read past end of file. File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 In source file init.f, at line number 226 PGFIO-F-217/list-directed read/unit=10/attempt to read past end of file. File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 In source file init.f, at line number 226 LAPW1 END LAPW2 END LAPW2 END lapwdm END - -- Dr. G.Y. Guo Professor Department of Physics National Taiwan University 1 Roosevelt Road, Sec. 4 Taipei 106, Taiwan, R.O.C. Tel. ++886-2-33665180 Fax. ++886-2-23639984 E-mail: gyguo@phys.ntu.edu.tw ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 14:05:00 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: single vs. double cells ==== Peter Blaha submitted the following contribution: ==== ==== Peter Blaha submitted the following contribution: ==== > I am investigating a AFM compound and therefore have to double my > unit cell. In the compound I am looking at the single cell is the cubic > space group #221 (Pm-3m). This is a peroskite structure and the afm order > is along the (111) axis and therefore I end up with a rhombohedral cell > which is space group #166 (R-3m). The problem is that if I calculate the > ferromagnetic solution in the doubled cell, my energy doesn't look > anything like that of double the single cell energy. In fact, there is an > approximately 30 Ryd difference!! Hi! I guess you own me a beer should we ever meet at a conference!!!!! It took me 3 hours to find out that your atttched struct file had a Ga-Z of 31.1 instead of 31.0 and then of course the total energies are off by 30 Ry. PS: You also had different RMT values, but this does not account for 30 Ry. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 10:32:58 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: Coulomb interaction strengths ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all Did anyone know how to calculate the nearest-neighbour Coulomb interaction strengths between different orbitals ? - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 17:35:25 +0200 From: Thomas Claesson Subject: Re: [WIEN]: Two questions ==== Thomas Claesson submitted the following contribution: ==== ==== Thomas Claesson submitted the following contribution: ==== Dear Wien developers and users! Thanks for your advice, Igor! I followed your instructions below and found out that starting from a converged case run without -orb the following happend when I made one extra iteration with -orb added (U=0.0001, J=0.0001). The Fermi energy changed from 0.41860 Ry to 0.62029 and the total energy from -6387.862958 to -6384.289129. The changes in the bandstructure plot were also quite drastic, so I am still a bit puzzled about what is going on. Perhaps I should add that I have not used too many k-points, 600 in whole BZ, 65 in IBZ, RKmax=7.0. I would really appreciate it if some could explain to me what happens here. Best regards, Thomas Claesson Igor Mazin wrote: >> >Case.scf has Fermi energy in it, from iteration to >iteration. Make several iterations with U=0.0001 and >J=0.0001 and then one without -orb. If you are >converged, nothing should change, including Fermi. > >If this is so, but your bands are plotted with an >incorrect Ef, you will know were to look then. > >Igor > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 14:39:38 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: LDA+U for systems without inversion symmetry ==== Peter Blaha submitted the following contribution: ==== ==== Peter Blaha submitted the following contribution: ==== > We have been trying to perform LDA+U calculations without SO > for systems without inversion symmetry, and we have failed. > We have used both runsp_lapw -orb and runsp_c_lapw -orb. > I think that the problem is due to the fact that lapwdm -dn -c > is not executed, as one can see from the 'dayfile' and 'error message' > enclosed below. We have no problem for systems with inversion > symmetry or for LDA+U+SO calculations. I don't know runsp_lapw > and x_lapw well enough to modify it. > > Could anyone modify runsp_lapw and x_lapw so that we can > do LDA+U calculations for systems without inversion symmetry > (no SO) in both serial and parallel executions? Please download the latest WIEN2k versions. These problems have been fixed some time ago. 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 10:24:00 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: The problem in band character plot ==== Peter Blaha submitted the following contribution: ==== ==== Peter Blaha submitted the following contribution: ==== > I tried TiC Bandstructure (with band character) as routine manner. > (Generate k-list, edit tic.in1, lapw1 -up, edit tic.in2, and > lapw2 -up -qtl.) > > When I start lapw2 with -up spin option, the program seems to search > opposite down spin (tic.energydn) file. (see below) Of course it does! You must not use the -up switch. I suppose you tried TiC (as in the manual) WITHOUT spinpolarization, i.e. using run_lapw Why would you then use x lapw1/2 -up ??? The -up switch is just for spinpolarized cases, but this requires that you also run a spinpolarized scf cycle (runsp_lapw). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 10:13:47 -0400 From: gpzhang Subject: [WIEN]: problem with band structure ==== gpzhang submitted the following contribution: ==== ==== gpzhang submitted the following contribution: ==== Dear Wien Users and Developers, I thought that I know how to calculate the band structure with wien97, but clearly not. I tried several different schemes but failed. So, I wonder whether you could help me. I succeeded to calculate TiC and MgB2 band structures, but when I tried to calculate the potassium vanadate, the band structure looks messy, meaning that the lines do not form a clear continuous curve. I should note that my present compound has no inversion symmetry and appears a little frustrated. Here is what I did. I first created a special K-list and attached it to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, is there a way to run this in parallel? The code complains if I do x lapw1 -c -p). After I finished it, I edited case.insp by inserting Ef (from case.scf). Then do x spaghetti -c. I got an error message like `1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io 21pf+0w RETURN key to continue ...' In addition, I found that my case.qtl has zero bytes in it. I can attach both case.klist and case.spaghetti_ps if necessary though both files are big. Many thanks in advance! Guoping ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 13:25:46 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Two questions ==== Igor Mazin submitted the following contribution: ==== If you are puzzled a bit, I am puzzled entirely. Fortunately Peter is back; after the magic with which he fished out the wrong Z in Michelle's case, I start to believe in his omnipotency. I have no clue of how what you describe may be possible. My last lame suggestion: I assume you had deleted all vorb files before doing this experiment. If you hadn't, you should. And BTW repeat -orb itereation twice, to produce new vorbs. > drastic, so I am still > a bit puzzled about what is going on. ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 15:13:03 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: problem with band structure ==== Peter Blaha submitted the following contribution: ==== ==== Peter Blaha submitted the following contribution: ==== > Here is what I did. I first created a special K-list and attached it > to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, > is there a way to run this in parallel? The code complains if I do x > lapw1 -c -p). I guess the code also tells you, that you can run in parallel only with a klist from unit 4, not 5 !!! You could insert the special k-mesh into case.klist, leave unit=4 and run x lapw1 -p -c Then concatenate all output1_x files into one single file. > After I finished it, I edited case.insp by inserting Ef > (from case.scf). Then do x spaghetti -c. You should not use the -c PS: If the options are not clear, always use: x spaghetti -h It tells you all allowed options for this program. > `1525-097 A READ statement using decimal base input found the invalid > digit '.' in the input file. The program will recover by assuming a > zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io > 21pf+0w RETURN key to continue ...' I suggest to remove case.insp and recreate it from the template. > In addition, I found that my case.qtl has zero bytes in it. This should be ok, since you did not x lapw2 -qtl -c (and you don't need it unless you want a "character-plot"). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 09:49:45 -0700 From: "Saeid Jalali" Subject: [WIEN]: bct-U ==== "Saeid Jalali" submitted the following contribution: ==== ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_003A_01C24765.BF944730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, There was a discussion in the mailing-list some times ago about the = bct-U (a=3Db=3D7.5 au, c=3D8.5 au). Since the problem was not closed = clearly, I worked on it as my interesting subject and would like here to = share the results to use your possibly expert comments. First, let's = below paste the discussion to see/remember the problem: ">I tried exactly the same now (bct-U, a=3Db=3D7.5 au, c=3D8.5=20 > au, case.inm=3D0.1+BROYD, U=3D0.45 Ry, J=3D0.05 Ry) with the newest = version. I used=20 > RKM=3D7 and 99 k-points in IBZ (not much, just to see whether it = works). These=20 > cases converge both with and without -orb (in both cases -so is used). = It=20 > takes many iterations however (>250). Are these results comparable = with what=20 > you found : >=20 > :HFF01 :MMI01 :EFG01 > -so -in1new 1 -283.949 2.64145 6.15215 > -so -in1new 1 -orb -39.481 0.00698 1.93274=20 Actually I get rather different results. I've attached scf files from = the three runs. Maybe you'll find the differences. My calculations converge in just 20 cycles. I used only 18 k-points so maybe it's because of k-mesh, but the differences seem to be to big.=20 I can only think of two things 1) Try not using the -in1new switch. The standard scheme should be ok = for a case like this. 2) Try changing your inst to=20 U=20 Rn 3 5=20 5, 3,3.0 N=20 5, 3,0.0 N=20 6, 2,0.5 N=20 6, 2,0.5 N=20 7,-1,1.0 N=20 7,-1,1.0 N ****=20 When you start from a configuration where only the f-electrons are spin polarized sometimes improves convergence tremendiously." So, you see the problem is to obtain different results by two individual = expert persons. Comparing the above reported results of (:HFF01, :MMI01, = :EFG01) Shows that there are also dramatic differences between the = results before and after adding -orb switch, which is expectable after = 250 iterations. Here we believe that the role of -so is marginal for = this problem. Hence, we go through the problem using the default = parameters of wien2k_02 (updated 30-July-2002) and get the following = self-consistent results: 1) runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE37)=3D=3D> :HFF01=3D-404.991,:MMI01=3D1.50924,:EFG01=3D3.38281. 2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE24)=3D=3D> :HFF01=3D0.000,:MMI01=3D0.00000,:EFG01=3D-7.62824. 3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested = case.inst; (:ITE21)=3D=3D> :HFF01=3D0.000,:MMI01=3D0.00001,:EFG01=3D-7.55947. 4) run_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE13)=3D=3D> :HFF01=3D---,:MMI01=3D---,:EFG01=3D3.26087. 5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE=3D13)=3D=3D> :HFF01=3D-350.370,:MMI01=3D1.95919,:EFG01=3D+7.04996. Now my questions are as follows: 1.Why the calculated EFG within step 1 (imposing magnetic) and 2 = (forcing zero magnet) are not alike with identical initial conditions, = same case.indmup&dn for each cases regarding the same EFG's within step1 = and 4? The later same EFG's (comparing 1 and 4) show that the EFG has not been = substantially affected by -orb and sp (spin-polarization). But Steps 4 = and 5 show the effect of sp! Step 2 and 3 show the suggestion about = case.inst is not the case. From 2 and 4 we also see the effect of U = parameter. 2.Why these counted evidences are not agree with each other? Anyway, I am at least willing to inform that all my calculations are = well converged in a few iterations in contrast to the 250 reported = iterations: maybe due to the latest wien2k version. In addition such = substantially different reported results with and without -orb are not = observed. Thank you for your attention in this respect, Your, S. Jalali. - ------=_NextPart_000_003A_01C24765.BF944730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
There was a discussion in the = mailing-list some=20 times ago about the bct-U (a=3Db=3D7.5 au, c=3D8.5 au). Since the = problem was not=20 closed clearly, I worked on it as my interesting subject and would like = here to=20 share the results to use your possibly expert comments. First, let's = below paste=20 the discussion to see/remember the problem:
 
">I tried exactly the same now = (bct-U, a=3Db=3D7.5=20 au, c=3D8.5
> au, case.inm=3D0.1+BROYD, U=3D0.45 Ry, J=3D0.05 Ry) = with the newest=20 version. I used
> RKM=3D7 and 99 k-points in IBZ (not much, just = to see=20 whether it works). These
> cases converge both with and without = - -orb (in=20 both cases -so is used). It
> takes many iterations however = (>250).=20 Are these results comparable with what
> you found :
> =
>=20 :HFF01 :MMI01 :EFG01
> -so -in1new 1 -283.949 2.64145 = 6.15215
> -so=20 - -in1new 1 -orb -39.481 0.00698 1.93274
Actually I get rather = different=20 results. I've attached scf files from the
three runs. Maybe you'll = find the=20 differences.
My calculations converge in just 20 cycles. I used only = 18=20 k-points so
maybe it's because of k-mesh, but the differences seem to = be to=20 big.
I can only think of two things
1) Try not using the -in1new = switch.=20 The standard scheme should be ok for
a case like this.
 
2) Try changing your inst to
U =
Rn 3 5=20
5, 3,3.0 N
5, 3,0.0 N
6, 2,0.5 N
6, 2,0.5 N
7,-1,1.0 = N=20
7,-1,1.0 N
****
When you start from a configuration where = only the=20 f-electrons are spin
polarized sometimes improves convergence=20 tremendiously."
 

So, you see the problem is to obtain different results by two=20 individual expert persons. Comparing the above reported results of = (:HFF01,=20 :MMI01, :EFG01) Shows that there are also dramatic differences between = the=20 results before and after adding -orb switch, which is expectable after = 250=20 iterations. Here we believe that the role of -so is marginal for this = problem.=20 Hence, we go through the problem using the default parameters of = wien2k_02=20 (updated 30-July-2002) and get the following self-consistent = results:
1)=20 runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE37)=3D=3D>
:HFF01=3D-404.991,:MMI01=3D1.50924,:EFG01=3D3.38281=
 
2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE24)=3D=3D>
:HFF01=3D0.000,:MMI01=3D0.00000,:EFG01=3D-7.62824.<= /DIV>
 
3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested=20 case.inst; =20 (:ITE21)=3D=3D>
:HFF01=3D0.000,:MMI01=3D0.00001,:EFG01=3D-7.55947.<= /DIV>
 
4) run_lapw -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE13)=3D=3D>
:HFF01=3D---,:MMI01=3D---,:EFG01=3D3.26087.
 
5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ;=20 (:ITE=3D13)=3D=3D>
:HFF01=3D-350.370,:MMI01=3D1.95919,:EFG01=3D+7.0= 4996.
 
Now my questions are as follows:
 
1.Why the calculated EFG within step 1 (imposing magnetic) = and 2=20 (forcing zero magnet) are not alike with identical initial = conditions,=20 same case.indmup&dn for each cases regarding the same EFG's = within=20 step1 and 4?
 
The later same EFG's (comparing 1 and 4) show that the EFG has=20 not been substantially affected by -orb and sp (spin-polarization). = But=20 Steps 4 and 5 show the effect of sp! Step 2 and 3 show the = suggestion about=20 case.inst is not the case. From 2 and 4 we also see the effect of U=20 parameter.
2.Why these counted evidences are not agree with each other?
 
Anyway, I am at least willing to inform that all my calculations = are well=20 converged in a few iterations in contrast to the 250 reported = iterations:=20 maybe due to the latest wien2k version. In addition = such substantially=20 different reported results with and without -orb are not = observed.
Thank you for your attention in this respect,
Your,
S. Jalali.
- ------=_NextPart_000_003A_01C24765.BF944730-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 14:20:42 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: bct-U ==== Peter Blaha submitted the following contribution: ==== ==== Peter Blaha submitted the following contribution: ==== > There was a discussion in the mailing-list some times ago about the bct-U The inital reason for the problem with U (AND spin-orbit!!) was that a filename with just ONE character (like u.struct) lead to a problem with the normalization of the SO-charge density. This also explains why different tests lead to different results (all doing bct-U, but some called the directory just u, others bctu). The problem was in lapw2, but this has been fixed in the latest version. > 1) runsp_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE37)==> > :HFF01=-404.991,:MMI01=1.50924,:EFG01=3.38281. > > 2) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 ; (:ITE24)==> > :HFF01=0.000,:MMI01=0.00000,:EFG01=-7.62824. > > 3) runsp_c_lapw -orb -in1new 5 -cc 0.0001 -i 99 + above suggested case.inst; (:ITE21)==> > :HFF01=0.000,:MMI01=0.00001,:EFG01=-7.55947. > > 4) run_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE13)==> > :HFF01=---,:MMI01=---,:EFG01=3.26087. > > 5) runsp_lapw -in1new 5 -cc 0.0001 -i 99 ; (:ITE=13)==> > :HFF01=-350.370,:MMI01=1.95919,:EFG01=+7.04996. > > 1.Why the calculated EFG within step 1 (imposing magnetic) and 2 (forcing zero magnet) are not alike with identical initial conditions, same case.indmup&dn for each cases regarding the same EFG's within step1 and 4? Why should it be ??? Agreement between 1 and 4 is just accidental and not perfect either. Similar (but not identical) EFGs do not mean that all the results are identical under all circumstances. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 19 Aug 2002 18:26:28 +0800 From: gyguo Subject: [WIEN]: errors from lapwdm in parallel ==== gyguo submitted the following contribution: ==== ==== gyguo submitted the following contribution: ==== Dear Prof. Blaha and WIEN users, We found that lapwdm does not work in parallel, as shown in the following error message. We use a PC cluster with MPI and PGI compiler. We did go into the SRC_lapwdm directory, trying to solve the problem. However, we cannot find the 'dmatscf.f' program. Any help to solve the problem will be highly appreciated. Regards, Guang-Yu Guo - -------- error message --------------------------------------- x lapwdm -so -up -p running LAPWDM in parallel mode [1] 17142 [2] 17157 [3] 17179 [4] 17184 [5] 17189 [6] 17195 [7] 17226 lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END lapwdm END [7] Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [6] - Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [5] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [4] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [3] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [2] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... [1] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop ; rm -f .lock_$lockfile[$p] ) >> ... node10 4.970u 0.370s 0:26.09 20.4% 0+0k 0+0io 235pf+0w node11 5.020u 0.390s 0:27.77 19.4% 0+0k 0+0io 234pf+0w node12 4.950u 0.400s 0:27.04 19.7% 0+0k 0+0io 235pf+0w node13 5.090u 0.280s 0:26.56 20.2% 0+0k 0+0io 235pf+0w node14 5.040u 0.320s 0:26.09 20.5% 0+0k 0+0io 235pf+0w node15 4.940u 0.320s 0:25.32 20.7% 0+0k 0+0io 235pf+0w node16 4.970u 0.330s 0:24.48 21.6% 0+0k 0+0io 235pf+0w Summary of lapwdmpara: node10 user=4.97 wallclock=26.09 node11 user=5.02 wallclock=27.77 node12 user=4.95 wallclock=27.04 node13 user=5.09 wallclock=26.56 node14 user=5.04 wallclock=26.09 node15 user=4.94 wallclock=25.32 node16 user=4.97 wallclock=24.48 PGFIO-F-231/formatted read/internal file/error on data conversion. In source file dmatscf.f, at line number 69 35.220u 2.680s 0:32.19 117.7% 0+0k 0+0io 26239pf+0w - -- Dr. G.Y. Guo Professor Department of Physics National Taiwan University 1 Roosevelt Road, Sec. 4 Taipei 106, Taiwan, R.O.C. Tel. ++886-2-33665180 Fax. ++886-2-23639984 E-mail: gyguo@phys.ntu.edu.tw ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 09:05:49 -0700 (PDT) From: Michelle Johannes Subject: Re: [WIEN]: single vs. double cells ==== Michelle Johannes submitted the following contribution: ==== ==== Michelle Johannes submitted the following contribution: ==== Peter- Wow, I'm really sorry about that. I have no idea why my z would have been increased so I never even checked it. I ran this calculation quite a few times to make sure the problem wasn't something spurious but I never thought to remake the .struct file from scratch. If its any consolation, I am very, very happy to have the answer. Michelle On Tue, 20 Aug 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I am investigating a AFM compound and therefore have to double my > > unit cell. In the compound I am looking at the single cell is the cubic > > space group #221 (Pm-3m). This is a peroskite structure and the afm order > > is along the (111) axis and therefore I end up with a rhombohedral cell > > which is space group #166 (R-3m). The problem is that if I calculate the > > ferromagnetic solution in the doubled cell, my energy doesn't look > > anything like that of double the single cell energy. In fact, there is an > > approximately 30 Ryd difference!! > > Hi! > > I guess you own me a beer should we ever meet at a conference!!!!! > > It took me 3 hours to find out that your atttched struct file had a Ga-Z > of 31.1 instead of 31.0 and then of course the total energies are off by > 30 Ry. > > PS: You also had different RMT values, but this does not account for 30 Ry. > > Regards > > 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 20 Aug 2002 16:05:09 -0700 (PDT) From: yanming Ma Subject: Re: [WIEN]: About AIM ==== yanming Ma submitted the following contribution: ==== - --0-796074058-1029884709=:605 Content-Type: text/plain; charset=us-ascii Dear wien2k users, I think I have gotten neccessay references for the AIM from all the replies. I really appreciate all your kind replies. Thanks very much for all of you, Alexander, Torsten, Jorge, Xiangyuan, and Victor. Cheers Yanming Ma Ph.D National research council of Canada, Steacie institute for molecular Sciences. ottawa, ontario "Dr. Alexander Hofmann" wrote:Dear Yanming, The basic articles are attached below. For some reasons I made in my molecular life tests with Baders program (PROAIMV) on the water molecule with different basis sets. I did the same with the Mulliken analysis (very common in molecular chemistry) and the Gaussian98 NPA (=Natural Population Analysis). And it turned out that the NPA is the most stable analysis with respect to varying basis sets. We can learn at least a couple of things from this (comments welcome): - - Even the conceptually best analysis (Bader) gives widely spreaded _absolute_ numbers. - - charge difference are quite reliable - - NPA is best for water, but it seems this due to some error cancellation. My take home message is: Carefully with absolute charges, trends are surely ok. with best regards Alex PS: attached the mentioned table (TeX-Format) @article{bader81, TITLE={Quantum Theory of Atoms in Molecules - Dalton Revisited}, AUTHOR={R. F. W. Bader and T. T. Nguyen-Dang}, JOURNAL={Adv. Quantum Chem.}, YEAR={1981}, VOLUME={14}, PAGES={63} } @book{bader90, TITLE={Atoms in Molecules - A Quantum Theory}, AUTHOR={R. F. W. Bader}, PUBLISHER={Oxford University Press}, YEAR={1990}, address={Oxford}, } @article{bader91, TITLE={A Quantum Theory of Molecular Structure and Its Applications}, AUTHOR={R. F. W. Bader}, JOURNAL={Chem. Rev.}, YEAR={1991}, VOLUME={91}, PAGES={893} } - -- Dr. Alexander Hofmann Humboldt-Universitaet zu Berlin Institut fuer Chemie Arbeitsgruppe Quantenchemie Brook-Taylor-Strasse 2 12489 Berlin ah@chemie.hu-berlin.de Tel.: +49-30-2093-7138 Fax.: +49-30-2093-7136 http://www.chemie.hu-berlin.de/ag_sauer/index.html PGP-Key: wwwkeys.de.pgp.net ID: D9D62D35 > ATTACHMENT part 2 application/x-tex - --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs - --0-796074058-1029884709=:605 Content-Type: text/html; charset=us-ascii

Dear wien2k users,

I think I have gotten neccessay references for the AIM from all the replies.

I really appreciate all your kind replies.

Thanks very much for all of you, Alexander, Torsten, Jorge, Xiangyuan, and Victor.

Cheers

 

Yanming Ma Ph.D

National research council of Canada, Steacie institute for molecular Sciences.

ottawa, ontario

  

 "Dr. Alexander Hofmann" wrote:

Dear Yanming,

The basic articles are attached below.

For some reasons I made in my molecular life tests with Baders program (PROAIMV) on the water molecule with different basis sets. I did the same with the Mulliken analysis (very common in molecular chemistry) and the Gaussian98 NPA (=Natural Population Analysis). And it turned out that the NPA is the most stable analysis with respect to varying basis sets.
We can learn at least a couple of things from this (comments welcome):
- Even the conceptually best analysis (Bader) gives widely spreaded _absolute_ numbers.
- charge difference are quite reliable
- NPA is best for water, but it seems this due to some error cancellation.

My take home message is: Carefully with absolute charges, trends are surely ok.


with best regards

Alex

PS: attached the mentioned table (TeX-Format)

! @article{bader81,
TITLE={Quantum Theory of Atoms in Molecules - Dalton Revisited},
AUTHOR={R. F. W. Bader
and T. T. Nguyen-Dang},
JOURNAL={Adv. Quantum Chem.},
YEAR={1981},
VOLUME={14},
PAGES={63}
}

@book{bader90,
TITLE={Atoms in Molecules - A Quantum Theory},
AUTHOR={R. F. W. Bader},
PUBLISHER={Oxford University Press},
YEAR={1990},
address={Oxford},
}

@article{bader91,
TITLE={A Quantum Theory of Molecular Structure and Its Applications},
AUTHOR={R. F. W. Bader},
JOURNAL={Chem. Rev.},
YEAR={1991},
VOLUME={91},
PAGES={893}
}

--

Dr. Alexander Hofmann

Humboldt-Universitaet zu Berlin
Institut fuer Chemie
Arbeitsgruppe Quantenchemie

Brook-Taylor-Strasse 2

12489 Berlin

ah@chemie.hu-berlin.de

Tel.: +49-30-2093-7138
Fax.: +49-30-2093-7136

http://www.chemie.hu-berlin.de/ag_sauer/index.html

PGP-Key: wwwkeys.de.pgp.net ID: D9D62D35
&g! t; ATTACHMENT part 2 application/x-tex


Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs - --0-796074058-1029884709=:605-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 08:32:34 +0200 (MET DST) From: Pavel Novak Subject: Re: [WIEN]: LDA+U for systems without inversion symmetry ==== Pavel Novak submitted the following contribution: ==== Dear colleague, there is a problem when running LDA+U on systems without the inversion symmetry - during the calculation a spurious orbital moment may develop and scf procedure may not converge. When considering (YCa)2BaNiO5 (LDA+U, without s-o, no inversion symmetry) I solved this problem by averaging out the orbital potential. Best regards Pavel Novak On Mon, 19 Aug 2002, gyguo wrote: > ==== > gyguo > submitted the following contribution: > ==== > > ==== > gyguo > submitted the following contribution: > ==== > > > Dear Prof. Blaha and WIEN users, > > We have been trying to perform LDA+U calculations without SO > for systems without inversion symmetry, and we have failed. > We have used both runsp_lapw -orb and runsp_c_lapw -orb. > I think that the problem is due to the fact that lapwdm -dn -c > is not executed, as one can see from the 'dayfile' and 'error message' > enclosed below. We have no problem for systems with inversion > symmetry or for LDA+U+SO calculations. I don't know runsp_lapw > and x_lapw well enough to modify it. > > Could anyone modify runsp_lapw and x_lapw so that we can > do LDA+U calculations for systems without inversion symmetry > (no SO) in both serial and parallel executions? > Thank you very much in advance. > > Regards, > Guang-Yu Guo > > > > > > ---------------- dayfile > ------------------------------------------------------------------------ > start (Sat Aug 17 16:17:44 CST 2002) with lapw0 (20/20 to go) > > lapw0 (16:17:44) 48.210u 0.560s 0:50.68 96.2% 0+0k 0+0io 274pf+0w > > lapw1 -c -up -orb (16:18:35) 1649.100u 20.790s 27:56.19 99.6% > 0+0k 0+0io 390pf+0w > > lapw2 -c -up (16:46:32) 118.960u 7.450s 2:14.88 93.7% 0+0k 0+0 > io 318pf+0w > > lapw2 -c -dn (16:48:47) 61.270u 3.420s 1:05.48 98.7% 0+0k 0+0io 316pf > +0w > > lapwdm -up -c (16:49:53) 2.600u 0.870s 0:04.00 86.7% 0+0k 0+0io 233pf > +0w > > lcore -up (16:49:57) 0.580u 0.010s 0:00.71 83.0% 0+0k 0+0io 176pf+0w > > lcore -dn (16:49:58) 0.600u 0.000s 0:00.63 95.2% 0+0k 0+0io 176pf+0w > > mixer (16:49:59) 6.730u 0.450s 0:10.18 70.5% 0+0k 0+0io 201pf+0w > :ENERGY convergence: 0 0 1.2786595000000000 > :CHARGE convergence: 0 0.00001 .5435234 > > ------------------- error message > ------------------------------------------------------------ > LAPW0 END > LAPW1 END > LAPW2 END > LAPW2 END > lapwdm END > total_exec: Command not found. > CORE END > CORE END > MIXER END > in cycle 2 ETEST: 1.2786595000000000 CTEST: .5435234 > LAPW0 END > PGFIO-F-217/list-directed read/unit=9/attempt to read past end of file. > File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 > In source file init.f, at line number 226 > PGFIO-F-217/list-directed read/unit=10/attempt to read past end of file. > File name = su-1ceco2-2sp+u.dmatdn formatted, sequential access record = 1 > In source file init.f, at line number 226 > LAPW1 END > LAPW2 END > LAPW2 END > lapwdm END > > > -- > Dr. G.Y. Guo > Professor > Department of Physics > National Taiwan University > 1 Roosevelt Road, Sec. 4 > Taipei 106, Taiwan, R.O.C. > Tel. ++886-2-33665180 > Fax. ++886-2-23639984 > E-mail: gyguo@phys.ntu.edu.tw > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 15:41:04 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: DOS ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all I meet a confused question. I am caculating the V2O3 with U.After SCF,I plot the partial DOS of vanadium(d,dz2,dx2y2,dxy,dxz,dyz).But in the DOS, the summary of dz2,dx2y2,dxy,dxz,dyz is much larger than d.and the figures of dxy,dxz,dyz are absoulte sameness.I don't know why. In the SCF,there is no any error occur. The following is a line in case.dos1evup. E,d,dz2,dx2y2,dxy,dxz,dyz -5.02081 0.58548264 0.08934838 0.14079606 2.69683133 2.69683133 2.69683133 - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 16:29:08 +0800 From: gyguo Subject: Re: [WIEN]: errors from lapwdm in parallel ==== gyguo submitted the following contribution: ==== Dear Prof. Blaha and WIEN users, The following e-mail was sent recently. The problem remains even when we use the latest version of WIEN2k (downloaded 19 August 2002). If anyone knows how to solve the problem, please let us know. Thank you. Guang-Yu Guo gyguo ¼g¹D¡G > ==== > gyguo > submitted the following contribution: > ==== > > Dear Prof. Blaha and WIEN users, > > We found that lapwdm does not work in parallel, > as shown in the following error message. > We use a PC cluster with MPI and PGI compiler. > We did go into the SRC_lapwdm directory, > trying to solve the problem. However, > we cannot find the 'dmatscf.f' program. > Any help to solve the problem will be highly > appreciated. > > Regards, > > Guang-Yu Guo > > -------- error message --------------------------------------- > x lapwdm -so -up -p > running LAPWDM in parallel mode > [1] 17142 > [2] 17157 > [3] 17179 > [4] 17184 > [5] 17189 > [6] 17195 > [7] 17226 > > lapwdm END > > lapwdm END > lapwdm END > lapwdm END > lapwdm END > lapwdm END > lapwdm END > [7] Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [6] - Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [5] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [4] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [3] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [2] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > [1] + Done ( cd $PWD; $t $exe ${def}_${loop}.def $loop > ; rm -f .lock_$lockfile[$p] ) >> ... > node10 4.970u 0.370s 0:26.09 20.4% 0+0k 0+0io 235pf+0w > node11 5.020u 0.390s 0:27.77 19.4% 0+0k 0+0io 234pf+0w > node12 4.950u 0.400s 0:27.04 19.7% 0+0k 0+0io 235pf+0w > node13 5.090u 0.280s 0:26.56 20.2% 0+0k 0+0io 235pf+0w > node14 5.040u 0.320s 0:26.09 20.5% 0+0k 0+0io 235pf+0w > node15 4.940u 0.320s 0:25.32 20.7% 0+0k 0+0io 235pf+0w > node16 4.970u 0.330s 0:24.48 21.6% 0+0k 0+0io 235pf+0w > Summary of lapwdmpara: > node10 user=4.97 wallclock=26.09 > node11 user=5.02 wallclock=27.77 > node12 user=4.95 wallclock=27.04 > node13 user=5.09 wallclock=26.56 > node14 user=5.04 wallclock=26.09 > node15 user=4.94 wallclock=25.32 > node16 user=4.97 wallclock=24.48 > PGFIO-F-231/formatted read/internal file/error on data conversion. > In source file dmatscf.f, at line number 69 > 35.220u 2.680s 0:32.19 117.7% 0+0k 0+0io 26239pf+0w > > -- > Dr. G.Y. Guo > Professor > Department of Physics > National Taiwan University > 1 Roosevelt Road, Sec. 4 > Taipei 106, Taiwan, R.O.C. > Tel. ++886-2-33665180 > Fax. ++886-2-23639984 > E-mail: gyguo@phys.ntu.edu.tw > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 12:36:33 +0400 From: "Alexander Korlyukov" Subject: [WIEN]: X-ray structural factors ==== "Alexander Korlyukov" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0044_01C2490F.62181E00 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Dear Wien2k users. I am quite newbie in Wien2k So I have a couple of questions to more experienced users, which dealt = with lapw3 program.=20 When I run lapw3 on hydrogen peroxide (space group P4(3)2(1)2), most of = X-ray structural factors obtained have negative sign. Obviously, that = such a set of X-ray structural factors contradicts to the experimental = data.=20 What kind of input parameters (in files case.in1, case.in2 and so on) = may influnce on sign of structural factor? Is this (obtainig of negative structural factors) deal with Struct Gen? = (Calculation of cubic groups (TiO2, Si, Ge etc.) always give only = positive ones) Alexander Korlyukov, Ph. D. Student INEOS RAS, Russia - ------=_NextPart_000_0044_01C2490F.62181E00 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Dear Wien2k users.
 
I am quite newbie in = Wien2k
So I have a couple of questions = to more=20 experienced users, which dealt with lapw3 program.
 
When I run lapw3 on hydrogen peroxide = (space group=20 P4(3)2(1)2), most of X-ray structural factors obtained have = negative=20 sign. Obviously, that such a set of X-ray structural factors = contradicts to=20 the experimental data.
What kind of input parameters (in files = case.in1,=20 case.in2 and so on) may influnce on sign of structural = factor?
Is this (obtainig of negative = structural=20 factors) deal with Struct Gen? (Calculation of cubic groups (TiO2, Si, = Ge etc.)=20 always give only positive ones)
 
Alexander Korlyukov,
 
Ph. D. Student
 
INEOS RAS, Russia
 
 
- ------=_NextPart_000_0044_01C2490F.62181E00-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 11:00:47 +0200 From: Enrique Lomba Subject: [WIEN]: Problem calculating DOS ==== Enrique Lomba submitted the following contribution: ==== Hello all, I am trying to calculate the DOS of trigonal Te, I have a converged calculation with the corresponding Te.vector file and when running x lapw2 -qtl -c to generate the partial charges I got the following error x lapw2 -qtl -c PGFIO-F-231/formatted read/unit=1001/error on data conversion. File name = /scratch/enrique/Te.help031 formatted, sequential access record = 13827 In source file outp.f, at line number 179 Now checking the file Te.help031 it turns out that there are several records with ****** and cannot be read, for instance L= 2 ********** 3778.777 1734.128 8947.667 3946.588 -2872.261 DZ2:1031.24651 232.066 108.280 561.864 244.372 -179.853 DX2Y2: 188.48954 44.795 19.674 100.627 44.140 -32.444 DXY:2452.45155 562.799 256.407 1321.702 580.255 -424.483 DXZ: 308.16757 85.456 29.708 153.398 69.021 -49.218 DYZ:********** 2853.661 1320.059 6810.077 3008.800 -2186.264 it seems they all correspond to L=2, could someone give me some hint on what is going on ?? Thanks and regards, Enrique - -- - -------------------------------------------------------------- Enrique Lomba Instituto de Quimica Fisica Rocasolano, CSIC C/ Serrano 119, 28006 Madrid, Spain FAX no. 34-915642431 Phone no. 34-915619407 (ext 1301) e-mail : E.Lomba@iqfr.csic.es www : http://www.fluid.iqfr.csic.es/enrique.html ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 02:09:43 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: DOS ==== "Saeid Jalali" submitted the following contribution: ==== > I meet a confused question. > I am caculating the V2O3 with U.After SCF,I plot the partial DOS of > vanadium(d,dz2,dx2y2,dxy,dxz,dyz).But in the DOS, the summary of > dz2,dx2y2,dxy,dxz,dyz is much larger than d.and the figures of dxy,dxz,dyz > are absoulte sameness.I don't know why. > In the SCF,there is no any error occur. > The following is a line in case.dos1evup. > E,d,dz2,dx2y2,dxy,dxz,dyz > -5.02081 0.58548264 0.08934838 0.14079606 2.69683133 > 2.69683133 2.69683133 You would not compare the value of the DOSs at a specific energy -- one line of case.dos1(ev)up/dn -- as it gives no sense in the solid. Instead, one will find the physical relation comparing the integral of the DOS's in specific energy windows: grep :QTLxx partial charges. This means that the number of electrons in for instance d-orbital should be expected to be equal to the sum of occupation numbers of d-partial density of states. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 11:19:23 +0200 From: Thomas Claesson Subject: Re: [WIEN]: Two questions ==== Thomas Claesson submitted the following contribution: ==== Many thanks for your help again, Igor! What I have been doing is save_lapw as soon as I reach self consistency, thinking that all files that need to be deleted actually were deleted, but perhaps the .vorb files are not deleted by save_lapw. So your suggestion is that I do this: 1) Delete .vorb files manually 2) Run to self consistency without -orb 3) save_lapw 4) Calculate bandstructure 5) Run with -orb -i 2 (with U=J=0.0001) 6) save_lapw 7) Calculate bandstructure not forgetting the -orb switch to lapw1 Have I got it right or have I missed anything or perhaps got the order wrong? Thanks in advance! Best regards, Thomas Claesson Igor Mazin wrote: >==== >Igor Mazin >submitted the following contribution: >==== > >If you are puzzled a bit, I am puzzled entirely. >Fortunately Peter is back; after the magic with which >he fished out the wrong Z in Michelle's case, I start >to believe in his omnipotency. > >I have no clue of how what you describe may be >possible. My last lame suggestion: I assume you had >deleted all vorb files before doing this experiment. >If you hadn't, you should. And BTW repeat -orb >itereation twice, to produce new vorbs. > >>drastic, so I am still >>a bit puzzled about what is going on. >> > >===== >***************************************************************************** >Igor Mazin, Naval Research Laboratory, Washington, DC 20375 >Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin >***************************************************************************** > >__________________________________________________ >Do You Yahoo!? >HotJobs - Search Thousands of New Jobs >http://www.hotjobs.com >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 11:35:17 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: X-ray structural factors ==== Peter Blaha submitted the following contribution: ==== > When I run lapw3 on hydrogen peroxide (space group P4(3)2(1)2), most of X-ray structural factors obtained have negative sign. Obviously, that such a set of X-ray structural factors contradicts to the experimental data. Negative structure factors are of course possible and correct. Only experiment has the problem that they measure F**2, i.e. they loose the sign (and phases). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 17:46:37 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: Re: [WIEN]: DOS ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== > You would not compare the value of the DOSs at a specific energy -- one line > of case.dos1(ev)up/dn -- as it gives no sense in the solid. Instead, one > will find the physical relation comparing the integral of the DOS's in > specific energy windows: grep :QTLxx partial charges. This means that the > number of electrons in for instance d-orbital should be expected to be equal > to the sum of occupation numbers of d-partial density of states. Yes,In case.scf,the number of electrons in d is equal to the sum of occupation numbers of d-partial.But we can also check this in DOS,thought caculate the integral below the plot.Using this method,I found the sum of the integral of all partial d is too large to belive. Is there something wrong? - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 12:49:49 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: errors from lapwdm in parallel ==== Peter Blaha submitted the following contribution: ==== > > We found that lapwdm does not work in parallel, > > as shown in the following error message. > > We use a PC cluster with MPI and PGI compiler. > > We did go into the SRC_lapwdm directory, > > trying to solve the problem. However, > > we cannot find the 'dmatscf.f' program. > > x lapwdm -so -up -p > > In source file dmatscf.f, at line number 69 a) At first I could not reproduce your error, because you did not mention that you used a "non-standard" case.indmc (krad ne.0). Standard scf should have worked. b) Finally I figured out, that your error in dmatscf.f (SRC_sumpara)!! could only occur when krad is .ne.0 and then I could reproduce the problem. c) Change in SRC_sumpara/dmatscf.f: .... ELSE IF(MARGN(2:4).EQ.'XOP') THEN READ(MARGN,'(4x,i2,i3,4f12.5)')IATOM,ll, X,y,z,zm <== change xop(IATOM,ll,1)=xop(IATOM,ll,1)+X xop(IATOM,ll,2)=xop(IATOM,ll,2)+y xop(IATOM,ll,3)=xop(IATOM,ll,3)+z xop(IATOM,ll,4)=xop(IATOM,ll,4)+zm IF(ILOOP.EQ.IPROC)THEN WRITE(22,724)IATOM,ll,(xop(IATOM,ll,ityp),ityp=1,4) <== change .... 724 FORMAT(':XOP',i2.2,i3,4f12.5) <== add Update on the web will follow soon. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 12:55:50 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problem calculating DOS ==== Peter Blaha submitted the following contribution: ==== > Now checking the file Te.help031 it turns out that there are several > records with ****** and cannot be read, for instance > > L= 2 ********** 3778.777 1734.128 8947.667 3946.588 -2872.261 > DZ2:1031.24651 232.066 108.280 561.864 244.372 -179.853 > DX2Y2: 188.48954 44.795 19.674 100.627 44.140 -32.444 > DXY:2452.45155 562.799 256.407 1321.702 580.255 -424.483 > DXZ: 308.16757 85.456 29.708 153.398 69.021 -49.218 > DYZ:********** 2853.661 1320.059 6810.077 3008.800 -2186.264 > > > it seems they all correspond to L=2, could someone give me some hint on > what is going on ?? It seems you have problems with the energy parameters of l=2 (d) for the first atom. Most likely this happened for an unoccupied state at higher energy (? you did not mention the energy) and thus appears only in the QTL calculation, but not during scf. Check in case.scf1 what the effective energy parameters for this channel are. Most likely you should increase the "0.3" value in the input to a larger number, but without the last iteration of the scf file + case.in1 I cannot say much more. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 04:24:36 -0700 (PDT) From: hamid salehi Subject: Re: [WIEN]: Problem calculating DOS ==== hamid salehi submitted the following contribution: ==== Dear Enrique I think that you have a spin polarized system but you are trying to plot a non spin polarized DOS. May be the up and down switches aren't active in your w2web interface. May be your problem solved if you run "x lapw2 -up(dn) -qtl" in command box or terminal. Bests. H-Salehi dept of physics Ferdowsi university Mashhad IRAN - --- Enrique Lomba wrote: > ==== > Enrique Lomba > submitted the following contribution: > ==== > > Hello all, > I am trying to calculate the DOS of trigonal Te, I > have a converged > calculation with the corresponding Te.vector file > and when running > x lapw2 -qtl -c to generate the partial charges I > got the following error > > x lapw2 -qtl -c > PGFIO-F-231/formatted read/unit=1001/error on data > conversion. > File name = /scratch/enrique/Te.help031 > formatted, sequential > access record = 13827 > In source file outp.f, at line number 179 > > Now checking the file Te.help031 it turns out that > there are several > records with ****** and cannot be read, for instance > > L= 2 ********** 3778.777 1734.128 8947.667 > 3946.588 -2872.261 > DZ2:1031.24651 232.066 108.280 561.864 > 244.372 -179.853 > DX2Y2: 188.48954 44.795 19.674 100.627 > 44.140 -32.444 > DXY:2452.45155 562.799 256.407 1321.702 > 580.255 -424.483 > DXZ: 308.16757 85.456 29.708 153.398 > 69.021 -49.218 > DYZ:********** 2853.661 1320.059 6810.077 > 3008.800 -2186.264 > > > it seems they all correspond to L=2, could someone > give me some hint on > what is going on ?? > Thanks and regards, > Enrique > > > -- > - -------------------------------------------------------------- > Enrique Lomba > Instituto de Quimica Fisica Rocasolano, CSIC > C/ Serrano 119, 28006 Madrid, Spain > > FAX no. 34-915642431 > Phone no. 34-915619407 (ext 1301) > e-mail : E.Lomba@iqfr.csic.es > www : http://www.fluid.iqfr.csic.es/enrique.html > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 04:25:51 -0700 From: "Saeid Jalali" Subject: Re: [WIEN]: DOS ==== "Saeid Jalali" submitted the following contribution: ==== > > You would not compare the value of the DOSs at a specific energy -- one line > > of case.dos1(ev)up/dn -- as it gives no sense in the solid. Instead, one > > will find the physical relation comparing the integral of the DOS's in > > specific energy windows: grep :QTLxx partial charges. This means that the > > number of electrons in for instance d-orbital should be expected to be equal > > to the sum of occupation numbers of d-partial density of states. > > Yes,In case.scf,the number of electrons in d is equal to the sum of > occupation numbers of d-partial. That's okay. >But we can also check this in DOS,thought > caculate the integral below the plot. Sure, you can. >Using this method,I found the sum > of the integral of all partial d is too large to belive. > Is there something wrong? Most likely your integrating is wrong. If you send me your file and the QTLs, I'll can try on it. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 17:26:11 +0200 From: Torsten Andersen Subject: [WIEN]: Has anybody on the list experience with the IBM p630? ==== Torsten Andersen submitted the following contribution: ==== Dear All, yes, I know it is a bit off, but I would like to know if anybody has some good experiences to share about Wien2k on the IBM p630 or other Power4 based system? Best regards, Torsten. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 18:26:48 +0200 From: Enrique Lomba Subject: Re: [WIEN]: Problem calculating DOS ==== Enrique Lomba submitted the following contribution: ==== This is a multi-part message in MIME format. - --------------060103070208030202050706 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > >>Now checking the file Te.help031 it turns out that there are several >>records with ****** and cannot be read, for instance >> >> L= 2 ********** 3778.777 1734.128 8947.667 3946.588 -2872.261 >> DZ2:1031.24651 232.066 108.280 561.864 244.372 -179.853 >> DX2Y2: 188.48954 44.795 19.674 100.627 44.140 -32.444 >> DXY:2452.45155 562.799 256.407 1321.702 580.255 -424.483 >> DXZ: 308.16757 85.456 29.708 153.398 69.021 -49.218 >> DYZ:********** 2853.661 1320.059 6810.077 3008.800 -2186.264 >> >> >>it seems they all correspond to L=2, could someone give me some hint on >>what is going on ?? > > > It seems you have problems with the energy parameters of l=2 (d) for the > first atom. Most likely this happened for an unoccupied state at higher > energy (? you did not mention the energy) and thus appears only in the > QTL calculation, but not during scf. Hello again, I fiddled around with the El paramater in case.in1c file with no success. Attached is the file an also the .scf1 file. And here are the full contents of the .help031 file with the energy of the band BAND# 37 E= 1.24718 WEIGHT= 0.0000000 L= 0 0.04806 0.537 0.009 0.901 -0.682 -0.018 L= 1 1.18968 1.161 0.028 0.000 0.000 0.000 PX: 0.43940 0.427 0.013 0.000 0.000 0.000 PY: 0.17217 0.166 0.006 0.000 0.000 0.000 PZ: 0.57811 0.569 0.010 0.000 0.000 0.000 L= 2 ********** 10645.237 3274.629 18533.693 9543.235 -5680.571 DZ2:4328.57095 1165.961 346.262 1954.711 1030.712 -599.893 DX2Y2:1166.55372 302.895 96.507 546.875 277.654 -167.515 Regards, Enrique - -- - -------------------------------------------------------------- Enrique Lomba Instituto de Quimica Fisica Rocasolano, CSIC C/ Serrano 119, 28006 Madrid, Spain FAX no. 34-915642431 Phone no. 34-915619407 (ext 1301) e-mail : E.Lomba@iqfr.csic.es www : http://www.fluid.iqfr.csic.es/enrique.html - --------------060103070208030202050706 Content-Type: text/plain; name="Teluro.in1c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Teluro.in1c" WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 -2.70 0.010 CONT 1 2 0.30 0.000 CONT 1 0 -0.84 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window - --------------060103070208030202050706 Content-Type: text/plain; name="Teluro.scf1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Teluro.scf1" ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM Te OVERALL ENERGY PARAMETER IS 0.3000 OVERALL BASIS SET ON ATOM IS LAPW E( 2)= -0.5200 E(BOTTOM)= -0.690 E(TOP)= -0.350 APW+lo E( 2)= 0.3000 LOCAL ORBITAL E( 0)= -0.7500 E(BOTTOM)= -0.750 E(TOP)= -200.000 APW+lo E( 0)= 0.3000 LOCAL ORBITAL E( 1)= 0.3000 APW+lo K= 0.00000 0.00000 0.00000 1 :RKM : MATRIX SIZE 282LOs: 45 RKM= 6.75 WEIGHT= 1.00 PGR: EIGENVALUES ARE: -0.6343986 -0.6343986 -0.6197216 -0.5772444 -0.5772444 -0.5600529 -0.5452516 -0.5452516 -0.5412693 -0.3790556 -0.3786083 -0.3786083 -0.2980131 -0.2952441 -0.2904580 -0.2904580 0.0213062 0.0213062 0.4682067 0.5016183 0.5016183 0.5200697 0.5200697 0.5833794 0.7489684 0.7786758 0.7786758 0.8030406 0.8030406 0.8750556 0.8876852 0.9481874 0.9481874 0.9718222 0.9995902 0.9995902 1.1001374 1.1001374 ******************************************************** NUMBER OF K-POINTS: 149 - --------------060103070208030202050706-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 21 Aug 2002 18:50:10 -0700 (PDT) From: Wien Wien Subject: [WIEN]: large system with hydrogens ==== Wien Wien submitted the following contribution: ==== Dear Wien2k users, I would like to run calculations for a fairly large molecule whose net formula is VS2O3N2C17H17 (a total of 42 atoms). The space group is P-1, with two molecules per unit cell. The cell volume is ca. 6000 au^3. I have selected the RMT values for V to be 1.8, for S 1.4, for O and N 1.2, for C 1.1, and H 0.49 (these are the maximal numbers allowed by NN program). The NPT is currently 781. With these parameters I am running into a problem in lstart: it appears that most of the core charge leaks out of the sphere with the separation energies down to - -10 Ry. What set of parameters would you recommend for this case? Is it the hydrogen atoms that cause the problem? Is this system feasible to be treated at all (I am running on a linux workstation with dual 1.8 GHz Pentium Xeon processor and 1.384 Gb of RDRAM). Thank you very much for your help. With best regards Tatyana Polenova __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 09:10:49 +0200 From: "Dr. Alexander Hofmann" Subject: Re: [WIEN]: Has anybody on the list experience with the IBM p630? ==== "Dr. Alexander Hofmann" submitted the following contribution: ==== Hi Torsten, our supercomputer centre is currently setting up a p690 system. The main experience is, that the new xlf version 8.x is very tricky. They try to switch back to version 7. No idea about performance. I'm currently fighting with my work horse program (VASP). But I'll surely try to compile w2k for a colleague later ... Hth Alex > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Dear All, > > yes, I know it is a bit off, but I would like to know if anybody has > some good experiences to share about Wien2k on the IBM p630 or other > Power4 based system? > > Best regards, > Torsten. > > -- > Dr. Torsten Andersen > Department of Physics, Condensed Matter Theory Group, Uppsala University > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace > News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - -- Dr. Alexander Hofmann Humboldt-Universitaet zu Berlin Institut fuer Chemie Arbeitsgruppe Quantenchemie Brook-Taylor-Strasse 2 12489 Berlin ah@chemie.hu-berlin.de Tel.: +49-30-2093-7138 Fax.: +49-30-2093-7136 http://www.chemie.hu-berlin.de/ag_sauer/index.html PGP-Key: wwwkeys.de.pgp.net ID: D9D62D35 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 12:16:21 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: large system with hydrogens ==== Peter Blaha submitted the following contribution: ==== > I would like to run calculations for a fairly large > molecule whose net formula is VS2O3N2C17H17 (a total > of 42 atoms). The space group is P-1, with two > molecules per unit cell. The cell volume is ca. 6000 > au^3. > > I have selected the RMT values for V to be 1.8, for S > 1.4, for O and N 1.2, for C 1.1, and H 0.49 (these are > the maximal numbers allowed by NN program). > > With these parameters I am running into a problem in > lstart: it appears that most of the core charge leaks > out of the sphere with the separation energies down to > -10 Ry. I believe the problem for core leakage is sulfur ? Can't you make its sphere bigger? Which atom is closest to it? Also H is smaller then I'm used in organic materials, but maybe O-H is that short ? > What set of parameters would you recommend for this > case? Is it the hydrogen atoms that cause the problem? H has no core, so there's no leakage. > Is this system feasible to be treated at all (I am > running on a linux workstation with dual 1.8 GHz > Pentium Xeon processor and 1.384 Gb of RDRAM). With 84 DIFFICULT atoms (because of small spheres) it is certainly a big calculation, but should be feasable eventually (start with RKmax=2.5) Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 09:54:40 -0400 From: gpzhang Subject: RE: [WIEN]: problem with band structure persists ==== gpzhang submitted the following contribution: ==== Dear Peter and Wien users, Thank you so much, Peter! I tried to run with x spaghetti but it gave me a similar band structure, which means the curves do not look like a band and do not change continuously. By the way, since my compound does not have inversion symmetry, from x spaghetti -h, I noticed that I may have to use x spaghetti -c. Am I wrong? The following is part of my case.in1c K-VECTORS FROM UNIT:5 GAMMA 0 0 0 160 2.00 -.50 0.50 1 1 0 160 1.0 2 2 0 160 1.0 ..... 79 79 0 160 1.0 M 80 80 0 160 1.0 END If you need further information, please feel free let me know. Again, thanks a lot in advance! Guoping >===== Original Message From Peter Blaha ===== >==== >Peter Blaha >submitted the following contribution: >==== > >> Here is what I did. I first created a special K-list and attached it >> to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, >> is there a way to run this in parallel? The code complains if I do x >> lapw1 -c -p). > >I guess the code also tells you, that you can run in parallel only with a >klist from unit 4, not 5 !!! You could insert the special k-mesh into >case.klist, leave unit=4 and run x lapw1 -p -c >Then concatenate all output1_x files into one single file. > >> After I finished it, I edited case.insp by inserting Ef >> (from case.scf). Then do x spaghetti -c. > >You should not use the -c >PS: If the options are not clear, always use: x spaghetti -h >It tells you all allowed options for this program. > >> `1525-097 A READ statement using decimal base input found the invalid >> digit '.' in the input file. The program will recover by assuming a >> zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io >> 21pf+0w RETURN key to continue ...' > >I suggest to remove case.insp and recreate it from the template. > >> In addition, I found that my case.qtl has zero bytes in it. > >This should be ok, since you did not x lapw2 -qtl -c (and you don't need >it unless you want a "character-plot"). > >Regards > > 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 18:32:39 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: large system with hydrogens ==== "Saeid Jalali" submitted the following contribution: ==== > > Is this system feasible to be treated at all (I am > > running on a linux workstation with dual 1.8 GHz > > Pentium Xeon processor and 1.384 Gb of RDRAM). > > With 84 DIFFICULT atoms (because of small spheres) it is certainly > a big calculation, but should be feasable eventually (start with RKmax=2.5) What are the recommended number of K points, Gmax, for calculating a hypothetical protein: a polypeptide chain of amino acids containing 3.6 residues or something around 100 organic atoms? What is the efficiency of parallel computing in the case of using only one K-point? ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 07:43:02 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: large system with hydrogens ==== Igor Mazin submitted the following contribution: ==== Tanya, Re H. I was doing solid molecular H eight years ago with a similar (D. Singh's) code. One unexpected problem was that a good convergence of the total energy required anomalously large GMAX (quite larger than twice RMAX). Maybe this is a public knowledge by now, at that time it came as a surprise. Igor - --- Wien Wien wrote: > ==== > Wien Wien > submitted the following contribution: > ==== > > Dear Wien2k users, > I would like to run calculations for a fairly large > molecule whose net formula is VS2O3N2C17H17 (a total > of 42 atoms). The space group is P-1, with two > molecules per unit cell. The cell volume is ca. 6000 > au^3. > > I have selected the RMT values for V to be 1.8, for > S > 1.4, for O and N 1.2, for C 1.1, and H 0.49 (these > are > the maximal numbers allowed by NN program). > > The NPT is currently 781. > > With these parameters I am running into a problem in > lstart: it appears that most of the core charge > leaks > out of the sphere with the separation energies down > to > -10 Ry. > > What set of parameters would you recommend for this > case? Is it the hydrogen atoms that cause the > problem? > > > Is this system feasible to be treated at all (I am > running on a linux workstation with dual 1.8 GHz > Pentium Xeon processor and 1.384 Gb of RDRAM). > > Thank you very much for your help. > With best regards > Tatyana Polenova > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 16:46:42 +0200 (MEST) From: Peter Blaha Subject: RE: [WIEN]: problem with band structure persists ==== Peter Blaha submitted the following contribution: ==== > By the way, since my compound does not have inversion symmetry, from > x spaghetti -h, I noticed that I may have to use x spaghetti -c. > > Am I wrong? Yes, you are wrong. Not all programs require the -c switch, only those where inversion symmetry really matters. Check you case.output1 file if it really contains the eigenvalues for the k-points listed below, or if you still have a case.output1 with a tetrahedral mesh ? > K-VECTORS FROM UNIT:5 > GAMMA 0 0 0 160 2.00 -.50 0.50 > 1 1 0 160 1.0 > 2 2 0 160 1.0 > ..... > > 79 79 0 160 1.0 > M 80 80 0 160 1.0 > END If the output file looks ok, please send this file (+ struct +insp) directly to me (gzipped). Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 17:25:40 +0200 From: Torsten Andersen Subject: Re: [WIEN]: problem with band structure persists ==== Torsten Andersen submitted the following contribution: ==== Dear Guoping, I have had similar problems with some calculations. In some cases it was solved by increasing the MT basis. Are you sure the calculation has converged (with respect to kmax, gmax, lmax)? Best regards, Torsten Andersen. gpzhang wrote: >==== >gpzhang >submitted the following contribution: >==== > >Dear Peter and Wien users, > >Thank you so much, Peter! > >I tried to run with > > x spaghetti > >but it gave me a similar band structure, which means the curves do not >look like a band and do not change continuously. > >By the way, since my compound does not have inversion symmetry, from >x spaghetti -h, I noticed that I may have to use x spaghetti -c. > >Am I wrong? > >The following is part of my case.in1c > > K-VECTORS FROM UNIT:5 >GAMMA 0 0 0 160 2.00 -.50 0.50 > 1 1 0 160 1.0 > 2 2 0 160 1.0 >..... > > 79 79 0 160 1.0 >M 80 80 0 160 1.0 >END > > >If you need further information, please feel free let me know. > >Again, thanks a lot in advance! > > >Guoping > > >>===== Original Message From Peter Blaha ===== >>==== >>Peter Blaha >>submitted the following contribution: >>==== >> >>>Here is what I did. I first created a special K-list and attached it >>>to *.in1c and changed the unit 4 to 5. I ran x lapw1 -c. (By the way, >>>is there a way to run this in parallel? The code complains if I do x >>>lapw1 -c -p). >>> >>I guess the code also tells you, that you can run in parallel only with a >>klist from unit 4, not 5 !!! You could insert the special k-mesh into >>case.klist, leave unit=4 and run x lapw1 -p -c >>Then concatenate all output1_x files into one single file. >> >>>After I finished it, I edited case.insp by inserting Ef >>>(from case.scf). Then do x spaghetti -c. >>> >>You should not use the -c >>PS: If the options are not clear, always use: x spaghetti -h >>It tells you all allowed options for this program. >> >>>`1525-097 A READ statement using decimal base input found the invalid >>>digit '.' in the input file. The program will recover by assuming a >>>zero in its place. STOP end OK 0.4u 0.1s 0:01 56% 36+314k 0+0io >>>21pf+0w RETURN key to continue ...' >>> >>I suggest to remove case.insp and recreate it from the template. >> >>>In addition, I found that my case.qtl has zero bytes in it. >>> >>This should be ok, since you did not x lapw2 -qtl -c (and you don't need >>it unless you want a "character-plot"). >> >>Regards >> >> 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ >>-------------------------------------------------------------------------- >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 17:46:19 +0200 From: Michel Penicaud Subject: [WIEN]: Bug report ==== Michel Penicaud submitted the following contribution: ==== In a calculation of orthorhombic alpha-U with the experimental parameters of ambient conditions the force with respect to the global coordinate system is: FGL01: 0. -1.745 0. in mRy/a.u. But if p1/2 LO are included in the calculation the force become: FGL01: 0. -2567.561 0. I think there is something wrong ! ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 09:48:52 -0700 (PDT) From: Wien Wien Subject: [WIEN]: large system with hydrogens; cont'd ==== Wien Wien submitted the following contribution: ==== - --0-1700026962-1030034932=:19200 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Dr. Blaha, thank you very much for your response. I changed the RMT value for S to 2.1 (the maximum allowed by the NN), and this didn't solve the problem of the core charge leakage unfortunately. One of the sulfur atoms is coordinated to V and bound to C, the second one is close to two C atoms. The size of the spheres for the remaining atoms (O, C, N, and H is the maximum allowed by NN). The C-H bonds are short. I am attaching the xyz file containing the X-ray coordinates for this molecule just in case. In this calculation I am only interested in finding out the EFG on the vanadium atom, and I was wondering whether there would be any shortcuts (e.g., whether there is anything I could ignore). Thank you very much! With best regards Tatyana Polenova - --- Peter Blaha wrote: > Date: Thu, 22 Aug 2002 12:16:21 +0200 (MEST) > From: Peter Blaha > To: > Subject: Re: [WIEN]: large system with hydrogens > > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I would like to run calculations for a fairly > large > > molecule whose net formula is VS2O3N2C17H17 (a > total > > of 42 atoms). The space group is P-1, with two > > molecules per unit cell. The cell volume is ca. > 6000 > > au^3. > > > > I have selected the RMT values for V to be 1.8, > for S > > 1.4, for O and N 1.2, for C 1.1, and H 0.49 (these > are > > the maximal numbers allowed by NN program). > > > > With these parameters I am running into a problem > in > > lstart: it appears that most of the core charge > leaks > > out of the sphere with the separation energies > down to > > -10 Ry. > > I believe the problem for core leakage is sulfur ? > Can't you make its > sphere bigger? Which atom is closest to it? > Also H is smaller then I'm used in organic > materials, but maybe O-H > is that short ? > > > What set of parameters would you recommend for > this > > case? Is it the hydrogen atoms that cause the > problem? > > H has no core, so there's no leakage. > > > Is this system feasible to be treated at all (I am > > running on a linux workstation with dual 1.8 GHz > > Pentium Xeon processor and 1.384 Gb of RDRAM). > > With 84 DIFFICULT atoms (because of small spheres) > it is certainly > a big calculation, but should be feasable eventually > (start with RKmax=2.5) > > Regards > 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@theochem.tuwien.ac.at WWW: > http://www.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com - --0-1700026962-1030034932=:19200 Content-Type: application/octet-stream; name="Sal50Et_frCIF.xyz" Content-Transfer-Encoding: base64 Content-Description: Sal50Et_frCIF.xyz Content-Disposition: attachment; filename="Sal50Et_frCIF.xyz" NDINCk5vTmFtZSAgMC4wMDAwMDANClYgIDEuNjE1OCAgMi4zNDIzIC0wLjQz MzYNClMgLTIuODA4NCAgMy4yOTU0ICAxLjE3NjYNClMgLTAuNzE5NSAgMi40 MTUxIC0wLjYzNTINCk8gIDEuOTcxOCAgMS4xNTMwICAwLjU3MjMNCk8gIDEu NjQxNiAgMS42MDkyIC0yLjAyNzYNCk8gIDMuMDc1MSAgMy40MzE2IC0wLjU4 MzENCk4gIDEuMDUyOSAgMy43NDYxICAxLjA5NjENCk4gLTAuMjU5NCAgMy44 OTM4ICAxLjU1NDINCkMgLTIuODcyOSAgNC4zMTEzICAyLjY4ODINCkMgLTEu MTA1OCAgMy4yNjg0ICAwLjgxOTYNCkMgIDEuODg5OSAgNC40NDYxICAxLjc4 NDINCkMgIDEuODE0MCAgMC4yNDM2IC0yLjQ0NzkNCkMgIDAuNTU3MiAtMC4y OTcwIC0zLjAxODcNCkMgIDMuODUzMyAgNC4wNDAzICAwLjMzMDMNCkMgIDUu MjA5OSAgNC4yNTM2ICAwLjA1NzkNCkMgIDUuOTk2NiAgNC44OTg4ICAwLjk3 NjUNCkMgIDUuNDYwOCAgNS40MDE2ICAyLjE2MjMNCkMgIDQuMTIyOSAgNS4y MzYzICAyLjQxNzENCkMgIDMuMjk4NiAgNC41NTMwICAxLjUxMTINCkMgLTEu NDY5MyAgMy42OTYwICA0LjY4NDkNCkMgLTEuMjYzNyAgMi45NTg5ICA1Ljg1 MTkNCkMgLTIuMjE2NyAgMi4wNDcxICA2LjI2ODMNCkMgLTMuMzY1MiAgMS44 NjU1ICA1LjUzOTANCkMgLTMuNTc5NCAgMi42MDc3ICA0LjM4ODUNCkMgLTIu NjM3NCAgMy41Mjk3ICAzLjk1MDENCkggLTIuMjE4NCAgNS4wOTEyICAyLjU0 OTUNCkggLTMuNzg4NCAgNC43MTg4ICAyLjc0ODcNCkggIDEuNTAxNyAgNC44 NDExICAyLjUwMjQNCkggIDIuNDU3MyAgMC4yNjE5IC0zLjAwOTcNCkggIDIu MTkyOCAtMC4yNDE1IC0xLjY0NzMNCkggIDAuNjgyNiAtMS4xOTUwIC0zLjM2 NDUNCkggIDAuMTI4MCAgMC4xNDY1IC0zLjc2NTENCkggIDAuMDY4MyAtMC4y ODkzIC0yLjUzOTgNCkggIDUuNTgwMiAgMy43Nzg4IC0wLjUzMzENCkggIDYu OTc5NSAgNS4wMzcxICAwLjgxNjcNCkggIDUuOTQ3MSAgNS43NzAxICAyLjgw MTQNCkggIDMuNzc5OSAgNS41ODUzICAzLjIxMzENCkggLTAuODM2MiAgNC4z MTE5ICA0LjM3OTQNCkggLTAuNDc3OCAgMy4wMDE0ICA2LjI3MzMNCkggLTIu MTQxNiAgMS41NDQ4ICA3LjA1OTYNCkggLTQuMTIxMiAgMS4yNjA5ICA1Ljg4 MDkNCkggLTQuMzM0NSAgMi40OTgxICAzLjg3MjUNCg== - --0-1700026962-1030034932=:19200-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 15:10:02 -0500 (CDT) From: Anja Verena Mudring Subject: [WIEN]: executables ==== Anja Verena Mudring submitted the following contribution: ==== I am using the precompiled executables on a Linux PC as we do not have a f90 compiler. Now I am meeting a problem with a structure of 52 atoms/cell. I figure out that changing NMATMAX from 5000 to 10000 will help. Is that possible? Regards, Anja Mudring. Dr. Anja-Verena Mudring Iowa State University 347 Spedding Hall Ames, Iowa 50011 Ph.: 515 294-3513 FAX: 515 294-5718 ______________ 106 University Vlg Apt B Ames, Iowa 50010 Ph.: 515 572-4931 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 16:44:46 -0400 From: Jeff Spirko Subject: [WIEN]: Bader's aim for non-symmetric atom ==== Jeff Spirko submitted the following contribution: ==== I want to run aim for an atom at a general position, without symmetry. The manual suggests using LM combinations up to 8 or even 10, but the default NCOM is 49, allowing all LM combinations only up to 6. Should I Increase NCOM in many programs and recompile, then use LM's up to 8. If I do this, are there other parameters I have to increase as well? (P. Blaha suggested this in an email on 4 Oct 2001.) If so, what other parameters must be changed? I am using WIEN2k_02. Or, should I Just run it with LM's up to 6? - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 20:52:16 GMT From: "Luis Alberto Terrazos Javier" Subject: [WIEN]: Re: : executables ==== "Luis Alberto Terrazos Javier" submitted the following contribution: ==== Dear Anja yes it is posible. You can download the IFC intel compiler free from : http://www.intel.com/software/products/compilers/ and change NMATMAX=10000 using ./siteconfig_lapw. best regards luis Anja Verena Mudring escritos: > ==== > Anja Verena Mudring > submitted the following contribution: > ==== > > I am using the precompiled executables on a Linux PC as we do not have a f90 > compiler. Now I am meeting a problem with a structure of 52 atoms/cell. > I figure out that changing NMATMAX from 5000 to 10000 will help. Is that > possible? > > Regards, Anja Mudring. > > > Dr. Anja-Verena Mudring > Iowa State University > 347 Spedding Hall > Ames, Iowa 50011 > Ph.: 515 294-3513 > FAX: 515 294-5718 > ______________ > > 106 University Vlg Apt B > Ames, Iowa 50010 > Ph.: 515 572-4931 > > > > > > > > > > > > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 22 Aug 2002 17:48:34 -0700 (PDT) From: Wien Wien Subject: [WIEN]: NPT and NPT00 for large systems ==== Wien Wien submitted the following contribution: ==== Dear Wien users, for a large system that I am running I am getting a complaint from the program: WARNING!!! For good atomic total energies you should probably change the radial mesh (reduce NRAD or increase R0), or increase PARAMTERS NPT and NPT00 I have changed these parameters in the param.inc file to NPT=4971, NPT00=790 on a fairly arbitrary basis (I tried several smaller values and still got a warning), and the corresponding IPINST parameter in the dstart source directory. Now the program doesn't complain, but the dstart takes a very long time with just 50 k-points (it has been running for already 4 hours. I am afraid that the lapw1 and lapw2 will take weeks if will be feasible at all. Does anyone have an idea on what the reasonable upper limits on NPT and NPT00 should be and what approximate ratio should I use between these two? Also, what would be a reasonable number of k-points to start with? My case consists of 82 atoms per unit cell, which unfortunately won't allow for many test calculations to establish the optimal values for the parameters. Thank you very much for your help! Tatyana __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 09:08:47 +0800 From: Wenhui Xie Subject: [WIEN]: The parallel error, please help ==== Wenhui Xie submitted the following contribution: ==== Dear WIEN, I meeting a problem in sheared memory parallel mode. The .machines files is: granularity:1 1:tayan:4 residue:tyan:4 lapw1:tyan:4 The mpirun switch in siteconfig is: mpirun -np 4 -machinefile .machines executable I do not understand executable? What is it? The computer name or program name? When I run testpara a error message is printed: Test: LAPW1 in parallel mode (using .machines) Granularity set to 1 Extrafine unset Residue set to tyan @: Expression Syntax. Why I get this error? By the way, I find the parallel version is not compiled with normal version at ame time. Because the setting of R_LIB (LAPACK+BLAS) must be changed from -llapack_lapw -lblas for normal version to -lllapack_lapw -lblas_lapw -latals for parallel version. There is anyone meet the same problem? Thanks for any reply. Yours Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 08:57:06 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Bug report ==== Peter Blaha submitted the following contribution: ==== > In a calculation of orthorhombic alpha-U with the experimental > parameters of ambient conditions the force with respect to the global > coordinate system is: > > FGL01: 0. -1.745 0. in > mRy/a.u. > > But if p1/2 LO are included in the calculation the force become: > > FGL01: 0. -2567.561 0. > > I think there is something wrong ! I expected something like this, although I haven't done any test with forces yet. We know that the EFG becomes wrong, when p1/2 LOs are added. We also traced this back to a false contribution to the nonspherical charge density but have not been able to fix this consistently yet. At the moment I can only say that one should not use any nonspherical quantities when using p1/2 LOs. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 09:21:35 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: large system with hydrogens; cont'd ==== Peter Blaha submitted the following contribution: ==== > I changed the RMT value for S to 2.1 (the maximum > allowed by the NN), and this didn't solve the problem > of the core charge leakage unfortunately. One of the Could you tell us which atom has the core leakage ? (Maybe you send the struct file instead of the xyz file?) The warnings concerning NPT0,.. and the radial mesh are usually not important and you can neglect them. > The size of the spheres for the remaining atoms (O, C, > N, and H is the maximum allowed by NN). The C-H bonds > are short. I am attaching the xyz file containing the > X-ray coordinates for this molecule just in case. I'm not an expert for organic molecules, but the lenght of an C-H bond must be fairly constant for all those compounds and from what I remember it was never necessary to go below 0.6/1.2 bohr for H and C spheres respectively!? I expect that dstart will run for many hours and of course also lapw1 (just one k-point!) will run for a day or so. Nevertheless, in about a week a scf run could be possible. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 11:07:39 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Bader's aim for non-symmetric atom ==== Peter Blaha submitted the following contribution: ==== > I want to run aim for an atom at a general position, without > symmetry. The manual suggests using LM combinations up to 8 or even > 10, but the default NCOM is 49, allowing all LM combinations only up > to 6. > > Should I Increase NCOM in many programs and recompile, then > use LM's up to 8. If I do this, are there other parameters I have > to increase as well? (P. Blaha suggested this in an email on 4 Oct > 2001.) If so, what other parameters must be changed? I am using > WIEN2k_02. > > Or, should I Just run it with LM's up to 6? My suggestion: Try to find critical points or atomic basins (with very few directions). If it works, no need for changes, but sometimes small discontinuities at RMT prevent proper finding of the atomic basins or of critical points and aim runs "forever". Also check the sigma (:FIT) in the scf file whether it is small (E-2) or larger. Regards 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@theochem.tuwien.ac.at WWW: http://www.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 15:15:32 +0200 From: Thomas Claesson Subject: [WIEN]: Oscillations with LDA+U ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am trying to run an LDA+U calculation on NiO in the AF II configuration. However, as described in the userguide, I get problems with oscillations during the SCF cycle. My question is: is there anything I do to reduce oscillations and improve convergence in the new Wien2k_02 mixing scheme. Will it make any difference if I reduce the mixing parameter and switch to Pratt mixing in case.inorb? Is perhaps case.inm the place where I should modify mixing? Could it help to add s-o coupling, as described in the userguide. I'm not primarily intersted in s-o effects? Thanks for your replies. Any suggestions are welcome! Best reagards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #32 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #33 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, August 30 2002 Volume 2002 : Number 033 ---------------------------------------------------------------------- Date: Fri, 23 Aug 2002 08:54:47 -0700 (PDT) From: Wien Wien Subject: Re: [WIEN]: large system with hydrogens; cont'd ==== Wien Wien submitted the following contribution: ==== - --0-915341040-1030118087=:92109 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Dr. Blaha, thank you very much for your response and for the comments. First, I found a typo in the .struct file. I apologize for taking your time before. I am sending the correct .struct file along. I rerun the lstart for this file,and the result doesn't show any core charge leakage. Now it appears that the core charge is 0 (and the charge inside the sphere is 0 as well). Is this reasonable? The C-H bond lengths are very short (most of these are aromatic carbons), and this is probably why the sphere radii for C and H had to be so small (1.1 and 0.49)... Thank you very much for your help and your time With best regards Tatyana Polenova __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com - --0-915341040-1030118087=:92109 Content-Type: application/octet-stream; name="Sal5OEt.struct" Content-Transfer-Encoding: base64 Content-Description: Sal5OEt.struct Content-Disposition: attachment; filename="Sal5OEt.struct" U2FsNU9FdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApQICAgTEFUVElD RSxOT05FUVVJVi4gQVRPTVM6NDIyX1AtMSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCk1PREUgT0YgQ0FMQz1SRUxBIHVu aXQ9YW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKIDE5LjAyNzY2MCAxOS4yMTg1MjIgMTkuMzUyNjkz IDkwLjg3MDAwMDExNS41NjAwMDAxMDcuNjMwMDAwICAgICAgICAgICAgICAg ICAgIApBVE9NPSAtMTogWD0wLjgxMDYwMDAwIFk9MC43MTE2MDAwMCBaPTAu OTU3NzAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4 CiAgICAgIC0xOiBYPTAuMTg5NDAwMDAgWT0wLjI4ODQwMDAwIFo9MC4wNDIz MDAwMApWICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9 ICAgIDIuMDAwMCAgIFo6IDIzLjAgICAgICAgICAgICAgICAgICAgCkxPQ0FM IFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAw CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4w MDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwCkFUT009IC0yOiBYPTAuNjcwOTAwMDAgWT0wLjIyMzIw MDAwIFo9MC45Nzg2MDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJ U1BMSVQ9IDgKICAgICAgLTI6IFg9MC4zMjkxMDAwMCBZPTAuNzc2ODAwMDAg Wj0wLjAyMTQwMDAwClMgICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEw MDAwIFJNVD0gICAgMi4xNjAwICAgWjogMTYuMCAgICAgICAgICAgICAgICAg ICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAw MDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0gLTM6IFg9MC45MTU3MDAwMCBZ PTAuMjExNzAwMDAgWj0wLjkwNTQwMDAwCiAgICAgICAgICBNVUxUPSAyICAg ICAgICAgIElTUExJVD0gOAogICAgICAtMzogWD0wLjA4NDMwMDAwIFk9MC43 ODgzMDAwMCBaPTAuMDk0NjAwMDAKUyAgICAgICAgICBOUFQ9ICA4NzEgIFIw PTAuMDAwMTAwMDAgUk1UPSAgICAyLjE2MDAgICBaOiAxNi4wICAgICAgICAg ICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4w MDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPSAtNDogWD0wLjc2 ODkwMDAwIFk9MC44MTU4MDAwMCBaPTAuODQzMzAwMDAKICAgICAgICAgIE1V TFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAgIC00OiBYPTAuMjMxMTAw MDAgWT0wLjE4NDIwMDAwIFo9MC4xNTY3MDAwMApPICAgICAgICAgIE5QVD0g IDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMDAwMCAgIFo6ICA4LjAg ICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009IC01 OiBYPTAuMTkyNDAwMDAgWT0wLjIxNzIwMDAwIFo9MC44ODY5MDAwMAogICAg ICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAgLTU6IFg9 MC44MDc2MDAwMCBZPTAuNzgyODAwMDAgWj0wLjExMzEwMDAwCk8gICAgICAg ICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDguMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDog ICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAK QVRPTT0gLTY6IFg9MC42Mzk2MDAwMCBZPTAuNTUyMTAwMDAgWj0wLjg5NzMw MDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOAogICAg ICAtNjogWD0wLjM2MDQwMDAwIFk9MC40NDc5MDAwMCBaPTAuMTAyNzAwMDAK TyAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAx LjIwMDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1Qg TUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAg ICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAw MAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMApBVE9NPSAtNzogWD0wLjg3NjYwMDAwIFk9MC41OTM4MDAwMCBa PTAuODM0NTAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElU PSA4CiAgICAgIC03OiBYPTAuMTIzNDAwMDAgWT0wLjQwNjIwMDAwIFo9MC4x NjU1MDAwMApOICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBS TVQ9ICAgIDEuMjAwMCAgIFo6ICA3LjAgICAgICAgICAgICAgICAgICAgCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAg MC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwCkFUT009IC04OiBYPTAuOTY5NjAwMDAgWT0wLjM3 MzYwMDAwIFo9MC4xNDQ1MDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAg ICBJU1BMSVQ9IDgKICAgICAgLTg6IFg9MC4wMzA0MDAwMCBZPTAuNjI2NDAw MDAgWj0wLjg1NTUwMDAwCk4gICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAw MDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDcuMCAgICAgICAgICAgICAg ICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAw MCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0gLTk6IFg9MC42NjMzMDAw MCBZPTAuMzIwODAwMDAgWj0wLjEyNDUwMDAwCiAgICAgICAgICBNVUxUPSAy ICAgICAgICAgIElTUExJVD0gOAogICAgICAtOTogWD0wLjMzNjcwMDAwIFk9 MC42NzkyMDAwMCBaPTAuODc1NTAwMDAKQyAgICAgICAgICBOUFQ9ICA4NzEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjEwMDAgICBaOiAgNi4wICAgICAg ICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPS0xMDogWD0w Ljg3MDQwMDAwIFk9MC4yODE3MDAwMCBaPTAuMDI5MzAwMDAKICAgICAgICAg IE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAgLTEwOiBYPTAuMTI5 NjAwMDAgWT0wLjcxODMwMDAwIFo9MC45NzA3MDAwMApDICAgICAgICAgIE5Q VD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICA2 LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEu MDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAg ICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009 LTExOiBYPTAuNzc4NTAwMDAgWT0wLjQ5NDkwMDAwIFo9MC43MjQyMDAwMAog ICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAtMTE6 IFg9MC4yMjE1MDAwMCBZPTAuNTA1MTAwMDAgWj0wLjI3NTgwMDAwCkMgICAg ICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4xMDAw ICAgWjogIDYuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJ WDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAg ICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDAKQVRPTT0tMTI6IFg9MC4yMTI2MDAwMCBZPTAuMDg5MTAwMDAgWj0wLjg1 MjUwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOAog ICAgIC0xMjogWD0wLjc4NzQwMDAwIFk9MC45MTA5MDAwMCBaPTAuMTQ3NTAw MDAKQyAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAg ICAxLjEwMDAgICBaOiAgNi4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAw IDEuMDAwMDAwMApBVE9NPS0xMzogWD0wLjA2NTMwMDAwIFk9MC45OTA4MDAw MCBaPTAuNzMyODAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQ TElUPSA4CiAgICAgLTEzOiBYPTAuOTM0NzAwMDAgWT0wLjAwOTIwMDAwIFo9 MC4yNjcyMDAwMApDICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAw MCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICA2LjAgICAgICAgICAgICAgICAgICAg CkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAw LjAwMDAwMDAgMS4wMDAwMDAwCkFUT009LTE0OiBYPTAuNTQ4NDAwMDAgWT0w LjQ2NDMwMDAwIFo9MC43NjgxMDAwMAogICAgICAgICAgTVVMVD0gMiAgICAg ICAgICBJU1BMSVQ9IDgKICAgICAtMTQ6IFg9MC40NTE2MDAwMCBZPTAuNTM1 NzAwMDAgWj0wLjIzMTkwMDAwCkMgICAgICAgICAgTlBUPSAgODcxICBSMD0w LjAwMDEwMDAwIFJNVD0gICAgMS4xMDAwICAgWjogIDYuMCAgICAgICAgICAg ICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAw MDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0tMTU6IFg9MC4zODk0 MDAwMCBZPTAuMzk0NjAwMDAgWj0wLjcyNjIwMDAwCiAgICAgICAgICBNVUxU PSAyICAgICAgICAgIElTUExJVD0gOAogICAgIC0xNTogWD0wLjYxMDYwMDAw IFk9MC42MDU0MDAwMCBaPTAuMjczODAwMDAKQyAgICAgICAgICBOUFQ9ICA4 NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjEwMDAgICBaOiAgNi4wICAg ICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAw MDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAg ICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPS0xNjog WD0wLjI5NzIwMDAwIFk9MC4zMDI5MDAwMCBaPTAuNTk2MDAwMDAKICAgICAg ICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAgLTE2OiBYPTAu NzAyODAwMDAgWT0wLjY5NzEwMDAwIFo9MC40MDQwMDAwMApDICAgICAgICAg IE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6 ICA2LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAg IDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFU T009LTE3OiBYPTAuMzYwMDAwMDAgWT0wLjI3MjcwMDAwIFo9MC41MDY0MDAw MAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAt MTc6IFg9MC42NDAwMDAwMCBZPTAuNzI3MzAwMDAgWj0wLjQ5MzYwMDAwCkMg ICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4x MDAwICAgWjogIDYuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAK ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAw MDAwMDAKQVRPTT0tMTg6IFg9MC41MTY4MDAwMCBZPTAuMzM3MDAwMDAgWj0w LjU0OTAwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0g OAogICAgIC0xODogWD0wLjQ4MzIwMDAwIFk9MC42NjMwMDAwMCBaPTAuNDUx MDAwMDAKQyAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjEwMDAgICBaOiAgNi4wICAgICAgICAgICAgICAgICAgIApMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAu MDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAw MDAwIDEuMDAwMDAwMApBVE9NPS0xOTogWD0wLjYxMzQwMDAwIFk9MC40MzM4 MDAwMCBaPTAuNjc5OTAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAg SVNQTElUPSA4CiAgICAgLTE5OiBYPTAuMzg2NjAwMDAgWT0wLjU2NjIwMDAw IFo9MC4zMjAxMDAwMApDICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAx MDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICA2LjAgICAgICAgICAgICAgICAg ICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009LTIwOiBYPTAuODI3ODAwMDAg WT0wLjMxMDcwMDAwIFo9MC4zODkxMDAwMAogICAgICAgICAgTVVMVD0gMiAg ICAgICAgICBJU1BMSVQ9IDgKICAgICAtMjA6IFg9MC4xNzIyMDAwMCBZPTAu Njg5MzAwMDAgWj0wLjYxMDkwMDAwCkMgICAgICAgICAgTlBUPSAgODcxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4xMDAwICAgWjogIDYuMCAgICAgICAg ICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAu MDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0tMjE6IFg9MC44 NTE5MDAwMCBZPTAuMjQ1NjAwMDAgWj0wLjUxMjMwMDAwCiAgICAgICAgICBN VUxUPSAyICAgICAgICAgIElTUExJVD0gOAogICAgIC0yMTogWD0wLjE0ODEw MDAwIFk9MC43NTQ0MDAwMCBaPTAuNDg3NzAwMDAKQyAgICAgICAgICBOUFQ9 ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjEwMDAgICBaOiAgNi4w ICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAw MDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPS0y MjogWD0wLjc0MDIwMDAwIFk9MC4xMjE3MDAwMCBaPTAuNTAzNzAwMDAKICAg ICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAgLTIyOiBY PTAuMjU5ODAwMDAgWT0wLjg3ODMwMDAwIFo9MC40OTYzMDAwMApDICAgICAg ICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAg IFo6ICA2LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAg ICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAw CkFUT009LTIzOiBYPTAuNjA1NjAwMDAgWT0wLjA2MjYwMDAwIFo9MC4zNzQ1 MDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAg ICAtMjM6IFg9MC4zOTQ0MDAwMCBZPTAuOTM3NDAwMDAgWj0wLjYyNTUwMDAw CkMgICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAg MS4xMDAwICAgWjogIDYuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9U IE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAw MDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAx LjAwMDAwMDAKQVRPTT0tMjQ6IFg9MC41ODA1MDAwMCBZPTAuMTI3OTAwMDAg Wj0wLjI1MjUwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJ VD0gOAogICAgIC0yNDogWD0wLjQxOTUwMDAwIFk9MC44NzIxMDAwMCBaPTAu NzQ3NTAwMDAKQyAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAg Uk1UPSAgICAxLjEwMDAgICBaOiAgNi4wICAgICAgICAgICAgICAgICAgIApM T0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAw MDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4w MDAwMDAwIDEuMDAwMDAwMApBVE9NPS0yNTogWD0wLjY5MDkwMDAwIFk9MC4y NTI0MDAwMCBaPTAuMjU4NDAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAg ICAgSVNQTElUPSA4CiAgICAgLTI1OiBYPTAuMzA5MTAwMDAgWT0wLjc0NzYw MDAwIFo9MC43NDE2MDAwMApDICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICA2LjAgICAgICAgICAgICAg ICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAw MDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAx LjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009LTI2OiBYPTAuNzQwMDAw MDAgWT0wLjQyMTAwMDAwIFo9MC4xNDUwMDAwMAogICAgICAgICAgTVVMVD0g MiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAtMjY6IFg9MC4yNjAwMDAwMCBZ PTAuNTc5MDAwMDAgWj0wLjg1NTAwMDAwCkggICAgICAgICAgTlBUPSAgODcx ICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMC40OTAwICAgWjogIDEuMCAgICAg ICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAw IDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0tMjc6IFg9 MC41NTYwMDAwMCBZPTAuMzI4MDAwMDAgWj0wLjA4NTAwMDAwCiAgICAgICAg ICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOAogICAgIC0yNzogWD0wLjQ0 NDAwMDAwIFk9MC42NzIwMDAwMCBaPTAuOTE1MDAwMDAKSCAgICAgICAgICBO UFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAwLjQ5MDAgICBaOiAg MS4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAg ICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9N PS0yODogWD0wLjgyNDAwMDAwIFk9MC40NzAwMDAwMCBaPTAuNjczMDAwMDAK ICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAgLTI4 OiBYPTAuMTc2MDAwMDAgWT0wLjUzMDAwMDAwIFo9MC4zMjcwMDAwMApIICAg ICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDAuNDkw MCAgIFo6ICAxLjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRS SVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAw MDAwCkFUT009LTI5OiBYPTAuMjg4MDAwMDAgWT0wLjExNDAwMDAwIFo9MC44 MzAwMDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgK ICAgICAtMjk6IFg9MC43MTIwMDAwMCBZPTAuODg2MDAwMDAgWj0wLjE3MDAw MDAwCkggICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0g ICAgMC40OTAwICAgWjogIDEuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwg Uk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAK ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDAKQVRPTT0tMzA6IFg9MC4yNTcwMDAwMCBZPTAuMDU1MDAw MDAgWj0wLjk0OTAwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElT UExJVD0gOAogICAgIC0zMDogWD0wLjc0MzAwMDAwIFk9MC45NDUwMDAwMCBa PTAuMDUxMDAwMDAKSCAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAwLjQ5MDAgICBaOiAgMS4wICAgICAgICAgICAgICAgICAg IApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAu MDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPS0zMTogWD0wLjA3OTUwMDAwIFk9 MC45MDgxMDAwMCBaPTAuNzA0MDAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAg ICAgICAgSVNQTElUPSA4CiAgICAgLTMxOiBYPTAuOTIwNTAwMDAgWT0wLjA5 MTkwMDAwIFo9MC4yOTYwMDAwMApIICAgICAgICAgIE5QVD0gIDg3MSAgUjA9 MC4wMDAxMDAwMCBSTVQ9ICAgIDAuNDkwMCAgIFo6ICAxLjAgICAgICAgICAg ICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009LTMyOiBYPTAuMDE1 MDAwMDAgWT0wLjAxOTAwMDAwIFo9MC42MzkwMDAwMAogICAgICAgICAgTVVM VD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAtMzI6IFg9MC45ODUwMDAw MCBZPTAuOTgxMDAwMDAgWj0wLjM2MTAwMDAwCkggICAgICAgICAgTlBUPSAg ODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMC40OTAwICAgWjogIDEuMCAg ICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0tMzM6 IFg9MC4wMDExMDAwMCBZPTAuOTYwNzAwMDAgWj0wLjc4MjIwMDAwCiAgICAg ICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOAogICAgIC0zMzogWD0w Ljk5ODkwMDAwIFk9MC4wMzkzMDAwMCBaPTAuMjE3ODAwMDAKSCAgICAgICAg ICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAwLjQ5MDAgICBa OiAgMS4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAg ICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAg ICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApB VE9NPS0zNDogWD0wLjM0NjAwMDAwIFk9MC40MjgwMDAwMCBaPTAuNzY2MDAw MDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAg LTM0OiBYPTAuNjU0MDAwMDAgWT0wLjU3MjAwMDAwIFo9MC4yMzQwMDAwMApI ICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDAu NDkwMCAgIFo6ICAxLjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBN QVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwCkFUT009LTM1OiBYPTAuMTgyMDAwMDAgWT0wLjI1NDAwMDAwIFo9 MC41NjIwMDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9 IDgKICAgICAtMzU6IFg9MC44MTgwMDAwMCBZPTAuNzQ2MDAwMDAgWj0wLjQz ODAwMDAwCkggICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMC40OTAwICAgWjogIDEuMCAgICAgICAgICAgICAgICAgICAKTE9D QUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAw MDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAw MDAwMCAxLjAwMDAwMDAKQVRPTT0tMzY6IFg9MC4zMDMwMDAwMCBZPTAuMjE5 MDAwMDAgWj0wLjQxOTAwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAgICAg IElTUExJVD0gOAogICAgIC0zNjogWD0wLjY5NzAwMDAwIFk9MC43ODEwMDAw MCBaPTAuNTgxMDAwMDAKSCAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAw MTAwMDAgUk1UPSAgICAwLjQ5MDAgICBaOiAgMS4wICAgICAgICAgICAgICAg ICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAw IDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4w MDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPS0zNzogWD0wLjU1NzAwMDAw IFk9MC4zMTUwMDAwMCBaPTAuNDg4MDAwMDAKICAgICAgICAgIE1VTFQ9IDIg ICAgICAgICAgSVNQTElUPSA4CiAgICAgLTM3OiBYPTAuNDQzMDAwMDAgWT0w LjY4NTAwMDAwIFo9MC41MTIwMDAwMApIICAgICAgICAgIE5QVD0gIDg3MSAg UjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDAuNDkwMCAgIFo6ICAxLjAgICAgICAg ICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009LTM4OiBYPTAu OTAyMDAwMDAgWT0wLjM5NDAwMDAwIFo9MC4zOTIwMDAwMAogICAgICAgICAg TVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgKICAgICAtMzg6IFg9MC4wOTgw MDAwMCBZPTAuNjA2MDAwMDAgWj0wLjYwODAwMDAwCkggICAgICAgICAgTlBU PSAgODcxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMC40OTAwICAgWjogIDEu MCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4w MDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0t Mzk6IFg9MC45NDQwMDAwMCBZPTAuMjc4MDAwMDAgWj0wLjU5MzAwMDAwCiAg ICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOAogICAgIC0zOTog WD0wLjA1NjAwMDAwIFk9MC43MjIwMDAwMCBaPTAuNDA3MDAwMDAKSCAgICAg ICAgICBOUFQ9ICA4NzEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAwLjQ5MDAg ICBaOiAgMS4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklY OiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAg ICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAw MApBVE9NPS00MDogWD0wLjc0OTAwMDAwIFk9MC4wNzUwMDAwMCBaPTAuNTg0 MDAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAg ICAgLTQwOiBYPTAuMjUxMDAwMDAgWT0wLjkyNTAwMDAwIFo9MC40MTYwMDAw MApIICAgICAgICAgIE5QVD0gIDg3MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDAuNDkwMCAgIFo6ICAxLjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJP VCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAw MDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAg MS4wMDAwMDAwCkFUT009LTQxOiBYPTAuNTE3MDAwMDAgWT0wLjk3NjAwMDAw IFo9MC4zNjkwMDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BM SVQ9IDgKICAgICAtNDE6IFg9MC40ODMwMDAwMCBZPTAuMDI0MDAwMDAgWj0w LjYzMTAwMDAwCkggICAgICAgICAgTlBUPSAgODcxICBSMD0wLjAwMDEwMDAw IFJNVD0gICAgMC40OTAwICAgWjogIDEuMCAgICAgICAgICAgICAgICAgICAK TE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAw MDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAw MCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0tNDI6IFg9MC40OTIwMDAwMCBZPTAu MDkwMDAwMDAgWj0wLjE2NDAwMDAwCiAgICAgICAgICBNVUxUPSAyICAgICAg ICAgIElTUExJVD0gOAogICAgIC00MjogWD0wLjUwODAwMDAwIFk9MC45MTAw MDAwMCBaPTAuODM2MDAwMDAKSCAgICAgICAgICBOUFQ9ICA4NzEgIFIwPTAu MDAwMTAwMDAgUk1UPSAgICAwLjQ5MDAgICBaOiAgMS4wICAgICAgICAgICAg ICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMAogICAyICAgICAgTlVNQkVSIE9G IFNZTU1FVFJZIE9QRVJBVElPTlMKLTEgMCAwIDAuMDAwMDAwMAogMC0xIDAg MC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKICAgICAgIDEKIDEgMCAwIDAu MDAwMDAwMAogMCAxIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKICAg ICAgIDIK - --0-915341040-1030118087=:92109-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 23 Aug 2002 19:19:04 +0200 From: Claudia Ambrosch-Draxl Subject: [WIEN]: compiler options ==== Claudia Ambrosch-Draxl submitted the following contribution: ==== Dear WIEN2k users, I am wondering if someone has managed to compile the WIEN2k code on an NEC or/and on a VPP. On both machines I can compile the WIEN97 version with the f90 compiler, but not the new version. Best regards, Claudia - -- Claudia Ambrosch-Draxl Institut f. Theoretische Physik, University Graz Universitaetsplatz 5, A-8010 Graz Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 http://physik.uni-graz.at/~cad ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 26 Aug 2002 13:32:18 +0200 (SAST) From: "Dr. K.Osuch" Subject: [WIEN]: Bug in spaghetti? ==== "Dr. K.Osuch" submitted the following contribution: ==== There seams to be a bug in the new spaghetti. When one tries to obtain a character band structure by setting 'jatom ne 0', the band structure does not show any contribution from the chosen orbitals. The *.ps structure shows atom=0, independently on what one gives in the *.insp file. This can be traced back to inview.f file in SRC_spaghetti, where there is a line: if(iprto(1).eq.0) jatom_list(jatom+1)=0 which sets jatom_list=0 if we want to have the band structure drawn with dotted lines. I do not know hat the reason was to have this condition in inview.f. Commenting out this line helps - the character band structure is created then with dots and circles. However if one changes line switch to 1 (lines), again no character is shown in *.ps. K. Osuch ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 26 Aug 2002 15:54:16 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Bug in spaghetti? ==== Peter Blaha submitted the following contribution: ==== > There seams to be a bug in the new spaghetti. When one tries to obtain > a character band structure by setting 'jatom ne 0', the band structure > does not show any contribution from the chosen orbitals. The *.ps > structure shows atom=0, independently on what one gives in the *.insp file. > This can be traced back to inview.f file in SRC_spaghetti, where there is a > line: > > if(iprto(1).eq.0) jatom_list(jatom+1)=0 > > > which sets jatom_list=0 if we want to have the band structure drawn with > dotted lines. I do not know hat the reason was to have this condition in > inview.f. Commenting out this line helps - the character band structure is > created then with dots and circles. However if one changes line switch to 1 > (lines), again no character is shown in *.ps. I don't know if its a bug or a "feature": The "character-plot" works if the line switch is set to 2 or 3 (and this was our intention). You are right, without the modification you suggested above, it is not possible to produce the same plot as with the "old" spaghetti. So maybe it is a good idea to make this change. Any comments ? I hope it works in all cases. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 26 Aug 2002 14:52:13 -0700 (PDT) From: Michelle Johannes Subject: [WIEN]: KPT problem ==== Michelle Johannes submitted the following contribution: ==== Dear Wien users: I am trying to look at the band structure for a compound which I calculated with both spin-orbit and with an added U. After calculating a converged charge density, I performed the following steps: x lapw1 -up x lapw1 -dn x lapwso -up -orb Then I tried x lapw2 -c -so -up -qtl and got this message: NKPT TOO SMALL In case.output2up it gives: NUMBER OF K-POINTS .GT. NKPT = 52 My actual number of k-pts in case.in1 is 51. x lapw2 -up -qtl works fine i.e. it finds the correct number of kpts, so I guess the problem is maybe with the spin-orbit or complex implementation. I have tried reducing the number of k-pts I calculate, but lapw2 always wants one more than I have. I have not attached any files because the problem does not seem to me to be specific to my compound, but I can send them along if it would help. Thanks for any input, Michelle ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 27 Aug 2002 10:37:49 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: KPT problem ==== Peter Blaha submitted the following contribution: ==== > x lapw1 -up > x lapw1 -dn > x lapwso -up -orb > > Then I tried x lapw2 -c -so -up -qtl and got this message: > NKPT TOO SMALL > > In case.output2up it gives: > NUMBER OF K-POINTS .GT. NKPT = 52 > > My actual number of k-pts in case.in1 is 51. x lapw2 -up -qtl works fine > i.e. it finds the correct number of kpts, so I guess the problem is maybe > with the spin-orbit or complex implementation. The problem is that a "runsp -so" command does not only perform the tree steps you made at the top of this message, but also copies cp $file.energydum $file.energydumup cp $file.energydum $file.energydumdn before running x lapw2 -c -so -up -qtl Maybe you want to use runsp -so -s lapw1 -e lapwso Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 27 Aug 2002 13:00:02 +0100 From: "Xiangyuan Cui" Subject: [WIEN]: Ask help for Spin-coupling calculation ==== "Xiangyuan Cui" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0010_01C24DC9.A8381C50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C24DC9.A839A2F0" - ------=_NextPart_001_0011_01C24DC9.A839A2F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear wien2k users: I am convinced that spin-orbital coupling is vital to determine the = magnetic ground state in YCO3 compound. Unfortunately, I could not set up SO calculation properly. I wonder if = anybody is kind enough to point out my=20 errors in the below procedures: 1. normal runsp_lapw converged. 2. initso_lapw: edit *.inso and *.in1:=20 the magnetization direction is 0001 for hexadral, I used 0 0 1, rather 0 = 0 0 1, Emax=3D5.5 please see the attached file *.inso and *.in1, 3. then ask" Do you have a spinpolarised case(and want to run symmetso)? = - ---choose "y" and *.outsymso is created. the number of symmetry operation changed from 12 to 4. 4. " Do you want to use the ew struct for SO cal.?" ---choose "y" " all inversion? " choose No=3D0 " k-poits" --400, short output and k-mesh shift allowed. now it says: "Spinorbit is now ready to run" But "run_lapw -so" crashed immediately and give "Fortune stop" and in = the *.outputso says: "error in struct file read". also attached is the two structure file, one is for normal s-p = calculation, the other one is created by initso. Thanks a lot in advance for your kindness and I wish you all the best! Xiangyuan CUI PhD student, Joule Lab, University of Salford, UK =20 =20 - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.377 / Virus Database: 211 - Release Date: 15/07/2002 - ------=_NextPart_001_0011_01C24DC9.A839A2F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear wien2k users:
 
I am convinced that spin-orbital = coupling is vital=20 to determine the magnetic ground state in YCO3 compound.
Unfortunately, I could not set up SO = calculation=20 properly.  I wonder if anybody is kind enough to point out my=20
errors in the below = procedures:
 
1. normal runsp_lapw = converged.
2. initso_lapw:
edit *.inso and *.in1:
the magnetization direction is 0001 for = hexadral, I=20 used 0 0 1, rather 0 0 0 1, Emax=3D5.5
please see the attached file *.inso and = *.in1,
3. then ask" Do you have a = spinpolarised case(and=20 want to run symmetso)? ---choose "y" and *.outsymso is = created.
 the number of symmetry operation = changed from=20 12 to 4.
4. " Do you want to use the ew struct = for SO cal.?"=20 - ---choose "y"
     " all = inversion? " choose=20 No=3D0
     " k-poits" = - --400, short=20 output and k-mesh shift allowed.
now it says: "Spinorbit is now ready to = run"
 
But "run_lapw -so" crashed immediately = and give=20 "Fortune stop" and in the *.outputso says: "error in struct = file=20 read".
also attached is the two structure = file, one is for=20 normal s-p calculation, the other one is created by initso.
 
Thanks a lot in advance for your = kindness and I=20 wish you all the best!
 
Xiangyuan CUI
 
PhD student, Joule Lab, University of = Salford,=20 UK
 
 
 
 
 
   
 

---
Outgoing mail is certified = Virus=20 Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.377 /=20 Virus Database: 211 - Release Date: = 15/07/2002
- ------=_NextPart_001_0011_01C24DC9.A839A2F0-- - ------=_NextPart_000_0010_01C24DC9.A8381C50 Content-Type: application/octet-stream; name="yco3.in1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="yco3.in1" WFFIL (WFPRI, SUPWF)=0A= 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT=0A= 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 0 0.30 0.000 CONT 1 =0A= 0 -3.23 0.005 STOP 1 =0A= 1 -1.73 0.010 CONT 1 =0A= 1 0.30 0.000 CONT 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 0 0.30 0.000 CONT 1 =0A= 0 -3.23 0.005 STOP 1 =0A= 1 -1.73 0.010 CONT 1 =0A= 1 0.30 0.000 CONT 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 =0A= 1 -4.57 0.005 STOP 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0 0.30 0.000 CONT 1 =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 =0A= 1 -4.34 0.005 STOP 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0 0.30 0.000 CONT 1 =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 =0A= 1 -4.57 0.005 STOP 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0 0.30 0.000 CONT 1 =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 =0A= 1 -4.57 0.005 STOP 1 =0A= 2 0.30 0.010 CONT 1 =0A= 0 0.30 0.000 CONT 1 =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 = =0A= 1 -4.57 0.005 STOP 1 = =0A= 2 0.30 0.010 CONT 1 = =0A= 0 0.30 0.000 CONT 1 = =0A= 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) =0A= 1 0.30 0.000 CONT 1 = =0A= 1 -4.57 0.005 STOP 1 = =0A= 2 0.30 0.010 CONT 1 = =0A= 0 0.30 0.000 CONT 1 = =0A= K-VECTORS FROM UNIT:4 -7.0 5.5 emin/emax window = =0A= - ------=_NextPart_000_0010_01C24DC9.A8381C50 Content-Type: application/octet-stream; name="yco3.inso" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="yco3.inso" WFFIL=0A= 10 0 0 llmax,ipr,kpot =0A= -10.0000 5.50000 emin,emax (output energy window)=0A= 0. 0. 1. direction of magnetization (lattice = vectors)=0A= 0 number of atoms for which RLO is added=0A= 0 -3.23 0.005 STOP atom number,e-lo,de (case.in1), repeat = NX times=0A= 0 -3.23 0.005 STOP=0A= 1 -4.57 0.005 STOP=0A= 1 -4.34 0.005 STOP=0A= 1 -4.57 0.005 STOP number of atoms for which SO is switch off; = atoms=0A= - ------=_NextPart_000_0010_01C24DC9.A8381C50 Content-Type: application/octet-stream; name="yco3.struct" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="yco3.struct" Ferri-test = =0A= R LATTICE,NONEQUIV. ATOMS: 5166_R-3m = =0A= MODE OF CALC=3DRELA unit=3Dbohr = =0A= 9.490000 9.490000 46.130000 90.000000 90.000000120.000000 = =0A= ATOM=3D -1: X=3D0.00000000 Y=3D0.00000000 Z=3D0.00000000=0A= MULT=3D 1 ISPLIT=3D 4=0A= Y 1 NPT=3D 781 R0=3D0.00010000 RMT=3D 2.5000 Z: 39.0 = =0A= LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000=0A= 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= ATOM=3D -2: X=3D0.86010600 Y=3D0.86010600 Z=3D0.86010600=0A= MULT=3D 2 ISPLIT=3D 4=0A= -2: X=3D0.13989400 Y=3D0.13989400 Z=3D0.13989400=0A= Y 2 NPT=3D 781 R0=3D0.00010000 RMT=3D 2.5000 Z: 39.0 = =0A= LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000=0A= 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= ATOM=3D -3: X=3D0.50000000 Y=3D0.50000000 Z=3D0.50000000=0A= MULT=3D 1 ISPLIT=3D 4=0A= Co1 NPT=3D 781 R0=3D0.00010000 RMT=3D 2.3000 Z: 27.0 = =0A= LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000=0A= 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= ATOM=3D -4: X=3D0.66540300 Y=3D0.66540300 Z=3D0.66540300=0A= MULT=3D 2 ISPLIT=3D 4=0A= -4: X=3D0.33459700 Y=3D0.33459700 Z=3D0.33459700=0A= Co2 NPT=3D 781 R0=3D0.00010000 RMT=3D 2.3000 Z: 27.0 = =0A= LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000=0A= 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= ATOM=3D -5: X=3D0.91868500 Y=3D0.41857000 Z=3D0.41857000=0A= MULT=3D 6 ISPLIT=3D 8=0A= -5: X=3D0.08131500 Y=3D0.58143000 Z=3D0.58143000=0A= -5: X=3D0.41857000 Y=3D0.41857000 Z=3D0.91868500=0A= -5: X=3D0.58143000 Y=3D0.58143000 Z=3D0.08131500=0A= -5: X=3D0.41857000 Y=3D0.91868500 Z=3D0.41857000=0A= -5: X=3D0.58143000 Y=3D0.08131500 Z=3D0.58143000=0A= Co3 NPT=3D 781 R0=3D0.00010000 RMT=3D 2.3000 Z: 27.0 = =0A= LOCAL ROT MATRIX: 0.0000000 0.5000000 0.8660254=0A= 0.0000000-0.8660254 0.5000000=0A= 1.0000000 0.0000000 0.0000000=0A= 12 NUMBER OF SYMMETRY OPERATIONS=0A= 1 0 0 0.0000000=0A= 0 1 0 0.0000000=0A= 0 0 1 0.0000000=0A= 1=0A= 0 0 1 0.0000000=0A= 1 0 0 0.0000000=0A= 0 1 0 0.0000000=0A= 2=0A= 0 1 0 0.0000000=0A= 0 0 1 0.0000000=0A= 1 0 0 0.0000000=0A= 3=0A= 0-1 0 0.0000000=0A= - -1 0 0 0.0000000=0A= 0 0-1 0.0000000=0A= 4=0A= - -1 0 0 0.0000000=0A= 0 0-1 0.0000000=0A= 0-1 0 0.0000000=0A= 5=0A= 0 0-1 0.0000000=0A= 0-1 0 0.0000000=0A= - -1 0 0 0.0000000=0A= 6=0A= - -1 0 0 0.0000000=0A= 0-1 0 0.0000000=0A= 0 0-1 0.0000000=0A= 7=0A= 0 0-1 0.0000000=0A= - -1 0 0 0.0000000=0A= 0-1 0 0.0000000=0A= 8=0A= 0-1 0 0.0000000=0A= 0 0-1 0.0000000=0A= - -1 0 0 0.0000000=0A= 9=0A= 0 1 0 0.0000000=0A= 1 0 0 0.0000000=0A= 0 0 1 0.0000000=0A= 10=0A= 1 0 0 0.0000000=0A= 0 0 1 0.0000000=0A= 0 1 0 0.0000000=0A= 11=0A= 0 0 1 0.0000000=0A= 0 1 0 0.0000000=0A= 1 0 0 0.0000000=0A= 12=0A= - ------=_NextPart_000_0010_01C24DC9.A8381C50 Content-Type: application/octet-stream; name="S-O-yco3.struct" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="S-O-yco3.struct" Ferri-test s-o calc. M|| 0.00 0.00 1.00 = =0A= R 6 66_R = =0A= RELA = =0A= 9.490000 9.490000 46.130000 90.000000 90.000000120.000000 = =0A= ATOM=3D -2: X=3D0.86010600 Y=3D0.86010600 Z=3D0.86010600=0A= MULT=3D 2 ISPLIT=3D 4=0A= -2: X=3D0.13989400 Y=3D0.13989400 Z=3D0.13989400=0A= Y 2 NPT=3D 781 R0=3D.000100000 RMT=3D 2.50000 Z: 39.00000 = =0A= LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= 1.0000000 0.0000000 0.0000000=0A= ATOM=3D -4: X=3D0.66540300 Y=3D0.66540300 Z=3D0.66540300=0A= MULT=3D 2 ISPLIT=3D 4=0A= -4: X=3D0.33459700 Y=3D0.33459700 Z=3D0.33459700=0A= Co2 NPT=3D 781 R0=3D.000100000 RMT=3D 2.30000 Z: 27.00000 = =0A= LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= 1.0000000 0.0000000 0.0000000=0A= ATOM=3D -5: X=3D0.91868500 Y=3D0.41857000 Z=3D0.41857000=0A= MULT=3D 4 ISPLIT=3D 8=0A= -5: X=3D0.08131500 Y=3D0.58143000 Z=3D0.58143000=0A= -5: X=3D0.41857000 Y=3D0.91868500 Z=3D0.41857000=0A= -5: X=3D0.58143000 Y=3D0.08131500 Z=3D0.58143000=0A= Co3 NPT=3D 781 R0=3D.000100000 RMT=3D 2.30000 Z: 27.00000 = =0A= LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000=0A= 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= ATOM=3D -6: X=3D0.41857000 Y=3D0.41857000 Z=3D0.91868500=0A= MULT=3D 2 ISPLIT=3D 8=0A= -6: X=3D0.58143000 Y=3D0.58143000 Z=3D0.08131500=0A= Co3 NPT=3D 781 R0=3D.000100000 RMT=3D 2.30000 Z: 27.00000 = =0A= LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000=0A= 0.0000000 0.0000000 1.0000000=0A= 1.0000000 0.0000000 0.0000000=0A= 4 NUMBER OF SYMMETRY OPERATIONS=0A= 1 0 0 0.0000000=0A= 0 1 0 0.0000000=0A= 0 0 1 0.0000000=0A= 1 A 1 so. oper. type orig. index=0A= - -1 0 0 0.0000000=0A= 0-1 0 0.0000000=0A= 0 0-1 0.0000000=0A= 2 A 7=0A= 0-1 0 0.0000000=0A= - -1 0 0 0.0000000=0A= 0 0-1 0.0000000=0A= 3 B 4=0A= 0 1 0 0.0000000=0A= 1 0 0 0.0000000=0A= 0 0 1 0.0000000=0A= 4 B 10=0A= - ------=_NextPart_000_0010_01C24DC9.A8381C50-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 27 Aug 2002 16:16:25 +0200 From: Torsten Andersen Subject: [WIEN]: lstart complaining about "good atomic total energies" ==== Torsten Andersen submitted the following contribution: ==== Dear Wien users, for some cases with small RMT I get the following warning from lstart during initialization: WARNING !!!! For good atomic total energies you should probably change the radial mesh (reduce NRAD or increase R0), or increase PARAMETERS NPT and NPT00 Since none of the scf-cycle programs contains the NPT and NPT00 parameters, does this actually mean anything to the result coming out after scf? And yes, I can make them disappear, but can I safely ignore that warning, too? Best regards, Torsten Andersen. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 27 Aug 2002 13:13:06 -0700 (PDT) From: Michelle Johannes Subject: Re: [WIEN]: KPT problem ==== Michelle Johannes submitted the following contribution: ==== Thank you, Peter. Copying the files by hand worked perfectly. However, the suggestion to use some limited part of the runsp script seems not to work. Perhaps asking it to stop after lapwso does not allow it to get to the part of the script where the .energydum files are copied? In any case, one working method is quite enough for me - thanks. Michelle On Tue, 27 Aug 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > x lapw1 -up > > x lapw1 -dn > > x lapwso -up -orb > > > > Then I tried x lapw2 -c -so -up -qtl and got this message: > > NKPT TOO SMALL > > > > In case.output2up it gives: > > NUMBER OF K-POINTS .GT. NKPT = 52 > > > > My actual number of k-pts in case.in1 is 51. x lapw2 -up -qtl works fine > > i.e. it finds the correct number of kpts, so I guess the problem is maybe > > with the spin-orbit or complex implementation. > > The problem is that a "runsp -so" command does not only perform the tree > steps you made at the top of this message, but also copies > cp $file.energydum $file.energydumup > cp $file.energydum $file.energydumdn > before running x lapw2 -c -so -up -qtl > > Maybe you want to use runsp -so -s lapw1 -e lapwso > > Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 28 Aug 2002 08:27:21 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: lstart complaining about "good atomic total energies" ==== Peter Blaha submitted the following contribution: ==== > for some cases with small RMT I get the following warning from lstart > during initialization: > > WARNING !!!! For good atomic total energies you should probably > change the radial mesh (reduce NRAD or increase R0), or increase > PARAMETERS NPT > and NPT00 > > Since none of the scf-cycle programs contains the NPT and NPT00 > parameters, does this actually mean anything to the result coming out > after scf? > > And yes, I can make them disappear, but can I safely ignore that > warning, too? It gives not only a warning, but also tells you how far the radial mesh reaches. If it is a "reasonable" value (a little smaller than 15 bohr, but this depends on the kind of atom), then there is absolutely no problem. If this maximum r-value is very small (e.g. below 10 bohr for a heavier element), it might happen that the resulting atomic densities are so poor that you get problems in the scf cycle. However, in general I believe you can savely ignore these warnings with respect to the scf calculation (not for an accurate atomic total energy). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 28 Aug 2002 10:41:02 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: DOS in spin.pol SO calculation ==== Peter Blaha submitted the following contribution: ==== Dear Wien users, The total spin-up / dn DOS could not be calculated in a spinpolarized spin-orbit calculation (since each qtlup/dn file contains all eigenvalues. We write now into case.qtlup/dn the up and dn-spin "norm" of each eigenvalue into case.qtlup (at the position of "q-interstital", which was not correct anyway in SO calculations) TETRA reads now in spinpol. SO cases (only then) for the "total DOS" these norms and produces a spin-up or dn total DOS. See: www.wien2k.at/reg_user/updates Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 28 Aug 2002 10:58:12 +0200 From: Torsten Andersen Subject: Re: [WIEN]: lstart complaining about "good atomic total energies" ==== Torsten Andersen submitted the following contribution: ==== Dear Peter, thank you for the answer. Does this mean that if I later (after the scf cycle) need an accurate atomic total energy, I can just change the radial mesh in lstart and rerun lstart? Or does the atomic total energy also influence the total energy in the scf cycle (which to my understanding of "full-potential" it should not)? Best regards, Torsten Andersen. Peter Blaha wrote: >==== >Peter Blaha >submitted the following contribution: >==== > >>for some cases with small RMT I get the following warning from lstart >>during initialization: >> >>WARNING !!!! For good atomic total energies you should probably >>change the radial mesh (reduce NRAD or increase R0), or increase >>PARAMETERS NPT >>and NPT00 >> >>Since none of the scf-cycle programs contains the NPT and NPT00 >>parameters, does this actually mean anything to the result coming out >>after scf? >> >>And yes, I can make them disappear, but can I safely ignore that >>warning, too? >> > >It gives not only a warning, but also tells you how far the radial mesh >reaches. If it is a "reasonable" value (a little smaller than 15 bohr, but >this depends on the kind of atom), then there is absolutely no problem. >If this maximum r-value is very small (e.g. below 10 bohr for a heavier >element), it might happen that the resulting atomic densities are so poor >that you get problems in the scf cycle. > >However, in general I believe you can savely ignore these warnings with >respect to the scf calculation (not for an accurate atomic total energy). > >Regards > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 28 Aug 2002 11:26:52 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: lstart complaining about "good atomic total energies" ==== Peter Blaha submitted the following contribution: ==== > thank you for the answer. Does this mean that if I later (after the scf > cycle) need an accurate atomic total energy, I can just change the > radial mesh in lstart and rerun lstart? Or does the atomic total energy > also influence the total energy in the scf cycle (which to my > understanding of "full-potential" it should not)? No, of course the atomic total energy does not influence E-tot of the scf cycle (unless you have such a bad starting density that the scf cycle doesnot converge, see my previous comment), Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 16:32:55 +0800 From: joshua xie Subject: [WIEN]: one question about case.in2 ==== joshua xie submitted the following contribution: ==== Dear wien user£¬ In file 'case.in2', there is a parameter 'ne'. How to determine its value in the energy range from 'emin' to 'eval' if I set 'efmod' to 'ALL'? ¡¡¡¡ Thank you very much! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ Best regards! Joshua Xie. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 11:28:46 +0200 (MESZ) From: "A. Postnikov" Subject: Re: [WIEN]: one question about case.in2 ==== "A. Postnikov" submitted the following contribution: ==== On Thu, 29 Aug 2002, joshua xie wrote: > ==== > joshua xie > submitted the following contribution: > ==== > > Dear wien user£¬ > > In file 'case.in2', there is a parameter 'ne'. How to determine its value in the energy range from 'emin' to 'eval' if I set 'efmod' to 'ALL'? I'd guess, NE is only important for the Fermi energy search, to let the program know how many electrons there are in the occupied bands. With efmod = ALL, there is no Fermi search, so NE probably has no effect. (But you shouldnn't use this option in the course of iterations, only for extractig bands / DOS / charge density!) Good luck, Adrei Postnikov +----------------------------------------------------------------------------+ | Dr. habil. Andrei Postnikov postnik@thp.uni-duisburg.de | | Gerhard Mercator Universitaet Duisburg - Theoretische Tieftemperaturphysik | | D-47048 Duisburg Tel. +49-203-3791608 Fax +49-203-3793665 | +----------------------------------------------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 14:50:52 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Ask help for Spin-coupling calculation ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-1656175879-1030625452=:22620 Content-Type: TEXT/PLAIN; charset=US-ASCII > I am convinced that spin-orbital coupling is vital to determine the magnetic ground state in YCO3 compound. > Unfortunately, I could not set up SO calculation properly. I wonder if anybo Hi, It is not really your fault. If you look into your newly created struct file, you will see that the atoms number 1 and 3 are missing!! Thus the error in the so-scf. The reason for that is a bug in symmetso, which used an old class.f subroutine with a few errors. I have fixed and updated SRC_symmetso on the web. I also include a correct struct file for SO calculations. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-1656175879-1030625452=:22620 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="yco3.struct_so" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="yco3.struct_so" RmVycmktdGVzdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzLW8g Y2FsYy4gTXx8ICAwLjAwICAwLjAwICAxLjAwICAgICAgIA0KUiAgICAgICAg ICAgICAgICAgICAgICAgICAgICA2IDY2X1IgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIFJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICA5LjQ5MDAwMCAgOS40OTAwMDAgNDYuMTMw MDAwIDkwLjAwMDAwMCA5MC4wMDAwMDAxMjAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDQNClkgMSAgICAgICAgTlBUPSAgNzgxICBSMD0uMDAwMTAwMDAwIFJN VD0gICAyLjUwMDAwICAgWjogIDM5LjAwMDAwICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAw IDEuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAu MDAwMDAwMCAwLjAwMDAwMDANCkFUT009IC0yOiBYPTAuODYwMTA2MDAgWT0w Ljg2MDEwNjAwIFo9MC44NjAxMDYwMA0KICAgICAgICAgIE1VTFQ9IDIgICAg ICAgICAgSVNQTElUPSA0DQogICAgICAtMjogWD0wLjEzOTg5NDAwIFk9MC4x Mzk4OTQwMCBaPTAuMTM5ODk0MDANClkgMiAgICAgICAgTlBUPSAgNzgxICBS MD0uMDAwMTAwMDAwIFJNVD0gICAyLjUwMDAwICAgWjogIDM5LjAwMDAwICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDAuMDAwMDAwMCAx LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCkFUT009IC0zOiBY PTAuNTAwMDAwMDAgWT0wLjUwMDAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA0DQpDbzEgICAgICAgIE5Q VD0gIDc4MSAgUjA9LjAwMDEwMDAwMCBSTVQ9ICAgMi4zMDAwMCAgIFo6ICAy Ny4wMDAwMCAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAw LjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQpB VE9NPSAtNDogWD0wLjY2NTQwMzAwIFk9MC42NjU0MDMwMCBaPTAuNjY1NDAz MDANCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gNA0KICAg ICAgLTQ6IFg9MC4zMzQ1OTcwMCBZPTAuMzM0NTk3MDAgWj0wLjMzNDU5NzAw DQpDbzIgICAgICAgIE5QVD0gIDc4MSAgUjA9LjAwMDEwMDAwMCBSTVQ9ICAg Mi4zMDAwMCAgIFo6ICAyNy4wMDAwMCAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAw MDAgMC4wMDAwMDAwDQpBVE9NPSAtNTogWD0wLjkxODY4NTAwIFk9MC40MTg1 NzAwMCBaPTAuNDE4NTcwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAg IElTUExJVD0gOA0KICAgICAgLTU6IFg9MC4wODEzMTUwMCBZPTAuNTgxNDMw MDAgWj0wLjU4MTQzMDAwDQogICAgICAtNTogWD0wLjQxODU3MDAwIFk9MC45 MTg2ODUwMCBaPTAuNDE4NTcwMDANCiAgICAgIC01OiBYPTAuNTgxNDMwMDAg WT0wLjA4MTMxNTAwIFo9MC41ODE0MzAwMA0KQ28zICAgICAgICBOUFQ9ICA3 ODEgIFIwPS4wMDAxMDAwMDAgUk1UPSAgIDIuMzAwMDAgICBaOiAgMjcuMDAw MDAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTY6IFg9MC40MTg1NzAwMCBZPTAuNDE4NTcwMDAgWj0wLjkxODY4NTAwDQog ICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC02 OiBYPTAuNTgxNDMwMDAgWT0wLjU4MTQzMDAwIFo9MC4wODEzMTUwMA0KQ28z ICAgICAgICBOUFQ9ICA3ODEgIFIwPS4wMDAxMDAwMDAgUk1UPSAgIDIuMzAw MDAgICBaOiAgMjcuMDAwMDAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAu MDAwMDAwMA0KICAgNCAgICAgIE5VTUJFUiBPRiBTWU1NRVRSWSBPUEVSQVRJ T05TDQogMSAwIDAgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMCAw IDEgMC4wMDAwMDAwDQogICAgICAgMSAgIEEgICAxIHNvLiBvcGVyLiAgdHlw ZSAgb3JpZy4gaW5kZXgNCi0xIDAgMCAwLjAwMDAwMDANCiAwLTEgMCAwLjAw MDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAgICAyICAgQSAgIDcNCiAw LTEgMCAwLjAwMDAwMDANCi0xIDAgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAw MDAwMDANCiAgICAgICAzICAgQiAgIDQNCiAwIDEgMCAwLjAwMDAwMDANCiAx IDAgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICA0ICAg QiAgMTANCg== - ---2105530234-1656175879-1030625452=:22620-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 10:21:48 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Ask help for Spin-coupling calculation ==== Neme Nnolim submitted the following contribution: ==== Is the SRC_symmetso update valid for all WIEN97 versions, or just WIEN2k? I use WIEN97.10. > > Hi, > It is not really your fault. > > If you look into your newly created struct file, you will see that the atoms > number 1 and 3 are missing!! Thus the error in the so-scf. > > The reason for that is a bug in symmetso, which used an old class.f > subroutine with a few errors. > > I have fixed and updated SRC_symmetso on the web. > > I also include a correct struct file for SO calculations. > - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 16:24:38 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Ask help for Spin-coupling calculation ==== Peter Blaha submitted the following contribution: ==== > Is the SRC_symmetso update valid for all WIEN97 versions, or just WIEN2k? > I use WIEN97.10. SRC_symmetso is not part of WIEN97. It is new in WIEN2k. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 29 Aug 2002 21:12:41 +0200 From: Liang Ching-Tarng Subject: [WIEN]: Wien and/or SpaceGroups ==== Liang Ching-Tarng submitted the following contribution: ==== Sehr geehrter Herr Blaha, ich schreibe gleich mal auf deutsch, denn ich denke, daß dieses Problem trivial und nicht von allgemeinen Interesse ist... Wir möchten NiO nachrechnen wegen LDA+U. Die antiferromagnetische Ordnung reduziert dieses kubische NaCl-System zu einem rhomboedrischen System, analog zu LiNiO2 mit der Raumgruppe R-3m (166). Der Kristallographischen Konvention folgend würde man a und alpha eingeben, oder a = b = c und alpha = beta = gamma, wobei a_rhom = sqrt(3/2)*a_cub (a_cub = 4.1648 AA) und alpha = 35.56 (cos(alpha) = 5/6 für eine kubische Struktur) sind. Für die Koordinaten hätte man nach Wyckoff Ni_1 (0,0,0) Ni_2 (1/2,1/2,1/2) 0 (1/4,1/4,1/4) [(3/4, 3/4, 3/4) braucht man nicht anzugeben, weil diese Position äquivalent ist mit R-3m] Ihre Eingabe ist im hexagonalen Systsem, mit Ihren Formeln im WienCode Handbuch ergibt sich a_hex = 5.6440 AA und c_hex = 14.440 AA, also eine sehr länglich hexagonale Zelle. Als Eingabe setzt man b_hex = 0 (???), die Winkel setzt man alle Null?? Dann sagt das Handbuch weiter (Kap. 4.3): man solle als Position den Wyckhoffpositionen einsetzen, und zwar für das rhomboedrische System. Aber wie soll das zusammenpassen? Muß nicht alles konvertieren ins hexagonale? Ihr Hilfsprogramm hex2rhomb macht aber genau das umgekehrte? Die Internationale Tabellen und auch Wyckhoff geben auch die hexagonalen Positionen an. Ich kann das nicht verstehen, weil das Programm die Eingaben automatisch ändert. Wenn man es selber die Gruppe suchen läßt, beschwert es sich das Sauerstoff zweimal da ist, aber es findet schon R-3m = 166! Gibt es nicht für das NiO ein wie für TiC ein Beispiel-File, den wir übernehmen können? Grüße und vielen Dank C.T. Liang und D. Schotte ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 30 Aug 2002 12:04:29 +0800 From: Wenhui Xie Subject: [WIEN]: Stop at lapw2 of cycle 2 ==== Wenhui Xie submitted the following contribution: ==== Dear WIEN Users, I get a problem of wien2k. The program stop at : in cycle 2 ETEST: 0 CTEST: 0 GETARG: argument index (2) out of range FORTRAN STOP LAPW0 END GETARG: argument index (2) out of range FORTRAN STOP LAPW1 END GETARG: argument index (2) out of range FORTRAN STOP LAPW1 END GETARG: argument index (2) out of range FORTRAN STOP LAPW2 END GETARG: argument index (2) out of range FORTRAN STOP LAPW2 END GETARG: argument index (2) out of range Input/Output Error 148: Invalid character In Procedure: insld At Line: 95 Statement: Formatted READ Unit: 20 Connected To: crte_wz.struct Form: Formatted Access: Sequential Records Read : 19 Records Written: 0 Current I/O Buffer: 12 NUMBER OF SYMMETRY OPERATIONS ! End of diagnostics Would you please to tell me what's wrong with it? Yours sincerely Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 30 Aug 2002 08:35:39 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Wien and/or SpaceGroups ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-1332553899-1030689339=:555 Content-Type: TEXT/PLAIN; charset=US-ASCII Lieber Hr.Liang Natuerlich haben wir NiO schon oft gerechnet, es ist ja DAS Paradebeispiel fuer LDA+U. Struct file liegt bei. Die Eingabe in WIEN ist for R Gitter wirklich sehr inkonsistent, daher habe ich auch versucht, sie so genau wie moeglich zu beschreiben. Es stimmt tatsaechlich: Sie muessen die "hexagonalen" Gitterkonstanten verwenden, aber die "rhomboedrischen"" Positionen. Das ist, zugegebenermassen, komplett inkonsistent, denn wie sie sagten, entweder sollte man alles im R-setting, oder alles im H setting machen. Leider nicht so programmiert! MfG 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-1332553899-1030689339=:555 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nioU_ldau.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="nioU_ldau.struct" TmlPICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUiAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiAzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICA1LjYwNTIzNiAgNS42MDUyMzYgMjcuNDU5 OTM0IDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNCk5pMSAgICAgICAgTlBUPSAgMzgxICBSMD0wLjAwMDUwMDAwIFJN VD0gICAgMi4zMDAwICAgWjogMjguMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuNTAwMDAwMDAgWT0w LjUwMDAwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAg ICAgICAgSVNQTElUPSA4DQpOaTIgICAgICAgIE5QVD0gIDM4MSAgUjA9MC4w MDA1MDAwMCBSTVQ9ICAgIDIuMzAwMCAgIFo6IDI4LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjI1 MDAwMDAwIFk9MC4yNTAwMDAwMCBaPTAuMjUwMDAwMDANCiAgICAgICAgICBN VUxUPSAyICAgICAgICAgIElTUExJVD0gOA0KICAgICAgLTM6IFg9MC43NTAw MDAwMCBZPTAuNzUwMDAwMDAgWj0wLjc1MDAwMDAwDQpPICAgICAgICAgIE5Q VD0gIDM4MSAgUjA9MC4wMDA1MDAwMCBSTVQ9ICAgIDEuNjUwMCAgIFo6ICA4 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQog IDEyICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUw0KIDEgMCAw IDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAw MA0KICAgICAgIDENCiAxIDAgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAw MDANCiAwIDEgMCAwLjAwMDAwMDANCiAgICAgICAyDQogMCAxIDAgMC4wMDAw MDAwDQogMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAg ICAgMw0KIDAgMCAxIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAwMA0KIDAg MSAwIDAuMDAwMDAwMA0KICAgICAgIDQNCiAwIDEgMCAwLjAwMDAwMDANCiAw IDAgMSAwLjAwMDAwMDANCiAxIDAgMCAwLjAwMDAwMDANCiAgICAgICA1DQog MCAwIDEgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMSAwIDAgMC4w MDAwMDAwDQogICAgICAgNg0KIDAgMC0xIDAuMDAwMDAwMA0KIDAtMSAwIDAu MDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KICAgICAgIDcNCiAwLTEgMCAw LjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCi0xIDAgMCAwLjAwMDAwMDAN CiAgICAgICA4DQogMCAwLTEgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAw DQogMC0xIDAgMC4wMDAwMDAwDQogICAgICAgOQ0KIDAtMSAwIDAuMDAwMDAw MA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAg MTANCi0xIDAgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAwLTEg MCAwLjAwMDAwMDANCiAgICAgIDExDQotMSAwIDAgMC4wMDAwMDAwDQogMC0x IDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogICAgICAxMg0K - ---2105530234-1332553899-1030689339=:555-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 30 Aug 2002 08:41:56 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Stop at lapw2 of cycle 2 ==== Peter Blaha submitted the following contribution: ==== > I get a problem of wien2k. The program stop at : > > in cycle 2 ETEST: 0 CTEST: 0 > GETARG: argument index (2) out of range > FORTRAN STOP LAPW0 END > GETARG: argument index (2) out of range > FORTRAN STOP LAPW1 END > GETARG: argument index (2) out of range > FORTRAN STOP LAPW1 END > GETARG: argument index (2) out of range > FORTRAN STOP LAPW2 END > GETARG: argument index (2) out of range > FORTRAN STOP LAPW2 END > GETARG: argument index (2) out of range > > Input/Output Error 148: Invalid character > In Procedure: insld > At Line: 95 > Statement: Formatted READ > Unit: 20 > Connected To: crte_wz.struct > Form: Formatted > Access: Sequential > Records Read : 19 > Records Written: 0 > Current I/O Buffer: > 12 NUMBER OF SYMMETRY OPERATIONS > ! > End of diagnostics > > > Would you please to tell me what's wrong with it? It's like a quizz game. Give him just a little bit of information and maybe he knows the answer! insld is part of LCORE, so the program stops in lcore. I guess it happens since it would find a positive energy for one of the core orbitals. The reasons for this I can again only speculate: a) You do an "open core" calculation for 4f states ? Increase the shift b) Your input/ struct file is wrong. Check :NEC01 in your scf file. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 30 Aug 2002 15:09:37 +0200 From: Enrique Lomba Subject: [WIEN]: How to set sensible choices for El in case.in1 ==== Enrique Lomba submitted the following contribution: ==== Hello again, I am trying (desperately) to run a calculation for Trigonal Te, and consistently I am getting the message QTL-B VALUE .EQ. 5.22752 !!!!!! in case.scf. From the manual I understand that this is not necesarly the result of a ghost band, but from the fact that linearization has reached its limit. I have tried to fiddle around with the El values in case.in1 adding local orbital.... where can I find some guidelines to set this values. Here is one of the case.in1c files I used WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 -2.19 0.020 CONT 0 0 0.30 0.000 CONT 0 1 -1.00 0.020 CONT 0 1 0.30 0.000 CONT 0 2 0.80 0.020 CONT 1 K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window and here part of the .scf file - --------------------------- ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM Te OVERALL ENERGY PARAMETER IS 0.3000 OVERALL BASIS SET ON ATOM IS LAPW E( 0)= -2.1900 E(BOTTOM)= -2.520 E(TOP)= -1.860 LAPW E( 0)= 0.3000 LOCAL ORBITAL E( 1)= -1.0000 E(BOTTOM)= -1.540 E(TOP)= -0.460 LAPW E( 1)= 0.3000 LOCAL ORBITAL E( 2)= 0.8200 E(BOTTOM)= -0.120 E(TOP)= 1.760 APW+lo K= 0.00000 0.00000 0.00000 1 :RKM : MATRIX SIZE 240LOs: 27 RKM= 6.92 WEIGHT= 1.00 PGR: EIGENVALUES ARE: -2.2046804 -2.1377468 -2.1377468 -1.1229720 -1.1229720 -1.0307893 -0.9778829 -0.9621835 -0.9621835 -0.9192676 -0.9013458 -0.9013458 0.1820136 0.1887096 0.1887096 0.2575385 0.2575385 0.2906676 0.3706620 0.3931053 0.3931053 0.6095509 0.6095509 0.6174805 0.7357479 0.7707214 0.7707214 0.7788895 0.7919586 0.7919587 0.9677639 0.9677639 1.1485932 1.2769433 1.2769433 1.3612111 1.4291974 1.4291974 ******************************************************** NUMBER OF K-POINTS: 149 :GMA : POTENTIAL AND CHARGE CUT-OFF 14.00 Ry**.5 Energy to separate semicore and valencestates: 0.08584 :NOE : NUMBER OF ELECTRONS = 48.000 :FER : F E R M I - ENERGY(TETRAH.M.)= 0.61477 :POS01: AT.NR. -1 POSITION = 0.26400 0.00000 0.33333 MULTIPLICITY = 3 LMMAX=25 LM= 0 0 1 0 2 0 2 2-2 2 3 0 3 2-3 2 4 0 4 2-4 2 4 4-4 4 5 0 5 2-5 2 5 4 -5 4 6 0 6 2-6 2 6 4-6 4 6 6-6 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :CHA01: TOTAL CHARGE INSIDE SPHERE 1 = 14.757799 :PCS01: PARTIAL CHARGES SPHERE = 1 S,P,D,F,PX,PY,PZ,D-Z2,D-X2Y2,D-XY,D-XZ,D-YZ :QTL01: 2.0778 5.5987 6.9971 0.0681 1.8906 1.8453 1.8628 1.2472 1.0846 1.2167 1.1035 2.3451 Q-s-low E-s-low Q-p-low E-p-low Q-d-low E-d-low Q-f-low E-f-low :EPL01: 1.9397 -2.1525 5.4135 -0.9915 0.1575 -1.0932 0.0082 - -1.1322 Q-s-hi E-s-hi Q-p-hi E-p-hi Q-d-hi E-d-hi Q-f-hi E-f-hi :EPH01: 0.1381 0.3861 0.1853 0.4142 6.8396 0.3981 0.0599 0.4306 QXX QXY QYY QZZ UP TO R :VZZ01: 58.79488 -13.59220 -28.30246 -30.49242 2.670 :CHA : TOTAL CHARGE INSIDE UNIT CELL = 48.000000 :SUM : SUM OF EIGENVALUES = -21.520219 QTL-B VALUE .EQ. 5.22752 !!!!!! Any help would be appreciated !!! Regards, Enrique - -- - -------------------------------------------------------------- Enrique Lomba Instituto de Quimica Fisica Rocasolano, CSIC C/ Serrano 119, 28006 Madrid, Spain FAX no. 34-915642431 Phone no. 34-915619407 (ext 1301) e-mail : E.Lomba@iqfr.csic.es www : http://www.fluid.iqfr.csic.es/enrique.html ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 30 Aug 2002 11:05:48 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Wien and/or SpaceGroups ==== Igor Mazin submitted the following contribution: ==== Liebe Herren, Meine Meinung nach, if you had a problem, there is a good chance somebody else may, too. Furthermore, since you do not know the solution, you cannot judge how trivial it is. This is the whole idea of the mailing list! Otherwise you could as well write Peter privately. I refer, of course to your writing in German (I personally have no problem reading German, but others may). More to the point, I'd like to raise another question, pertinent probably to the future releases. In another popular code, Stuttgart LMTO, the user has a possibility to describe the unit cell in Cartesian coordinates as three vectors rather than as three lengths and three angles. For instance, the AFL NIO unit cell would be a/2 a/2 a a/2 a 1/2 a a/2 a/2 I found that extremely convenient for doing reduced symmetry supercells. It looks to me, naively, that this should be quite a small addition to the existing code. Did you ever thought about adding such an option? Igor - --- Peter Blaha wrote: > Lieber Hr.Liang > > Natuerlich haben wir NiO schon oft gerechnet, es ist > ja DAS Paradebeispiel > fuer LDA+U. Struct file liegt bei. > > Die Eingabe in WIEN ist for R Gitter wirklich sehr > inkonsistent, daher habe ich > auch versucht, sie so genau wie moeglich zu > beschreiben. > Es stimmt tatsaechlich: Sie muessen die > "hexagonalen" Gitterkonstanten > verwenden, aber die "rhomboedrischen"" Positionen. > Das ist, zugegebenermassen, > komplett inkonsistent, denn wie sie sagten, entweder > sollte man alles im > R-setting, oder alles im H setting machen. > Leider nicht so programmiert! > > MfG > > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > NiO > > R LATTICE,NONEQUIV. ATOMS: 3 > > MODE OF CALC=RELA > > 5.605236 5.605236 27.459934 90.000000 90.000000 > 90.000000 > ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ni1 NPT= 381 R0=0.00050000 RMT= 2.3000 > Z: 28.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -2: X=0.50000000 Y=0.50000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ni2 NPT= 381 R0=0.00050000 RMT= 2.3000 > Z: 28.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -3: X=0.25000000 Y=0.25000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -3: X=0.75000000 Y=0.75000000 Z=0.75000000 > O NPT= 381 R0=0.00050000 RMT= 1.6500 > Z: 8.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 12 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 > 1 0 0 0.0000000 > 0 0 1 0.0000000 > 0 1 0 0.0000000 > 2 > 0 1 0 0.0000000 > 1 0 0 0.0000000 > 0 0 1 0.0000000 > 3 > 0 0 1 0.0000000 > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 4 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 0 0 0.0000000 > 5 > 0 0 1 0.0000000 > 0 1 0 0.0000000 > 1 0 0 0.0000000 > 6 > 0 0-1 0.0000000 > 0-1 0 0.0000000 > -1 0 0 0.0000000 > 7 > 0-1 0 0.0000000 > 0 0-1 0.0000000 > -1 0 0 0.0000000 > 8 > 0 0-1 0.0000000 > -1 0 0 0.0000000 > 0-1 0 0.0000000 > 9 > 0-1 0 0.0000000 > -1 0 0 0.0000000 > 0 0-1 0.0000000 > 10 > -1 0 0 0.0000000 > 0 0-1 0.0000000 > 0-1 0 0.0000000 > 11 > -1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0-1 0.0000000 > 12 > ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #33 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #34 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Tuesday, September 10 2002 Volume 2002 : Number 034 ---------------------------------------------------------------------- Date: Sat, 31 Aug 2002 02:11:03 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k_02 user: I have a CeX system to calculate. I have calculated it with LSDA, LSDA+SIC ,LSDA+SO+SIC, but I encounter some questions, now first I list my result below: 1: LSDA: ENE: -28342.456753 FER: 0.63687 MMTOT: 0.96610 MMI01:0.83685--------note: 01 refer to Ce MMI02:-0.00321 2:LSDA+SIC a: U=0.43 J=0.05 ENE:-28342.343906 FER: 0.63843 MMTOT: 1.31303 MMI01: 1.13621 MMI02:-0.00311 b: U=0.48 J=0.06 ENE:-28342.334611 FER:0.63844 MMTOT:1.32972 MMI01: 1.15569 MMI02:-0.00340 3:LSDA+SO+SIC: a: U=0.48 J=0.06 ENE:-28342.536933 FER:0.64280 MMTOT:0.07238 MMINT:0.02410 MMI02:0.00034 ORB01:0.34208 b: U=0.56 J=0.07 in this case , the case.scf has message like this: warn energy intergal is 28.999918 should be 29 I also calculate the system with LSDA+SO +OP:the result like this : ENE;-28342.509503 FER: 0.63745 MMTOT:0.47180 MMI01:0.42996 MMI02:-0.00010 ORB01:-2.81328 In all my calculations , I have set EMAX in case.in1 to equal default value 1.5, I also set it to 3.5 when I calculate it with LSDA+SO+OP,the MMTOT became large, but the difference is small SO there are several questions I want to know: 1:according to my understandign,adding spin-orbit coupling ,the magnetis moment of spin will decrease,but in my case when I use LSDA+SO+SIC, the MMI01 decrease to 0.02410,it is to small ,I can't believe it ? is it reasonable or someting wrong with it? 2: Why when I increase the values of U and J to 0.56 and 0.07 ,there are warning in case.scf ? what this mean? And how can this affect the result? How can I handle with it? 3: According to the userguider, in case.inc , in the first line ,there is a "shift" for "positive" energy ,when I calculate a system with 4f element, must I set this "shift" some value insted of zero? if must, how about the range it is? Thanks for your help and advice Hai _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£http://www.hotmail.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 31 Aug 2002 02:09:51 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k_02 user: I have a CeX system to calculate. I have calculated it with LSDA, LSDA+SIC ,LSDA+SO+SIC, but I encounter some questions, now first I list my result below: 1: LSDA: ENE: -28342.456753 FER: 0.63687 MMTOT: 0.96610 MMI01:0.83685--------note: 01 refer to Ce MMI02:-0.00321 2:LSDA+SIC a: U=0.43 J=0.05 ENE:-28342.343906 FER: 0.63843 MMTOT: 1.31303 MMI01: 1.13621 MMI02:-0.00311 b: U=0.48 J=0.06 ENE:-28342.334611 FER:0.63844 MMTOT:1.32972 MMI01: 1.15569 MMI02:-0.00340 3:LSDA+SO+SIC: a: U=0.48 J=0.06 ENE:-28342.536933 FER:0.64280 MMTOT:0.07238 MMINT:0.02410 MMI02:0.00034 ORB01:0.34208 b: U=0.56 J=0.07 in this case , the case.scf has message like this: warn energy intergal is 28.999918 should be 29 I also calculate the system with LSDA+SO +OP:the result like this : ENE;-28342.509503 FER: 0.63745 MMTOT:0.47180 MMI01:0.42996 MMI02:-0.00010 ORB01:-2.81328 In all my calculations , I have set EMAX in case.in1 to equal default value 1.5, I also set it to 3.5 when I calculate it with LSDA+SO+OP,the MMTOT became large, but the difference is small SO there are several questions I want to know: 1:according to my understandign,adding spin-orbit coupling ,the magnetis moment of spin will decrease,but in my case when I use LSDA+SO+SIC, the MMI01 decrease to 0.02410,it is to small ,I can't believe it ? is it reasonable or someting wrong with it? 2: Why when I increase the values of U and J to 0.56 and 0.07 ,there are warning in case.scf ? what this mean? And how can this affect the result? How can I handle with it? 3: According to the userguider, in case.inc , in the first line ,there is a "shift" for "positive" energy ,when I calculate a system with 4f element, must I set this "shift" some value insted of zero? if must, how about the range it is? _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Sep 2002 12:23:57 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Wien and/or SpaceGroups ==== Peter Blaha submitted the following contribution: ==== > More to the point, I'd like to raise another question, > pertinent probably to the future releases. In another > popular code, Stuttgart LMTO, the user has a > possibility to describe the unit cell in Cartesian > coordinates as three vectors rather than as three > lengths and three angles. For instance, the AFL NIO > unit cell would be > a/2 a/2 a > a/2 a 1/2 > a a/2 a/2 > I found that extremely convenient for doing reduced > symmetry supercells. It looks to me, naively, that > this should be quite a small addition to the existing > code. Did you ever thought about adding such an > option? So far: no! I always found it much easier to specify F or B lattice and/or some angles instead of figuring out the proper Bravais matrix, but we may reconsider things if it seems usefull. In The NiO example: With this bravais matrix, how would you specify the atomic positions ? Another point: specifying H or R in WIEN means also using a special coordinate system with all symmetry operations in hex coordinates,.... Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 02 Sep 2002 14:50:22 +0200 From: Enrique Lomba Subject: [WIEN]: Warning regarding Intel libraries for ia32 Linux and Wien2k code ==== Enrique Lomba submitted the following contribution: ==== Dear Wien users, I was having a lot of trouble trying to get results for trigonal Te (ghost states, limit of the linearization process, etc ...), but thanks to Fred Nastos who repeated the same calculation, I found out that the Wien2k code I had compiled was broken. I linked the code with Portland Group pgf90 in various linux boxes (p3 and p4) against the optimized Intel MathKernel libraries, which in other cases seemed to worked nicely (lib_mklp3 and lib_mklp4) and it worked ok in the test cases. In this instance (trigonal Te) it seems the lapw2c program gives wrong results !!!! I recompiled the code using the optimized blas found in http://www.cs.utk.edu/~ghenry/distrib/index.htm and the results now look ok and reproduce the bibliographic data !! In summary, I guess that there is something wrong (or some incompatibility) when lapw2c is compiled using this library. Perhaps someone with more expertise in this particular code could take a look and determine the BLAS routines which are behaving incorrectly and report that to Intel. Thanks to all and regards, Enrique - -- - -------------------------------------------------------------- Enrique Lomba Instituto de Quimica Fisica Rocasolano, CSIC C/ Serrano 119, 28006 Madrid, Spain FAX no. 34-915642431 Phone no. 34-915619407 (ext 1301) e-mail : E.Lomba@iqfr.csic.es www : http://www.fluid.iqfr.csic.es/enrique.html ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 14:13:10 +0430 From: "Saeid Jalali" Subject: [WIEN]: runsp -so -orb ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_000B_01C25354.087440F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, We are running the latest version of wien2k code, 29-Aug-2002. In a = nonmagnetic case, e.g. bct-U, which we would keep the original structure even in the presence of spin-orbit = coupling, lda+u calculation fails at the=20 step of "x lapwdm -up -c -so" in the first cycle. This means that one = has to let the initso reduce the no. of symmetry operations from 48 to 16 (in this case evrything is okay), which is not = our favorite physics. Is this natural? One calculating "runsp -so -orb" and not "runsp -orb" or "runsp -so" = also has to copy case.indm to case.indmc, why? Is doing "mv case.in1 case.in1c" also necessary for a nonmagnetic case = with its original case.struct to run "runsp_c -so -orb"? Your, S. Jalali. - ------=_NextPart_000_000B_01C25354.087440F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear=20 all,

We are running the =
latest version of wien2k code, 29-Aug-2002. In a nonmagnetic case, e.g. bct-U, which =
we
 would keep the original =
structure even in the presence of spin-orbit coupling, lda+u calculation =
fails at the 
step of "x =
lapwdm =96up =96c =96so" in the first cycle. This means that one has to =
let the initso reduce the no. of symmetry
 operations from 48 to 16 (in this case evrything =
is okay), which is not our favorite physics. Is this =
natural?
One calculating =
=93runsp =96so =96orb=94 and not =
=93runsp =96orb=94 or =93runsp =96so=94 also has to copy case.indm to =
case.indmc, why?

Is doing=20 =93mv case.in1 case.in1c=94 also necessary for a nonmagnetic case with = its original=20 case.struct to run =93runsp_c =96so =96orb=94?

 

Your,

S.=20 Jalali.

- ------=_NextPart_000_000B_01C25354.087440F0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 12:01:26 +0200 (MEST) From: Vidya Ravindran Subject: [WIEN]: Conversion from eV --> Tesla ==== Vidya Ravindran submitted the following contribution: ==== Dear All, I am trying to convert energy given in eV to the magnetic field intensity given in Tesla. I am unable to find a direct conversion factor for eV to Tesla I am highly thankful if somebody could suggest the conversion factors or some references where I can find them. Thank you. Yours sincerely, R. Vidya **************************************************************** R. Vidya, Department of Chemistry |Tel: +47 228 55606 University of Oslo, PO Box 1033 |Fax: +47 228 55441/5565 Blindern, N-0315 OSLO, NORWAY | Email: ravindran.vidya@kjemi.uio.no | URL: http://folk.uio.no/~ravindrv | **************************************************************** ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 16:40:55 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0036_01C25368.AC9B0560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I am trying to convert energy given in eV to the magnetic > field intensity given in Tesla. I am unable to find a direct = conversion > factor for eV to Tesla > I am highly thankful if somebody could suggest the conversion > factors or some references where I can find them. I have not seen such a direct formula, but I think it is feasible = writing fundamental formula as follows: I hope the used following symbols are visible in your editor: 1Gauss(G)=3D10-4Tessla(T)=3D10-4Weber(Wb)/m2=3D1Oersted(Oe)=3D103/4pA/m 1eV=3D1eWA=3D=3D=3D>4ep10-7Tessla=3DeV/mW If they are not I would below repeat them in a plain text: 1Gauss(G)=3D10^(-4)Tessla(T)=3D10^(-4)Weber(Wb)/m2=3D1Oersted(Oe)=3D10^3/= (4*3.14)A/m 1eV=3De*ohm*A=3D=3D=3D>4*e*3.14*10^(-7)Tessla=3DeV/m*ohm - ------=_NextPart_000_0036_01C25368.AC9B0560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>      I am = trying to=20 convert energy given in eV to the magnetic
> field intensity given = in=20 Tesla. I am unable to find a direct conversion
> factor for eV to=20 Tesla
> I am highly thankful if somebody could suggest the=20 conversion
> factors or some references where I can find=20 them.
I have not seen such a direct formula, = but I think=20 it is feasible writing fundamental formula as follows:
I hope the used following = symbols are visible=20 in your editor:
1Gauss(G)=3D10-4Tessla(T)=3D10-4Weber(Wb)/m2=3D1Oersted(Oe)=3D103/4pA/m1eV=3D1eWA=3D=3D=3D>4ep10-7Tessla=3DeV/mW
If they are not I would below = repeat them in a plain text:
1Gauss(G)=3D10^(-4)Tessla(T)=3D10^(-4)Weber(Wb)/m2=3D1Oersted(Oe)=3D10^3/(4*3.14)A/m1eV=3De*ohm*A=3D=3D=3D>4*e*3.14*10^(-7)Tessla=3DeV/m*ohm
- ------=_NextPart_000_0036_01C25368.AC9B0560-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 14:45:49 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: runsp -so -orb ==== Peter Blaha submitted the following contribution: ==== >In a nonmagnetic case, e.g. bct-U, which we > would keep the original structure even in the presence of spin-orbit coupling, lda+u calculation fails at the > step of "x lapwdm -up -c -so" in the first cycle. This means that one has to let the initso reduce the no. of symmetry > operations from 48 to 16 (in this case evrything is okay), which is not our favorite physics. Is this natural? WIEN has a constraint: LDA+U calculations must be done in "spin-polarized" mode (But you can use runsp_c_lapw which constrains to zero moment). When doing spinpolarization and adding SO, symmetry must be reduced. This follows naturally from the first constraint. > One calculating "runsp -so -orb" and not "runsp -orb" or "runsp -so" also has to copy case.indm to case.indmc, why? After lapwso the eigenvectors are complex, so one must run the complex versions of lapw2 (always) and lapwdm (this program is called only with -orb) > Is doing "mv case.in1 case.in1c" also necessary for a nonmagnetic case with its original case.struct to run "runsp_c -so -orb"? I think so. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 18:55:53 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: runsp -so -orb ==== "Saeid Jalali" submitted the following contribution: ==== Dear all, First, I would appreciate Peter for his exact answers as usual, and then ask one thing more: Why is only "lapwdm -c -up -so" called during "runsp_c_lapw -so -orb" and not "lapwdm -c -dn -so" looking at :log? Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 10:54:17 -0400 From: Fred Nastos Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== Fred Nastos submitted the following contribution: ==== > > I am trying to convert energy given in eV to the magnetic > > field intensity given in Tesla. I am unable to find a direct conversion > > factor for eV to Tesla I believe that is because a direct conversion factor does not exist. In SI units, the Tesla measures magnetic induction, B, and has dimensions of [mass][charge]^{-1}[time]^{-1}. Still in SI units, the magnetic field, H, has units of Amperes/m and dimensions of [charge][length]^{-1}[time]^{-1}. So, I'm not sure what you mean by "magnetic field intensity given in Tesla". > I have not seen such a direct formula, but I think it is feasible writing > fundamental formula as follows: > 1Gauss(G)=10^(-4)Tessla(T)=10^(-4)Weber(Wb)/m2=1Oersted(Oe) > =10^3/(4*3.14)A/m 1eV=e*ohm*A===>4*e*3.14*10^(-7)Tessla=eV/m*ohm I believe this is dangerous, since, in Gaussian Units, an induction field of one gauss corresponds to a magnetic field of one oersted only in the absence of magnetic materials. Nonetheless, your result shows that to relate magnetic fields and energy you need material information (i.e. the magnetic moment). ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 14:40:16 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== Igor Mazin submitted the following contribution: ==== You guys are making this way too complicated. The conversion factor is just the Bohr magneton, I check the backpage of my Ashcrift-Mermin, one, two, three... 1 mu_B=5.7884E-5 eV/T - --- Fred Nastos wrote: > ==== > Fred Nastos > submitted the following contribution: > ==== > > > > > I am trying to convert energy given in eV to the > magnetic > > > field intensity given in Tesla. I am unable to > find a direct conversion > > > factor for eV to Tesla > > I believe that is because a direct conversion factor > does not exist. > > In SI units, the Tesla measures magnetic induction, > B, and has dimensions of > [mass][charge]^{-1}[time]^{-1}. Still in SI units, > the magnetic field, H, has > units of Amperes/m and dimensions of > [charge][length]^{-1}[time]^{-1}. > So, I'm not sure what you mean by "magnetic field > intensity given in Tesla". > > > I have not seen such a direct formula, but I think > it is feasible writing > > fundamental formula as follows: > > > > 1Gauss(G)=10^(-4)Tessla(T)=10^(-4)Weber(Wb)/m2=1Oersted(Oe) > > =10^3/(4*3.14)A/m > 1eV=e*ohm*A===>4*e*3.14*10^(-7)Tessla=eV/m*ohm > > I believe this is dangerous, since, in Gaussian > Units, an induction field of > one gauss corresponds to a magnetic field of one > oersted only in the absence > of magnetic materials. Nonetheless, your result > shows that to relate magnetic > fields and energy you need material information > (i.e. the magnetic moment). > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Sep 2002 14:50:13 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: Wien and/or SpaceGroups ==== Igor Mazin submitted the following contribution: ==== Well, my position is that it is always nicer to have a choice. - --- Peter Blaha wrote: > > code. Did you ever thought about adding such an > > option? > > So far: no! > I always found it much easier to specify F or B > lattice and/or some angles > instead of figuring out the proper Bravais matrix, > but we may reconsider > things if it seems usefull. Well, my position is that it is always nicer to have a choice. > In The NiO example: With this bravais matrix, how > would you specify the > atomic positions ? The same way. Since the positions are given in terms of the lattice vectors, and the lattice vectors are exactly the same as rhombohedral vectors, the atomic positions are the same. Specifically, for NiO, the unit celee vectors are, in units of a, 1.0 0.5 0.5 0.5 1.0 0.5 0.5 0.5 1.0 And positions are 0.00 0.00 0.00 Ni1 0.50 0.50 0.50 Ni2 0.25 0.25 0.25 O - -.25 -.25 -.25 O What can be simpler? > > Another point: specifying H or R in WIEN means also > using a special > coordinate system with all symmetry operations in > hex coordinates,.... > > Regards > > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Sep 2002 01:59:57 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k users: I have download the version of wien2k,(modified 29 august,) but when I use it to calculate , I find there are always the sign of "ghost band"in case.scf file. I have test it to calculate a system with SO+LDA+U, but whatever I change the value U,J, the sentnece like "QTL_B Value .EQ. 0.xxxxxxx" always appear in my case.file . I thought it may be my fault in add SO+LDA+U, so I change to test it with the example Ni in userguide, but to my surprise , the sentence "QTL_B Value .EQ. 7.09128" also appear!!!, I can hardly believe it !!!. why can this be?Did anyone else also encounter this porblem? I am so puzzled about this _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 09:45:02 +0430 From: "Saeid Jalali" Subject: [WIEN]: Re: ==== "Saeid Jalali" submitted the following contribution: ==== > I have download the version of wien2k,(modified 29 august,) but when I > use it to calculate , I find there are always the sign of "ghost band"in > case.scf file. I have test it to calculate a system with SO+LDA+U, but > whatever I change the value U,J, the sentnece like "QTL_B Value .EQ. > 0.xxxxxxx" always appear in my case.file . I thought it may be my fault in > add SO+LDA+U, so I change to test it with the example Ni in userguide, but > to my surprise , the sentence "QTL_B Value .EQ. 7.09128" also appear!!!, I > can hardly believe it !!!. why can this be?Did anyone else also encounter > this porblem? I am so puzzled about this Did you see http://www.wien2k.at/reg_user/faq/scf.html ? Meanwhile, I have found that using "-in1new 5" is very reliable, though many think it is dangerous. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 10:36:32 +0430 From: "Saeid Jalali" Subject: [WIEN]: Re: ==== "Saeid Jalali" submitted the following contribution: ==== > 3: According to the userguider, in case.inc , in the first line ,there > is a "shift" for "positive" energy ,when I calculate a system with 4f > element, must I set this "shift" some value insted of zero? if must, how > about the range it is? Did you see http://www.wien2k.at/reg_user/faq/open_core.html ? For sure, open core calculation is another approach to put some localized 4f-electrons from valence state into the core. In this approach one cannot make choice how far from Fermi energy electrons can be. This means that the 4f-electrons can be regularly (LDA) in the valence state (at the Fermi energy) or using the open core treatment in the core region. Implemented LDA+U now is more reliable approach with its adjustable parameters to play with DOS's. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 08:44:10 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: runsp -so -orb ==== Peter Blaha submitted the following contribution: ==== > Why is only "lapwdm -c -up -so" called during "runsp_c_lapw -so -orb" and > not "lapwdm -c -dn -so" looking at :log? lapwdm calculates the density matrices inside spheres. This is needed ONLY for the orbital potentials, not for a standard LDA(GGA) calculation, even when spin-orbit is included. After runsp -so has finished, one can use lapwdm to calculate an orbital moment, but there is no need to do this during scf. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 09:02:36 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== > I have download the version of wien2k,(modified 29 august,) but when I > use it to calculate , I find there are always the sign of "ghost band"in > case.scf file. I have test it to calculate a system with SO+LDA+U, but > whatever I change the value U,J, the sentnece like "QTL_B Value .EQ. > 0.xxxxxxx" always appear in my case.file . I thought it may be my fault in > add SO+LDA+U, so I change to test it with the example Ni in userguide, but > to my surprise , the sentence "QTL_B Value .EQ. 7.09128" also appear!!!, I > can hardly believe it !!!. why can this be?Did anyone else also encounter > this porblem? I am so puzzled about this A small QTL-B value does NOT mean that you have ghost bands! The QTL-B value is the contribution to the wavefunction (charge) from the B_lm u-dot term in the basis. When you consider that this u-dot term is used to account for the energy dependence of the radial wavefunction, it is clear that this B_lm term should always be smaller than the A_lm term (it should be a correction to the A_lm). Obviously, the better your choice of the energy parameters is, the smaller the correction. Thus "better" energy parameters should give smaller QTL-B. However, depending on the system, you may always find some small QTL-B warnings, since e.g. a 3d wavefunction has a very strong energy dependence, but may still contribute over a fairly wide energy range to the eigenvalue spectrum. In such cases one can further improve the situation by adding a 3d "local-orbital". However, be carefull, you must be sure that the energy parameters of the regular 3d-LAPW and the 3d -LO are at least about 0.5 Ry apart, otherwise you may get real ghostbands due to nearly degenerate basis functions. Only QTL-B values larger than 20-30 mean that you have actual ghostbands. QTL-B between 5 and 10 suggests that you analyse the situation (check the help files and/or the :EPL :EPH lines in the scf file), change the energy parameters by hand (case.in1) or use the -in1new switch of run_lapw. But there may be examples where you can (or must) stay with such QTL-B. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 13:15:49 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: runsp -so -orb ==== "Saeid Jalali" submitted the following contribution: ==== > > Why is only "lapwdm -c -up -so" called during "runsp_c_lapw -so -orb" and > > not "lapwdm -c -dn -so" looking at :log? > > lapwdm calculates the density matrices inside spheres. This is needed ONLY > for the orbital potentials, not for a standard LDA(GGA) calculation, even > when spin-orbit is included. > After runsp -so has finished, one can use lapwdm to calculate an orbital > moment, but there is no need to do this during scf. Yes, you can say that again and I like to thank you very much, but to show I have not realized yet let me please continue in this respect: The question is in the presence of orbital potential, as it is indicated by -orb, and I would emphasis why only up density matrices are calculated and not down density matrices. Please notice that this is not the case during "runsp -orb". This means that both "lapwdm -up" and "lapwdm -dn" are called in the absence of -so, but only "lapwdm -up" in the presence of -so. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 10:55:30 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: runsp -so -orb ==== Peter Blaha submitted the following contribution: ==== > > > Why is only "lapwdm -c -up -so" called during "runsp_c_lapw -so -orb" > and > > > not "lapwdm -c -dn -so" looking at :log? > > > > lapwdm calculates the density matrices inside spheres. This is needed ONLY > > for the orbital potentials, not for a standard LDA(GGA) calculation, even > > when spin-orbit is included. > > After runsp -so has finished, one can use lapwdm to calculate an orbital > > moment, but there is no need to do this during scf. > Yes, you can say that again and I like to thank you very much, but to show I > have not realized yet let me please continue in this respect: > The question is in the presence of orbital potential, as it is indicated > by -orb, and I would emphasis why only up density matrices are calculated > and not down density matrices. Please notice that this is not the case > during "runsp -orb". This means that both "lapwdm -up" and "lapwdm -dn" are > called in the absence of -so, but only "lapwdm -up" in the presence of -so. Spin-orbit couples spin-up and dn, i.e. an eigenvector of a single eigenvalue may contain both, spinup and dn contribution. Thus one cannot seperate the eigenvalues into spin-up and dn eigenvalues anymore. When processing the i-th eigenvalue, both spin-up AND spin-dn AND the spin-up-dn cross terms !! are calculated at once. Thus you need only one call to lapwdm. Without SO, I must call lapwdm separately for spin-up and dn since for up ONLY the up eigenvalues and for dn only dn-eigenvalues are present. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 15:08:47 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: runsp -so -orb ==== "Saeid Jalali" submitted the following contribution: ==== > Spin-orbit couples spin-up and dn, i.e. an eigenvector of a single eigenvalue > may contain both, spinup and dn contribution. Thus one cannot seperate the > eigenvalues into spin-up and dn eigenvalues anymore. When processing the i-th > eigenvalue, both spin-up AND spin-dn AND the spin-up-dn cross terms !! are > calculated at once. Thus you need only one call to lapwdm. Therefore, one concludes that with SO even for a magnetic case up-DOSs and dn-DOSs are alike. To make it more complicated, one can consider a case with two inequivalent atoms, and turn on the SO only for one atom, which is possible now in wien code: turning off the SO for another atom. In this case, up and dn density matrices should be calculated for one atom and only up density matrices for the other atom. I cannot imagine how practically it is performed. Partial DOSs can be separated as spheres are separated, but I cannot think about the total-DOS. Please forgive me for severely asking trivial questions. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Sep 2002 11:04:36 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Re: ==== "Yue Hai" submitted the following contribution: ==== Dear Sasid: According to your help, does it mean that When use LDA+U, it is not need to shift potential in case.inc? And LDA+U have a better result than open core treament? Hai >From: "Saeid Jalali" >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: [WIEN]: Re: >Date: Wed, 4 Sep 2002 10:36:32 +0430 > >==== >"Saeid Jalali" >submitted the following contribution: >==== > > > 3: According to the userguider, in case.inc , in the first line ,there > > is a "shift" for "positive" energy ,when I calculate a system with 4f > > element, must I set this "shift" some value insted of zero? if must, how > > about the range it is? > >Did you see http://www.wien2k.at/reg_user/faq/open_core.html ? For sure, >open core calculation is another approach to put some localized 4f-electrons >from valence state into the core. In this approach one cannot make choice >how far from Fermi energy electrons can be. This means that the 4f-electrons >can be regularly (LDA) in the valence state (at the Fermi energy) or using >the open core treatment in the core region. Implemented LDA+U now is more >reliable approach with its adjustable parameters to play with DOS's. >Your, >S. Jalali. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Sep 2002 11:13:11 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Re: your mail ==== "Yue Hai" submitted the following contribution: ==== Dear Peter: Thanks for your help. And I want to know , if the QTL-B is small, can I ignore it? And how does it affect our calculation? Hai >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: [WIEN]: Re: your mail >Date: Wed, 4 Sep 2002 09:02:36 +0200 (MEST) > >==== >Peter Blaha >submitted the following contribution: >==== > > > I have download the version of wien2k,(modified 29 august,) but when I > > use it to calculate , I find there are always the sign of "ghost band"in > > case.scf file. I have test it to calculate a system with SO+LDA+U, but > > whatever I change the value U,J, the sentnece like "QTL_B Value .EQ. > > 0.xxxxxxx" always appear in my case.file . I thought it may be my fault in > > add SO+LDA+U, so I change to test it with the example Ni in userguide, but > > to my surprise , the sentence "QTL_B Value .EQ. 7.09128" also appear!!!, I > > can hardly believe it !!!. why can this be?Did anyone else also encounter > > this porblem? I am so puzzled about this > >A small QTL-B value does NOT mean that you have ghost bands! > >The QTL-B value is the contribution to the wavefunction (charge) from the >B_lm u-dot term in the basis. When you consider that this u-dot term is >used to account for the energy dependence of the radial wavefunction, it is >clear that this B_lm term should always be smaller than the A_lm term >(it should be a correction to the A_lm). Obviously, the better your choice >of the energy parameters is, the smaller the correction. Thus "better" >energy parameters should give smaller QTL-B. However, depending on the >system, you may always find some small QTL-B warnings, since e.g. a 3d >wavefunction has a very strong energy dependence, but may still contribute >over a fairly wide energy range to the eigenvalue spectrum. In such cases >one can further improve the situation by adding a 3d "local-orbital". >However, be carefull, you must be sure that the energy parameters of the >regular 3d-LAPW and the 3d -LO are at least about 0.5 Ry apart, otherwise >you may get real ghostbands due to nearly degenerate basis functions. > >Only QTL-B values larger than 20-30 mean that you have actual ghostbands. > >QTL-B between 5 and 10 suggests that you analyse the situation (check the >help files and/or the :EPL :EPH lines in the scf file), change the >energy parameters by hand (case.in1) or use the -in1new switch of run_lapw. >But there may be examples where you can (or must) stay with such QTL-B. > >Regards > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 17:29:12 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Re: ==== "Saeid Jalali" submitted the following contribution: ==== >does it mean that When use LDA+U, it is not need > to shift potential in case.inc? It is not needed in LDA+U scheme to change case.inc file: it is a trick in open core calculation. Indeed, shifting in LDA+U scheme is a job for added orbital dependent potential, and one controls it using U and J, and in some special cases changing the diagonal elements of density matrices. The later one, which is not recommended for any cases by the author, means that changing the initial values of occupation numbers may change the final result to a better agreement with experiment. This would not be so surprising as really a compound is a chaotic system! Even though chaos is a classical phenomena with exact definition, one would extend it to quantum mechanics taking into account different density of states within different initial values. > And LDA+U have a better result than open > core treament? Basically, yes it has, or at least one wishes so as one is free now to struggle with more flexible parameters. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 12:47:57 -0400 From: Fred Nastos Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== Fred Nastos submitted the following contribution: ==== > The conversion factor is just the Bohr magneton, > I check the backpage of my Ashcrift-Mermin, one, two, three... > 1 mu_B=5.7884E-5 eV/T The Bohr magneton is the conversion factor to convert magnetic dipoles given in ev/T to Rydberg atomic units (for Hartree a.u. it is twice the Bohr magneton). It is not a conversion factor for Teslas to eV. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 12:16:14 -0700 (PDT) From: yanming Ma Subject: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== yanming Ma submitted the following contribution: ==== - --0-232292027-1031166974=:5675 Content-Type: text/plain; charset=us-ascii Dear wien2k users, I am using the AIM program in WIEN2k. When I calculated the critical points for some materials. The AIM runs without stopping. I know the discontinuities appear at the sphere boundary. According to the User guides of wien2k, I have gotten the as little "core-leakage" as possible from LSTART. But I don't know how to increase properly the default LM-list to LM=8 or 10 without causing other problems. I would appreciate highly all kinds of comments. Thanks in advance. - --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes - --0-232292027-1031166974=:5675 Content-Type: text/html; charset=us-ascii

Dear wien2k users,

I am  using the AIM program in WIEN2k. When I calculated the critical points for some materials. The AIM runs without stopping. I know the discontinuities appear at the sphere boundary. According to the User guides of wien2k, I have gotten the as little "core-leakage" as possible from LSTART. But I don't know how to increase properly the default LM-list to LM=8 or 10 without causing other problems. 

I would appreciate highly all kinds of comments. 

Thanks in advance. 


Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes - --0-232292027-1031166974=:5675-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Sep 2002 20:26:13 GMT From: "Luis Alberto Terrazos Javier" Subject: [WIEN]: allocate data object ==== "Luis Alberto Terrazos Javier" submitted the following contribution: ==== Dear wien users and developers I have a system with 80 atoms per unit cell with 7 non-equivelent atoms in this case it are calculating without problem I have the same system with 80 atoms per unit cell with 13 non-equivalent atoms but when are calculating lapw1 stop with this error: 1525-108 Error encountered while attempting to allocate a data object. The prog ram will stop. I compiled with NMATMAX=10000 and with a 2gb memory ram in a sp2 machine in the moment was stop the program it is using only 100Mb of memory ram. I looking for the similar error in the digest list but I did not encounter the solution for this problem. I would like to know where is the mistake. Thanks for you help luis ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Sep 2002 20:26:26 -0700 (PDT) From: morteza jamal Subject: [WIEN]: d Orbital existence ==== morteza jamal submitted the following contribution: ==== Dear Win2k users. Is the d orbital existence, effective in the selection Muffin tin radius. __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 10:26:28 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0130_01C254C6.B20190A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I am using the AIM program in WIEN2k. When I calculated the critical = points for some materials. The AIM runs without >stopping. I know the = discontinuities appear at the sphere boundary. According to the User = guides of wien2k, I have gotten >the as little "core-leakage" as = possible from LSTART. But I don't know how to increase properly the = default LM-list to >LM=3D8 or 10 without causing other problems.=20 To make LM=3D8 one needs to change LM combinations in case.in2 file as = follows: 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 2 = 7 4 7 6 8 0 8 2 8 4 8 6 8 8 One can follow the logic to make higher LM combinations. Your, S. Jalali. - ------=_NextPart_000_0130_01C254C6.B20190A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>I am  using the AIM program in WIEN2k. When I calculated = the=20 critical points for some materials. The AIM runs without = >stopping. I=20 know the discontinuities appear at the sphere boundary. According to the = User=20 guides of wien2k, I have gotten >the as little "core-leakage" as = possible from LSTART. But I don't know how to increase properly the = default=20 LM-list to >LM=3D8 or 10 without causing other problems. 
 
To make LM=3D8 one needs to = change LM=20 combinations in case.in2 file as follows:

0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 = 8 8

0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 = 6 4 6 6 7=20 0 7 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8

One can follow the logic to = make higher LM=20 combinations.

Your,

S. = Jalali.

- ------=_NextPart_000_0130_01C254C6.B20190A0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 11:21:50 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== "Saeid Jalali" submitted the following contribution: ==== > > The conversion factor is just the Bohr magneton, > > I check the backpage of my Ashcrift-Mermin, one, two, three... > > 1 mu_B=5.7884E-5 eV/T > > The Bohr magneton is the conversion factor to convert magnetic > dipoles given in ev/T to Rydberg atomic units (for Hartree a.u. it is > twice the Bohr magneton). It is not a conversion factor for Teslas > to eV. I'll say. > > > I am trying to convert energy given in eV to the magnetic > > > field intensity given in Tesla. I am unable to find a direct conversion > > > factor for eV to Tesla > > I believe that is because a direct conversion factor does not exist. Real part of the complex Poynting vector is the key to establish that such a conversion factor varies from one case to another case depending on material information (both geometric shape and magnetic properties). From Poynting vector we know that there is a relationship between density of energy (u) and E and B fields: u=1/(16*pi)*( epsilon*E^2+1/mu*B^2). Since it is easier to think about electric field, I would go through the problem keeping only the first term of the above equation regardless the constant factor, i.e. u=epsilon*E^2. This relation between density of energy (energy per volume) and electric field implies that one can find self-energy of a known charge distribution via integrating of the generated E field of the charge distribution over all space. Hence, conversion factor, which is in general accessible after integrating, varies by the geometry of the charge distribution and dielectric constants of the substance and its environment. The same story describes how the conversion factor varies by the geometry of a current distribution and magnetic permeailities of the substances and its environment. Dose this mean that the original question (conversion factor for Tessla to eV) is meaningless? The answer is: no it is not meaningless but it is useless due to non-unique-answer. Your, S. Jalali. My previous answer works just for some simple special cases. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 11:00:47 +0200 (MEST) From: Ponniah Vajeeston Subject: [WIEN]: reference of the open-core approximation ==== Ponniah Vajeeston submitted the following contribution: ==== Dear WIEN users, I am looking for the exact reference of the open-core approximation. I will appreciate if somebody can help me. Regards, P.Vajeeston ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 12:10:49 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: reference of the open-core approximation ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > Ponniah Vajeeston > submitted the following contribution: > ==== > > I am looking for the exact reference of the open-core approximation. > I will appreciate if somebody can help me. I don't think there is one unique source. In M. Richter, J. Phys. D: Appl. Phys. 31 (1998) 1017-1048 you find under par. 2.2 an overview of early papers that apply and/or devellop this approximation. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 14:48:50 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: reference of the open-core approximation ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0007_01C254EB.59134CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I am looking for the exact reference of the open-core approximation. > I will appreciate if somebody can help me. I do not know what you mean exact, but I find the following references = useful: 1. M. Richter, J. Phys. D: Appl. Phys. 31, 1017 (1998). 2.M. Divi=A1s, K. Schwarz, P. Blaha, G. Hilscher, H. Michor, and S. = Khmelevskyi, Phys. Rev. B 62, 6774 (2000). Your, S. Jalali. - ------=_NextPart_000_0007_01C254EB.59134CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> I am looking for the exact = reference of the=20 open-core approximation.
> I will appreciate if somebody can help=20 me.
I do not know what you mean exact, but = I find the=20 following references useful:
1. M. Richter, J. Phys. D: Appl. = Phys. 31,=20 1017 (1998).

2.M. Divi=A1s, K. Schwarz, = P. Blaha, G.=20 Hilscher, H. Michor, and S. = Khmelevskyi, Phys.=20 Rev. B 62, 6774 (2000).

Your,

S. Jalali.

 - ------=_NextPart_000_0007_01C254EB.59134CC0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 05 Sep 2002 14:13:43 +0200 From: Thomas Claesson Subject: [WIEN]: Strange LDA+U behaviour ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I have a very strange behaviour to report, which ocurred when I tried to run an LDA+U calculation on NiO in the AF II configuration. I am able to run both on an ordinary Linux PC (P4 1.5 GHz) and on a multiprocessor AIX system (an IBM SP2), where I run in parallel. This is what I first tried on both systems: 1) runsp_c_lapw (i.e. NOT LDA+U) 2) runsp_c_lapw -orb (U=0.59, J=0.07 Ry) Step 1) converged nicely without any problems on both systems. When I tried 2) it converged after about 30-40 cycles and some small oscillations on the SP2. On my PC however it was impossible to make it converge using this approach. When I calculated DOS and bandstructure (X-gamma-Z direction) on the SP2 I found to my great surprise that there was no gap at the Fermi level! With LDA+U there should certainly be a gap, see for instance O. Bengone et. al, PRB 62,16392 (2000). Then I tried to make it converge also on the PC, so I started from a low U-value, and increased U in steps of about 0.1 Ry, running to self consistency for each U-value. With a reduced mixing factor (0.03) I managed to converge it on the PC this way. When I calculated DOS and bandstructure (X-gamma-Z direction) again, I now found the expected gap at the Fermi level! This made me happy and at the same time very puzzled. How can it be that two runs, made on different computers, that should be identical can differ so much? Later I tried the same method on the SP2 (increasing U gradually with a low mixing factor), but with the same result (no gap). When I make runs without LDA+U I get identical results on both machines. I have used RKmax = 7.0 and a k-mesh of 300-600 points in the entire BZ. The only thing I can think of that should differ between these two systems is the precision, probably the SP2 has greater precision than my PC, where I run the executables. On the SP2 I have compiled the source with xlf90. I am using the latest version of the code on both machines. Thanks for your replies! Any suggestions are welcome! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 05:35:43 -0700 (PDT) From: yanming Ma Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== yanming Ma submitted the following contribution: ==== - --0-1927393837-1031229343=:49205 Content-Type: text/plain; charset=us-ascii Dear Saeid Jalali, Thanks very much for your reply. Do I need change the NCOM in param.inc file? I remeber someone in the maillist said " The Maximum LM can be only 6 when the parameter NCOM equal to 49. So question is how large the NCOM should be when LM set to be 8. Yanming Saeid Jalali wrote:>I am using the AIM program in WIEN2k. When I calculated the critical points for some materials. The AIM runs without >stopping. I know the discontinuities appear at the sphere boundary. According to the User guides of wien2k, I have gotten >the as little "core-leakage" as possible from LSTART. But I don't know how to increase properly the default LM-list to >LM=8 or 10 without causing other problems. To make LM=8 one needs to change LM combinations in case.in2 file as follows: 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8 One can follow the logic to make higher LM combinations. Your, S. Jalali. - --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes - --0-1927393837-1031229343=:49205 Content-Type: text/html; charset=us-ascii

Dear Saeid Jalali,

Thanks very much for your reply. Do I need change the NCOM in param.inc file? I remeber someone in the maillist said " The Maximum LM can be only 6 when the parameter NCOM equal to 49. So question is how large the NCOM should be when LM set to be 8.

Yanming  

 Saeid Jalali wrote:

>I am  using the AIM program in WIEN2k. When I calculated the critical points for some materials. The AIM runs without >stopping. I know the discontinuities appear at the sphere boundary. According to the User guides of wien2k, I have gotten >the as little "core-leakage" as possible from LSTART. But I don't know how to increase properly the default LM-list to >LM=8 or 10 without causing other problems. 
 
To make LM=8 one needs to change LM combinations in case.in2 file as follows:

0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8

0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8

One can follow the logic to make higher LM combinations.

Your,

S. Jalali.


Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes - --0-1927393837-1031229343=:49205-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 19:27:21 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_000C_01C25512.4192B0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Do I need change the NCOM in param.inc file? I remeber someone in the = maillist said " The Maximum LM can be only 6=20 >when the parameter NCOM equal to 49. So question is how large the NCOM = should be when LM set to be 8. Default used number of LM components in charge representation is 91, = which must satisfy the following condition: NCOM+3>(number of LM with m=3D0)+2*(number of LM with m>0) Now, let's check it for your LM=3D8 case: NCOM+3=3D91+3=3D94 which is for sure grater than (9)+2*(16)=3D41. I am not sure if one should also count the combination with negative M = or not, but still 94 is grater than (9)+4*(16)=3D73. So you would go ahead, or at least give the later suspection a check for = LM>8. Your, S. jalali. - ------=_NextPart_000_000C_01C25512.4192B0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Do I need change the NCOM in param.inc file? I remeber = someone in=20 the maillist said " The Maximum LM can be only 6
>when the parameter NCOM equal to 49. So question is how large = the=20 NCOM should be when LM set to be 8.
 
Default used number of LM components in charge = representation is 91,=20 which must satisfy the following condition:
NCOM+3>(number of LM with m=3D0)+2*(number of LM with = m>0)
 
Now, let's check it for your LM=3D8 case:
NCOM+3=3D91+3=3D94=20 which is for sure grater than (9)+2*(16)=3D41.
I am not sure if one should also = count the=20 combination with negative M or not, but still 94 is grater than=20 (9)+4*(16)=3D73.
So you = would go ahead,=20 or at least give the later suspection a check for=20 LM>8.
Your,
S. jalali.
 
- ------=_NextPart_000_000C_01C25512.4192B0A0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 11:21:13 -0400 From: Jeff Spirko Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== Jeff Spirko submitted the following contribution: ==== On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote: > >I am using the AIM program in WIEN2k. When I calculated the critical > points for some materials. The AIM runs without >stopping. I know the > discontinuities appear at the sphere boundary. According to the User > guides of wien2k, I have gotten >the as little "core-leakage" as > possible from LSTART. But I don't know how to increase properly the > default LM-list to >LM=8 or 10 without causing other problems. > To make LM=8 one needs to change LM combinations in case.in2 file as > follows: > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 > 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8 This is not necessarily true. You need to look at the symmetry of the atom (in the .outputs file) and pick the correct LM list from the WIEN2k usersguide (Section 7.4 on lapw2). - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 03:01:19 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== "Saeid Jalali" submitted the following contribution: ==== > On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote: > > >I am using the AIM program in WIEN2k. When I calculated the critical > > points for some materials. The AIM runs without >stopping. I know the > > discontinuities appear at the sphere boundary. According to the User > > guides of wien2k, I have gotten >the as little "core-leakage" as > > possible from LSTART. But I don't know how to increase properly the > > default LM-list to >LM=8 or 10 without causing other problems. > > > To make LM=8 one needs to change LM combinations in case.in2 file as > > follows: > > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 > > 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 > > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8 > > This is not necessarily true. You need to look at the symmetry of > the atom (in the .outputs file) and pick the correct LM list from > the WIEN2k usersguide (Section 7.4 on lapw2). Yes, certainly the LM list depends on the point group of the atom, which is considered by the symmetry program to generate a right LM list for each inequivalent atom. Thus, it is easier to use the generated list in the in2 file, and just follow the logic of the list to add more combinations to the list(s) instead of using those complicated tables. Two above listed LM's are just an example to show how one would follow the logic, and I would here to thank you for your on time alert. Indeed, lower symmetry corresponds to longer list. This means that lower symmetry corresponds to higher splitting. This says that lower symmetry corresponds to more irreducible representations, which are absolutely depending on the symmetry. For example in the worst case with no any symmetries one easily sees that for L=6 there are exactly 49 LM pairs: To show this I am willing to sum the (2L+1) from L=0 to L=6: (0+1)+(2*1+1)+(2*2+1)+(2*3+1)+(2*4+1)+(2*5+1)+(2*6+1)=1+3+5+7+9+11+13=49. >I am not sure if one should also count the combination with negative M or not I have checked it out generating many case.in2 files form various case.struct with different ISPLITs, and found that negative M's are also considered by the program if they are needed. It is worth to mention that since the number of LM lists are equal to the number of inequivalent atoms, one considers the lowest symmetry or longest LM list to count the LM combination to check the condition on NCOM: I had done it for the above two LM lists as an example in my last email. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Sep 2002 16:30:24 -0700 (PDT) From: Michelle Johannes Subject: [WIEN]: monoclinic cell ==== Michelle Johannes submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---307652566-650165112-1031268624=:6826 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Wien users: I am trying to calculate a monoclinic cell with b as the unique axis. The space group is #14, but I am unsure of the setting, although I know that I want b to be the unique axis (beta is not 90). Therefore, I decided to simply put in all the positions by hand rather than selecting a specific group. Here is the relevant part of the .struct file: P LATTICE,NONEQUIV. ATOMS: 1 MODE OF CALC=RELA 12.545897 12.893606 11.939294 90.000000104.000000 90.000000 However when I do this and then run sgroup, the output switches the labels of my axes and angles. I think it orders them according to length, with a being the shortest. Since my b axis is longest, it is called "c" in the output and though I input beta=104, the output shows gamma=104: Bravais lattice: Monoclinic primitive a b c 15.08216567 12.54589700 12.89360600 alpha beta gamma 90.00000000 90.00000000 129.81621960 I have no problem with the renaming of the axes since the angle is consistent, but should I now switch my atomic coordinates or is it reading them properly? I am attaching my .struct file and the .outputsgroup file in case my explanation is not clear. Thank you for your help, Michelle - ---307652566-650165112-1031268624=:6826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mono.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mono.struct" VGl0bGUNClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogMSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEENCiAx Mi41NDU4OTcgMTIuODkzNjA2IDExLjkzOTI5NCA5MC4wMDAwMDAxMDQuMDAw MDAwIDkwLjAwMDAwMA0KQXRvbT0gLTE6IFg9MC4yODE2MDAwMCBZPTAuMTU1 ODAwMDAgWj0wLjA5NzU4MDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAg ICBJU1BMSVQ9IDgNCkF0b209IC0xOiBYPTAuMjE4NDAwMDAgWT0wLjY1NTgw MDAwIFo9MC40MDI0MDAwMA0KQXRvbT0gLTE6IFg9MC43MTg0MDAwMCBZPTAu ODQ0MjAwMDAgWj0wLjkwMjQwMDAwDQpBdG9tPSAtMTogWD0wLjc4MTYwMDAw IFk9MC4zNDQyMDAwMCBaPTAuNTk3NTgwMDANCkV1ICAgICAgICAgTlBUPSAg NzgxICBSMD0wLjAwMDAxMDAwIFJNVD0gICAgMi4wMDAwICAgWjogNjMuMA0K ICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgMCBTWU1NRVRSWSBPUEVSQVRJT05T Og0K - ---307652566-650165112-1031268624=:6826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mono.outputsgroup" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mono.outputsgroup" QnJhdmFpcyBsYXR0aWNlOiBNb25vY2xpbmljIHByaW1pdGl2ZQ0KDQogICAg IGEgICAgICAgICAgICAgYiAgICAgICAgICAgIGMNCiAxNS4wODIxNjU2NyAg ICAxMi41NDU4OTcwMCAgIDEyLjg5MzYwNjAwDQogICAgIGFscGhhICAgICAg ICAgYmV0YSAgICAgICAgIGdhbW1hDQogOTAuMDAwMDAwMDAgICAgOTAuMDAw MDAwMDAgICAxMjkuODE2MjE5NjANCg0KDQo9PT09PSBEZWNvbXBvc2l0aW9u IG9mIG5ldyBiYXNpcyB2ZWN0b3JzIG92ZXIgaW5wdXQgYmFzaXMgPT09PT0N CiAxLjAwMDAwMCAgIDAuMDAwMDAwICAxLjAwMDAwMCAgPC0tLSAxDQotMS4w MDAwMDAgICAwLjAwMDAwMCAgMC4wMDAwMDAgIDwtLS0gMg0KIDAuMDAwMDAw ICAtMS4wMDAwMDAgIDAuMDAwMDAwICA8LS0tIDMNCg0KPT09PSBOdW1iZXIg b2YgYXRvbXMgaW4gY2VsbDogNA0KPT09PSBBdG9tIHBvc2l0aW9uczoNCg0K IDAuNTk3NTkwMDAgICAwLjgxNTk5MDAwICAwLjg0NDIwMDAwDQogRXUNCiAw LjkwMjQxMDAwICAgMC4xODQwMTAwMCAgMC4zNDQyMDAwMA0KIEV1DQogMC40 MDI0MTAwMCAgIDAuMTg0MDEwMDAgIDAuMTU1ODAwMDANCiBFdQ0KIDAuMDk3 NTkwMDAgICAwLjgxNTk5MDAwICAwLjY1NTgwMDAwDQogRXUNCg0KPT09PSBO dW1iZXIgb2Ygbm9uZXF1aXZhbGVudCBzb3J0czogMQ0KPT09PSBOb25lcXVp dmFsZW50IGF0b21zLCBwb2ludCBncm91cCBmb3IgZWFjaCBzb3J0OiA9PT09 DQoNClNvcnQgbnVtYmVyOiAxDQogIE5hbWVzIG9mIHBvaW50IGdyb3VwOiAx ICAgICAgMSAgICAgIEMxDQogIE5ldyBiYXNpcyB2ZWN0b3JzIGZvciB0aGlz IHBvaW50IGdyb3VwOg0KICAgIDEuMDAwMCAgIDAuMDAwMCAgMC4wMDAwICA8 LS0tIDENCiAgICAwLjAwMDAgICAxLjAwMDAgIDAuMDAwMCAgPC0tLSAyDQog ICAgMC4wMDAwICAgMC4wMDAwICAxLjAwMDAgIDwtLS0gMw0KDQogIEF0b20g cG9zaXRpb25zOiA0DQogICAwLjU5NzU5MDAwICAgMC44MTU5OTAwMCAgMC44 NDQyMDAwMA0KICAgRXUNCiAgIDAuOTAyNDEwMDAgICAwLjE4NDAxMDAwICAw LjM0NDIwMDAwDQogICBFdQ0KICAgMC40MDI0MTAwMCAgIDAuMTg0MDEwMDAg IDAuMTU1ODAwMDANCiAgIEV1DQogICAwLjA5NzU5MDAwICAgMC44MTU5OTAw MCAgMC42NTU4MDAwMA0KICAgRXUNCg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KDQpOdW1iZXIgYW5kIG5hbWUgb2Ygc3BhY2UgZ3JvdXA6IDE0IChQ IDIxL2MpIFt1bmlxdWUgYXhpcyBjXSBjZWxsIGNob2ljZSAxDQotIFNob3J0 IC0gRnVsbCAtIFNjaG9lbmZsaWVzIC0gbmFtZXMgb2YgcG9pbnQgZ3JvdXA6 DQogMi9tICAgIDIvbSAgICBDMmgNCg0KTnVtYmVyIG9mIHN5bW1ldHJ5IG9w ZXJhdGlvbnM6IDQNCk9wZXJhdGlvbjogMQ0KIDEuMCAgIDAuMCAgIDAuMCAg MC4wMDANCiAwLjAgICAxLjAgICAwLjAgIDAuMDAwDQogMC4wICAgMC4wICAg MS4wICAwLjAwMA0KDQpPcGVyYXRpb246IDINCi0xLjAgICAwLjAgICAwLjAg IDAuNTAwDQogMC4wICAtMS4wICAgMC4wICAwLjAwMA0KIDAuMCAgIDAuMCAg IDEuMCAgMC41MDANCg0KT3BlcmF0aW9uOiAzDQotMS4wICAgMC4wICAgMC4w ICAwLjAwMA0KIDAuMCAgLTEuMCAgIDAuMCAgMC4wMDANCiAwLjAgICAwLjAg IC0xLjAgIDAuMDAwDQoNCk9wZXJhdGlvbjogNA0KIDEuMCAgIDAuMCAgIDAu MCAgMC41MDANCiAwLjAgICAxLjAgICAwLjAgIDAuMDAwDQogMC4wICAgMC4w ICAtMS4wICAwLjUwMA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KPT09PT0gTnVt YmVyIG9mIHBvc3NpYmxlIHNoaWZ0IHZlY3RvcnM6IDggPT09PT0NCj09PT09 IExpc3Qgb2Ygc2hpZnQgdmVjdG9yczoNCiAwLjAwMDAgICAwLjAwMDAgICAw LjAwMDANCiAwLjAwMDAgICAwLjAwMDAgICAwLjUwMDANCiAwLjAwMDAgICAw LjUwMDAgICAwLjAwMDANCiAwLjAwMDAgICAwLjUwMDAgICAwLjUwMDANCiAw LjUwMDAgICAwLjAwMDAgICAwLjAwMDANCiAwLjUwMDAgICAwLjAwMDAgICAw LjUwMDANCiAwLjUwMDAgICAwLjUwMDAgICAwLjAwMDANCiAwLjUwMDAgICAw LjUwMDAgICAwLjUwMDANCg0KTGlzdCBvZiBzaGlmdGVkIGNlbGxzOg0KDQpD ZWxsICMxIA0KICBTaGlmdCB2ZWN0b3I6ICAwLjAwMDAgICAwLjAwMDAgICAw LjUwMDANCiAgTm9uZXF1aXZhbGVudCBhdG9tcyA6DQoNCiAwLjU5NzU5MDAw ICAgMC44MTU5OTAwMCAgMC4zNDQyMDAwMA0KIEV1DQogMC45MDI0MTAwMCAg IDAuMTg0MDEwMDAgIDAuODQ0MjAwMDANCiBFdQ0KIDAuNDAyNDEwMDAgICAw LjE4NDAxMDAwICAwLjY1NTgwMDAwDQogRXUNCiAwLjA5NzU5MDAwICAgMC44 MTU5OTAwMCAgMC4xNTU4MDAwMA0KIEV1DQoNCkNlbGwgIzIgDQogIFNoaWZ0 IHZlY3RvcjogIDAuMDAwMCAgIDAuNTAwMCAgIDAuMDAwMA0KICBOb25lcXVp dmFsZW50IGF0b21zIDoNCg0KIDAuNTk3NTkwMDAgICAwLjMxNTk5MDAwICAw Ljg0NDIwMDAwDQogRXUNCiAwLjkwMjQxMDAwICAgMC42ODQwMTAwMCAgMC4z NDQyMDAwMA0KIEV1DQogMC40MDI0MTAwMCAgIDAuNjg0MDEwMDAgIDAuMTU1 ODAwMDANCiBFdQ0KIDAuMDk3NTkwMDAgICAwLjMxNTk5MDAwICAwLjY1NTgw MDAwDQogRXUNCg0KQ2VsbCAjMyANCiAgU2hpZnQgdmVjdG9yOiAgMC4wMDAw ICAgMC41MDAwICAgMC41MDAwDQogIE5vbmVxdWl2YWxlbnQgYXRvbXMgOg0K DQogMC41OTc1OTAwMCAgIDAuMzE1OTkwMDAgIDAuMzQ0MjAwMDANCiBFdQ0K IDAuOTAyNDEwMDAgICAwLjY4NDAxMDAwICAwLjg0NDIwMDAwDQogRXUNCiAw LjQwMjQxMDAwICAgMC42ODQwMTAwMCAgMC42NTU4MDAwMA0KIEV1DQogMC4w OTc1OTAwMCAgIDAuMzE1OTkwMDAgIDAuMTU1ODAwMDANCiBFdQ0KDQpDZWxs ICM0IA0KICBTaGlmdCB2ZWN0b3I6ICAwLjUwMDAgICAwLjAwMDAgICAwLjAw MDANCiAgTm9uZXF1aXZhbGVudCBhdG9tcyA6DQoNCiAwLjA5NzU5MDAwICAg MC44MTU5OTAwMCAgMC44NDQyMDAwMA0KIEV1DQogMC40MDI0MTAwMCAgIDAu MTg0MDEwMDAgIDAuMzQ0MjAwMDANCiBFdQ0KIDAuOTAyNDEwMDAgICAwLjE4 NDAxMDAwICAwLjE1NTgwMDAwDQogRXUNCiAwLjU5NzU5MDAwICAgMC44MTU5 OTAwMCAgMC42NTU4MDAwMA0KIEV1DQoNCkNlbGwgIzUgDQogIFNoaWZ0IHZl Y3RvcjogIDAuNTAwMCAgIDAuMDAwMCAgIDAuNTAwMA0KICBOb25lcXVpdmFs ZW50IGF0b21zIDoNCg0KIDAuMDk3NTkwMDAgICAwLjgxNTk5MDAwICAwLjM0 NDIwMDAwDQogRXUNCiAwLjQwMjQxMDAwICAgMC4xODQwMTAwMCAgMC44NDQy MDAwMA0KIEV1DQogMC45MDI0MTAwMCAgIDAuMTg0MDEwMDAgIDAuNjU1ODAw MDANCiBFdQ0KIDAuNTk3NTkwMDAgICAwLjgxNTk5MDAwICAwLjE1NTgwMDAw DQogRXUNCg0KQ2VsbCAjNiANCiAgU2hpZnQgdmVjdG9yOiAgMC41MDAwICAg MC41MDAwICAgMC4wMDAwDQogIE5vbmVxdWl2YWxlbnQgYXRvbXMgOg0KDQog MC4wOTc1OTAwMCAgIDAuMzE1OTkwMDAgIDAuODQ0MjAwMDANCiBFdQ0KIDAu NDAyNDEwMDAgICAwLjY4NDAxMDAwICAwLjM0NDIwMDAwDQogRXUNCiAwLjkw MjQxMDAwICAgMC42ODQwMTAwMCAgMC4xNTU4MDAwMA0KIEV1DQogMC41OTc1 OTAwMCAgIDAuMzE1OTkwMDAgIDAuNjU1ODAwMDANCiBFdQ0KDQpDZWxsICM3 IA0KICBTaGlmdCB2ZWN0b3I6ICAwLjUwMDAgICAwLjUwMDAgICAwLjUwMDAN CiAgTm9uZXF1aXZhbGVudCBhdG9tcyA6DQoNCiAwLjA5NzU5MDAwICAgMC4z MTU5OTAwMCAgMC4zNDQyMDAwMA0KIEV1DQogMC40MDI0MTAwMCAgIDAuNjg0 MDEwMDAgIDAuODQ0MjAwMDANCiBFdQ0KIDAuOTAyNDEwMDAgICAwLjY4NDAx MDAwICAwLjY1NTgwMDAwDQogRXUNCiAwLjU5NzU5MDAwICAgMC4zMTU5OTAw MCAgMC4xNTU4MDAwMA0KIEV1DQo= - ---307652566-650165112-1031268624=:6826-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 11:08:03 +0200 (CEST) From: Georg Madsen Subject: Re: [WIEN]: monoclinic cell ==== Georg Madsen submitted the following contribution: ==== > I have no problem with the renaming of the axes since the angle is > consistent, but should I now switch my atomic coordinates or is it reading > them properly? I am attaching my .struct file and the .outputsgroup file > in case my explanation is not clear. If you use the new axes you should also use new coordinates. I guess your case.struct_sgroup should have the correct new structure. Georg ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 06 Sep 2002 12:43:59 +0200 From: Enrique Lomba Subject: [WIEN]: Single atom calculations ==== Enrique Lomba submitted the following contribution: ==== Dear Wien users, could someone give me some advice on how to calculate single atom energies to get a proper cohesive energy calculation ? I read in the manual that one should use a sufficiently large fcc cell (how large is sufficiently large ?? one must use trial and error ? and another question ? does one have to keep the same RMT and no. of k-points than in the calculation for the solid whose cohesive energy one wants to determine ? One would then have a relatively large number of local orbitals in the base .... any help will be appreciated, thanks in advance ! Enrique - -- - -------------------------------------------------------------- Enrique Lomba Instituto de Quimica Fisica Rocasolano, CSIC C/ Serrano 119, 28006 Madrid, Spain FAX no. 34-915642431 Phone no. 34-915619407 (ext 1301) e-mail : E.Lomba@iqfr.csic.es www : http://www.fluid.iqfr.csic.es/enrique.html ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 06:07:45 -0700 (PDT) From: yanming Ma Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== yanming Ma submitted the following contribution: ==== - --0-1660464621-1031317665=:80998 Content-Type: text/plain; charset=us-ascii Dear Saeid and Jeff, Thanks very much for your excellent explainations for the LM combination. Best wishes Yanming Ma Saeid Jalali wrote:==== "Saeid Jalali" submitted the following contribution: ==== > On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote: > > >I am using the AIM program in WIEN2k. When I calculated the critical > > points for some materials. The AIM runs without >stopping. I know the > > discontinuities appear at the sphere boundary. According to the User > > guides of wien2k, I have gotten >the as little "core-leakage" as > > possible from LSTART. But I don't know how to increase properly the > > default LM-list to >LM=8 or 10 without causing other problems. > > > To make LM=8 one needs to change LM combinations in case.in2 file as > > follows: > > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 > > 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 > > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8 > > This is not necessarily true. You need to look at the symmetry of > the atom (in the .outputs file) and pick the correct LM list from > the WIEN2k usersguide (Section 7.4 on lapw2). Yes, certainly the LM list depends on the point group of the atom, which is considered by the symmetry program to generate a right LM list for each inequivalent atom. Thus, it is easier to use the generated list in the in2 file, and just follow the logic of the list to add more combinations to the list(s) instead of using those complicated tables. Two above listed LM's are just an example to show how one would follow the logic, and I would here to thank you for your on time alert. Indeed, lower symmetry corresponds to longer list. This means that lower symmetry corresponds to higher splitting. This says that lower symmetry corresponds to more irreducible representations, which are absolutely depending on the symmetry. For example in the worst case with no any symmetries one easily sees that for L=6 there are exactly 49 LM pairs: To show this I am willing to sum the (2L+1) from L=0 to L=6: (0+1)+(2*1+1)+(2*2+1)+(2*3+1)+(2*4+1)+(2*5+1)+(2*6+1)=1+3+5+7+9+11+13=49. >I am not sure if one should also count the combination with negative M or not I have checked it out generating many case.in2 files form various case.struct with different ISPLITs, and found that negative M's are also considered by the program if they are needed. It is worth to mention that since the number of LM lists are equal to the number of inequivalent atoms, one considers the lowest symmetry or longest LM list to count the LM combination to check the condition on NCOM: I had done it for the above two LM lists as an example in my last email. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes - --0-1660464621-1031317665=:80998 Content-Type: text/html; charset=us-ascii

Dear Saeid and Jeff,

Thanks very much for your excellent explainations for the LM combination.

Best wishes

Yanming Ma

 Saeid Jalali wrote:

====
"Saeid Jalali"
submitted the following contribution:
====


> On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote:
> > >I am using the AIM program in WIEN2k. When I calculated the
critical
> > points for some materials. The AIM runs without >stopping. I know
the
> > discontinuities appear at the sphere boundary. According to the
User
> > guides of wien2k, I have gotten >the as little "core-leakage"
as
> > possible from LSTART. But I don't know how to increase properly
the
> > default LM-list to >LM=8 or 10 without causing other problems.
>
> > To make LM=8 one needs to change LM combinations in case.in2 file
as
> > follows:
> > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8
> > 0 0 1 0 2 0 2 2 3! 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0
7
> > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8
>
> This is not necessarily true. You need to look at the symmetry of
> the atom (in the .outputs file) and pick the correct LM list from
> the WIEN2k usersguide (Section 7.4 on lapw2).

Yes, certainly the LM list depends on the point group of the atom, which is
considered by the symmetry program to generate a right LM list for each
inequivalent atom. Thus, it is easier to use the generated list in the in2
file, and just follow the logic of the list to add more combinations to the
list(s) instead of using those complicated tables. Two above listed LM's are
just an example to show how one would follow the logic, and I would here to
thank you for your on time alert. Indeed, lower symmetry corresponds to
longer list. This means that lower symmetry corresponds to higher splitting.
This says that lower symmetry corresponds to mor! e irreducible
representations, which are absolutely depending on the symmetry. For example
in the worst case with no any symmetries one easily sees that for L=6 there
are exactly 49 LM pairs: To show this I am willing to sum the (2L+1) from
L=0 to L=6:

(0+1)+(2*1+1)+(2*2+1)+(2*3+1)+(2*4+1)+(2*5+1)+(2*6+1)=1+3+5+7+9+11+13=49.



>I am not sure if one should also count the combination with negative M or
not



I have checked it out generating many case.in2 files form various
case.struct with different ISPLITs, and found that negative M's are also
considered by the program if they are needed. It is worth to mention that
since the number of LM lists are equal to the number of inequivalent atoms,
one considers the lowest symmetry or longest LM list to count the LM
combination to check the condition on NCOM: I had done it for the above two
LM lists as an example in my last email.

Your,

S. Jalali.

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes - --0-1660464621-1031317665=:80998-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 06:07:59 -0700 (PDT) From: yanming Ma Subject: Re: [WIEN]: How to increase the default LM-list to LM =8 or 10 ==== yanming Ma submitted the following contribution: ==== - --0-715084127-1031317679=:92535 Content-Type: text/plain; charset=us-ascii Dear Saeid and Jeff, Thanks very much for your excellent explainations for the LM combination. Best wishes Yanming Ma Saeid Jalali wrote: ==== "Saeid Jalali" submitted the following contribution: ==== > On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote: > > >I am using the AIM program in WIEN2k. When I calculated the critical > > points for some materials. The AIM runs without >stopping. I know the > > discontinuities appear at the sphere boundary. According to the User > > guides of wien2k, I have gotten >the as little "core-leakage" as > > possible from LSTART. But I don't know how to increase properly the > > default LM-list to >LM=8 or 10 without causing other problems. > > > To make LM=8 one needs to change LM combinations in case.in2 file as > > follows: > > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8 > > 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0 7 > > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8 > > This is not necessarily true. You need to look at the symmetry of > the atom (in the .outputs file) and pick the correct LM list from > the WIEN2k usersguide (Section 7.4 on lapw2). Yes, certainly the LM list depends on the point group of the atom, which is considered by the symmetry program to generate a right LM list for each inequivalent atom. Thus, it is easier to use the generated list in the in2 file, and just follow the logic of the list to add more combinations to the list(s) instead of using those complicated tables. Two above listed LM's are just an example to show how one would follow the logic, and I would here to thank you for your on time alert. Indeed, lower symmetry corresponds to longer list. This means that lower symmetry corresponds to higher splitting. This says that lower symmetry corresponds to more irreducible representations, which are absolutely depending on the symmetry. For example in the worst case with no any symmetries one easily sees that for L=6 there are exactly 49 LM pairs: To show this I am willing to sum the (2L+1) from L=0 to L=6: (0+1)+(2*1+1)+(2*2+1)+(2*3+1)+(2*4+1)+(2*5+1)+(2*6+1)=1+3+5+7+9+11+13=49. >I am not sure if one should also count the combination with negative M or not I have checked it out generating many case.in2 files form various case.struct with different ISPLITs, and found that negative M's are also considered by the program if they are needed. It is worth to mention that since the number of LM lists are equal to the number of inequivalent atoms, one considers the lowest symmetry or longest LM list to count the LM combination to check the condition on NCOM: I had done it for the above two LM lists as an example in my last email. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes - --0-715084127-1031317679=:92535 Content-Type: text/html; charset=us-ascii

Dear Saeid and Jeff,

Thanks very much for your excellent explainations for the LM combination.

Best wishes

Yanming Ma

 Saeid Jalali wrote:

====
"Saeid Jalali"
submitted the following contribution:
====


> On Thu, Sep 05, 2002 at 10:26:28AM +0430, Saeid Jalali wrote:
> > >I am using the AIM program in WIEN2k. When I calculated the
critical
> > points for some materials. The AIM runs without >stopping. I know
the
> > discontinuities appear at the sphere boundary. According to the
User
> > guides of wien2k, I have gotten >the as little "core-leakage"
as
> > possible from LSTART. But I don't know how to increase properly
the
> > default LM-list to >LM=8 or 10 without causing other problems.
>
> > To make LM=8 one needs to change LM combinations in case.in2 file
as
> > follows:
> > 0 0 2 0 2 2 4 0 4 2 4 4 6 0 6 2 6 4 6 6 8 0 8 2 8 4 8 6 8 8
> > 0 0 1 0 2 0 2 2 3! 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 7 0
7
> > 2 7 4 7 6 8 0 8 2 8 4 8 6 8 8
>
> This is not necessarily true. You need to look at the symmetry of
> the atom (in the .outputs file) and pick the correct LM list from
> the WIEN2k usersguide (Section 7.4 on lapw2).

Yes, certainly the LM list depends on the point group of the atom, which is
considered by the symmetry program to generate a right LM list for each
inequivalent atom. Thus, it is easier to use the generated list in the in2
file, and just follow the logic of the list to add more combinations to the
list(s) instead of using those complicated tables. Two above listed LM's are
just an example to show how one would follow the logic, and I would here to
thank you for your on time alert. Indeed, lower symmetry corresponds to
longer list. This means that lower symmetry corresponds to higher splitting.
This says that lower symmetry corresponds to mor! e irreducible
representations, which are absolutely depending on the symmetry. For example
in the worst case with no any symmetries one easily sees that for L=6 there
are exactly 49 LM pairs: To show this I am willing to sum the (2L+1) from
L=0 to L=6:

(0+1)+(2*1+1)+(2*2+1)+(2*3+1)+(2*4+1)+(2*5+1)+(2*6+1)=1+3+5+7+9+11+13=49.



>I am not sure if one should also count the combination with negative M or
not



I have checked it out generating many case.in2 files form various
case.struct with different ISPLITs, and found that negative M's are also
considered by the program if they are needed. It is worth to mention that
since the number of LM lists are equal to the number of inequivalent atoms,
one considers the lowest symmetry or longest LM list to count the LM
combination to check the condition on NCOM: I had done it for the above two
LM lists as an example in my last email.

Your,

S. Jalali.

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes - --0-715084127-1031317679=:92535-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 21:22:55 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Single atom calculations ==== "Saeid Jalali" submitted the following contribution: ==== > could someone give me some advice on how to calculate single atom > energies to get a proper cohesive energy calculation ? I read in the > manual that one should use a sufficiently large fcc cell (how large is > sufficiently large ?? one must use trial and error ? For a quick guess about cohesive energy one can look at the output file of the atomic lstart program to find atomic energies. But it is not an accurate way as it is suffering with two different methods of energy calculation: fully relativistic Dirack-Fock method for calculating atomic energies and Scalar relativistic FP-LAPW method for calculating total bulk energy. It is not expected from two individual approaches to obtain an energy, thus it is suggested by the author to calculate also atomic energies within FP-LAPW to use cancellation error. Calculating atomic energy within bulk total energy calculation needs to make a supercell to avoid interacting each atom with its nearest neighbors to mimic an free atom. In general, one would check the convergence of the calculated total atomic energy through various lattice parameters of the supercell to make sure that there is not any interaction between the atom with the others. You would use F, B, P, or any other space groups to make supercell for such a simple calculation, but I also have found F more suitable. Basically, to obtain an accurate atomic energy using a vary large lattice parameter helps, but starting from a doubled lattice parameter looks good. > and another > question ? does one have to keep the same RMT and no. of k-points than > in the calculation for the solid whose cohesive energy one wants to > determine ? The point is to use cancellation error as much as possible. For bulk calculation one first finds suitable no. of k-points. This can be the case also for atomic calculation. About the RMT I think it looks more reasonable to keep the V_RMT/V_cell: V is Volume. However, according to my experience using the same RMT's is not bad. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 21:27:54 +0200 (MEST) From: Pio =?ISO-8859-1?Q?B=E4ttig?= Subject: [WIEN]: Bandstructure plotting ==== Pio =?ISO-8859-1?Q?B=E4ttig?= submitted the following contribution: ==== Dear Wien users I encounter a small problem when trying to plot bands with characters (using Wien2k_02_130802), I can't manage to get wider lines, they stay at standard thickness. My case.insp file looks as follows: - ------- ### Figure configuration 5.0 3.0 # paper offset of plot 10.0 15.0 # xsize,ysize of plot [cm] 1.0 4 # major ticks, minor ticks 1.0 1 # character height, font switch 1.1 1 0 # line width, line switch, color switch ### Data configuration 0.0 1.6 1 # energy range, energy switch (1:Ry, 2:eV) 1 0.70914 # Fermi switch, Fermi-level (in Ry units) 1 999 # number of bands for heavier plotting 1,1 2 4 0.2 # jatom, jtype, size of heavier plotting - ------- In the last line (size of heavier plotting), I tried 0.2, 0.4, 3, without effect. The relevant 4 lines from case.qtlup are the following: - ------- JATOM= 1 MULT= 2 ISPLIT= 2 tot,0,1,2,D-eg,D-t2g,3 JATOM= 2 MULT= 1 ISPLIT= 2 tot,0,1,2,D-eg,D-t2g,3 JATOM= 3 MULT= 1 ISPLIT= 2 tot,0,1,2,D-eg,D-t2g,3 JATOM= 4 MULT= 6 ISPLIT=-2 tot,0,1,PZ,PX+PY,2,DZ2,DXY,DX2Y2,DXZ+DYZ,3 - ------- I think I might be forgetting something small, but can't figure out what. Thank you very much for any hint. Pio Baettig - -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Sep 2002 19:52:19 -0400 From: Fred Nastos Subject: Re: [WIEN]: Bandstructure plotting ==== Fred Nastos submitted the following contribution: ==== > I can't manage to get wider lines, they stay at standard thickness. My > case.insp file looks as follows: > > > > 1.1 1 0 # line width, line switch, color switch Instead, try: 1.1 2 0 # line width, line switch, color switch Choice 1 for the line switch denotes just lines. The character plotting uses circles, given by switch 2, to denote the character. > 2 4 0.2 # jatom, jtype, size of heavier > plotting ------- > In the last line (size of heavier plotting), I tried 0.2, 0.4, 3, without > effect. A size of 0.2 should be enough. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Sep 2002 00:14:48 +0500 From: "Rashid Ahmed" Subject: [none] ==== "Rashid Ahmed" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0005_01C25928.3D609960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable end - ------=_NextPart_000_0005_01C25928.3D609960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<lasts>
end
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
- ------=_NextPart_000_0005_01C25928.3D609960-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #34 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #35 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Wednesday, September 18 2002 Volume 2002 : Number 035 ---------------------------------------------------------------------- Date: Wed, 11 Sep 2002 07:40:42 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k users: In the latest version of wien2k,how to calculate the DOS? According to Peter,there have changed in wien2k like this: "The total spin-up / dn DOS could not be calculated in a spinpolarized spin-orbit calculation (since each qtlup/dn file contains all eigenvalues. We write now into case.qtlup/dn the up and dn-spin "norm" of each eigenvalue into case.qtlup (at the position of "q-interstital", which was not correct anyway in SO calculations). TETRA reads now in spinpol. SO cases (only then) for the "total DOS" these norms and produces a spin-up or dn total DOS." but this donn't point out how to get DOS in this wien2k, can somebody eles give me some help? when I run : x lapw2 -c -up -qtl, there is always error message. _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Sep 2002 01:37:20 -0700 (PDT) From: romdhani hedi Subject: [WIEN]: ROTDEF ERROR ==== romdhani hedi submitted the following contribution: ==== - --0-1229455378-1031733440=:6288 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear wien users, I am interested of optical properties of In2S3 compound using the WIEN97 code. When I execute the program joint errors appear. In order to clarify the problem I send the In2S3.struct file. Best Regards. __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute - --0-1229455378-1031733440=:6288 Content-Type: application/x-unknown; name="In2S3.struct" Content-Transfer-Encoding: base64 Content-Description: In2S3.struct Content-Disposition: attachment; filename="In2S3.struct" SW4yUzMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApCICAgTEFUVElD RSxOT05FUVVJVi4gQVRPTVM6MTEgICAgICAgICAgICAgICAgICAgMTQxIEk0 MS9hbWQKTU9ERSBPRiBDQUxDPVJFTEEKIDE0LjQwNTQwMCAxNC40MDU0MDAg NjEuMTUxNjAwIDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwCkF0b209 IC0xOiBYPTAuMDAwMDAwMDAgWT0wLjQ5OTcwMDAwIFo9MC4wMDAwMDAwMAog ICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTE6 IFg9MC43NTAzMDAwMCBZPTAuNzUwMDAwMDAgWj0wLjI1MDAwMDAwCkF0b209 IC0xOiBYPTAuMDAwMDAwMDAgWT0wLjAwMDMwMDAwIFo9MC4wMDAwMDAwMApB dG9tPSAtMTogWD0wLjc0OTcwMDAwIFk9MC4yNTAwMDAwMCBaPTAuNzUwMDAw MDAKSW4xICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDEwMDAgUk1UPSAg ICAyLjMwMDAgICBaOiA0OS4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAg IDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC0y OiBYPTAuMDAwMDAwMDAgWT0wLjk4MTkwMDAwIFo9MC4zMzI0MDAwMAogICAg ICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTI6IFg9 MC4yNjgxMDAwMCBZPTAuNzUwMDAwMDAgWj0wLjU4MjQwMDAwCkF0b209IC0y OiBYPTAuMDAwMDAwMDAgWT0wLjUxODEwMDAwIFo9MC4zMzI0MDAwMApBdG9t PSAtMjogWD0wLjIzMTkwMDAwIFk9MC4yNTAwMDAwMCBaPTAuMDgyNDAwMDAK SW4yICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDEwMDAgUk1UPSAgICAy LjUwMDAgICBaOiA0OS4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAwLjAwMDAwMDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEu MDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC0zOiBY PTAuMDAwMDAwMDAgWT0wLjAxODEwMDAwIFo9MC42Njc2MDAwMAogICAgICAg ICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTM6IFg9MC4y MzE5MDAwMCBZPTAuNzUwMDAwMDAgWj0wLjkxNzYwMDAwCkF0b209IC0zOiBY PTAuMDAwMDAwMDAgWT0wLjQ4MTkwMDAwIFo9MC42Njc2MDAwMApBdG9tPSAt MzogWD0wLjI2ODEwMDAwIFk9MC4yNTAwMDAwMCBaPTAuNDE3NjAwMDAKSW4y ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDEwMDAgUk1UPSAgICAyLjUw MDAgICBaOiA0OS4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAw LjAwMDAwMDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC00OiBYPTAu MDAwMDAwMDAgWT0wLjkwMDAwMDAwIFo9MC4yNTAwMDAwMAogICAgICAgICAg TVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTQ6IFg9MC4zNTAw MDAwMCBZPTAuNzUwMDAwMDAgWj0wLjUwMDAwMDAwCkF0b209IC00OiBYPTAu MDAwMDAwMDAgWT0wLjYwMDAwMDAwIFo9MC4yNTAwMDAwMApBdG9tPSAtNDog WD0wLjE1MDAwMDAwIFk9MC4yNTAwMDAwMCBaPTAuMDAwMDAwMDAKUyAxICAg ICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjgwMDAg ICBaOiAxNi4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAw MCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC01OiBYPTAuMDAw MDAwMDAgWT0wLjEwMDAwMDAwIFo9MC43NTAwMDAwMAogICAgICAgICAgTVVM VD0gNCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTU6IFg9MC4xNTAwMDAw MCBZPTAuNzUwMDAwMDAgWj0wLjAwMDAwMDAwCkF0b209IC01OiBYPTAuMDAw MDAwMDAgWT0wLjQwMDAwMDAwIFo9MC43NTAwMDAwMApBdG9tPSAtNTogWD0w LjM1MDAwMDAwIFk9MC4yNTAwMDAwMCBaPTAuNTAwMDAwMDAKUyAxICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjgwMDAgICBa OiAxNi4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC02OiBYPTAuMDAwMDAw MDAgWT0wLjAwODYwMDAwIFo9MC4wNzg1MDAwMAogICAgICAgICAgTVVMVD0g NCAgICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTY6IFg9MC4yNDE0MDAwMCBZ PTAuNzUwMDAwMDAgWj0wLjMyODUwMDAwCkF0b209IC02OiBYPTAuMDAwMDAw MDAgWT0wLjQ5MTQwMDAwIFo9MC4wNzg1MDAwMApBdG9tPSAtNjogWD0wLjI1 ODYwMDAwIFk9MC4yNTAwMDAwMCBaPTAuODI4NTAwMDAKUyAyICAgICAgICBO UFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAyLjMwMDAgICBaOiAx Ni4wCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAg MS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC03OiBYPTAuMDAwMDAwMDAg WT0wLjk5MTQwMDAwIFo9MC45MjE1MDAwMAogICAgICAgICAgTVVMVD0gNCAg ICAgICAgICBJU1BMSVQ9IDgKQXRvbT0gLTc6IFg9MC4yNTg2MDAwMCBZPTAu NzUwMDAwMDAgWj0wLjE3MTUwMDAwCkF0b209IC03OiBYPTAuMDAwMDAwMDAg WT0wLjUwODYwMDAwIFo9MC45MjE1MDAwMApBdG9tPSAtNzogWD0wLjI0MTQw MDAwIFk9MC4yNTAwMDAwMCBaPTAuNjcxNTAwMDAKUyAyICAgICAgICBOUFQ9 ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAyLjMwMDAgICBaOiAxNi4w CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAw MDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAx LjAwMDAwMDAgMC4wMDAwMDAwCkF0b209IC04OiBYPTAuMDAwMDAwMDAgWT0w LjAyMzcwMDAwIFo9MC40MTMxMDAwMAogICAgICAgICAgTVVMVD0gNCAgICAg ICAgICBJU1BMSVQ9IDgKQXRvbT0gLTg6IFg9MC4yMjYzMDAwMCBZPTAuNzUw MDAwMDAgWj0wLjY2MzEwMDAwCkF0b209IC04OiBYPTAuMDAwMDAwMDAgWT0w LjQ3NjMwMDAwIFo9MC40MTMxMDAwMApBdG9tPSAtODogWD0wLjI3MzcwMDAw IFk9MC4yNTAwMDAwMCBaPTAuMTYzMTAwMDAKUyAzICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAyLjIwMDAgICBaOiAxNi4wCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAw MDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwCkF0b209IC05OiBYPTAuMDAwMDAwMDAgWT0wLjk3 MDAwMDAwIFo9MC41ODY5MDAwMAogICAgICAgICAgTVVMVD0gNCAgICAgICAg ICBJU1BMSVQ9IDgKQXRvbT0gLTk6IFg9MC4yNzM3MDAwMCBZPTAuNzUwMDAw MDAgWj0wLjgzNjkwMDAwCkF0b209IC05OiBYPTAuMDAwMDAwMDAgWT0wLjUy MzcwMDAwIFo9MC41ODY5MDAwMApBdG9tPSAtOTogWD0wLjIyNjMwMDAwIFk9 MC4yNTAwMDAwMCBaPTAuMzM2OTAwMDAKUyAzICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAyLjIwMDAgICBaOiAxNi4wCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAw CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwCkF0b209LTEwOiBYPTAuMDAwMDAwMDAgWT0wLjI1MDAw MDAwIFo9MC4yMDQ2MDAwMAogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJ U1BMSVQ9IDgKQXRvbT0tMTA6IFg9MC4wMDAwMDAwMCBZPTAuNzUwMDAwMDAg Wj0wLjQ1NDYwMDAwCkluMyAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDAx MDAwIFJNVD0gICAgMi40MDAwICAgWjogNDkuMAogICAgICAgICAgICAgICAg ICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAg ICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAw MApBdG9tPS0xMTogWD0wLjAwMDAwMDAwIFk9MC43NTAwMDAwMCBaPTAuNzk1 NDAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CkF0 b209LTExOiBYPTAuNTAwMDAwMDAgWT0wLjc1MDAwMDAwIFo9MC4wNDU0MDAw MApJbjMgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwMTAwMCBSTVQ9ICAg IDIuNDAwMCAgIFo6IDQ5LjAKICAgICAgICAgICAgICAgICAgICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAK - --0-1229455378-1031733440=:6288-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Sep 2002 13:16:18 +0200 From: Claudia Ambrosch-Draxl Subject: Re: [WIEN]: ROTDEF ERROR ==== Claudia Ambrosch-Draxl submitted the following contribution: ==== romdhani hedi wrote: > > Dear wien users, > I am interested of optical properties of In2S3 > compound using the WIEN97 code. When I execute the > program joint errors appear. In order to clarify the > problem I send the In2S3.struct file. > Best Regards. > This error usually appeared in the old version when the NMAT parameter was set too small. Regards, Claudia Ambrosch-Draxl Institut f. Theoretische Physik, University Graz Universitaetsplatz 5, A-8010 Graz Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 http://physik.uni-graz.at/~cad ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Sep 2002 05:25:22 -0700 (PDT) From: morteza jamal Subject: [WIEN]: P1/2 calculations ==== morteza jamal submitted the following contribution: ==== Dear Wien2k users. We know that using P1/2 orbitals is not true for calculating EFG. Is there any other parameters that can not be calculated using P1/2 orbitals? Specially i want to know that in HFF(Hyperfine) calculations P1/2 orbitals can be used or not. Best wishes. Morteza Jamal. __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Sep 2002 08:16:05 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: runsp -so -orb ==== Igor Mazin submitted the following contribution: ==== In fact, a switch to run lapwdm even without -orb would be useful. It takes no time and helps monitor convergence of the orbital moment. Igor - --- Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > Why is only "lapwdm -c -up -so" called during > "runsp_c_lapw -so -orb" and > > not "lapwdm -c -dn -so" looking at :log? > > lapwdm calculates the density matrices inside > spheres. This is needed ONLY > for the orbital potentials, not for a standard > LDA(GGA) calculation, even > when spin-orbit is included. > > After runsp -so has finished, one can use lapwdm to > calculate an orbital > moment, but there is no need to do this during scf. > > Regards > > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 10:55:59 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question about SCF convergence ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I would like to consult about SCF convergence. How do I know whether SCF calculation converge or diverge? What is the default criteria of SCF calculation? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 11:30:06 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: [WIEN] ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I have some question about running scf calculation. While I am running the SCF calculation, WIEN97 generates a file with extension ".vec" in step LAPW1. However, this file is empty but the SCF calculation still continues. Is it neccessary to key-in some command to print the eigenvector out? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 10:28:32 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: [WIEN] ==== "Saeid Jalali" submitted the following contribution: ==== > While I am running the SCF calculation, WIEN97 generates a file with > extension ".vec" in step LAPW1. However, this file is empty but the SCF > calculation still continues. Is it neccessary to key-in some command to > print the eigenvector out? As far as I know, we in wien code don't have a file with such an extension. Instead case.vector is a necessarily generated file by lapw1 containing the eigenvalues and eigenvectors of all k-points, which is necessarily needed as an input file for lapw2. Thus, turning on a switch is not needed. In spin-polarized calculations one looks for case.vectorup and case.vectordn and not case.vector. > How do I know whether SCF >calculation converge or diverge? grepline_lapw :DIS "*.scf" 1 >What is the default criteria of SCF calculation? On :ENE it is 0.0001Ry. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 16:30:03 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: 'LOPW' ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, Can someone please tell me what the error message LOPW Plane waves exhausted for lapw1 in SCF... I have never come across it before... Thanks, Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 08:40:19 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: 'LOPW' ==== Peter Blaha submitted the following contribution: ==== > Can someone please tell me what the error message > > LOPW Plane waves exhausted > > for lapw1 in SCF... I have never come across it before... Usually, that your struct file is incorrect.(Contains the same atom twice, not proper symmetry, equivalent atoms,....) Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 08:56:39 +0200 From: Gilles Hug Subject: [WIEN]: Re: Wien2k & MacOs X ==== Gilles Hug submitted the following contribution: ==== Dear Ching-Tarng & Dieter, At 18:28 +0200 11/09/02, Liang Ching-Tarng wrote: >Dear Gilles Hug, > >we are trying to use WIEN2k-code on MacOs X (10.1) >and the Absoft80-Compiler, some recent version(beta?) or demo >to start with. > >Your suggestion in siteconfig_lapw is > ># as suggested by Gilles Hug gilles.hug@onera.fr there >macg4:FC:f95 >macg4:MPF:f95 >macg4:CC:cc >macg4:FOPT:-O1 -cons -lU77 -w -ffree -N11 -YEXT_SFX='_' -YEXT_NAMES=LCS >macg4:FPOPT: >macg4:LDFLAGS:-llapack -lf90math_altivec -lblas_altivec -lfio -lf77math -lU77 >macg4:R_LIBS: -llapack -lf90math_altivec -lblas_altivec -lfio -lf77math -lU77 >macg4:DPARALLEL: >macg4:RP_LIBS: >macg4:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ > >and the compilation is without any problems, except "optic", but >this is not important and could be fixed. The real problem is we cannot >run WIEN, lstart ends with a segmentation fault. >Did you have similar problems? Yes, Absoft said they have a bug in their compiler which should be fixed now. But I have not yet the lastest version. >Maybe it has to do with the stack size? Should one not compile >with the static-option -s? We did not understand your option -cons, Yes, I had put the following lines in my .tcshrc limit stacksize unlimited limit datasize unlimited Please try teh -s option I didn't. >macg4:FOPT:-O1 -cons -lU77 -w -ffree -N11 -YEXT_SFX='_' -YEXT_NAMES=LCS > >looking through the usergide of Absoft-f95. Ok. May not necessary. I can't find anymore what this option is for. Acrually I stop searching whan the code was running so... >Do you have any suggestions? Is it worthwile to let the G4 of 933 Mhz >do some computional work? Of course. My old G4-500MHz runs faster than the Dec-alpha (also old) as long as I don't use complex calculation. unfortunately Altivec is not used for double. This is a limitation. I'm installing Jaguar now and it seems significantly faster (the system, I guess not plain calculations). And I kind of love the new Mail with IA to clear all the Junk mail. Best, Gilles ps : I took the liberty to send also to the Wien list as it might interest someone else or someone else might have additional improvments. - -- _______________________________________________________ Gilles Hug LEM, UMR 104, ONERA-CNRS, BP72 92322 Chatillon Cedex, France tel : +33 1 46 73 45 42 fax : +33 1 46 73 41 55 mailto:Gilles.Hug@onera.fr http://www.onera.fr/lem/anachistr/index.html _______________________________________________________ Office National d'Etudes et de Recherches Aerospatiales ------- & ------ Centre National de la Recherche Scientifique _______________________________________________________ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 09:33:52 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: runsp -so -orb ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-990962995-1031816032=:2496 Content-Type: TEXT/PLAIN; charset=US-ASCII > In fact, a switch to run lapwdm even without -orb > would be useful. It takes no time and helps monitor > convergence of the orbital moment. Try the attached runsp_lapw script with runsp -so -dm If you like it, I'll copy it into the standard distribution. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-990962995-1031816032=:2496 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=runsp_lapw Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=runsp_lapw IyEvYmluL2NzaCAtZg0KaHVwDQp1bmFsaWFzIHJtDQoNCnNldCBuYW1lICA9 ICQwDQpzZXQgYmluICAgPSAkbmFtZTpoCQkjZGlyZWN0b3J5IG9mIFdJRU4t ZXhlY3V0YWJsZXMNCmlmICEoLWQgJGJpbikgc2V0IGJpbiA9IC4NCnNldCBu YW1lICA9ICRuYW1lOnQgCQkjbmFtZSBvZiB0aGlzIHNjcmlwdC1maWxlDQpz ZXQgbG9nZmlsZSA9IDpsb2cNCnNldCB0bXAgICA9ICg6JG5hbWUpCQkjdGVt cG9yYXJ5IGZpbGVzDQoNCnNldCBzY3JhdGNoID0gICAgICAgICAgICAgICAg ICAgIyBzZXQgZGlyZWN0b3J5IGZvciB2ZWN0b3JzIGFuZCBoZWxwIGZpbGVz DQppZiAoJD9TQ1JBVENIKSB0aGVuICAgICAgICAgICAgICAjaWYgZW52cm9u bWVudCBTQ1JBVENIIGlzIHNldA0KIHNldCBzY3JhdGNoPWBlY2hvICRTQ1JB VENIICB8IHNlZCAtZSAncy9cLyQvLydgLyAjc2V0ICRzY3JhdGNoIHRvIHRo YXQgdmFsdWUgIA0KZW5kaWYgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQojLS0tPiBmdW5jdGlvbnMgJiBzdWJyb3V0aW5lcw0KYWxpYXMJdGVzdGlu cHV0CSdzZXQgZXJyaW49IlwhOjEiO2lmICghIC1lIFwhOjEgfHwgLXogXCE6 MSkgZ290byBcIToyJw0KYWxpYXMJdGVzdHN0YXR1cwknaWYgKCRzdGF0dXMp IGdvdG8gZXJyb3InDQphbGlhcwl0ZXN0ZXJyb3IJJ2lmICggLWUgXCE6MS5l cnJvciAmJiAhIC16IFwhOjEuZXJyb3IpIGdvdG8gZXJyb3InDQphbGlhcwl0 ZXN0c3RvcAknaWYgKFwhOjEgPT0gJHN0b3BhZnRlciApIGdvdG8gc3RvcCcN CmFsaWFzICAgY2xlYW5kYXlmaWxlICAgICdncmVwIC12ICJcWyIgJGRheWZp bGUgPi50bXA7J1wNCiAgICAgICAgICAgICAgICAgICAgICAgICdtdiAudG1w ICRkYXlmaWxlJw0KYWxpYXMJb3V0cHV0CQknc2V0IGRhdGUgPSBgZGF0ZSAr IiglVCkiYDsnXA0KCQkJJ3ByaW50ZiAiPiAgICVzXHQlcyAiICJcIToqIiAi JGRhdGUiID4+ICRkYXlmaWxlJw0KDQphbGlhcwlleGVjCQknKCRiaW4veCAg XCE6KikgPj4gJGRheWZpbGU7J1wNCgkJCSd0ZXN0c3RhdHVzJw0KDQphbGlh cwl0b3RhbF9leGVjCSdvdXRwdXQgXCE6KjsnXA0KCQkJJ2V4ZWMgXCE6Kjsn XA0KICAgICAgICAgICAgICAgICAgICAgICAgJ2NsZWFuZGF5ZmlsZTsnXA0K CQkJJ3Rlc3RlcnJvciBcIToxOydcDQoJCQkndGVzdGVycm9yIHVwXCE6MTsn XA0KCQkJJ3Rlc3RlcnJvciBkblwhOjE7J1wNCgkJCSd0ZXN0c3RvcCBcITox Jw0KYWxpYXMJVE9UdG9GT1IJJ3NlZCAicy9UT1QvRk9SLyIgXCE6MSA+ICR0 bXA7J1wNCgkJCSdtdiAkdG1wIFwhOjEnDQphbGlhcwlGT1J0b1RPVAknc2Vk ICJzL0ZPUi9UT1QvIiBcIToxID4gJHRtcDsnXA0KCQkJJ212ICR0bXAgXCE6 MScNCg0KIy0tLT4gZGVmYXVsdCBwYXJhbWV0ZXJzDQpzZXQgY2N1dAk9IDAu MDAwMCAJI3VwcGVyIGxpbWl0IGZvciBjaGFyZ2UgY29udmVyZ2VuY2UNCnNl dCBmY3V0CT0gMCAJIAkjdXBwZXIgbGltaXQgZm9yIGZvcmNlIGNvbnZlcmdl bmNlDQpzZXQgZWN1dAk9IDAuMDAwMQkjdXBwZXIgbGltaXQgZm9yIGVuZXJn eSBjb252ZXJnZW5jZQ0Kc2V0IGl0ZXIJPSAyMAkjbWF4aW11bSBudW1iZXIg b2YgaXRlcmF0aW9ucw0Kc2V0IHJpdGVyCT0gMjAJI3Jlc3RhcnQgYWZ0ZXIg JHJpdGVyIGl0ZXJhdGlvbnMNCnNldCBzdG9wYWZ0ZXIJCSNzdG9wIGFmdGVy ICRzdG9wYWZ0ZXINCnNldCBuZXh0CQkjc2V0IC0+IHN0YXJ0IGN5Y2xlIHdp dGggJG5leHQNCnNldCBxbGltaXQgPSAwLjA1ICAgICAgICNzZXQgLT4gd3Jp dGVzIEUtTCBpbiBuZXcgaW4xIHdoZW4gcWxpbWl0IGlzIGZ1bGZpbGxlZA0K c2V0IGluMW5ldyA9IDk5OQ0Kc2V0IHBhcmENCnNldCBub2hucw0Kc2V0IG5v aG5zMSA9IDANCnNldCBpdA0Kc2V0IGl0MA0Kc2V0IHNvDQpzZXQgb3JiDQp1 bnNldCBvcmJjDQp1bnNldCBkbQ0Kc2V0IGN0ZXN0PSgwIDAgMCkNCnNldCBl dGVzdD0oMCAwIDApDQoNCiMtLS0+IGRlZmF1bHQgZmxhZ3MNCnVuc2V0IHJl bm9ybQ0KdW5zZXQgaW4xb3JpZw0KdW5zZXQgZm9yY2UJCSNzZXQgLT4gZm9y Y2UtY2FsY3VsYXRpb24gYWZ0ZXIgc2VsZi1jb25zaXN0ZW5jeQ0KdW5zZXQg Zl9ub3RfY29udg0KdW5zZXQgaGVscAkJI3NldCAtPiBoZWxwIG91dHB1dA0K dW5zZXQgY29tcGxleAkJI3NldCAtPiBjb21wbGV4IGNhbGN1bGF0aW9uDQp1 bnNldCBpbml0CQkjc2V0IC0+IHN3aXRjaGVzIGluaXRpYWxseSBzZXQgdG8g dG90YWwgZW5lcmd5IGNhbGMuDQoNCiMtLS0+IGhhbmRsaW5nIG9mIGlucHV0 IG9wdGlvbnMNCmVjaG8gIj4gICAoJG5hbWUpIG9wdGlvbnM6ICRhcmd2Igk+ PiAkbG9nZmlsZQ0KYWxpYXMgc2IgJ3NoaWZ0OyBicmVha3N3JwkjZGVmaW5p dGlvbiB1c2VkIGluIHN3aXRjaA0Kd2hpbGUgKCQjYXJndikNCiAgc3dpdGNo ICgkMSkNCiAgY2FzZSAtW0h8aF06DQogICAgc2V0IGhlbHA7IHNiDQogIGNh c2UgLXNvOg0KICAgIHNldCBzbyA9IC1zbzsgc2INCiAgY2FzZSAtbm9obnM6 DQogICAgc2V0IG5vaG5zID0gLW5vaG5zOyBzaGlmdDsgc2V0IG5vaG5zMSA9 ICQxO3NiDQogIGNhc2UgLWRtOg0KICAgIHNldCBkbTsgc2INCiAgY2FzZSAt b3JiOg0KICAgIHNldCBvcmIgPSAtb3JiOyBzYg0KICBjYXNlIC1vcmJjOg0K ICAgIHNldCBvcmJjDQogICAgc2V0IG9yYiA9IC1vcmI7IHNiDQogIGNhc2Ug LWl0Og0KICAgIHNldCBpdCA9IC1pdDsgc2INCiAgY2FzZSAtaXQwOg0KICAg IHNldCBpdCA9IC1pdDsgc2V0IGl0MCA9IC1pdDsgc2INCiAgY2FzZSAtcDoN CiAgICBzZXQgcGFyYSA9IC1wOyBzYg0KICBjYXNlIC1JOg0KICAgIHNldCBp bml0OyBzYg0KICBjYXNlIC1lOiANCiAgICBzaGlmdDsgc2V0IHN0b3BhZnRl ciA9ICQxOyBzYg0KICBjYXNlIC1jYzogDQogICAgc2hpZnQ7IHNldCBjY3V0 ID0gJDE7IHNldCBmY3V0ID0gMDsgc2V0IGVjdXQ9MDsgc2INCiAgY2FzZSAt ZWM6IA0KICAgIHNoaWZ0OyBzZXQgZWN1dCA9ICQxOyBzZXQgZmN1dCA9IDA7 IHNldCBjY3V0PTA7IHNiDQogIGNhc2UgLWZjOiANCiAgICBzaGlmdDsgc2V0 IGZfbm90X2NvbnY7IHNldCBmY3V0ID0gJDE7IHNldCBlY3V0ID0gMDsgc2V0 IGNjdXQ9MDsgc2INCiAgY2FzZSAtcWw6IA0KICAgIHNoaWZ0OyBzZXQgcWxp bWl0ID0gJDE7ICBzYg0KICBjYXNlIC1pbjFuZXc6IA0KICAgIHNoaWZ0OyBz ZXQgaW4xbmV3ID0gJDE7ICBzYg0KICBjYXNlIC1pbjFvcmlnOg0KICAgIHNl dCBpbjFvcmlnOyBzYg0KICBjYXNlIC1yZW5vcm06IA0KICAgIHNldCByZW5v cm07IHNldCBuZXh0PW1peGVyOyAgc2INCiAgY2FzZSAtaToNCiAgICBzaGlm dDsgc2V0IGl0ZXIgID0gJDE7IHNiDQogIGNhc2UgLXI6DQogICAgc2hpZnQ7 IHNldCByaXRlciA9ICQxOyBzYg0KICBjYXNlIC1zOg0KICAgIHNoaWZ0OyBz ZXQgbmV4dCAgPSAkMTsgc2INCiAgZGVmYXVsdDogDQogICAgZWNobyAiRVJS T1I6IG9wdGlvbiAkMSBkb2VzIG5vdCBleGlzdFwhIjsgc2INCiAgZW5kc3cN CmVuZA0KaWYgKCQ/aGVscCkgZ290byBoZWxwDQogIA0KIy0tLT4gcGF0aC0g YW5kIGZpbGUtbmFtZXMNCnNldCBmaWxlICAgID0gYHB3ZGANCnNldCBmaWxl ICAgID0gJGZpbGU6dAkJI3RhaWwgb2YgZmlsZS1uYW1lcw0Kc2V0IGRheWZp bGUgPSAkZmlsZS5kYXlmaWxlCSNtYWluIG91dHB1dC1maWxlDQoNCiMtLS0+ IHN0YXJ0aW5nIG91dA0KaWYgKCRuZXh0ICE9ICIiKSBnb3RvIHN0YXJ0CSNz dGFydCB3aXRoIG9wdGlvbmFsIHByb2dyYW0NCnNldCBuZXh0ID0gbGFwdzAJ CSNkZWZhdWx0IHN0YXJ0IHdpdGggbHN0YXJ0DQoNCmlmICEoLWUgJGZpbGUu Y2xtc3VtKSB0aGVuDQogICBpZiAoLWUgJGZpbGUuY2xtc3VtX29sZCkgdGhl bg0KICAgIGNwICRmaWxlLmNsbXN1bV9vbGQgJGZpbGUuY2xtc3VtDQogICBl bHNlDQogICAgIGVjaG8gJ25vJyAkZmlsZScuY2xtc3VtKF9vbGQpIGZpbGUg Zm91bmQsIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgbGFwdzAgXCEnDQogICAg IGVjaG8gJ25vJyAkZmlsZScuY2xtc3VtKF9vbGQpIGZpbGUgZm91bmQsIHdo aWNoIGlzIG5lY2Vzc2FyeSBmb3IgbGFwdzAgXCEnXA0KCT4+JGRheWZpbGUN CiAgICAgZ290byBlcnJvcg0KICAgZW5kaWYNCmVuZGlmDQoNCnN0YXJ0OgkJ CQkjaW5pdGFsaXphdGlvbiBvZiBpbjItZmlsZXMNCmlmICgkP2luaXQpIHRo ZW4NCiAgZm9yZWFjaCBpICgkZmlsZS5pbjIqKQ0KICAgIHNlZCAiMXMvW0Et Wl0uLi4uL1RPVCAgLyIgJGkgPiAkdG1wDQogICAgbXYgJHRtcCAkaQ0KICBl bmQNCmVuZGlmDQoNCnNldCBpY3ljbGU9MQ0KDQpzZXQgcml0ZXJfc2F2ZT0k cml0ZXINCnByaW50ZiAiXG5cbkNhbGN1bGF0aW5nICRmaWxlIGluIGBwd2Rg XG5vbiBgaG9zdG5hbWVgIiAgPiAkZGF5ZmlsZQ0KcHJpbnRmICJcblxuICAg IHN0YXJ0IFx0KCVzKSAiICJgZGF0ZWAiCT4+ICRkYXlmaWxlDQplY2hvICAi d2l0aCAkbmV4dCAoJGl0ZXIvJHJpdGVyIHRvIGdvKSIJPj4gJGRheWZpbGUN CmdvdG8gJG5leHQNCg0KY3ljbGU6CQkJCQkjYmVnaW4gb2Ygc2MtY3ljbGUN Cm5vaHVwIGVjaG8gaW4gY3ljbGUgJGljeWNsZSAiICAgRVRFU1Q6ICRldGVz dFszXSAgIENURVNUOiAkY3Rlc3RbM10iDQpodXANCg0KbGFwdzA6DQp0ZXN0 aW5wdXQJJGZpbGUuaW4wIGVycm9yX2lucHV0DQp0b3RhbF9leGVjCWxhcHcw ICRwYXJhDQoNCmlmICgkZmN1dCA9PSAiMCIpIGdvdG8gb3JiDQoNCiMtLS0+ IHRlc3Qgb2YgZm9yY2UtY29udmVyZ2VuY2UgZm9yIGFsbCBmb3JjZXMNCmlm ICEoLWUgJGZpbGUuc2NmKSBnb3RvIG9yYg0Kc2V0IG5hdG9tID0gYGdyZXAg VU5JVENFTEwgJGZpbGUub3V0cHV0MCB8YXdrICd7cHJpbnQgJE5GfSdgDQpz ZXQgaWF0b20gPSAxDQpzZXQgZnRlc3QgPSAoMSAwKQ0Kd2hpbGUgKCRpYXRv bSA8PSAkbmF0b20pIAkJI2N5Y2xlIG92ZXIgYWxsIGF0b21zIA0KICBpZiAo JGlhdG9tIDw9IDkpIHRoZW4NCiAgICAgIHNldCB0ZXN0ID0gKGAkYmluL3Rl c3Rjb252IC1wIDpGT1IwJGlhdG9tIC1jICRmY3V0YCkJDQogIGVsc2UNCiAg ICAgIHNldCB0ZXN0ID0gKGAkYmluL3Rlc3Rjb252IC1wIDpGT1IkaWF0b20g LWMgJGZjdXRgKQkNCiAgZW5kaWYNCiAgaWYgICEoJHRlc3RbMV0pIHNldCBm dGVzdFsxXSA9IDANCiAgc2V0IGZ0ZXN0WzJdID0gJHRlc3RbMl0NCiAgc2V0 IGZ0ZXN0ICAgID0gKCRmdGVzdCAkdGVzdFszXSAkdGVzdFs0XSkNCiAgQCBp YXRvbSArKw0KZW5kDQplY2hvICI6Rk9SQ0UgY29udmVyZ2VuY2U6ICAkZnRl c3RbMS1dIgkJCT4+ICRkYXlmaWxlDQoNCmlmICgkZnRlc3RbMV0pIHRoZW4J CQkjZm9yY2UgY29udmVyZ2VuY2VkDQogIGlmICgkbm9obnMgPT0gJy1ub2hu cycpIHRoZW4JCQkjZm9yY2UgY29udmVyZ2VuY2VkDQogICAgICBzZXQgbm9o bnMgDQogICAgICBlY2hvICJOT0hOUyBkZWFjdGl2YXRlZCBieSBGT1JDRSBj b252ZXJnZW5jZSIJCT4+ICRkYXlmaWxlDQogIGVsc2UNCiAgICAgIHNldCBp dGVyID0gMQ0KICAgICAgdW5zZXQgZl9ub3RfY29udiANCiAgICAgIGZvcmVh Y2ggaSAoJGZpbGUuaW4yKikNCiAgICAgICAgVE9UdG9GT1IgJGkJCQkJI3N3 aXRjaCBGT1ItbGFiZWwNCiAgICAgIGVuZA0KICBlbmRpZg0KZW5kaWYNCg0K b3JiOg0KZm9yZWFjaCBpIChkbWF0dXAgZG1hdGRuIGRtYXR1ZCApDQogIGlm ICgtZSAkZmlsZS4kaSApIGNwICRmaWxlLiRpICRmaWxlLiRpIl9vbGQiCQkj c2F2ZSB0aGlzIGN5Y2xlIGZvciBuZXh0DQplbmQNCg0KaWYgKCAtZSAkZmls ZS5zY2ZvcmJ1cCApIHJtICRmaWxlLnNjZm9yYnVwIA0KaWYgKCAtZSAkZmls ZS5zY2ZvcmJkbiApIHJtICRmaWxlLnNjZm9yYmRuIA0KaWYgKCAtZSAkZmls ZS5zY2ZvcmJkdSApIHJtICRmaWxlLnNjZm9yYmR1IA0KaWYgKCAiJG9yYiIg IT0gIi1vcmIiICkgZ290byBsYXB3MQ0KaWYgKCAkP29yYmMgKSBnb3RvIGxh cHcxDQppZiAoISAtZSAkZmlsZS5kbWF0dXAgfHwgLXogJGZpbGUuZG1hdHVw ICkgZ290byBsYXB3MQ0KI2ZvcmVhY2ggaSAoIHZvcmJ1cCB2b3JiZG4gdm9y YmR1ICkNCiMgIGlmICgtZSAkZmlsZS4kaSApIFwNCiMgIGNwICRmaWxlLiRp ICRmaWxlLiRpIl9vbGQiCQkjc2F2ZSBsYXN0IGN5Y2xlDQojZW5kDQp0ZXN0 aW5wdXQJJGZpbGUuaW5vcmIgZXJyb3JfaW5wdXQNCnRvdGFsX2V4ZWMJb3Ji IC11cCAkcGFyYQ0KdG90YWxfZXhlYwlvcmIgLWRuICRwYXJhDQppZiAoICIk c28iID09ICItc28iICYmIC1lICRmaWxlLmRtYXR1ZCApIHRoZW4NCnRvdGFs X2V4ZWMJb3JiIC1kdSAkcGFyYQ0KZW5kaWYNCg0KbGFwdzE6DQp0ZXN0aW5w dXQJJGZpbGUuaW4xIGxhcHcxYw0KaWYgKC1lIC5mdWxsZGlhZykgdGhlbg0K ICBlY2hvICIgICAgZnVsbCBkaWFnb25hbGl6YXRpb24gZm9yY2VkIg0KICBz ZXQgaXQwDQogIHJtIC5mdWxsZGlhZw0KZW5kaWYNCiNnZW5lcmF0ZXMgaW4x LWZpbGUgZnJvbSA6RVBML0VQSCBpbiBjYXNlLnNjZjIgDQojICBpZiAoJGlj eWNsZSA9PSAkaW4xbmV3KSBybSAkZmlsZS5icm95ZDEgJGZpbGUuYnJveWQy IA0KICBpZiAoJGljeWNsZSA+PSAkaW4xbmV3ICkgdGhlbg0KICAgIGlmICgh IC1lICRmaWxlLmluMV9vcmlnICkgY3AgJGZpbGUuaW4xICRmaWxlLmluMV9v cmlnDQogICAgd3JpdGVfaW4xX2xhcHcgLXVwIC1xbCAkcWxpbWl0ID4+ICRk YXlmaWxlDQogICAgaWYoJHN0YXR1cyA9PSAwICkgY3AgJGZpbGUuaW4xbmV3 ICRmaWxlLmluMQ0KICBlbmRpZg0KaWYoJD9pbjFvcmlnKSB0aGVuDQogICAg aWYgKCAtZSAkZmlsZS5pbjFfb3JpZyApIGNwICRmaWxlLmluMV9vcmlnICRm aWxlLmluMQ0KICAgIHVuc2V0IGluMW9yaWcNCmVuZGlmDQppZiAoICIkc28i ID09ICItc28iICkgdGhlbg0KICB0b3RhbF9leGVjCWxhcHcxICRpdDAgLXVw ICRwYXJhICRub2hucw0KZWxzZQ0KICB0b3RhbF9leGVjCWxhcHcxICRpdDAg LXVwICRwYXJhICRub2hucyAkb3JiDQplbmRpZg0KICBpZiAoJGljeWNsZSA+ PSAkaW4xbmV3ICkgdGhlbg0KICAgIHdyaXRlX2luMV9sYXB3IC1kbiAtcWwg JHFsaW1pdCA+PiAkZGF5ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCApIGNw ICRmaWxlLmluMW5ldyAkZmlsZS5pbjENCiAgZW5kaWYNCmlmICggIiRzbyIg PT0gIi1zbyIgKSB0aGVuDQogIHRvdGFsX2V4ZWMJbGFwdzEgJGl0MCAtZG4g JHBhcmEgJG5vaG5zDQplbHNlDQogIHRvdGFsX2V4ZWMJbGFwdzEgJGl0MCAt ZG4gJHBhcmEgJG5vaG5zICRvcmINCmVuZGlmDQpzZXQgaXQwID0gJGl0DQoN CmxhcHdzbzoNCmlmICggLWUgJGZpbGUuc2Nmc28gKSBybSAkZmlsZS5zY2Zz byANCmlmICggIiRzbyIgPT0gIi1zbyIgKSB0aGVuDQogICB0ZXN0aW5wdXQJ JGZpbGUuaW5zbyBlcnJvcl9pbnB1dA0KICAgdG90YWxfZXhlYyBsYXB3c28g LXVwICRvcmIgJHBhcmENCiAgIGlmICggIiRwYXJhIiAhPSAiLXAiICkgdGhl bg0KICAgICBjcCAkZmlsZS5lbmVyZ3lkdW0gJGZpbGUuZW5lcmd5ZHVtdXAN CiAgICAgY3AgJGZpbGUuZW5lcmd5ZHVtICRmaWxlLmVuZXJneWR1bWRuDQog ICBlbmRpZg0KICAgZ290byBsYXB3MmMNCmVuZGlmDQoNCmxhcHcyOg0KdGVz dGlucHV0CSRmaWxlLmluMiBlcnJvcl9pbnB1dA0KdG90YWxfZXhlYwlsYXB3 MiAtdXAgJHBhcmENCnRvdGFsX2V4ZWMJbGFwdzIgLWRuICRwYXJhDQoNCmxh cHdkbToNCmlmICggLWUgJGZpbGUuc2NmZG11cCApIHJtICRmaWxlLnNjZmRt dXAgDQppZiAoIC1lICRmaWxlLnNjZmRtZG4gKSBybSAkZmlsZS5zY2ZkbWRu DQppZiAoICIkb3JiIiAhPSAiLW9yYiIgKSBnb3RvIGxhcHcxcw0KaWYgKCAk P29yYmMgKSBnb3RvIGxhcHcxcw0KdGVzdGlucHV0CSRmaWxlLmluZG0gZXJy b3JfaW5wdXQNCnRvdGFsX2V4ZWMJbGFwd2RtIC11cCAkcGFyYQ0KdG90YWxf ZXhlYwlsYXB3ZG0gLWRuICRwYXJhDQoNCmxhcHcxczoNCmlmICggJGl0ID09 ICItaXQiICkgdGhlbg0KICB0b3VjaCAke3NjcmF0Y2h9JGZpbGUudmVjdG9y Lm9sZA0KICBmb3JlYWNoIGkgKCR7c2NyYXRjaH0kZmlsZS52ZWN0b3IqLm9s ZCkNCiAgICBybSAkaQ0KICBlbmQNCiAgZm9yZWFjaCBpICggJHtzY3JhdGNo fSRmaWxlLnZlY3RvciogKQ0KICBpZiAoISAteiAkaSkgbXYgJGkgJGkub2xk DQogIGVuZA0KZW5kaWYNCnRlc3RpbnB1dAkkZmlsZS5pbjFzIGxjb3JlDQp0 b3RhbF9leGVjCWxhcHcxIC1zYyAtdXAgJHBhcmEgJG5vaG5zICRvcmINCnRv dGFsX2V4ZWMJbGFwdzEgLXNjIC1kbiAkcGFyYSAkbm9obnMgJG9yYg0KDQps YXB3MnM6DQp0ZXN0aW5wdXQJJGZpbGUuaW4ycyBlcnJvcl9pbnB1dA0KdG90 YWxfZXhlYwlsYXB3MiAtc2MgLXVwICRwYXJhDQp0b3RhbF9leGVjCWxhcHcy IC1zYyAtZG4gJHBhcmENCmdvdG8gbGNvcmUNCg0KbGFwdzFjOg0KdGVzdGlu cHV0CSRmaWxlLmluMWMgZXJyb3JfaW5wdXQNCmlmICgtZSAuZnVsbGRpYWcp IHRoZW4NCiAgZWNobyAiICAgIGZ1bGwgZGlhZ29uYWxpemF0aW9uIGZvcmNl ZCINCiAgc2V0IGl0MA0KICBybSAuZnVsbGRpYWcNCmVuZGlmDQojZ2VuZXJh dGVzIGluMS1maWxlIGZyb20gOkVQTC9FUEggaW4gY2FzZS5zY2YyIA0KIyAg aWYgKCRpY3ljbGUgPT0gJGluMW5ldykgcm0gJGZpbGUuYnJveWQxICRmaWxl LmJyb3lkMiANCiAgaWYgKCRpY3ljbGUgPj0gJGluMW5ldyApIHRoZW4NCiAg ICBpZiAoISAtZSAkZmlsZS5pbjFjX29yaWcgKSBjcCAkZmlsZS5pbjFjICRm aWxlLmluMWNfb3JpZw0KICAgIHdyaXRlX2luMV9sYXB3IC11cCAtYyAtcWwg JHFsaW1pdCA+PiAkZGF5ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCApIGNw ICRmaWxlLmluMWNuZXcgJGZpbGUuaW4xYw0KICBlbmRpZg0KaWYoJD9pbjFv cmlnKSB0aGVuDQogICAgaWYgKCAtZSAkZmlsZS5pbjFjX29yaWcgKSBjcCAk ZmlsZS5pbjFjX29yaWcgJGZpbGUuaW4xYw0KICAgIHVuc2V0IGluMW9yaWcN CmVuZGlmDQppZiAoICIkc28iID09ICItc28iICkgdGhlbg0KIHRvdGFsX2V4 ZWMJbGFwdzEgJGl0MCAtYyAtdXAgJHBhcmEgJG5vaG5zIA0KZWxzZQ0KIHRv dGFsX2V4ZWMgICAgIGxhcHcxICRpdDAgLWMgLXVwICRwYXJhICRub2hucyAk b3JiDQplbmRpZg0KICBpZiAoJGljeWNsZSA+PSAkaW4xbmV3ICkgdGhlbg0K ICAgIHdyaXRlX2luMV9sYXB3IC1kbiAtYyAtcWwgJHFsaW1pdCA+PiAkZGF5 ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCApIGNwICRmaWxlLmluMWNuZXcg JGZpbGUuaW4xYw0KICBlbmRpZg0KaWYgKCAiJHNvIiA9PSAiLXNvIiApIHRo ZW4NCiB0b3RhbF9leGVjCWxhcHcxICRpdDAgLWMgLWRuICRwYXJhICRub2hu cyANCmVsc2UNCiB0b3RhbF9leGVjICAgICBsYXB3MSAkaXQwIC1jIC1kbiAk cGFyYSAkbm9obnMgJG9yYg0KZW5kaWYNCg0Kc2V0IGl0MCA9ICRpdA0KDQps YXB3c29jOg0KaWYgKCAtZSAkZmlsZS5zY2ZzbyApIHJtICRmaWxlLnNjZnNv IA0KaWYgKCAiJHNvIiA9PSAiLXNvIiApIHRoZW4NCiAgIHRlc3RpbnB1dAkk ZmlsZS5pbnNvIGVycm9yX2lucHV0DQogICB0b3RhbF9leGVjIGxhcHdzbyAt dXAgLWMgJG9yYiAkcGFyYQ0KICAgaWYgKCAiJHBhcmEiICE9ICItcCIgKSB0 aGVuDQogICAgIGNwICRmaWxlLmVuZXJneWR1bSAkZmlsZS5lbmVyZ3lkdW11 cA0KICAgICBjcCAkZmlsZS5lbmVyZ3lkdW0gJGZpbGUuZW5lcmd5ZHVtZG4N CiAgIGVuZGlmDQplbmRpZg0KDQpsYXB3MmM6DQp0ZXN0aW5wdXQJJGZpbGUu aW4yYyBlcnJvcl9pbnB1dA0KdG90YWxfZXhlYwlsYXB3MiAtYyAtdXAgJHNv ICRwYXJhDQp0b3RhbF9leGVjCWxhcHcyIC1jIC1kbiAkc28gJHBhcmENCg0K bGFwd2RtYzoNCmlmICggLWUgJGZpbGUuc2NmZG11cCApIHJtICRmaWxlLnNj ZmRtdXAgDQppZiAoIC1lICRmaWxlLnNjZmRtZG4gKSBybSAkZmlsZS5zY2Zk bWRuDQp0ZXN0aW5wdXQJJGZpbGUuaW4yYyBlcnJvcl9pbnB1dA0KaWYgKCAh ICQ/ZG0gKSB0aGVuIA0KIGlmICggIiRvcmIiICE9ICItb3JiIiApIGdvdG8g bGFwdzFjcw0KIGlmICggJD9vcmJjICkgZ290byBsYXB3MWNzDQplbmRpZg0K dGVzdGlucHV0CSRmaWxlLmluZG1jIGVycm9yX2lucHV0DQp0b3RhbF9leGVj CWxhcHdkbSAtdXAgJHBhcmEgJHNvIC1jDQppZiAoICIkc28iICE9ICItc28i ICkgdGhlbg0KdG90YWxfZXhlYwlsYXB3ZG0gLWRuICRwYXJhIC1jDQplbmRp Zg0KDQpsYXB3MWNzOg0KaWYgKCAkaXQgPT0gIi1pdCIgKSB0aGVuDQogIHRv dWNoICR7c2NyYXRjaH0kZmlsZS52ZWN0b3Iub2xkDQogIGZvcmVhY2ggaSAo JHtzY3JhdGNofSRmaWxlLnZlY3Rvcioub2xkKQ0KICAgIHJtICRpDQogIGVu ZA0KICBmb3JlYWNoIGkgKCAke3NjcmF0Y2h9JGZpbGUudmVjdG9yKiApDQog IGlmICghIC16ICRpKSBtdiAkaSAkaS5vbGQNCiAgZW5kDQplbmRpZg0KdGVz dGlucHV0CSRmaWxlLmluMWNzIGxjb3JlDQp0b3RhbF9leGVjCWxhcHcxIC1j IC1zYyAtdXAgJHBhcmEgJG5vaG5zICRvcmINCnRvdGFsX2V4ZWMJbGFwdzEg LWMgLXNjIC1kbiAkcGFyYSAkbm9obnMgJG9yYg0KDQpsYXB3MmNzOg0KdGVz dGlucHV0CSRmaWxlLmluMmNzIGVycm9yX2lucHV0DQp0b3RhbF9leGVjCWxh cHcyIC1jIC1zYyAtdXAgJHBhcmENCnRvdGFsX2V4ZWMJbGFwdzIgLWMgLXNj IC1kbiAkcGFyYQ0KDQpsY29yZToNCnRlc3RpbnB1dAkkZmlsZS5pbmMgc2Nm DQp0b3RhbF9leGVjCWxjb3JlIC11cA0KdG90YWxfZXhlYwlsY29yZSAtZG4N Cg0Kc2NmOg0KZm9yZWFjaCBpICggMCBvcmJ1cCBvcmJkbiBvcmJkdSAxdXAg MWRuIHNvIDJ1cCAyZG4gZG11cCBkbWRuIDFzdXAgMXNkbiAyc3VwIDJzZG4g Y3VwIGNkbiApDQogIGlmICgtZSAkZmlsZS5zY2YkaSkgdGhlbg0KICAgICAg aWYgKCIkaSIgIT0gImRtZG4iIHx8ICIkc28iICE9ICItc28iKSBjYXQgJGZp bGUuc2NmJGkgID4+ICRmaWxlLnNjZg0KICBlbmRpZg0KZW5kDQpmb3JlYWNo IGkgKGNsbXN1bSBjbG11cCBjbG1kbiB2c3B1cCB2c3BkbiB2bnN1cCB2bnNk biApDQogIGlmICgtZSAkZmlsZS4kaSApIGNwICRmaWxlLiRpICRmaWxlLiRp Il9vbGQiCQkjc2F2ZSBsYXN0IGN5Y2xlDQplbmQNCg0KbWl4ZXI6DQp0ZXN0 aW5wdXQJJGZpbGUuaW5tIGVycm9yX2lucHV0DQp0b3RhbF9leGVjCW1peGVy DQpjYXQgJGZpbGUuc2NmbSA+PiAkZmlsZS5zY2YNCg0KaWYoJD9yZW5vcm0p IHRoZW4NCiAgIHVuc2V0IHJlbm9ybQ0KICAgcm0gJGZpbGUuYnJveSoNCmVu ZGlmDQoNCm1peGVyX3ZyZXNwOg0KdGVzdGlucHV0ICAgICAgICRmaWxlLmlu bV92cmVzcCBlbmVyZ3l0ZXN0DQp0b3RhbF9leGVjICAgICAgbWl4ZXJfdnJl c3ANCiN0b3RhbF9leGVjICAgICAgaW50MTYNCg0KZW5lcmd5dGVzdDoNCiMt LS0+IG91dHB1dCBlbmVyZ2llcw0KI3NldCBFRiA9IGBncmVwICdGIEUgUicg JGZpbGUuc2NmMiAgICB8YXdrICd7cHJpbnRmKCIlLjVmIiwgJE5GKX0nYA0K I3NldCBFVCA9IGBncmVwICdBTCBFTicgJGZpbGUub3V0cHV0bSB8YXdrICd7 cHJpbnRmKCIlLjVmIiwgJE5GKX0nYA0KI2NhdCA8PCB0aGVlbmQJCQkJPj4g JGRheWZpbGUNCiNFRiAgJEVGDQojRVQgICRFVA0KI3RoZWVuZA0KI2VjaG8g JEVUIAkJCQk+ICRmaWxlLmZpbk0NCg0KIy0tLT4gdGVzdCBvZiBlbmVyZ3kg Y29udmVyZ2VuY2UNCiNpZiAoJGVjdXQgPT0gIjAiKSBnb3RvIGNoYXJnZXRl c3QNCnNldCBldGVzdCA9IChgJGJpbi90ZXN0Y29udiAtcCA6RU5FIC1jICRl Y3V0YCkJDQp0ZXN0c3RhdHVzDQplY2hvICI6RU5FUkdZIGNvbnZlcmdlbmNl OiAgJGV0ZXN0WzEtM10iCQk+PiAkZGF5ZmlsZQ0KaWYgKCRldGVzdFsxXSkg dGhlbg0KICBpZiAoJG5vaG5zID09ICctbm9obnMnKSB0aGVuDQogICAgICBz ZXQgbm9obnMgDQogICAgICBlY2hvICJOT0hOUyBkZWFjdGl2YXRlZCBieSBF TkVSR1kgY29udmVyZ2VuY2UiCQk+PiAkZGF5ZmlsZQ0KICBlbHNlDQogICAg ICBzZXQgaXRlciA9IDENCiAgZW5kaWYNCmVuZGlmDQoNCmNoYXJnZXRlc3Q6 DQojaWYgKCRjY3V0ID09ICIwIikgZ290byBuZXh0aXRlcg0Kc2V0IGN0ZXN0 ID0gKGAkYmluL3Rlc3Rjb252IC1wIDpESVMgLWMgJGNjdXRgKQkNCnRlc3Rz dGF0dXMNCmVjaG8gIjpDSEFSR0UgY29udmVyZ2VuY2U6ICAkY3Rlc3RbMS0z XSIJCT4+ICRkYXlmaWxlDQppZiAoJGN0ZXN0WzFdKSB0aGVuDQogIGlmICgk bm9obnMgPT0gJy1ub2hucycpIHRoZW4NCiAgICAgIHNldCBub2hucyANCiAg ICAgIGVjaG8gIk5PSE5TIGRlYWN0aXZhdGVkIGJ5IENIQVJHRSBjb252ZXJn ZW5jZSIJCT4+ICRkYXlmaWxlDQogIGVsc2UNCiAgICAgIHNldCBpdGVyID0g MQ0KICBlbmRpZg0KZW5kaWYNCg0KIy0tLT4gb3V0cHV0IGZvcmNlcw0KI2dy ZXAgJ0ZUT1QnICRmaWxlLm91dHB1dG18YXdrICd7cHJpbnQgIkZUICIsJDIs JDQsJDUsJDZ9J1wNCiMJCQkJCT4+ICRkYXlmaWxlDQojZ3JlcCAnRlRPVCcg JGZpbGUub3V0cHV0bXxhd2sgJ3twcmludCAkNCwkNSwkNn0nIFwNCiMJCQkJ CT4+ICRmaWxlLmZpbk0JDQoNCm5leHRpdGVyOg0KQCAgaXRlciAtLQ0KQCBy aXRlciAtLQ0KQCBub2huczEgLS0NCkAgaWN5Y2xlICsrDQoNCiMtLS0+IG5v aG5zDQppZiAoISAkbm9obnMxICkgdGhlbg0KICBzZXQgbm9obnMNCiAgZWNo byAiTk9ITlMgZGVhY3RpdmF0ZWQiIAkJCT4+ICRkYXlmaWxlDQplbmRpZg0K DQojLS0tPiByZXN0YXJ0DQppZiAoISAkcml0ZXIgJiYgLWUgJGZpbGUuYnJv eWQxKSB0aGVuDQogIGVjaG8gIiAgICByZXN0YXJ0IiAJCQk+PiAkZGF5Zmls ZQ0KICBybSAkZmlsZS5icm95ZDEgJGZpbGUuYnJveWQyDQogIHNldCByaXRl cj0kcml0ZXJfc2F2ZQ0KZW5kaWYNCg0KZm9yZWFjaCBpICgkdG1wKQkJCSNk ZWxldGUgdGVtcG9yYXJ5IGZpbGVzDQogIGlmICgtZSAkaSkgcm0gJGkNCmVu ZA0KDQojb3V0cHV0CQljeWNsZQ0KcHJpbnRmICIlc1xuXG4iICIkaXRlci8k cml0ZXIgdG8gZ28iIAk+PiAkZGF5ZmlsZQ0KaWYgKC1lIC5zdG9wKSBnb3Rv IHN0b3AxDQoNCmlmICgkaXRlcikgZ290byBjeWNsZQkJCSNlbmQgb2Ygc2Mt Y3ljbGUNCg0KaWYgKCAkP2Zfbm90X2NvbnYgKSB0aGVuDQogICAgICBwcmlu dGYgIlxuPiAgIEZPUkNFUyBOT1QgQ09OVkVSR0VEXG4iCQkJPj4gJGRheWZp bGUgICAgDQogICAgICBleGl0IDMNCmVuZGlmDQoNCnN0b3A6CQkJCQkjbm9y bWFsIGV4aXQNCnByaW50ZiAiXG4+ICAgc3RvcFxuIgkJCT4+ICRkYXlmaWxl DQpleGl0IDAgDQoNCnN0b3AxOgkJCQkJI25vcm1hbCBleGl0DQpwcmludGYg IlxuPiAgIHN0b3AgZHVlIHRvIC5zdG9wIGZpbGVcbiIJCQk+PiAkZGF5Zmls ZQ0KaWYgKC1lIC5zdG9wKSBybSAuc3RvcA0KZXhpdCAwIA0KDQplcnJvcl9p bnB1dDoJCQkJCSNlcnJvciBleGl0CQ0KcHJpbnRmICJcbj4gICBzdG9wIGVy cm9yOiB0aGUgcmVxdWlyZWQgaW5wdXQgZmlsZSAkZXJyaW4gZm9yIHRoZSBu ZXh0IHN0ZXAgY291bGQgbm90IGJlIGZvdW5kXG4iCQk+PiAkZGF5ZmlsZQ0K ZXhpdCAxDQoNCmVycm9yOgkJCQkJI2Vycm9yIGV4aXQJDQpwcmludGYgIlxu PiAgIHN0b3AgZXJyb3JcbiIJCT4+ICRkYXlmaWxlDQpleGl0IDENCg0KaGVs cDoJCQkJCSNoZWxwIGV4aXQgDQpjYXQgPDwgdGhlZW5kIA0KDQpQUk9HUkFN OgkkMA0KDQpQVVJQT1NFOglydW5uaW5nIHRoZSBzcGlucG9sYXJpemVkIHNj Zi1jeWNsZSBpbiBXSUVODQoJCXRvIGJlIGNhbGxlZCB3aXRoaW4gdGhlIGNh c2UtZGlyZWN0b3J5DQoJCWhhcyB0byBiZSBsb2NhdGVkIGluICckV0lFTlJP T1QnIGRpcmVjdG9yeQ0KDQpVU0FHRToJCSRuYW1lIFtPUFRJT05TXSBbRkxB R1NdDQoNCk9QVElPTlM6DQotY2MgTElNSVQgLT4JY2hhcmdlIGNvbnZlcmNl bmNlIExJTUlUICgkY2N1dCkNCi1lYyBMSU1JVCAtPgllbmVyZ3kgY29udmVy Y2VuY2UgTElNSVQgKCRlY3V0IFJ5KQ0KLWZjIExJTUlUIC0+CWZvcmNlICBj b252ZXJjZW5jZSBMSU1JVCAoJGZjdXQgbVJ5L2EudS4pDQotZSBQUk9HUkFN IC0+CWV4aXQgYWZ0ZXIgUFJPR1JBTSAoJHN0b3BhZnRlcikNCi1pIE5VTUJF UiAtPiAJbWF4LiBOVU1CRVIgKCRpdGVyKSBvZiBpdGVyYXRpb25zDQotcyBQ Uk9HUkFNIC0+IAlzdGFydCB3aXRoIFBST0dSQU0gKCRuZXh0KQ0KLXIgTlVN QkVSIC0+IAlyZXN0YXJ0IGFmdGVyIE5VTUJFUiAoJHJpdGVyKSBpdGVyYXRp b25zIChybSAqLmJyb3lkKikNCi1ub2hucyBOVU1CRVIgLT5kbyBub3QgdXNl IEhOUyBmb3IgTlVNQkVSIGl0ZXJhdGlvbnMgDQotcWwgTElNSVQgLT4gICAg c2VsZWN0IExJTUlUICgkcWxpbWl0KSBhcyBtaW4uY2hhcmdlIGZvciBFLUwg c2V0dGluZyBpbiBuZXcgaW4xDQotaW4xbmV3IE4gLT4gICAgdXNlICJuZXci IGluMSBmaWxlIGFmdGVyIE4gaXRlciAocmV3cml0ZSBpbjEgdXNpbmcgc2Nm IGluZm8pDQoNCkZMQUdTOg0KLWgvLUggLT4JaGVscA0KLUkgICAgLT4Jd2l0 aCBpbml0aWFsaXphdGlvbiBvZiBpbjItZmlsZXMgdG8gIlRPVCIgDQotcCAg ICAtPiAgICAgICAgcnVuIGstcG9pbnRzIGluIHBhcmFsbGVsIChuZWVkcyAu bWFjaGluZSBmaWxlIFtzcGVlZDpuYW1lXSkNCi1zbyAgIC0+CXJ1biBTQ0Yg aW5jbHVkaW5nIHNwaW4tb3JiaXQgY291cGxpbmcNCi1kbSAgIC0+CWNhbGN1 bGF0ZSB0aGUgZGVuc2l0eSBtYXRyaXggKHdoZW4gLXNvIGlzIHNldCwgYnV0 IC1vcmIgaXMgbm90KQ0KLWl0ICAgLT4gICAgICAgIHVzZSBpdGVyYXRpdmUg ZGlhZ29uYWxpemF0aW9uIGFmdGVyIGZpcnN0IGN5Y2xlDQotaXQwICAtPgl1 c2UgaXRlcmF0aXZlIGRpYWdvbmFsaXphdGlvbiAoYWxzbyBpbiBmaXJzdCBj eWNsZSkNCi1vcmIgIC0+ICAgICAgICB1c2UgTERBK1UsIE9QIG9yIEItZXh0 IGNvcnJlY3Rpb24gDQotb3JiYyAtPiAgICAgICAgdXNlIExEQStVIGNvcnJl Y3Rpb24sIGJ1dCB3aXRoIGNvbnN0YW50IFYtbWF0cml4IA0KLXJlbm9ybS0+ ICAgICAgIHN0YXJ0IHdpdGggbWl4ZXIgYW5kIHJlbm9ybWFsaXplIGRlbnNp dHkNCi1pbjFvcmlnLT4gICAgICB1c2UgY2FzZS5pbjFfb3JpZyBmaWxlIChh ZnRlciBhIHByZXZpb3VzIC1pbjFuZXcpDQoJCQ0KQ09OVFJPTCBGSUxFUzoN Ci5zdG9wCQlzdG9wIGFmdGVyIFNDRiBjeWNsZQ0KLmZ1bGxkaWFnCWZvcmNl IGZ1bGwgZGlhZ29uYWxpemF0aW9uDQoNCkVOVklST05NRU5UIFZBUklCTEVT Og0KU0NSQVRDSCAgICAgICAgIGRpcmVjdG9yeSAgd2hlcmUgdmVjdG9ycyBh bmQgaGVscCBmaWxlcyBzaG91bGQgZ28NCg0KdGhlZW5kDQoNCmV4aXQgMQ0K DQoNCg== - ---2105530234-990962995-1031816032=:2496-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 18:00:39 +1000 From: chen0130@flinders.edu.au Subject: Thanks Re: [WIEN]: 'LOPW' ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thankyou! Quoting Peter Blaha : > ==== > Peter Blaha > submitted the following contribution: > ==== > > > Can someone please tell me what the error message > > > > LOPW Plane waves exhausted > > > > for lapw1 in SCF... I have never come across it before... > > Usually, that your struct file is incorrect.(Contains the same atom twice, > not proper symmetry, equivalent atoms,....) > > Regards > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Sep 2002 14:04:56 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: bug in lapw0 for cubic magnetic cases ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-747226996-1031832296=:2496 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear WIEN users, In all WIEN2k versions released so far, there is a significant bug for CUBIC pusitions (IATNR is positive in case.struct) in SPINPOLARIZED calculations. (When V-xc was calculated, the spin-dn density was calculated from the spherical spin-dn part, but with the nonspherical density contributions taken from spin up.) This leads e.g. for AFM-Cr to a permanent (small, like 0.01 uB) ferromagnetic moment in an unconstraint runsp_lapw calculation. From this experience one can estimate that cubic magnetic moments may be wrong by up to 0.1 uB and also E-tot will be wrong by a few mRy/atom. Please download the new SRC_lapw0.tar.gz or replace srolyl.f with the attached file. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-747226996-1031832296=:2496 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="srolyl.f" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="srolyl.f" ICAgICAgc3Vicm91dGluZSBzcm9seWwoY2xtc3B1LGNsbXNwZCx5eSxzcWZw LCAmDQogICAgICAgICAgICAgICAgICAgICAgICBpYXRucixsbG1tLGZ1LGZk LGZ0LGxtLGxtbWF4KQ0KIQ0KICAgICAgaW1wbGljaXQgcmVhbCo4IChhLWgs by16KQ0KIQ0KICAgICAgSU5DTFVERSAncGFyYW0uaW5jJw0KIQ0KICAgICAg UkVBTCo4ICAgOjogIGNfa3ViKDA6MTAsMDoxMCkNCiAgICAgIENPTU1PTiAv bm9ybV9rdWIvIGNfa3ViDQogICAgICBJTlRFR0VSICAgICA6OiBMTSgyLE5D T00rMykNCiAgICAgIGRpbWVuc2lvbiBjbG1zcHUobmNvbSksY2xtc3BkKG5j b20pLHl5KG5jb20pDQohDQogICAgICBzcXJ0Mj1TUVJUKDIuZDApDQoNCiAg ICAgIGZ1PUNMTVNQVSgxKSpZWSgxKS9TUUZQICAgICAgICAgICAgICAgICAg DQogICAgICBmZD1DTE1TUEQoMSkqWVkoMSkvU1FGUCAgICAgICAgICAgICAg ICAgIA0KIS0tLS0tLS0tLS0tLS0NCiAgICAgIElGKElBVE5SLkxULjApIFRI RU4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgRE8gOCBMTTE9MixMTE1NICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgIGZ1PWZ1K0NMTVNQ VShsbTEpKllZKGxtMSkgICAgICAgICAgICAgICAgICANCiAgICAgICAgZmQ9 ZmQrQ0xNU1BEKGxtMSkqWVkobG0xKSAgICAgICAgICAgICAgICAgIA0KIDgg ICAgIGNvbnRpbnVlDQohICAgICAgIElGKGZ1LkxULjAuMGQwKSB0aGVuDQoh ICAgICAgICBXUklURSgqLDI5MjkpIExNMSxmdSxDTE1TUFUsWVkgIA0KISAg ICAgICAgZnU9MS5lLTYNCiEgICAgICAgIGVuZCBpZiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQohICAgICAgICBJRihmZC5MVC4w LjBkMCkgdGhlbg0KISAgICAgICAgV1JJVEUoKiwyOTI5KSBMTTEsZmQsQ0xN U1BELFlZICANCiEgICAgICAgIGZkPTEuZS02DQohICAgICAgICBlbmQgaWYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KISAyOTI5 IEZPUk1BVCgnIExNMSxmZCxDTE0sWVkgJyxpNCwoNEUxNi41KSkgICAgICAg ICAgICAgICAgICANCiEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQohICAgICAg RUxTRSBJRihMTE1NLkdULjEpICBUSEVOICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCiAgICAgIEVMU0UNCg0KICAgICAgaXl5 PTANCiAgICAgIGk9MQ0KICAgICAgRE8NCiEgICAgICAgICB3cml0ZSg2LCop ICdpeXknLGl5eQ0KDQogICAgICAgICBJRihpLmd0LmxtbWF4KSBFWElUDQog ICAgICAgICBJRihsbSgxLGkpLkVRLjAuQU5ELmxtKDIsaSkuRVEuMCkgVEhF Tg0KICAgICAgICAgICAgaXl5PWl5eSsxDQogICAgICAgICAgICBpPWkrMQ0K ICAgICAgICAgRUxTRUlGIChsbSgxLGkpLkVRLi0zLkFORC5sbSgyLGkpLkVR LjIpIFRIRU4gIA0KICAgICAgICAgICAgaXl5PWl5eSsxDQohICAgICAgICAg ICAgd3JpdGUoNiwqKSAnTE0oLTMsMikuIGl5eT0nLGl5eSwnaT0nLGkNCiAg ICAgICAgICAgIGZ1PWZ1K2NsbXNwdShpKSp5eShpeXkpDQogICAgICAgICAg ICBmZD1mZCtjbG1zcGQoaSkqeXkoaXl5KQ0KICAgICAgICAgICAgaT1pKzEN CiAgICAgICAgIEVMU0VJRiAobG0oMSxpKS5FUS40Lk9SLmxtKDEsaSkuRVEu Ni5PUi4gJg0KICAgICAgICAgICAgICAgICBsbSgxLGkpLkVRLi03Lk9SLmxt KDEsaSkuRVEuLTkgKSBUSEVOICANCiAgICAgICAgICAgIGMxPWNfa3ViKGFi cyhsbSgxLGkpKSxsbSgyLGkpKQ0KICAgICAgICAgICAgYzI9Y19rdWIoYWJz KGxtKDEsaSkpLGxtKDIsaSkrNCkNCiAgICAgICAgICAgIGl5eT1peXkrMQ0K ICAgICAgICAgICAgZnU9ZnUrKGMxKkNMTVNQVShpKStjMipDTE1TUFUoaSsx KSkqWVkoaXl5KQ0KICAgICAgICAgICAgZmQ9ZmQrKGMxKkNMTVNQZChpKStj MipDTE1TUGQoaSsxKSkqWVkoaXl5KQ0KICAgICAgICAgICAgaT1pKzINCiAg ICAgICAgIEVMU0VJRiAobG0oMSxpKS5FUS44Lk9SLmxtKDEsaSkuRVEuMTAp IFRIRU4gDQogICAgICAgICAgICBpeXk9aXl5KzENCiAgICAgICAgICAgIGMx PWNfa3ViKGFicyhsbSgxLGkpKSxsbSgyLGkpKQ0KICAgICAgICAgICAgYzI9 Y19rdWIoYWJzKGxtKDEsaSkpLGxtKDIsaSkrNCkNCiAgICAgICAgICAgIGMz PWNfa3ViKGFicyhsbSgxLGkpKSxsbSgyLGkpKzgpDQogICAgICAgICAgICBm dT1mdSsoYzEqQ0xNU1BVKGkpK2MyKkNMTVNQVShpKzEpICsgICYNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjMypDTE1TUFUoaSsyKSAgKSpZWShp eXkpDQogICAgICAgICAgICBmZD1mZCsoYzEqQ0xNU1BkKGkpK2MyKkNMTVNQ ZChpKzEpICsgICYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjMypD TE1TUGQoaSsyKSAgKSpZWShpeXkpDQogICAgICAgICAgICBpPWkrMw0KICAg ICAgICAgRUxTRQ0KICAgICAgICAgICAgV1JJVEUoNiwqKSAnVU5DT1JSRUNU IExNIExJU1QgRk9SIENVQklDIFNUUlVDVFVSRScNCiAgICAgICAgICAgIFdS SVRFKDYsKikgJ3Nyb2x5bC5mJw0KICAgICAgICAgICAgU1RPUA0KICAgICAg ICAgRU5ESUYNCiAgICAgIEVORCBETw0KICAgICAgSUYoaXl5Lk5FLmxsbW0p IFRIRU4NCiAgICAgICAgIHdyaXRlKDYsKikgJ2l5eT0nLGl5eSwnIGRpZmZl cmVudCBmcm9tIGxsbW09JyxsbG1tDQogICAgICAgICBTVE9QDQogICAgICBF TkRJRg0KICAgICAgRU5ESUYNCg0KICAgICAgZnQ9ZnUrZmQgDQohDQogICAg ICByZXR1cm4NCiAgICAgIGVuZA0K - ---2105530234-747226996-1031832296=:2496-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Sep 2002 06:43:33 -0700 (PDT) From: hamid salehi Subject: [WIEN]: DOS-dn ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started DOS -don and got this message(PGFIO-F-231/formated read/unit=5/error on data conversion. FILE Name: home inst Formated,sequential access record =4 In source file tetra,at line number 90\ 0.010u,0.00s.... 0+0k what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Sep 2002 11:47:39 -0400 From: Fred Nastos Subject: [WIEN]: ==== Fred Nastos submitted the following contribution: ==== I'm interested in calculating spin-populations and coherences due to optical excitations. To do this I need the quantities where |mk> are the spinor wavefunctions, and sigma is a Pauli matrix. I am only interested in the matrix elements between states at the same k-point. Presumably, these quantities are somewhere in the code when m=n=valence band, but I need them for valence and conduction bands. Does any part of the WIEN2k code explicitly calculate this? If not, does anyone have any hints as to where to begin if I wanted to calculate these. Thanks, Fred ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Sep 2002 21:30:00 +0000 From: "SOHAIL AFZAL" Subject: [WIEN]: Request to add in your mailing list ==== "SOHAIL AFZAL" submitted the following contribution: ==== Dear Professor, It will be highly appreciated if you kindly add the fallowing addresses on your mailing list. rasofi@hotmail.com energy@cyber.net.pk Hope a favorable action With best Regards Sohail Afzal Tahir Centre for High Energy Physics University of the Punjab Quaid-i-Azam Campus Lahore Pakistan _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Sep 2002 23:23:21 -0700 From: Jiang Bin Subject: [WIEN]: Question on orientation dependence EELS calculation ==== Jiang Bin submitted the following contribution: ==== This is a multi-part message in MIME format. - --Boundary_(ID_PwtEJqpq4WIw+naZPXHOeA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7bit Dear Prof. I have question on the EELS calculation. The crystal is MgB2. I attached the case.struct file and case.innes file for you to check. Several question on the orientation calculation EELS (1) What's the Euler angle's of the observation basis and crystal basis. (2) How to choose the Euler angle to let q//c and q//x etc. (3) The procedure to launch programs and modification of case.struct. (4) for the case of "H", How to modify the files and procedure to launch calculation (not for MgB2). (5) is "F" follow the same procedure for calculation as "H" option. (when should I change ISPLIT=88 in case.struct file) (5) For Mg L-edge. Could I modify the core energy to -3.0 Ry to include Mg-2s orbital into core orbital for EELS calculation? - -- Best regards Bin Jiang - --------------------------------- Department of Physics & Astronomy Arizona State University Tempe, AZ 85287-1504 USA Email: jiangb@asu.edu - ------------------------------------ - --Boundary_(ID_PwtEJqpq4WIw+naZPXHOeA) Content-type: text/plain; charset=gb2312; name="mgb2.struct" Content-transfer-encoding: 7bit Content-disposition: inline; filename="mgb2.struct" MgB2 H LATTICE,NONEQUIV. ATOMS: 2191_P6/mmm MODE OF CALC=RELA unit=bohr 5.826784 5.826784 6.654295 90.000000 90.000000120.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 4 Mg1 NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 12.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.33333300 Y=0.66666700 Z=0.50000000 MULT= 2 ISPLIT= 4 -2: X=0.66666700 Y=0.33333300 Z=0.50000000 B 1 NPT= 781 R0=0.00010000 RMT= 1.6500 Z: 5.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 24 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 0-1 0 0.0000000 1-1 0 0.0000000 0 0 1 0.0000000 2 - -1 1 0 0.0000000 - -1 0 0 0.0000000 0 0 1 0.0000000 3 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 4 0 1 0 0.0000000 - -1 1 0 0.0000000 0 0 1 0.0000000 5 1-1 0 0.0000000 1 0 0 0.0000000 0 0 1 0.0000000 6 0 1 0 0.0000000 1 0 0 0.0000000 0 0-1 0.0000000 7 1-1 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 8 - -1 0 0 0.0000000 - -1 1 0 0.0000000 0 0-1 0.0000000 9 0-1 0 0.0000000 - -1 0 0 0.0000000 0 0-1 0.0000000 10 - -1 1 0 0.0000000 0 1 0 0.0000000 0 0-1 0.0000000 11 1 0 0 0.0000000 1-1 0 0.0000000 0 0-1 0.0000000 12 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 13 0 1 0 0.0000000 - -1 1 0 0.0000000 0 0-1 0.0000000 14 1-1 0 0.0000000 1 0 0 0.0000000 0 0-1 0.0000000 15 1 0 0 0.0000000 0 1 0 0.0000000 0 0-1 0.0000000 16 0-1 0 0.0000000 1-1 0 0.0000000 0 0-1 0.0000000 17 - -1 1 0 0.0000000 - -1 0 0 0.0000000 0 0-1 0.0000000 18 0-1 0 0.0000000 - -1 0 0 0.0000000 0 0 1 0.0000000 19 - -1 1 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 20 1 0 0 0.0000000 1-1 0 0.0000000 0 0 1 0.0000000 21 0 1 0 0.0000000 1 0 0 0.0000000 0 0 1 0.0000000 22 1-1 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 23 - -1 0 0 0.0000000 - -1 1 0 0.0000000 0 0 1 0.0000000 24 - --Boundary_(ID_PwtEJqpq4WIw+naZPXHOeA) Content-type: text/plain; charset=gb2312; name="mgb2.innes" Content-transfer-encoding: 7bit Content-disposition: inline; filename="mgb2.innes" Title: Atom 1 K Peak 2, 1 (atom) 1 (n core) 0 (l core) 0,0.0,100 (EMIN,DE,EMAX) 190, 0, .8 (E-Loss of 1st edge, split between edges, precision, all in eV) 120 (energy of the incident electrons (keV)) 0, 0 (ThetaX, ThetaY in mrad) 0 (double of Bragg angle in mrad) 0, 0, 0 (DeltaX, DeltaY, Number of cases - 1: (0=1 case)) 4 (LambdaMax) L (L for Line and P for Plane) N (N: Normal (l' DOS); F: Fine (l' m' DOS); H: HyperFine ...) 0.0, 0.0, 0.0 (Euler's angles between the observator basis and the cristal basis in degrees) 0.2 (Spectrometer aperture in mrad) 0.2 (convergence angle in mrad) 3, 4 (NR, NT) - --Boundary_(ID_PwtEJqpq4WIw+naZPXHOeA)-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 15 Sep 2002 07:30:21 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k_02 users: In the latest version wien2k_02, when I use it to calculate , there are always have some message like this: warn ingergation 28.99328888,should be 29 NOE: number of electrons =29 ------------ ------------ Total "warnning"Total energy in Ry =-28342.5000000Ry from the message this mean that the NOE is 29 and during some SCF interation ,the intergation value of NOE is not 29. So I want to know these question: 1; what's this warn mean? 2: How can I avoid this warn? for example, can I change a larger RMT to avoid this ,or can I choose a low energy in lstart?(for : change -6.0 Ry to -7.0 Ry?) 3:How can it affect my result? If the difference between ingergraton velue and the true value is small(like in my case ,just 0.006),can I neglect it? Hai _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 16 Sep 2002 18:23:51 +0800 From: joshua xie Subject: [WIEN]: Calculation about diamond ==== joshua xie submitted the following contribution: ==== For diamond, I set the two C atoms in FCC with positions (0,0,0) and (1/4,1/4,1/4), respectively. When initializing the calculation there is a warning which is "YOU MUST MOVE THE ORIGIN". I do not know how to cope with this porblem, would someone help me? Thanks in advance. Best regards! Joshua ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 16 Sep 2002 12:37:50 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Calculation about diamond ==== Peter Blaha submitted the following contribution: ==== > For diamond, I set the two C atoms in FCC with positions (0,0,0) and (1/4,1/4,1/4), respectively. > When initializing the calculation there is a warning which is "YOU MUST MOVE THE ORIGIN". Use (1/8,1/8,1/8) and (7/8,7/8,7/8) or WIEN2k !!! 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Sep 2002 18:12:46 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question on maximum number of inequivalent atoms in unit cell ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I am using WIEN97 with graphic interface (WIEN in a Box) to calculate CNT. Actually, I have already successful to calculate CNT(5,0) with WIEN with inequivalent atoms equals 3. However, I can't perform the calculation with CNT(5,5). The problem is that outputnn file only contains 3 lines as below: cnt55 P 10 RELA Then, below is my input file: cnt55 P LATTICE,NONEQUIV. ATOMS: 1 MODE OF CALC=RELA 4.651079 18.897269 18.897269 90.000000 90.000000 90.000000 Atom= -1: X=0.75000000 Y=0.83923876 Z=0.50000000 MULT=20 ISPLIT= 8 Atom= -1: X=0.75000000 Y=0.80991003 Z=0.63798083 Atom= -1: X=0.25000000 Y=0.77444992 Z=0.69939954 Atom= -1: X=0.25000000 Y=0.66961938 Z=0.79378939 Atom= -1: X=0.75000000 Y=0.60483054 Z=0.82263523 ....... Then, I would like to consult about the maximum number of inequivalent atoms in a unit cell supported by WIEN97. Or there is an option for setting the maximum number of inequivalent atoms in a unit cell. If it is so, how to set the maximum number of inequivalent atoms in a unit cell? Thank you Martin - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Sep 2002 19:35:59 +0200 (METDST) From: John Tatini Titantah Subject: [WIEN]: electron density difference ==== John Tatini Titantah submitted the following contribution: ==== Dear wien users, This question might have been raised some times on this forum but I would still pose it. I am trying to do calculations on N sibstituted graphite (1N+15C) and I am interested in studing the charge transfer processes. For this it is very instructive to look at the charge density difference, where charge density difference stands for the difference between the crystalline charge density and the superposed atomic densities. I thought the DIFF switch in *.in5 would give this quantity but it does not seem to be the case. I expect to obtain regions of negative and others of positive charges but I do not get this on my substituted graphene plane. What is it that I have missed? I even changed EMIN of *.in2 to the energy of the highest occupied state (which in my case is -0.01Ry as seen on the eigen values in *.scf. Can someone indicate to me what aspect I have not considered? Thanks very much for your suggestions @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Dr. Titantah John Tatini Theoretical Study of Matter Department of Physics University of Antwerpen Groenenborgerlaan 171 2020 Antwerpen BELGIUM Tel: +32-3-2180-312 fax: +32-3-2180-318 gsm: +32-494-143515 email: jtitanta@ruca.ua.ac.be @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Sep 2002 16:05:35 -0300 (ARST) From: Fabian Dominguez Subject: [WIEN]: Problem with number of states when DOS is doing. ==== Fabian Dominguez submitted the following contribution: ==== Hello Wien users, I'm running Fe-H with H in different positions and the following problema arise. When I do DOS and then I plot it no states appears under -10 eV, this happens when Total DOS is done or total 'p', 'd','s'...and in all cases, I mean for differents positions of Hydrogen. Trying to solve this problem I change the range in *int but nothing happens. Then I select in *in1/in1c the lower limit of the energy window, but nothing happens. I did the same in *klist. After I try changing in *in2/in2c EMIN from -9 to -14, well my porpuse was to get this value lower. And nothing happens. QUESTIONS: 1-/ How can I solve this problem because I think there should be states under - -10 eV, What coud be the problem? 2-/ Related to change in *in2/*in2c from -9 to -14 does it affect anything the previous self consistent running done, or I's a enough one more iteration only? Thanks to who could help me. Fabian ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 09:11:43 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: electron density difference ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > John Tatini Titantah > submitted the following contribution: > ==== > > This question might have been raised some times on this forum but I > would still pose it. I am trying to do calculations on N sibstituted > graphite (1N+15C) and I am interested in studing the charge transfer > processes. For this it is very instructive to look at the charge density > difference, where charge density difference stands for the difference > between the crystalline charge density and the superposed atomic > densities. I thought the DIFF switch in *.in5 would give this quantity but > it does not seem to be the case. I expect to obtain regions of negative > and others of positive charges but I do not get this on my substituted > graphene plane. What is it that I have missed? I even changed EMIN of > *.in2 to the energy of the highest occupied state (which in my > case is -0.01Ry as seen on the eigen values in *.scf. Can someone indicate > to me what aspect I have not considered? Have a look in the UG at the first paragraphs of the lstart explanation. The atomic densities used for subtraction with DIFF in lapw5 are created only if you include a 'P' with the relevant orbitals. Put the P's there, rerun lstart, and then lapw5. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 09:05:28 +0200 From: =?US-ASCII?Q?Anders_Froseth?= Subject: SV: [WIEN]: electron density difference ==== =?US-ASCII?Q?Anders_Froseth?= submitted the following contribution: ==== Dear John! For lapw5 to calculate the bonding charge density you need to have the atomic electron densities in the .sigma file. The .sigma file is created by lstart using the .inst file as input. For each atomic orbital from which you need the density, you have to replace an N with a P in the .inst file. So - edit the .inst file, run lstart and then run lapw5 again. This will hopefully solve your problem.. Regards Anders Froseth > -----Opprinnelig melding----- > Fra: owner-wien@zeus.theochem.tuwien.ac.at > [mailto:owner-wien@zeus.theochem.tuwien.ac.at]Pa vegne av John Tatini > Titantah > Sendt: 17. september 2002 19:36 > Til: wien@zeus.theochem.tuwien.ac.at > Emne: [WIEN]: electron density difference > > > ==== > John Tatini Titantah > submitted the following contribution: > ==== > > Dear wien users, > This question might have been raised some times on this forum but I > would still pose it. I am trying to do calculations on N sibstituted > graphite (1N+15C) and I am interested in studing the charge transfer > processes. For this it is very instructive to look at the charge density > difference, where charge density difference stands for the difference > between the crystalline charge density and the superposed atomic > densities. I thought the DIFF switch in *.in5 would give this quantity but > it does not seem to be the case. I expect to obtain regions of negative > and others of positive charges but I do not get this on my substituted > graphene plane. What is it that I have missed? I even changed EMIN of > *.in2 to the energy of the highest occupied state (which in my > case is -0.01Ry as seen on the eigen values in *.scf. Can someone indicate > to me what aspect I have not considered? > Thanks very much for your suggestions > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > Dr. Titantah John Tatini > Theoretical Study of Matter > Department of Physics > University of Antwerpen > Groenenborgerlaan 171 > 2020 Antwerpen > BELGIUM > Tel: +32-3-2180-312 > fax: +32-3-2180-318 > gsm: +32-494-143515 > email: jtitanta@ruca.ua.ac.be > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 11:48:45 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: electron density difference ==== "Saeid Jalali" submitted the following contribution: ==== > This question might have been raised some times on this forum but I > would still pose it. I am trying to do calculations on N sibstituted > graphite (1N+15C) and I am interested in studing the charge transfer > processes. For this it is very instructive to look at the charge density > difference, where charge density difference stands for the difference > between the crystalline charge density and the superposed atomic > densities. I thought the DIFF switch in *.in5 would give this quantity but > it does not seem to be the case. I expect to obtain regions of negative > and others of positive charges but I do not get this on my substituted > graphene plane. What is it that I have missed? I even changed EMIN of > *.in2 to the energy of the highest occupied state (which in my > case is -0.01Ry as seen on the eigen values in *.scf. Can someone indicate > to me what aspect I have not considered? Is not your case.sigma file empty? If it is change N to P (capital P) in your case.inst to generate atomic charge densities: only after this DIFF works. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 11:38:48 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Problem with number of states when DOS is doing. ==== "Saeid Jalali" submitted the following contribution: ==== > I'm running Fe-H with H in different positions and the following problema > arise. > > When I do DOS and then I plot it no states appears under -10 eV, this > happens when Total DOS is done or total 'p', 'd','s'...and in all cases, I > mean for differents positions of Hydrogen. > > Trying to solve this problem I change the range in *int but nothing > happens. > Then I select in *in1/in1c the lower limit of the energy window, but > nothing happens. I did the same in *klist. > After I try changing in *in2/in2c EMIN from -9 to -14, well my porpuse was > to get this value lower. And nothing happens. Please notice that the unit of energy in input files is in Ry and not in eV, so if you are looking for something around 10eV, it is not needed to change EMIN in case.in1 (not case.in2) file. Instead if one is interested in energies grater than 1.5Ry, it is necessary to increase Emax in case.in1 file. > QUESTIONS: > > 1-/ > > How can I solve this problem because I think there should be states under > -10 eV, What coud be the problem? I don't know if some states should be there at around -10eV or not, but if you think so just change the Emin in case.int to -1.0 Ry. Below the valence states towards semi core states the bands are not so broad: they are usually narrow. To observe narrow bands one would first open the case.dos1evup(dn) via a plain text editor to find where the narrow bands are. After finding the interval energy one can plot the state using wien2k interface or any other graphical tools, e.g. gnuplot or so. > 2-/ > > Related to change in *in2/*in2c from -9 to -14 does it affect anything the > previous self consistent running done, or I's a enough one more iteration > only? I guess it would be clear now. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 09:23:24 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problem with number of states when DOS is doing. ==== Peter Blaha submitted the following contribution: ==== > I'm running Fe-H with H in different positions and the following problema > arise. > > When I do DOS and then I plot it no states appears under -10 eV, this > happens when Total DOS is done or total 'p', 'd','s'...and in all cases, I > mean for differents positions of Hydrogen. > > How can I solve this problem because I think there should be states under > -10 eV, What coud be the problem? Why do you think so ? Look into your scf file and check where you have eigenvalues. Then consider EF and convert from Ry to eV and you KNOW where your states should be. (Personally I expect for Fe-H systems only states at about -4 Ry (Fe 3p), which is -50 eV or so. For those atomic like states a DOS is meaningless (althoug you can get it, when your e-mesh in case.int is fine enough). Changing EMIN from -9 to -14 means (Ry units!!!!) nothing for your case. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 09:42:22 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Question on maximum number of inequivalent atoms in unit cell ==== Peter Blaha submitted the following contribution: ==== > I am using WIEN97 with graphic interface (WIEN in a Box) to calculate > CNT. Actually, I have already successful to calculate CNT(5,0) with > WIEN with inequivalent atoms equals 3. However, I can't perform the > calculation with CNT(5,5). The problem is that outputnn file only contains > 3 lines as below: > > cnt55 > P 10 > RELA > > Then, below is my input file: > > cnt55 > P LATTICE,NONEQUIV. ATOMS: 1 > MODE OF CALC=RELA > 4.651079 18.897269 18.897269 90.000000 90.000000 90.000000 > Atom= -1: X=0.75000000 Y=0.83923876 Z=0.50000000 > MULT=20 ISPLIT= 8 > Atom= -1: X=0.75000000 Y=0.80991003 Z=0.63798083 > Atom= -1: X=0.25000000 Y=0.77444992 Z=0.69939954 > Atom= -1: X=0.25000000 Y=0.66961938 Z=0.79378939 > Atom= -1: X=0.75000000 Y=0.60483054 Z=0.82263523 > ....... > > > Then, I would like to consult about the maximum number of inequivalent > atoms in a unit cell supported by WIEN97. Or there is an option for > setting the maximum number of inequivalent atoms in a unit cell. If it is > so, how to set the maximum number of inequivalent atoms in a unit cell? In WIEN97 you must redimension the program using siteconfig. The relevant parameters are NATO and NDIF (see the UG for nn and for other programs). PS: This is not necessary with WIEN2k because of dynamical allocation) However, your struct file looks strange. There is no spacegroup with MULT=20,.... Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 12:14:58 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Question on maximum number of inequivalent atoms in unit cell ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_006D_01C25F0D.014A8630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I am using WIEN97 with graphic interface (WIEN in a Box) to calculate=20 > CNT. Actually, I have already successful to calculate CNT(5,0) with=20 > WIEN with inequivalent atoms equals 3. However, I can't perform the=20 > calculation with CNT(5,5). The problem is that outputnn file only = contains=20 > 3 lines as below: >=20 > cnt55 > P 10 > RELA >=20 > Then, below is my input file: >=20 > cnt55 > P LATTICE,NONEQUIV. ATOMS: 1 > MODE OF CALC=3DRELA > 4.651079 18.897269 18.897269 90.000000 90.000000 90.000000 > Atom=3D -1: X=3D0.75000000 Y=3D0.83923876 Z=3D0.50000000 > MULT=3D20 ISPLIT=3D 8 > Atom=3D -1: X=3D0.75000000 Y=3D0.80991003 Z=3D0.63798083 > Atom=3D -1: X=3D0.25000000 Y=3D0.77444992 Z=3D0.69939954 > Atom=3D -1: X=3D0.25000000 Y=3D0.66961938 Z=3D0.79378939 > Atom=3D -1: X=3D0.75000000 Y=3D0.60483054 Z=3D0.82263523 > ....... >=20 >=20 > Then, I would like to consult about the maximum number of inequivalent = > atoms in a unit cell supported by WIEN97. Or there is an option for=20 > setting the maximum number of inequivalent atoms in a unit cell. If it = is=20 > so, how to set the maximum number of inequivalent atoms in a unit = cell? You would check the following default parameters for your case. PARAMETER (NATO=3D 64)=20 PARAMETER (NNN=3D10000)=20 PARAMETER (NDIF=3D 99)=20 PARAMETER (mshell=3D 100)=20 NATO NUMBER OF NONEQUIVALENT ATOMS=20 NNN NUMBER OF NEIGHBOURS=20 NDIF NUMBER OF ALL ATOMS IN UNITCELL=20 MSHELL Max. Nr. of SHELLS And if necessary try to change them in nn program, and recompile nn. Your, Saeid. - ------=_NextPart_000_006D_01C25F0D.014A8630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> I am using WIEN97 with graphic = interface (WIEN=20 in a Box) to calculate
> CNT. Actually, I have already successful = to=20 calculate CNT(5,0) with
> WIEN with inequivalent atoms equals 3. = However,=20 I can't perform the
> calculation with CNT(5,5). The problem is = that=20 outputnn file only contains
> 3 lines as below:
>
>=20 cnt55
> = P          =20 10
>      RELA
>
> Then, below is = my=20 input file:
>
> cnt55
> P   = LATTICE,NONEQUIV.=20 ATOMS: 1
> MODE OF CALC=3DRELA
>   4.651079 18.897269 = 18.897269=20 90.000000 90.000000 90.000000
> Atom=3D -1: X=3D0.75000000 = Y=3D0.83923876=20 Z=3D0.50000000
> =          =20 MULT=3D20          = ISPLIT=3D 8
>=20 Atom=3D -1: X=3D0.75000000 Y=3D0.80991003 Z=3D0.63798083
> Atom=3D = - -1: X=3D0.25000000=20 Y=3D0.77444992 Z=3D0.69939954
> Atom=3D -1: X=3D0.25000000 = Y=3D0.66961938=20 Z=3D0.79378939
> Atom=3D -1: X=3D0.75000000 Y=3D0.60483054 = Z=3D0.82263523
>=20 .......
>
>
> Then, I would like to consult about = the=20 maximum number of inequivalent
> atoms in a unit cell supported = by=20 WIEN97. Or there is an option for
> setting the maximum number of = inequivalent atoms in a unit cell. If it is
> so, how to set the = maximum=20 number of inequivalent atoms in a unit cell?
You would check the following default = parameters=20 for your case.

PARAMETER (NATO=3D 64)

PARAMETER (NNN=3D10000)

PARAMETER (NDIF=3D 99)

PARAMETER (mshell=3D 100)

NATO NUMBER OF NONEQUIVALENT ATOMS =

NNN NUMBER OF NEIGHBOURS

NDIF NUMBER OF ALL ATOMS IN UNITCELL =

MSHELL Max. Nr. of SHELLS

And if necessary try to change them in nn = program,=20 and recompile nn.

Your,

Saeid.

- ------=_NextPart_000_006D_01C25F0D.014A8630-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #35 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #36 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, September 26 2002 Volume 2002 : Number 036 ---------------------------------------------------------------------- Date: Wed, 18 Sep 2002 11:59:54 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== > In the latest version wien2k_02, when I use it to calculate , there are > always have some message like this: > warn ingergation 28.99328888,should be 29 > NOE: number of electrons =29 > ------------ > ------------ > Total "warnning"Total energy in Ry =-28342.5000000Ry > > from the message this mean that the NOE is 29 and during some SCF > interation ,the intergation value of NOE is not 29. > So I want to know these question: > 1; what's this warn mean? > 2: How can I avoid this warn? for example, can I change a larger RMT > to avoid this ,or can I choose a low energy in lstart?(for : change -6.0 Ry > to -7.0 Ry?) > > 3:How can it affect my result? If the difference between ingergraton > velue and the true value is small(like in my case ,just 0.006),can I > neglect it? If these warnings happen during scf, but at the end of the scf they disappeared, then don't worry. However, if they persist, you must either a) change the k-mesh (x kgen) b) change the Fermi method (to gauss or temp) Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 16:15:34 +0100 (BST) From: Vincent Jennings Subject: [WIEN]: Units. ==== Vincent Jennings submitted the following contribution: ==== Hi, This should be an easy question... I want to check the units for RKmax and Gmax. I figure RKmax should be dimensionless, and Gmax should have dimension of 1/length. Thanks, Vin. - ------------------------------------------------------------------------------- Vincent Jennings "Some days you're the pigeon email: V.L.Jennings@warwick.ac.uk and some days you're the statue." - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 18:13:07 +0200 From: Jutta Rogal Subject: [WIEN]: Gmax convergence ==== Jutta Rogal submitted the following contribution: ==== This is a multi-part message in MIME format. - --------------00BE623C56E4CD7611E6B667 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Wien-users, I have calculated the total energies of Palladium-bulk in an fcc-lattice with one atom in the unit cell, 72 irred. k-points [12x12x12] and a cutoff energy of 24 Ry for the wavefunction. If I now increase the value of Gmax in *.in2, which determines the cutoff energy for the potential, the total energy goes up an seems to converge to some value (as you can see in the attachment). Now my question is: If I increase the cutoff energy for the potential, which means that I'm improving my basis set, should the total energy of my system according to the variational principle not acutally decrease and converge to a certain value instead of increase? Regards Jutta - -- - ----------------------------------------------------------------------- Jutta Rogal phone: 49-30-8413 4807 Fritz-Haber-Institut rogal@fhi-berlin.mpg.de der Max-Planck-Gesellschaft, Abteilung Theorie Faradayweg 4-6 14195 Berlin/Germany - ------------------------------------------------------------------------ - --------------00BE623C56E4CD7611E6B667 Content-Type: text/plain; charset=us-ascii; name="Pd_gmax.TXT" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Pd_gmax.TXT" Gmax E_Pd (Ry) E_Pd (eV) E_Pd (eV)+137334 10 -10094.104853 -137334.334167 -0.334167 11 -10094.101896 -137334.293936 -0.293936 12 -10094.101878 -137334.293691 -0.293691 13 -10094.101243 -137334.285052 -0.285052 14 -10094.100228 -137334.271242 -0.271242 15 -10094.100221 -137334.271147 -0.271147 16 -10094.099491 -137334.261215 -0.261215 18 -10094.098840 -137334.252358 -0.252358 20 -10094.098540 -137334.248276 -0.248276 24 -10094.097732 -137334.237283 -0.237283 30 -10094.097294 -137334.231324 -0.231324 - --------------00BE623C56E4CD7611E6B667-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 11:28:43 -0700 (PDT) From: morteza jamal Subject: [WIEN]: very Wonderfull ==== morteza jamal submitted the following contribution: ==== Dear Wein2k users. We are using LDA+U for UCd3 . There is one Wonderfull things in our result. one ITERATION is REPEATED (for example ITE=14).number of repeat is 22. After 22 REPEATS;number of ITERATIONS change from 14 to 15. There is no error. we used this option for running: "runsp_c_lapw -so -orb -in1new 5 -cc 0.00001 ......." What has happened? Please help me. Best wishes. Morteza Jamal. __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Sep 2002 16:24:49 -0300 (ARST) From: Fabian Dominguez Subject: Re: [WIEN]: Problem with number of states when DOS is doing. ==== Fabian Dominguez submitted the following contribution: ==== Dear Saeid and Wien users, Ok what you said in your answer saeid but I have no solution to my problem since in *int I used units in Ry and I'm not using upper limit in energy window in 1.5 but 3.5, because this is the only way to run lapw2 -qtl - -up/dn and not to get an error of FERMI type...the use of 3.5 is good because total number of electrons are totally included in the window... well this a comment to your answer to mine related to energy window in *in1/*in1c. Another thing is that using TETRA option in *in2/*in2c and upper limit in 1.5 in *in1/*in1c FERMI type error appears, if I use 3.5 no error appears. The point is that I'm not trying to see states around -10eV what I want to see is a DOS in a established range, not nessesary between -10 and for example 5 eV if not a complete DOS, because I think there should be many states under -10eV, I mean to choose a range and be sure that no states are under the lower level selected. thank and I wait for an answer. Fabian ============================***================================= Lic. Fabian Alfredo Dominguez Avenalle. Instituto de Fisica de Liquidos y Sistemas Biologicos (IFLYSIB). Universidad Nacional de La Plata (UNLP). Calle 59 N 789 La Plata CP. 1900 BUENOS AIRES ARGENTINA CC. 565 TE: 0221-4233283 TELEFAX: 0221-4257317 E-MAIL: fabian@iflysib.unlp.edu.ar ============================***================================= ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 08:14:21 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problem with number of states when DOS is doing. ==== Peter Blaha submitted the following contribution: ==== > The point is that I'm not trying to see states around -10eV what I want to > see is a DOS in a established range, not nessesary between -10 and for > example 5 eV if not a complete DOS, because I think there should be many > states under -10eV, I mean to choose a range and be sure that no states > are under the lower level selected. Inspect case.outputt. There you see the bandranges, i.e. the energies where you have eigenvalues ("states"). If there are no states, then the DOS is simply zero!!! Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 08:18:15 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Gmax convergence ==== Peter Blaha submitted the following contribution: ==== > I have calculated the total energies of Palladium-bulk in an fcc-lattice > with one atom in the unit cell, 72 irred. k-points [12x12x12] and a > cutoff energy of 24 Ry for the wavefunction. If I now increase the > value of Gmax in *.in2, which determines the cutoff energy for the > potential, the total energy goes up an seems to converge to some value > (as you can see in the attachment). Now my question is: If I increase > the cutoff energy for the potential, which means that I'm improving my > basis set, should the total energy of my system according to the > variational principle not acutally decrease and converge to a certain > value instead of increase? Increasing GMAX does NOT mean improving the basis set !!! You have only a better description of the coulomb and XC-potential. Thus the variational principle does not apply. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 14:46:30 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: [WIEN] ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I am now using WIEN97 with graphic interface (WIEN In A Box). And the system I am interested in as below: Number of inequivalent atoms : 19 Number of atoms per unit cell : 152 Number of electrons in unit cell : 608 Then, I would like to consult about the setting of the following parameters in siteconfig : KMAX1 KMAX2 KMAX3 NATO NDIF NKPT NMAT NMATIT NUME NUMEIT NWAV Especially, the parameter of NUME and NUMEIT. Thank you very much Martin - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 09:36:14 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Gmax convergence ==== Torsten Andersen submitted the following contribution: ==== Dear Peter, Somehow I always thought that an increasing number of planewaves was an improvement of the basis set used in a specific calculation. And, since increasing GMAX increases the number of planewaves, then why isn't it an improvement? Best regards, Torsten Andersen. Peter Blaha wrote: >==== >Peter Blaha >submitted the following contribution: >==== > >>I have calculated the total energies of Palladium-bulk in an fcc-lattice >>with one atom in the unit cell, 72 irred. k-points [12x12x12] and a >>cutoff energy of 24 Ry for the wavefunction. If I now increase the >>value of Gmax in *.in2, which determines the cutoff energy for the >>potential, the total energy goes up an seems to converge to some value >>(as you can see in the attachment). Now my question is: If I increase >>the cutoff energy for the potential, which means that I'm improving my >>basis set, should the total energy of my system according to the >>variational principle not acutally decrease and converge to a certain >>value instead of increase? >> > >Increasing GMAX does NOT mean improving the basis set !!! >You have only a better description of the coulomb and XC-potential. >Thus the variational principle does not apply. > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 10:14:26 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Gmax convergence ==== Peter Blaha submitted the following contribution: ==== > Somehow I always thought that an increasing number of planewaves was an > improvement of the basis set used in a specific calculation. And, since > increasing GMAX increases the number of planewaves, then why isn't it an > improvement? GMAX increases the number of Fouriercoefficients ("planewaves") for the description of rho and V. (The list at the bottom of the case.clmsum and case.vns files gets "longer"). It has nothing to do with the planewave expansion of your wavefunctions. I.e. the "matrixsize" in lapw1 (case.scf1) is not changed by GMAX (case.in2), but by RKMAX (case.in1) Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 10:18:43 +0200 From: "koitzsch" Subject: Re: [WIEN]: Gmax convergence ==== "koitzsch" submitted the following contribution: ==== I think there is a mix-up between RKmax and gmax here. christian koitzsch - ----- Original Message ----- From: "Torsten Andersen" To: Sent: Thursday, September 19, 2002 9:36 AM Subject: Re: [WIEN]: Gmax convergence > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Dear Peter, > > Somehow I always thought that an increasing number of planewaves was an > improvement of the basis set used in a specific calculation. And, since > increasing GMAX increases the number of planewaves, then why isn't it an > improvement? > > Best regards, > Torsten Andersen. > > Peter Blaha wrote: > > >==== > >Peter Blaha > >submitted the following contribution: > >==== > > > >>I have calculated the total energies of Palladium-bulk in an fcc-lattice > >>with one atom in the unit cell, 72 irred. k-points [12x12x12] and a > >>cutoff energy of 24 Ry for the wavefunction. If I now increase the > >>value of Gmax in *.in2, which determines the cutoff energy for the > >>potential, the total energy goes up an seems to converge to some value > >>(as you can see in the attachment). Now my question is: If I increase > >>the cutoff energy for the potential, which means that I'm improving my > >>basis set, should the total energy of my system according to the > >>variational principle not acutally decrease and converge to a certain > >>value instead of increase? > >> > > > >Increasing GMAX does NOT mean improving the basis set !!! > >You have only a better description of the coulomb and XC-potential. > >Thus the variational principle does not apply. > > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > >-------------------------------------------------------------------------- > > > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > > > > -- > Dr. Torsten Andersen > Department of Physics, Condensed Matter Theory Group, Uppsala University > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace > News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 12:36:46 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Gmax convergence ==== Torsten Andersen submitted the following contribution: ==== Thank you for the clarification... yes, it seems logical, since a larger RKmax gives a larger Gmin, and thereby requires a larger Gmax. Best regards, Torsten Andersen. koitzsch wrote: >==== >"koitzsch" >submitted the following contribution: >==== > >I think there is a mix-up between RKmax and gmax here. > >christian koitzsch > > >----- Original Message ----- >From: "Torsten Andersen" >To: >Sent: Thursday, September 19, 2002 9:36 AM >Subject: Re: [WIEN]: Gmax convergence > > >>==== >>Torsten Andersen >>submitted the following contribution: >>==== >> >>Dear Peter, >> >>Somehow I always thought that an increasing number of planewaves was an >>improvement of the basis set used in a specific calculation. And, since >>increasing GMAX increases the number of planewaves, then why isn't it an >>improvement? >> >>Best regards, >>Torsten Andersen. >> >>Peter Blaha wrote: >> >>>==== >>>Peter Blaha >>>submitted the following contribution: >>>==== >>> >>>>I have calculated the total energies of Palladium-bulk in an fcc-lattice >>>>with one atom in the unit cell, 72 irred. k-points [12x12x12] and a >>>>cutoff energy of 24 Ry for the wavefunction. If I now increase the >>>>value of Gmax in *.in2, which determines the cutoff energy for the >>>>potential, the total energy goes up an seems to converge to some value >>>>(as you can see in the attachment). Now my question is: If I increase >>>>the cutoff energy for the potential, which means that I'm improving my >>>>basis set, should the total energy of my system according to the >>>>variational principle not acutally decrease and converge to a certain >>>>value instead of increase? >>>> >>>Increasing GMAX does NOT mean improving the basis set !!! >>>You have only a better description of the coulomb and XC-potential. >>>Thus the variational principle does not apply. >>> >>> 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@theochem.tuwien.ac.at WWW: >>> >http://info.tuwien.ac.at/theochem/ > >>-------------------------------------------------------------------------- >> >>>==== >>>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>>To (un)subscribe send mail to >>>majordomo@zeus.theochem.tuwien.ac.at >>>==== >>> >>> >>-- >>Dr. Torsten Andersen >>Department of Physics, Condensed Matter Theory Group, Uppsala University >>UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace >>News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics >> >> >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 13:20:33 +0000 From: "Yue Hai" Subject: [none] ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k_2 users: I want to use wien2k_02 to calculate an antimagnetism double perovskite system. I have followed the following methods, but encounter some problems: 1: init_lapw and afminput ,then run runafm_lapw -orbc -cc 0.0001, this can work and achieve the AFM result. but I found when I change the U value in case.inorb, the results are same expect the Fermi level. Because the - -orb is not supported in runafm_lapw , so I want to know , in -orbc , how does the U and J affect the calculation or not affecting our calculation? 2:init_lapw(befor lstar , I have flip the spin of AFM atoms and set zero of another atoms), then run runfsm_lapw -m 0 -orbc -cc 0.0001, but I found the tendency of SCF is to make every atom to become no magnetism----paramagnetism.and In the 6th cycle, errors apperared and SCF stoped, error in uplapw1.error like these: select--no energy limits found for L=1 select--E-bottom -1.74500 E-top -200.0000 3.init_lapw(befor lstar , I have flip the spin of AFM atoms and set zero of another atoms), then run runsp_lapw -orb -cc 0.0001, but I cann't achieve an AFM results I have known that the double antimagnetism system has been successfullly calculated by other problem, so I want to know if it also can be calculated by wien2k_02, and If can , what's the righe way to do it ? I hope Prof Peter or some other experts can give me some advise on this problem. Yours Hai _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 12:21:37 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: Electron density map using w2web ==== Bing Zhou submitted the following contribution: ==== Dear All: I sent my questions about mapping the elctron density for my minerals, I am still puzzled now, I list the questions again as fellowing, any instruction, suggestion and comment is highly appreciated! 1. For my crystal (tetragonal symmetry), no case.in2 file was created after the SCF cycles, but I get the following files: tugtupite.in2_ls tugtupite.in2_st tugtupite.in2_sy tugtupite.in2c 2. After I run "x lapw2", it crashed with the following error message: ****** FORTRAN RUN-TIME SYSTEM ****** End-of-file: -1 Location: the READ statement at line 56 of "fermi.f" Unit: 30 File: tugtupite.energy Abort 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 20:30:04 +0200 From: Cesar Lazo Subject: Re: [WIEN]: Conversion from eV --> Tesla ==== Cesar Lazo submitted the following contribution: ==== Maybe this can help you: http://www.chemie.fu-berlin.de/chemistry/general/units_en.html Regards, Cesar Lazo Vidya Ravindran wrote: >==== >Vidya Ravindran >submitted the following contribution: >==== > > >Dear All, > I am trying to convert energy given in eV to the magnetic >field intensity given in Tesla. I am unable to find a direct conversion >factor for eV to Tesla > I am highly thankful if somebody could suggest the conversion >factors or some references where I can find them. > Thank you. > >Yours sincerely, >R. Vidya > >**************************************************************** >R. Vidya, Department of Chemistry |Tel: +47 228 55606 >University of Oslo, PO Box 1033 |Fax: +47 228 55441/5565 >Blindern, N-0315 OSLO, NORWAY | >Email: ravindran.vidya@kjemi.uio.no | >URL: http://folk.uio.no/~ravindrv | >**************************************************************** > > > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 23:22:18 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Electron density map using w2web ==== "Saeid Jalali" submitted the following contribution: ==== > After I run "x lapw2", it crashed with the following error message: You would try "x lapw2 -c". Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 23:53:37 +0430 From: "Saeid Jalali" Subject: [WIEN]: Re: ==== "Saeid Jalali" submitted the following contribution: ==== > 2:init_lapw(befor lstar , I have flip the spin of AFM atoms and set zero > of another atoms), then run runfsm_lapw -m 0 -orbc -cc 0.0001, but I found > the tendency of SCF is to make every atom to become no > magnetism----paramagnetism.and In the 6th cycle, errors apperared and SCF > stoped, error in uplapw1.error like these: > select--no energy limits found for L=1 > select--E-bottom -1.74500 E-top -200.0000 I am not sure if you are treating with your system in a right physical way or not, but I guess the 6th cycle is too soon to make a decision. You would add "-in1new 5" switch to control linearization, and rerun it in a clean directory to maybe get ride of that error to see what happen after 6th cycle. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 15:08:04 -0500 (CDT) From: Bing Zhou Subject: Re: [WIEN]: Electron density map using w2web ==== Bing Zhou submitted the following contribution: ==== Dear Dr.Jalali: Thanks! I used "x lapw2 -c", it crashed again and the error message is the same as that from "x lapw2". Any more suggestion? Best wishes! On Thu, 19 Sep 2002, Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > After I run "x lapw2", it crashed with the following error message: > You would try "x lapw2 -c". > Your, > S. Jalali. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Sep 2002 17:38:52 -0500 (CDT) From: zheng@cz.chem.niu.edu (Chong Zheng) Subject: [WIEN]: tomach flue and i probably want be in class today. so if you can please email m ==== zheng@cz.chem.niu.edu (Chong Zheng) submitted the following contribution: ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 09:28:18 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Electron density map using w2web ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0054_01C26088.0E326E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I used "x lapw2 -c", it crashed again and the error message is the = same as > that from "x lapw2". Just to check if "x lapw -c" works or not, one would quickly rerun (only = 1 iteration) the calculation in a clean directory and then give the = command a retry. If one sees that it works now, one may first save the = calculation with the name of for instance "old" (save_lapw old), then = does "rm case.recprlist" and "x dstart (up and dn)". Now one is ready to = rerun "x lapw2 -c". But if one sees that it does not work again (!!!), I = suggest to take a look at :log file to see the history of the performed = command during scf. Your, S. Jalali. - ------=_NextPart_000_0054_01C26088.0E326E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> I used "x lapw2 -c", it crashed = again and the=20 error message is the same as
> that from "x lapw2".
Just to = check if "x=20 lapw -c" works or not, one would quickly rerun (only 1 iteration) = the=20 calculation in a clean directory and then give the command a = retry. If one=20 sees that it works now, one may first save the calculation = with the=20 name of for instance "old" (save_lapw old),  then does "rm = case.recprlist" and "x dstart (up and dn)".=20 Now one is ready to rerun "x lapw2 -c". But if one sees that = it does=20 not work again (!!!), I suggest to take a look at :log file to see = the=20 history of the performed command during scf.
Your,
S. Jalali.
- ------=_NextPart_000_0054_01C26088.0E326E40-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 08:43:55 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Electron density map using w2web ==== Peter Blaha submitted the following contribution: ==== > I sent my questions about mapping the elctron density for my minerals, I > am still puzzled now, I list the questions again as fellowing, any > instruction, suggestion and comment is highly appreciated! > > 1. For my crystal (tetragonal symmetry), no case.in2 file was created > after the SCF cycles, but I get the following files: > > tugtupite.in2_ls tugtupite.in2_st tugtupite.in2_sy > tugtupite.in2c > > 2. After I run "x lapw2", it crashed with the following error message: > > ****** FORTRAN RUN-TIME SYSTEM ****** > End-of-file: -1 > Location: the READ statement at line 56 of "fermi.f" > Unit: 30 > File: tugtupite.energy Let's try a little teaching in solving problems: 1) It is nice that you checked which in2 files you have. Aparently your mineral does not have inversion and thus case.in2c !!! was created. Thus many commands need the "-c" switch. (Use x program -h to find out if "program" needs it or not). Since you provided us with the information about in2 files, there was already a proper hint in the mailing list. 2) Now lets do the same for problem 2). It complained about the file tugtupite.energy. Do ls -als *energ* What do you see ? I hope you have done an scf run before ? I see two choices: a) you find files *energy_1,... ===> you have done it in parallel, use x lapw2 -c -p b) you find files *energyup, dn (or up_1,.) ===> guess what is the problem Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 07:08:37 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Electron density map using w2web ==== "Yue Hai" submitted the following contribution: ==== Dear Saeid: According to your advice , I have use the -in1new 5 in my AFM LDA+U calculation(this has been from an clear directory), there are no 'select' error, but in the 10th cycle, the SCF stopped because of other error. The following is the screen print message: LAPW0 END LAPW1 END PGFIO-F_231/formatted read/unit=1005/error on date conversion File name=/case.helpup035 formatted sequential access record=5 In source file 01up.f, at line number 181 it looks like that the -in1new just remove my select problem ,and the tendency is also to paramagnetism ,not AFM. may be I should change my value of U or J. In some value of U or J, I can achieve my AFM results. Do you think it is possible? Yours Hai "Saeid Jalali" submitted the following contribution: ==== > 2:init_lapw(befor lstar , I have flip the spin of AFM atoms and set zero > of another atoms), then run runfsm_lapw -m 0 -orbc -cc 0.0001, but I found > the tendency of SCF is to make every atom to become no > magnetism----paramagnetism.and In the 6th cycle, errors apperared and SCF > stoped, error in uplapw1.error like these: > select--no energy limits found for L=1 > select--E-bottom -1.74500 E-top -200.0000 I am not sure if you are treating with your system in a right physical way or not, but I guess the 6th cycle is too soon to make a decision. You would add "-in1new 5" switch to control linearization, and rerun it in a clean directory to maybe get ride of that error to see what happen after 6th cycle. Your, S. Jalali. _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£http://www.hotmail.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 09:42:01 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: [WIEN] ==== Peter Blaha submitted the following contribution: ==== > I am now using WIEN97 with graphic interface (WIEN In A Box). And the > system I am interested in as below: > > Number of inequivalent atoms : 19 > Number of atoms per unit cell : 152 > Number of electrons in unit cell : 608 > > Then, I would like to consult about the setting of the following > parameters in siteconfig : > > KMAX1 > KMAX2 must be tested, depens on lattice parameters,if too small, program > KMAX3 stops and will tell you > NATO 19 > NDIF 152 > NKPT > NMAT 7000 - 15000 > NMATIT 1 or if memory permits 7000 - 15000 > NUME 800 > NUMEIT 1 or 800 > NWAV probably quite large, must be tested, if too small, program stops and will tell you Remember: A system with 150 atoms requires a large number of plane wave!!! NMAT must be very large (see above) and you need a computer with huge memory. Depending on inversion/or no-inversion and on the nn-distances (determines RMT) you may / may not be able to perform such calculations. I hope you have some experience with smaller systems! PS: WIEN2k has a more efficient basis and NMAT 4000-10000 is probably sufficient Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 13:22:15 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Electron density map using w2web ==== "Saeid Jalali" submitted the following contribution: ==== > I have use the -in1new 5 in my AFM LDA+U > calculation(this has been from an clear directory), there are no 'select' > error, but in the 10th cycle, the SCF stopped because of other error. The > following is the screen print message: > LAPW0 END > LAPW1 END > PGFIO-F_231/formatted read/unit=1005/error on date conversion > File name=/case.helpup035 formatted sequential access record=5 > In source file 01up.f, at line number 181 > > it looks like that the -in1new just remove my select problem ,and the > tendency is also to paramagnetism ,not AFM. may be I should change my > value of U or J. In some value of U or J, I can achieve my AFM results. Do > you think it is possible? You would reduce the 5 to 3. But I think we need wait to see if we can get a chance to receive a reply from Peter. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 13:00:03 +0100 (BST) From: Vincent Jennings Subject: Re: [WIEN]: Units. ==== Vincent Jennings submitted the following contribution: ==== I posted this question a few days ago, and I know that it's fairly trivial, but I would like confirmation that I have the right units as it is one of the last things that I need to finish off my thesis. So far I havn't found anything that states the units explicitly. As far as I can tell from the comments in lapw2 files Gmax is in 1/a.u. Thanks for any comments, Vin. > Hi, > This should be an easy question... > I want to check the units for RKmax and Gmax. I figure RKmax should be > dimensionless, and Gmax should have dimension of 1/length. - ------------------------------------------------------------------------------- Vincent Jennings "Some days you're the pigeon email: V.L.Jennings@warwick.ac.uk and some days you're the statue." - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 18:59:19 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Units. ==== "Saeid Jalali" submitted the following contribution: ==== > I posted this question a few days ago, and I know that it's fairly > trivial, but I would like confirmation that I have the right units as it > is one of the last things that I need to finish off my thesis. So far I > havn't found anything that states the units explicitly. > > As far as I can tell from the comments in lapw2 files Gmax is in 1/a.u. > > Hi, > > This should be an easy question... > > I want to check the units for RKmax and Gmax. I figure RKmax should be > > dimensionless, and Gmax should have dimension of 1/length. I don't think that looking for the units of physical quantities is trivial. Many refuse to answer such questions and like to pretend they are trivial as they come from and return to fundamental physics. Yes you are right: the unit of Kmax or Gmax is 1/length, and so R*Kmax is dimensionless. Your question returns to star space, where we have exp(r.K) with the cutoff of Kmax as basis for expanding wavefunctions and exp(r.G) with the cutoff of Gmax as basis for expanding charge density and potential energy. So, Kmax and Gmax should be dimensionless. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 10:41:47 -0500 (CDT) From: Bing Zhou Subject: Re: [WIEN]: Electron density map using w2web ==== Bing Zhou submitted the following contribution: ==== Dear Peter and Saeid: Thank you for your great help! First I would let you know what I am doing now: I finished the SCF cycles with paralellization mode (40 days!), then I tried to map Electron Density with w2web without success due to the empty case.vector file. Now I am running mini_lapw for my sample in single mode because I want to obtain the non-empty case.vector file. At the same time, I try to manipulate the Electron Density mapping with w2web so that I can become familar with the procedures. I run "ls -als *energ*" as Peter suggested, my computer showed the following message: 224 -rw------- 1 umbingz student 106496 Sep 20 09:05 tugtupite.energy 272 -rw------- 1 umbingz student 122982 Aug 12 11:24 tugtupite.energy_1 272 -rw------- 1 umbingz student 123009 Aug 12 10:55 tugtupite.energy_2 272 -rw------- 1 umbingz student 123123 Aug 12 12:05 tugtupite.energy_3 272 -rw------- 1 umbingz student 123053 Aug 12 09:53 tugtupite.energy_4 12 -rw------- 1 umbingz student 5260 Aug 10 04:25 tugtupite.energy_5 12 -rw------- 1 umbingz student 5281 Aug 10 04:37 tugtupite.energy_6 12 -rw------- 1 umbingz student 5253 Aug 10 05:22 tugtupite.energy_7 0 -rw------- 1 umbingz student 0 Jun 22 02:42 tugtupite.energydn 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_1 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_2 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_3 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_4 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_5 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_6 0 -rw------- 1 umbingz student 0 Jun 22 02:43 tugtupite.energydn_7 Then I tried the command "x lapw2 -c -p", it seems to work according to the following message on my screen: running LAPW2 in parallel mode STOP: LAPW2 - FERMI; weighs written [1] 1531 [2] 1535 [3] 1539 [4] 1543 Now I already stoped the excution of "x lapw2 -c -p". Last question: the w2web requirs case.in2, how can I get one in my case (only case.in2c available)? On Fri, 20 Sep 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I sent my questions about mapping the elctron density for my minerals, I > > am still puzzled now, I list the questions again as fellowing, any > > instruction, suggestion and comment is highly appreciated! > > > > 1. For my crystal (tetragonal symmetry), no case.in2 file was created > > after the SCF cycles, but I get the following files: > > > > tugtupite.in2_ls tugtupite.in2_st tugtupite.in2_sy > > tugtupite.in2c > > > > 2. After I run "x lapw2", it crashed with the following error message: > > > > ****** FORTRAN RUN-TIME SYSTEM ****** > > End-of-file: -1 > > Location: the READ statement at line 56 of "fermi.f" > > Unit: 30 > > File: tugtupite.energy > > Let's try a little teaching in solving problems: > > 1) It is nice that you checked which in2 files you have. Aparently your > mineral does not have inversion and thus case.in2c !!! was created. Thus > many commands need the "-c" switch. (Use x program -h to find out > if "program" needs it or not). > Since you provided us with the information about in2 files, there was > already a proper hint in the mailing list. > > 2) Now lets do the same for problem 2). It complained about the file > tugtupite.energy. Do ls -als *energ* > What do you see ? > I hope you have done an scf run before ? > I see two choices: a) you find files *energy_1,... ===> you have done it > in parallel, use x lapw2 -c -p > b) you find files *energyup, dn (or up_1,.) ===> guess what is the problem > > Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 18:37:56 +0200 From: "koitzsch" Subject: [WIEN]: dummy atom ==== "koitzsch" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0009_01C260D4.D668A270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everybody, I would like to include "dummy-atoms" with zero charge into a structure = as some sort of placeholder. This would simplify the analysis since I am = interested in the partial DOS at an interstitial site, which is not = occupied by an atom. Does anybody know how to do that? I think the = general question is, if one can introduce a muffin tin sphere, which is = not centered around an atom? Thanks a lot and have a nice weekend Christian Koitzsch ++++++++++++++++++++++++++++++++++++++++++++ University of Fribourg Dep. of Physics Solid State Physics CH-1700 Fribourg Switzerland - ------=_NextPart_000_0009_01C260D4.D668A270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Everybody,
 
I would like to include "dummy-atoms" = with zero=20 charge into a structure as some sort of placeholder. This would simplify = the=20 analysis since I am interested in the partial DOS at an interstitial = site, which=20 is not occupied by an atom. Does anybody know how to do that? I think = the=20 general question is, if one can introduce a muffin tin sphere, which is = not=20 centered around an atom?
 
Thanks a lot and have a nice = weekend
 
Christian Koitzsch
 
++++++++++++++++++++++++++++++++++++++++++++
University of Fribourg
Dep. of Physics
Solid State Physics
CH-1700 Fribourg
Switzerland
- ------=_NextPart_000_0009_01C260D4.D668A270-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Sep 2002 21:38:01 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Electron density map using w2web ==== "Saeid Jalali" submitted the following contribution: ==== > Last question: the w2web requirs case.in2, how can I get one in my case > (only case.in2c available)? Change session information to include complex calculation (no inversion) to active -c in the w2web too. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Sep 2002 16:32:44 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, Actually, I would like to build up a unit-cell with 32 atoms and my input file is as below: - ---------- cnt8010A P LATTICE,NONEQUIV. ATOMS: 3 MODE OF CALC=RELA 18.897269 18.897269 8.055906 90.000000 90.000000 90.000000 Atom= -1: X=0.81337534 Y=0.50000000 Z=0.08333334 MULT= 8 ISPLIT= 8 Atom= -1: X=0.50000000 Y=0.81337534 Z=0.08333334 Atom= -1: X=0.18662466 Y=0.50000000 Z=0.08333334 Atom= -1: X=0.50000000 Y=0.18662466 Z=0.08333334 Atom= -1: X=0.81337534 Y=0.50000000 Z=0.41666667 Atom= -1: X=0.50000000 Y=0.81337534 Z=0.41666667 Atom= -1: X=0.18662466 Y=0.50000000 Z=0.41666667 Atom= -1: X=0.50000000 Y=0.18662466 Z=0.41666667 C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -2: X=0.72158983 Y=0.72158983 Z=0.08333334 MULT= 8 ISPLIT= 8 Atom= -2: X=0.27841017 Y=0.72158983 Z=0.08333334 Atom= -2: X=0.27841017 Y=0.27841017 Z=0.08333334 Atom= -2: X=0.72158983 Y=0.27841017 Z=0.08333334 Atom= -2: X=0.72158983 Y=0.72158983 Z=0.41666667 Atom= -2: X=0.27841017 Y=0.72158983 Z=0.41666667 Atom= -2: X=0.27841017 Y=0.27841017 Z=0.41666667 Atom= -2: X=0.72158983 Y=0.27841017 Z=0.41666667 C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -3: X=0.78952107 Y=0.61992355 Z=0.58333334 MULT=16 ISPLIT= 8 Atom= -3: X=0.61992355 Y=0.78952107 Z=0.58333334 Atom= -3: X=0.38007645 Y=0.78952107 Z=0.58333334 Atom= -3: X=0.21047893 Y=0.61992355 Z=0.58333334 Atom= -3: X=0.21047893 Y=0.38007645 Z=0.58333334 Atom= -3: X=0.38007645 Y=0.21047893 Z=0.58333334 Atom= -3: X=0.61992355 Y=0.21047893 Z=0.58333334 Atom= -3: X=0.78952107 Y=0.38007645 Z=0.58333334 Atom= -3: X=0.78952107 Y=0.61992355 Z=0.91666667 Atom= -3: X=0.61992355 Y=0.78952107 Z=0.91666667 Atom= -3: X=0.38007645 Y=0.78952107 Z=0.91666667 Atom= -3: X=0.21047893 Y=0.61992355 Z=0.91666667 Atom= -3: X=0.21047893 Y=0.38007645 Z=0.91666667 Atom= -3: X=0.38007645 Y=0.21047893 Z=0.91666667 Atom= -3: X=0.61992355 Y=0.21047893 Z=0.91666667 Atom= -3: X=0.78952107 Y=0.38007645 Z=0.91666667 C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 SYMMETRY OPERATIONS: - ---------- And then I initalize the calulation and inputed the following parameter: nn : 2 lstart : 5 (LSDA), -6.0 (ENERGY to separate core and valence states) Then, I continue calculate the symmetry. In the output file (.outputs), a few sentences appear as below: - ---------- PGBSYM: NON-SYMMORPHIC SPACE GROUP OR NON-STANDARD ORIGIN OF COORDINATES PGBSYM: SPACE GROUP CONTAINS INVERSION BUT ATOMS SHOULD BE SHIFTED BY 0.00000000 0.00000000 0.25000000 - ---------- Firstly, I ignore the sentence above and continue the calculation but the calculation stopped very soon and ask me to shift the coordinates. Then, I convert the coordinates above back to bohr unit and shifted by 0.25 bohr and then convert the shifted coordinates back to lattice format. However, it doesn't work at all and similar sentences appear in file (.outputs) again to ask me to shift the coordinates by about 0.21. Finally, I try to shift the coordinates in lattice format by 0.25 and calculate it again. Then, a few sentences appear as below: - ---------- PGBSYM: SPACE GROUP IS SYMMORPHIC PGBSYM: SPACE GROUP CONTAINS INVERSION - ---------- Then, I continue the calculation but it also stopped in step "dstart". My questions are: How can I fix the above problem? How does "WIEN In A Box" (wien97 with graphic interface) decide whether my coordinates need to be shifted or not? What are the criteria? Is it possible to have atoms placed outside the unit cell? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Sep 2002 01:42:24 -0700 (PDT) From: romdhani hedi Subject: Re: [WIEN]: dummy atom ==== romdhani hedi submitted the following contribution: ==== - --- koitzsch wrote: > Hi Everybody, > > I would like to include "dummy-atoms" with zero > charge into a structure as some sort of placeholder. > This would simplify the analysis since I am > interested in the partial DOS at an interstitial > site, which is not occupied by an atom. Does anybody > know how to do that? I think the general question > is, if one can introduce a muffin tin sphere, which > is not centered around an atom? > > Thanks a lot and have a nice weekend Salut you can introduce empty spheres ( Z=0 ) in different positions according to your space group ( like LMTO method ) and run calculations. best regards > > Christian Koitzsch > > ++++++++++++++++++++++++++++++++++++++++++++ > University of Fribourg > Dep. of Physics > Solid State Physics > CH-1700 Fribourg > Switzerland > __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Sep 2002 14:32:44 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: dummy atom ==== "Saeid Jalali" submitted the following contribution: ==== >>I think the general question > > is, if one can introduce a muffin tin sphere, which > > is not centered around an atom? > you can introduce empty spheres ( Z=0 ) in different > positions according to your space group ( like LMTO > method ) and run calculations. What are your interpretation of in1 and in2 files in the case of including an atom with Z=0?! Would you send us one iteration of your run? Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Sep 2002 16:48:29 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0007_01C2618E.B6DD1E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Actually, I would like to build up a unit-cell with 32 atoms and my input > file is as below: > ---------- > cnt8010A > P LATTICE,NONEQUIV. ATOMS: 3 > MODE OF CALC=RELA > 18.897269 18.897269 8.055906 90.000000 90.000000 90.000000 > Atom= -1: X=0.81337534 Y=0.50000000 Z=0.08333334 > MULT= 8 ISPLIT= 8 > Atom= -1: X=0.50000000 Y=0.81337534 Z=0.08333334 > Atom= -1: X=0.18662466 Y=0.50000000 Z=0.08333334 > Atom= -1: X=0.50000000 Y=0.18662466 Z=0.08333334 > Atom= -1: X=0.81337534 Y=0.50000000 Z=0.41666667 > Atom= -1: X=0.50000000 Y=0.81337534 Z=0.41666667 > Atom= -1: X=0.18662466 Y=0.50000000 Z=0.41666667 > Atom= -1: X=0.50000000 Y=0.18662466 Z=0.41666667 > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -2: X=0.72158983 Y=0.72158983 Z=0.08333334 > MULT= 8 ISPLIT= 8 > Atom= -2: X=0.27841017 Y=0.72158983 Z=0.08333334 > Atom= -2: X=0.27841017 Y=0.27841017 Z=0.08333334 > Atom= -2: X=0.72158983 Y=0.27841017 Z=0.08333334 > Atom= -2: X=0.72158983 Y=0.72158983 Z=0.41666667 > Atom= -2: X=0.27841017 Y=0.72158983 Z=0.41666667 > Atom= -2: X=0.27841017 Y=0.27841017 Z=0.41666667 > Atom= -2: X=0.72158983 Y=0.27841017 Z=0.41666667 > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -3: X=0.78952107 Y=0.61992355 Z=0.58333334 > MULT=16 ISPLIT= 8 > Atom= -3: X=0.61992355 Y=0.78952107 Z=0.58333334 > Atom= -3: X=0.38007645 Y=0.78952107 Z=0.58333334 > Atom= -3: X=0.21047893 Y=0.61992355 Z=0.58333334 > Atom= -3: X=0.21047893 Y=0.38007645 Z=0.58333334 > Atom= -3: X=0.38007645 Y=0.21047893 Z=0.58333334 > Atom= -3: X=0.61992355 Y=0.21047893 Z=0.58333334 > Atom= -3: X=0.78952107 Y=0.38007645 Z=0.58333334 > Atom= -3: X=0.78952107 Y=0.61992355 Z=0.91666667 > Atom= -3: X=0.61992355 Y=0.78952107 Z=0.91666667 > Atom= -3: X=0.38007645 Y=0.78952107 Z=0.91666667 > Atom= -3: X=0.21047893 Y=0.61992355 Z=0.91666667 > Atom= -3: X=0.21047893 Y=0.38007645 Z=0.91666667 > Atom= -3: X=0.38007645 Y=0.21047893 Z=0.91666667 > Atom= -3: X=0.61992355 Y=0.21047893 Z=0.91666667 > Atom= -3: X=0.78952107 Y=0.38007645 Z=0.91666667 > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 0 SYMMETRY OPERATIONS: > ---------- > > And then I initalize the calulation and inputed the following parameter: > > nn : 2 > lstart : 5 (LSDA), -6.0 (ENERGY to separate core and valence states) > > Then, I continue calculate the symmetry. In the output file (.outputs), > a few sentences appear as below: > ---------- > PGBSYM: NON-SYMMORPHIC SPACE GROUP OR NON-STANDARD ORIGIN OF COORDINATES > PGBSYM: SPACE GROUP CONTAINS INVERSION > BUT ATOMS SHOULD BE SHIFTED BY 0.00000000 0.00000000 > 0.25000000 > ---------- > > Firstly, I ignore the sentence above and continue the calculation but the > calculation stopped very soon and ask me to shift the coordinates. > > Then, I convert the coordinates above back to bohr unit and shifted by > 0.25 bohr and then convert the shifted coordinates back to lattice format. > However, it doesn't work at all and similar sentences appear in file > (.outputs) again to ask me to shift the coordinates by about 0.21. > > Finally, I try to shift the coordinates in lattice format by 0.25 and > calculate it again. Then, a few sentences appear as below: > ---------- > PGBSYM: SPACE GROUP IS SYMMORPHIC > PGBSYM: SPACE GROUP CONTAINS INVERSION > ---------- > Then, I continue the calculation but it also stopped in step "dstart". > > > My questions are: > > How can I fix the above problem? To fix it you would download the attachment which containes proper .struct and .inst files of your case. Your, S. Jalali. - ------=_NextPart_000_0007_01C2618E.B6DD1E30 Content-Type: application/x-tar; name="C.tar" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="C.tar" Yy5pbnN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDc2 NgAwMDAwNzY3ADAwMDAwMDAwNDQxADA3NTQzMTUxMzI0ADAxMTYyMAAgMAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHNqYWxhbGkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd2llbjJrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABD CkhlIDMgNQoyLC0xLDEuMCAgTgoyLC0xLDEuMCAgTgoyLCAxLDEuMCAgTgoyLCAxLDAuMCAgTgoy LC0yLDEuMCAgTgoyLC0yLDAuMCAgTgpDCkhlIDMgNQoyLC0xLDEuMCAgTgoyLC0xLDEuMCAgTgoy LCAxLDEuMCAgTgoyLCAxLDAuMCAgTgoyLC0yLDEuMCAgTgoyLC0yLDAuMCAgTgpDCkhlIDMgNQoy LC0xLDEuMCAgTgoyLC0xLDEuMCAgTgoyLCAxLDEuMCAgTgoyLCAxLDAuMCAgTgoyLC0yLDEuMCAg TgoyLC0yLDAuMCAgTgoqKioqCioqKiogICAgICAgICBFTkQgb2YgaW5wdXQgKGluc3RnZW5fbGFw dykKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMu c3RydWN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNzU1ADAwMDA3NjYA MDAwMDc2NwAwMDAwMDAwNzE2MgAwNzU0MzE1MTMyNAAwMTIyMDEAIDAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIgIABzamFsYWxpAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHdpZW4yawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY250 ODAxMEEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIApQICAgTEFUVElDRSxOT05FUVVJVi4gQVRPTVM6IDMgMTIzIFA0 L21tbSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCk1PREUgT0YgQ0FMQz1S RUxBIHVuaXQ9Ym9ociAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKIDE4Ljg5NzI2OSAxOC44OTcyNjkgIDguMDU1OTA2IDkwLjAwMDAwMCA5MC4wMDAw MDAgOTAuMDAwMDAwICAgICAgICAgICAgICAgICAgIApBVE9NPSAtMTogWD0wLjgxMzM3NTM0IFk9 MC41MDAwMDAwMCBaPTAuODMzMzMzMzQKICAgICAgICAgIE1VTFQ9IDggICAgICAgICAgSVNQTElU PSA4CiAgICAgIC0xOiBYPTAuMTg2NjI0NjYgWT0wLjUwMDAwMDAwIFo9MC44MzMzMzMzNAogICAg ICAtMTogWD0wLjUwMDAwMDAwIFk9MC44MTMzNzUzNCBaPTAuODMzMzMzMzQKICAgICAgLTE6IFg9 MC41MDAwMDAwMCBZPTAuMTg2NjI0NjYgWj0wLjgzMzMzMzM0CiAgICAgIC0xOiBYPTAuMTg2NjI0 NjYgWT0wLjUwMDAwMDAwIFo9MC4xNjY2NjY2NgogICAgICAtMTogWD0wLjgxMzM3NTM0IFk9MC41 MDAwMDAwMCBaPTAuMTY2NjY2NjYKICAgICAgLTE6IFg9MC41MDAwMDAwMCBZPTAuODEzMzc1MzQg Wj0wLjE2NjY2NjY2CiAgICAgIC0xOiBYPTAuNTAwMDAwMDAgWT0wLjE4NjYyNDY2IFo9MC4xNjY2 NjY2NgpDIDEgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAg IFo6ICA2LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwCkFUT009IC0yOiBYPTAuNzIxNTg5ODMgWT0wLjcyMTU4OTgzIFo9MC44MzMzMzMz NAogICAgICAgICAgTVVMVD0gOCAgICAgICAgICBJU1BMSVQ9IDgKICAgICAgLTI6IFg9MC4yNzg0 MTAxNyBZPTAuMjc4NDEwMTcgWj0wLjgzMzMzMzM0CiAgICAgIC0yOiBYPTAuMjc4NDEwMTcgWT0w LjcyMTU4OTgzIFo9MC44MzMzMzMzNAogICAgICAtMjogWD0wLjcyMTU4OTgzIFk9MC4yNzg0MTAx NyBaPTAuODMzMzMzMzQKICAgICAgLTI6IFg9MC4yNzg0MTAxNyBZPTAuNzIxNTg5ODMgWj0wLjE2 NjY2NjY2CiAgICAgIC0yOiBYPTAuNzIxNTg5ODMgWT0wLjI3ODQxMDE3IFo9MC4xNjY2NjY2Ngog ICAgICAtMjogWD0wLjcyMTU4OTgzIFk9MC43MjE1ODk4MyBaPTAuMTY2NjY2NjYKICAgICAgLTI6 IFg9MC4yNzg0MTAxNyBZPTAuMjc4NDEwMTcgWj0wLjE2NjY2NjY2CkMgMiAgICAgICAgTlBUPSAg NzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMCAgICAgICAgICAgICAg ICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMC4wMDAwMDAwLTAuNzA3MTA2OC0wLjcwNzEwNjgK ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwLTAuNzA3MTA2OCAwLjcwNzEwNjgKICAgICAg ICAgICAgICAgICAgICAtMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKQVRPTT0gLTM6IFg9 MC43ODk1MjEwNyBZPTAuNjE5OTIzNTUgWj0wLjMzMzMzMzM0CiAgICAgICAgICBNVUxUPTE2ICAg ICAgICAgIElTUExJVD0gOAogICAgICAtMzogWD0wLjIxMDQ3ODkzIFk9MC4zODAwNzY0NSBaPTAu MzMzMzMzMzQKICAgICAgLTM6IFg9MC4zODAwNzY0NSBZPTAuNzg5NTIxMDcgWj0wLjMzMzMzMzM0 CiAgICAgIC0zOiBYPTAuNjE5OTIzNTUgWT0wLjIxMDQ3ODkzIFo9MC4zMzMzMzMzNAogICAgICAt MzogWD0wLjIxMDQ3ODkzIFk9MC42MTk5MjM1NSBaPTAuNjY2NjY2NjYKICAgICAgLTM6IFg9MC43 ODk1MjEwNyBZPTAuMzgwMDc2NDUgWj0wLjY2NjY2NjY2CiAgICAgIC0zOiBYPTAuNjE5OTIzNTUg WT0wLjc4OTUyMTA3IFo9MC42NjY2NjY2NgogICAgICAtMzogWD0wLjM4MDA3NjQ1IFk9MC4yMTA0 Nzg5MyBaPTAuNjY2NjY2NjYKICAgICAgLTM6IFg9MC4yMTA0Nzg5MyBZPTAuMzgwMDc2NDUgWj0w LjY2NjY2NjY2CiAgICAgIC0zOiBYPTAuNzg5NTIxMDcgWT0wLjYxOTkyMzU1IFo9MC42NjY2NjY2 NgogICAgICAtMzogWD0wLjYxOTkyMzU1IFk9MC4yMTA0Nzg5MyBaPTAuNjY2NjY2NjYKICAgICAg LTM6IFg9MC4zODAwNzY0NSBZPTAuNzg5NTIxMDcgWj0wLjY2NjY2NjY2CiAgICAgIC0zOiBYPTAu Nzg5NTIxMDcgWT0wLjM4MDA3NjQ1IFo9MC4zMzMzMzMzNAogICAgICAtMzogWD0wLjIxMDQ3ODkz IFk9MC42MTk5MjM1NSBaPTAuMzMzMzMzMzQKICAgICAgLTM6IFg9MC4zODAwNzY0NSBZPTAuMjEw NDc4OTMgWj0wLjMzMzMzMzM0CiAgICAgIC0zOiBYPTAuNjE5OTIzNTUgWT0wLjc4OTUyMTA3IFo9 MC4zMzMzMzMzNApDIDMgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEu MjAwMCAgIFo6ICA2LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEu MDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwCiAgMTYgICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUwog MSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAg MQotMSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAg ICAgMgogMC0xIDAgMC4wMDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAog ICAgICAgMwogMCAxIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAw MAogICAgICAgNAotMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAw MDAwMAogICAgICAgNQogMSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMC0xIDAu MDAwMDAwMAogICAgICAgNgogMCAxIDAgMC4wMDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMC0x IDAuMDAwMDAwMAogICAgICAgNwogMC0xIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAg MC0xIDAuMDAwMDAwMAogICAgICAgOAotMSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAK IDAgMC0xIDAuMDAwMDAwMAogICAgICAgOQogMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAw MDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAxMAogMCAxIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAw MDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAxMQogMC0xIDAgMC4wMDAwMDAwCiAxIDAgMCAw LjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAxMgogMSAwIDAgMC4wMDAwMDAwCiAwLTEg MCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAxMwotMSAwIDAgMC4wMDAwMDAwCiAw IDEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAxNAogMC0xIDAgMC4wMDAwMDAw Ci0xIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAxNQogMCAxIDAgMC4wMDAw MDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAxNgoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== - ------=_NextPart_000_0007_01C2618E.B6DD1E30-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 13:35:12 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --143914132-1161458966-1032672912=:27785 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Saeid Jalali, Thank you for your files. Actually, I have changed the unit cell and it is similar to the one you sent to me. My input file is as below: - ------ new10A P LATTICE,NONEQUIV. ATOMS: 1 MODE OF CALC=RELA 18.897269 18.897269 8.055906 90.000000 90.000000 90.000000 Atom= -1: X=0.81337534 Y=0.50000000 Z=0.33333333 MULT=32 ISPLIT= 8 Atom= -1: X=0.78952107 Y=0.61992355 Z=0.16666667 Atom= -1: X=0.72158983 Y=0.72158983 Z=0.33333333 Atom= -1: X=0.61992355 Y=0.78952107 Z=0.16666667 Atom= -1: X=0.50000000 Y=0.81337534 Z=0.33333333 Atom= -1: X=0.38007645 Y=0.78952107 Z=0.16666667 Atom= -1: X=0.27841017 Y=0.72158983 Z=0.33333333 Atom= -1: X=0.21047893 Y=0.61992355 Z=0.16666667 Atom= -1: X=0.18662466 Y=0.50000000 Z=0.33333333 Atom= -1: X=0.21047893 Y=0.38007645 Z=0.16666667 Atom= -1: X=0.27841017 Y=0.27841017 Z=0.33333333 Atom= -1: X=0.38007645 Y=0.21047893 Z=0.16666667 Atom= -1: X=0.50000000 Y=0.18662466 Z=0.33333333 Atom= -1: X=0.61992355 Y=0.21047893 Z=0.16666667 Atom= -1: X=0.72158983 Y=0.27841017 Z=0.33333333 Atom= -1: X=0.78952107 Y=0.38007645 Z=0.16666667 Atom= -1: X=0.81337534 Y=0.50000000 Z=0.66666667 Atom= -1: X=0.78952107 Y=0.61992355 Z=0.83333333 Atom= -1: X=0.72158983 Y=0.72158983 Z=0.66666667 Atom= -1: X=0.61992355 Y=0.78952107 Z=0.83333333 Atom= -1: X=0.50000000 Y=0.81337534 Z=0.66666667 Atom= -1: X=0.38007645 Y=0.78952107 Z=0.83333333 Atom= -1: X=0.27841017 Y=0.72158983 Z=0.66666667 Atom= -1: X=0.21047893 Y=0.61992355 Z=0.83333333 Atom= -1: X=0.18662466 Y=0.50000000 Z=0.66666667 Atom= -1: X=0.21047893 Y=0.38007645 Z=0.83333333 Atom= -1: X=0.27841017 Y=0.27841017 Z=0.66666667 Atom= -1: X=0.38007645 Y=0.21047893 Z=0.83333333 Atom= -1: X=0.50000000 Y=0.18662466 Z=0.66666667 Atom= -1: X=0.61992355 Y=0.21047893 Z=0.83333333 Atom= -1: X=0.72158983 Y=0.27841017 Z=0.66666667 Atom= -1: X=0.78952107 Y=0.38007645 Z=0.83333333 C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 SYMMETRY OPERATIONS: - ------ Then, I initalize the calulation and inputed the following parameter: nn = 2 Wien97 (WIEN In The Box) finds that it is error for the input file and aks me to use a new one that supplied by WIEN. I certainly accept the new input file from WIEN. The input file generated by WIEN is attached with this mail. My question is as below: 1. The (.struct) file is different from the one produced by WIEN in terms of the classification of the inequivalent atoms. Why? Are they the same? 2. And I found that the bandstructure is plotted automatically by WIEN (in the format of ps file). Which files store the information about the bandstructure? What information do the following files store? Files with extension : (.outputsp),(.spaghetti_ene),(.spaghetti_ps),(.nsh) 3. Actually, I am trying to get the bandstructure and I am interested in the one-directional bandstructure along the c direction and WIEN gives me the 3-directional bandstructure. Which part of the bandstructure should I look into? Thank you very much Martin On Sat, 21 Sep 2002, Saeid Jalali wrote: > > Actually, I would like to build up a unit-cell with 32 atoms and my input > > file is as below: > > ---------- > > cnt8010A > > P LATTICE,NONEQUIV. ATOMS: 3 > > MODE OF CALC=RELA > > 18.897269 18.897269 8.055906 90.000000 90.000000 90.000000 > > Atom= -1: X=0.81337534 Y=0.50000000 Z=0.08333334 > > MULT= 8 ISPLIT= 8 > > Atom= -1: X=0.50000000 Y=0.81337534 Z=0.08333334 > > Atom= -1: X=0.18662466 Y=0.50000000 Z=0.08333334 > > Atom= -1: X=0.50000000 Y=0.18662466 Z=0.08333334 > > Atom= -1: X=0.81337534 Y=0.50000000 Z=0.41666667 > > Atom= -1: X=0.50000000 Y=0.81337534 Z=0.41666667 > > Atom= -1: X=0.18662466 Y=0.50000000 Z=0.41666667 > > Atom= -1: X=0.50000000 Y=0.18662466 Z=0.41666667 > > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -2: X=0.72158983 Y=0.72158983 Z=0.08333334 > > MULT= 8 ISPLIT= 8 > > Atom= -2: X=0.27841017 Y=0.72158983 Z=0.08333334 > > Atom= -2: X=0.27841017 Y=0.27841017 Z=0.08333334 > > Atom= -2: X=0.72158983 Y=0.27841017 Z=0.08333334 > > Atom= -2: X=0.72158983 Y=0.72158983 Z=0.41666667 > > Atom= -2: X=0.27841017 Y=0.72158983 Z=0.41666667 > > Atom= -2: X=0.27841017 Y=0.27841017 Z=0.41666667 > > Atom= -2: X=0.72158983 Y=0.27841017 Z=0.41666667 > > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -3: X=0.78952107 Y=0.61992355 Z=0.58333334 > > MULT=16 ISPLIT= 8 > > Atom= -3: X=0.61992355 Y=0.78952107 Z=0.58333334 > > Atom= -3: X=0.38007645 Y=0.78952107 Z=0.58333334 > > Atom= -3: X=0.21047893 Y=0.61992355 Z=0.58333334 > > Atom= -3: X=0.21047893 Y=0.38007645 Z=0.58333334 > > Atom= -3: X=0.38007645 Y=0.21047893 Z=0.58333334 > > Atom= -3: X=0.61992355 Y=0.21047893 Z=0.58333334 > > Atom= -3: X=0.78952107 Y=0.38007645 Z=0.58333334 > > Atom= -3: X=0.78952107 Y=0.61992355 Z=0.91666667 > > Atom= -3: X=0.61992355 Y=0.78952107 Z=0.91666667 > > Atom= -3: X=0.38007645 Y=0.78952107 Z=0.91666667 > > Atom= -3: X=0.21047893 Y=0.61992355 Z=0.91666667 > > Atom= -3: X=0.21047893 Y=0.38007645 Z=0.91666667 > > Atom= -3: X=0.38007645 Y=0.21047893 Z=0.91666667 > > Atom= -3: X=0.61992355 Y=0.21047893 Z=0.91666667 > > Atom= -3: X=0.78952107 Y=0.38007645 Z=0.91666667 > > C NPT= 781 R0=0.00010000 RMT= 1.2000 Z: 6.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > 0 SYMMETRY OPERATIONS: > > ---------- > > > > And then I initalize the calulation and inputed the following parameter: > > > > nn : 2 > > lstart : 5 (LSDA), -6.0 (ENERGY to separate core and valence states) > > > > Then, I continue calculate the symmetry. In the output file (.outputs), > > a few sentences appear as below: > > ---------- > > PGBSYM: NON-SYMMORPHIC SPACE GROUP OR NON-STANDARD ORIGIN OF COORDINATES > > PGBSYM: SPACE GROUP CONTAINS INVERSION > > BUT ATOMS SHOULD BE SHIFTED BY 0.00000000 0.00000000 > > 0.25000000 > > ---------- > > > > Firstly, I ignore the sentence above and continue the calculation but the > > calculation stopped very soon and ask me to shift the coordinates. > > > > Then, I convert the coordinates above back to bohr unit and shifted by > > 0.25 bohr and then convert the shifted coordinates back to lattice format. > > However, it doesn't work at all and similar sentences appear in file > > (.outputs) again to ask me to shift the coordinates by about 0.21. > > > > Finally, I try to shift the coordinates in lattice format by 0.25 and > > calculate it again. Then, a few sentences appear as below: > > ---------- > > PGBSYM: SPACE GROUP IS SYMMORPHIC > > PGBSYM: SPACE GROUP CONTAINS INVERSION > > ---------- > > Then, I continue the calculation but it also stopped in step "dstart". > > > > > > My questions are: > > > > How can I fix the above problem? > > To fix it you would download the attachment which containes proper .struct > and .inst files of your case. > > Your, > S. Jalali. > - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - --143914132-1161458966-1032672912=:27785 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="10a.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="10a.struct" bmV3MTBBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANClAgICBMQVRUSUNFLE5P TkVRVUlWLiBBVE9NUzogMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCk1PREUgT0YgQ0FMQz1SRUxBICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAxOC44OTcyNjkgMTguODk3MjY5ICA4LjA1NTkwNiA5 MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMCAgICAgICAgICAgICAgICAg ICANCkFUT009IC0xOiBYPTAuODEzMzc1MzQgWT0wLjUwMDAwMDAwIFo9MC4z MzMzMzMzMw0KICAgICAgICAgIE1VTFQ9IDggICAgICAgICAgSVNQTElUPSA4 DQogICAgICAtMTogWD0wLjUwMDAwMDAwIFk9MC44MTMzNzUzNCBaPTAuMzMz MzMzMzMNCiAgICAgIC0xOiBYPTAuMTg2NjI0NjYgWT0wLjUwMDAwMDAwIFo9 MC4zMzMzMzMzMw0KICAgICAgLTE6IFg9MC41MDAwMDAwMCBZPTAuMTg2NjI0 NjYgWj0wLjMzMzMzMzMzDQogICAgICAtMTogWD0wLjgxMzM3NTM0IFk9MC41 MDAwMDAwMCBaPTAuNjY2NjY2NjcNCiAgICAgIC0xOiBYPTAuNTAwMDAwMDAg WT0wLjgxMzM3NTM0IFo9MC42NjY2NjY2Nw0KICAgICAgLTE6IFg9MC4xODY2 MjQ2NiBZPTAuNTAwMDAwMDAgWj0wLjY2NjY2NjY3DQogICAgICAtMTogWD0w LjUwMDAwMDAwIFk9MC4xODY2MjQ2NiBaPTAuNjY2NjY2NjcNCkMgICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDYuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAw MDANCkFUT009IC0yOiBYPTAuNzg5NTIxMDcgWT0wLjYxOTkyMzU1IFo9MC4x NjY2NjY2Nw0KICAgICAgICAgIE1VTFQ9MTYgICAgICAgICAgSVNQTElUPSA4 DQogICAgICAtMjogWD0wLjYxOTkyMzU1IFk9MC43ODk1MjEwNyBaPTAuMTY2 NjY2NjcNCiAgICAgIC0yOiBYPTAuMzgwMDc2NDUgWT0wLjc4OTUyMTA3IFo9 MC4xNjY2NjY2Nw0KICAgICAgLTI6IFg9MC4yMTA0Nzg5MyBZPTAuNjE5OTIz NTUgWj0wLjE2NjY2NjY3DQogICAgICAtMjogWD0wLjIxMDQ3ODkzIFk9MC4z ODAwNzY0NSBaPTAuMTY2NjY2NjcNCiAgICAgIC0yOiBYPTAuMzgwMDc2NDUg WT0wLjIxMDQ3ODkzIFo9MC4xNjY2NjY2Nw0KICAgICAgLTI6IFg9MC42MTk5 MjM1NSBZPTAuMjEwNDc4OTMgWj0wLjE2NjY2NjY3DQogICAgICAtMjogWD0w Ljc4OTUyMTA3IFk9MC4zODAwNzY0NSBaPTAuMTY2NjY2NjcNCiAgICAgIC0y OiBYPTAuNzg5NTIxMDcgWT0wLjYxOTkyMzU1IFo9MC44MzMzMzMzMw0KICAg ICAgLTI6IFg9MC42MTk5MjM1NSBZPTAuNzg5NTIxMDcgWj0wLjgzMzMzMzMz DQogICAgICAtMjogWD0wLjM4MDA3NjQ1IFk9MC43ODk1MjEwNyBaPTAuODMz MzMzMzMNCiAgICAgIC0yOiBYPTAuMjEwNDc4OTMgWT0wLjYxOTkyMzU1IFo9 MC44MzMzMzMzMw0KICAgICAgLTI6IFg9MC4yMTA0Nzg5MyBZPTAuMzgwMDc2 NDUgWj0wLjgzMzMzMzMzDQogICAgICAtMjogWD0wLjM4MDA3NjQ1IFk9MC4y MTA0Nzg5MyBaPTAuODMzMzMzMzMNCiAgICAgIC0yOiBYPTAuNjE5OTIzNTUg WT0wLjIxMDQ3ODkzIFo9MC44MzMzMzMzMw0KICAgICAgLTI6IFg9MC43ODk1 MjEwNyBZPTAuMzgwMDc2NDUgWj0wLjgzMzMzMzMzDQpDICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA2 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtMzogWD0wLjcyMTU4OTgzIFk9MC43MjE1ODk4MyBaPTAuMzMzMzMz MzMNCiAgICAgICAgICBNVUxUPSA4ICAgICAgICAgIElTUExJVD0gOA0KICAg ICAgLTM6IFg9MC4yNzg0MTAxNyBZPTAuNzIxNTg5ODMgWj0wLjMzMzMzMzMz DQogICAgICAtMzogWD0wLjI3ODQxMDE3IFk9MC4yNzg0MTAxNyBaPTAuMzMz MzMzMzMNCiAgICAgIC0zOiBYPTAuNzIxNTg5ODMgWT0wLjI3ODQxMDE3IFo9 MC4zMzMzMzMzMw0KICAgICAgLTM6IFg9MC43MjE1ODk4MyBZPTAuNzIxNTg5 ODMgWj0wLjY2NjY2NjY3DQogICAgICAtMzogWD0wLjI3ODQxMDE3IFk9MC43 MjE1ODk4MyBaPTAuNjY2NjY2NjcNCiAgICAgIC0zOiBYPTAuMjc4NDEwMTcg WT0wLjI3ODQxMDE3IFo9MC42NjY2NjY2Nw0KICAgICAgLTM6IFg9MC43MjE1 ODk4MyBZPTAuMjc4NDEwMTcgWj0wLjY2NjY2NjY3DQpDICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA2 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAw LjAwMDAwMDAtMC43MDcxMDY4LTAuNzA3MTA2OA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwLTAuNzA3MTA2OCAwLjcwNzEwNjgNCiAgICAgICAg ICAgICAgICAgICAgLTEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog IDE2ICAgICAgTlVNQkVSIE9GIFNZTU1FVFJZIE9QRVJBVElPTlMNCi0xIDAg MCAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAw MDANCiAgICAgICAxDQotMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC4wMDAw MDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICAgMg0KLTEgMCAwIDAuMDAw MDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0KICAg ICAgIDMNCi0xIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAw IDAgMSAwLjAwMDAwMDANCiAgICAgICA0DQogMC0xIDAgMC4wMDAwMDAwDQot MSAwIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogICAgICAgNQ0K IDAtMSAwIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAu MDAwMDAwMA0KICAgICAgIDYNCiAwIDEgMCAwLjAwMDAwMDANCi0xIDAgMCAw LjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAgICA3DQogMCAxIDAg MC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAw DQogICAgICAgOA0KIDAtMSAwIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAw MA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAgIDkNCiAwLTEgMCAwLjAwMDAw MDANCiAxIDAgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAg IDEwDQogMCAxIDAgMC4wMDAwMDAwDQogMSAwIDAgMC4wMDAwMDAwDQogMCAw LTEgMC4wMDAwMDAwDQogICAgICAxMQ0KIDAgMSAwIDAuMDAwMDAwMA0KIDEg MCAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgMTINCiAx IDAgMCAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAw MDAwMDANCiAgICAgIDEzDQogMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC4w MDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICAxNA0KIDEgMCAwIDAu MDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0K ICAgICAgMTUNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDAN CiAwIDAgMSAwLjAwMDAwMDANCiAgICAgIDE2DQo= - --143914132-1161458966-1032672912=:27785-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 00:06:55 -0700 (PDT) From: mehrdad dadsetani Subject: [WIEN]: *.inc1 ==== mehrdad dadsetani submitted the following contribution: ==== dear users wien97(2k) i have run scf with so, but *.inc1 is empty. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 14:12:20 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: ==== "Saeid Jalali" submitted the following contribution: ==== Let's assume your struct works now. > 1. The (.struct) file is different from the one produced by WIEN in terms > of the classification of the nonequivalent atoms. Why? Are they the same? One can not constrain to be equivalent those certain 32 carbons. This means that you have 3 distinct carbon classes (8, 8, 16) and not one class with 32 atoms. Nature has constrain and wien nicely follows rules: number of space groups is finite. Therefore we cannot say that they (a system with 3 distinct carbon classes (8, 8, 16) and a system with one class with 32 atoms) are the same, even though if you plot them they look like the same. > 2. And I found that the bandstructure is plotted automatically by WIEN > (in the format of ps file). Which files store the information about the > bandstructure? What information do the following files store? > Files with extension : (.outputsp),(.spaghetti_ene),(.spaghetti_ps),(.nsh) case.spaghetti_ene, which can be used for an XY-plot -- see the description of line 10 of .insp file. > 3. Actually, I am trying to get the bandstructure and I am interested in > the one-directional bandstructure along the c direction and WIEN gives me > the 3-directional bandstructure. Which part of the bandstructure should I > look into? I suggest to use xcrsden program to generate klist along your favorite symmetry direction. Your, S. jalali ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 14:48:06 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: *.inc1 ==== "Saeid Jalali" submitted the following contribution: ==== > i have run scf with so, but *.inc1 is empty. Let's suppose you mean *.in1c and not *.inc1, as there is not such a file in wien. In this case I wonder why one should necessarily look for .in1c file in the presence of only spin-orbit. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 12:23:49 +0200 From: Torsten Andersen Subject: [WIEN]: Symmetso A and B type symmetries - bug? ==== Torsten Andersen submitted the following contribution: ==== This is a multi-part message in MIME format. - --------------060707020507040209030207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all of you, I just downloaded the newest version of Wien2k_02, and I have a little problem with symmetso. It appears to me that it gives wrong sorting of A and B symmetry types. I have attached a structure file for illustration. In it is 4 symmetries: 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 -1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 2 1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 3 -1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 4 Choosing M as 1.0 0.0 0.0 in .inso I would by hand expect symmetries 1 and 4 to be of the A type, since M transforms as M_i=det(s)*s_ij*M_j under a symmetry operation with the 3x3 matrix s. Then why does symmetso tell me that symmetries 1 and 2 are the A type? Best regards, Torsten. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics - --------------060707020507040209030207 Content-Type: text/plain; name="W5Fe110.struct" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="W5Fe110.struct" 5W layers + 1 Fe layer with 10% contraction in the first Fe-W distance CXY LATTICE,NONEQUIV. ATOMS: 6 35 Cmm2 MODE OF CALC=RELA 8.564901 6.056302 101.06580 90.000000 90.000000 90.000000 ATOM= -1: X=0.50000000 Y=0.00000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Fe1 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 26.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.00000000 Y=0.00000000 Z=0.46309345 MULT= 1 ISPLIT= 8 W 1 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 74.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.50000000 Y=0.00000000 Z=0.42077460 MULT= 1 ISPLIT= 8 W 2 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 74.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -4: X=0.00000000 Y=0.00000000 Z=0.37869270 MULT= 1 ISPLIT= 8 W 3 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 74.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -5: X=0.50000000 Y=0.00000000 Z=0.33661080 MULT= 1 ISPLIT= 8 W 4 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 74.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -6: X=0.00000000 Y=0.00000000 Z=0.29452890 MULT= 1 ISPLIT= 8 W 5 NPT= 781 R0=0.00000100 RMT= 2.3500 Z: 74.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 2 1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 3 - -1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 4 - --------------060707020507040209030207 Content-Type: text/plain; name="W5Fe110.inso" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="W5Fe110.inso" WFFIL 4 1 0 llmax,ipr,kpot -10.0000 1.50000 emin,emax (output energy window) 1. 0. 0. direction of magnetization (lattice vectors) 0 number of atoms for which RLO is added NX1 -4.97 0.005 atom number,e-lo,de (case.in1), repeat NX times 0 0 0 0 0 number of atoms for which SO is switch off; atoms - --------------060707020507040209030207 Content-Type: text/plain; name="W5Fe110.outsymso" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="W5Fe110.outsymso" Magnetization is along 1.0000 0.0000 0.0000 direction 5W layers + 1 Fe layer with 10% contraction in the first Fe-W distance ATOMIC POSITIONS: 1 4.28245050 0.00000000 50.53290000 2 0.00000000 0.00000000 46.80291000 3 4.28245050 0.00000000 42.52592157 4 0.00000000 0.00000000 38.27288068 5 4.28245050 0.00000000 34.01983979 6 0.00000000 0.00000000 29.76679890 PGLSYM: THE CRYSTAL SYSTEM IS ORTHORHOMBIC PGLSYM: ORDER OF LATTICE POINT GROUP (NO BASE) = 8 PGBSYM: ORDER OF LATTICE SPACE GROUP (WITH BASE) = 4 PGBSYM: SPACE GROUP IS SYMMORPHIC PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION Symmetry operation 1 -1.00000 0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 -1.0000 0.0000 0.0000 0.0000 0.0000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 2 in struct file Symmetry operation 2 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 4 in struct file Symmetry operation 3 1.00000 0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.0000 0.0000 0.0000 0.0000 0.0000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 3 in struct file Symmetry operation 4 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 1 in struct file LATSYM done 5W layers + 1 Fe layer with 10% contract CXY 6 35 C RELA 8.564901 6.056302101.065800 90.000000 90.000000 90.000000 -1 0.5000000 0.0000000 0.5000000 1 8 Fe1 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 26.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -2 0.0000000 0.0000000 0.4630935 1 8 W 1 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 74.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -3 0.5000000 0.0000000 0.4207746 1 8 W 2 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 74.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -4 0.0000000 0.0000000 0.3786927 1 8 W 3 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 74.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -5 0.5000000 0.0000000 0.3366108 1 8 W 4 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 74.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -6 0.0000000 0.0000000 0.2945289 1 8 W 5 NPT= 781 R0=.000001000 RMT= 2.35000 Z: 74.00000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 THETA, PHI 1.57079632679490 0.000000000000000E+000 symmetry operation 1 1 0 0 0 1 0 0 0 1 operation type A preserve M direction symmetry operation 2 -1 0 0 0 -1 0 0 0 1 operation type A preserve M direction symmetry operation 3 1 0 0 0 -1 0 0 0 1 operation type B *(time inv.) preserve M direction symmetry operation 4 -1 0 0 0 1 0 0 0 1 operation type B *(time inv.) preserve M direction atom 1 not equivalent, new set 1 atom 2 not equivalent, new set 2 atom 3 not equivalent, new set 3 atom 4 not equivalent, new set 4 atom 5 not equivalent, new set 5 atom 6 not equivalent, new set 6 j ind2,ieq 1 1 1 j ind2,ieq 2 2 1 j ind2,ieq 3 3 1 j ind2,ieq 4 4 1 j ind2,ieq 5 5 1 j ind2,ieq 6 6 1 natso= 6 multso 1 1 1 1 1 1 ieq 1 1 1 1 1 1 jatom,ind1,ind2 1 1 1 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 jatom,ind1,ind2 2 2 2 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 jatom,ind1,ind2 3 3 3 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 jatom,ind1,ind2 4 4 4 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 jatom,ind1,ind2 5 5 5 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 jatom,ind1,ind2 6 6 6 rotloc rotij rotlso 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 0.0000 0.0000 1.0000 so. oper. 1 orig. 1 type A so. oper. 2 orig. 2 type A number of A-type operations= 2 so. oper. 3 orig. 3 type B so. oper. 4 orig. 4 type B number of B-type operations= 2 System does not have center of inversion Warning: clmfile 25 skipped Warning: clmfile 26 skipped Warning: clmfile 27 skipped Warning: clmfile 28 skipped Generating clm file 35 nw k j knew rhonew kold Generating clm file 36 nw k j knew rhonew kold Generating clm file 37 nw k j knew rhonew kold SYMSO done 5W layers + 1 Fe layer with 10% contract s-o calc. M|| 1.00 0.00 0.00 ATOMIC POSITIONS: 1 4.28245050 0.00000000 50.53290000 2 0.00000000 0.00000000 46.80291505 3 4.28245050 0.00000000 42.52592157 4 0.00000000 0.00000000 38.27288068 5 4.28245050 0.00000000 34.01983979 6 0.00000000 0.00000000 29.76679890 PGLSYM: THE CRYSTAL SYSTEM IS ORTHORHOMBIC PGLSYM: ORDER OF LATTICE POINT GROUP (NO BASE) = 8 PGBSYM: ORDER OF LATTICE SPACE GROUP (WITH BASE) = 4 PGBSYM: SPACE GROUP IS SYMMORPHIC PGBSYM: SPACE GROUP DOES NOT CONTAIN INVERSION Symmetry operation 1 -1.00000 0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 -1.0000 0.0000 0.0000 0.0000 0.0000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 2 in struct file Symmetry operation 2 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 4 in struct file Symmetry operation 3 1.00000 0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.0000 0.0000 0.0000 0.0000 0.0000 -1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 3 in struct file Symmetry operation 4 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 0.00000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 this is operation 1 in struct file LATSYM done 5W layers + 1 Fe layer with 10% contract s-o calc. M|| 1.00 0.00 0.00 Fe1 : 2 Atome, Index 1 bis 2 W 1 : 2 Atome, Index 3 bis 4 W 2 : 2 Atome, Index 5 bis 6 W 3 : 2 Atome, Index 7 bis 8 W 4 : 2 Atome, Index 9 bis 10 W 5 : 2 Atome, Index 11 bis 12 RSTRUCT done number of atoms: 12 ATOM: -1 Fe1 G 1 oper. # 1 1 GM= Fe1 G 2 oper. # 5 2 || z GM= Fe1 G 3 oper. # 7 m n y GM= Fe1 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== ATOM: -2 W 1 G 1 oper. # 1 1 GM= W 1 G 2 oper. # 5 2 || z GM= W 1 G 3 oper. # 7 m n y GM= W 1 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== ATOM: -3 W 2 G 1 oper. # 1 1 GM= W 2 G 2 oper. # 5 2 || z GM= W 2 G 3 oper. # 7 m n y GM= W 2 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== ATOM: -4 W 3 G 1 oper. # 1 1 GM= W 3 G 2 oper. # 5 2 || z GM= W 3 G 3 oper. # 7 m n y GM= W 3 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== ATOM: -5 W 4 G 1 oper. # 1 1 GM= W 4 G 2 oper. # 5 2 || z GM= W 4 G 3 oper. # 7 m n y GM= W 4 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== ATOM: -6 W 5 G 1 oper. # 1 1 GM= W 5 G 2 oper. # 5 2 || z GM= W 5 G 3 oper. # 7 m n y GM= W 5 G 4 oper. # 8 m n x GM= check whether the operations form a group SYMMETRY OPERATIONS FORM A GROUP ,GROUP MULTIPLICATION TABLE: i 1 2 3 4 j 1 1 2 3 4 2 2 1 4 3 3 3 4 1 2 4 4 3 2 1 pointgroup is mm2 (neg. iatnr!!) axes should be: 2 || z, m n y z-rotation vector: 0.0000 0.0000 1.0000 y-rotation vector: 0.0000 1.0000 0.0000 2 LOCAL ROT MATRIX: NEW OLD 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 1.0000000 lm: 0 0 1 0 2 0 2 2 3 0 3 2 4 0 4 2 4 4 5 0 5 2 5 4 6 0 6 2 6 4 6 6 ============================================== - --------------060707020507040209030207-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 01:15:35 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Symmetso A and B type symmetries - bug? ==== "Saeid Jalali" submitted the following contribution: ==== Dear Torsten, > I just downloaded the newest version of Wien2k_02, and I have a little > problem with symmetso. Are you sure that your struct file is not wrong? Are not you concerned about lopw.f program even regardless spin-orbit or spin polarization (just a simple run)? This was indicated by the author as an evidence of having not a correct structure (specifying an atom twice). Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 17:50:34 -0500 (CDT) From: Bing Zhou Subject: Re: [WIEN]: Electron density map using w2web ==== Bing Zhou submitted the following contribution: ==== Dear Peter and Saeid: It works now, thanks! On Fri, 20 Sep 2002, Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > Last question: the w2web requirs case.in2, how can I get one in my case > > (only case.in2c available)? > Change session information to include complex calculation (no inversion) to > active -c in the w2web too. > Your, > S. Jalali. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Sep 2002 22:41:55 -0700 (PDT) From: mehrdad dadsetani Subject: [WIEN]: *.in1c empty ==== mehrdad dadsetani submitted the following contribution: ==== dear saeed i wrote for you that my calculation is with so(spin-orbit).but file *.in1c is empty. i have done this process 1-initialise 2-initso 3- run scf resut enrgy and charge and fermi energy is converged.you Know that *.in1c is necesary for band structure,so i can't calculated band structure. why *.in1c is empty. *.in2c isn't empty. bets wishes M.dadsetani __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 08:36:10 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: dummy atom ==== Peter Blaha submitted the following contribution: ==== > I would like to include "dummy-atoms" with zero charge into a structure as some sort of placeholder. This would simplify the analysis since I am interested in the partial DOS at an interstitial site, which is not occupied by an atom. Does anybody know how to do that? I think the general question is, if one can introduce a muffin tin sphere, which is not centered around an atom? In general I do not recommend to use "empty" spheres, but there might be exceptions where it is usefull for analysis as you indicate above. During init_lapw put Z=1 (maybe with reduced, but non-zero occupation in case.inst). Before starting the scf cycle, put Z to zero and correct the number of electrons in case.in2. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 10:47:16 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Symmetso A and B type symmetries - bug? ==== Torsten Andersen submitted the following contribution: ==== Dear Saeid, no atoms are specified more than once. What is lopw.f? Something new? Anyway, nn, sgroup, symmetry, and so on behaves well, and the system runs nicely through the scf cycle if I just select the right symmetries by hand. Symmetry and sgroup finds the four symmetries if I remove the symmetries. I still believe there is an undocumented feature (or bug) in symmetso for this CXY case. It also did not remove the B types, as it should according to the manual, p. 129, for a system without inversion symmetry such as this one. For a similar type of calculation, but with a P lattice and Cu in stead of W, it finds the right symmetry. Best regards, Torsten. Saeid Jalali wrote: >==== >"Saeid Jalali" >submitted the following contribution: >==== > >Dear Torsten, > >>I just downloaded the newest version of Wien2k_02, and I have a little >>problem with symmetso. >> >Are you sure that your struct file is not wrong? Are not you concerned about >lopw.f program even regardless spin-orbit or spin polarization (just a >simple run)? This was indicated by the author as an evidence of having not a >correct structure (specifying an atom twice). >Your, >S. Jalali. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 14:03:57 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Symmetso A and B type symmetries - bug? ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0012_01C2630A.0F7517B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > no atoms are specified more than once. What is lopw.f? Something new?=20 LOPW is a SUBROUTINE which generates the LAPW (K+G)-vector for local = orbitals, and it is not new at all. > Anyway, nn, sgroup, symmetry, and so on behaves well, I will say. > and the system=20 > runs nicely through the scf cycle if I just select the right = symmetries=20 > by hand. And if you leave symmeties as defualt? > Symmetry and sgroup finds the four symmetries if I remove the=20 > symmetries. I still believe there is an undocumented feature (or bug) = in=20 > symmetso for this CXY case. It also did not remove the B types, as it=20 > should according to the manual, p. 129, for a system without inversion = > symmetry such as this one. For a similar type of calculation, but with = a=20 > P lattice and Cu in stead of W, it finds the right symmetry. I have gone through your case using simple run_lapw c-shell script = without considering anything more, e.g. -so, and found that lapw1 = complains about LOPW. Now choice is yours to believe whatever you would = like. Your, S. Jalali. - ------=_NextPart_000_0012_01C2630A.0F7517B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> no atoms are specified more than = once. What is=20 lopw.f? Something new?

LOPW is a SUBROUTINE which generates the LAPW (K+G)-vector for local orbitals, and it is = not new at=20 all.

> Anyway, nn, sgroup, symmetry, and = so on=20 behaves well,
I will say.
> and the system
> runs = nicely=20 through the scf cycle if I just select the right symmetries
> by=20 hand.
And if you leave symmeties as = defualt?
 
> Symmetry and sgroup finds the = four=20 symmetries if I remove the
> symmetries. I still believe there is = an=20 undocumented feature (or bug) in
> symmetso for this CXY case. It = also=20 did not remove the B types, as it
> should according to the = manual, p.=20 129, for a system without inversion
> symmetry such as this one. = For a=20 similar type of calculation, but with a
> P lattice and Cu in = stead of W,=20 it finds the right symmetry.
I have gone through your case using = simple run_lapw=20 c-shell script without considering anything more, e.g. -so, and found = that lapw1=20 complains about LOPW. Now choice is yours to believe whatever you would=20 like.
Your,
S. Jalali.
- ------=_NextPart_000_0012_01C2630A.0F7517B0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 13:03:55 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Symmetso A and B type symmetries - bug? ==== Peter Blaha submitted the following contribution: ==== > I just downloaded the newest version of Wien2k_02, and I have a little > problem with symmetso. It appears to me that it gives wrong sorting of A > and B symmetry types. I have attached a structure file for illustration. > In it is 4 symmetries: > > 4 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 > -1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 2 > 1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 3 > -1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 4 > > Choosing M as 1.0 0.0 0.0 in .inso I would by hand expect symmetries 1 > and 4 to be of the A type, since M transforms as M_i=det(s)*s_ij*M_j > under a symmetry operation with the 3x3 matrix s. Then why does symmetso > tell me that symmetries 1 and 2 are the A type? I have tried this using your struct file. Symmetso correctly describes the second operation as B type (not as A as you claim) when magnetization is in 1 0 0 direction. Operation2 is A type for magnetization in (0 0 1) direction. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 12:15:03 +0100 (BST) From: Vincent Jennings Subject: Re: [WIEN]: Units. ==== Vincent Jennings submitted the following contribution: ==== Dear Saeid, Thanks for your comments. I'm happy now that I have the right dimensions. I am still uncertain about the units for Gmax, though. I guess that they are (a.u.)^-1, but I can't find anything that states this in the user guide. Thanks again, Vin. On Fri, 20 Sep 2002, Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > I posted this question a few days ago, and I know that it's fairly > > trivial, but I would like confirmation that I have the right units as it > > is one of the last things that I need to finish off my thesis. So far I > > havn't found anything that states the units explicitly. > > > > As far as I can tell from the comments in lapw2 files Gmax is in 1/a.u. > > > > Hi, > > > This should be an easy question... > > > I want to check the units for RKmax and Gmax. I figure RKmax should > be > > > dimensionless, and Gmax should have dimension of 1/length. > > I don't think that looking for the units of physical quantities is trivial. > Many refuse to answer such questions and like to pretend they are trivial as > they come from and return to fundamental physics. > Yes you are right: the unit of Kmax or Gmax is 1/length, and so R*Kmax is > dimensionless. > Your question returns to star space, where we have exp(r.K) with the cutoff > of Kmax as basis for expanding wavefunctions and exp(r.G) with the cutoff of > Gmax as basis for expanding charge density and potential energy. So, Kmax > and Gmax should be dimensionless. > Your, > S. Jalali. > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - ------------------------------------------------------------------------------- Vincent Jennings "Some days you're the pigeon email: V.L.Jennings@warwick.ac.uk and some days you're the statue." - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 13:31:20 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Symmetso A and B type symmetries - bug? ==== Torsten Andersen submitted the following contribution: ==== Dear Peter, So maybe I have misunderstood something. My symmetso just did it again... Does h,k,l in case.inso in any way correspond to a,b,c in case.struct? And yes, I know how it should be with M along a,b, or c. Best regards, Torsten. Peter Blaha wrote: >==== >Peter Blaha >submitted the following contribution: >==== > >>I just downloaded the newest version of Wien2k_02, and I have a little >>problem with symmetso. It appears to me that it gives wrong sorting of A >>and B symmetry types. I have attached a structure file for illustration. >>In it is 4 symmetries: >> >> 4 NUMBER OF SYMMETRY OPERATIONS >> 1 0 0 0.0000000 >> 0 1 0 0.0000000 >> 0 0 1 0.0000000 >> 1 >> -1 0 0 0.0000000 >> 0-1 0 0.0000000 >> 0 0 1 0.0000000 >> 2 >> 1 0 0 0.0000000 >> 0-1 0 0.0000000 >> 0 0 1 0.0000000 >> 3 >> -1 0 0 0.0000000 >> 0 1 0 0.0000000 >> 0 0 1 0.0000000 >> 4 >> >>Choosing M as 1.0 0.0 0.0 in .inso I would by hand expect symmetries 1 >>and 4 to be of the A type, since M transforms as M_i=det(s)*s_ij*M_j >>under a symmetry operation with the 3x3 matrix s. Then why does symmetso >>tell me that symmetries 1 and 2 are the A type? >> > >I have tried this using your struct file. >Symmetso correctly describes the second operation as B type (not as A as >you claim) when magnetization is in 1 0 0 direction. > >Operation2 is A type for magnetization in (0 0 1) direction. > >Regards > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 15:16:17 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: *.in1c empty ==== "Saeid Jalali" submitted the following contribution: ==== > you Know that *.in1c is necesary for band structure,so i > can't calculated band structure. I don't know that: case.in1c is necessary just in the absent of inversion symmetry. I paste below a comment in this respect from the Aouther, "Even in a non-spinpolarized case the eigenvectors from lapwso are always complex numbers, so one must use lapw2c (and in2c), but not lapw1c or in1c (if inversion is present)." > why *.in1c is empty. > *.in2c isn't empty. It should be clear now. Anyway if you think that your system does not have inversion, you can simply move case.in1 to case.in1c. Your, S. jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 16:56:16 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Units. ==== "Saeid Jalali" submitted the following contribution: ==== > I am still uncertain about the units for Gmax, though. > I guess that they are (a.u.)^-1, but I can't find anything that states > this in the user guide. Yes, they are: see description of rkmax. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 15:20:14 +0200 From: =?US-ASCII?Q?Anders_Froseth?= Subject: SV: [WIEN]: Units. ==== =?US-ASCII?Q?Anders_Froseth?= submitted the following contribution: ==== Dear Vincent, The units for GMAX, (as stated in the .scf file) are Ry**(1/2). This makes GMAX "proportional" to the magnitude of the largest vector in the Fourier expansion of the charge density and potential in the interstitial region. You have to play around with atomic units: GMAX = (E_max)**(1/2) = h_bar*K_max/(2*m_electron)**(1/2) and in atomic units the constant of proportionality is equal to 1 (h_bar**2/2m = 1) and GMAX = (E_max)**(1/2) = K_max Regards, Anders > -----Opprinnelig melding----- > Fra: owner-wien@zeus.theochem.tuwien.ac.at > [mailto:owner-wien@zeus.theochem.tuwien.ac.at]Pa vegne av Vincent > Jennings > Sendt: 23. september 2002 13:15 > Til: wien@zeus.theochem.tuwien.ac.at > Emne: Re: [WIEN]: Units. > > > ==== > Vincent Jennings > submitted the following contribution: > ==== > > Dear Saeid, > Thanks for your comments. I'm happy now that I have the right > dimensions. I am still uncertain about the units for Gmax, though. > I guess that they are (a.u.)^-1, but I can't find anything that states > this in the user guide. > > Thanks again, > Vin. > > On Fri, 20 Sep 2002, Saeid Jalali wrote: > > > ==== > > "Saeid Jalali" > > submitted the following contribution: > > ==== > > > > > I posted this question a few days ago, and I know that it's fairly > > > trivial, but I would like confirmation that I have the right > units as it > > > is one of the last things that I need to finish off my > thesis. So far I > > > havn't found anything that states the units explicitly. > > > > > > As far as I can tell from the comments in lapw2 files Gmax is > in 1/a.u. > > > > > > Hi, > > > > This should be an easy question... > > > > I want to check the units for RKmax and Gmax. I figure > RKmax should > > be > > > > dimensionless, and Gmax should have dimension of 1/length. > > > > I don't think that looking for the units of physical quantities > is trivial. > > Many refuse to answer such questions and like to pretend they > are trivial as > > they come from and return to fundamental physics. > > Yes you are right: the unit of Kmax or Gmax is 1/length, and so > R*Kmax is > > dimensionless. > > Your question returns to star space, where we have exp(r.K) > with the cutoff > > of Kmax as basis for expanding wavefunctions and exp(r.G) with > the cutoff of > > Gmax as basis for expanding charge density and potential > energy. So, Kmax > > and Gmax should be dimensionless. > > Your, > > S. Jalali. > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > ------------------------------------------------------------------ > ------------- > Vincent Jennings "Some days you're the pigeon > email: V.L.Jennings@warwick.ac.uk and some days you're the statue." > ------------------------------------------------------------------ > ------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 15:30:35 +0100 (BST) From: Vincent Jennings Subject: Re: SV: [WIEN]: Units. ==== Vincent Jennings submitted the following contribution: ==== Thanks Saeid and Anders, I should have thought to look in the scf file. That makes sense now. Vincent On Mon, 23 Sep 2002, Anders Froseth wrote: > ==== > =?US-ASCII?Q?Anders_Froseth?= > submitted the following contribution: > ==== > > > Dear Vincent, > > The units for GMAX, (as stated in the .scf file) are Ry**(1/2). > This makes GMAX "proportional" to the magnitude of the largest vector > in the Fourier expansion of the charge density and potential in > the interstitial region. You have to play around with atomic units: > > GMAX = (E_max)**(1/2) = h_bar*K_max/(2*m_electron)**(1/2) > > and in atomic units the constant > of proportionality is equal to 1 (h_bar**2/2m = 1) and > > GMAX = (E_max)**(1/2) = K_max > > Regards, > > Anders > > > -----Opprinnelig melding----- > > Fra: owner-wien@zeus.theochem.tuwien.ac.at > > [mailto:owner-wien@zeus.theochem.tuwien.ac.at]Pa vegne av Vincent > > Jennings > > Sendt: 23. september 2002 13:15 > > Til: wien@zeus.theochem.tuwien.ac.at > > Emne: Re: [WIEN]: Units. > > > > > > ==== > > Vincent Jennings > > submitted the following contribution: > > ==== > > > > Dear Saeid, > > Thanks for your comments. I'm happy now that I have the right > > dimensions. I am still uncertain about the units for Gmax, though. > > I guess that they are (a.u.)^-1, but I can't find anything that states > > this in the user guide. > > > > Thanks again, > > Vin. > > > > On Fri, 20 Sep 2002, Saeid Jalali wrote: > > > > > ==== > > > "Saeid Jalali" > > > submitted the following contribution: > > > ==== > > > > > > > I posted this question a few days ago, and I know that it's fairly > > > > trivial, but I would like confirmation that I have the right > > units as it > > > > is one of the last things that I need to finish off my > > thesis. So far I > > > > havn't found anything that states the units explicitly. > > > > > > > > As far as I can tell from the comments in lapw2 files Gmax is > > in 1/a.u. > > > > > > > > Hi, > > > > > This should be an easy question... > > > > > I want to check the units for RKmax and Gmax. I figure > > RKmax should > > > be > > > > > dimensionless, and Gmax should have dimension of 1/length. > > > > > > I don't think that looking for the units of physical quantities > > is trivial. > > > Many refuse to answer such questions and like to pretend they > > are trivial as > > > they come from and return to fundamental physics. > > > Yes you are right: the unit of Kmax or Gmax is 1/length, and so > > R*Kmax is > > > dimensionless. > > > Your question returns to star space, where we have exp(r.K) > > with the cutoff > > > of Kmax as basis for expanding wavefunctions and exp(r.G) with > > the cutoff of > > > Gmax as basis for expanding charge density and potential > > energy. So, Kmax > > > and Gmax should be dimensionless. > > > Your, > > > S. Jalali. > > > > > > > > > ==== > > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > > To (un)subscribe send mail to > > > majordomo@zeus.theochem.tuwien.ac.at > > > ==== > > > > > > > ------------------------------------------------------------------ > > ------------- > > Vincent Jennings "Some days you're the pigeon > > email: V.L.Jennings@warwick.ac.uk and some days you're the statue." > > ------------------------------------------------------------------ > > ------------- > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - ------------------------------------------------------------------------------- Vincent Jennings "Some days you're the pigeon email: V.L.Jennings@warwick.ac.uk and some days you're the statue." - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Sep 2002 18:45:12 +0430 From: "Saeid Jalali" Subject: Re: [WIEN]: Units. ==== "Saeid Jalali" submitted the following contribution: ==== > > I am still uncertain about the units for Gmax, though. > > I guess that they are (a.u.)^-1, but I can't find anything that states > > this in the user guide. > Yes, they are: see description of rkmax. In the description of rkamx, one finds how my fast above confirmation is unclean in contrast to the clean one of Anders!!! Thank you Anders. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 09:13:44 +0200 From: Torsten Andersen Subject: [WIEN]: case.inso ==== Torsten Andersen submitted the following contribution: ==== Hello again, the symmetso problem was solved, thanks to Peter Blaha. Now a simple question about case.inso, since it has changed from Wien2k_01 to Wien2k_02. If I don't want rlo's, do I have to delete "line 6"? In the old case.inso it was just ignored, I think. In the new case.inso there is a "line 7", however. If in "line 5" I have put a zero, what does the program expect next, a single line 6 or no line 6, but line 7 in stead? Yes, I guess it could be read by sifting through the code, but I think it should be clear in the manual... Best regards, Torsten. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 17:43:03 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: occupied bands ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, Can anyone tell me if there is a way in Wien to find out which bands are occupied (eg by the bandindex number)? As there are many bands that emerge from a bandstruct calc for slabs... Maybe a density of states calc would be helpful? Thanks for your time! Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 10:03:44 +0200 From: Torsten Andersen Subject: Re: [WIEN]: occupied bands ==== Torsten Andersen submitted the following contribution: ==== It can not be done that simple, as bands do cross the Fermi energy in many systems. Thereby I have also said how you can find out... Wien2k gives you the Fermi energy and the energies for each k-point, so all those below the Fermi energy are occupied and all those above are unoccupied. A density of states calculation (or a spaghetti) can, if enough k-points are involved, give you a fairly good hint about if crossing bands exists. Best regards, Torsten. chen0130@flinders.edu.au wrote: >==== >chen0130@flinders.edu.au >submitted the following contribution: >==== > >Dear Wien users, > >Can anyone tell me if there is a way in Wien to find out which bands are >occupied (eg by the bandindex number)? > >As there are many bands that emerge from a bandstruct calc for slabs... > >Maybe a density of states calc would be helpful? > >Thanks for your time! > >Cheng > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 10:16:13 +0200 From: Torsten Andersen Subject: Re: [WIEN]: occupied bands ==== Torsten Andersen submitted the following contribution: ==== Oh... and, if no bands cross the Fermi energy, you indeed can use the band index. Best regards, Torsten. Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > It can not be done that simple, as bands do cross the Fermi energy in > many systems. > > Thereby I have also said how you can find out... Wien2k gives you the > Fermi energy and the energies for each k-point, so all those below the > Fermi energy are occupied and all those above are unoccupied. A > density of states calculation (or a spaghetti) can, if enough k-points > are involved, give you a fairly good hint about if crossing bands exists. > > Best regards, > Torsten. > > chen0130@flinders.edu.au wrote: > >> ==== >> chen0130@flinders.edu.au >> submitted the following contribution: >> ==== >> >> Dear Wien users, >> >> Can anyone tell me if there is a way in Wien to find out which bands are >> occupied (eg by the bandindex number)? >> >> As there are many bands that emerge from a bandstruct calc for slabs... >> >> Maybe a density of states calc would be helpful? >> >> Thanks for your time! >> >> Cheng >> >> >> ==== >> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> To (un)subscribe send mail to >> majordomo@zeus.theochem.tuwien.ac.at >> ==== >> >> > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 10:57:45 +0200 From: "Antoine Villesuzanne" Subject: [WIEN]: Partial DOS/Tetra ==== "Antoine Villesuzanne" submitted the following contribution: ==== Calculating the partial DOS for : (i) one atom type (ii) one atomic orbital for one atom type does not give consistent results since the atom type mutiplicity is accounted for in (i), but not in (ii). In other words, for a given atom type, the sum of atomic orbital contributions to the DOS is equal to the atom type partial DOS divided by the multiplicity. This may lead to wrong conclusions and should be corrected in tetra. Regards Antoine Villesuzanne ICMCB-CNRS 87 Av. Dr. Schweitzer 33608 Pessac cedex France ville@icmcb.u-bordeaux.fr ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 10:56:51 +0200 From: "koitzsch" Subject: Re: [WIEN]: occupied bands ==== "koitzsch" submitted the following contribution: ==== hope I understood the question correctly: In principle you know your Fermi Energy from the output of your scf cycle. This would tell you up to which energy your bands are filled. Then you just have to see if you have eigenvalues in a particular band below this level, which would render your band filled. I think the best way to see that is a conventional band structure plot. It answers all this, since you have to tell the program the correct Fermi Energy in case.insp from case.scf Best Regards Christian Koitzsch - ----- Original Message ----- From: To: Sent: Tuesday, September 24, 2002 9:43 AM Subject: [WIEN]: occupied bands > ==== > chen0130@flinders.edu.au > submitted the following contribution: > ==== > > Dear Wien users, > > Can anyone tell me if there is a way in Wien to find out which bands are > occupied (eg by the bandindex number)? > > As there are many bands that emerge from a bandstruct calc for slabs... > > Maybe a density of states calc would be helpful? > > Thanks for your time! > > Cheng > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 18:42:02 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, Actually, I am trying to calculate the optical properties of my molecule. And after I have performed "optic". I found that the output file ".outmat" only containing 4 K-point. Then, I look back to the file ".outputkgen". The ".outputkgen" is as below: ortho= T R1 = 18.897269 0.000000 0.000000 R2 = 0.000000 18.897269 0.000000 R3 = 0.000000 0.000000 4.651079 DEPENDENCE OF DIVISION OF TRANSLATION VECTORS IARB= 0 0 0 NAME OF POINT GROUP = INVERSION = 1 ERROR : POINT GROUP NAME NOT IN THE LIST, CHECK : BRADLEY AND CRACKNELL NUMBER OF POINT GROUP OPERATIONS = 2 SYMMETRY MATRIX NR. 1 SYMMETRY MATRIX NR. 2 SYMMETRY MATRIX NR. 3 SYMMETRY MATRIX NR. 4 1 0 0 -1 0 0 0 0 0 0 0 0 0 1 0 0 -1 0 0 0 0 0 0 0 0 0 1 0 0 -1 0 0 0 0 0 0 SYMMETRY MATRIX NR. 1 SYMMETRY MATRIX NR. 2 SYMMETRY MATRIX NR. 3 SYMMETRY MATRIX NR. 4 -1 0 0 1 0 0 -1 0 0 1 0 0 0 -1 0 0 1 0 0 -1 0 0 1 0 0 0 -1 0 0 1 0 0 1 0 0 -1 G1 G2 G3 0.052918 0.000000 0.000000 0.000000 0.052918 0.000000 0.000000 0.000000 0.215004 G1 G2 G3 0.332492 0.000000 0.000000 0.000000 0.332492 0.000000 0.000000 0.000000 1.350909 length of reciprocal lattic vectors: 1.70109365 1.70109365 6.91151972 SUBMESH SHIFTED; SHIFT: 0 0 0 NO. OF MESH POINTS IN THE BRILLOUIN ZONE = 6 DIVISION OF RECIPROCAL LATTICE VECTORS (INTERVALS)= 1 1 6 point coordinates relation 1 0 0 0 1 0.12500 0.12500 2 0 0 1 2 0.25000 0.25000 3 0 0 2 3 0.25000 0.25000 4 0 0 3 4 0.25000 0.25000 5 0 0 4 3 0.25000 0.50000 6 0 0 5 2 0.25000 0.50000 7 0 0 6 1 0.12500 0.25000 8 0 1 0 1 0.12500 0.37500 9 0 1 1 2 0.25000 0.75000 10 0 1 2 3 0.25000 0.75000 11 0 1 3 4 0.25000 0.50000 12 0 1 4 3 0.25000 1.00000 13 0 1 5 2 0.25000 1.00000 14 0 1 6 1 0.12500 0.50000 15 1 0 0 1 0.12500 0.62500 16 1 0 1 2 0.25000 1.25000 17 1 0 2 3 0.25000 1.25000 18 1 0 3 4 0.25000 0.75000 19 1 0 4 3 0.25000 1.50000 20 1 0 5 2 0.25000 1.50000 21 1 0 6 1 0.12500 0.75000 22 1 1 0 1 0.12500 0.87500 23 1 1 1 2 0.25000 1.75000 24 1 1 2 3 0.25000 1.75000 25 1 1 3 4 0.25000 1.00000 26 1 1 4 3 0.25000 2.00000 27 1 1 5 2 0.25000 2.00000 28 1 1 6 1 0.12500 1.00000 weights of k-points: 1 1 1.000000 0.333333 2 2 2.000000 0.666667 3 3 2.000000 0.666667 4 4 1.000000 0.333333 sum of weights: 2.000000 internal and cartesian k-vectors: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.16667 0.00000 0.00000 0.22515 0.00000 0.00000 0.33333 0.00000 0.00000 0.45030 0.00000 0.00000 0.50000 0.00000 0.00000 0.67545 NO. OF INEQUIVALENT K-POINTS 4 INEQUIVALENT BLOCH VECTORS 1( 0.000000 0.000000 0.000000) 2 ( 0.000000 0.000000 0.225152) 3( 0.000000 0.000000 0.450303) 4 ( 0.000000 0.000000 0.675455) NUMBER OF DIFFERENT TETRAHEDRA : 9 NKP,NDIV,afact 4 1 1 6 1. 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.16667 0.00000 0.00000 2.00000 0.00000 0.00000 0.33333 0.00000 0.00000 4.00000 0.00000 0.00000 0.50000 0.00000 0.00000 6.00000 My questions are as below: 1. What does the "reciprocal lattic vectors" mean? 2. How does wien get the "NO. OF MESH POINTS IN THE BRILLOUIN ZONE"? What does this value mean? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 14:09:20 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Partial DOS/Tetra ==== "Saeid Jalali" submitted the following contribution: ==== > Calculating the partial DOS for : > (i) one atom type > (ii) one atomic orbital for one atom type > does not give consistent results since the atom type mutiplicity is > accounted for in (i), but not in (ii). > In other words, for a given atom type, the sum of atomic orbital > contributions to the DOS is equal to the atom type partial DOS divided by > the multiplicity. > This may lead to wrong conclusions and should be corrected in tetra. This is perfectly recognized by you, is not this?! You, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 13:20:17 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: occupied bands ==== Peter Blaha submitted the following contribution: ==== > Can anyone tell me if there is a way in Wien to find out which bands are > occupied (eg by the bandindex number)? > > As there are many bands that emerge from a bandstruct calc for slabs... > > Maybe a density of states calc would be helpful? > > Thanks for your time! Have a look into case.output2 (up/dn). At the top you find e-fermi, but also the emin/emax of each band (ordered by bandindex), so that you easily can judge how many bands are fully occupied and how many bands cross EF. (The same info is also given in case.outputt (after tetra). Of course in a metallic situation you then must plot a bandstructure to get more insight. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 19:38:56 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I would like to consult about the deftinition of somr terms in wien od solid-state physics. 1. definition of "momentum matrix elements" (Is it the same as transition dipole moment?) 2. definition of k-mesh (What is the differences between k-mesh and k-point?) Thank you very much Martin - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 13:31:30 +0200 From: Torsten Andersen Subject: Re: [WIEN]: case.inso ==== Torsten Andersen submitted the following contribution: ==== So, I took a dive into the code. In SRC_lapwso/init.f I found: - --BEGIN QUOTE CODE--- !rschmid ! read in parameters for basis extension by relativistic basis function. !rschmid do ity=1,nat nlr(ity)=0 end do read(5,*,end=644)nrelcase do i=1,nrelcase read(5,*) ity,edum1,edum2 extei(ity,1)=edum1 extde(ity,1)=edum2 nlr(ity)=1 enddo 644 read(5,*,end=345)noff,(iatoff(i),i=1,noff) do i=1,noff lso(iatoff(i))=.false. write(6,*)'SOC on atom ',iatoff(i),'SWITCHED OFF !!!' enddo 345 continue 5000 format (1x,i1,2f10.5,a4) - -- END QUOTE CODE --- It is clear to me what happens up to and including read(5,*,end=644)nrelcase. However, do i=1,nrelcase then becomes do i=1,0 if nrelcase is put to zero. Now I know that if the standard of Fortran90 is followed, the do-loop is not executed [Metcalf & Reid, p. 73], and thus to get correct input, "line 6" has to be deleted, unless the first number in it is 0. I also remember to have seen in some places that for certain "default" options of compilers, do-loops gets run at least once... so there could be a potential problem there... So I answered my question first, it seems :-) Any comments? Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Hello again, > > the symmetso problem was solved, thanks to Peter Blaha. > > Now a simple question about case.inso, since it has changed from > Wien2k_01 to Wien2k_02. > > If I don't want rlo's, do I have to delete "line 6"? In the old > case.inso it was just ignored, I think. In the new case.inso there is > a "line 7", however. If in "line 5" I have put a zero, what does the > program expect next, a single line 6 or no line 6, but line 7 in stead? > > Yes, I guess it could be read by sifting through the code, but I think > it should be clear in the manual... > > Best regards, > Torsten. > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 13:36:12 +0200 From: Torsten Andersen Subject: Re: [WIEN]: case.inso ==== Torsten Andersen submitted the following contribution: ==== Oops. It should be "line 6" has to be deleted, unless the first number in it is 0, or "line 7" is needed. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 13:46:43 +0200 From: Torsten Andersen Subject: Re: [WIEN]: ==== Torsten Andersen submitted the following contribution: ==== Hi, 1. Momentum matrix elements are usually where the "p" is the momentum operator. The transition dipole moment can be the same, but is not necessary that. It depends on the context. 2. A k-mesh is the grid of k-points used when calculating. You could call it k-point sampling set - it is the sampling points in the numerical approximation used to replace integrals with sums. Was this of any help? Otherwise, ask again... Best regards, Torsten Andersen. Ma Chi Chiu wrote: >==== >Ma Chi Chiu >submitted the following contribution: >==== > >Hi, > >I would like to consult about the deftinition of somr terms in wien od >solid-state physics. > >1. definition of "momentum matrix elements" (Is it the same as transition >dipole moment?) >2. definition of k-mesh (What is the differences between k-mesh and >k-point?) > >Thank you very much > >Martin > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 14:52:56 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Partial DOS/Tetra ==== Peter Blaha submitted the following contribution: ==== On Tue, 24 Sep 2002, Antoine Villesuzanne wrote: > ==== > "Antoine Villesuzanne" > submitted the following contribution: > ==== > > Calculating the partial DOS for : > (i) one atom type > (ii) one atomic orbital for one atom type > does not give consistent results since the atom type mutiplicity is > accounted for in (i), but not in (ii). > In other words, for a given atom type, the sum of atomic orbital > contributions to the DOS is equal to the atom type partial DOS divided by > the multiplicity. > This may lead to wrong conclusions and should be corrected in tetra. This is not an error, but a "feature" (documented in the UG (section TETRA)) I admit it might be unusual, but the idea is: In the decomposition of the total DOS into contributions of atoms, I want to include the multiplicity, so that I get an idea of which atoms contribute with which amount to a DOS at a particular energy. On the other hand, the lm-like DOS I want to see per atom, so that I can get a feeling about a possible chemical bonding. It is something like the coefficient in front of a basis function (or an orbital population). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 15:03:37 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: case.inso ==== Peter Blaha submitted the following contribution: ==== > If I don't want rlo's, do I have to delete "line 6"? In the old > case.inso it was just ignored, I think. In the new case.inso there is a > "line 7", however. If in "line 5" I have put a zero, what does the > program expect next, a single line 6 or no line 6, but line 7 in stead? > > Yes, I guess it could be read by sifting through the code, but I think > it should be clear in the manual... The UG states line 6 should be repeated nrl times, i.e. if nrl=0 it should not be present at all. I will add this explicitly in the UG. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 09:26:06 -0400 From: Fred Nastos Subject: Re: [WIEN]: case.inso ==== Fred Nastos submitted the following contribution: ==== On September 24, 2002 07:31 am, Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > So, I took a dive into the code. In SRC_lapwso/init.f I found: > > > > I also remember to have seen in some places that for certain > "default" options of compilers, do-loops gets run at least > once... so there could be a potential problem there... I have only seen "forcing each do loop to execute at least once" as a compiler option that is turned off by default. Do you remember which compiler has this turned on. > So I answered my question first, it seems :-) Any comments? For no RLOs I use something like the following case.inso (depending on details). The older style case.inso (WIEN2k_01) doesn't work sometimes, since there is the new option of switching off SO for individual atoms. WFFIL 4 1 0 llmax,ipr,kpot -10.0000 5.00000 emin,emax (output energy window) 0. 0. 1. direction of magnetization (lattice vectors) 0 number of atoms for which RLO is added 0 0 0 0 0 number of atoms for which SO is switch off;atoms Cheers, Fred > Torsten Andersen wrote: > > ==== > > Torsten Andersen > > submitted the following contribution: > > ==== > > > > Hello again, > > > > the symmetso problem was solved, thanks to Peter Blaha. > > > > Now a simple question about case.inso, since it has changed from > > Wien2k_01 to Wien2k_02. > > > > If I don't want rlo's, do I have to delete "line 6"? In the old > > case.inso it was just ignored, I think. In the new case.inso there is > > a "line 7", however. If in "line 5" I have put a zero, what does the > > program expect next, a single line 6 or no line 6, but line 7 in stead? > > > > Yes, I guess it could be read by sifting through the code, but I think > > it should be clear in the manual... > > > > Best regards, > > Torsten. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 09:45:07 -0400 From: Fred Nastos Subject: Re: [WIEN]: ==== Fred Nastos submitted the following contribution: ==== On September 24, 2002 07:38 am, Ma Chi Chiu wrote: > ==== > Ma Chi Chiu > submitted the following contribution: > ==== Before I pushed send, I noticed Dr. Andersen has allready replied. Just to add though... > 1. definition of "momentum matrix elements" (Is it the same as transition > dipole moment?) The momentum matrix element is defined as, = int d^3r i hbar nabla where |nk> is a Bloch state. The wien code uses Rydberg atomic units (throughout), in which hbar=m=e=1. The atomic unit for momentum (Ry or H) is hbar/a0 (where a0 is the Bohr radius). The dipole matrix element is usually . If n and m are different bands the two matrix elements can be simply related as they are for molecules. > 2. definition of k-mesh (What is the differences between k-mesh and > k-point?) The k-mesh is the set of k-points, i.e. the grid of points. See Bloechl et al. [Phys. Rev. B 49, 16223-16233 (1994)] for the details. Fred ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 09:50:32 -0400 (EDT) From: Neme Nnolim Subject: [WIEN]: Question about slab calculations ==== Neme Nnolim submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --Boundary_(ID_58wsaM2GAVOeBTRCg3qraA) Content-type: TEXT/PLAIN; charset=US-ASCII Dear WIEN users, I am attempting to carry out calculations on a 5-layer tantalum slab periodic in the z-direction (please see attached struct file). For calculation of properties, I understand one needs to find the optimal length of empty space in the unit cell as well as the optimal interlayer spacing for the slab. WIEN offers 'mini' and the c/a and volume optimization combination for structural optimization purposes. Which optimization feature is best suited for the optimization of the slab interlayer spacing? Can the c/a and volume optimization combination be used to optimize the amount of unit cell vacuum space? Thanks for looking. Regards, Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- - --Boundary_(ID_58wsaM2GAVOeBTRCg3qraA) Content-id: Content-type: TEXT/PLAIN; name=Ta_slab1.struct; charset=US-ASCII Content-description: Ta_slab1.struct Content-disposition: attachment; filename=Ta_slab1.struct Content-transfer-encoding: BASE64 VGFfc2xhYiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUCAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiAzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICA2LjIzODU2MCAgNi4yMzg1NjAxMDUuMDAw MDAwIDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAg Wj0wLjM3NTIyOTAwDQogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BM SVQ9LTINCiAgICAgIC0xOiBYPTAuMDAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9 MC42MjQ3NzEwMA0KVGEgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMDA1 MDAgUk1UPSAgICAyLjcwMDAgICBaOiA3My4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTI6IFg9MC41MDAwMDAw MCBZPTAuNTAwMDAwMDAgWj0wLjU2MjM4NjAwDQogICAgICAgICAgTVVMVD0g MiAgICAgICAgICBJU1BMSVQ9LTINCiAgICAgIC0yOiBYPTAuNTAwMDAwMDAg WT0wLjUwMDAwMDAwIFo9MC40Mzc2MTUwMA0KVGEgICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMDA1MDAgUk1UPSAgICAyLjcwMDAgICBaOiA3My4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTM6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAgWj0wLjUwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9LTINClRhICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDAwNTAwIFJNVD0gICAgMi43MDAwICAg WjogNzMuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCiAgMTYgICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUw0K IDEgMCAwIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAu MDAwMDAwMA0KICAgICAgIDENCiAwLTEgMCAwLjAwMDAwMDANCiAxIDAgMCAw LjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAgICAyDQotMSAwIDAg MC4wMDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAw DQogICAgICAgMw0KIDAgMSAwIDAuMDAwMDAwMA0KIDEgMCAwIDAuMDAwMDAw MA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAgIDQNCiAwLTEgMCAwLjAwMDAw MDANCi0xIDAgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAg ICA1DQogMSAwIDAgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMCAw LTEgMC4wMDAwMDAwDQogICAgICAgNg0KIDEgMCAwIDAuMDAwMDAwMA0KIDAt MSAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgIDcNCiAw LTEgMCAwLjAwMDAwMDANCiAxIDAgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAw MDAwMDANCiAgICAgICA4DQogMCAxIDAgMC4wMDAwMDAwDQotMSAwIDAgMC4w MDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQogICAgICAgOQ0KLTEgMCAwIDAu MDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuMDAwMDAwMA0K ICAgICAgMTANCi0xIDAgMCAwLjAwMDAwMDANCiAwLTEgMCAwLjAwMDAwMDAN CiAwIDAgMSAwLjAwMDAwMDANCiAgICAgIDExDQogMCAxIDAgMC4wMDAwMDAw DQogMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICAx Mg0KIDAtMSAwIDAuMDAwMDAwMA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMCAx IDAuMDAwMDAwMA0KICAgICAgMTMNCiAxIDAgMCAwLjAwMDAwMDANCiAwIDEg MCAwLjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAgIDE0DQogMCAx IDAgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAw MDAwDQogICAgICAxNQ0KLTEgMCAwIDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAw MDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgMTYNCg== - --Boundary_(ID_58wsaM2GAVOeBTRCg3qraA)-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 15:54:10 +0200 From: Torsten Andersen Subject: Re: [WIEN]: case.inso ==== Torsten Andersen submitted the following contribution: ==== No, I do not remember which compiler (or if it was turned on or off as default)... sorry. In Fortran90 it should be off as default, since that is what the standard says, but for adapted fortran77-compilers I am not sure what happens if the file has a .f extension and not .f90. Some of them allows for a lot of things in .f files, so it is hard to keep track of. But I simply deleted "line 6" after looking into the code, so my inso file is something like yours (with other details) now. And the function is now clear to me... Best, Torsten. Fred Nastos wrote: >==== >Fred Nastos >submitted the following contribution: >==== > >On September 24, 2002 07:31 am, Torsten Andersen wrote: > >>==== >>Torsten Andersen >>submitted the following contribution: >>==== >> >>So, I took a dive into the code. In SRC_lapwso/init.f I found: >> >> >> >>I also remember to have seen in some places that for certain >>"default" options of compilers, do-loops gets run at least >>once... so there could be a potential problem there... >> > >I have only seen "forcing each do loop to execute at least once" as >a compiler option that is turned off by default. Do you remember which >compiler has this turned on. > >>So I answered my question first, it seems :-) Any comments? >> > >For no RLOs I use something like the following case.inso (depending on >details). The older style case.inso (WIEN2k_01) doesn't work sometimes, since >there is the new option of switching off SO for individual atoms. > >WFFIL > 4 1 0 llmax,ipr,kpot > -10.0000 5.00000 emin,emax (output energy window) > 0. 0. 1. direction of magnetization (lattice vectors) > 0 number of atoms for which RLO is added > 0 0 0 0 0 number of atoms for which SO is switch off;atoms > >Cheers, > >Fred > >>Torsten Andersen wrote: >> >>>==== >>>Torsten Andersen >>>submitted the following contribution: >>>==== >>> >>>Hello again, >>> >>>the symmetso problem was solved, thanks to Peter Blaha. >>> >>>Now a simple question about case.inso, since it has changed from >>>Wien2k_01 to Wien2k_02. >>> >>>If I don't want rlo's, do I have to delete "line 6"? In the old >>>case.inso it was just ignored, I think. In the new case.inso there is >>>a "line 7", however. If in "line 5" I have put a zero, what does the >>>program expect next, a single line 6 or no line 6, but line 7 in stead? >>> >>>Yes, I guess it could be read by sifting through the code, but I think >>>it should be clear in the manual... >>> >>>Best regards, >>>Torsten. >>> > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 16:18:04 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: Question about slab calculations ==== "Stefaan Cottenier" submitted the following contribution: ==== > I am attempting to carry out calculations on a 5-layer tantalum > slab periodic in the z-direction (please see attached struct file). > > For calculation of properties, I understand one needs to find the optimal > length of empty space in the unit cell as well as the optimal interlayer > spacing for the slab. > > WIEN offers 'mini' and the c/a and volume optimization combination for > structural optimization purposes. Which optimization feature is best > suited for the optimization of the slab interlayer spacing? > > Can the c/a and volume optimization combination be used to optimize the > amount of unit cell vacuum space? No, you're slightly on the wrong track here. A possible strategy could be : 1) Take a slab with atoms on the bulk positions, and (after having determined good Rkm and k-mesh) gradually increase the vacuum region. When you see that e.g. surface properties or the potential in the middle of the vacuum (directly printed in case.scf) do no change any more, then you have reached a good vacuum thickness. Keeping this vacuum constant, now repeat the procedure for the number of layers in the slab. Make it as thick as needed in order to avoid crosstalk between the two surfaces in your slab (again a good check would be whether moments, forces, efg's, hyperfine fields,... at the surface do not change when adding additional layers). 2) With this knowledge, use mini to find the optimized positions. You cannot use c/a optimization, as together with the vacuum thickness also the atomic positions would change (fractional coordinates, remember) Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Sep 2002 14:20:36 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Question about slab calculations ==== Neme Nnolim submitted the following contribution: ==== Thanks Stefaan. I will probably have more questions as I try your suggestions. Regards, Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Sep 2002 11:51:34 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: occupied bands ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks Peter, Torsten, Christian for you help! It is greatly appreciated! I am using Wien97.10, and when I look into the case.output2 file, I am told the number of electrons, and then half that number is the number of occupied bands (2 electrons to a band)... Is it the same case.output2 as Wien2k, as Peter was referring? None-the-less, I am in a better position now! Cheng Quoting Peter Blaha : > ==== > Peter Blaha > submitted the following contribution: > ==== > > > Can anyone tell me if there is a way in Wien to find out which bands are > > occupied (eg by the bandindex number)? > > > > As there are many bands that emerge from a bandstruct calc for slabs... > > > > Maybe a density of states calc would be helpful? > > > > Thanks for your time! > > Have a look into case.output2 (up/dn). At the top you find e-fermi, but > also the emin/emax of each band (ordered by bandindex), so that you > easily can judge how many bands are fully occupied and how many bands > cross EF. > > (The same info is also given in case.outputt (after tetra). > > Of course in a metallic situation you then must plot a bandstructure to > get more insight. > > Regards > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Sep 2002 12:47:46 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I got some problems while calculating JOINT(joint density of state). My problem is that WIEN always have the following error messages in file (.outputjoint). - ------ parameter INUME set too small! check paramter and band indices in *.injoint - ------ Then, I check back the file "param.inc" in directory "SRC_joint". And the file is ias below: - ------ Cb C .........PARAMETER INCLUDE FILE............. C PARAMETER(NKPT=2000) PARAMETER (NUME= 300) C PARAMETER(INUME=5000) PARAMETER(INUMEDEN=50) PARAMETER(MET=10000) PARAMETER(MG=9) PARAMETER(NSW=9) C..new struct + latgen PARAMETER (NATO= 10) PARAMETER (NDIF= 24) PARAMETER(NSYM= 48) C NATO MAX NUMBER OF INEQ: ATOMS C C NDIF MAX NUMBER OF ATOMPOSITION IN CELL C C NSYM MAX NUMBER OF SYM-OPERATION C C NUME MAX NUMBER OF EIGENVALUES PER K - POINT C C INUME MAX NUMBER OF BANDCOMBINATIONS nume*(nume+1)/2 C C INUMEden MAX NUMBER OF BANDCOMBINATIONS for band analysis C C MET MAXIMUM FOR ENERGYMESH C C MG MAXIMUM NUMBER OF SPECTRA c (polarizations: see input case.inop) C C NSW NUMBER OF SWITCHCODES fixed! C C....special: not used in standart application PARAMETER (NEKPT=5) PARAMETER (NUMTETR= 6) C NEKPT NUMBER OF NOT EQUIVALENT K_POINTS fixed! C C NUMTETR NUMBER OF TETRAEDERS fixed! - ------ Then, I tried to change "INUME" from 5000 to 45150{300*(300+1)/2}, 10000, 8000. However, I can't compile it. And then, I tried 6000 and it could be compiled but the same error message appears when I run the program. Why? What value should I use? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Sep 2002 08:40:31 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: occupied bands ==== Peter Blaha submitted the following contribution: ==== > I am using Wien97.10, and when I look into the case.output2 file, > I am told the number of electrons, and then half that number is the number of > occupied bands (2 electrons to a band)... > > Is it the same case.output2 as Wien2k, as Peter was referring? Sorry, what I described is only in case.output2 of WIEN2k. You find the same info in case.outputt. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Sep 2002 08:45:56 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: ==== Peter Blaha submitted the following contribution: ==== INUME was very difficult to set in WIEN97 and made the program easily very big (even several GB). Try to set INUME using the actual number of bands in your case (check the output of optic) and not simply the value of parameter NUME. WIEN2k should be easier to use! > I got some problems while calculating JOINT(joint density of state). My > problem is that WIEN always have the following error messages in file > (.outputjoint). > ------ > parameter INUME set too small! > check paramter and band indices in *.injoint > C > Then, I tried to change "INUME" from 5000 to 45150{300*(300+1)/2}, 10000, 8000. > However, I can't compile it. And then, I tried 6000 and it could be > compiled but the same error message appears when I run the program. Why? > What value should I use? 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Sep 2002 18:03:11 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, Can anyone tell me what exactly the input file ".injoint" for JDOS calculation is? The reason is that I got nearly all elements in the files ".Im_eps_zz_*" equal 0. The input file (.injoint) being used is as below: - ------ 36 44 : LOWER AND UPPER BANDINDEX -5.0000 0.00010 2.2000 : EMIN DE EMAX FOR ENERGYGRID IN ryd eV : output units eV / ryd / cm-1 5 : SWITCH 1 : NUMBER OF COLUMNS 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - ONLY) SWITCH: 0...JOINTDOS FOR EACH BAND COMBINATION 1...JOINTDOS AS SUM OVER ALL BAND COMBINATIONS 2...DOS FOR EACH BAND 3...DOS AS SUM OVER ALL BANDS 4...Im(EPSILON) 5...Im(EPSILON) for each band combination 6...INTRABAND contributions 7...INTRABAND contributions including band analysis - ------ Is there anything wrong for my input file? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 16:01:30 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: density of states for occupied states ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, I was wondering if there is a possible way to calculate the DOS for occupied states? Thanks for you time! Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #36 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #37 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, October 3 2002 Volume 2002 : Number 037 ---------------------------------------------------------------------- Date: Thu, 26 Sep 2002 16:07:13 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: DOS for occupied bands... ==== chen0130@flinders.edu.au submitted the following contribution: ==== Sorry, I do believe states below the fermi energy are occupied by definition? Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 08:21:23 +0200 From: Torsten Andersen Subject: Re: [WIEN]: DOS for occupied bands... ==== Torsten Andersen submitted the following contribution: ==== Yeah, you are right... so you get it simply by cutting your DOS figure at the Fermi energy :-) Have fun, Torsten. chen0130@flinders.edu.au wrote: >==== >chen0130@flinders.edu.au >submitted the following contribution: >==== > >Sorry, > >I do believe states below the fermi energy are occupied by definition? > >Cheng > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 08:34:35 +0200 From: Claudia Ambrosch-Draxl Subject: Re: [WIEN]: ==== Claudia Ambrosch-Draxl submitted the following contribution: ==== Ma Chi Chiu wrote: > > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Hi, > > Can anyone tell me what exactly the input file ".injoint" for JDOS calculation is? > The reason is that I got nearly all elements in the files ".Im_eps_zz_*" equal 0. > > The input file (.injoint) being used is as below: > ------ > 36 44 : LOWER AND UPPER BANDINDEX > -5.0000 0.00010 2.2000 : EMIN DE EMAX FOR ENERGYGRID IN ryd > eV : output units eV / ryd / cm-1 > 5 : SWITCH > 1 : NUMBER OF COLUMNS > 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - > ONLY) You are searching for transitions between band 36 and 44 only! Make sure that you include transitions from occupied bands to empty states. Regards, Claudia Ambrosch-Draxl Institut f. Theoretische Physik, University Graz Universitaetsplatz 5, A-8010 Graz Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 http://physik.uni-graz.at/~cad ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 08:57:30 +0200 From: Torsten Andersen Subject: Re: [WIEN]: ==== Torsten Andersen submitted the following contribution: ==== If I may add to that... in general you should include at least all the bands within the energy window in order to get something representative for your system. Limiting the number of bands (I believe) can be used to study the transitions in greater detail (e.g., to find out whether the response from transitions between two specific bands is dominating all other responses), as well as giving you faster results. Best regards, Torsten. Claudia Ambrosch-Draxl wrote: >==== >Claudia Ambrosch-Draxl >submitted the following contribution: >==== > >Ma Chi Chiu wrote: > >>==== >>Ma Chi Chiu >>submitted the following contribution: >>==== >> >>Hi, >> >>Can anyone tell me what exactly the input file ".injoint" for JDOS calculation is? >>The reason is that I got nearly all elements in the files ".Im_eps_zz_*" equal 0. >> >>The input file (.injoint) being used is as below: >>------ >> 36 44 : LOWER AND UPPER BANDINDEX >> -5.0000 0.00010 2.2000 : EMIN DE EMAX FOR ENERGYGRID IN ryd >>eV : output units eV / ryd / cm-1 >> 5 : SWITCH >> 1 : NUMBER OF COLUMNS >> 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - >>ONLY) >> > >You are searching for transitions between band 36 and 44 only! Make sure >that you include transitions from occupied bands to empty states. > >Regards, >Claudia Ambrosch-Draxl > >Institut f. Theoretische Physik, University Graz >Universitaetsplatz 5, A-8010 Graz >Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 >http://physik.uni-graz.at/~cad >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 16:57:40 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I am wondering whether I should calculate the optical properties before or after bandstructre calculation? It is beacuse I have tried to calculate the optical properties two time. The first trial is calulating the optical properties directly after SCF calculation and the second trial is calculating the optical properties after density of states and bandstructure calculations. Then, I found the content in the file .outputjoint are different and certainly the plot for joint DOS are different, too. Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 11:48:56 +0200 From: Torsten Andersen Subject: Re: [WIEN]: ==== Torsten Andersen submitted the following contribution: ==== After the scf cycle, if you calculate band structures you have changed your case.vector file, and you will need to execute lapw1 with the original k-mesh (not the band structure mesh) in order to get a good optics result. Then the result should also be the same as if you calculate the optics first and the bandstructure afterwards. Best regards, Torsten. Ma Chi Chiu wrote: >==== >Ma Chi Chiu >submitted the following contribution: >==== > >Dear all, > >I am wondering whether I should calculate the optical properties >before or after bandstructre calculation? >It is beacuse I have tried to calculate the optical properties two time. >The first trial is calulating the optical properties directly after SCF >calculation and the second trial is calculating the optical properties after >density of states and bandstructure calculations. Then, I found the >content in the file .outputjoint are different and certainly the plot for >joint DOS are different, too. > >Thank you very much > >Martin > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 18:39:26 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I would like to consult about the definition od physical meaning of several terms in the file ".inop". Below is file ".inop" - ------ 1200 1 number of k-points, first k-point - -5.0 2.2 Emin, Emax for matrix elements 9 number of choices (columns in *outmat) 1 Re xx 2 Re yy 3 Re zz 4 Re xy 5 Re xz 6 Re yz 7 Im xy 8 Im xz 9 Im yz Choices: 1......Re 2......Re 3......Re 4......Re 5......Re 6......Re 7......Im 8......Im 9......Im - ------ The terms that I am not really understand are : 1. Emin for matrix elements 2. Emax for matrix elements How will this two terms affect the JDOS plot? Also, for the file ".injoint" - ------ 30 50 : LOWER AND UPPER BANDINDEX 0.0000 0.00010 1.0000 : EMIN DE EMAX FOR ENERGYGRID IN ryd eV : output units eV / ryd / cm-1 5 : SWITCH 9 : NUMBER OF COLUMNS 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - ONLY) SWITCH: 0...JOINTDOS FOR EACH BAND COMBINATION 1...JOINTDOS AS SUM OVER ALL BAND COMBINATIONS 2...DOS FOR EACH BAND 3...DOS AS SUM OVER ALL BANDS 4...Im(EPSILON) 5...Im(EPSILON) for each band combination 6...INTRABAND contributions 7...INTRABAND contributions including band analysis - ------ How will the below terms affect the JDOS plot? Do they just govern the x-axis of the plot? Terms : "EMIN" "DE" "EMAX" Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 13:34:48 +0200 From: Claudia Ambrosch-Draxl Subject: Re: [WIEN]: ==== Claudia Ambrosch-Draxl submitted the following contribution: ==== Ma Chi Chiu wrote: > > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > I am wondering whether I should calculate the optical properties > before or after bandstructre calculation? > It is beacuse I have tried to calculate the optical properties two time. > The first trial is calulating the optical properties directly after SCF > calculation and the second trial is calculating the optical properties after > density of states and bandstructure calculations. Then, I found the > content in the file .outputjoint are different and certainly the plot for > joint DOS are different, too. > The different results may have to do wih the fact that you did not use a dense enough k-point mesh for the optical properties. It seems that you have used two different meshes for the SCF cycle and the DOS, repsectively, and that you have used these meshes for the optical spectra. Right? Anyway, you should use a much denser grid for calculating the optical spectra than for the SCF cycle. Such a grid can only be a starting point for checking the k-point convergence with respect to the optical spectra and usually does not give reliable results. A band structure mesh is not uniform and cannot not work at all since in joint we use the tetrahedron method for the BZ integrations which requires the case.klist + case.kgen files. Best regards, Claudia Ambrosch-Draxl Institut f. Theoretische Physik, University Graz Universitaetsplatz 5, A-8010 Graz Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 http://physik.uni-graz.at/~cad ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 00:05:37 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]:Optical properties ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Firstly, thank for the explaination from Claudia Ambrosch-Draxl and Torsten Andersen. However, I don't know how to have a denser k-mesh point. Actually, I inputed 20 for the number of k-point during SCF but WIEN automatically change it to 4 and the bandstructure looks okay. Is it I need to run kgen again with a large value of k-point for optical properties' calculation? Thank you very much Martin On Thu, 26 Sep 2002, Claudia Ambrosch-Draxl wrote: > ==== > Claudia Ambrosch-Draxl > submitted the following contribution: > ==== > > Ma Chi Chiu wrote: > > > > ==== > > Ma Chi Chiu > > submitted the following contribution: > > ==== > > > > Dear all, > > > > I am wondering whether I should calculate the optical properties > > before or after bandstructre calculation? > > It is beacuse I have tried to calculate the optical properties two time. > > The first trial is calulating the optical properties directly after SCF > > calculation and the second trial is calculating the optical properties after > > density of states and bandstructure calculations. Then, I found the > > content in the file .outputjoint are different and certainly the plot for > > joint DOS are different, too. > > > > The different results may have to do wih the fact that you did not use a > dense enough k-point mesh for the optical properties. It seems that you > have used two different meshes for the SCF cycle and the DOS, > repsectively, and that you have used these meshes for the optical > spectra. Right? > Anyway, you should use a much denser grid for calculating the optical > spectra than for the SCF cycle. Such a grid can only be a starting point > for checking the k-point convergence with respect to the optical spectra > and usually does not give reliable results. > A band structure mesh is not uniform and cannot not work at all since in > joint we use the tetrahedron method for the BZ integrations which > requires the case.klist + case.kgen files. > > Best regards, > Claudia Ambrosch-Draxl > > Institut f. Theoretische Physik, University Graz > Universitaetsplatz 5, A-8010 Graz > Tel. [43] (316) 380-5235 Fax [43] (316) 380-9820 > http://physik.uni-graz.at/~cad > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Sep 2002 18:14:24 +0200 From: Torsten Andersen Subject: Re: [WIEN]:Optical properties ==== Torsten Andersen submitted the following contribution: ==== You need "a fair amount" of k-points, and then to run at least lapw1 again to create the corresponding output files. As the number cannot be given as a general rule, you can start with a few hundred, and increase the number until you reach convergence in the optical spectrum, but expect to use thousands of k-points for that. Best regards, Torsten Andersen. Ma Chi Chiu wrote: >==== >Ma Chi Chiu >submitted the following contribution: >==== > >Dear all, > >Firstly, thank for the explaination from Claudia Ambrosch-Draxl and >Torsten Andersen. However, I don't know how to have a denser k-mesh point. >Actually, I inputed 20 for the number of k-point during SCF but WIEN >automatically change it to 4 and the bandstructure looks okay. Is it I >need to run kgen again with a large value of k-point for optical >properties' calculation? > >Thank you very much > >Martin > >On Thu, 26 Sep 2002, Claudia Ambrosch-Draxl wrote: > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 12:10:22 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: DOS matching bandstructures... ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear wien users, I am studying a simple case of solid Li2O. My bandstructure reveals bands at 0 to -5 eV (O 2p), -15 eV and -45 eV... then I changed the k mesh back to the original, run a single SCF cycle, to ensure lapw1 is done, and do the DOS... but it only has peaks at around -5 eV (ignoring above E_fermi) i also tried setting a fresh case and doing the DOS only after the SCF... i am puzzled, I really expect peaks in the DOS to correspond to the bands at those energies... can someone tell me possible errors, hints from their experiences? thanks for you time! Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 08:10:07 +0200 From: Torsten Andersen Subject: Re: [WIEN]: DOS matching bandstructures... ==== Torsten Andersen submitted the following contribution: ==== So you are calculating DOS and band structure from two different k-meshes. I am not so surprised you get different results. Of course, ideally, if your band structure is representative, you should see at least a fingerprint of it in the DOS. Have you tried to calculate the DOS with the results from the band structure, just to check how it looks compared to what you expect? If that looks like you think it should from the band structure, you could try other paths through the Brillouin Zone (BZ) for the band structure and see if that is a better representative. Remember that the band structure is only along specific paths in the BZ and are not by nature representative for the DOS. Another thing you could do to see the fingerprint of the "missing" feature, is to zoom on the scale in the DOS. In gnuplot you can do that by "set yrange [0:0.1]" or similar. Okay, it may be too general a comment... so if somebody has specific experiences... Best regards, Torsten Andersen. chen0130@flinders.edu.au wrote: >==== >chen0130@flinders.edu.au >submitted the following contribution: >==== > >Dear wien users, > >I am studying a simple case of solid Li2O. > >My bandstructure reveals bands at 0 to -5 eV (O 2p), -15 eV and -45 eV... > >then I changed the k mesh back to the original, run a single SCF cycle, to >ensure lapw1 is done, > >and do the DOS... but it only has peaks at around -5 eV (ignoring above E_fermi) > >i also tried setting a fresh case and doing the DOS only after the SCF... > >i am puzzled, I really expect peaks in the DOS to correspond to the bands at >those energies... > >can someone tell me possible errors, hints from their experiences? > >thanks for you time! > >Cheng > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 09:38:17 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: DOS matching bandstructures... ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0015_01C26609.9BF15B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I am studying a simple case of solid Li2O.=20 >=20 > My bandstructure reveals bands at 0 to -5 eV (O 2p), -15 eV and -45 = eV... =20 > then I changed the k mesh back to the original, run a single SCF = cycle, to > ensure lapw1 is done, That is okay, but when you want to calculate DOS after the = bandstructure, you only need to run lapw1 with the original case.in1 = file to make sure about proper case.vector(s). > and do the DOS... but it only has peaks at around -5 eV (ignoring = above E_fermi) >=20 > i also tried setting a fresh case and doing the DOS only after the = SCF... =20 That is okay (making strongly sure), but time consuming. > i am puzzled, I really expect peaks in the DOS to correspond to the = bands at > those energies... =20 You are right, there should be such a correspondence between DOS and = band character plotting. =20 > can someone tell me possible errors, hints from their experiences? =20 If you would see DOS's from -45eV, change Emin of case.int file to = - -45/13.6~-3.4Ry, and then run tetra. =20 Your, S. Jalali. - ------=_NextPart_000_0015_01C26609.9BF15B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> I am studying a = simple case of=20 solid Li2O.
>
> My bandstructure reveals bands at 0 to -5 = eV (O=20 2p), -15 eV and -45 eV...
 
> then I changed the k mesh = back to=20 the original, run a single SCF cycle, to
> ensure lapw1 is=20 done,

 

That is okay, but when you = want to=20 calculate DOS after the bandstructure, = you only need to run=20 lapw1 with the original case.in1 file to make sure about proper=20 case.vector(s).


> and do the DOS... = but it=20 only has peaks at around -5 eV (ignoring above E_fermi)
>
> = i also=20 tried setting a fresh case and doing the DOS only after the=20 SCF...

 

That is okay (making = strongly sure),=20 but time consuming.

> i am puzzled, I really expect peaks in = the DOS=20 to correspond to the bands at
> those=20 energies...
 

You are right, there = should be such=20 a correspondence between DOS and band character = plotting.

 

> can someone tell me = possible=20 errors, hints from their experiences?

 

If you would see = DOS's from=20 - -45eV, change Emin of case.int file to -45/13.6~-3.4Ry, and then run=20 tetra.

 

Your,

S.=20 Jalali.

- ------=_NextPart_000_0015_01C26609.9BF15B20-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 09:56:30 +0200 From: Torsten Andersen Subject: [WIEN]: Questions about "mini" vs. "optimize" ==== Torsten Andersen submitted the following contribution: ==== Dear All, since I am a newbie to "mini", I am afraid I have to ask a few questions, although there is a FAQ on the subject. I am aware that "mini" uses a scheme to create a new struct file where some internal parameters have been optimized according to "case.inM". My question is then: If I have only one parameter I want to optimize, is there any speed advantage in using "mini" compared to doing a "optimize"-like scheme where one changes that internal parameter in the struct file, run it again with force convergence, and so on... in that case I would be able to make a number of changes to the struct file and run each of the struct files through run_lapw in parallel, and I would assume that I get data in the scf-file for the forces that I then could plot as a function of the change of the internal parameter. If "mini" is really running a "run_lapw" for each change of the internal parameter I am afraid I will get very old before it finishes, if I have to run it in serial. Am I missing something? Best regards, Torsten Andersen. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 14:00:11 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== "Stefaan Cottenier" submitted the following contribution: ==== > If I have only one parameter I want to optimize, is there any speed > advantage in using "mini" compared to doing a "optimize"-like scheme > where one changes that internal parameter in the struct file, run it > again with force convergence, and so on... in that case I would be able > to make a number of changes to the struct file and run each of the > struct files through run_lapw in parallel, and I would assume that I get > data in the scf-file for the forces that I then could plot as a function > of the change of the internal parameter. Yes, this is usually more efficient than mini, as you can learn from the first results and quickly go to the minimum. > If "mini" is really running a "run_lapw" for each change of the internal > parameter I am afraid I will get very old before it finishes, if I have > to run it in serial. Unfortunately, you are right. According to my experience, this is the real bottleneck now in first principles calculations. If your property is sensitive to the correct internal coordinates (impurities, surfaces, phase boundaries,...) then you are spending 95% of your cpu time to obtaining the correct internal coordinates. And only then you can start to do physics. Maybe this is an occasion to put a more general question to the mailing list: what are all of you doing to cope with this problem? Do you have experience with codes that can in an efficient way relax complicated structures? They need not to be that accurate as LAPW, in many cases it would be very helpful to have a rough but quick estimate before one starts mini. Best regards, Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 14:21:13 -0200 (DFT) From: Frederic Lemoigno Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Frederic Lemoigno submitted the following contribution: ==== Hi Stefaan, If you're looking for a quick, low memory ab initio code for relaxing (3D) structures, have a try with SIESTA: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/ The first version is freely available. Yours F. Lemoigno > > ==== > "Stefaan Cottenier" > submitted the following contribution: > ==== > . . . > > Unfortunately, you are right. According to my experience, this is the real > bottleneck now in first principles calculations. If your property is > sensitive to the correct internal coordinates (impurities, surfaces, phase > boundaries,...) then you are spending 95% of your cpu time to obtaining the > correct internal coordinates. And only then you can start to do physics. > Maybe this is an occasion to put a more general question to the mailing > list: what are all of you doing to cope with this problem? Do you have > experience with codes that can in an efficient way relax complicated > structures? They need not to be that accurate as LAPW, in many cases it > would be very helpful to have a rough but quick estimate before one starts > mini. > > Best regards, > Stefaan > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 15:06:03 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Torsten Andersen submitted the following contribution: ==== Hi Stefaan, thank you for the very informative answer! there is possibly the "other Wien-code" VASP, but that is provided that good pseudopotentials exist...which is not the case for all the structures we like to consider. Best regards, Torsten. Stefaan Cottenier wrote: >==== >"Stefaan Cottenier" >submitted the following contribution: >==== > >>If I have only one parameter I want to optimize, is there any speed >>advantage in using "mini" compared to doing a "optimize"-like scheme >>where one changes that internal parameter in the struct file, run it >>again with force convergence, and so on... in that case I would be able >>to make a number of changes to the struct file and run each of the >>struct files through run_lapw in parallel, and I would assume that I get >>data in the scf-file for the forces that I then could plot as a function >>of the change of the internal parameter. >> > >Yes, this is usually more efficient than mini, as you can learn from the >first results and quickly go to the minimum. > >>If "mini" is really running a "run_lapw" for each change of the internal >>parameter I am afraid I will get very old before it finishes, if I have >>to run it in serial. >> > >Unfortunately, you are right. According to my experience, this is the real >bottleneck now in first principles calculations. If your property is >sensitive to the correct internal coordinates (impurities, surfaces, phase >boundaries,...) then you are spending 95% of your cpu time to obtaining the >correct internal coordinates. And only then you can start to do physics. >Maybe this is an occasion to put a more general question to the mailing >list: what are all of you doing to cope with this problem? Do you have >experience with codes that can in an efficient way relax complicated >structures? They need not to be that accurate as LAPW, in many cases it >would be very helpful to have a rough but quick estimate before one starts >mini. > >Best regards, >Stefaan > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 22:16:28 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I would like to consult about the bandstructure calculation. My question is as below: In chapter three of User's Guide, it tells us to append the appropriate template to the .in1 file and change the entry "K-point from unit" 4 to 5. In the sample "TiC", it is asked to use $WIENROOT/SRC_templates/fcc.klist. And now, I am using a simple cubic lattice and is it I can just append $WIENROOT/SRC_templates/simple_cubic.klist to .in1 file? And what is the relationship between the simple_cubic.klist and my own .klist file? Thank you very much Martin - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 17:23:05 +0200 From: "koitzsch" Subject: [WIEN]: Re: ma chi chiu ==== "koitzsch" submitted the following contribution: ==== Hi, Oh, it just depends, what directions you are interested in. These sample klists are just paths in k-space into some conventional Brillouin zone directions. In principal you can give any k-point and evaluate the eigenvalues at that specific k-point. If you are e.g. interested in the dispersion along one specific direction you can either hope that this direction is included in the sample klists provided, or you can make just any path in k-space by using XCrysDen. XcrysDen produces number triples, which yield if multiplied by conventional reciprocal lattice vectors, the appropriate k-point. (you can even calculate this by hand and include a conventional spreadsheet text file) Maybe to give you a physical example: if you calculate graphite and you are interested in the dispersion perpendicular to the graphite sheats, you generate a k-list along the hexagonal c-axis (reciprocal space) starting from Gamma (0,0,0) to the Brillouin zone boundary (0,0,1) and you make sth. like 200 points in between. The difference to case.klist is that the k-list for band structure calculations is along high symmetry directions, while the case.klist for an scf cycle sort-of samples the irreducible Brillouin zone homogenously. In simple words: there is nothing you can learn out of the change in eigenvalues if you go from one point in this case.klist to the next point.. Hope, this helps a little bit Christian Koitzsch - ----- Original Message ----- From: "Ma Chi Chiu" To: Sent: Friday, September 27, 2002 4:16 PM Subject: [WIEN]: > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > I would like to consult about the bandstructure calculation. My question > is as below: > > In chapter three of User's Guide, it tells us to append the appropriate > template to the .in1 file and change the entry "K-point from unit" 4 to 5. > In the sample "TiC", it is asked to use $WIENROOT/SRC_templates/fcc.klist. > > And now, I am using a simple cubic lattice and is it I can just append > $WIENROOT/SRC_templates/simple_cubic.klist to .in1 file? And what is the > relationship between the simple_cubic.klist and my own .klist file? > > Thank you very much > > Martin > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~ "Here is your country, do not let anyone take its glory away ~~ > ~~ from you. Do not let selfish men or greedy interests skin ~~ > ~~ your country of its beauty, its riches, or its romance. The ~~ > ~~ world and the future and your very children shall judge you ~~ > ~~ according to the way you deal with this sacred trust." ~~ > ~~ ~~ > ~~ ~~ > ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 17:22:27 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Peter Blaha submitted the following contribution: ==== > > If I have only one parameter I want to optimize, is there any speed > > advantage in using "mini" compared to doing a "optimize"-like scheme > > where one changes that internal parameter in the struct file, run it > > again with force convergence, and so on... in that case I would be able > > to make a number of changes to the struct file and run each of the > > struct files through run_lapw in parallel, and I would assume that I get > > data in the scf-file for the forces that I then could plot as a function > > of the change of the internal parameter. > > Yes, this is usually more efficient than mini, as you can learn from the > first results and quickly go to the minimum. If you have just one parameter AND it follows a linear relationship for the force/position (or, equivalently, follows a parabolic energy vs. pos behaviour), then this is such a trivial case that you most likely are better off doing it by hand. (You can do 2 geometries sequential and calculate from this the F=0 geometry). Alternatively the BROYD scheme in case.inM should also be very effective, while NEWT may converge slowly with unfortunate parameters. If your potential energy is anharmonic,..... bad luck. > > If "mini" is really running a "run_lapw" for each change of the internal > > parameter I am afraid I will get very old before it finishes, if I have > > to run it in serial. Well, the idea would be to use the k-point parallelism, not doing the structures in parallel, but see above... Or maybe you do Project 1 on computer one and project 2 on computer 2,... > Unfortunately, you are right. According to my experience, this is the real > bottleneck now in first principles calculations. If your property is > sensitive to the correct internal coordinates (impurities, surfaces, phase > boundaries,...) then you are spending 95% of your cpu time to obtaining the > correct internal coordinates. And only then you can start to do physics. > Maybe this is an occasion to put a more general question to the mailing > list: what are all of you doing to cope with this problem? Do you have > experience with codes that can in an efficient way relax complicated > structures? They need not to be that accurate as LAPW, in many cases it > would be very helpful to have a rough but quick estimate before one starts > mini. In 90% of all electronic structure papers nowadays a structure relaxation has been performed. Of course it is true, that this may take quite a long time, since this is nothing than a long series of sequential scf calculations. Yes, there are many other programs available, SIESTA and VASP was already mentioned before. For a partiular class of compounds these programs can be highly efficient and much faster than WIEN (e.i. with SIESTA they have simulated biomolecules with 1000s !! of atoms). However, most of those programs are NOT applicable to all systems. Try SIESTA for metals and I doubt that you can do more than WIEN can do, and in addition most likely the results will also be WRONG. To use such programs, you probably need to be much more experienced than when using WIEN. I disagree with the statement: > They need not to be that accurate as LAPW, in many cases it > would be very helpful to have a rough but quick estimate before one starts > mini. They might even go into the wrong direction!! then you are better off to start with your estimated (or exp.) structure (and use a very small k-mesh at the beginning) I must admit that WIEN could be significantly improved with respect to structural relaxations. Mainly 2 points would be important: a) Better usage of the charge density of the previous geometry, so that one does not need so many scf cycles for the subsequent geometry steps. We have some ideas about that, but no manpower. b) The implemented NEWT algorithm for relaxation is quite stupid! You have to select proper "timestep"-factors in the input and the handling is clumsy. Also here many improvements (for both the NEWT scheme, but also other schemes like conjg gradients) are waiting. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Sep 2002 18:23:50 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Torsten Andersen submitted the following contribution: ==== Dear Peter and Stefaan, thank you for these very interesting and deep answers! It confirmed to me that it is a difficult and potentially long-lasting task, but also revealed a great deal of insight into the process. As usual, I am setting up a slab calculation in order to try to optimize a metal surface with an overlayer of another metal. Thus, based on your answers, I have decided to use a little bit of two worlds (the "optimize"-like scheme and VASP separately, and if the latter gives a reasonable output it will be followed by another, but finer, "optimize"-like scheme to test and possibly fine-tune the result), in order to test how easy or difficult it is to find something useful. I pretty much know the positions of the atoms in two dimensions from experiment, but there are no experimental results on the third dimension, as far as I can tell by sifting through the literature. The "bulk" material does not change very much at the surface, so to a first approximation it is a question of getting the overlayer distance to the "bulk" determined. Unfortunately, at the moment I am confined to do parallelisation on the scf-cycle level, since each CPU has its own place in the queueing system. Yes, I can play with channels in the queueing system, but that would require thousands of k-points to be of any use (and a queue-tuned run_lapw, which is possible to write, but clumsy). Best regards, Torsten. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 00:58:42 +0800 From: "yulihua-wuhan" Subject: [none] ==== "yulihua-wuhan" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_000F_01C2668A.30CA4EC0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBXaWVuMmsgVXNlcnMgYW5kIGRldmVsb3BlcnM6DQoNCiAgIEkgaGF2ZSBjYWxjdWxhdGVk IHRoZSBjb21wb3VuZCBYMllPMiBiYW5kIHN0cnVjdHVyZSxhbmQgZmluZCBzb21lIGJhbmRzIGFy ZSBhbG1vc3Qgb25seSANCnJlbGF0ZWQgdG8gUyBvcmJpdGFsIG9mIE8tYXRvbSAsYW5kIHdoZW4g SSBwbG90IHRoZSBET1MgY3VydmVzLEkgZmluZCB0aGF0IHRoZSBPIHRvdGFsIERPUyBpcyANCmRv dWJsZSBhcyB0aGUgTy1hdG9tIFMgcGFydGlhbCBET1MgYXQgdGhlIGNvcnJlc3BvbmRpbmcgZW5l cmd5IHJhbmdlIGZvciB0aG9zZSBiYW5kcyxzbyBJIHRoaW5rIA0KdGhlIERPUyB1bml0IGlzIHN0 YXRlcy9lVi9hdG9tIGZvciBhdG9tIHBhcnRpYWwgRE9TLHN0YXRlcy9lVi9jaGVtaXN0cnkgZm9y bXVsYSgyIE8gYXRvbXMpIGZvciANCmF0b20gdG90YWwgRE9TLGFuZCBzdGF0ZXMvZVYvY2hlbWlz dHJ5IGZvcm11bGEgZm9yIHRvdGFsIERPUyhhbGwgYXRvbXMgaW4gdGhlIGNvbXBvdW5kKS4gICBB bSBJIA0KcmlnaHQ/DQoNCiAgIEJ1dCB0aGlzIGNvbXBvdW5kIGhhcyAyIGZvcm11bGEgdW5pdHMg cGVyIGNlbGwsIHNvIG1heWJlIHdlIGhhdmUgYW5vdGhlciBjaG9pY2U6DQogICBmb3IgaW5zdGFu Y2UgTyBhdG9tIGluIHRoaXMgY29tcG91bmQgDQogICBzdGF0ZXMvZVYvKDIgYXRvbSkgZm9yIGF0 b20gcGFydGlhbCBET1MsDQogICBzdGF0ZXMvZVYvY2VsbCBmb3IgYXRvbSB0b3RhbCBET1MsDQog ICBzdGF0ZXMvZVYvY2VsbCBmb3IgdG90YWwgRE9TKGFsbCBhdG9tcyBpbiB0aGUgY29tcG91bmQp Lg0KDQogICBJIGd1ZXNzIHNvbWUgYW5zd2VycyBhYm92ZSwgdGhlIGFuc3dlciBzaG91bGQgYmUg ZGVmaW5pdGUuIEkgd2FudCB0byBhc2sgdGhlIERPUyB1bml0cy4NCg0KICAgVGhhbmsgeW91IHZl cnkgbXVjaCANCg0KDQo= - ------=_NextPart_000_000F_01C2668A.30CA4EC0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkRlYXIgV2llbjJrIFVzZXJzIGFuZCBkZXZlbG9wZXJzOjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7Jm5ic3A7IEkgaGF2ZSBjYWxjdWxh dGVkIHRoZSBjb21wb3VuZCANClgyWU8yIGJhbmQgc3RydWN0dXJlLGFuZCBmaW5kIHNvbWUgYmFu ZHMgYXJlIGFsbW9zdCBvbmx5IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5yZWxhdGVkIHRvIFMgb3JiaXRhbCBvZiBPLWF0b20gLGFuZCB3aGVuIEkgDQpw bG90IHRoZSBET1MgY3VydmVzLEkgZmluZCB0aGF0IHRoZSBPIHRvdGFsIERPUyBpcyA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ZG91YmxlIGFzIHRoZSBP LWF0b20gUyBwYXJ0aWFsIERPUyBhdCB0aGUgDQpjb3JyZXNwb25kaW5nIGVuZXJneSByYW5nZSBm b3IgdGhvc2UgYmFuZHMsc28gSSB0aGluayA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+dGhlIERPUyB1bml0IGlzIHN0YXRlcy9lVi9hdG9tIGZvciBhdG9t IA0KcGFydGlhbCBET1Msc3RhdGVzL2VWL2NoZW1pc3RyeSBmb3JtdWxhKDIgTyBhdG9tcykgZm9y IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5hdG9tIHRv dGFsIERPUyxhbmQgc3RhdGVzL2VWL2NoZW1pc3RyeSBmb3JtdWxhIA0KZm9yIHRvdGFsIERPUyhh bGwgYXRvbXMgaW4gdGhlIGNvbXBvdW5kKS4mbmJzcDsmbmJzcDsgQW0gSSA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+cmlnaHQ/PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsmbmJzcDsgQnV0IHRoaXMgY29t cG91bmQgaGFzIDIgZm9ybXVsYSANCnVuaXRzIHBlciBjZWxsLCBzbyBtYXliZSB3ZSBoYXZlIGFu b3RoZXIgY2hvaWNlOjxCUj4mbmJzcDsmbmJzcDsgZm9yIGluc3RhbmNlIE8gDQphdG9tIGluIHRo aXMgY29tcG91bmQgPEJSPiZuYnNwOyZuYnNwOyBzdGF0ZXMvZVYvKDIgYXRvbSkgZm9yIGF0b20g cGFydGlhbCANCkRPUyw8QlI+Jm5ic3A7Jm5ic3A7IHN0YXRlcy9lVi9jZWxsIGZvciBhdG9tIHRv dGFsIERPUyw8QlI+Jm5ic3A7Jm5ic3A7IA0Kc3RhdGVzL2VWL2NlbGwgZm9yIHRvdGFsIERPUyhh bGwgYXRvbXMgaW4gdGhlIGNvbXBvdW5kKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiZuYnNwOyZuYnNwOyBJIGd1ZXNzIHNvbWUgYW5zd2VycyBhYm92ZSwg dGhlIA0KYW5zd2VyIHNob3VsZCBiZSBkZWZpbml0ZS4gSSB3YW50IHRvIGFzayB0aGUgRE9TIHVu aXRzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 Jm5ic3A7IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== - ------=_NextPart_000_000F_01C2668A.30CA4EC0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 09:10:15 +0330 From: "Saeid Jalali" Subject: [WIEN]: Re: ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_004D_01C266CE.DB7CF1D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I suggest looking for recent e-mails with the subject of "Partial = DOS/Tetra". Your, S. Jalali. ----- Original Message -----=20 From: yulihua-wuhan=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Friday, September 27, 2002 8:28 PM Dear Wien2k Users and developers: I have calculated the compound X2YO2 band structure,and find some = bands are almost only=20 related to S orbital of O-atom ,and when I plot the DOS curves,I find = that the O total DOS is=20 double as the O-atom S partial DOS at the corresponding energy range = for those bands,so I think=20 the DOS unit is states/eV/atom for atom partial = DOS,states/eV/chemistry formula(2 O atoms) for=20 atom total DOS,and states/eV/chemistry formula for total DOS(all atoms = in the compound). Am I=20 right? But this compound has 2 formula units per cell, so maybe we have = another choice: for instance O atom in this compound=20 states/eV/(2 atom) for atom partial DOS, states/eV/cell for atom total DOS, states/eV/cell for total DOS(all atoms in the compound). I guess some answers above, the answer should be definite. I want = to ask the DOS units. Thank you very much=20 - ------=_NextPart_000_004D_01C266CE.DB7CF1D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I suggest looking for recent e-mails = with the=20 subject of "Partial DOS/Tetra".
Your,
S. Jalali.
----- Original Message -----
From:=20 yulihua-wuhan
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Friday, September 27, = 2002 8:28=20 PM

Dear Wien2k Users and=20 developers:
 
   I have calculated the = compound=20 X2YO2 band structure,and find some bands are almost only
related to S orbital of O-atom = ,and when I=20 plot the DOS curves,I find that the O total DOS is
double as the O-atom S partial DOS = at the=20 corresponding energy range for those bands,so I think
the DOS unit is states/eV/atom for = atom=20 partial DOS,states/eV/chemistry formula(2 O atoms) for
atom total DOS,and = states/eV/chemistry=20 formula for total DOS(all atoms in the compound).   Am I=20
right?
 
   But this compound has = 2 formula=20 units per cell, so maybe we have another choice:
   for = instance=20 O atom in this compound
   states/eV/(2 atom) for atom = partial=20 DOS,
   states/eV/cell for atom total = DOS,
  =20 states/eV/cell for total DOS(all atoms in the compound).
 
   I guess some answers = above, the=20 answer should be definite. I want to ask the DOS units.
 
   Thank you very much=20
 
 
- ------=_NextPart_000_004D_01C266CE.DB7CF1D0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 15:01:54 +0800 (CST) From: music@theory.issp.ac.cn Subject: [WIEN]: QTL-B about 2 ==== music@theory.issp.ac.cn submitted the following contribution: ==== Dear wien users, I'm using wien2k to calculate a system including La and H atoms, and I've set the RMT=1.2 for H, and RKMAX=6. But the QTL-B equals to 5 at first. So I used 'runsp_lapw -inlnew 1' to get updated case.in1c file. Then QTL-B equals to about 2. I wonder how this small QTL-B values occur and does it matter the properties of system ? Many thanks for any help from you ! - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 12:34:12 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: QTL-B about 2 ==== "Saeid Jalali" submitted the following contribution: ==== > I'm using wien2k to calculate a system including La and H atoms, and > I've set the RMT=1.2 for H, and RKMAX=6. But the QTL-B equals to 5 at > first. So I used 'runsp_lapw -inlnew 1' to get updated case.in1c file. > Then QTL-B equals to about 2. I wonder how this small QTL-B values > occur and does it matter the properties of system ? Your adding the switch "in1new 1" is perfect to get rise accuracy of linearization both in semi core (:EPL) and valence (:EPH) states to reduce QTL-B value. This small value occurs, as contribution from linearized basis to wavefunction is not exactly zero. Although you can don't care, there are also possibilities to improve it decreasing RMT as you are treating with a short bondlength system, reducing mixing factor to 0.01 in case.inm file, and finally give linearization by hand a try to check if in1new is done perfectly its job or not. To carry out the later step, linearization manually, one plots DOSs and then finds center of each curve, where the probability of electrons is maximum for each DOS, to find the best linearization and compare the result with the last in1 file. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 18:40:44 +0800 From: joshua xie Subject: [WIEN]: about 4H and 6H SiC ==== joshua xie submitted the following contribution: ==== Dear wien users£¬ I am not quite clear about the crystal structure of 4H and 6H SiC,so I do not know how to write the struct file of perfect 4H or 6H SiC crystal. Could someone give me the struct file or some hints to do these jobs? Thank you very much. Best regards! Joshua Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 19:30:35 +0800 (CST) From: music@theory.issp.ac.cn Subject: Re: [WIEN]: QTL-B about 2 ==== music@theory.issp.ac.cn submitted the following contribution: ==== Thank you very much. I'll try it. On Sat, 28 Sep 2002, Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > I'm using wien2k to calculate a system including La and H atoms, and > > I've set the RMT=1.2 for H, and RKMAX=6. But the QTL-B equals to 5 at > > first. So I used 'runsp_lapw -inlnew 1' to get updated case.in1c file. > > Then QTL-B equals to about 2. I wonder how this small QTL-B values > > occur and does it matter the properties of system ? > Your adding the switch "in1new 1" is perfect to get rise accuracy of > linearization both in semi core (:EPL) and valence (:EPH) states to reduce > QTL-B value. This small value occurs, as contribution from linearized basis > to wavefunction is not exactly zero. Although you can don't care, there are > also possibilities to improve it decreasing RMT as you are treating with a > short bondlength system, reducing mixing factor to 0.01 in case.inm file, > and finally give linearization by hand a try to check if in1new is done > perfectly its job or not. To carry out the later step, linearization > manually, one plots DOSs and then finds center of each curve, where the > probability of electrons is maximum for each DOS, to find the best > linearization and compare the result with the last in1 file. > Your, > Saeid. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 15:27:22 +0200 (MESZ) From: "A. Postnikov" Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== "A. Postnikov" submitted the following contribution: ==== Dear WIEN comunity, refering to a recent discussion about mini and relaxation - to my opinion the most annoying feature of WIEN in what regards structure relaxation is that internal coordinates and lattice parameters have to be optimized decoupled, and the optimization of lattice parameters is essentially done by hand (in a sequence of volume, c/a, c/b, ... runs). So it involves a fair amount of hand work to keep trace on all these optimizations, ultimately (with a bit of luck) converging them in a sequence of loops volume - c/a - mini - volume - c/a - .... - - or does anyone do it in a more automatized way? For the comparison, the SIESTA code already mentioned in this discussion includes a very nice feature of relaxing everything "on the fly", based on forces and stress tensor. One can e.g. define a target pressure and/or target stress - and the computer does (the large part of) the rest. And this has nothing to do with all-electron/pseudopot issues. To my opinion, the argumentation that SIESTA (or VASP) are fast and conveninet but unfortunately they don't work for all systems is somehow beyond the point. The calculation speed is one issue - and here both SIESTA and VASP pay a certain price for being fast. But the possibility to do convenient and automatic structure optimization has nothing to do with the speed. It can be incorporated in any code where forces and stress are available. A certain technical difference is that SIESTA does not care about conserving symmetry and proceeds with "general" (and "noisy") Cartesian forces, whereas in WIEN the forces and stress are constrained by the space group. But once we start the simulation the symmetry won't break by itself and doesn't need to be recalculated, so all the machinery of mini can be hopefully extended over varying lattice parameters. Although being certainly dependent on careful manpower, the implementation of such symmetry-constrained conjugate gradient search seems to me mostly a technical issue, and I am sure many users will appreciate this addition. Andrei Postnikov apostnik@uos.de On Fri, 27 Sep 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > .... > > In 90% of all electronic structure papers nowadays a structure relaxation > has been performed. > Of course it is true, that this may take quite a long time, since this is > nothing than a long series of sequential scf calculations. > > Yes, there are many other programs available, SIESTA and VASP was already > mentioned before. > > For a partiular class of compounds these programs can be highly efficient > and much faster than WIEN (e.i. with SIESTA they have simulated biomolecules > with 1000s !! of atoms). However, most of those programs are NOT applicable > to all systems. Try SIESTA for metals and I doubt that you can do more than > WIEN can do, and in addition most likely the results will also be WRONG. > > To use such programs, you probably need to be much more experienced than > when using WIEN. > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 19:09:56 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: about 4H and 6H SiC ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_04AF_01C26722.A21613A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I am not quite clear about the crystal structure of 4H and 6H = SiC,so I do not know how to write the struct file of perfect 4H or 6H = SiC crystal. Could someone give me the struct file or some hints to do = these jobs? 4H and 6H SiC refer to 4 and 6 dimmers of this formula to indicate that = 4 SiC dimmers (4 Si and 4 C totally 8 atoms) are in 4H SiC cell and 6 = SiC dimmers (6 Si and 6 C totally 12 atoms) are in 6H SiC cell. In 4H = SiC there are 2 types of Si and 2 type of C. In 6H SiC there are 3 types = of Si and 3 type of C. In 4H SiC there are 4 internal parameters, while = the number of internal parameters is only 5 for 6H SiC. The number of = space group for 4H SiC is "186" and it is similar to the number of space = group for 6H SiC. So You would select this number using struct generator = of WIEN2K for both of them, and just try to fill atomic positions. One = can find these atomic positions via many references, that I would notify = you from one of them: 4H SiC B1 =3D z1c Z (C-I) B2 =3D (=C2=BD+ z1)cZ (C-I)=20 B3 =3D =C2=BDaX-a/(23=C2=BD)Y+ z2cZ (C-II) B4 =3D =C2=BDaX+ a/(23=C2=BD)Y+(=C2=BD+z2)c Z (C-II) B5 =3D z3c Z (Si-I) =20 B6 =3D (=C2=BD+ z3)cZ (Si-I) B7 =3D =C2=BDaX+a/(23=C2=BD)Y+ z4cZ (Si-II) =20 B8 =3D =C2=BDaX- a/(23=C2=BD)Y+(=C2=BD+z4)c Z (Si-II) =20 in where (z1 =3D 0, z2 =3D 1/4, z3 =3D 3/16, z4 =3D 7/16 - -------------------------------------------------------------------------= - ------- 6H SiC B1 =3D 0 (Si-I) B2 =3D =C2=BD c Z (Si-I) B3 =3D z1 c Z (C-I) B4 =3D (=C2=BD + z1) c Z (C-I)=20 B5 =3D =C2=BD a X + a/(2 3=C2=BD) Y + z2 c Z (Si-II) B6 =3D =C2=BD a X - a/(2 3=C2=BD) Y + (=C2=BD + z2) c Z (Si-II)=20 B7 =3D =C2=BD a X + a/(2 3=C2=BD) Y + z3 c Z (C-II)=20 B8 =3D =C2=BD a X - a/(2 3=C2=BD) Y + (=C2=BD + z3) c Z (C-II)=20 B9 =3D =C2=BD a X + a/(2 3=C2=BD) Y + z4 c Z (Si-III) B10=3D =C2=BD a X - a/(2 3=C2=BD) Y + (=C2=BD + z4) c Z (Si-III)=20 B11 =3D =C2=BD a X + a/(2 3=C2=BD) Y + z5 c Z (C-III)=20 B12 =3D =C2=BD a X - a/(2 3=C2=BD) Y + (=C2=BD + z5) c Z (C-III)=20 2 3=C2=BD is 2*3^(1/2), zi is internal parameter, X, Y, Z are = Cartesian axis's, and a=3Db, c are lattice parameters, which you don't = need to consider them when you are filling the positions.=20 Your, S. Jalali. PS: This e-mail is sent as a Unicode message. - ------=_NextPart_000_04AF_01C26722.A21613A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
>      I am not quite clear about the = crystal=20 structure of 4H and 6H SiC,so I do not know how to write the struct file = of=20 perfect 4H or 6H SiC crystal. Could someone give me the struct file or = some=20 hints to do these jobs?
 
4H and 6H SiC refer to 4 and = 6 dimmers of=20 this formula to indicate that 4 SiC dimmers (4 Si and 4 C totally 8 = atoms) are in 4H SiC cell and 6 SiC=20 dimmers (6 Si and 6 C totally 12 atoms) are in 6H SiC = cell. In 4H=20 SiC there are 2 types of Si and 2 type of C. In 6H SiC there are 3 = types of=20 Si and 3 type of C. In 4H SiC there are 4 internal = parameters, while=20 the number of internal parameters is only 5 for 6H SiC. The number of = space=20 group for 4H SiC is "186" and it is similar to the number of space group = for 6H=20 SiC. So You would select this number using struct generator of WIEN2K = for both=20 of them, and just try to fill atomic positions. One can find these = atomic=20 positions via many references, that I would notify you from one of=20 them:
 
4H SiC
B1  =3D=  =20 z1c Z=20  (C-I)
B2 =  =3D=20 (=C2=BD+ z1)cZ=20  (C-I) 
B3=20  =3D =20 =C2=BDaX-a/(23=C2=BD)Y+ = z2cZ=20  (C-II)
B4  =3D =20 =C2=BDaX+=20 a/(23=C2=BD)Y+(=C2=BD+z2)c = Z=20  (C-II)
B5=20  =3D  z3c = Z=20  (Si-I)  =
B6=20  =3D  (=C2=BD+=20 z3)cZ=20  (Si-I)
B7 &= nbsp;=3D =20 =C2=BDaX+a/(23=C2=BD)Y+ = z4cZ=20  (Si-II)  
B8 &= nbsp;=3D =20 =C2=BDaX-=20 a/(23=C2=BD)Y+(=C2=BD+z4)c = Z=20  (Si-II)  
in where = (z1 =3D 0,  z2=20 =3D 1/4, z3 =3D 3/16, z4 =3D 7/16
6H SiC
B1 =3D   0  =20 (Si-I)
B2 =3D = =C2=BD c Z (Si-I)
B3 =3D = z1 c Z (C-I)
B4 =3D (=C2=BD + = z1) c=20 Z (C-I)
B5 =3D =C2=BD a X + a/(2 3=C2=BD) Y + = z2 c=20 Z (Si-II)
B6 =3D =C2=BD a = X - a/(2=20 3=C2=BD) Y + (=C2=BD + z2) c Z = (Si-II)
B7 =3D =C2=BD a = X + a/(2=20 3=C2=BD) Y + z3 c Z (C-II)
B8 =3D =C2=BD a X - a/(2 3=C2=BD) Y + = (=C2=BD + z3)=20 c Z (C-II)
B9 =3D =C2=BD a = X + a/(2=20 3=C2=BD) Y + z4 c Z (Si-III)
B10=3D =C2=BD a X - a/(2 = 3=C2=BD)=20 Y + (=C2=BD + z4) c Z (Si-III)=20
B11 =3D =C2=BD a X + a/(2 3=C2=BD) Y + = z5 c=20 Z (C-III)
B12 =3D =C2=BD a X - a/(2 3=C2=BD) Y + = (=C2=BD + z5)=20 c Z (C-III)
 
2 3=C2=BD  is  = 2*3^(1/2), zi=20 is internal parameter, X, Y, Z are Cartesian = axis's, and=20 a=3Db, c are lattice parameters, which you don't need to consider = them when=20 you are filling the positions.
 
Your,
S. Jalali.
PS: This e-mail is sent as a Unicode=20 message.
- ------=_NextPart_000_04AF_01C26722.A21613A0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Sep 2002 19:41:47 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: min_lapw ==== Bing Zhou submitted the following contribution: ==== Dear All: Can I run min_lapw in parallelization mode? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 29 Sep 2002 09:29:52 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: min_lapw ==== "Saeid Jalali" submitted the following contribution: ==== > Can I run min_lapw in parallelization mode? No you cannot use -p directly for series of sequential calculations, but in the "run_lapw" job to parallelize the k-points. In the case of having one internal parameter following the rule of E=aX^2 or F=-aX, it is recommended to minimize in parallel mode manually, selecting at least two X-positions and fitting the parabolic formula. I am really afraid to say that having such a rule is a simple but general idea, which may be extended to cases with more than one internal parameter. This means that if one collects relaxed positions of studied systems with two internal parameters, one may find an empirical rule. This may not be just an idea to parallelize serial mini calculations, as in this case speeding up is another goal of this story. We know that there are many cases with one internal parameter following the parabolic rule, an I wonder if it is possible at least to take an special consideration for these systems. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 29 Sep 2002 12:00:05 +0200 From: Stefaan.Cottenier@fys.kuleuven.ac.be Subject: Re: [WIEN]: min_lapw ==== Stefaan.Cottenier@fys.kuleuven.ac.be submitted the following contribution: ==== > ==== > Bing Zhou > submitted the following contribution: > ==== > > Can I run min_lapw in parallelization mode? Yes. With min_lapw you always specify a run_lapw or runsp_lapw command (either as argument or in a jobfile). Include the -p switch there and provide a suitable .machines file. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 29 Sep 2002 10:05:16 -0400 (EDT) From: Neme Nnolim Subject: [WIEN]: Problems with Eplot 'coa' plotting ==== Neme Nnolim submitted the following contribution: ==== Dear All, Eplot in WIEN works well for 'vol' plots but does not seem to work as well for 'coa' plots. My 'coa' energies calculated with x optimize look smooth when plotted with an external plotting program, but do not plot in Eplot. Anyone else experienced this? Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 29 Sep 2002 10:44:15 -0400 (EDT) From: Neme Nnolim Subject: [WIEN]: Re: Problems with Eplot 'coa' plotting ==== Neme Nnolim submitted the following contribution: ==== Actually I don't see what Eplot could possibly use for abscissa values for a 'coa' plot in the case.analysis file, unlike the 'vol' plot where :VOL is used for the abscissa. On Sun, 29 Sep 2002, Neme Nnolim wrote: > Date: Sun, 29 Sep 2002 10:05:16 -0400 (EDT) > From: Neme Nnolim > To: WIEN mailing list > Subject: Problems with Eplot 'coa' plotting > > > Dear All, > > Eplot in WIEN works well for 'vol' plots but does not seem to work as > well for 'coa' plots. > > My 'coa' energies calculated with x optimize look smooth when plotted with > an external plotting program, but do not plot in Eplot. > > Anyone else experienced this? > > Neme > > ------------------------------------------------------------------------------ > Neme Okechukwu Nnolim > Department of Materials Science, New Jersey Institute of Technology > Room 302, Tiernan Hall, 161 Warren Street, University Heights > Newark, New Jersey 07102-1982 > Tel: (973) 596-8283, FAX: (973) 596-5794 > ------------------------------------------------------------------------------- > > > - -- - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 29 Sep 2002 12:11:19 -0700 (PDT) From: Igor Mazin Subject: Re: [WIEN]: ==== Igor Mazin submitted the following contribution: ==== Just a follow-up. A solid is not a molecuel, and no band strusture code has a complete basis set. Therefore the difference between these matrix elements may be nontrivial. See our old paper, Z.f.Phys., B53, 1983, 263 Good luck Igor - --- Fred Nastos wrote: > ==== > Fred Nastos > submitted the following contribution: > ==== > > On September 24, 2002 07:38 am, Ma Chi Chiu wrote: > > ==== > > Ma Chi Chiu > > submitted the following contribution: > > ==== > > Before I pushed send, I noticed Dr. Andersen has > allready replied. Just > to add though... > > > 1. definition of "momentum matrix elements" (Is it > the same as transition > > dipole moment?) > > The momentum matrix element is defined as, > > = int d^3r i hbar nabla > > where |nk> is a Bloch state. The wien code uses > Rydberg atomic units > (throughout), in which hbar=m=e=1. The atomic unit > for momentum (Ry or H) > is hbar/a0 (where a0 is the Bohr radius). > > The dipole matrix element is usually . If n > and m are different bands > the two matrix elements can be simply related as > they are for molecules. > > > 2. definition of k-mesh (What is the differences > between k-mesh and > > k-point?) > > The k-mesh is the set of k-points, i.e. the grid of > points. See Bloechl et al. > [Phys. Rev. B 49, 16223-16233 (1994)] for the > details. > > Fred > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== ***************************************************************************** Igor Mazin, Naval Research Laboratory, Washington, DC 20375 Ph.: 202 767-6990; Fax: 202 404-7546; http://cst-www.nrl.navy.mil/~mazin ***************************************************************************** __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 10:53:12 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: DOS matching bandstructures... ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks Saeid Jalali and Torsten Andersen for you assistance! Thanks so much! It is a great relief to see the peaks corresponding to the energy levels of the bands! thanks for your invaluable help! Cheng Quoting Saeid Jalali : > > I am studying a simple case of solid Li2O. > > > > My bandstructure reveals bands at 0 to -5 eV (O 2p), -15 eV and -45 eV... > > > then I changed the k mesh back to the original, run a single SCF cycle, > to > > ensure lapw1 is done, > > > > That is okay, but when you want to calculate DOS after the bandstructure, you > only need to run lapw1 with the original case.in1 file to make sure about > proper case.vector(s). > > > > and do the DOS... but it only has peaks at around -5 eV (ignoring above > E_fermi) > > > > i also tried setting a fresh case and doing the DOS only after the SCF... > > > > That is okay (making strongly sure), but time consuming. > > > i am puzzled, I really expect peaks in the DOS to correspond to the bands > at > > those energies... > > > You are right, there should be such a correspondence between DOS and band > character plotting. > > > > > can someone tell me possible errors, hints from their experiences? > > > > If you would see DOS's from -45eV, change Emin of case.int file to > -45/13.6~-3.4Ry, and then run tetra. > > > > Your, > > S. Jalali. > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 11:20:26 +0900 From: Satoshi Okada Subject: [WIEN]: lapw2 & ifc on LINUX ==== Satoshi Okada submitted the following contribution: ==== Hi all, I try to make WIEN2k with ifc(Intel Fortran Compiler) on LINUX. When WIEN2k(lapw2) read a vector data file ( UNIT 10 ), the illegal values were inputed for kx_buf,ky_buf,kz_buf after about 400byte reading. SRC_lapw2/read_vec.F: 54 IF(myid.EQ.0) THEN 55 WRITE(31,205) s,t,z,n,ne,bname 56 READ(10) (kx_buf(i),ky_buf(i),kz_buf(i), i=1,n-(nlo+nlon+nlov)), (kxlo(i),kylo(i),kzlo(i),i=1,(nlo+nlon+nlov)) 57 ENDIF This problem occur in sample input data (TiC , TiO2). Another compiler ( ex. pgf90 ) can read this data file correctly. And, when i use FORMATTED vector data file for WRITE & READ, lapw2 can read all data correctly. So, i think this problem cases binary data READ(WRITE) for ifc. Do you have any suggestion for this problem ? When I asked Intel this problem, Intel said "Give me all program & data". And I didn't. ================================= Our environment : CPU Intel Pentium4 1.8GHz 256KBcache M/B ASUS P4T Mem 1048MB OS SuSE Linux 7.1 kernel 2.4.17 ifc Intel(R) Fortran Compiler for 32-bit applications, Version 6.0.1 Build 20020822Z WIEN2K WIEN2k_02 (Sep 12) OPTION current:FOPT:-FR -mp -w current:LDFLAGS:-L../SRC_lib -Vaxlib -static current:R_LIBS:-lblas_lapw -llapack_lapw Regards. - ------------------------------------------------------------------- Satoshi Okada Intel OEM MFG. HIT Corporation Ltd., Tel:+81-3-5796-3033 2-32-3 kitashinagawa Fax:+81-3-5796-3034 Shinagawa 140-0001 http://www.hpc.co.jp/ Tokyo, Japan mailto:okada@hpc.co.jp ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 08:41:41 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Peter Blaha submitted the following contribution: ==== > thank you for these very interesting and deep answers! It confirmed to > me that it is a difficult and potentially long-lasting task, but also I do NOT think that this a difficult and long-lasting task!! > As usual, I am setting up a slab calculation in order to try to optimize > a metal surface with an overlayer of another metal. Thus, based on your In fact, this is even a quite simple task (unless you have a big x-y supercell) The easiest way: a) Calculate (using "optimize") the bulk-lattice parameter of your substrate metal. This should be fairly quick because of the small 3D unitcell. b) Use this lattice parameter for you slab calculations (If you use the exp. latticeparameters, you may get a "stain" in the free c-direction, since the atoms may want to come closer (or further apart) not due to a surface effect, but because GGA wants another bulk distance). c) A metal slab with an overlayer does NOT have just one free parameter, since also the original surface (and possibly the sub-surface) can relax too, so there are at least 2-3 free parameters. An "optimize" scheme is in most cases not very suitable (unless you have a system where ONLY the overlayer distance needs to be determined). min_lapw works usually very good for these problems and once you got experience and know how to set the input in case.inM it should converge pretty quickly to zero forces. (There are many previous wien-mailings how to monitor *.scf_mini and how to adjust inM). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 09:11:05 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Questions about "mini" vs. "optimize" ==== Peter Blaha submitted the following contribution: ==== > to my opinion the most annoying feature of WIEN > in what regards structure relaxation is that > internal coordinates and lattice parameters have to be > optimized decoupled, and the optimization of lattice > parameters is essentially done by hand > (in a sequence of volume, c/a, c/b, ... runs). I agree, FULL optimizations of noncubic (tetragonal and hexagonal still can be done in most cases) structures is BEYOND the present WIEN2k. (For cubic, tetragonal or hexagonal cells use the standard optimize, but replace the "run_lapw" by "min_lapw" when you have free internal coordinates) > But the possibility to do convenient and automatic > structure optimization has nothing to do with the speed. > It can be incorporated in any code where forces and stress > are available. That's the point: At present the stress tensor is not available in WIEN. One can try to calculate it directly (C.Ambrosch-Draxl is working on that), or one could also do it numerically (from a few E-tot calculations) or using conjg.gradients. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 09:29:00 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problems with Eplot 'coa' plotting ==== Peter Blaha submitted the following contribution: ==== > Eplot in WIEN works well for 'vol' plots but does not seem to work as > well for 'coa' plots. > > My 'coa' energies calculated with x optimize look smooth when plotted with > an external plotting program, but do not plot in Eplot. The w2web interface does not yet support the c/a plotting at all. I think you still could use "eplot_lapw" from the command line, but you need a file: case.analysis grepline :ene '*coa*scf' 1 > case.analysis Note: it does not plot a line, but just a series of dots. PS: It gets the c/a ratio not from the scf file, but from the filename using: grep $type $file.analysis | grep -v "Analysis generated" | grep -v ":VOL " |\ sed "s/.*$type//" | tr ":a-z" " " | awk '{print $1 " " $NF}'|\ cut -c1-6,8- | tr "_" " " |sort -n 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 09:47:01 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: lapw2 & ifc on LINUX ==== Peter Blaha submitted the following contribution: ==== > I try to make WIEN2k with ifc(Intel Fortran Compiler) on LINUX. > > When WIEN2k(lapw2) read a vector data file ( UNIT 10 ), > the illegal values were inputed for kx_buf,ky_buf,kz_buf > after about 400byte reading. > > SRC_lapw2/read_vec.F: > 54 IF(myid.EQ.0) THEN > 55 WRITE(31,205) s,t,z,n,ne,bname > 56 READ(10) (kx_buf(i),ky_buf(i),kz_buf(i), > i=1,n-(nlo+nlon+nlov)), > (kxlo(i),kylo(i),kzlo(i),i=1,(nlo+nlon+nlov)) > 57 ENDIF On our system we also use the ifc compiler and have no problems at all. However, since this compiler is still under development, a lot may depend on the version of the compiler. I have one suggestion for testing: Add in SRC_lapw2/read_vec.F: CHARACTER*3 IPGR and change the following line: IF (myid.EQ.0) READ(10,IOSTAT=ios) s,t,z,bname,n,ne,ipgr ipgr is written by lapw1/tapewf.F Usually partial reads ignore longer records and with the next read the next record is read and everything is fine. Maybe the ifc does not like this. PS: Please let me know if this fixes your problem. (The final solution should be to remove ipgr from tapewf.F since it is no longer needed. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 08:56:54 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Problems with Eplot 'coa' plotting ==== Neme Nnolim submitted the following contribution: ==== > > The w2web interface does not yet support the c/a plotting at all. > > I think you still could use "eplot_lapw" from the command line, but > you need a file: case.analysis > > grepline :ene '*coa*scf' 1 > case.analysis > > Note: it does not plot a line, but just a series of dots. > > PS: It gets the c/a ratio not from the scf file, but from the filename using: > > grep $type $file.analysis | grep -v "Analysis generated" | grep -v ":VOL " |\ > sed "s/.*$type//" | tr ":a-z" " " | awk '{print $1 " " $NF}'|\ > cut -c1-6,8- | tr "_" " " |sort -n > I wanted to use Eplot for c/a plotting because I thought that Eplot would carry out a fitting to obtain the shear constant in the same way that the energy points from a 'vol' plot are fitted to obtain the bulk modulus. That mess you have up there convinces me that I have to fit the energy points from c/a calculations myself. - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Sep 2002 17:53:14 -0600 From: Pablo de la Mora Subject: [WIEN]: fixed spin moment ==== Pablo de la Mora submitted the following contribution: ==== Dear Wien users, We are trying to do some fixed spin calculations. We had a ferrimagnetic system and we wanted to see how it changed when the total moment of the cell increased. For the unrestricted system the up and down-spin DOS were quite different, one shifted from the other. For the fixed-spin-system the up and down DOS were quite similar in shape except for the size, now the up-spin and the down-spin were not shifted one from the other. Is this expected for these type of calculations? Yours Pablo de la Mora ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 01 Oct 2002 08:00:18 +0530 From: "R.K.Thapa" Subject: Re: [WIEN]: fixed spin moment ==== "R.K.Thapa" submitted the following contribution: ==== Dear Dr. de la Mora I am also one of the beneficiaries of WIEN2K which I received freely on request to Prof. Karlheinz Schwarz, Vienna Univ. of Technology. But I regret to inform you that I AM NOT ABLE TO DO ANY WORKs with this code as I do not possess or have FORTRAN 90 compiler for linux os. If possible, may I reuest you kindly to send me this fortran compiler (PGF90) for linux os for the act of which I shall ever remain grateful to you. The reason for this special request to you is that the cost of this in dollar is very high and my institute just turned down my request for its procurement. Sorry for all the trouibles and I most humbly apologise. Sincerely yours R.K.Thapa ========================= Condensed Matter Theory Research Group Department of Physics Mizoram University Pachhunga University College Aizawl 796001 Miizoram Tel. (0389)-328044(R), 327095(O) Fax :(0389)-323491 E-mails : rktt@sancharnet.in ramkumar_thapa@yahoo.com ================================ Pablo de la Mora wrote: > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > Dear Wien users, > We are trying to do some fixed spin calculations. > We had a ferrimagnetic system and we wanted to see how it changed > when the total moment of the cell increased. > For the unrestricted system the up and down-spin DOS were quite > different, one shifted from the other. For the fixed-spin-system the up > and down DOS were quite similar in shape except for the size, now the > up-spin and the down-spin were not shifted one from the other. > Is this expected for these type of calculations? > Yours > > Pablo de la Mora > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 01 Oct 2002 08:02:17 +0530 From: "R.K.Thapa" Subject: [WIEN]: request if possible ==== "R.K.Thapa" submitted the following contribution: ==== Dear Dr.Neme Nnolim I am also one of the beneficiaries of WIEN2K which I received freely on request to Prof. Karlheinz Schwarz, Vienna Univ. of Technology. But I regret to inform you that I AM NOT ABLE TO DO ANY WORKs with this code as I do not possess or have FORTRAN 90 compiler for linux os. If possible, may I reuest you kindly to send me this fortran compiler (PGF90) for linux os for the act of which I shall ever remain grateful to you. The reason for this special request to you is that the cost of this in dollar is very high and my institute just turned down my request for its procurement. Sorry for all the trouibles and I most humbly apologise. Sincerely yours R.K.Thapa ========================= Condensed Matter Theory Research Group Department of Physics Mizoram University Pachhunga University College Aizawl 796001 Miizoram Tel. (0389)-328044(R), 327095(O) Fax :(0389)-323491 E-mails : rktt@sancharnet.in ramkumar_thapa@yahoo.com Neme Nnolim wrote: > ==== > Neme Nnolim > submitted the following contribution: > ==== > > > > > The w2web interface does not yet support the c/a plotting at all. > > > > I think you still could use "eplot_lapw" from the command line, but > > you need a file: case.analysis > > > > grepline :ene '*coa*scf' 1 > case.analysis > > > > Note: it does not plot a line, but just a series of dots. > > > > PS: It gets the c/a ratio not from the scf file, but from the filename using: > > > > grep $type $file.analysis | grep -v "Analysis generated" | grep -v ":VOL " |\ > > sed "s/.*$type//" | tr ":a-z" " " | awk '{print $1 " " $NF}'|\ > > cut -c1-6,8- | tr "_" " " |sort -n > > > > I wanted to use Eplot for c/a plotting because I thought that Eplot would > carry out a fitting to obtain the shear constant in the same way that the > energy points from a 'vol' plot are fitted to obtain the bulk modulus. > > That mess you have up there convinces me that I have to fit the > energy points from c/a calculations myself. > > ------------------------------------------------------------------------------ > Neme Okechukwu Nnolim > Department of Materials Science, New Jersey Institute of Technology > Room 302, Tiernan Hall, 161 Warren Street, University Heights > Newark, New Jersey 07102-1982 > Tel: (973) 596-8283, FAX: (973) 596-5794 > ------------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 15:20:11 +1000 From: chen0130@flinders.edu.au Subject: [WIEN]: band gaps with slabs ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, I have two questions about bandstructures for slabs, (1) With slab bandstructures, I have much more bands than the bulk, and at the GAMMA point, the bands do not meet at the same energy. Can anyone tell me how I take the band gap? Would it be acceptable to take the midpoint of a region and take that from the midpoint from the higher region (at GAMMA)? As my system is Li2O, and I have valence bands at Li(1s), O(2s) and O(2p), where each region has a collection of bands which are not all meeting at the GAMMA point. (2) It would make sense, that as the slab gets thicker, it becomes closer to the bulk, yet the bulk is a only 6 bands, whereas a 21 layer slab is 126 (occupied) bands... My understanding at this stage is that a bigger cell with more atoms will have more bands, is that all there is to it? It seems that the overall electronic structure should not be affected, as the 'really thick' slab begins to describe something similar to the bulk... Thanks for you time! Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 09:14:16 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: request if possible ==== Peter Blaha submitted the following contribution: ==== > regret to inform you that I AM NOT ABLE TO DO ANY WORKs with this code > as I do not possess or have FORTRAN 90 compiler for linux os. > If possible, may I reuest you kindly to send me this fortran compiler > (PGF90) for linux os for the act of which I shall ever remain grateful > to you. I do not think that one can send you (legally) the pgi f90 compiler. However, you have two choices: a) On the download page of WIEN2k we provide also the executables. When you download them, you do not need a compiler at all!!! (but cannot change the code) b) There is a free f90 compiler from intel. You con download (free of charge) the "unsupported" ifc 6.0 from there homepage. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 11:23:34 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: band gaps with slabs ==== Peter Blaha submitted the following contribution: ==== Your questions about slabs are quite basic and elementary: Suppose you create a cell with two layers (but no vacuum for the moment). Then you have "doubled" your primitive unit cell. A doubled real space cell leads to a smaller reciprocal cell and since you have twice as many atoms you MUST find twice as many bands. In this simple example, the bands at Gamma (in the supercell) reflect the original states at gamma (of the small unit cell) AND the "backfolded" states at the "Z" point of the original cell (where I suppose that you doubled the z-direction). I hope the principle is clear by now. When you now take a thicker slab, you get backfolding along the normal of your surface (i.e. for a (001) surface you get (at Gamma) all the eigenvalues from the original gamma-Z line (depending on the number of layers with a finer or coarser k-grid along this direction). Of course the vacuum "disturbs" these states to some extend, so they will not be exactly the backfolded states, but very close to them. In addition so called "surface states" can appear, which have nothing in common with the "bulk states". With this knowledge you should be able to answer your questions alone. > I have two questions about bandstructures for slabs, > > (1) With slab bandstructures, I have much more bands than the bulk, and at the > GAMMA point, the bands do not meet at the same energy. > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 11:43:10 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: fixed spin moment ==== Peter Blaha submitted the following contribution: ==== > We are trying to do some fixed spin calculations. > We had a ferrimagnetic system and we wanted to see how it changed > when the total moment of the cell increased. > For the unrestricted system the up and down-spin DOS were quite > different, one shifted from the other. For the fixed-spin-system the up > and down DOS were quite similar in shape except for the size, now the > up-spin and the down-spin were not shifted one from the other. I guess you misinterprete your results. The sequence of a FSM calculation is: x lapw1 -up cp vector_up vector_dn cp in2_up in2 x lapw2 -up x lapw1 -dn cp vector_dn vector_up cp in2_dn in2 x lapw2 -dn Thus at the end of a FSM scf cycle, all you have are the spin-dn vectors and it does not matter wether you do x lapw2 -up -qtl or x lapw2 -dn -qtl, you get the same qtl-file (and thus DOS) You must have both vector files for the DOS: i.e. run x lapw1 -up (now you have proper spin-up and dn vectors) and x lapw2 -up -qtl x lapw2 -dn -qtl eventually you should also correct for the differences in EF for up/dn as found in the scf file. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 15:41:48 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: fixed spin moment ==== "Saeid Jalali" submitted the following contribution: ==== > We are trying to do some fixed spin calculations. > We had a ferrimagnetic system and we wanted to see how it changed > when the total moment of the cell increased. > For the unrestricted system the up and down-spin DOS were quite > different, one shifted from the other. > For the fixed-spin-system the up > and down DOS were quite similar in shape except for the size, now the > up-spin and the down-spin were not shifted one from the other. > Is this expected for these type of calculations? In one side, splitting of up-DOS and dn-DOS refers to or depends on correlation. For example in strongly correlated fcc-Gd in its metallic state the distance between higher (unoccupied) 4f band and lower (occupied) 4f band within local spin density approximation is 5.5 eV. For fcc-Sm it is around 0.5 eV, which is much smaller than Hubbard U shifted between up and down DOSs. On the other hand, within LSDA up and down spin densities will be different if number of up electrons are not equal to number of down electrons, which is an indication of magnetic moment. You have nicely touched two points together. As far as I know in wien2k we can impose zero magnetic moment even in a spin polarized calculation, but I am not sure if fixing magnetic moment to a non zero value is also possible. If you don't think so, please show us how we can do it: changing or increasing magnetic moment gradually from paramagnetically zero value to the highest value in its fully ferromagnetic situation. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 16:04:41 +0200 From: "Kevin Jorissen" Subject: [WIEN]: lxdos - problems with lapw2 and tetra ==== "Kevin Jorissen" submitted the following contribution: ==== Dear wien users, I am trying to use wien2k with the parameter lxdos = 3. I recompiled tetra and lapw2 after setting this parameter to 3 in param.inc resp. modules.F. However, I have not succeeded to make either of them function properly. * When running x lapw2 -qtl after SCF, the program terminates normally and produces a qtl-file with the correct format for ISPLIT =88 or 99. However, the xdos-matrix is equal to zero! * Tetra on the other hand works fine with lxdos = 1, but seems to fail regardless the value of ISPLIT when the program is recompiled with lxdos = 3. I get a core dump - segmentation fault. Watching case.outputt and inserting some test lines in tetra.f and arbdos.f, I saw that all statements up to the invocation of arbdos are executed in tetra, but the routine arbdos never gets started (a test line in the beginning of the program is never printed). The routine has been changed w.r.t. WIEN97 (extra arguments of which I do not know the meaning, and different declaration of variables of course). Lxdos is not used explicitly, but determines the size of certain objects. The cases I have used for testing are simple diamond and graphite - nothing excentric, really. Discovering small changes in the WIEN2k-code w.r.t. WIEN97 I learned that someone has obviously been working on the lxdos3-case, so I hope this someone will be able to help me and maybe bring to my attention new elements that have to be considered when performing this kind of calculation. Please do not hesitate to ask for additional information if necessary. Kind regards, Kevin Jorissen EMAT - University of Antwerp kevin.jorissen@ua.ac.be ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 16:41:31 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: lxdos - problems with lapw2 and tetra ==== Peter Blaha submitted the following contribution: ==== > I am trying to use wien2k with the parameter lxdos = 3. I recompiled tetra > and lapw2 after setting this parameter to 3 in param.inc resp. modules.F. > However, I have not succeeded to make either of them function properly. Have you updated to the latest version from the web ? Older WIEN2k versions had a bug for lxdos=3. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 08:00:38 -0700 (PDT) From: sayede adlane Subject: Re: [WIEN]: Problems with Eplot 'coa' plotting ==== sayede adlane submitted the following contribution: ==== - --0-1406971704-1033484438=:7953 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is simple script that I use to plot c/a or b/a vs Energy (plus polyfiting 4th order). To use it just type : >Enplot casename Hope to help you ! Yours A. Sayede. - --- Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > Eplot in WIEN works well for 'vol' plots but does > not seem to work as > > well for 'coa' plots. > > > > My 'coa' energies calculated with x optimize look > smooth when plotted with > > an external plotting program, but do not plot in > Eplot. > > The w2web interface does not yet support the c/a > plotting at all. > > I think you still could use "eplot_lapw" from the > command line, but > you need a file: case.analysis > > grepline :ene '*coa*scf' 1 > case.analysis > > Note: it does not plot a line, but just a series of > dots. > > PS: It gets the c/a ratio not from the scf file, but > from the filename using: > > grep $type $file.analysis | grep -v "Analysis > generated" | grep -v ":VOL " |\ > sed "s/.*$type//" | tr ":a-z" " " | awk '{print $1 > " " $NF}'|\ > cut -c1-6,8- | tr "_" " " |sort -n > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com - --0-1406971704-1033484438=:7953 Content-Type: application/octet-stream; name=EnPlot Content-Transfer-Encoding: base64 Content-Description: EnPlot Content-Disposition: attachment; filename=EnPlot IyEvYmluL2Jhc2gKZWNobyAiIgplY2hvICIiCmVjaG8gIiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyIKZWNobyAiIyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIgplY2hvICIjICAgICAg ICAgICAgICAgIEVuUGxvdCAgICAgICAgICAgICAgICMiCmVjaG8gIiMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyIKZWNobyAiIyAg UGxvdCBFbmVyZ3kgdnMgYy9hIG9yIGIvYSAgICAgICAgICAjIgplY2hvICIj ICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBTYXllZGUgICMiCmVjaG8g IiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyIKZWNo byAiIgplY2hvICJ1c2FnZTogRW5QbG90IGNhc2VfbmFtZSIKZWNobyAiIgpl Y2hvICd0eXBlICAgIjEiICBmb3IgYy9hIG9yJwplY2hvICcgICAgICAgIjIi ICBmb3IgYi9hICcKZWNobyAiIgpyZWFkIGFucwppZiBbICRhbnMgIT0gIjEi IC1hICRhbnMgIT0gIjIiIF07dGhlbiAKZWNobyAidHlwZSAxIG9yIDIgISIK ZXhpdCAwCmVsaWYgWyAkYW5zID0gIjEiIF07dGhlbgplY2hvICIjIGMvYSAg ICAgICBFbmVyZ3koUnkpIiA+ICQxLmRhdApmb3IgeSBpbiBgbHMgLWwgKmNv YSpzY2YgfCBhd2sgJ3sgcHJpbnQgJDcsICQ5fSd8IHNvcnQgLWRuIHwgIGF3 ayAne3ByaW50ICQyfSdgOyAKZG8gZXhwb3J0IGE9YGdyZXAgOkxBVCAkeSB8 IHRhaWwgLW4gMXwgYXdrICd7cHJpbnQgICQ3LyQ1fSdgOyAKZXhwb3J0IGI9 YGdyZXAgOkVORSAkeSB8IHRhaWwgLW4gMSB8IGF3ayAne3ByaW50ICQ5fSdg OyAKZWNobyAkYSAkYjsgCmRvbmUgPj4gJDEuZGF0CmVsaWYKWyAkYW5zID0g IjIiIF07dGhlbgplY2hvICIjIGIvYSAgICAgICBFbmVyZ3koUnkpIiA+ICQx LmRhdApmb3IgeSBpbiBgbHMgLWwgKmJvYSpzY2YgfCBhd2sgJ3sgcHJpbnQg JDcsICQ5fSd8IHNvcnQgLWRuIHwgIGF3ayAne3ByaW50ICQyfSdgOyAKZG8g ZXhwb3J0IGE9YGdyZXAgOkxBVCAkeSB8IHRhaWwgLW4gMXwgYXdrICd7cHJp bnQgICQ2LyQ1fSdgOyAKZXhwb3J0IGI9YGdyZXAgOkVORSAkeSB8IHRhaWwg LW4gMSB8IGF3ayAne3ByaW50ICQ5fSdgOyAKZWNobyAkYSAkYjsgCmRvbmUg Pj4gJDEuZGF0CmZpCmNhdCA8PEVPRiA+JDEucGxvdApzZXQgZm9ybWF0IHkg IiUuNGYiCmYoeCk9YTErYTIqeCthMyp4KioyK2E0KngqKjMrYTUqeCoqNApm aXQgZih4KSAnJDEuZGF0JyB2aWEgJyQxLnBhcmEnCnBsb3QgIiQxLmRhdCIg dGl0bGUgIiQxIjsgcmVwbG90IGYoeCkgdGl0bGUgInBvbHlmaXRfNG9yZGVy IgpwYXVzZSAtMQpFT0YKY2F0IDw8RU9GID4kMS5wYXJhCmExPTEKYTI9MQph Mz0xCmE0PTEKYTU9MQpFT0YKZ251cGxvdCAkMS5wbG90CmVjaG8gIkRvIHlv dSB3YW50IGEgaGFyZCBjb3B5ID8gKHkvbikiCnJlYWQgYW5zMQppZiBbICRh bnMxID0gInkiIF07dGhlbiAKY2F0IDw8RU9GID4kMS5wb3N0CnNldCB0ZXJt aW5hbCBwb3N0c2NyaXB0CnNldCBvdXRwdXQgIiQxLnBzIgpzZXQgZm9ybWF0 IHkgIiUuNGYiCmYoeCk9YTErYTIqeCthMyp4KioyK2E0KngqKjMrYTUqeCoq NApmaXQgZih4KSAnJDEuZGF0JyB2aWEgJyQxLnBhcmEnCnBsb3QgIiQxLmRh dCIgdGl0bGUgIiQxIjsgcmVwbG90IGYoeCkgdGl0bGUgInBvbHlmaXRfNG9y ZGVyIgpFT0YKZ251cGxvdCAkMS5wb3N0Cmd2ICQxLnBzCmVsc2UKZWNobyAi YnllIDstKSIKZXhpdCAxCmZp - --0-1406971704-1033484438=:7953-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 1 Oct 2002 17:29:40 +0200 From: "Kevin Jorissen" Subject: Re:Fw: [WIEN]: lxdos - problems with lapw2 and tetra ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Mr. Blaha, the VERSION-file in my wien2k-directory reads WIEN2k_02 (Release 27/05/2002) If I have not made any mistake, it has, however, been downloaded quite recently. I will download the latest version in any case and install it, and contact you again if problems persist. Thank you, Kevin Jorissen EMAT - University of Antwerp kevin.jorissen@ua.ac.be ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 01 Oct 2002 23:55:42 -0400 (EDT) From: Neme Nnolim Subject: Re: [WIEN]: Problems with Eplot 'coa' plotting ==== Neme Nnolim submitted the following contribution: ==== Thanks for the script, Adlane. I can't wait to try it. Regards, Neme On Tue, 1 Oct 2002, sayede adlane wrote: > Date: Tue, 1 Oct 2002 08:00:38 -0700 (PDT) > From: sayede adlane > Reply-To: wien@zeus.theochem.tuwien.ac.at > To: wien@zeus.theochem.tuwien.ac.at > Subject: Re: [WIEN]: Problems with Eplot 'coa' plotting > > Here is simple script that I use to plot c/a or b/a vs > Energy (plus polyfiting 4th order). > To use it just type : > >Enplot casename > Hope to help you ! > > Yours A. Sayede. - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Materials Science, New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 2 Oct 2002 09:59:27 +0200 From: "Kevin Jorissen" Subject: [WIEN]: lxdos3 - lapw2 - tetra ==== "Kevin Jorissen" submitted the following contribution: ==== Installing the newest version of WIEN2k (VERSION file still reads 'released 27/5' by the way) didn't change anything, I'm sorry to say. Thanks for all suggestions, Kevin Jorissen EMAT, University of Antwerp kevin.jorissen@ua.ac.be ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 3 Oct 2002 14:34:51 +0200 From: "Stefaan Cottenier" Subject: [WIEN]: sgroup ==== "Stefaan Cottenier" submitted the following contribution: ==== Dear Wien users, It might be due to my limited knowledge on crystallography, but I see strange behaviour in sgroup. Using the GUI, I want to create group nr. 225 (Fm-3m), with the atoms on position 8c (point group m-3m). According to tables, these should have positions 1/4,1/4,1/4 and 1/4,1/4,3/4. In the GUI, I should enter only 1 position, I choose the 1/4,1/4,1/4. Then, after saving the structure, it returns two positions: 1/4,1/4,1/4 and the unexpected 3/4,3/4,3/4. So far, I could assume that the GUI uses another setting for this structure, so I assume everything could still be all right and proceed. However, sgroup protests : warning: !!! Bravais lattice has changed. and recommends group nr. 221 (P m -3 m). If I neglect this warning and go to symmetry, it asks to shift the origin, and after that the original multiplicity of 2 becomes 1. When I make the struct-file manually, with the two positions according to the tables : F LATTICE,NONEQUIV. ATOMS: 1225_Fm-3m MODE OF CALC=RELA unit=bohr 7.558900 7.558900 7.558900 90.000000 90.000000 90.000000 ATOM= -1: X=0.25000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 8 ATOM= -1:X= 0.25000000 Y=0.25000000 Z=0.75000000 Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 NUMBER OF SYMMETRY OPERATIONS then the same behaviour happens. Something similar happens with the most general 192l (1.) position in this group: the GUI finds only 24 instead of 48 positions, sgroup correctly detects the group, but symmetry detects as point group m instead of 1 (actually, it has made 96k instead of 192l). Similar behaviour is seen in group nr. 229 with the 6b position. I am using the latest Wien version. Is this a bug, or should I update my crystallography knowledge ? Stefaan - ---------------------------------------------------------------------------- - -- Stefaan Cottenier Instituut voor Kern- en Stralingsfysica K.U.Leuven Celestijnenlaan 200 D tel: + 32 16 32 71 45 B-3001 Leuven fax: + 32 16 32 79 85 Belgium e-mail: Stefaan.Cottenier@fys.kuleuven.ac.be http://www.fys.kuleuven.ac.be/iks/nvsf/nvsf.html - ---------------------------------------------------------------------------- - -- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #37 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #38 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, October 11 2002 Volume 2002 : Number 038 ---------------------------------------------------------------------- Date: Thu, 3 Oct 2002 15:16:27 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: case.int file ==== Bing Zhou submitted the following contribution: ==== Dear All: I try to calculate DOS, but I did not found my case.int file when I found the following files: tic.in0 tic.in2_st tic.inm_restart_st tic.in0_st tic.in2_sy tic.inm_st tic.in1 tic.in5 tic.inso tic.in1_st tic.inc tic.inst tic.in2 tic.inc_st tic.in2_ls tic.inm What should I do to make it work? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 3 Oct 2002 16:43:15 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: case.int file ==== Bing Zhou submitted the following contribution: ==== Dear All: Never mind the following question, case.int file only can be produced after x lapw -qtl is run. Best wishes! Dear All: I try to calculate DOS, but I did not found my case.int file when I found the following files: tic.in0 tic.in2_st tic.inm_restart_st tic.in0_st tic.in2_sy tic.inm_st tic.in1 tic.in5 tic.inso tic.in1_st tic.inc tic.inst tic.in2 tic.inc_st tic.in2_ls tic.inm What should I do to make it work? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 03 Oct 2002 17:06:39 -0600 From: Pablo de la Mora Subject: Re: [WIEN]: fixed spin moment ==== Pablo de la Mora submitted the following contribution: ==== - --------------080903050806000100030000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Peter Blaha wrote: >==== >Peter Blaha >submitted the following contribution: >==== > >> We are trying to do some fixed spin calculations. >> We had a ferrimagnetic system and we wanted to see how it changed >>when the total moment of the cell increased. >> For the unrestricted system the up and down-spin DOS were quite >>different, one shifted from the other. For the fixed-spin-system the up >>and down DOS were quite similar in shape except for the size, now the >>up-spin and the down-spin were not shifted one from the other. >> > >I guess you misinterprete your results. The sequence of a FSM calculation >is: > >x lapw1 -up >cp vector_up vector_dn >cp in2_up in2 >x lapw2 -up > >x lapw1 -dn >cp vector_dn vector_up >cp in2_dn in2 >x lapw2 -dn > >Thus at the end of a FSM scf cycle, all you have are the spin-dn vectors >and it does not matter wether you do x lapw2 -up -qtl or x lapw2 -dn -qtl, >you get the same qtl-file (and thus DOS) > >You must have both vector files for the DOS: i.e. run > >x lapw1 -up (now you have proper spin-up and dn vectors) and > >x lapw2 -up -qtl >x lapw2 -dn -qtl > >eventually you should also correct for the differences in EF for up/dn >as found in the scf file. > >Regards > > > > P.Blaha > Thank you very much, now the calculations are going well - --------------080903050806000100030000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Peter Blaha wrote:
====
Peter Blaha <pblaha@theochem.tuwien.ac.at>
submitted the following contribution:
====

    We are trying to do some fixed spin calculations.
    We had a ferrimagnetic system and we wanted to see how it changed
when the total moment of the cell increased.
    For the unrestricted system the up and down-spin DOS were quite
different, one shifted from the other. For the fixed-spin-system the up
and down DOS were quite similar in shape except for the size, now the
up-spin and the down-spin were not shifted one from the other.

I guess you misinterprete your results. The sequence of a FSM calculation
is:

x lapw1 -up
cp vector_up vector_dn
cp in2_up in2
x lapw2 -up

x lapw1 -dn
cp vector_dn vector_up
cp in2_dn in2
x lapw2 -dn

Thus at the end of a FSM scf cycle, all you have are the spin-dn vectors
and it does not matter wether you do    x lapw2 -up -qtl   or x lapw2 -dn -qtl,
you get the same qtl-file (and thus DOS)

You must have both vector files for the DOS: i.e. run

x lapw1 -up   (now you have proper spin-up and dn vectors) and

x lapw2 -up -qtl
x lapw2 -dn -qtl

eventually you should also correct for the differences in EF for up/dn
as found in the scf file.

Regards



                                      P.Blaha
Thank you very much, now the calculations are going well
- --------------080903050806000100030000-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 15:47:23 +1000 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: band gaps with slabs ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks for your advice Prof Blaha, I am wondering if you could direct me to some help about backfolding, and back folded states...i have not heard about these before. I am wondering then, to take a band gap from the bandstructure of a slab may not be a trivial task? Thanks for your help! Cheng Quoting Peter Blaha : > ==== > Peter Blaha > submitted the following contribution: > ==== > > Your questions about slabs are quite basic and elementary: > > Suppose you create a cell with two layers (but no vacuum for the moment). > Then > you have "doubled" your primitive unit cell. A doubled real space cell > leads > to a smaller reciprocal cell and since you have twice as many atoms you > MUST > find twice as many bands. In this simple example, the bands at Gamma (in > the > supercell) reflect the original states at gamma (of the small unit cell) > AND the "backfolded" states at the "Z" point of the original cell (where > I suppose that you doubled the z-direction). > > I hope the principle is clear by now. > > When you now take a thicker slab, you get backfolding along the normal of > your surface (i.e. for a (001) surface you get (at Gamma) all the > eigenvalues > from the original gamma-Z line (depending on the number of layers with a > finer or coarser k-grid along this direction). > > Of course the vacuum "disturbs" these states to some extend, so they will > not be exactly the backfolded states, but very close to them. In addition > so called "surface states" can appear, which have nothing in common with > the > "bulk states". > > With this knowledge you should be able to answer your questions alone. > > > I have two questions about bandstructures for slabs, > > > > (1) With slab bandstructures, I have much more bands than the bulk, and at > the > > GAMMA point, the bands do not meet at the same energy. > > > > > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 08:04:01 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: case.int file ==== Peter Blaha submitted the following contribution: ==== > I try to calculate DOS, but I did not found my case.int file when I found > the following files: > > tic.in0 tic.in2_st tic.inm_restart_st > tic.in0_st tic.in2_sy tic.inm_st > tic.in1 tic.in5 tic.inso > tic.in1_st tic.inc tic.inst > tic.in2 tic.inc_st > tic.in2_ls tic.inm > > What should I do to make it work? Go back to the usersguide, chapter getting started. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 08:29:32 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: band gaps with slabs ==== Peter Blaha submitted the following contribution: ==== > Thanks for your advice Prof Blaha, I am wondering if you could direct me to some > help about backfolding, and back folded states...i have not heard about these > before. Trival example for a primitive lattice: You have a lattice parameter a, so the reciprocal space length is 2pi/a. Thus your "X" point has the coordinates pi/a, or along the "delta" line the 1/3 and 2/3 points have the coordinates pi/3a and 2pi/3a. Now you make a slab (supercell) with 6a. Thus your reciprocal lattice vector has a length of 2pi/6a. Therefore the Gamma point of the supercell has all the k-points of K=0, pi/3a, 2pi/3a and pi/a which corresponds the four points mentioned above. In addition, since 1/3 and 2/3 points are inside the BZ, their "weight" is twice that of Gamma or X, so you also find in your slab those eigenvalues twice (leading to the factor of 6 in the number of eigenvalues). (Try it graphically in one dimension and it should be clear.) > I am wondering then, to take a band gap from the bandstructure of a slab may not > be a trivial task? It is trivial! Still the bandgap is between the highest occupied energy and the lowest unoccupied! Plot a bandstructure or a DOS, or simply look into case.output2 to find the band-limits. What is NOT so trivial is to find out from a slab calculation across which k-points of the bulk system the gap is ("direct-indirect" ?) 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 08:57:13 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: sgroup ==== Peter Blaha submitted the following contribution: ==== > It might be due to my limited knowledge on crystallography, but I see > strange behaviour in sgroup. Using the GUI, I want to create group nr. 225 > (Fm-3m), with the atoms on position 8c (point group m-3m). According to > tables, these should have positions 1/4,1/4,1/4 and 1/4,1/4,3/4. In the GUI, > I should enter only 1 position, I choose the 1/4,1/4,1/4. Then, after saving > the structure, it returns two positions: 1/4,1/4,1/4 and the unexpected > 3/4,3/4,3/4. So far, I could assume that the GUI uses another setting for > this structure, so I assume everything could still be all right and proceed. Yes, the positions (1/4,1/4,3/4) and (3/4,3/4,3/4) are of course the same, since they differ only by a "centering" of (1/2,1/2,0). > However, sgroup protests : > > warning: !!! Bravais lattice has changed. > > and recommends group nr. 221 (P m -3 m). If I neglect this warning and go to > symmetry, it asks to shift the origin, and after that the original > multiplicity of 2 becomes 1. Just make a small drawing of your proposed unit cell. In the FCC !! lattice with the 2 position (1/4,1/4,1/4 and 1/4,1/4,3/4) add all "centerings", i.e. add all (1/2,1/2,0)+permutations. You will see that you can describe this with a smaller Primitive!! unit cell of just a/2 lattice parameter and just one atom (at (0,0,0)). > > When I make the struct-file manually, with the two positions according to > the tables : > > F LATTICE,NONEQUIV. ATOMS: 1225_Fm-3m > MODE OF CALC=RELA unit=bohr > 7.558900 7.558900 7.558900 90.000000 90.000000 90.000000 > ATOM= -1: X=0.25000000 Y=0.25000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > ATOM= -1:X= 0.25000000 Y=0.25000000 Z=0.75000000 > Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 0 NUMBER OF SYMMETRY OPERATIONS > > then the same behaviour happens. > > Something similar happens with the most general 192l (1.) position in this > group: the GUI finds only 24 instead of 48 positions, sgroup correctly > detects the group, but symmetry detects as point group m instead of 1 > (actually, it has made 96k instead of 192l). Similar behaviour is seen in > group nr. 229 with the 6b position. > > I am using the latest Wien version. > > Is this a bug, or should I update my crystallography knowledge ? If you select a particular spacegroup X, but occupy just one position (sometimes even a few) it MAY happen that this corresponds actually to a smaller cell with a different spacegroup Y. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 12:48:00 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: sgroup ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > Peter Blaha > submitted the following contribution: > ==== > > If you select a particular spacegroup X, but occupy just one position > (sometimes even a few) it MAY happen that this corresponds actually to > a smaller cell with a different spacegroup Y. Indeed, my three different examples can be traced back to the same wrong assumption that every spacegroup can be made for any single one of its special positions. If I repeat the example nr. 225 and put an atom at position 8c (-43m) AND one at 4a (m-3m), then sgroup and symmetry find the expected information. Thanks, that's clear now. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 17:20:40 -0500 (GMT) From: "Dr. Sharat Chandra" Subject: [WIEN]: AFM and FM calculations ==== "Dr. Sharat Chandra" submitted the following contribution: ==== Hi all I am trying to calculate the properties of LaMnO3 based compounds in which La has been doped by Ca and Mn doped by various electron and hole dopants like Zr, Ru, Al, Fe etc. The space group for LaMnO3 is 62 (Pnma). The lattice constants are a=5.679 b=7.703 c=5.541 and a=b=g=90, where a b and c can change on doping. LaMnO3 ground state is antiferromagnetic which on becomes ferromagnetic when La is doped by >25% Ca. This forms the base compound for our experiments. For calculating the properties of this compound, I have constructed a supercell (1X3X1 cells) and replaced La atoms by Ca. For this configuration, the spacegroup detects triclinic (P 1) space group and symmetry detects orthorhombic system. My question is that for undoped LaMnO3 I have to flip the Mn spins and make the up and down spins of La and O equal for getting the proper anti- ferromagnetic orientation. Do I have to make the up and down spins of La Ca and O equal for LaCaMnO3 also (which is ferromagnetic)? Also, for band structure calculations, should the band structure be calculated by using the Orthorhombic critical points (G -> Z -> T -> Y -> G -> X -> S -> R -> U) or triclinic critical points? Regards Sharat Chandra ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 22:21:07 +0800 From: "yulihua-wuhan" Subject: [WIEN]: Ref of LDA ==== "yulihua-wuhan" submitted the following contribution: ==== Dear Wien2k Users and developers: In the case.in0 , i only find: 5.......CA-LDA 13.....PBE-GGA 14.....PW2-GGA about the XC potential so what is the exact reference of the LDA? ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 17:38:15 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Ref of LDA ==== Peter Blaha submitted the following contribution: ==== > Dear Wien2k Users and developers: > In the case.in0 , i only find: > 5.......CA-LDA > 13.....PBE-GGA > 14.....PW2-GGA > about the XC potential > so what is the exact reference of the LDA? It's in the UG: Perdew-Wang 1992 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 17:40:38 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: Ref of LDA ==== "Kevin Jorissen" submitted the following contribution: ==== 5 : Perdew and Wang 92, reparameterization of Ceperly-Alder data, the recommended LDA option kind regards, Kevin Jorissen EMAT, University of Antwerp as stated in the UG (section about lapw0) - ----- Original Message ----- From: "yulihua-wuhan" To: Sent: Friday, October 04, 2002 4:21 PM Subject: [WIEN]: Ref of LDA > ==== > "yulihua-wuhan" > submitted the following contribution: > ==== > > Dear Wien2k Users and developers: > In the case.in0 , i only find: > 5.......CA-LDA > 13.....PBE-GGA > 14.....PW2-GGA > about the XC potential > so what is the exact reference of the LDA? > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 4 Oct 2002 17:29:45 +0100 (BST) From: Dave Pankhurst Subject: [WIEN]: error in init_lapw ==== Dave Pankhurst submitted the following contribution: ==== Dear wien users, When sgroup finds a new structure you are asked if you would like to continue or edit case.struct_sgroup. At the moment, instead of doing this, the script pops up the case.struct file when you type "y". I presume this is a mistake and line 142 should be: editor $file.struct_sgroup rather than editor $file.struct Is this the desired behaviour? best regards, Dave Pankhurst +---------------------------------+------------------------------------+ | Dr David Pankhurst, | Tel : +44 1865 283325/283326 | | Department of Materials, | Fax : +44 1865 273789 | | University of Oxford, | | | Parks Road, Oxford OX1 3PH, UK | david.pankhurst@materials.ox.ac.uk | +---------------------------------+------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 5 Oct 2002 22:07:18 +0800 From: "yulihua-wuhan" Subject: [WIEN]: semi-core states and valence & klist ==== "yulihua-wuhan" submitted the following contribution: ==== Dear Wien2k Users and developers: Firstly thanks P. Blaha and K.Jorissen, i have seen the Ref of LDA in the UG. Now i have a new question about treating the semi-core states and valence states. I am calculating the band structure of the Ag2PdO2 (semiconductor) using the default choices. the case.inc is: 9 0.00 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT 1,-1,2 ( N,KAPPA,OCCUP) 2,-1,2 ( N,KAPPA,OCCUP) 2, 1,2 ( N,KAPPA,OCCUP) 2,-2,4 ( N,KAPPA,OCCUP) 3,-1,2 ( N,KAPPA,OCCUP) 3, 1,2 ( N,KAPPA,OCCUP) 3,-2,4 ( N,KAPPA,OCCUP) 3, 2,4 ( N,KAPPA,OCCUP) 3,-3,6 ( N,KAPPA,OCCUP) 9 0.00 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT 1,-1,2 ( N,KAPPA,OCCUP) 2,-1,2 ( N,KAPPA,OCCUP) 2, 1,2 ( N,KAPPA,OCCUP) 2,-2,4 ( N,KAPPA,OCCUP) 3,-1,2 ( N,KAPPA,OCCUP) 3, 1,2 ( N,KAPPA,OCCUP) 3,-2,4 ( N,KAPPA,OCCUP) 3, 2,4 ( N,KAPPA,OCCUP) 3,-3,6 ( N,KAPPA,OCCUP) 1 0.00 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT 1,-1,2 ( N,KAPPA,OCCUP) 0 so i think Ag and Pd core states are (1s2s2p3s3p3d), O core states is (1s). The case.inst is: Ag Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Pd Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,2.0 N 5,-1,1.0 N 5,-1,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N **** End of Input **** End of Input so i think Ag and Pd valence states are (4d5s), O valence states are (2s2p). The case.in1 is: WFFIL (WFPRI, SUPWF) 8.50 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 0.30 0.000 CONT 0 0 -6.68 0.005 STOP 0 1 0.30 0.000 CONT 0 1 -3.88 0.005 STOP 0 2 0.30 0.010 CONT 1 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 0.30 0.000 CONT 0 0 -6.23 0.005 STOP 0 1 0.30 0.000 CONT 0 1 -3.62 0.005 STOP 0 2 0.30 0.010 CONT 1 0.30 3 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 -1.55 0.010 CONT 0 ------> 3s LAPW? 0 0.30 0.000 CONT 0 ------> 2s LOs? 1 0.30 0.000 CONT 1 ------>2p APW+lo K-VECTORS FROM UNIT:5 -8.0 2.5 emin/emax window so according to the UG and the step-by-step course of S. Cottenier, i think Ag and Pd (4s4p) are semi-core states treated with LOs, and add 5p to the valence states (unoccupied) . But for the O atoms, the UG said that " If the same l value is specified twice, ......The first energy is used for the usual LAPW's and the second for the LOs", so i think 2s(semi-core) is treated with LOs, and add 3s(unoccupied) to the valence states. But the energy( -1.55Ry) for 3s < (0.30Ry) for 2s. And in the case.inst O (2s2p) is valence states. Where is my errors? I use -in1new 5 to get a new case.in1: WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT .28213 5 0 global e-param with N other choices, napw 0 0.290 0.000 CONT 0 0 -6.090 0.005 CONT 0 1 0.308 0.000 CONT 0 1 -3.411 0.005 CONT 0 2 0.353 0.010 CONT 1 .28213 5 0 global e-param with N other choices, napw 0 0.298 0.000 CONT 0 0 -5.616 0.005 CONT 0 1 0.292 0.000 CONT 0 1 -3.120 0.005 CONT 0 2 0.385 0.010 CONT 1 .28213 3 0 global e-param with N other choices, napw 0 0.342 0.000 CONT 0 ----->3s LAPW ? 0 -0.775 0.010 CONT 0 ----->2s LOs ? 1 0.283 0.000 CONT 1 K-VECTORS FROM UNIT:5 -8.0 3.5 emin/emax window so the energy (0.342Ry) for 3s, (-0.775Ry) for 2s.This is reasonable. The calculation results of two cases are almost same. so i think in the first one: 0 -1.55 0.010 CONT 0 ------> 2s LOs? O 2s is semi-core states, not the valence states specified in the case.inst. 0 0.30 0.000 CONT 0 ------> 3s LAPW? Am i right? And another question about the klist: If the k-points specified in the klist is all in the IBZ, and if only these k-points in the IBZ will be calculated while other is not need to be calculated? At last, In my calculation, like the usual situation, the band gap is underestimated for three versions of the XC potential and LAPW, APW+lo and mixed basis set. So i suggest the developers add the GW quasi-particle correction to this code. Of course maybe that is not need because we obtain many information about the electronic structure. Best regards for everyone! Yulihua ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 5 Oct 2002 21:45:23 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: semi-core states and valence & klist ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_000D_01C26CB8.8239E610 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > I am calculating the band structure of the Ag2PdO2 (semiconductor) = using the default choices. > the case.inc is: > 9 0.00 NUMBER OF ORBITALS (EXCLUDING SPIN), SHIFT > 1,-1,2 ( N,KAPPA,OCCUP) > 2,-1,2 ( N,KAPPA,OCCUP) > 2, 1,2 ( N,KAPPA,OCCUP) > 2,-2,4 ( N,KAPPA,OCCUP) > 3,-1,2 ( N,KAPPA,OCCUP) > 3, 1,2 ( N,KAPPA,OCCUP) > 3,-2,4 ( N,KAPPA,OCCUP) > 3, 2,4 ( N,KAPPA,OCCUP) > 3,-3,6 ( N,KAPPA,OCCUP) ... > so i think Ag and Pd core states are (1s2s2p3s3p3d), O core states is = (1s). You are right about core states. > The case.inst is: > Ag=20 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N ... > so i think Ag and Pd valence states are (4d5s), O valence states are = (2s2p). Although you have also correctly distinguished valence states of O, = valence states of Ag and Pd are 4s^2 4p^6 4d^(10) 5s^1. Valence = (valence+semi core) states are separated from core states selecting = separation energy (S.E.) in wien2k during initialization procedure. = Based on your chosen S.E. configurations of your atoms look like: Ag: [Ar 3d^(10)] 4s^2 4p^6 4d^(10) 5s^1 Pd: [Ar 3d^(10)] 4s^2 4p^6 4d^8 5s^2 O: [He] 2s^2 2p^4 which the ones for Ag and Pd appear different from following standard = electronic configurations: Ag: [Kr] 4d^(10) 5s^1=20 Pd: [Kr] 4d^8 5s^2 Changing S.E. will change the core sates and so number of valence = electrons printed in case.in2 file. I said these because I would emphasis on this point that one should not = utilizing case.inst file try to recognize valence electrons. case.inst = file is an input file for atomic lstart program, and case.inc file is an = input file for lcore program. .in1 is: > WFFIL (WFPRI, SUPWF) > 8.50 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global = APW/LAPW) > 0 0.30 0.000 CONT 0 > 0 -6.68 0.005 STOP 0 > ... > so according to the UG and the step-by-step course of S. Cottenier, i = think Ag and Pd (4s4p) are semi-core states treated > with LOs, and add = 5p to the valence states (unoccupied) . =20 Although you are right again, semi core states of atoms are not what one = can deduce from case.in1 file: just one can justify about added or not = LO's. This means that from case.in1 file one can conclude that for which = orbitals of an atom LO's are added. One may add manually one local = orbital for an atom if it is not already added. This can be easily done = specifying once more (maximum twice) a l-value in case.in1 file keeping = the format. =20 > But for the O atoms, the UG said that " If the same l value is = specified twice, ......The first energy is used for the usual=20 > LAPW's and the second for the LOs", so i think 2s(semi-core) is = treated with LOs, and add 3s(unoccupied) to the valence=20 > states. But the energy( -1.55Ry) for 3s < (0.30Ry) for 2s. And in the = case.inst O (2s2p) is valence states. =20 > Where is my errors?=20 I think it should be clear now considering described above = misunderstanding of case.inst, case.inc, and case.in1 files. =20 > And another question about the klist: > If the k-points specified in the klist is all in the IBZ, and if only = these k-points in the IBZ will be calculated while other is not=20 > need to be calculated? =20 Yes, the other will be predictable employing symmetry. Your, S. Jalali. =20 =20 - ------=_NextPart_000_000D_01C26CB8.8239E610 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> I am calculating = the band=20 structure of the Ag2PdO2 (semiconductor) using the default = choices.
>=20    the case.inc is:
>     9=20 0.00     NUMBER OF ORBITALS (EXCLUDING SPIN), = SHIFT
>=20 1,-1,2           &= nbsp;  =20 ( N,KAPPA,OCCUP)
>=20 2,-1,2           &= nbsp;  =20 ( N,KAPPA,OCCUP)
> 2,=20 1,2           &nbs= p;  =20 ( N,KAPPA,OCCUP)
>=20 2,-2,4           &= nbsp;  =20 ( N,KAPPA,OCCUP)
>=20 3,-1,2           &= nbsp;  =20 ( N,KAPPA,OCCUP)
> 3,=20 1,2           &nbs= p;  =20 ( N,KAPPA,OCCUP)
>=20 3,-2,4           &= nbsp;  =20 ( N,KAPPA,OCCUP)
> 3,=20 2,4           &nbs= p;  =20 ( N,KAPPA,OCCUP)
>=20 3,-3,6           &= nbsp;  =20 ( N,KAPPA,OCCUP)
...

> so i think Ag and Pd = core=20 states are (1s2s2p3s3p3d), O core states is (1s).

 

You are right about core=20 states.


> The = case.inst=20 is:
> Ag
> Kr 3 5
> 4, 2,2.0  N
> 4, = 2,2.0 =20 N

...
> so i = think Ag and Pd=20 valence states are (4d5s), O valence states are (2s2p).

 

Although you have also = correctly=20 distinguished valence states of O,  valence states of Ag and Pd=20 are 4s^2 4p^6 4d^(10) 5s^1. Valence (valence+semi core) = states are=20 separated from core states selecting separation energy (S.E.) in wien2k = during=20 initialization procedure. Based on your chosen S.E. configurations of = your atoms=20 look like:
Ag: [Ar 3d^(10)]  4s^2 4p^6 4d^(10) 5s^1

Pd: [Ar 3d^(10)]  = 4s^2 4p^6=20 4d^8 5s^2

O: [He] 2s^2 = 2p^4

which the ones for Ag and = Pd appear=20 different from following standard electronic configurations:

Ag: = [Kr]  4d^(10)=20 5s^1 =

Pd: [Kr]  4d^8=20 5s^2

Changing S.E. will change = the core=20 sates and so number of valence electrons printed in case.in2 = file.

I said these because = I would=20 emphasis on this point that one should=20 not utilizing case.inst file try to recognize = valence=20 electrons. case.inst file is an input file for atomic lstart program, = and=20 case.inc file is an input file for lcore program.


.in1 is:
>=20 WFFIL        (WFPRI, SUPWF)
> =  =20 8.50       10    4 = (R-MT*K-MAX; MAX=20 L IN WF, V-NMT
>   0.30    5 =20 0      (GLOBAL E-PARAMETER WITH n OTHER = CHOICES, global=20 APW/LAPW)
>  0    = 0.30     =20 0.000 CONT 0
>  0   = - -6.68     =20 0.005 STOP 0
> ...
> so according to the UG and the = step-by-step=20 course of S.=20 Cottenier,=20 i think Ag and Pd  (4s4p) are semi-core states treated > with = LOs, and=20 add 5p to the valence states (unoccupied) .

 

Although you are right = again, semi=20 core states of atoms are not what one can deduce from case.in1 file:=20 just one can justify about added or not LO's. This = means=20 that from case.in1 file one can conclude that for which orbitals of an = atom LO's=20 are added. One may add manually one local orbital for an atom if it is = not=20 already added. This can be easily done specifying once more (maximum = twice)=20 a l-value in case.in1 file keeping the format.

 

> But for the O = atoms, the=20 UG said that " If the same l value is specified twice, ......The first = energy is=20 used for the usual

> LAPW's and the second = for the=20 LOs", so i think 2s(semi-core) is treated with LOs, and add = 3s(unoccupied) to=20 the valence

> states. But the = energy(=20 - -1.55Ry) for 3s <  (0.30Ry) for 2s. And in the case.inst O = (2s2p) is=20 valence states. 

>=20             &= nbsp;         =20 Where is my errors?

I think it should be clear = now=20 considering described above misunderstanding of case.inst, case.inc, and = case.in1 files.


 
> And another = question=20 about the klist:
>  If the k-points specified in the klist is = all in=20 the IBZ, and if only these k-points in the IBZ will be calculated while = other is=20 not

> need to be=20 calculated?

 

Yes, the other will be = predictable=20 employing symmetry.

 

Your,

S. = Jalali.

 

 

 - ------=_NextPart_000_000D_01C26CB8.8239E610-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 00:47:17 +0800 From: "yulihua-wuhan" Subject: [WIEN]: semi-core states and valence states for LOs ==== "yulihua-wuhan" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0045_01C26D9B.16211320 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 RGVhciBXaWVuMmsgVXNlcnMgYW5kIGRldmVsb3BlcnM6DQoNCiAgIEZpcnN0bHkgdGhhbmtzIFMu IEphbGFsaSAuIE5vdyBzb21ldGhpbmcgaXMgY2xlYXIgYW5kIG90aGVyIHRoaW5nIGlzIG5vdCBj bGVhciBmb3IgbWUuDQogIEZpcnN0bHkgdGhlIGNsZWFyIHRoaW5nOg0KICBGcm9tIHRoZSBjYXNl Lm91dHB1dHN0IGZpbGUgKGkgc2VsZWN0IHRoZSBzZXBhcmF0aW9uIGVuZXJneSA9IC0wLjcgUnkp OiANCg0KICAgICBBZw0KLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLg0KICBPUkJJVEFMICAgICAgT0NDVVBBVElPTiAgICAgVFJJQUwgRU5FUkdJRVMNCi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCiAgICAgICA0UyAgICAg ICAgICAgIDEuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0UyAgICAg ICAgICAgIDEuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0UCogICAg ICAgICAgIDEuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0UCogICAg ICAgICAgIDEuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0UCAgICAg ICAgICAgIDIuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0UCAgICAg ICAgICAgIDIuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgICANCiAgICAgICA0RCogICAg ICAgICAgIDIuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgIE4NCiAgICAgICA0RCogICAg ICAgICAgIDIuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgIE4NCiAgICAgICA0RCAgICAg ICAgICAgIDMuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgIE4NCiAgICAgICA0RCAgICAg ICAgICAgIDMuMDAwICAgICAgICAgLTMuNDUxNTYyNUUrMDEgICAgIE4NCiAgICAgICA1UyAgICAg ICAgICAgIDEuMDAwICAgICAgICAgLTIuMjA5MDAwMEUrMDEgICAgIE4NCiAgICAgICA1UyAgICAg ICAgICAgIDAuMDAwICAgICAgICAgLTIuMjA5MDAwMEUrMDEgICAgIE4NCi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KICAgICAgLTI2LjEzNjUwICAgICAgLTI2LjEzNjE5DQog ICAgICAgLTYuOTc4NjcgICAgICAgLTYuOTc5MTYNCiAgICAgICAtNC41NTczMyAgICAgICAtNC41 NTY4MQ0KICAgICAgIC00LjE4Mzg1ICAgICAgIC00LjE4MjkwDQogICAgICAgLTAuNTc2MTMgICAg ICAgLTAuNTYxNTMNCiAgICAgICAtMC41MzU2NCAgICAgICAtMC41MjAxOA0KICAgICAgIC0wLjM0 ODAwICAgICAgIC0wLjI5MDk4DQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0K VE9UQUwgQ09SRS1DSEFSR0U6ICAgICAgICAgICAgICAgICAgIDI4LjAwMDAwMDAwMDAxNTU2ICAg ICANClRPVEFMIENPUkUtQ0hBUkdFIElOU0lERSBTUEhFUkU6ICAgICAyNy45OTk5OTgyNDQ0MTUy MyANCg0KICAgIFBkICAgIA0KLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uDQogICAgICAgNFMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNFMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNFAqICAgICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNFAqICAgICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNFAgICAgICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNFAgICAgICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICAgDQogICAgICAgNEQqICAgICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICBODQogICAgICAgNEQqICAgICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICBODQogICAgICAgNEQgICAgICAgICAgICAzLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICBODQogICAgICAgNEQgICAgICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBF KzAxICAgICBODQogICAgICAgNVMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC0yLjExNjAwMDBF KzAxICAgICBODQogICAgICAgNVMgICAgICAgICAgICAwLjAwMCAgICAgICAgIC0yLjExNjAwMDBF KzAxICAgICBODQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4NCiAgICAgICAtMjMuOTk2OTMgICAgICAtMjMuOTg2MDYNCiAgICAgICAtNi41MzI2MiAg ICAgICAtNi40ODQ0NQ0KICAgICAgIC00LjI0NDM5ICAgICAgIC00LjE5MzYxDQogICAgICAgLTMu OTE2OTUgICAgICAgLTMuODY1MDENCiAgICAgICAtMC41MzYwNiAgICAgICAtMC40NzMwMg0KICAg ICAgIC0wLjUwMTgwICAgICAgIC0wLjQzODI2DQogICAgICAgLTAuMzQ5MDUgICAgICAgLTAuMjc2 NTUNCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0K IFRPVEFMIENPUkUtQ0hBUkdFOiAgICAgICAgICAgICAgICAgICAyOC4wMDAwMDAwMDAwMTk4NiAg ICAgDQogVE9UQUwgQ09SRS1DSEFSR0UgSU5TSURFIFNQSEVSRTogICAgIDI3Ljk5OTk5NjE4MDI0 OTc5ICAgICANCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uDQoNCiAgTw0KLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uDQogICAgICAgMlMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQogICAgICAgMlMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQogICAgICAgMlAqICAgICAgICAgICAxLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQogICAgICAgMlAqICAgICAgICAgICAxLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQogICAgICAgMlAgICAgICAgICAgICAyLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQogICAgICAgMlAgICAgICAgICAgICAwLjAwMCAgICAgICAgIC00LjAw MDAwMDBFKzAwICAgICBODQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLg0KICAgICAgIC0zNy44MzU3NiAgICAgIC0zNy43NDUzNw0KICAg ICAgIC0xLjg1Mjg1ICAgICAgIC0xLjYxNDIzDQogICAgICAgLTAuNzUyNzggICAgICAgLTAuNTI5 NDYNCiAgICAgICAtMC43NTAwMCAgICAgICAtMC41MjY5NQ0KLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCiBUT1RBTCBDT1JFLUNIQVJH RTogICAgICAgICAgICAgICAgICAgMi4wMDAwMDAwMDAwMDE4MzcgICAgIA0KIFRPVEFMIENPUkUt Q0hBUkdFIElOU0lERSBTUEhFUkU6ICAgICAxLjk5OTk5OTk4OTMwNDQ0NCAgICAgDQouLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQoNCnNv IGkgdGhpbmsgdGhlIGNvbmZpZ3VyYXRpb25zIG9mIGF0b21zOg0KQWc6IFtBciAzZF4oMTApXSAg NHNeMiA0cF42IDRkXigxMCkgNXNeMQ0KUGQ6IFtBciAzZF4oMTApXSAgNHNeMiA0cF42IDRkXjkg ICAgIDVzXjEgICAtLS0tLS0tLT4gbm90IDRkXjggNXNeMg0KDQpPOiAgIFtIZV0gMnNeMiAycF40 DQoNCg0KVGhlIHVuY2xlYXIgdGhpbmcgaXMgdGhhdCBmcm9tIGNhc2UuaW4xOg0KDQpXRkZJTCAg ICAgICAgKFdGUFJJLCBTVVBXRikNCiAgOC41MCAgICAgICAxMCAgICA0IChSLU1UKkstTUFYOyBN QVggTCBJTiBXRiwgVi1OTVQNCiAgMC4zMCAgICA1ICAwICAgICAgKEdMT0JBTCBFLVBBUkFNRVRF UiBXSVRIIG4gT1RIRVIgQ0hPSUNFUywgZ2xvYmFsIEFQVy9MQVBXKQ0KIDAgICAgMC4zMCAgICAg IDAuMDAwIENPTlQgMCAgLS0tLT5MQVBXICAgIGZvciA1cz8gIA0KIDAgICAtNi42OCAgICAgIDAu MDA1IFNUT1AgMCAgLS0tLT5MQVBXK0xPIGZvciA0cz8gIA0KIDEgICAgMC4zMCAgICAgIDAuMDAw IENPTlQgMCAgLS0tLT5MQVBXICAgIGZvciA1cD8NCiAxICAgLTMuODggICAgICAwLjAwNSBTVE9Q IDAgIC0tLS0+TEFQVytMTyBmb3IgNHA/DQogMiAgICAwLjMwICAgICAgMC4wMTAgQ09OVCAxICAt LS0tPkxBUFcrbG8gZm9yIDRkIChuZXcgYmFzaXMgc2V0KQ0KICAwLjMwICAgIDUgIDAgICAgICAo R0xPQkFMIEUtUEFSQU1FVEVSIFdJVEggbiBPVEhFUiBDSE9JQ0VTLCBnbG9iYWwgQVBXL0xBUFcp DQogMCAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAwDQogMCAgIC02LjIzICAgICAgMC4wMDUgU1RP UCAwDQogMSAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAwIC0tLS0tPiBzYW1lIGFzIGFib3ZlDQog MSAgIC0zLjYyICAgICAgMC4wMDUgU1RPUCAwDQogMiAgICAwLjMwICAgICAgMC4wMTAgQ09OVCAx DQogIDAuMzAgICAgMyAgMCAgICAgIChHTE9CQUwgRS1QQVJBTUVURVIgV0lUSCBuIE9USEVSIENI T0lDRVMsIGdsb2JhbCBBUFcvTEFQVykNCiAwICAgLTEuNTUgICAgICAwLjAxMCBDT05UIDAgLS0t LS0+IExBUFcgICAgZm9yIDJzPyAgICAgICAgICAgIA0KIDAgICAgMC4zMCAgICAgIDAuMDAwIENP TlQgMCAtLS0tLT4gTEFQVytMTyBmb3IgM3M/DQogMSAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAx IC0tLS0tPiBMQVBXK2xvIGZvciAycCAobmV3IGJhc2lzIHNldCkNCkstVkVDVE9SUyBGUk9NIFVO SVQ6NCAgIC04LjAgICAgICAgMS41ICAgICAgZW1pbi9lbWF4IHdpbmRvdw0KDQpJIGp1c3Qgb25s eSBjYW4gY29uY2x1ZGUgdGhhdCBMT3MgYXJlIGFkZGVkIHRvIFMsUCBmb3IgQWcgYW5kIFBkIGF0 b21zLCBhbmQgTE9zIGFyZSBhZGRlZCB0byBTIGZvciBPIGF0b20uDQpCdXQgaG93IGNhbiBpIGtu b3cgd2hpY2ggb3JiaXRhbHMgYXJlIHRyZWF0ZWQgd2l0aCBMQVBXK0xPIGFuZCB3aGljaCBhcmUg c2VtaS1jb3JlPw0KSWYgaSBjYW4gZGlzdGluZ3Vpc2ggd2hpY2ggb3JiaXRhbHMgb2YgdGhlIGF0 b20gKDJzIG9yIDNzIG9mIE8gYXRvbSkgYXJlIHRyZWF0ZWQgd2l0aCBMQVBXK0xPL0xBUFcgdXNp bmcgdGhlIGxpbmVhcml6YXRpb24gZW5lcmd5Pw0KDQoNCg0KUmVnYXJkcyBmb3IgZXZlcnlvbmUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgeXVsaWh1YQ0KDQoNCg0KDQo= - ------=_NextPart_000_0045_01C26D9B.16211320 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiB4bWxuczpzdDEgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwg NS41MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkRlYXIgV2llbjJrIFVzZXJzIGFuZCBkZXZl bG9wZXJzOjxCUj48QlI+Jm5ic3A7Jm5ic3A7IEZpcnN0bHkgdGhhbmtzIA0KUy4mbmJzcDtKYWxh bGkgLiBOb3cgc29tZXRoaW5nIGlzIGNsZWFyIGFuZCBvdGhlciB0aGluZyBpcyBub3QgY2xlYXIg Zm9yIA0KbWUuPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ Jm5ic3A7IEZpcnN0bHkgdGhlIGNsZWFyIHRoaW5nOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsgRnJvbSB0aGUgY2FzZS5vdXRwdXRz dCBmaWxlIChpIHNlbGVjdCB0aGUgDQpzZXBhcmF0aW9uIGVuZXJneSA9IC0wLjcgUnkpOiA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FnPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsgT1JCSVRBTCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCk9DQ1VQQVRJT04mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVFJJQUwgRU5FUkdJRVM8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjRTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMy40NTE1NjI1RSswMSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQo0UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuNDUxNTYyNUUrMDEmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KNFAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQotMy40NTE1NjI1RSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0UCombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoxLjAw MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjQ1 MTU2MjVFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjRQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMi4wMDAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMy40NTE1NjI1RSswMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo0UCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjIuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuNDUxNTYyNUUrMDEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KNEQqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KMi4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQotMy40NTE1NjI1RSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjREKiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjIuMDAwJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuNDUxNTYy NUUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo0RCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjMuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuNDUxNTYyNUUrMDEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0 RCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCjMuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KLTMuNDUxNTYyNUUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo1UyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEuMDAw Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTIuMjA5 MDAwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQo1UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjAuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTIuMjA5MDAwMEUrMDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTI2LjEzNjUwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KLTI2LjEzNjE5PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCi02Ljk3ODY3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTYuOTc5 MTY8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTQuNTU3MzMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotNC41NTY4MTxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotNC4xODM4NSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCi00LjE4MjkwPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCi0wLjU3NjEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KLTAuNTYxNTM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTAu NTM1NjQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC41MjAxODxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC4zNDgwMCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtMC4yOTA5ODwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 IHNpemU9Mj5UT1RBTCANCkNPUkUtQ0hBUkdFOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjI4LjAwMDAwMDAwMDAxNTU2Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxCUj5UT1RBTCBDT1JFLUNIQVJHRSBJTlNJREUgDQpTUEhFUkU6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDI3Ljk5OTk5ODI0NDQxNTIzJm5ic3A7PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJz cDsgUGQmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjRTJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQotMy4zMDYyNTAwRSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0UyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEu MDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMu MzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNFAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMy4zMDYyNTAwRSswMSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQo0UCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoxLjAwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjMwNjI1MDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjRQ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KMi4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQotMy4zMDYyNTAwRSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0UCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CjIuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K LTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNEQqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMi4wMDAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMy4zMDYyNTAwRSswMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCjREKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCjIuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KLTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0RCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CjMuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K LTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0RCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjIuMDAwJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuMzA2MjUwMEUrMDEmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQo1UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCjEuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTIuMTE2MDAwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo1UyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCjAuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KLTIuMTE2MDAwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQombmJzcDstMjMuOTk2OTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQotMjMuOTg2MDY8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTYu NTMyNjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotNi40ODQ0NTxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotNC4yNDQzOSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi00LjE5MzYxPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjkxNjk1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KLTMuODY1MDE8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KLTAuNTM2MDYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC40 NzMwMjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC41MDE4MCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0wLjQzODI2PEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0wLjM0OTA1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0wLjI3NjU1PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwO1RPVEFMIA0KQ09SRS1DSEFSR0U6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMjguMDAwMDAwMDAwMDE5 ODYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZuYnNwO1RPVEFMIENPUkUtQ0hBUkdFIElO U0lERSANClNQSEVSRTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjcuOTk5OTk2MTgwMjQ5Nzkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7IE88L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyANCjJTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQotNC4wMDAwMDAwRSswMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBOPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjJTJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQotNC4wMDAwMDAwRSswMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjJQKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEuMDAwJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTQuMDAwMDAwMEUrMDAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQoyUCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQoxLjAwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCi00LjAwMDAwMDBFKzAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMlAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoyLjAw MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi00LjAw MDAwMDBFKzAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMlAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQowLjAwMCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi00LjAwMDAwMDBFKzAwJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyANCnNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDst MzcuODM1NzYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMzcuNzQ1Mzc8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTEuODUyODUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMS42MTQyMzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQotMC43NTI3OCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCi0wLjUyOTQ2PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCi0wLjc1MDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0wLjUyNjk1 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+ Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ Jm5ic3A7VE9UQUwgDQpDT1JFLUNIQVJHRTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoyLjAwMDAwMDAwMDAwMTgzNyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8QlI+Jm5ic3A7VE9UQUwgQ09SRS1DSEFSR0UgSU5TSURFIA0KU1BIRVJFOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxLjk5OTk5OTk4OTMwNDQ0NCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0K c2l6ZT0yPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1B cmlhbD5zbyBpIHRoaW5rIHRoZSBjb25maWd1cmF0aW9ucyANCm9mJm5ic3A7YXRvbXM6PEJSPkFn OiBbQXIgM2ReKDEwKV0mbmJzcDsgNHNeMiA0cF42IDRkXigxMCkgNXNeMTxTUEFOIA0Kc3R5bGU9 Im1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIA0Kc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5QZDombmJzcDtbQXImbmJzcDszZF4oMTAp XSZuYnNwOyANCjRzXjIgNHBeNiA0ZF45Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDVzXjEmbmJz cDsmbmJzcDsgLS0tLS0tLS0mZ3Q7IG5vdCA0ZF44IA0KNXNeMjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIA0Kc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5POiZuYnNwOyZuYnNwOyBbSGVdIDJz XjIgDQoycF40PC9TUEFOPjxTUEFOIA0Kc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0 OyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PlRoZSB1bmNsZWFy IHRoaW5nIGlzIHRoYXQgZnJvbSBjYXNlLmluMTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+V0ZGSUwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQooV0ZQUkksIFNVUFdGKTxCUj4mbmJzcDsgOC41MCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEwJm5ic3A7Jm5ic3A7Jm5ic3A7IDQgKFItTVQq Sy1NQVg7IE1BWCBMIElOIFdGLCBWLU5NVDxCUj4mbmJzcDsgDQowLjMwJm5ic3A7Jm5ic3A7Jm5i c3A7IDUmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoR0xPQkFMIA0KRS1Q QVJBTUVURVIgV0lUSCBuIE9USEVSIENIT0lDRVMsIGdsb2JhbCBBUFcvTEFQVyk8QlI+Jm5ic3A7 MCZuYnNwOyZuYnNwOyZuYnNwOyANCjAuMzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MC4wMDAgQ09OVCAwJm5ic3A7IA0KLS0tLSZndDtMQVBXJm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciA1 cz8mbmJzcDsmbmJzcDs8QlI+Jm5ic3A7MCZuYnNwOyZuYnNwOyANCi02LjY4Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMDA1IFNUT1AgMCZuYnNwOyZuYnNwOy0tLS0mZ3Q7TEFQVytM TyANCmZvciZuYnNwOzRzPyZuYnNwOyA8QlI+Jm5ic3A7MSZuYnNwOyZuYnNwOyZuYnNwOyANCjAu MzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4wMDAgQ09OVCAwJm5ic3A7IA0KLS0t LSZndDtMQVBXJm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciA1cD88QlI+Jm5ic3A7MSZuYnNwOyZuYnNw OyANCi0zLjg4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMDA1IFNUT1AgMCZuYnNw OyAtLS0tJmd0O0xBUFcrTE8gZm9yIA0KNHA/PEJSPiZuYnNwOzImbmJzcDsmbmJzcDsmbmJzcDsg MC4zMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAxMCBDT05UIA0KMSZuYnNwOyAt LS0tJmd0O0xBUFcrbG8gZm9yIDRkIChuZXcgYmFzaXMgc2V0KTxCUj4mbmJzcDsgMC4zMCZuYnNw OyZuYnNwOyZuYnNwOyANCjUmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAo R0xPQkFMIEUtUEFSQU1FVEVSIFdJVEggbiBPVEhFUiANCkNIT0lDRVMsIGdsb2JhbCBBUFcvTEFQ Vyk8QlI+Jm5ic3A7MCZuYnNwOyZuYnNwOyZuYnNwOyANCjAuMzAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMC4wMDAgQ09OVCAwPEJSPiZuYnNwOzAmbmJzcDsmbmJzcDsgDQotNi4yMyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAwNSBTVE9QIDA8QlI+Jm5ic3A7MSZuYnNw OyZuYnNwOyZuYnNwOyANCjAuMzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4wMDAg Q09OVCAwIC0tLS0tJmd0OyBzYW1lIGFzIA0KYWJvdmU8QlI+Jm5ic3A7MSZuYnNwOyZuYnNwOyAt My42MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAwNSBTVE9QIA0KMDxCUj4mbmJz cDsyJm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MC4wMTAgQ09OVCANCjE8QlI+Jm5ic3A7IDAuMzAmbmJzcDsmbmJzcDsmbmJzcDsgMyZuYnNwOyAw Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKEdMT0JBTCBFLVBBUkFNRVRFUiBXSVRI IG4gT1RIRVIgQ0hPSUNFUywgZ2xvYmFsIA0KQVBXL0xBUFcpPEJSPiZuYnNwOzAmbmJzcDsmbmJz cDsgLTEuNTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4wMTAgQ09OVCANCjAgLS0t LS0mZ3Q7Jm5ic3A7TEFQVyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgDQoycz8mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8QlI+Jm5ic3A7MCZuYnNwOyZuYnNwOyZuYnNwOyANCjAuMzAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMC4wMDAgQ09OVCAwIC0tLS0tJmd0OyBMQVBXK0xPIGZvciANCjNzPzxCUj4m bmJzcDsxJm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMC4wMDAgQ09OVCAxIA0KLS0tLS0mZ3Q7IExBUFcrbG8gZm9yIDJwIChuZXcgYmFzaXMgc2V0 KTxCUj5LLVZFQ1RPUlMgRlJPTSBVTklUOjQmbmJzcDsmbmJzcDsgDQotOC4wJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuNSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCmVtaW4vZW1heCB3aW5kb3c8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkkganVzdCBvbmx5IGNhbiBjb25jbHVkZSZuYnNwO3RoYXQg TE9zIGFyZSBhZGRlZCB0byANClMsUCBmb3IgQWcgYW5kIFBkIGF0b21zLCBhbmQgTE9zIGFyZSBh ZGRlZCB0byBTIGZvciBPIGF0b20uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPkJ1dCBob3cgY2FuIGkga25vdyB3aGljaCBvcmJpdGFscyBhcmUg dHJlYXRlZCB3aXRoIA0KTEFQVytMTyBhbmQgd2hpY2ggYXJlIHNlbWktY29yZT88L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+SWYgaSBjYW4gZGlz dGluZ3Vpc2ggd2hpY2ggb3JiaXRhbHMgb2YgdGhlIGF0b20gKDJzIG9yIA0KM3Mgb2YgTyBhdG9t KSBhcmUgdHJlYXRlZCB3aXRoIExBUFcrTE8vTEFQVyB1c2luZyB0aGUgbGluZWFyaXphdGlvbiAN CmVuZXJneT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPTM+UmVnYXJkcyBmb3IgDQpldmVyeW9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnl1bGlodWE8L0ZPTlQ+PEJSPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRk9OVD4mbmJzcDs8L0RJ Vj48L0JPRFk+PC9IVE1MPg0K - ------=_NextPart_000_0045_01C26D9B.16211320-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 00:10:33 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: semi-core states and valence states for LOs ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0037_01C26D95.F41189E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Now something is clear and other thing is > not clear for me. > Firstly the clear thing: > From the case.outputst file (i select the separation energy =3D -0.7 > Ry):=20 >=20 > Ag > -26.13650 -26.13619 > -6.97867 -6.97916 > -4.55733 -4.55681 > -4.18385 -4.18290 > -0.57613 -0.56153 > -0.53564 -0.52018 > -0.34800 -0.29098 > ................................... > TOTAL CORE-CHARGE: 28.00000000001556 =20 > TOTAL CORE-CHARGE INSIDE SPHERE: 27.99999824441523=20 You did perfect reducing S.E. to -7.0Ry. In this case 2 electrons of 4s = orbital is considered as a valence state. -6.0Ry confines these two = electrons into core states, and so they leaks out of sphere as they are = not really core electrons. This is something similar to the nice Fe = example presented in the beautiful textbook of Stefaan. > Pd =20 > -23.99693 -23.98606 > -6.53262 -6.48445 > -4.24439 -4.19361 > -3.91695 -3.86501 > -0.53606 -0.47302 > -0.50180 -0.43826 > -0.34905 -0.27655 > ................................................... > TOTAL CORE-CHARGE: 28.00000000001986 =20 > TOTAL CORE-CHARGE INSIDE SPHERE: 27.99999618024979 =20 > ........................................................ Here in Pd we also have a similar situation to Ag. >=20 > O > -37.83576 -37.74537 > -1.85285 -1.61423 > -0.75278 -0.52946 > -0.75000 -0.52695 > ........................................................... > TOTAL CORE-CHARGE: 2.000000000001837 =20 > TOTAL CORE-CHARGE INSIDE SPHERE: 1.999999989304444 =20 > .......................................................... For O only -2.0Ry seems enough, but considering Ag and Pd atoms one = should choose still -7.0Ry. =20 > so i think the configurations of atoms: > Ag: [Ar 3d^(10)] 4s^2 4p^6 4d^(10) 5s^1 > Pd: [Ar 3d^(10)] 4s^2 4p^6 4d^9 5s^1 --------> not 4d^8 5s^2 >=20 > O: [He] 2s^2 2p^4 I don't know how you find that configuration for Pd! > The unclear thing is that from case.in1: >=20 > WFFIL (WFPRI, SUPWF) > 8.50 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global > APW/LAPW) > 0 0.30 0.000 CONT 0 ---->LAPW for 5s? =20 > 0 -6.68 0.005 STOP 0 ---->LAPW+LO for 4s? =20 > 1 0.30 0.000 CONT 0 ---->LAPW for 5p? > 1 -3.88 0.005 STOP 0 ---->LAPW+LO for 4p? > 2 0.30 0.010 CONT 1 ---->LAPW+lo for 4d (new basis set) > 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global > APW/LAPW) > 0 0.30 0.000 CONT 0 > 0 -6.23 0.005 STOP 0 > 1 0.30 0.000 CONT 0 -----> same as above > 1 -3.62 0.005 STOP 0 > 2 0.30 0.010 CONT 1 > 0.30 3 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global > APW/LAPW) > 0 -1.55 0.010 CONT 0 -----> LAPW for 2s? =20 > 0 0.30 0.000 CONT 0 -----> LAPW+LO for 3s? > 1 0.30 0.000 CONT 1 -----> LAPW+lo for 2p (new basis set) > K-VECTORS FROM UNIT:4 -8.0 1.5 emin/emax window >=20 > I just only can conclude that LOs are added to S,P for Ag and Pd = atoms, > and LOs are added to S for O atom. > But how can i know which orbitals are treated with LAPW+LO and which = are > semi-core? Of coarse, you can guess these LO's are added to make a better treatment = for 4s 4p of Ag and Pd and for 2s of O, as they are deeper in energy = scale comparing the other valence orbitals. To make more sure which = orbitals and how many electrons are in semi core states and if added = LO's have done their jobs one can plot density of states in semi core = region or look into case.ouputt or case.outpu2. > If i can distinguish which orbitals of the atom (2s or 3s of O atom) = are > treated with LAPW+LO/LAPW using the linearization energy? Yes, I think you have marked correctly the way of treatments in the = case.in1 file. Your, S. Jalali. - ------=_NextPart_000_0037_01C26D95.F41189E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Now something is clear and other = thing=20 is
> not clear for me.
>   Firstly the clear=20 thing:
>   From the case.outputst file (i select the = separation=20 energy =3D -0.7
> Ry):
> =
>     =20 Ag
>      =20 - -26.13650     =20 - -26.13619
>       =20 - -6.97867      =20 - -6.97916
>       =20 - -4.55733      =20 - -4.55681
>       =20 - -4.18385      =20 - -4.18290
>       =20 - -0.57613      =20 - -0.56153
>       =20 - -0.53564      =20 - -0.52018
>       =20 - -0.34800       -0.29098
>=20 ...................................
> TOTAL=20 CORE-CHARGE:          &= nbsp;       =20 28.00000000001556    
> TOTAL CORE-CHARGE = INSIDE=20 SPHERE:     27.99999824441523 
You did perfect reducing S.E. to = - -7.0Ry. In=20 this case 2 electrons of 4s orbital is considered as a valence = state.=20 - -6.0Ry confines these two electrons into core states, and so they leaks = out of=20 sphere as they are not really core electrons. This is something similar = to the=20 nice Fe example presented in the beautiful textbook of = Stefaan.
 
>     = Pd   =20
>       =20 - -23.99693     =20 - -23.98606
>       =20 - -6.53262      =20 - -6.48445
>       =20 - -4.24439      =20 - -4.19361
>       =20 - -3.91695      =20 - -3.86501
>       =20 - -0.53606      =20 - -0.47302
>       =20 - -0.50180      =20 - -0.43826
>       =20 - -0.34905       -0.27655
>=20 ...................................................
>  TOTAL=20 CORE-CHARGE:          &= nbsp;       =20 28.00000000001986    
>  TOTAL = CORE-CHARGE=20 INSIDE SPHERE:     = 27.99999618024979    =20
>=20 ........................................................
=
Here in Pd we also have a similar = situation to=20 Ag.
 
>
>  =20 O
>       =20 - -37.83576     =20 - -37.74537
>       =20 - -1.85285      =20 - -1.61423
>       =20 - -0.75278      =20 - -0.52946
>       =20 - -0.75000       -0.52695
>=20 ...........................................................
> = TOTAL=20 CORE-CHARGE:          &= nbsp;       =20 2.000000000001837    
>  TOTAL = CORE-CHARGE=20 INSIDE SPHERE:     = 1.999999989304444    =20
>=20 ..........................................................
For O only -2.0Ry seems enough, but = considering Ag=20 and Pd atoms one should choose still -7.0Ry.
 
> so i think the = configurations of=20 atoms:
> Ag: [Ar 3d^(10)]  4s^2 4p^6 4d^(10) 5s^1
> Pd: = [Ar=20 3d^(10)]  4s^2 4p^6 4d^9     5s^1  =20 - --------> not 4d^8 5s^2
>
> O:   [He] 2s^2=20 2p^4
I don't know how you find that = configuration for=20 Pd!
> The unclear thing is that from=20 case.in1:
>
> = WFFIL       =20 (WFPRI, SUPWF)
>   = 8.50      =20 10    4 (R-MT*K-MAX; MAX L IN WF, = V-NMT
>  =20 0.30    5  0      (GLOBAL=20 E-PARAMETER WITH n OTHER CHOICES, global
> APW/LAPW)
>  = 0    0.30      0.000 CONT = 0 =20 - ---->LAPW    for 5s? 
>  = 0  =20 - -6.68      0.005 STOP 0  ---->LAPW+LO = for=20 4s? 
>  1    = 0.30     =20 0.000 CONT 0  ---->LAPW    for 5p?
> =20 1   -3.88      0.005 STOP 0 =20 - ---->LAPW+LO for 4p?
>  2   =20 0.30      0.010 CONT 1  ---->LAPW+lo = for 4d=20 (new basis set)
>   0.30    5 =20 0      (GLOBAL E-PARAMETER WITH n OTHER = CHOICES,=20 global
> APW/LAPW)
>  0   =20 0.30      0.000 CONT 0
>  = 0  =20 - -6.23      0.005 STOP 0
> =20 1    0.30      0.000 CONT 0 = - ----->=20 same as above
>  1   = - -3.62     =20 0.005 STOP 0
>  2   =20 0.30      0.010 CONT 1
>  =20 0.30    3  0      (GLOBAL=20 E-PARAMETER WITH n OTHER CHOICES, global
> APW/LAPW)
>  = 0   -1.55      0.010 CONT 0 -----> = LAPW    for=20 2s?           =20
>  0    0.30      = 0.000 CONT=20 0 -----> LAPW+LO for 3s?
>  1   =20 0.30      0.000 CONT 1 -----> LAPW+lo for 2p = (new=20 basis set)
> K-VECTORS FROM UNIT:4  =20 - -8.0       = 1.5     =20 emin/emax window
>
> I just only can conclude that LOs are = added to=20 S,P for Ag and Pd atoms,
> and LOs are added to S for O = atom.
> But=20 how can i know which orbitals are treated with LAPW+LO and which = are
>=20 semi-core?
Of coarse, you can guess these LO's are added to make a = better=20 treatment for 4s 4p of Ag and Pd and for 2s of O, as they are deeper in = energy=20 scale comparing the other valence orbitals. To make more sure which = orbitals and=20 how many electrons are in semi core states and if added LO's have done = their=20 jobs one can plot density of states in semi core region or = look into=20 case.ouputt or case.outpu2.
 
> If i can distinguish which = orbitals of the=20 atom (2s or 3s of O atom) are
> treated with LAPW+LO/LAPW using = the=20 linearization energy?
Yes, I think = you have=20 marked correctly the way of treatments in the case.in1 = file.
 
Your,
S. Jalali.
- ------=_NextPart_000_0037_01C26D95.F41189E0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 09:30:47 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: error in init_lapw ==== Peter Blaha submitted the following contribution: ==== > When sgroup finds a new structure you are asked if you would like to > continue or edit case.struct_sgroup. At the moment, instead of doing > this, the script pops up the case.struct file when you type "y". I > presume this is a mistake and line 142 should be: > > editor $file.struct_sgroup > > rather than > > editor $file.struct Yes, you are right. It will be changed with the next update. Thanks 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 15:50:28 +0800 From: "yulihua-wuhan" Subject: Re: [WIEN]: semi-core states and valence states for LOs ==== "yulihua-wuhan" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0030_01C26E19.4236F190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBXaWVuMmsgVXNlcnMgYW5kIGRldmVsb3BlcnM6DQoNCiAgIFRoYW5rcyBTLiBKYWxhbGkg Lg0KDQogICBGcm9tIHRoZSBjYXNlLm91dHB1dHN0IGZpbGU6IA0KICAgIFBkICAgIA0KLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQogICAgICAgNFMgICAg ICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNFMgICAg ICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNFAqICAg ICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNFAqICAg ICAgICAgICAxLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNFAgICAg ICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNFAgICAg ICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICAgDQogICAgICAgNEQqICAg ICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICBODQogICAgICAgNEQqICAg ICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICBODQogICAgICAgNEQgICAg ICAgICAgICAzLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICBODQogICAgICAgNEQgICAg ICAgICAgICAyLjAwMCAgICAgICAgIC0zLjMwNjI1MDBFKzAxICAgICBOICAtLS0tLS0+DQogICAg ICAgNVMgICAgICAgICAgICAxLjAwMCAgICAgICAgIC0yLjExNjAwMDBFKzAxICAgICBOICAtLS0t LS0+IGhlcmUgDQogICAgICAgNVMgICAgICAgICAgICAwLjAwMCAgICAgICAgIC0yLjExNjAwMDBF KzAxICAgICBODQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4NCiAgICAgICAtMjMuOTk2OTMgICAgICAtMjMuOTg2MDYNCiAgICAgICAtNi41MzI2MiAg ICAgICAtNi40ODQ0NQ0KICAgICAgIC00LjI0NDM5ICAgICAgIC00LjE5MzYxDQogICAgICAgLTMu OTE2OTUgICAgICAgLTMuODY1MDENCiAgICAgICAtMC41MzYwNiAgICAgICAtMC40NzMwMg0KICAg ICAgIC0wLjUwMTgwICAgICAgIC0wLjQzODI2DQogICAgICAgLTAuMzQ5MDUgICAgICAgLTAuMjc2 NTUNCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAN CkkgdGhpbmsgdGhlIGNvbmZpZ3VyYXRpb25zIG9mIFBkIGF0b206DQogUGQ6IFtBciAzZF4oMTAp XSAgNHNeMiA0cF42IDRkXjkgNXNeMSAgIC0tLS0tLS0tPiBub3QgNGReOCA1c14yDQpUaGUgVUcg ZGVzY3JpYmUgdGhlIHNpdHVhdGlvbiBvZiB0aGUgQ3UgaW4gTFNUQVJUIHNlY3Rpb24uDQoNClRo YW5rcyBmb3IgdGltZSAgICAgICAgICAgICAgICAgICAgICAgICAgIHl1bGlodWENCg0K - ------=_NextPart_000_0030_01C26E19.4236F190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDUyMi4xODAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5EZWFyIFdpZW4yayBVc2VycyBhbmQgZGV2 ZWxvcGVyczo8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rcyANClMuJm5ic3A7SmFsYWxp IC48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOzxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+RnJvbSB0aGUgY2FzZS5vdXRwdXRzdCBmaWxlOiA8L0ZPTlQ+DQo8RElW PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBk Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IA0Kc2l6ZT0yPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0UyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCjEuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KLTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNFMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoxLjAwMCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjMwNjI1 MDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjRQKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjEuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KNFAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQotMy4zMDYyNTAwRSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo0UCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCjIuMDAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KLTMuMzA2MjUwMEUrMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNFAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoyLjAw MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjMw NjI1MDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjREKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjIuMDAwJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTMuMzA2MjUwMEUrMDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQo0RCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQoyLjAwMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCi0zLjMwNjI1MDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNEQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQozLjAw MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjMw NjI1MDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNEQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoyLjAwMCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0zLjMwNjI1MDBFKzAxJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE4mbmJzcDsgDQotLS0tLS0mZ3Q7PEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCjVTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMS4wMDAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMi4xMTYwMDAwRSswMSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBOJm5ic3A7Jm5ic3A7LS0tLS0tJmd0OyANCmhlcmUmbmJzcDs8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KNVMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQowLjAw MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0yLjEx NjAwMDBFKzAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KJm5ic3A7LTIzLjk5NjkzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTIzLjk4 NjA2PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi02LjUzMjYyJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTYuNDg0NDU8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTQuMjQ0MzkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQotNC4xOTM2MTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQotMy45MTY5NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCi0zLjg2NTAxPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi0w LjUzNjA2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTAuNDczMDI8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLTAuNTAxODAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC40MzgyNjxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQotMC4zNDkwNSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtMC4yNzY1NTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IA0Kc2l6ZT0yPi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+SSZuYnNwO3RoaW5rIHRoZSBjb25maWd1cmF0aW9ucyBvZiBQZCANCmF0b206PEJSPiZu YnNwO1BkOiBbQXIgM2ReKDEwKV0mbmJzcDsgNHNeMiA0cF42IDRkXjkmbmJzcDs1c14xJm5ic3A7 Jm5ic3A7IA0KLS0tLS0tLS0mZ3Q7IG5vdCA0ZF44IDVzXjI8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+VGhlIFVHIGRlc2NyaWJlIHRoZSANCnNpdHVhdGlvbiBv ZiB0aGUgQ3UgaW4gTFNUQVJUIHNlY3Rpb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5UaGFua3MgZm9yIA0KdGltZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnl1bGlodWE8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxGT05UIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== - ------=_NextPart_000_0030_01C26E19.4236F190-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 07 Oct 2002 16:45:39 +0200 From: Ingo Loa Subject: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== Ingo Loa submitted the following contribution: ==== Dear Wien2k team & users, when looking at the pressure-induced bcc-to-fcc transition in Cs by total-energy calculations, I recently encountered the following difficulties. I could easily converge the total energy as a function of RKMAX and number of k-points. Convergence with regard to GMAX, however, was extremely slow. Even with GMAX values as large as 50, the total energy of the bcc phase was still not converged on the 1-meV/atom level. This appears rather unusual to me, especially, because it occurs in a fairly simple system. A summary of typical input files is given below, the calculations were performed with a recent release of Wien2k. Does anybody have an idea of what may cause these troubles or how to proceed? Any comments/suggestions are welcome. Regards, Ingo Loa ************************************************************************* Cs-bcc.struct: Cs-bcc B LATTICE,NONEQUIV. ATOMS: 1 MODE OF CALC=RELA unit=ang 11.515569 11.515569 11.515569 90.000000 90.000000 90.000000 ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Cs NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 55.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 48 NUMBER OF SYMMETRY OPERATIONS - -------------------------------------------------------------------------- Cs-bcc.in0: TOT 13 (5...CA-LDA, 13...PBE-GGA, 14...PW2-GGA) NR2V (R2V) - -------------------------------------------------------------------------- Cs-bcc.in1: WFFIL (WFPRI, SUPWF) 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT -.14794 6 0 global e-param with N other choices, napw 0 0.103 0.000 CONT 1 0 -1.602 0.000 CONT 1 1 0.116 0.000 CONT 1 1 -0.633 0.000 CONT 1 2 0.132 0.000 CONT 1 2 -5.087 0.000 CONT 1 K-VECTORS FROM UNIT:4 -8.0 2.5 emin/emax window - -------------------------------------------------------------------------- Cs-bcc.in2: TOT (TOT,FOR,QTL,EFG,FERMI) -9.0 19.0 0.50 0.05 EMIN, NE, ESEPERMIN, ESEPER0 TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) 0 0 4 0 4 4 6 0 6 4 55. GMAX FILE FILE/NOFILE write recprlist - -------------------------------------------------------------------------- Cs-bcc.klist: 165 k-points in the irreducible wedge, 4913 points in total. - -------------------------------------------------------------------------- - -------------------------------------------------------------------------- Ingo Loa Max-Planck-Institut fuer Festkoerperforschung, Stuttgart Heisenbergstr. 1 // D-70569 Stuttgart // Germany Tel. +49.711.689-1469 // Fax. +49.711.689-1444 I.Loa@fkf.mpg.de // http://www.mpi-stuttgart.mpg.de/hd - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 17:45:28 +0200 From: "koitzsch" Subject: [WIEN]: open core treatment ==== "koitzsch" submitted the following contribution: ==== Hi Everybody, I have a question regarding an open core treatment of 4f electrons in a rare earth silicide, specifically GdSi. My Case.struct looks like this: Title H LATTICE,NONEQUIV. ATOMS: 2 MODE OF CALC=RELA 7.318912 7.318912 7.904728 90.000000 90.000000120.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 4 Gd NPT= 781 R0=0.00001000 RMT= 3.0000 Z: 64.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.33333333 Y=0.66666667 Z=0.50000000 MULT= 2 ISPLIT= 4 -2: X=0.66666667 Y=0.33333333 Z=0.50000000 Si NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 14.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 24 NUMBER OF SYMMETRY OPERATIONS As outlined in the FAQ section, I ran a SCF cycle conventionally, and looked, where my 4f's are in case.scf OVERALL ENERGY PARAMETER IS 0.3000 E( 0)= 0.3000 E( 0)= -2.4675 E(BOTTOM)= -2.515 E(TOP)= -2.420 E( 1)= -0.8650 E(BOTTOM)= -1.030 E(TOP)= -0.700 E( 1)= 0.3000 E( 3)= 0.6150 E(BOTTOM)= 0.580 E(TOP)= 0.650 E( 2)= 0.5100 E(BOTTOM)= 0.510 E(TOP)= -200.000 So, as far as I understand, a shift of 0.7 would be sufficient I modifief then, case.inc to get the half filled 4f shell into core (number of orbitals changed from 14 to 16 and inluded 4, 3,3 and 4,-4,4 and specified a shift of 0.7: 16 0.70 NUMBER OF ORBITALS (EXCLUDING SPIN) 1,-1,2 ( N,KAPPA,OCCUP) 2,-1,2 ( N,KAPPA,OCCUP) 2, 1,2 ( N,KAPPA,OCCUP) 2,-2,4 ( N,KAPPA,OCCUP) 3,-1,2 ( N,KAPPA,OCCUP) 3, 1,2 ( N,KAPPA,OCCUP) 3,-2,4 ( N,KAPPA,OCCUP) 3, 2,4 ( N,KAPPA,OCCUP) 3,-3,6 ( N,KAPPA,OCCUP) 4,-1,2 ( N,KAPPA,OCCUP) 4, 1,2 ( N,KAPPA,OCCUP) 4,-2,4 ( N,KAPPA,OCCUP) 4, 2,4 ( N,KAPPA,OCCUP) 4,-3,6 ( N,KAPPA,OCCUP) 4, 3,3 4,-4,4 4 NUMBER OF ORBITALS (EXCLUDING SPIN) 1,-1,2 ( N,KAPPA,OCCUP) 2,-1,2 ( N,KAPPA,OCCUP) 2, 1,2 ( N,KAPPA,OCCUP) 2,-2,4 ( N,KAPPA,OCCUP) 0 Then I modified case.in1 and put the 4f's fixed at -1 WFFIL (WFPRI, SUPWF) 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 0 -3.43 0.005 STOP 1 -1.67 0.010 CONT 1 0.30 0.000 CONT 3 -1.00 0.000 CONT 2 0.30 0.010 CONT 0.30 2 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 1 0.30 0.000 CONT K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window and finally I removed the 7 4f's from valence charge and reduced therefore NE from 26 to 19 in case.in2 WFFIL (WFPRI, SUPWF) 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 0 -3.43 0.005 STOP 1 -1.67 0.010 CONT 1 0.30 0.000 CONT 3 -1.00 0.000 CONT 2 0.30 0.010 CONT 0.30 2 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 1 0.30 0.000 CONT K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window Nevertheless I get then after running again dstart and having a mixing parameter of 0.01 the following error messages: LAPW0 END LAPW1 END LAPW2 END forrtl: severe (64): input conversion error, unit 20, file /home/koitzsch/GdSi/GdSi.struct 0: _call_remove_gp_range [0x3ff81a6c374] 1: _call_remove_gp_range [0x3ff81a6c8f4] 2: _call_remove_gp_range [0x3ff81a93b84] 3: _call_remove_gp_range [0x3ff81a926e0] 4: insld_ [insld.f: 92, 0x12000928c] 5: hfsd_ [hfsd.f: 127, 0x120005ffc] 6: main [for_main.c: 203, 0x120002554] 7: __start [0x1200024c8] Does anybody know, what I am doing wrong here. Thank you for any suggestions Christian Koitzsch University of Fribourg Department of Physics CH-1700 Fribourg Switzerland ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 07 Oct 2002 17:55:15 +0200 From: Florent Boucher Subject: [WIEN]: Pb SRC_lapw2/atpar.F and lxdos ==== Florent Boucher submitted the following contribution: ==== Dear Peter, we are trying to use the ISPLIT=99 option in WIEN2K (latest version) and we have troubles with the atpar.F program. In the distributed version they are comments for the following lines: ! !....overlap integrals for x-dos ! !!$ do l=0,lxdos !!$ do lp=0,lxdos !!$ pu1u2(l,lp)=0.d0 !!$ pueu2(l,lp)=0.d0 !!$ pu2u2(l,lp)=0.d0 !!$ CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rrad1(1,lp) & !!$ ,rrad2(1,lp),pu1u1(l,lp),JATOM) !!$ CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rade1(1,lp) & !!$ ,rade2(1,lp),pu1ue(l,lp),JATOM) !!$ if(lp.le.lmax2) CALL RINT13(REL,rrad1(1,l),rrad2(1,l) & !!$ ,a1lo(1,lp),b1lo(1,lp),pu1u2(l,lp),JATOM) !!$ CALL RINT13(REL,rade1(1,l),rade2(1,l),rade1(1,lp) & !!$ ,rade2(1,lp),pueue(l,lp),JATOM) !!$ if(lp.le.lmax2) CALL RINT13(REL,rade1(1,l),rade2(1,l) & !!$ ,a1lo(1,lp),b1lo(1,lp),pueu2(l,lp),JATOM) !!$ if((lp.le.lmax2).and.(l.le.lmax2)) CALL RINT13(REL,a1lo(1,l) & !!$ ,b1lo(1,l),a1lo(1,lp),b1lo(1,lp),pu2u2(l,lp),JATOM) !!$ enddo !!$ enddo For this reason, the qtl file and help files have only zero values (pu1u1, pueue .... are not initialized) When we try to remove the comments, we are unable to compile. We have the following errors as the dimension of the array has changed in order to use multiple LO. a1lo(1:nrad,1:nloat,0:lomax) Here is the error: f90: Error: atpar_tmp_.F, line 281: The number of subscripts is incorrect. [A1LO] ,a1lo(1,lp),b1lo(1,lp),pu1u2(l,lp),JATOM) - ------------------^ f90: Error: atpar_tmp_.F, line 281: The number of subscripts is incorrect. [B1LO] ,a1lo(1,lp),b1lo(1,lp),pu1u2(l,lp),JATOM) - -----------------------------^ f90: Error: atpar_tmp_.F, line 285: The number of subscripts is incorrect. [A1LO] ,a1lo(1,lp),b1lo(1,lp),pueu2(l,lp),JATOM) - ------------------^ f90: Error: atpar_tmp_.F, line 285: The number of subscripts is incorrect. [B1LO] ,a1lo(1,lp),b1lo(1,lp),pueu2(l,lp),JATOM) - -----------------------------^ f90: Error: atpar_tmp_.F, line 286: The number of subscripts is incorrect. [A1LO] if((lp.le.lmax2).and.(l.le.lmax2)) CALL RINT13(REL,a1lo(1,l) & - ---------------------------------------------------------------^ f90: Error: atpar_tmp_.F, line 287: The number of subscripts is incorrect. [B1LO] ,b1lo(1,l),a1lo(1,lp),b1lo(1,lp),pu2u2(l,lp),JATOM) - ------------------^ f90: Error: atpar_tmp_.F, line 287: The number of subscripts is incorrect. [A1LO] ,b1lo(1,l),a1lo(1,lp),b1lo(1,lp),pu2u2(l,lp),JATOM) - ----------------------------^ f90: Error: atpar_tmp_.F, line 287: The number of subscripts is incorrect. [B1LO] ,b1lo(1,l),a1lo(1,lp),b1lo(1,lp),pu2u2(l,lp),JATOM) - ---------------------------------------^ * Do you think you can do something about that ? Regards Florent - -- -------------------------------------------------------------------------- | Florent BOUCHER | | | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 18:01:19 +0200 From: "Stefaan Cottenier" Subject: Re: [WIEN]: open core treatment ==== "Stefaan Cottenier" submitted the following contribution: ==== > LAPW0 END > LAPW1 END > LAPW2 END > forrtl: severe (64): input conversion error, unit 20, file > /home/koitzsch/GdSi/GdSi.struct > 0: _call_remove_gp_range [0x3ff81a6c374] > 1: _call_remove_gp_range [0x3ff81a6c8f4] > 2: _call_remove_gp_range [0x3ff81a93b84] > 3: _call_remove_gp_range [0x3ff81a926e0] > 4: insld_ [insld.f: 92, 0x12000928c] > 5: hfsd_ [hfsd.f: 127, 0x120005ffc] > 6: main [for_main.c: 203, 0x120002554] > 7: __start [0x1200024c8] > > Does anybody know, what I am doing wrong here. Your problem is in lcore. Two suggestions : 1) Try to fill first the core orbitals like this (completely fill one, and only then go to the next): > 4, 3,6 > 4,-4,1 2) Try a slightly larger shift (0.8, 0.9). Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 11:08:22 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: min_lapw ==== Bing Zhou submitted the following contribution: ==== Dear All: After the SCF cycles, I run min_lapw, it stoped after 5 cycles with the following information on my screen: run_lapw -I -fc 1. -renorm -i 40 hup: Command not found STOP: MIXER END in cycle 2 ETEST: 0 CTEST: 0 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 3 ETEST: 11732.1216010000000000 CTEST: .0410162 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 4 ETEST: 5866.5759085000000000 CTEST: .0398830 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 5 ETEST: .7647320000000000 CTEST: .0390583 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END STOP: MINI - Error I checked the case.file as following: Calculating chiolite in /local/project00/umbingz/mysamples/chiolite on mira start (Wednesday October 2 17:35:21 CDT 2002) with mixer (40/20 to go) > mixer (17:35:21) 13.0u 0.0s 1:05 19% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 0 :CHARGE convergence: 0 0 0 cycle 2 (Wednesday October 2 17:36:30 CDT 2002) cycle 2 (39/19 to go) > lapw0 (17:36:30) 69.0u 0.0s 4:45 24% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (17:41:43) 45834.0u 108.0s 23:20:29 54% 0+0k 0+0io 0pf+0w > lapw2 (17:02:14) 2228.0u 44.0s 46:20 81% 0+0k 0+0io 0pf+0w > lcore (17:48:35) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (17:48:44) 13.0u 0.0s 0:16 77% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 11732.1216010000000000 :CHARGE convergence: 0 0 .0410162 cycle 3 (Thursday October 3 17:49:05 CDT 2002) cycle 3 (38/18 to go) > lapw0 (17:49:05) 73.0u 0.0s 1:24 86% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (17:50:44) 46437.0u 143.0s 14:39:53 88% 0+0k 0+0io 0pf+0w > lapw2 (08:30:38) 2148.0u 38.0s 42:03 86% 0+0k 0+0io 0pf+0w > lcore (09:12:42) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (09:12:52) 13.0u 0.0s 0:17 76% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 5866.5759085000000000 :CHARGE convergence: 0 0 .0398830 cycle 4 (Friday October 4 09:13:13 CDT 2002) cycle 4 (37/17 to go) > lapw0 (09:13:13) 71.0u 0.0s 1:18 90% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (09:14:44) 45305.0u 117.0s 16:42:28 75% 0+0k 0+0io 0pf+0w > lapw2 (01:57:13) 2048.0u 38.0s 39:18 88% 0+0k 0+0io 0pf+0w > lcore (02:36:32) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (02:36:41) 13.0u 0.0s 0:15 83% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 .7647320000000000 :CHARGE convergence: 0 0 .0390583 cycle 5 (Saturday October 5 02:36:59 CDT 2002) cycle 5 (36/16 to go) > lapw0 (02:36:59) 68.0u 0.0s 1:13 92% 0+0k 0+0io 0pf+0w :FORCE convergence: 1 1. 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO .1155000000000000 XCO .2215000000000000 XCO > lapw1 (02:38:36) 43686.0u 175.0s 12:45:03 95% 0+0k 0+0io 0pf+0w > lapw2 (15:23:40) 16605.0u 39.0s 5:16:03 87% 0+0k 0+0io 0pf+0w > lcore (20:39:44) 0.0u 0.0s 0:01 0% 0+0k 0+0io 0pf+0w > mixer (20:39:55) 13.0u 0.0s 0:16 79% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 .7540850000000000 :CHARGE convergence: 0 0 .0381198 cycle 6 (Saturday October 5 20:40:14 CDT 2002) cycle 6 (0/15 to go) > stop > mini (20:40:15) 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w > stop error Could you pleaselet me know what is wrong for my min_lapw? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 18:15:32 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Ingo Loa, in WIEN97 there was an internal limit on the value of GMAX, reducing it to 25 (I think) if the user specified a larger value. Maybe you could check in your .in2(c)-file that you are indeed going up to 50, or in your .outputd that more plane waves are indeed being used. Perhaps you've just been doing the same calculation over and over again. Also, GMAX is not the cutoff of a basis like (r)kmax, so there is no variational principle for the energy. So 'convergence wrt gmax' does not mean quite the same as 'convergence wrt kmax', as was pointed out recently on the mailing list. Apart from that, if you still have problems with such incredibly high GMAX-values, are you sure there are no problems elsewhere in your calculation? kind regards, Kevin Jorissen EMAT, University of Antwerp - ----- Original Message ----- From: "Ingo Loa" To: Sent: Monday, October 07, 2002 4:45 PM Subject: [WIEN]: bcc Cs, convergence of Etot wrt GMAX > ==== > Ingo Loa > submitted the following contribution: > ==== > > Dear Wien2k team & users, > > when looking at the pressure-induced bcc-to-fcc transition in Cs by > total-energy calculations, I recently encountered the following > difficulties. I could easily converge the total energy as a function of > RKMAX and number of k-points. Convergence with regard to GMAX, however, was > extremely slow. Even with GMAX values as large as 50, the total energy of > the bcc phase was still not converged on the 1-meV/atom level. This appears > rather unusual to me, especially, because it occurs in a fairly simple > system. A summary of typical input files is given below, the calculations > were performed with a recent release of Wien2k. > > Does anybody have an idea of what may cause these troubles or how to > proceed? Any comments/suggestions are welcome. > > Regards, > Ingo Loa > > > ************************************************************************* > > Cs-bcc.struct: > > Cs-bcc > B LATTICE,NONEQUIV. ATOMS: 1 > MODE OF CALC=RELA unit=ang > 11.515569 11.515569 11.515569 90.000000 90.000000 90.000000 > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= > 2 > Cs NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 55.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 > 0.0000000 > 0.0000000 0.0000000 > 1.0000000 > 48 NUMBER OF SYMMETRY > OPERATIONS > -------------------------------------------------------------------------- > Cs-bcc.in0: > > TOT 13 (5...CA-LDA, 13...PBE-GGA, 14...PW2-GGA) > NR2V (R2V) > -------------------------------------------------------------------------- > Cs-bcc.in1: > > WFFIL (WFPRI, SUPWF) > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > -.14794 6 0 global e-param with N other choices, napw > 0 0.103 0.000 CONT 1 > 0 -1.602 0.000 CONT 1 > 1 0.116 0.000 CONT 1 > 1 -0.633 0.000 CONT 1 > 2 0.132 0.000 CONT 1 > 2 -5.087 0.000 CONT 1 > K-VECTORS FROM UNIT:4 -8.0 2.5 emin/emax window > -------------------------------------------------------------------------- > Cs-bcc.in2: > > TOT (TOT,FOR,QTL,EFG,FERMI) > -9.0 19.0 0.50 0.05 EMIN, NE, ESEPERMIN, ESEPER0 > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > 0 0 4 0 4 4 6 0 6 4 > 55. GMAX > FILE FILE/NOFILE write recprlist > -------------------------------------------------------------------------- > Cs-bcc.klist: > > 165 k-points in the irreducible wedge, 4913 points in total. > -------------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------------- > Ingo Loa > Max-Planck-Institut fuer Festkoerperforschung, Stuttgart > Heisenbergstr. 1 // D-70569 Stuttgart // Germany > Tel. +49.711.689-1469 // Fax. +49.711.689-1444 > I.Loa@fkf.mpg.de // http://www.mpi-stuttgart.mpg.de/hd > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 18:18:01 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== "Kevin Jorissen" submitted the following contribution: ==== Here it is (beginning of dstart.f) : gmax=9.0 read(15,*,end=26) gmax1 if((gmax1.gt.6.d0).and.(gmax1.lt.25.d0)) gmax=gmax1 26 continue so by specifying a very large gmax, you'll end up with an unexpectedly small value instead ... kind regards, Kevin Jorissen EMAT, University of Antwerp - ----- Original Message ----- From: "Ingo Loa" To: Sent: Monday, October 07, 2002 4:45 PM Subject: [WIEN]: bcc Cs, convergence of Etot wrt GMAX > ==== > Ingo Loa > submitted the following contribution: > ==== > > Dear Wien2k team & users, > > when looking at the pressure-induced bcc-to-fcc transition in Cs by > total-energy calculations, I recently encountered the following > difficulties. I could easily converge the total energy as a function of > RKMAX and number of k-points. Convergence with regard to GMAX, however, was > extremely slow. Even with GMAX values as large as 50, the total energy of > the bcc phase was still not converged on the 1-meV/atom level. This appears > rather unusual to me, especially, because it occurs in a fairly simple > system. A summary of typical input files is given below, the calculations > were performed with a recent release of Wien2k. > > Does anybody have an idea of what may cause these troubles or how to > proceed? Any comments/suggestions are welcome. > > Regards, > Ingo Loa > > > ************************************************************************* > > Cs-bcc.struct: > > Cs-bcc > B LATTICE,NONEQUIV. ATOMS: 1 > MODE OF CALC=RELA unit=ang > 11.515569 11.515569 11.515569 90.000000 90.000000 90.000000 > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= > 2 > Cs NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 55.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 > 0.0000000 > 0.0000000 0.0000000 > 1.0000000 > 48 NUMBER OF SYMMETRY > OPERATIONS > -------------------------------------------------------------------------- > Cs-bcc.in0: > > TOT 13 (5...CA-LDA, 13...PBE-GGA, 14...PW2-GGA) > NR2V (R2V) > -------------------------------------------------------------------------- > Cs-bcc.in1: > > WFFIL (WFPRI, SUPWF) > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > -.14794 6 0 global e-param with N other choices, napw > 0 0.103 0.000 CONT 1 > 0 -1.602 0.000 CONT 1 > 1 0.116 0.000 CONT 1 > 1 -0.633 0.000 CONT 1 > 2 0.132 0.000 CONT 1 > 2 -5.087 0.000 CONT 1 > K-VECTORS FROM UNIT:4 -8.0 2.5 emin/emax window > -------------------------------------------------------------------------- > Cs-bcc.in2: > > TOT (TOT,FOR,QTL,EFG,FERMI) > -9.0 19.0 0.50 0.05 EMIN, NE, ESEPERMIN, ESEPER0 > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > 0 0 4 0 4 4 6 0 6 4 > 55. GMAX > FILE FILE/NOFILE write recprlist > -------------------------------------------------------------------------- > Cs-bcc.klist: > > 165 k-points in the irreducible wedge, 4913 points in total. > -------------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------------- > Ingo Loa > Max-Planck-Institut fuer Festkoerperforschung, Stuttgart > Heisenbergstr. 1 // D-70569 Stuttgart // Germany > Tel. +49.711.689-1469 // Fax. +49.711.689-1444 > I.Loa@fkf.mpg.de // http://www.mpi-stuttgart.mpg.de/hd > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 19:03:46 +0200 From: "koitzsch" Subject: Re: [WIEN]: open core treatment ==== "koitzsch" submitted the following contribution: ==== Hi Stefaan and everybody else in the User List, I tried both suggestions - first I changed to 4, 3,6 4,-4,1 and then a bigger shift, unfortunately both had no effect, the error message remains the same. Christian Koitzsch University of Fribourg Department of Physics CH-1700 Fribourg - ----- Original Message ----- From: "Stefaan Cottenier" To: Sent: Monday, October 07, 2002 6:01 PM Subject: Re: [WIEN]: open core treatment > ==== > "Stefaan Cottenier" > submitted the following contribution: > ==== > > > LAPW0 END > > LAPW1 END > > LAPW2 END > > forrtl: severe (64): input conversion error, unit 20, file > > /home/koitzsch/GdSi/GdSi.struct > > 0: _call_remove_gp_range [0x3ff81a6c374] > > 1: _call_remove_gp_range [0x3ff81a6c8f4] > > 2: _call_remove_gp_range [0x3ff81a93b84] > > 3: _call_remove_gp_range [0x3ff81a926e0] > > 4: insld_ [insld.f: 92, 0x12000928c] > > 5: hfsd_ [hfsd.f: 127, 0x120005ffc] > > 6: main [for_main.c: 203, 0x120002554] > > 7: __start [0x1200024c8] > > > > Does anybody know, what I am doing wrong here. > > Your problem is in lcore. Two suggestions : > > 1) Try to fill first the core orbitals like this (completely fill one, and > only then go to the next): > > 4, 3,6 > > 4,-4,1 > > 2) Try a slightly larger shift (0.8, 0.9). > > Stefaan > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 13:28:43 -0500 (CDT) From: Bing Zhou Subject: [WIEN]: min_lapw (fwd) ==== Bing Zhou submitted the following contribution: ==== Dear All: The file mini.error contains the following information: 'MINI' - can't open unit: 5 'MINI' - filename: chiolite.inM 'MINI' - status: old form: formatted It might help you to guess what is wrong with my min_lapw procedure. Best wishes! ==== Bing Zhou submitted the following contribution: ==== Dear All: After the SCF cycles, I run min_lapw, it stoped after 5 cycles with the following information on my screen: run_lapw -I -fc 1. -renorm -i 40 hup: Command not found STOP: MIXER END in cycle 2 ETEST: 0 CTEST: 0 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 3 ETEST: 11732.1216010000000000 CTEST: .0410162 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 4 ETEST: 5866.5759085000000000 CTEST: .0398830 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END in cycle 5 ETEST: .7647320000000000 CTEST: .0390583 hup: Command not found STOP: LAPW0 END STOP: LAPW1 END STOP: LAPW2 END STOP: CORE END STOP: MIXER END STOP: MINI - Error I checked the case.file as following: Calculating chiolite in /local/project00/umbingz/mysamples/chiolite on mira start (Wednesday October 2 17:35:21 CDT 2002) with mixer (40/20 to go) > mixer (17:35:21) 13.0u 0.0s 1:05 19% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 0 :CHARGE convergence: 0 0 0 cycle 2 (Wednesday October 2 17:36:30 CDT 2002) cycle 2 (39/19 to go) > lapw0 (17:36:30) 69.0u 0.0s 4:45 24% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (17:41:43) 45834.0u 108.0s 23:20:29 54% 0+0k 0+0io 0pf+0w > lapw2 (17:02:14) 2228.0u 44.0s 46:20 81% 0+0k 0+0io 0pf+0w > lcore (17:48:35) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (17:48:44) 13.0u 0.0s 0:16 77% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 11732.1216010000000000 :CHARGE convergence: 0 0 .0410162 cycle 3 (Thursday October 3 17:49:05 CDT 2002) cycle 3 (38/18 to go) > lapw0 (17:49:05) 73.0u 0.0s 1:24 86% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (17:50:44) 46437.0u 143.0s 14:39:53 88% 0+0k 0+0io 0pf+0w > lapw2 (08:30:38) 2148.0u 38.0s 42:03 86% 0+0k 0+0io 0pf+0w > lcore (09:12:42) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (09:12:52) 13.0u 0.0s 0:17 76% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 5866.5759085000000000 :CHARGE convergence: 0 0 .0398830 cycle 4 (Friday October 4 09:13:13 CDT 2002) cycle 4 (37/17 to go) > lapw0 (09:13:13) 71.0u 0.0s 1:18 90% 0+0k 0+0io 0pf+0w :FORCE convergence: 0 1. 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO 0 YCO > lapw1 (09:14:44) 45305.0u 117.0s 16:42:28 75% 0+0k 0+0io 0pf+0w > lapw2 (01:57:13) 2048.0u 38.0s 39:18 88% 0+0k 0+0io 0pf+0w > lcore (02:36:32) 0.0u 0.0s 0:03 0% 0+0k 0+0io 0pf+0w > mixer (02:36:41) 13.0u 0.0s 0:15 83% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 .7647320000000000 :CHARGE convergence: 0 0 .0390583 cycle 5 (Saturday October 5 02:36:59 CDT 2002) cycle 5 (36/16 to go) > lapw0 (02:36:59) 68.0u 0.0s 1:13 92% 0+0k 0+0io 0pf+0w :FORCE convergence: 1 1. 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO .1155000000000000 XCO .2215000000000000 XCO > lapw1 (02:38:36) 43686.0u 175.0s 12:45:03 95% 0+0k 0+0io 0pf+0w > lapw2 (15:23:40) 16605.0u 39.0s 5:16:03 87% 0+0k 0+0io 0pf+0w > lcore (20:39:44) 0.0u 0.0s 0:01 0% 0+0k 0+0io 0pf+0w > mixer (20:39:55) 13.0u 0.0s 0:16 79% 0+0k 0+0io 0pf+0w :ENERGY convergence: 0 0 .7540850000000000 :CHARGE convergence: 0 0 .0381198 cycle 6 (Saturday October 5 20:40:14 CDT 2002) cycle 6 (0/15 to go) > stop > mini (20:40:15) 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w > stop error Could you pleaselet me know what is wrong for my min_lapw? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 7 Oct 2002 22:05:15 +0200 From: Stefaan Cottenier Subject: Re: [WIEN]: min_lapw (fwd) ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Bing Zhou > submitted the following contribution: > ==== > > The file mini.error contains the following information: > > 'MINI' - can't open unit: 5 > 'MINI' - filename: chiolite.inM > 'MINI' - status: old form: formatted > > It might help you to guess what is wrong with my min_lapw procedure. Take the usersguide and read the sections on mini and min_lapw. You did not create a chiolite.inM file (input file for mini), and the fact you didn't do that shows that you should first read the basics about mini. The philosophy of min_lapw has been dealt with several times in the mailing list, check the digests. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 08:08:15 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: open core treatment ==== "Saeid Jalali" submitted the following contribution: ==== > I tried both suggestions - first I changed to > 4, 3,6 > 4,-4,1 > > and then a bigger shift, unfortunately both had no effect, the error message > remains the same. I am pretty sure that your problem in lcore will be fixed using the shift of 1.0 in the case.inc file. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 08 Oct 2002 09:19:21 +0200 From: Ingo Loa Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== Ingo Loa submitted the following contribution: ==== Dear Kevin Jorissen, thank you for your comments. At 18:18 07.10.2002 +0200, you wrote: >==== >"Kevin Jorissen" >submitted the following contribution: >==== > >Here it is (beginning of dstart.f) : > > gmax=9.0 > read(15,*,end=26) gmax1 > if((gmax1.gt.6.d0).and.(gmax1.lt.25.d0)) gmax=gmax1 > 26 continue > > >so by specifying a very large gmax, you'll end up with an unexpectedly small >value instead ... As far as I understand, GMAX is forced to be less than 25 only in dstart, i.e., only during the initialization. In the SCF cycle, lapw2 seems to use GMAX as requested by me, see the following line out of .scf. :GMA : POTENTIAL AND CHARGE CUT-OFF 55.00 Ry**.5 While you are probably right that the total energy is not variational with GMAX, I would still expect it to give some stable solution once the charge density and potential are expanded accurately enough. Below you find the evolution of ETOT with GMAX for a series of calculations. As you can see, ETOT increases monotonically with GMAX, levels off above GMAX ~ 30, but it still changes by 0.12 mRy when going from GMAX=45 to GMAX=55. GMAX ETOT 20 -15580.55975 24 -15580.55936 28 -15580.55891 35 -15580.55854 45 -15580.55826 55 -15580.55814 The reason why I insist in having a converged solution is that the energy difference between bcc and fcc Cs is very small, as it is for all of the alkali metals. And it turns out that the bcc-fcc energy difference at equilibrium volume decreases with increasing GMAX. In order to make some statement on the stable phase and phase transition pressure/volume, one needs a well-converged calculation. Regards, Ingo Loa >----- Original Message ----- >From: "Ingo Loa" >To: >Sent: Monday, October 07, 2002 4:45 PM >Subject: [WIEN]: bcc Cs, convergence of Etot wrt GMAX > > > > ==== > > Ingo Loa > > submitted the following contribution: > > ==== > > > > Dear Wien2k team & users, > > > > when looking at the pressure-induced bcc-to-fcc transition in Cs by > > total-energy calculations, I recently encountered the following > > difficulties. I could easily converge the total energy as a function of > > RKMAX and number of k-points. Convergence with regard to GMAX, however, >was > > extremely slow. Even with GMAX values as large as 50, the total energy of > > the bcc phase was still not converged on the 1-meV/atom level. This >appears > > rather unusual to me, especially, because it occurs in a fairly simple > > system. A summary of typical input files is given below, the calculations > > were performed with a recent release of Wien2k. > > > > Does anybody have an idea of what may cause these troubles or how to > > proceed? Any comments/suggestions are welcome. > > > > Regards, > > Ingo Loa > > > > > > ************************************************************************* > > > > Cs-bcc.struct: > > > > Cs-bcc > > B LATTICE,NONEQUIV. ATOMS: 1 > > MODE OF CALC=RELA unit=ang > > 11.515569 11.515569 11.515569 90.000000 90.000000 90.000000 > > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > > MULT= 1 ISPLIT= > > 2 > > Cs NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 55.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 > > 0.0000000 > > 0.0000000 0.0000000 > > 1.0000000 > > 48 NUMBER OF SYMMETRY > > OPERATIONS > > -------------------------------------------------------------------------- > > Cs-bcc.in0: > > > > TOT 13 (5...CA-LDA, 13...PBE-GGA, 14...PW2-GGA) > > NR2V (R2V) > > -------------------------------------------------------------------------- > > Cs-bcc.in1: > > > > WFFIL (WFPRI, SUPWF) > > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > > -.14794 6 0 global e-param with N other choices, napw > > 0 0.103 0.000 CONT 1 > > 0 -1.602 0.000 CONT 1 > > 1 0.116 0.000 CONT 1 > > 1 -0.633 0.000 CONT 1 > > 2 0.132 0.000 CONT 1 > > 2 -5.087 0.000 CONT 1 > > K-VECTORS FROM UNIT:4 -8.0 2.5 emin/emax window > > -------------------------------------------------------------------------- > > Cs-bcc.in2: > > > > TOT (TOT,FOR,QTL,EFG,FERMI) > > -9.0 19.0 0.50 0.05 EMIN, NE, ESEPERMIN, >ESEPER0 > > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > > 0 0 4 0 4 4 6 0 6 4 > > 55. GMAX > > FILE FILE/NOFILE write recprlist > > -------------------------------------------------------------------------- > > Cs-bcc.klist: > > > > 165 k-points in the irreducible wedge, 4913 points in total. > > -------------------------------------------------------------------------- > > - -------------------------------------------------------------------------- Ingo Loa Max-Planck-Institut fuer Festkoerperforschung, Stuttgart Heisenbergstr. 1 // D-70569 Stuttgart // Germany Tel. +49.711.689-1469 // Fax. +49.711.689-1444 I.Loa@fkf.mpg.de // http://www.mpi-stuttgart.mpg.de/hd - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 10:45:42 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Ingo Loa, you are right that the reduced value is only used for the initialisation (I did not know this). Lapw2 checks whether the gmax you have requested in case.in2 is different from the one used to construct the case.recprlist, and if it is, then a new list will be calculated (by the routine deter.f) using the 'new' gmax. So what you did was right (except maybe it would be better to set gmax < 25 for the initialisation, so you'll have a better starting potential/density than with the reset value gmax=9; and then increase it before running the SCF). I don't know why you cannot converge the energy better. Maybe someone with more insight in these potentials can answer that question. kindly yours, Kevin Jorissen EMAT, University of Antwerp - ----- Original Message ----- From: "Ingo Loa" To: Sent: Tuesday, October 08, 2002 9:19 AM Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX > ==== > Ingo Loa > submitted the following contribution: > ==== > > Dear Kevin Jorissen, > > thank you for your comments. > > > At 18:18 07.10.2002 +0200, you wrote: > >==== > >"Kevin Jorissen" > >submitted the following contribution: > >==== > > > >Here it is (beginning of dstart.f) : > > > > gmax=9.0 > > read(15,*,end=26) gmax1 > > if((gmax1.gt.6.d0).and.(gmax1.lt.25.d0)) gmax=gmax1 > > 26 continue > > > > > >so by specifying a very large gmax, you'll end up with an unexpectedly small > >value instead ... > > > As far as I understand, GMAX is forced to be less than 25 only in dstart, > i.e., only during the initialization. In the SCF cycle, lapw2 seems to use > GMAX as requested by me, see the following line out of .scf. > > :GMA : POTENTIAL AND CHARGE CUT-OFF 55.00 Ry**.5 > > > While you are probably right that the total energy is not variational with > GMAX, I would still expect it to give some stable solution once the charge > density and potential are expanded accurately enough. Below you find the > evolution of ETOT with GMAX for a series of calculations. As you can see, > ETOT increases monotonically with GMAX, levels off above GMAX ~ 30, but it > still changes by 0.12 mRy when going from GMAX=45 to GMAX=55. > > GMAX ETOT > > 20 -15580.55975 > 24 -15580.55936 > 28 -15580.55891 > 35 -15580.55854 > 45 -15580.55826 > 55 -15580.55814 > > > The reason why I insist in having a converged solution is that the energy > difference between bcc and fcc Cs is very small, as it is for all of the > alkali metals. And it turns out that the bcc-fcc energy difference at > equilibrium volume decreases with increasing GMAX. In order to make some > statement on the stable phase and phase transition pressure/volume, one > needs a well-converged calculation. > > Regards, > Ingo Loa > > > >----- Original Message ----- > >From: "Ingo Loa" > >To: > >Sent: Monday, October 07, 2002 4:45 PM > >Subject: [WIEN]: bcc Cs, convergence of Etot wrt GMAX > > > > > > > ==== > > > Ingo Loa > > > submitted the following contribution: > > > ==== > > > > > > Dear Wien2k team & users, > > > > > > when looking at the pressure-induced bcc-to-fcc transition in Cs by > > > total-energy calculations, I recently encountered the following > > > difficulties. I could easily converge the total energy as a function of > > > RKMAX and number of k-points. Convergence with regard to GMAX, however, > >was > > > extremely slow. Even with GMAX values as large as 50, the total energy of > > > the bcc phase was still not converged on the 1-meV/atom level. This > >appears > > > rather unusual to me, especially, because it occurs in a fairly simple > > > system. A summary of typical input files is given below, the calculations > > > were performed with a recent release of Wien2k. > > > > > > Does anybody have an idea of what may cause these troubles or how to > > > proceed? Any comments/suggestions are welcome. > > > > > > Regards, > > > Ingo Loa > > > > > > > > > ************************************************************************* > > > > > > Cs-bcc.struct: > > > > > > Cs-bcc > > > B LATTICE,NONEQUIV. ATOMS: 1 > > > MODE OF CALC=RELA unit=ang > > > 11.515569 11.515569 11.515569 90.000000 90.000000 90.000000 > > > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > > > MULT= 1 ISPLIT= > > > 2 > > > Cs NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 55.0 > > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > > 0.0000000 1.0000000 > > > 0.0000000 > > > 0.0000000 0.0000000 > > > 1.0000000 > > > 48 NUMBER OF SYMMETRY > > > OPERATIONS > > > -------------------------------------------------------------------------- > > > Cs-bcc.in0: > > > > > > TOT 13 (5...CA-LDA, 13...PBE-GGA, 14...PW2-GGA) > > > NR2V (R2V) > > > -------------------------------------------------------------------------- > > > Cs-bcc.in1: > > > > > > WFFIL (WFPRI, SUPWF) > > > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > > > -.14794 6 0 global e-param with N other choices, napw > > > 0 0.103 0.000 CONT 1 > > > 0 -1.602 0.000 CONT 1 > > > 1 0.116 0.000 CONT 1 > > > 1 -0.633 0.000 CONT 1 > > > 2 0.132 0.000 CONT 1 > > > 2 -5.087 0.000 CONT 1 > > > K-VECTORS FROM UNIT:4 -8.0 2.5 emin/emax window > > > -------------------------------------------------------------------------- > > > Cs-bcc.in2: > > > > > > TOT (TOT,FOR,QTL,EFG,FERMI) > > > -9.0 19.0 0.50 0.05 EMIN, NE, ESEPERMIN, > >ESEPER0 > > > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > > > 0 0 4 0 4 4 6 0 6 4 > > > 55. GMAX > > > FILE FILE/NOFILE write recprlist > > > -------------------------------------------------------------------------- > > > Cs-bcc.klist: > > > > > > 165 k-points in the irreducible wedge, 4913 points in total. > > > -------------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------------- > Ingo Loa > Max-Planck-Institut fuer Festkoerperforschung, Stuttgart > Heisenbergstr. 1 // D-70569 Stuttgart // Germany > Tel. +49.711.689-1469 // Fax. +49.711.689-1444 > I.Loa@fkf.mpg.de // http://www.mpi-stuttgart.mpg.de/hd > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 11:28:21 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: bcc Cs, convergence of Etot wrt GMAX ==== Peter Blaha submitted the following contribution: ==== I must admit I'm also a little bit annoyed by the slow convergence of E-tot with respect to GMAX. One possible reason could be the small RMT value of 2.0 for such a heavy element. (We know that one needs a large GMAX for H with it's small sphere). I do NOT suggest RMTs as large as possible, but try 2.5-3.0 bohr. (It should be faster anyway). I have, however, also some other remarks. If you are looking for such small energy differences, is RKMAX=8 converged ? (Probably not absolutely, but the resulting energy differences may be stable). > > > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT The number of k-points seems incredibly small to me for high accuracy!! > > > 165 k-points in the irreducible wedge, 4913 points in total. Regards > While you are probably right that the total energy is not variational with > GMAX, I would still expect it to give some stable solution once the charge > density and potential are expanded accurately enough. Below you find the > evolution of ETOT with GMAX for a series of calculations. As you can see, > ETOT increases monotonically with GMAX, levels off above GMAX ~ 30, but it > still changes by 0.12 mRy when going from GMAX=45 to GMAX=55. > > GMAX ETOT > > 20 -15580.55975 > 24 -15580.55936 > 28 -15580.55891 > 35 -15580.55854 > 45 -15580.55826 > 55 -15580.55814 > > > The reason why I insist in having a converged solution is that the energy > difference between bcc and fcc Cs is very small, as it is for all of the > alkali metals. And it turns out that the bcc-fcc energy difference at > equilibrium volume decreases with increasing GMAX. In order to make some > statement on the stable phase and phase transition pressure/volume, one > needs a well-converged calculation. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 08 Oct 2002 21:01:46 +0900 From: Satoshi Okada Subject: Re: [WIEN]: lapw2 & ifc on LINUX ==== Satoshi Okada submitted the following contribution: ==== Dear all, Thank you for your advice, but extra field of record did't fix my problem. And I find another hit of this issue. For my old enviroment, the variable SCRATCH was set to /tmp. But when I set SCRATCH to current directory(on Network File System), all binary data can be read correctly and lapw2 fin !! So, I think ifc & NFS read/write of LINUX cause this problem. I will ask INTEL this problem again. Regargs. Peter Blaha wrote: > > I try to make WIEN2k with ifc(Intel Fortran Compiler) on LINUX. > > > > When WIEN2k(lapw2) read a vector data file ( UNIT 10 ), > > the illegal values were inputed for kx_buf,ky_buf,kz_buf > > after about 400byte reading. > > > > SRC_lapw2/read_vec.F: > > 54 IF(myid.EQ.0) THEN > > 55 WRITE(31,205) s,t,z,n,ne,bname > > 56 READ(10) (kx_buf(i),ky_buf(i),kz_buf(i), > > i=1,n-(nlo+nlon+nlov)), > > (kxlo(i),kylo(i),kzlo(i),i=1,(nlo+nlon+nlov)) > > 57 ENDIF > > On our system we also use the ifc compiler and have no problems at all. > However, since this compiler is still under development, a lot may depend > on the version of the compiler. > > I have one suggestion for testing: > Add in SRC_lapw2/read_vec.F: > > CHARACTER*3 IPGR > > and change the following line: > IF (myid.EQ.0) READ(10,IOSTAT=ios) s,t,z,bname,n,ne,ipgr > > ipgr is written by lapw1/tapewf.F > Usually partial reads ignore longer records and with the next read > the next record is read and everything is fine. Maybe the ifc does not like > this. > > PS: Please let me know if this fixes your problem. (The final > solution should be to remove ipgr from tapewf.F since it is no longer needed. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 13:42:10 +0100 (BST) From: Dave Pankhurst Subject: [WIEN]: sgroup ==== Dave Pankhurst submitted the following contribution: ==== Dear Wien users, I have a comment I would like to make about sgroup. First of all, I'd like to congratulate the authors on an excellent and very useful program. I am using it to find the symmetry of distorted unit cells for the purpose of calculating elastic constants in non cubic materials. My minor niggle concerns numerical precision. In one particular case sgroup detects tetragonal body centred symmetry and the output is as follows. (case.outputsgroup) Bravais lattice: Tetragonal body centred a b c 5.77803900 5.77803900 16.37833700 alpha beta gamma 90.00000000 90.00000000 90.00000100 However, as you can see, there is a small error in gamma due, presumably, to the fact that the lattice parameters in the struct file are only given to 6 decimal places. However, having detected that the system is tetragonal, should not the program _automatically_ set all angles to exactly 90 degrees? The problem with this small error is that the symmetry program that follows in init_lapw seems to be quite pedantic about angles. In fact, based on the struct file produced by sgroup in this case, symmetry thinks the structure is monoclinic. I have occasionally noticed a few other numerical errors. Like the following case where sgroup chooses to shift the atomic z coordinate of a particular atom ATOM= -2: X=0.16621400 Y=0.33242800 Z=0.00000000 by half a C lattice vector ... (case.struct_sgroup) ATOM= 2: X=0.16621400 Y=0.33242800 Z=0.50000017 again, a small numerical error seems to have been incurred in calculating the shifted z coordinate. This time it is not large enough to perturb the symmetry program but I'm not sure if this is the desired behaviour. Btw. I have verified that this behaviour occurs using both portland and hp compilers. Sorry if these problems seem trivial but, in the first case at least, there do seem to be some problems of consistency between the separate wien programs. best regards, Dave Pankhurst +---------------------------------+------------------------------------+ | Dr David Pankhurst, | Tel : +44 1865 283325/283326 | | Department of Materials, | Fax : +44 1865 273789 | | University of Oxford, | | | Parks Road, Oxford OX1 3PH, UK | david.pankhurst@materials.ox.ac.uk | +---------------------------------+------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 16:03:49 +0200 From: "koitzsch" Subject: [WIEN]: still open core ==== "koitzsch" submitted the following contribution: ==== Hi everybody, I am still struggling with the open core treatment of 4f electrons. After some unsuccessfull attempts with GdSi (see previous mails, the suggested shift of 1.0 did not work either, Saeid), I tried to repeat the fcc Yb example, but I get the exact same error message, so I am wondering if I miss something on the FAQ page or do sth. else wrong? I just ran the normal calculation with 50 kpoints, but this should be irrelevant for this open core problem? the struct file: Title F LATTICE,NONEQUIV. ATOMS: 1 225 Fm-3m MODE OF CALC=RELA 8.474000 8.474000 8.474000 90.000000 90.000000 90.000000 ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Yb NPT= 781 R0=0.00001000 RMT= 2.5000 Z: 70.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 48 NUMBER OF SYMMETRY OPERATIONS then in Yb.scf: ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM Yb OVERALL ENERGY PARAMETER IS 0.3000 E( 0)= 0.3000 E( 0)= -3.1225 E(BOTTOM)= -3.240 E(TOP)= -3.005 E( 1)= -1.1000 E(BOTTOM)= -1.440 E(TOP)= -0.760 E( 1)= 0.3000 E( 3)= 0.6200 E(BOTTOM)= 0.570 E(TOP)= 0.670 E( 2)= 0.4900 E(BOTTOM)= 0.490 E(TOP)= -200.000 Title F LATTICE,NONEQUIV. ATOMS: 1 225 Fm-3m MODE OF CALC=RELA 8.474000 8.474000 8.474000 90.000000 90.000000 90.000000 ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Yb NPT= 781 R0=0.00001000 RMT= 2.5000 Z: 70.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 so I guess a shift of 0.7 should be fine? Yb.in1old: WFFIL (WFPRI, SUPWF) 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 0 -4.06 0.005 STOP 1 -1.85 0.010 CONT 1 0.30 0.000 CONT 3 0.30 0.010 CONT 2 0.30 0.010 CONT K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window Yb.in1new WFFIL (WFPRI, SUPWF) 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 0 0.30 0.000 CONT 0 -4.06 0.005 STOP 1 -1.85 0.010 CONT 1 0.30 0.000 CONT 3 -1.00 0.000 CONT 2 0.30 0.010 CONT K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window Yb.in2old TOT (TOT,FOR,QTL,EFG,FERMI) -9.0 24.0 EMIN, NE TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) 0 0 4 0 4 4 6 0 6 4 10. GMAX FILE FILE/NOFILE write recprlist Yb.in2new TOT (TOT,FOR,QTL,EFG,FERMI) -9.0 11.0 EMIN, NE TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) 0 0 4 0 4 4 6 0 6 4 10. GMAX FILE FILE/NOFILE write recprlist new Yb.inc 16 0.70 NUMBER OF ORBITALS (EXCLUDING SPIN) 1,-1,2 ( N,KAPPA,OCCUP) 2,-1,2 ( N,KAPPA,OCCUP) 2, 1,2 ( N,KAPPA,OCCUP) 2,-2,4 ( N,KAPPA,OCCUP) 3,-1,2 ( N,KAPPA,OCCUP) 3, 1,2 ( N,KAPPA,OCCUP) 3,-2,4 ( N,KAPPA,OCCUP) 3, 2,4 ( N,KAPPA,OCCUP) 3,-3,6 ( N,KAPPA,OCCUP) 4,-1,2 ( N,KAPPA,OCCUP) 4, 1,2 ( N,KAPPA,OCCUP) 4,-2,4 ( N,KAPPA,OCCUP) 4, 2,4 ( N,KAPPA,OCCUP) 4,-3,6 ( N,KAPPA,OCCUP) 4, 3,6 4,-4,7 0 Error Message: LAPW0 END LAPW1 END LAPW2 END forrtl: severe (64): input conversion error, unit 20, file /home/koitzsch/Yb/Yb.struct 0: _call_remove_gp_range [0x3ff81a6c374] 1: _call_remove_gp_range [0x3ff81a6c8f4] 2: _call_remove_gp_range [0x3ff81a93b84] 3: _call_remove_gp_range [0x3ff81a926e0] 4: insld_ [insld.f: 92, 0x12000928c] 5: hfsd_ [hfsd.f: 127, 0x120005ffc] 6: main [for_main.c: 203, 0x120002554] 7: __start [0x1200024c8] Does anybody see, where the error is? Thanks a lot! Christian Koitzsch University of Fribourg Department of Physics CH-1700 Fribourg Switzerland ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 16:29:23 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: still open core ==== Peter Blaha submitted the following contribution: ==== > I am still struggling with the open core treatment of 4f electrons. After > some unsuccessfull attempts with GdSi (see previous mails, the suggested > shift of 1.0 did not work either, Saeid), I tried to repeat the fcc Yb > example, but I get the exact same error message, so I am wondering if I miss > something on the FAQ page or do sth. else wrong? Try a really big shift like -3. or even -10. > then in Yb.scf: > > ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM Yb > > OVERALL ENERGY PARAMETER IS 0.3000 > E( 0)= 0.3000 > E( 0)= -3.1225 E(BOTTOM)= -3.240 E(TOP)= -3.005 > E( 1)= -1.1000 E(BOTTOM)= -1.440 E(TOP)= -0.760 > E( 1)= 0.3000 > E( 3)= 0.6200 E(BOTTOM)= 0.570 E(TOP)= 0.670 > E( 2)= 0.4900 E(BOTTOM)= 0.490 E(TOP)= -200.000 > Title > F LATTICE,NONEQUIV. ATOMS: 1 225 Fm-3m > MODE OF CALC=RELA > 8.474000 8.474000 8.474000 90.000000 90.000000 90.000000 > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 2 > Yb NPT= 781 R0=0.00001000 RMT= 2.5000 Z: 70.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > > so I guess a shift of 0.7 should be fine? This is most likely much too small. > Yb.in1new > > WFFIL (WFPRI, SUPWF) > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) > 0 0.30 0.000 CONT > 0 -4.06 0.005 STOP > 1 -1.85 0.010 CONT > 1 0.30 0.000 CONT > 3 -1.00 0.000 CONT Are you sure this was low enough to avoid any real 4f electrons in the valence? Did your error happen in the first open core scf-cycle or only afterwards ? After all: open core calculations are not state of the art anymore. Use LDA+U for the 4f systems. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 08 Oct 2002 18:10:26 +0200 From: Florent Boucher Subject: Re: [WIEN]: Pb SRC_lapw2/atpar.F and lxdos ==== Florent Boucher submitted the following contribution: ==== Dear Peter, it seems to work now. Just a small error in SRC_tetra/tetra.f because the fermden is not initialized allocate (RNUMB(jend,MG), DENSTY(jend,MG),fermden(jend)) allocate (ehelp(jend),denbr(jend,mg)) DENSTY=0.0 RNUMB=0.0 fermden=0.0 <- In some case it crash ... Regards and thank you. Florent Peter Blaha a écrit: >Dear Florent and Kevin, > >It seems Georg has never converted that part to the f90 version. > >I'm attatching a modified atpar.F routine where I uncommented the double loop >and set a proper index for a1lo,.... Try it and let me know if it >works. >PS: It will not work with relativistic LOs! > >Regards > > >>we are trying to use the ISPLIT=99 option in WIEN2K (latest version) and >>we have troubles with the atpar.F program. In the distributed version >>they are comments for the following lines: >>! >>!....overlap integrals for x-dos >>! >>!!$ do l=0,lxdos >>!!$ do lp=0,lxdos >>!!$ pu1u2(l,lp)=0.d0 >>!!$ pueu2(l,lp)=0.d0 >>!!$ pu2u2(l,lp)=0.d0 >>!!$ CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rrad1(1,lp) & >>!!$ ,rrad2(1,lp),pu1u1(l,lp),JATOM) >>!!$ CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rade1(1,lp) & >>!!$ ,rade2(1,lp),pu1ue(l,lp),JATOM) >>!!$ if(lp.le.lmax2) CALL RINT13(REL,rrad1(1,l),rrad2(1,l) & >>!!$ ,a1lo(1,lp),b1lo(1,lp),pu1u2(l,lp),JATOM) >>!!$ CALL RINT13(REL,rade1(1,l),rade2(1,l),rade1(1,lp) & >>!!$ ,rade2(1,lp),pueue(l,lp),JATOM) >>!!$ if(lp.le.lmax2) CALL RINT13(REL,rade1(1,l),rade2(1,l) & >>!!$ ,a1lo(1,lp),b1lo(1,lp),pueu2(l,lp),JATOM) >>!!$ if((lp.le.lmax2).and.(l.le.lmax2)) CALL >>RINT13(REL,a1lo(1,l) & >>!!$ ,b1lo(1,l),a1lo(1,lp),b1lo(1,lp),pu2u2(l,lp),JATOM) >>!!$ enddo >>!!$ enddo >> >>For this reason, the qtl file and help files have only zero values >>(pu1u1, pueue .... are not initialized) >> >> > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > > >------------------------------------------------------------------------ > > SUBROUTINE ATPAR (REL,NAT,JATOM,LATOM,cform,ZZ) > use param > use defs > use struk > use lo; USE atspdt, only: e=>el,p,dp,pe,dpe,pei > USE parallel > IMPLICIT REAL*8 (A-H,O-Z) >#ifdef Parallel > INCLUDE 'mpif.h' >#endif > CHARACTER*4 cform > LOGICAL REL > dimension emist2(0:lomax,nloat) >! > COMMON /RADFU/ RRAD1(NRAD,0:LMAX2),RADE1(NRAD,0:LMAX2), & > RRAD2(NRAD,0:LMAX2),RADE2(NRAD,0:LMAX2) > COMMON /POTNLC/ VR(NRAD) > COMMON /UHELP/ A(NRAD),B(NRAD),AP(NRAD),BP(NRAD),AE(NRAD), & > BE(NRAD) > common /normal/ pu1u1(0:lxdos,0:lxdos),pu1ue(0:lxdos,0:lxdos) & > ,pu1u2(0:lxdos,0:lxdos),pueue(0:lxdos,0:lxdos) & > ,pueu2(0:lxdos,0:lxdos),pu2u2(0:lxdos,0:lxdos) >!--------------------------------------------------------------------- >!.....READ TOTAL SPHERICAL POTENTIAL V(0,0) OF TAPE18=VSP >! NORM OF V(0,0)=V00(R)*R/SQRT(4.D0*PI) > > READ(18,1980) > READ(18,2000) IDUMMY > READ(18,2031) > READ(18,2022) ( VR(J), J=1,JRI(JATOM) ) > READ(18,2031) > READ(18,2030) > DO J=1,JRI(JATOM) > VR(J)=VR(J)/2.0D0 > enddo >! > nlo=0 > nlov=0 > nlon=0 >! nlo #LO on this atom, nlov #LO up til now, nlon #LO left > ilo(0:lmax2)=0 > DO i=1,jatom > IF(myid.EQ.0) THEN > READ(10) e > READ(10) elo > ENDIF >#ifdef Parallel > CALL MPI_BCAST(e,lmax2+1,MPI_DOUBLE_PRECISION, 0, MPI_COMM_WORLD, ierr) > CALL MPI_BCAST(elo,(lmax2+1)*nloat,MPI_DOUBLE_PRECISION, 0, MPI_COMM_WORLD, ierr) >#endif > IF(i.EQ.jatom) THEN > DO l=0,lmax2 > lapw(l)=.TRUE. > IF(e(l).GT.150.) THEN > e(l)=e(l)-200.d+0 > lapw(l)=.FALSE. > ENDIF > ENDDO > ENDIF > DO l = 0,lomax > DO k=1,nloat > loor(k,l)=.FALSE. > rlo(k,l)=.FALSE. > IF (i.EQ.jatom) THEN > IF (elo(l,k).LT.(995.d+0)) THEN > ilo(l)=ilo(l)+1 > nlo=nlo+((2*l+1))*mult(i) > IF(.NOT.lapw(l).AND.k.EQ.1) GOTO 666 > IF(k.EQ.nloat) THEN > rlo(ilo(l),l)=.TRUE. > ENDIF > loor(ilo(l),l)=.TRUE. >666 CONTINUE > ENDIF > ELSE > IF (elo(l,k).LT.(995.d+0)) nlov=nlov+((2*l+1))*mult(i) > ENDIF > ENDDO > ENDDO > ENDDO > IF(jatom.EQ.nat) GOTO 30 > DO i=jatom+1,nat > READ(10) emist > READ(10) emist2 >#ifdef Parallel > CALL MPI_BCAST(emist2,(lmax2+1)*nloat,MPI_DOUBLE_PRECISION, 0, MPI_COMM_WORLD, ierr) >#endif > DO l = 0,lomax > DO k=1,nloat > IF (emist2(l,k).LT.(995.0d+0)) & > nlon=nlon+((2*l+1))*mult(i) > ENDDO > ENDDO > ENDDO > 30 CONTINUE > IF(myid.EQ.0) THEN > WRITE(6,13) JATOM,IATNR(JATOM),(POS(I,LATOM),I=1,3) & > ,MULT(JATOM) > WRITE(21,13) JATOM,IATNR(JATOM),(POS(I,LATOM),I=1,3) & > ,MULT(JATOM) > WRITE(6,1060) ANAME(JATOM) > DO JROW=1,3 > WRITE(6,1070) ( ROTLOC(JCOL,JROW,JATOM),JCOL=1,3 ) > ENDDO > INDEX=LATOM-1 > DO M=1,MULT(JATOM) > INDEX=INDEX+1 > WRITE(6,1080) M,( POS(JC,INDEX),JC=1,3 ) > DO JR=1,3 > WRITE(6,1090)(ROTIJ(JC,JR,INDEX),JC=1,3),TAUIJ(JR,INDEX) > ENDDO > ENDDO > WRITE(6,7) ANAME(JATOM) > WRITE(6,5) E > WRITE(6,14) > ENDIF > > DO 70 l=0,LMAX2 > DELE=2.0D-3 > DELEI=0.25D0/DELE > FL=L > EI=E(l)/2.0d0 >! >! CALCULATE ENERGY-DERIVATIVE BY FINITE DIFFERENCE >! DELE IS THE UPWARD AND DOWNWARD ENERGY SHIFT IN HARTREES >! > E1=EI-DELE > CALL OUTWIN(REL,VR,R0(JATOM),DX(JATOM),JRI(JATOM),E1, & > FL,UVB,DUVB,NODEL,ZZ) > CALL RINT13(REL,A,B,A,B,OVLP,JATOM) > TRX=1.0D0/SQRT(OVLP) > IMAX=JRI(JATOM) > DO M=1,IMAX > AE(M)=TRX*A(M) > BE(M)=TRX*B(M) > ENDDO > UVB=TRX*UVB > DUVB=TRX*DUVB > E1=EI+DELE > CALL OUTWIN(REL,VR,R0(JATOM),DX(JATOM),JRI(JATOM),E1, & > FL,UVE,DUVE,NODE,ZZ) > CALL RINT13(REL,A,B,A,B,OVLP,JATOM) > TRX=1.0d0/SQRT(OVLP) > UVE=DELEI*(TRX*UVE-UVB) > DUVE=DELEI*(TRX*DUVE-DUVB) > IMAX=JRI(JATOM) > DO M=1,IMAX > AE(M)=DELEI*(TRX*A(M)-AE(M)) > BE(M)=DELEI*(TRX*B(M)-BE(M)) > ENDDO >! >! CALCULATE FUNCTION AT EI >! > CALL OUTWIN(REL,VR(1),R0(JATOM),DX(JATOM),JRI(JATOM),EI, & > FL,UV,DUV,NODES,ZZ) > CALL RINT13(REL,A,B,A,B,OVLP,JATOM) > TRX=1.0d0/SQRT(OVLP) > P(l)=TRX*UV > DP(l)=TRX*DUV > IMAX=JRI(JATOM) > DO M=1,IMAX > A(M)=TRX*A(M) > B(M)=TRX*B(M) > ENDDO >! >! INSURE ORTHOGONALIZATION >! > CALL RINT13(REL,A,B,AE,BE,CROSS,JATOM) > TRY=-CROSS > IF(TRY.LT.(-0.05d0).AND.myid.EQ.0) WRITE(6,9) L,TRY,OVLP > IMAX=JRI(JATOM) > DO M=1,IMAX > AE(M)=(AE(M)+TRY*A(M)) > BE(M)=(BE(M)+TRY*B(M)) > ENDDO > IMAX=JRI(JATOM) > DO 80 I=1,IMAX > RRAD1(I,l)=A(I) > RRAD2(I,l)=B(I) > RADE1(I,l)=AE(I) > RADE2(I,l)=BE(I) > 80 CONTINUE > PE(l)=UVE+TRY*P(l) > DPE(l)=DUVE+TRY*DP(l) > CALL RINT13(REL,AE,BE,AE,BE,PEI(l),JATOM) > IF(myid.EQ.0) WRITE(6,8) L,P(l),DP(l),PE(l),DPE(l),PEI(l),NODEL,NODES,NODE > 70 continue >! >! nun fur lo >! > pr12lo(1:nloat,1:nloat,0:lomax)=0.0d0 > pi12lo(1:nloat,0:lomax)=0.0d0 > pe12lo(1:nloat,0:lomax)=0.0d0 > a1lo(1:nrad,1:nloat,0:lomax)=0.0d0 > b1lo(1:nrad,1:nloat,0:lomax)=0.0d0 > > lo_loop: DO l=0,lomax > DO jlo=1,ilo(l) > if (.not.loor(jlo,l)) CYCLE > DELE=2.0D-3 > DELEI=0.25D0/DELE > FL=L > EI=elo(l,jlo)/2.d0 >! >! CALCULATE FUNCTION AT EI >! > IF(rlo(jlo,l)) THEN > ei=elo(l,nloat)/2.d0 > kappa=l >! kappa=-2 > CALL diracout(rel,vr(1),r0(jatom),dx(jatom),jri(jatom), & > ei,fl,kappa,uv,duv,nodes,zz) >!!$ CALL diracout_old(rel,vr(1),r0(jatom),dx(jatom),jri(jatom), & >!!$ ei,fl,kappa,uv,duv,nodes,zz) >! do m=1,jri(jatom) >! write(78,'(2f13.7)') a(m),b(m) >! enddo > CALL dergl(a,b,r0(jatom),dx(jatom),jri(jatom)) > DO m = 1, jri(jatom) > r_m = r0(jatom)*exp(dx(jatom)*(m-1)) > b(m) = b(m)*r_m / (2.d0*clight+(elo(l,jlo)-2.d0*vr(m)/r_m)/(2.d0*clight)) >! write(79,'(2f13.7)') r_m,b(m) >! b(m)=b(m)*clight >! b(m)=0.0d0 > ENDDO > ELSE > CALL outwin(rel,vr(1),r0(jatom),dx(jatom),jri(jatom), & > ei,fl,uv,duv,nodes,zz) > ENDIF > CALL rint13(rel,a,b,a,b,ovlp,jatom) > TRX=1.0d0/SQRT(OVLP) > plo(jlo,l)=trx*uv > dplo(jlo,l)=trx*duv > IMAX=JRI(JATOM) > DO M=1,IMAX > a1lo(M,jlo,l)=TRX*A(M) > b1lo(M,jlo,l)=TRX*B(M) > ENDDO > IF(l.EQ.1) THEN > DO m=1,imax > r_m = r0(jatom)*EXP(dx(jatom)*(m-1)) > WRITE(94,'(4e14.6)') r_m,a1lo(m,jlo,l),rrad1(m,l),rade1(m,l) > ENDDO > ENDIF > CALL RINT13(REL,rrad1(1,l),rrad2(1,l),a1lo(1,jlo,l),b1lo(1,jlo,l), & > pi12lo(jlo,l),JATOM) > CALL RINT13(REL,rade1(1,l),rade2(1,l),a1lo(1,jlo,l),b1lo(1,jlo,l), & > pe12lo(jlo,l),JATOM) > > IF(myid.EQ.0) WRITE(6,800) L,Plo(jlo,l),DPlo(jlo,l),NODEL,NODES,NODE > ENDDO > > DO jlo=1,ilo(l) > CALL ABC(l,jlo,jatom) > ENDDO > > DO jlo=1,ilo(l) > IF (.NOT.loor(jlo,l)) CYCLE > DO jlop=1,ilo(l) > IF (.NOT.loor(jlop,l)) CYCLE > CALL RINT13(REL,a1lo(1,jlop,l),b1lo(1,jlop,l), & > a1lo(1,jlo,l),b1lo(1,jlo,l), & > pr12lo(jlop,jlo,l),JATOM) > ENDDO > ENDDO > ENDDO lo_loop > >! >!....overlap integrals for x-dos >! not for rlo's !!!! > do l=0,lxdos > do lp=0,lxdos > pu1u2(l,lp)=0.d0 > pueu2(l,lp)=0.d0 > pu2u2(l,lp)=0.d0 > CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rrad1(1,lp) & > ,rrad2(1,lp),pu1u1(l,lp),JATOM) > CALL RINT13(REL,rrad1(1,l),rrad2(1,l),rade1(1,lp) & > ,rade2(1,lp),pu1ue(l,lp),JATOM) > > jlo=max(ilo(lp),1) > if(jlo.eq.3) jlo=2 !!! exclude rlo > if(lp.le.lmax2.and.loor(jlo,lp)) CALL RINT13(REL,rrad1(1,l),rrad2(1,l) & > ,a1lo(1,jlo,lp),b1lo(1,jlo,lp),pu1u2(l,lp),JATOM) > CALL RINT13(REL,rade1(1,l),rade2(1,l),rade1(1,lp) & > ,rade2(1,lp),pueue(l,lp),JATOM) > if(lp.le.lmax2.and.loor(jlo,lp)) CALL RINT13(REL,rade1(1,l),rade2(1,l) & > ,a1lo(1,jlo,lp),b1lo(1,jlo,lp),pueu2(l,lp),JATOM) > jlop=max(ilo(l),1) > if(jlop.eq.3) jlop=2 !!! exclude rlo > if((lp.le.lmax2).and.(l.le.lmax2).and.loor(jlo,lp).and.loor(jlop,l)) CALL RINT13(REL,a1lo(1,jlop,l) & > ,b1lo(1,jlop,l),a1lo(1,jlo,lp),b1lo(1,jlo,lp),pu2u2(l,lp),JATOM) > enddo > enddo >! > RETURN >! > 2 FORMAT(5E14.7) > 3 FORMAT(16I5) > 4 FORMAT(I4,E16.7) > 5 FORMAT(10X,' ENERGY PARAMETERS ARE',7F7.2) > 6 FORMAT(10X,'E(',I2,')=',F10.4) > 7 FORMAT(/10X,'ATOMIC PARAMETERS FOR ',A10/) > 14 FORMAT(/11X,'L',5X,'U(R)',10X, & > 'U''(R)',9X,'DU/DE',8X,'DU''/DE',6X,'NORM-U''') > 8 FORMAT(10X,I2,5E14.6,5X,3I2) > 800 FORMAT(10X,I2,2E14.6,42X,5X,3I2) > 9 FORMAT(10X,'FOR L=',I2,' CORRECTION=',E14.5,' OVERLAP=',E14.5) > 11 FORMAT(7F10.5) > 13 FORMAT(////,':POS',i2.2,':',1x,'AT.NR.',I3,2X,'POSITION =', & > 3F8.5,2X,'MULTIPLICITY =',I3) > 1040 FORMAT(8I2) > 1050 FORMAT(A10,I5,5X,2F10.9,I5,F5.2) > 1060 FORMAT(//,3X,'NOT EQUIV ATOM ',A10,' LOCAL ROTATION MATRIX') > 1070 FORMAT(30X,3F10.5) > 1080 FORMAT(13X,'EQUIV ATOM ',I3,3X,'POSITION: ',3F8.3) > 1090 FORMAT(30X,3F10.5,5X,F10.5) > 1980 FORMAT(3X) > 2000 FORMAT(16X,I2//) > 2022 FORMAT(3X,4E19.12) > 2030 FORMAT(///) > 2031 FORMAT(/) > END > > - -- -------------------------------------------------------------------------- | Florent BOUCHER | | | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 8 Oct 2002 18:14:47 +0200 (MET DST) From: Pavel Novak Subject: Re: [WIEN]: still open core ==== Pavel Novak submitted the following contribution: ==== Dear Christian, you can always treat the 4f-electrons as semicore - we checked some years ago that it is equivalent to puting them in core and there are no problems with crash of calculation. You have to prevent the hybridization of 4f by fixing in semicore calculation (.in1) the s, p, d energies at something like 2Ry and similarly in valence LAPW1 you fix 4f energy at 2Ry. Semicore calculation may be run with minimal number of k-points. Regards Pavel Novak On Tue, 8 Oct 2002, koitzsch wrote: > ==== > "koitzsch" > submitted the following contribution: > ==== > > Hi everybody, > > I am still struggling with the open core treatment of 4f electrons. After > some unsuccessfull attempts with GdSi (see previous mails, the suggested > shift of 1.0 did not work either, Saeid), I tried to repeat the fcc Yb > example, but I get the exact same error message, so I am wondering if I miss > something on the FAQ page or do sth. else wrong? > > I just ran the normal calculation with 50 kpoints, but this should be > irrelevant for this open core problem? > > the struct file: > > Title > F LATTICE,NONEQUIV. ATOMS: 1 225 Fm-3m > MODE OF CALC=RELA > 8.474000 8.474000 8.474000 90.000000 90.000000 90.000000 > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 2 > Yb NPT= 781 R0=0.00001000 RMT= 2.5000 Z: 70.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 48 NUMBER OF SYMMETRY OPERATIONS > > > then in Yb.scf: > > ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM Yb > > OVERALL ENERGY PARAMETER IS 0.3000 > E( 0)= 0.3000 > E( 0)= -3.1225 E(BOTTOM)= -3.240 E(TOP)= -3.005 > E( 1)= -1.1000 E(BOTTOM)= -1.440 E(TOP)= -0.760 > E( 1)= 0.3000 > E( 3)= 0.6200 E(BOTTOM)= 0.570 E(TOP)= 0.670 > E( 2)= 0.4900 E(BOTTOM)= 0.490 E(TOP)= -200.000 > Title > F LATTICE,NONEQUIV. ATOMS: 1 225 Fm-3m > MODE OF CALC=RELA > 8.474000 8.474000 8.474000 90.000000 90.000000 90.000000 > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 2 > Yb NPT= 781 R0=0.00001000 RMT= 2.5000 Z: 70.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > > so I guess a shift of 0.7 should be fine? > > Yb.in1old: > > WFFIL (WFPRI, SUPWF) > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) > 0 0.30 0.000 CONT > 0 -4.06 0.005 STOP > 1 -1.85 0.010 CONT > 1 0.30 0.000 CONT > 3 0.30 0.010 CONT > 2 0.30 0.010 CONT > K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window > > Yb.in1new > > WFFIL (WFPRI, SUPWF) > 8.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > 0.30 6 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) > 0 0.30 0.000 CONT > 0 -4.06 0.005 STOP > 1 -1.85 0.010 CONT > 1 0.30 0.000 CONT > 3 -1.00 0.000 CONT > 2 0.30 0.010 CONT > K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window > > Yb.in2old > > TOT (TOT,FOR,QTL,EFG,FERMI) > -9.0 24.0 EMIN, NE > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > 0 0 4 0 4 4 6 0 6 4 > 10. GMAX > FILE FILE/NOFILE write recprlist > > Yb.in2new > > TOT (TOT,FOR,QTL,EFG,FERMI) > -9.0 11.0 EMIN, NE > TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) > 0 0 4 0 4 4 6 0 6 4 > 10. GMAX > FILE FILE/NOFILE write recprlist > > new Yb.inc > > 16 0.70 NUMBER OF ORBITALS (EXCLUDING SPIN) > 1,-1,2 ( N,KAPPA,OCCUP) > 2,-1,2 ( N,KAPPA,OCCUP) > 2, 1,2 ( N,KAPPA,OCCUP) > 2,-2,4 ( N,KAPPA,OCCUP) > 3,-1,2 ( N,KAPPA,OCCUP) > 3, 1,2 ( N,KAPPA,OCCUP) > 3,-2,4 ( N,KAPPA,OCCUP) > 3, 2,4 ( N,KAPPA,OCCUP) > 3,-3,6 ( N,KAPPA,OCCUP) > 4,-1,2 ( N,KAPPA,OCCUP) > 4, 1,2 ( N,KAPPA,OCCUP) > 4,-2,4 ( N,KAPPA,OCCUP) > 4, 2,4 ( N,KAPPA,OCCUP) > 4,-3,6 ( N,KAPPA,OCCUP) > 4, 3,6 > 4,-4,7 > 0 > > > > > Error Message: > LAPW0 END > LAPW1 END > LAPW2 END > forrtl: severe (64): input conversion error, unit 20, file > /home/koitzsch/Yb/Yb.struct > 0: _call_remove_gp_range [0x3ff81a6c374] > 1: _call_remove_gp_range [0x3ff81a6c8f4] > 2: _call_remove_gp_range [0x3ff81a93b84] > 3: _call_remove_gp_range [0x3ff81a926e0] > 4: insld_ [insld.f: 92, 0x12000928c] > 5: hfsd_ [hfsd.f: 127, 0x120005ffc] > 6: main [for_main.c: 203, 0x120002554] > 7: __start [0x1200024c8] > > > Does anybody see, where the error is? > > > Thanks a lot! > > > > Christian Koitzsch > University of Fribourg > Department of Physics > CH-1700 Fribourg > Switzerland > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 9 Oct 2002 08:22:07 +0200 (MEST) From: Peter Blaha Subject: [WIEN]: research position (fwd) ==== Peter Blaha submitted the following contribution: ==== - ---------- Forwarded message ---------- Date: Tue, 08 Oct 2002 20:10:44 -0600 From: Holmann Brand To: pblaha@theochem.tuwien.ac.at Subject: research position Dear Dr. Prof. Blaha: I would very much appreciate it if you would kindly forward this message to any students and postdoctoral researchers that might be interested in the research position described below: The Materials Science Group of the Applied Physics Division at Los Alamos National Laboratory is seeking postdoctoral candidates to collaborate on the development and application of periodic quantum mechanical methods for studying molecular crystals. The successful candidate will be expected to interact with a multi-disciplinary team of theoretical and experimental scientists. For consideration, please send a resume to Dr. Holmann Brand at brand@lanl.gov Salary rates for this postdoctoral position in US dollars are: Years since PhD: Salary: PhD + 0 $56,700 PhD + 1 $58,200 PhD + 2 $59,700 PhD + 3 $61,100 PhD + 4 $62,700 Sincerely, Holmann V. Brand, Ph.D. Materials Science Group Phone: 505-667-2384 Mail Stop D413 Group Phone: 505-667-6504 Los Alamos National Laboratory Group Fax: 505-667-3726 Los Alamos, NM 87545 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 9 Oct 2002 20:55:38 +0800 From: "yulihua-wuhan" Subject: [WIEN]: charge convergence & U J value ==== "yulihua-wuhan" submitted the following contribution: ==== Dear Wien2k Users and developers: In the UG, the charge distance = Integrate[p(n)-p(n-1) ] dr, but the UG didn't tell the integration range.So if I use the charge convergence 0.0001, it means the distance in every MT sphere or the whole cell?? Of course, I think the unit is electron-charge, i.e. 0.0001 electron-charge. Are I right? I have another question about the SOC and LDA+U caculation.When I perform the "runsp -so -orb" caculation on U-based compound (with f-electron), the iteration show the oscillations of the energe and the charge, how can I solve the problem? And anyone have the experience of choosing the U,J value in the case.inorb on this kind of compound. Thinks yulihua ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 9 Oct 2002 08:16:35 -0700 (PDT) From: Battery Wien Subject: [WIEN]: Error File- lapw1 ==== Battery Wien submitted the following contribution: ==== This is my first time running wien 2k. I am running a CoO2 trigonal structure. The default parameters were used for the initialization. The run ended at lapw1 with the following error message: 'SELECT' - no energy limits found for L= 1 'SELECT' - E-bottom -8.18500 E-top -200.00000 Please Advise. Thanks. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 9 Oct 2002 10:36:31 -0700 (PDT) From: Claudio Lee Subject: [WIEN]: Obital polarization calculation ==== Claudio Lee submitted the following contribution: ==== Dear all, I have this problem, if you know the answer please help me. For spin polarized calculation. First step, my calculation has been included spin-obit coupling, and now, after this step has been done I want to include obital polarization into my calculation. Reading the wien2k menu, I follow the instruction but I dont know what I am doing wrong. Using this script x lapwd -up I got the error as it shows following: 'lapwdm' - can't open unit: 5 'lapwdm' - filename: Fe274.indm 'lapwdm' - status: old form: formatted So if anyone knows about this please help me, it will be better if you help me step by step how to include spin-obit coupling and obital polarization into the calculation of the spin-polarized case. Many thanks in advance. Sincerely, Claudio. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 09 Oct 2002 12:49:14 -0600 From: Pablo de la Mora Subject: [WIEN]: problems with parallel execution ==== Pablo de la Mora submitted the following contribution: ==== Dear Wien Users, I am having problems with parallel execution. I am doing a supercell for doping, it worked fine with a supercell with 4 cells, but with 2 cells it crashed. - ------------ End of the 'dayfile' 1.230u 0.930s 3:02.72 1.1% 0+0k 0+0io 60807pf+0w > lapw2 -up -p (02:06:41) running LAPW2 in parallel mode ** LAPW2 crashed! 0.080u 0.070s 0:00.15 100.0% 0+0k 0+0io 4056pf+0w > stop error - --------------- 'uplapw2.error' Error in LAPW2 ** Error in Parallel LAPW2 - --------------- 'case.struct' CaCuO2 dopado con Gd (50%) B LATTICE,NONEQUIV. ATOMS: 4 139 I4/mmm MODE OF CALC=RELA 10.506193 10.506193 13.108000 90.000000 90.000000 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT=-2 Ca NPT= 781 R0=0.00005000 RMT= 2.0000 Z: 20.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.00000000 Y=0.00000000 Z=0.50000000 MULT= 1 ISPLIT=-2 Gd NPT= 781 R0=0.00001000 RMT= 2.3000 Z: 64.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.50000000 Y=0.00000000 Z=0.25000000 MULT= 2 ISPLIT=-2 -3: X=0.00000000 Y=0.50000000 Z=0.25000000 Cu NPT= 781 R0=0.00005000 RMT= 1.9000 Z: 29.0 LOCAL ROT MATRIX: 0.7071068-0.7071068 0.0000000 0.7071068 0.7071068 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -4: X=0.75000000 Y=0.25000000 Z=0.25000000 MULT= 4 ISPLIT= 8 -4: X=0.25000000 Y=0.75000000 Z=0.25000000 -4: X=0.25000000 Y=0.25000000 Z=0.75000000 -4: X=0.25000000 Y=0.25000000 Z=0.25000000 O NPT= 781 R0=0.00010000 RMT= 1.8100 Z: 8.0 LOCAL ROT MATRIX: 0.0000000 0.7071068 0.7071068 0.0000000-0.7071068 0.7071068 1.0000000 0.0000000 0.0000000 16 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 etc. - ------------------ This has happened before in other cases. Sometimes the same case crashes and sometimes it does not! The cluster has 6 machines two with two 1GHz intel processors each four with one 500MHz intel processor Thanks Pablo de la Mora ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 9 Oct 2002 14:04:08 -0500 From: "Yang, Jinbo (UMR-Student)" Subject: [WIEN]: empty sphere ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Wien2k users I want to deal with some vacancies in the compound. So some "empty" spheres(Zero charge) will be used as vacancies to fill into the lattice. I already have read Dr. Peter's answer to a similar question on Sept 23. But I still am not able to do it. I also can not find the number of electrons in file case.in2. Does anyone has experience on this? I appreciated your help very much. Thank you so much Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165 Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 01:00:01 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: empty sphere ==== "Saeid Jalali" submitted the following contribution: ==== > I want to deal with some vacancies in the compound. So some "empty" spheres(Zero charge) will be used as vacancies > to fill into the lattice. I already have read Dr. Peter's answer to a similar question on Sept 23. But I still am not able to do it. Doing calculation including "dummy-atoms" using empty spheres can be considered as a trick to plot partial l-like DOS at an interstitial religion, where is not occupied by an atom: this is exactly answered and I have nothing more to add. This is not a trick to include vacancies: empty does not refer to vacuum. Although in the empty spheres there are no atoms, they are not essentially empty of electrons. Charge density illustrates where is less occupied by electrons. Your, S. Jalali ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 09 Oct 2002 18:39:14 -0600 From: Pablo de la Mora Subject: Re: [WIEN]: problems with parallel execution ==== Pablo de la Mora submitted the following contribution: ==== Pablo de la Mora wrote: > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > Dear Wien Users, > I am having problems with parallel execution. I am doing a > supercell for doping, it worked fine with a supercell with 4 cells, > but with 2 cells it crashed. > > ------------ End of the 'dayfile' > 1.230u 0.930s 3:02.72 1.1% 0+0k 0+0io 60807pf+0w > > lapw2 -up -p (02:06:41) running LAPW2 in parallel mode > ** LAPW2 crashed! > 0.080u 0.070s 0:00.15 100.0% 0+0k 0+0io 4056pf+0w > > > stop error > > --------------- 'uplapw2.error' > Error in LAPW2 > ** Error in Parallel LAPW2 > > --------------- 'case.struct' > CaCuO2 dopado con Gd > (50%) B > LATTICE,NONEQUIV. ATOMS: 4 139 > I4/mmm MODE OF > CALC=RELA > 10.506193 10.506193 13.108000 90.000000 90.000000 > 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 > Z=0.00000000 > MULT= 1 ISPLIT=-2 > Ca NPT= 781 R0=0.00005000 RMT= 2.0000 Z: > 20.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -2: X=0.00000000 Y=0.00000000 Z=0.50000000 > MULT= 1 ISPLIT=-2 > Gd NPT= 781 R0=0.00001000 RMT= 2.3000 Z: > 64.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -3: X=0.50000000 Y=0.00000000 Z=0.25000000 > MULT= 2 ISPLIT=-2 > -3: X=0.00000000 Y=0.50000000 Z=0.25000000 > Cu NPT= 781 R0=0.00005000 RMT= 1.9000 Z: > 29.0 LOCAL ROT MATRIX: 0.7071068-0.7071068 0.0000000 > 0.7071068 0.7071068 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -4: X=0.75000000 Y=0.25000000 Z=0.25000000 > MULT= 4 ISPLIT= 8 > -4: X=0.25000000 Y=0.75000000 Z=0.25000000 > -4: X=0.25000000 Y=0.25000000 Z=0.75000000 > -4: X=0.25000000 Y=0.25000000 Z=0.25000000 > O NPT= 781 R0=0.00010000 RMT= 1.8100 Z: > 8.0 LOCAL ROT MATRIX: 0.0000000 0.7071068 0.7071068 > 0.0000000-0.7071068 0.7071068 > 1.0000000 0.0000000 0.0000000 > 16 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0-1 0.0000000 > etc. > > ------------------ > This has happened before in other cases. Sometimes the same case > crashes and sometimes it does not! > The cluster has 6 machines > two with two 1GHz intel processors each > four with one 500MHz intel processor > Thanks I want to add that I did a calculation with the two dual (two 1GHz processors per machine; hydra and nodo1) the calculation did not crash: - -------------------- .machines file 2:hydra 2:hydra 2.nodo1 2:nodo1 - ---------------------- but with the non homogeneous cluster (including the 500MHz processors; nodo3,...) it did crash: - -------------------- .machines file 2:hydra 2:hydra 2.nodo1 2:nodo1 1:nodo3 1:nodo4 1:nodo5 - ------------------ Pablo de la Mora ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 24 Jun 1999 15:24:40 -0700 (PDT) From: Michelle Johannes Subject: Re: [WIEN]: Obital polarization calculation ==== Michelle Johannes submitted the following contribution: ==== Claudio- Here is (I hope) a simple recipe: After converging your s.o. calculation: 1) create a case.inorb file (see UG) 2) create a case.indm file (again see UG) 3) Change your case.indm file to case.indmc (running s-o plus LDA+U requires this) 4) runsp_lapw -so -orb Good luck, Michelle On Wed, 9 Oct 2002, Claudio Lee wrote: > ==== > Claudio Lee > submitted the following contribution: > ==== > > Dear all, > I have this problem, if you know the answer please > help me. > For spin polarized calculation. First step, my > calculation has been included spin-obit coupling, and > now, after this step has been done I want to include > obital polarization into my calculation. Reading the > wien2k menu, I follow the instruction but I dont know > what I am doing wrong. > Using this script > x lapwd -up > I got the error as it shows following: > 'lapwdm' - can't open unit: 5 > 'lapwdm' - filename: Fe274.indm > 'lapwdm' - status: old form: > formatted > > So if anyone knows about this please help me, it will > be better if you help me step by step how to include > spin-obit coupling and obital polarization into the > calculation of the spin-polarized case. > Many thanks in advance. > Sincerely, > Claudio. > > > > > > > __________________________________________________ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 08:23:58 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: problems with parallel execution ==== Peter Blaha submitted the following contribution: ==== The problems you have given below may have several reasons and one needs much more info and tests. a) Does it never crash with the two 1 GHz machines ? b) Does it always or sometimes crash when including the 500 MHz processors ? c) Only this case crashes or all/some others too ? Common directory NFS mounted ? WIEN2k runs everywhere ? can you connect to all machines without password ? Slow network connection ? (In particular when the error occurs only occasional) Did lapw1 work in parallel ? Do you see all vector_* files with proper (new) date ? What happens when you run x lapw2 -p interactively ? Regards > > I am having problems with parallel execution. I am doing a > > supercell for doping, it worked fine with a supercell with 4 cells, > > but with 2 cells it crashed. > > > > ------------ End of the 'dayfile' > > 1.230u 0.930s 3:02.72 1.1% 0+0k 0+0io 60807pf+0w > > > lapw2 -up -p (02:06:41) running LAPW2 in parallel mode > > ** LAPW2 crashed! > > 0.080u 0.070s 0:00.15 100.0% 0+0k 0+0io 4056pf+0w > > This has happened before in other cases. Sometimes the same case > > crashes and sometimes it does not! > > The cluster has 6 machines > > two with two 1GHz intel processors each > > four with one 500MHz intel processor > > Thanks > > I want to add that I did a calculation with the two dual (two 1GHz > processors per machine; hydra and nodo1) the calculation did not crash: > > -------------------- .machines file > 2:hydra > 2:hydra > 2.nodo1 > 2:nodo1 > ---------------------- > > but with the non homogeneous cluster (including the 500MHz processors; > nodo3,...) it did crash: > > -------------------- .machines file > 2:hydra > 2:hydra > 2.nodo1 > 2:nodo1 > 1:nodo3 > 1:nodo4 > 1:nodo5 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 08:27:13 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Error File- lapw1 ==== Peter Blaha submitted the following contribution: ==== > This is my first time running wien 2k. I am running a > CoO2 trigonal structure. The default parameters were > used for the initialization. The run ended at lapw1 > with the following error message: > > 'SELECT' - no energy limits found for L= 1 > > 'SELECT' - E-bottom -8.18500 E-top -200.00000 Hi battery! You need to supply much more information! Did it crash in the first cycle? Most likely your struct file or input-files are not ok. Did it crash after a few cycles ? Reduce mixing in case.inm, rm *.bro* case.scf x dstart (up/dn) and try another run(sp) 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 08:39:38 +0200 From: Stefaan Cottenier Subject: Re: [WIEN]: problems with parallel execution ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > I am having problems with parallel execution. Your problem could be similar to what I had some time ago. Check whether after the crash you can continue with 'x lapw2 -up -p'. If you can, then the problem most likely is due to a slow network, and you should add a few seconds of extra delay at the beginning of the lapw2para script. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 15:18:19 +0200 From: Moreau Philippe Subject: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== Moreau Philippe submitted the following contribution: ==== Dear all, We reported a couple of days ago a problem with the calculation of ELNES spectra with WIEN2K last version (ISPLIT=99). Thanks to the changes proposed by Peter (changes in atpar.F , thank you) no error message appears anymore and case.qtl is not filled with numerous and only zeros. Nevertheless, the obtained spectra are completely different (totally wrong compared to experiments) from previous WIEN97.10 calculations. we succesufully used the WIEN2K chain (initelnes, tetra, telnes) on a former case.qtl WIEN97 file. so the problem probabily comes from lapw2 generating a wrong case.qtl. has anyone performed ELNES calculations with WIEN2K ? and if yes with what changes if any ? thanks Philippe ---------------------------------------------------------------------------- | Dr. Philippe MOREAU | | | | Maître de Conférences à l'Université de Nantes | | Equipe PROSES (Propriétés, Réactivité, Organisation et Structure Electro- | | nique des Solides) | | | | INSTITUT DES MATERIAUX JEAN ROUXEL | Mailto:Philippe.Moreau@cnrs-imn.fr | | Laboratoire de Chimie des Solides | | | 2, rue de la Houssiniere | Phone: (33) 2 40 37 64 14 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 | http://www.cnrs-imn.fr | | FRANCE | | ---------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 10 Oct 2002 17:52:12 +0200 From: "Dariusz Chrobak" Subject: [WIEN]: Spin-up, spin-down calculations ==== "Dariusz Chrobak" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_001A_01C27085.C350AA00 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dear all, I am a new wien2k user. Therefore I have a simple (for you) question. I = have obtain negative parts of the spin-down charge density distribution = during example calculation for fcc Ni . I dont know what I am doing wrong.=20 Many thanks in advance. Sincerely, Darek - ------=_NextPart_000_001A_01C27085.C350AA00 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Dear all,
I am a new wien2k user. Therefore I have a simple (for you) = question.=20 I have obtain negative parts of the spin-down charge density = distribution=20 during example calculation for fcc Ni .
I dont know what I am doing wrong.
Many thanks in=20 advance.
Sincerely,
Darek
- ------=_NextPart_000_001A_01C27085.C350AA00-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 11 Oct 2002 13:30:56 -0700 (PDT) From: yanming Ma Subject: [WIEN]: Problem with compiling the WIEN for Parrallel in SGI machine ==== yanming Ma submitted the following contribution: ==== - --0-957832938-1034368256=:1905 Content-Type: text/plain; charset=us-ascii Dear Dr. Peter and WIEN2k users, When I try to compile the latest version of WIEN2k for parallel calculation in SGI machine, I met some problems. (1) What i have done to configue parallel execution during the compiling is the following. a). I choose "shared Memory Architecture?(y/n)" as "y" b).I choose "Do you have MPI and Scalapack installed....to run finergained parrallel?(y/n)" as "y". Because this sgi machine using MPI and PBS. I do have a big calculation should be done. c). Following these choices, I have selected the settings for sgi system are RP RP_LIB: -L /user/local /SCALAPACK -L/usr/local/BLACS/LIN -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi. FP FPOPT:-O -mpips4 -r10000 -freeform -64 (2) when I compile the Lapw1 package, this kind of error messages occurs. ld64: ERROR 33 : Unresolved text symbol "MPI_Irecv" -- 1st referenced by /usr/ Use linker option -v to see when and which objects, archives and dsos ar ld64: ERROR 33 : Unresolved text symbol "MPI_Pack_size" -- 1st referenced by / Use linker option -v to see when and which objects, archives and dsos ar ld64: ERROR 33 : Unresolved text symbol "MPI_Pack" -- 1st referenced by /usr/l Use linker option -v to see when and which objects, archives and dsos ar ld64: INFO 152: Output file removed because of error. *** Error code 2 (bu21) *** Error code 1 (bu21) Does any one have the same experience. Any comments are welcome. I will highly appreicate your help. Yanming Ma Steacie Institute for molecular Sciences, National Research Council of Canada - --------------------------------- Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com - --0-957832938-1034368256=:1905 Content-Type: text/html; charset=us-ascii

Dear Dr. Peter and WIEN2k users,

When I try to compile the latest version of WIEN2k for parallel calculation in SGI machine, I met some problems. 

(1) What i have done to configue parallel execution during the compiling is the following. a). I choose "shared Memory Architecture?(y/n)" as "y"

              b).I choose "Do you have MPI and Scalapack installed....to run finergained parrallel?(y/n)" as "y". Because this sgi machine using MPI and PBS. I do have a big calculation should be done.

             c). Following these choices, I have selected the settings for sgi system are

RP RP_LIB: -L /user/local /SCALAPACK -L/usr/local/BLACS/LIN -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi.

FP FPOPT:-O -mpips4 -r10000 -freeform -64

(2) when I compile the Lapw1 package, this kind of error messages occurs.

ld64: ERROR   33 : Unresolved text symbol "MPI_Irecv" -- 1st referenced by /usr/
      Use linker option -v to see when and which objects, archives and dsos ar
ld64: ERROR   33 : Unresolved text symbol "MPI_Pack_size" -- 1st referenced by /
        Use linker option -v to see when and which objects, archives and dsos ar
ld64: ERROR   33 : Unresolved text symbol "MPI_Pack" -- 1st referenced by /usr/l
        Use linker option -v to see when and which objects, archives and dsos ar
ld64: INFO    152: Output file removed because of error.
*** Error code 2 (bu21)
*** Error code 1 (bu21)

Does any one have the same experience. Any comments are welcome. I will highly appreicate your help.

Yanming Ma

Steacie Institute for molecular Sciences, National Research Council of Canada


Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com - --0-957832938-1034368256=:1905-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #38 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #39 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Tuesday, October 22 2002 Volume 2002 : Number 039 ---------------------------------------------------------------------- Date: Sun, 13 Oct 2002 10:37:25 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Problem with compiling the WIEN for Parrallel in SGI machine ==== Torsten Andersen submitted the following contribution: ==== Dear Ms. Ma, either you have not installed MPI, or it is not installed in your default library path. Check this. And if it is not in the default library path, but installed, add a -L/path/to/directory/of/MPI type of directive like you have to SCALAPACK and BLACS below. Best regards, Torsten Andersen. yanming Ma wrote: > Dear Dr. Peter and WIEN2k users, > > When I try to compile the latest version of WIEN2k for parallel > calculation in SGI machine, I met some problems. > > (1) What i have done to configue parallel execution during the > compiling is the following. a). I choose "shared Memory > Architecture?(y/n)" as "y" > > b).I choose "Do you have MPI and Scalapack > installed....to run finergained parrallel?(y/n)" as "y". Because this > sgi machine using MPI and PBS. I do have a big calculation should be done. > > c). Following these choices, I have selected the > settings for sgi system are > > RP RP_LIB: -L /user/local /SCALAPACK -L/usr/local/BLACS/LIN -lpblas > -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi. > > FP FPOPT:-O -mpips4 -r10000 -freeform -64 > > (2) when I compile the Lapw1 package, this kind of error messages occurs. > > ld64: ERROR 33 : Unresolved text symbol "MPI_Irecv" -- 1st > referenced by /usr/ > Use linker option -v to see when and which objects, archives and > dsos ar > ld64: ERROR 33 : Unresolved text symbol "MPI_Pack_size" -- 1st > referenced by / > Use linker option -v to see when and which objects, archives > and dsos ar > ld64: ERROR 33 : Unresolved text symbol "MPI_Pack" -- 1st referenced > by /usr/l > Use linker option -v to see when and which objects, archives > and dsos ar > ld64: INFO 152: Output file removed because of error. > *** Error code 2 (bu21) > *** Error code 1 (bu21) > > Does any one have the same experience. Any comments are welcome. I > will highly appreicate your help. > > Yanming Ma > > Steacie Institute for molecular Sciences, National Research Council of > Canada > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos, > & more > faith.yahoo.com - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 14 Oct 2002 11:07:54 +0200 From: =?us-ascii?Q?Anders_Froseth?= Subject: SV: [WIEN]: Problem with compiling the WIEN for Parrallel in SGI machine ==== =?us-ascii?Q?Anders_Froseth?= submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0002_01C27371.F1F0BD20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Yianming, I have a suggestion for you regarding the flags you are using (independent of your mpi part). To get a generally more efficient and numerically stable code you could replace - -O by - -O3 -OPT:IEEE_arithmetic = 0 -OPT:IEEE_roundoff = 0 you will then get a more agressive optimisation which is also safe with respect to numerical stability. Regards, Anders Dear Dr. Peter and WIEN2k users, When I try to compile the latest version of WIEN2k for parallel calculation in SGI machine, I met some problems. (1) What i have done to configue parallel execution during the compiling is the following. a). I choose "shared Memory Architecture?(y/n)" as "y" b).I choose "Do you have MPI and Scalapack installed....to run finergained parrallel?(y/n)" as "y". Because this sgi machine using MPI and PBS. I do have a big calculation should be done. c). Following these choices, I have selected the settings for sgi system are RP RP_LIB: -L /user/local /SCALAPACK -L/usr/local/BLACS/LIN -lpblas -lredist -ltools -lscalapack -lfbl acs -lblacs -lmpi. FP FPOPT:-O -mpips4 -r10000 -freeform -64 (2) when I compile the Lapw1 package, this kind of error messages occurs. ld64: ERROR 33 : Unresolved text symbol "MPI_Irecv" -- 1st referenced by /usr/ Use linker option -v to see when and which objects, archives and dsos ar ld64: ERROR 33 : Unresolved text symbol "MPI_Pack_size" -- 1st referenced by / Use linker option -v to see when and which objects, archives and dsos ar ld64: ERROR 33 : Unresolved text symbol "MPI_Pack" -- 1st referenced by /usr/l Use linker option -v to see when and which objects, archives and dsos ar ld64: INFO 152: Output file removed because of error. *** Error code 2 (bu21) *** Error code 1 (bu21) Does any one have the same experience. Any comments are welcome. I will highly appreicate your help. Yanming Ma Steacie Institute for molecular Sciences, National Research Council of Canada - ---------------------------------------------------------------------------- - -- Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com - ------=_NextPart_000_0002_01C27371.F1F0BD20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Yianming,
 
I have a=20 suggestion for you regarding the flags you are using (independent=20 of
your mpi=20 part). To get a generally more efficient and numerically = stable code=20 you could replace
 
-O
 
by=20
 
-O3=20 - -OPT:IEEE_arithmetic =3D 0  -OPT:IEEE_roundoff =3D = 0
 
you will then get a more agressive = optimisation which=20 is also safe with respect to numerical=20 stability.
 
Regards,
Anders

Dear Dr. Peter and WIEN2k users,

When I try to compile the latest version of WIEN2k for parallel=20 calculation in SGI machine, I met some problems. 

(1) What i have done to configue parallel execution during the = compiling is=20 the following. a). I choose "shared Memory Architecture?(y/n)" as = "y"

=

           &nbs= p; =20 b).I choose "Do you have MPI and Scalapack installed....to run = finergained=20 parrallel?(y/n)" as "y". Because this sgi machine using MPI and PBS. I = do have=20 a big calculation should be done.

=

           &nbs= p;=20 c). Following these choices, I have selected the settings for sgi = system=20 are

RP RP_LIB: -L /user/local /SCALAPACK -L/usr/local/BLACS/LIN -lpblas = -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi.

FP FPOPT:-O -mpips4 -r10000 -freeform -64

(2) when I compile the Lapw1 package, this kind of error messages=20 occurs.

ld64: ERROR   33 : Unresolved text symbol "MPI_Irecv" -- = 1st=20 referenced by /usr/
      Use linker = option -v to=20 see when and which objects, archives and dsos ar
ld64: = ERROR   33=20 : Unresolved text symbol "MPI_Pack_size" -- 1st referenced by=20 /
        Use linker option -v = to see=20 when and which objects, archives and dsos ar
ld64: = ERROR   33 :=20 Unresolved text symbol "MPI_Pack" -- 1st referenced by=20 /usr/l
        Use linker option = - -v to=20 see when and which objects, archives and dsos ar
ld64:=20 INFO    152: Output file removed because of = error.
*** Error=20 code 2 (bu21)
*** Error code 1 (bu21)

Does any one have the same experience. Any comments are welcome. I = will=20 highly appreicate your help.

Yanming Ma

Steacie Institute for molecular Sciences, National Research Council = of=20 Canada


Do you Yahoo!?
Faith Hill - = Exclusive=20 Performances, Videos, & more
faith.yahoo.com - ------=_NextPart_000_0002_01C27371.F1F0BD20-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 14 Oct 2002 17:50:29 +0200 From: "Kevin Jorissen" Subject: TETRA / Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Philippe, I perform ELNES calculations with WIEN2k, too. Sorry for taking so long to respond. After receiving Peter's new atpar.F, I too got good qtl-files. And yes, from them I also calculate spectra : I calculated H-spectra (orientation dependent) for graphite and they do compare to those calculated with WIEN97. I have no idea what the problem might be in your situation (maybe you solved it already). I'd like to ask you a question : how do you cope with the reading of the qtl-file by tetra? The xdos-matrix elements are written by outp.f as complex numbers, but read by tetra as real numbers. To solve this problem, we use a modified FORMAT-statement for reading, skipping the complex parts and reading the real parts. Do you use a similar trick, or do you have something better? Good luck with the calculations, thanks again to Peter Blaha for fixing the atpar.F, Kevin Jorissen EMAT, University of Antwerp - ----- Original Message ----- From: "Moreau Philippe" To: Sent: Thursday, October 10, 2002 3:18 PM Subject: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? > ==== Moreau Philippe submitted the following contribution: ==== > > > Dear all, > > We reported a couple of days ago a problem with the calculation of ELNES spectra with WIEN2K last version (ISPLIT=99). > > Thanks to the changes proposed by Peter (changes in atpar.F , thank you) no error message appears anymore and case.qtl is not filled with numerous and only zeros. Nevertheless, the obtained spectra are completely different (totally wrong compared to experiments) from previous WIEN97.10 calculations. > > we succesufully used the WIEN2K chain (initelnes, tetra, telnes) on a former case.qtl WIEN97 file. > > so the problem probabily comes from lapw2 generating a wrong case.qtl. > > has anyone performed ELNES calculations with WIEN2K ? and if yes with what changes if any ? > > thanks > > Philippe > > > > > > -------------------------------------------------------------------------- - -- > | Dr. Philippe MOREAU | > | | > | Maître de Conférences à l'Université de Nantes | > | Equipe PROSES (Propriétés, Réactivité, Organisation et Structure Electro- | > | nique des Solides) | > | | > | INSTITUT DES MATERIAUX JEAN ROUXEL | Mailto:Philippe.Moreau@cnrs-imn.fr | > | Laboratoire de Chimie des Solides | | > | 2, rue de la Houssiniere | Phone: (33) 2 40 37 64 14 | > | BP 32229 | Fax: (33) 2 40 37 39 95 | > | 44322 NANTES CEDEX 3 | http://www.cnrs-imn.fr | > | FRANCE | | > -------------------------------------------------------------------------- - -- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 14 Oct 2002 10:06:28 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Philippe, I perform ELNES calculations with WIEN2k, too. Sorry for taking so long to respond. After receiving Peter's new atpar.F, I too got good qtl-files. And yes, from them I also calculate spectra : I calculated H-spectra (orientation dependent) for graphite and they do compare to those calculated with WIEN97. I have no idea what the problem might be in your situation (maybe you solved it already). I'd like to ask you a question : how do you cope with the reading of the qtl-file by tetra? The xdos-matrix elements are written by outp.f as complex numbers, but read by tetra as real numbers. To solve this problem, we use a modified FORMAT-statement for reading, skipping the complex parts and reading the real parts. Do you use a similar trick, or do you have something better? Good luck with the calculations, thanks again to Peter Blaha for fixing the atpar.F, Kevin Jorissen EMAT, University of Antwerp - ----- Original Message ----- From: "Moreau Philippe" To: Sent: Thursday, October 10, 2002 3:18 PM Subject: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? > ==== Moreau Philippe submitted the following contribution: ==== > > > Dear all, > > We reported a couple of days ago a problem with the calculation of ELNES spectra with WIEN2K last version (ISPLIT=99). > > Thanks to the changes proposed by Peter (changes in atpar.F , thank you) no error message appears anymore and case.qtl is not filled with numerous and only zeros. Nevertheless, the obtained spectra are completely different (totally wrong compared to experiments) from previous WIEN97.10 calculations. > > we succesufully used the WIEN2K chain (initelnes, tetra, telnes) on a former case.qtl WIEN97 file. > > so the problem probabily comes from lapw2 generating a wrong case.qtl. > > has anyone performed ELNES calculations with WIEN2K ? and if yes with what changes if any ? > > thanks > > Philippe > > > > > > -------------------------------------------------------------------------- - -- > | Dr. Philippe MOREAU | > | | > | Maître de Conférences à l'Université de Nantes | > | Equipe PROSES (Propriétés, Réactivité, Organisation et Structure Electro- | > | nique des Solides) | > | | > | INSTITUT DES MATERIAUX JEAN ROUXEL | Mailto:Philippe.Moreau@cnrs-imn.fr | > | Laboratoire de Chimie des Solides | | > | 2, rue de la Houssiniere | Phone: (33) 2 40 37 64 14 | > | BP 32229 | Fax: (33) 2 40 37 39 95 | > | 44322 NANTES CEDEX 3 | http://www.cnrs-imn.fr | > | FRANCE | | > -------------------------------------------------------------------------- - -- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 15 Oct 2002 11:29:35 +0200 From: Thomas Claesson Subject: [WIEN]: Test ==== Thomas Claesson submitted the following contribution: ==== Sorry, just testing, don't bother. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 15 Oct 2002 21:13:22 +0800 From: "whoming" Subject: [WIEN]: About fine grained parallel computation in WIEN2K ==== "whoming" submitted the following contribution: ==== Dear all, Has anyone performed fine grained parallel calculation on SGI Origin 2000/38000? I have got a pecular result on it. I use TiC as the sample.And use all the same parameters to initialize the computation before the following three kinds of SCF calculations. "Serial calculation" and "k-point parallel calculation" get the same result and both are resonable in physics.But when I perform "fine grained parallel calculation".There are some bad results. After one cycle: 1) I have carefully compared all the files produced by lapw0, lapw1 in the three situations.They are all the same in values. 2)But the difference appears from lapw2. "TOTAL CHARGE INSIDE SPHERE" in tic.output2 produced by fine grained parallel calculation differs from that either in "Serial calculation" or in "k-point parallel calculation".(In the "k-point parallel calculation",you have to add up all the correspond "TOTAL CHARGE INSIDE SPHERE" from all the tic.output2_* files.) This is the first difference.And also I found that there is "QTL-B Value .EQ.7.30302!!!!!!" in tic.output2_1 in the fine grained calculation. 3)When I turn to tic.scf2 or tic.scf2_1 files, there is just one line like":GMA : POTENTIAL AND CHARGE CUT-OFF 14.00 Ry**.5" in the fine grained calculation. While in the other two calculations there are much more contents and all are the same in values. At the end, Serial calculation and k-point parallel calculation converged in about the same resonable result.But the fine grained parallel computation makes the total energy oscillate and appears "QTL-B Value" in tic.output2_1 files. Has anyone account the same problems as me?Your kind help will be appreciated very much! Thanks!! Yours, whoming P.S. The machines file for k-point parallel calculation: 1:localhost 1:localhost 1:localhost 1:localhost granularity:1 and it for fine grained parallel calculation: 1:localhost:4 granularity:1 There are only four k-points in tic.klist file. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 15 Oct 2002 17:54:47 +0200 From: Florent Boucher Subject: Re: TETRA / Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== Florent Boucher submitted the following contribution: ==== Dear Peter,
Dear Kevin,
we did with Philippe some more tests about the problem we found with the new WIEN2K and qtl files (ISPLIT=99).
If we still use the "old" way (standard LAPW, switch 0 in the in1 file) we have effectively the same results between wien97 and wien2K.
But if we use the "new" way (APW, switch 1 in the in1 file) we have completely different results for the elnes calculations. Please have a look at the two files included in attachments.
Your comments will be appreciated ...

Besides, concerning the point about the read statment in tetra.
I'd like to ask you a question : how do you cope with the reading of the
qtl-file by tetra?  The xdos-matrix elements are written by outp.f as
complex numbers, but read by tetra as real numbers.  To solve this problem,
we use a modified FORMAT-statement for reading, skipping the complex parts
and reading the real parts.  Do you use a similar trick, or do you have
something better?

All seems to be OK. There is a small trick:
outp.f writes (lxdos2*(lxdos2+1)/2=136 complex numbers ->   lxdos2*(lxdos2+1)=272 real numbers)
tetra.f reads lxdos2*(lxdos2+1)=272 real numbers (The odd numbers correspond to real part of qtl and even numbers to the imaginary parts of qtl)
So, normally you do not need to change tetra

Regards
Philippe, Florent
Kevin Jorissen a écrit:
====
"Kevin Jorissen" <kevin.jorissen@ua.ac.be>
submitted the following contribution:
====

Dear Philippe,


I perform ELNES calculations with WIEN2k, too.  Sorry for taking so long to
respond.
After receiving Peter's new atpar.F, I too got good qtl-files.  And yes,
from them I also calculate spectra : I calculated H-spectra (orientation
dependent) for graphite and they do compare to those calculated with WIEN97.
I have no idea what the problem might be in your situation (maybe you solved
it already).

I'd like to ask you a question : how do you cope with the reading of the
qtl-file by tetra?  The xdos-matrix elements are written by outp.f as
complex numbers, but read by tetra as real numbers.  To solve this problem,
we use a modified FORMAT-statement for reading, skipping the complex parts
and reading the real parts.  Do you use a similar trick, or do you have
something better?

Good luck with the calculations,
thanks again to Peter Blaha for fixing the atpar.F,

Kevin Jorissen
EMAT, University of Antwerp


- ----- Original Message -----
From: "Moreau Philippe" <Philippe.Moreau@cnrs-imn.fr>
To: <wien@zeus.theochem.tuwien.ac.at>
Sent: Thursday, October 10, 2002 3:18 PM
Subject: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99?


  
==== Moreau Philippe submitted the following contribution: ====


Dear all,

We reported a couple of days ago a problem with the calculation of ELNES
    
spectra with WIEN2K last version (ISPLIT=99).
  
Thanks to the changes proposed by Peter (changes in atpar.F , thank you)
    
no error message appears anymore and case.qtl is not filled with numerous
and only zeros. Nevertheless, the obtained spectra are completely different
(totally wrong compared to experiments) from previous WIEN97.10
calculations.
  
we succesufully used the WIEN2K chain (initelnes, tetra, telnes) on a
    
former case.qtl WIEN97 file.
  
so the problem probabily comes from lapw2 generating a wrong case.qtl.

has anyone performed ELNES calculations with WIEN2K ? and if yes with what
    
changes if any ?
  
thanks

Philippe





- --------------------------------------------------------------------------
    
--
  
| Dr. Philippe MOREAU |
| |
| Maître de Conférences à l'Université de Nantes |
| Equipe PROSES (Propriétés, Réactivité, Organisation et Structure
    
Electro- |
  
| nique des Solides) |
| |
| INSTITUT DES MATERIAUX JEAN ROUXEL | Mailto:Philippe.Moreau@cnrs-imn.fr
    
|
  
| Laboratoire de Chimie des Solides | |
| 2, rue de la Houssiniere | Phone: (33) 2 40 37 64 14 |
| BP 32229 | Fax: (33) 2 40 37 39 95 |
| 44322 NANTES CEDEX 3 | http://www.cnrs-imn.fr |
| FRANCE | |
- --------------------------------------------------------------------------
    
-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe
send mail to majordomo@zeus.theochem.tuwien.ac.at ====

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====

  

-- 
 --------------------------------------------------------------------------
| Florent BOUCHER                    |                                     |
| Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr  |
| 2, rue de la Houssinière           | Phone: (33) 2 40 37 39 24           |
| BP 32229                           | Fax:   (33) 2 40 37 39 95           |
| 44322 NANTES CEDEX 3 (FRANCE)      | http://www.cnrs-imn.fr              |
 --------------------------------------------------------------------------

==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 15 Oct 2002 20:45:51 -0200 (BDB) From: vivienne denise falcao Subject: [WIEN]: Problems with X-Ray Spectra ==== vivienne denise falcao submitted the following contribution: ==== Dear All, I am using wien 97 to calculate x-ray spectra. I need to exchange the energy range because in my calculations I wish a energy range between - -5 and 25 eV for x-ray absorption spectra. But, in my calculations the maximum energy in the case.xspec is 12 eV. What can I do to exchange the energy range? I hope answer. Thankfull, Vivienne. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 08:50:23 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Problems with X-Ray Spectra ==== "Saeid Jalali" submitted the following contribution: ==== > I am using wien 97 to calculate x-ray spectra. I need to exchange > the energy range because in my calculations I wish a energy range between > -5 and 25 eV for x-ray absorption spectra. But, in my calculations the > maximum energy in the case.xspec is 12 eV. What can I do to exchange the > energy range? Upper limit of energy window is 1.5Ry in case.in1 file, so to include state with higher energy one should increase it, and then run lapw1 to make sense the change. Upper limit of energy window is 1.5Ry in case.int file, so to see included state with higher energy one should increase it too, and then run tetra to produce favorite DOS's, which are essential in this respect. Your, S. Jalali ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 08:04:30 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Problems with X-Ray Spectra ==== Torsten Andersen submitted the following contribution: ==== Dear Vivienne, in addition to what Saeid already said... There is around 13.6eV on a Ry, so to get up to 25eV, all the upper limits of your energy windows must be increased to at least 2Ry. Best regards, Torsten Andersen. vivienne denise falcao wrote: >==== >vivienne denise falcao >submitted the following contribution: >==== > >Dear All, > > I am using wien 97 to calculate x-ray spectra. I need to exchange >the energy range because in my calculations I wish a energy range between >-5 and 25 eV for x-ray absorption spectra. But, in my calculations the >maximum energy in the case.xspec is 12 eV. What can I do to exchange the >energy range? > I hope answer. > >Thankfull, > >Vivienne. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 08:07:37 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: About fine grained parallel computation in WIEN2K ==== Peter Blaha submitted the following contribution: ==== > Has anyone performed fine grained parallel calculation on SGI > Origin 2000/38000? > 2)But the difference appears from lapw2. "TOTAL CHARGE INSIDE > SPHERE" in tic.output2 produced by fine grained > parallel calculation differs from that either in "Serial calculation" or in > "k-point parallel calculation".(In the "k-point parallel > calculation",you have to add up all the correspond "TOTAL CHARGE INSIDE > SPHERE" from all the tic.output2_* files.) > This is the first difference.And also I found that there is "QTL-B Value > .EQ.7.30302!!!!!!" in tic.output2_1 in the fine grained calculation. Dear whoming Probably you are using more processors than you have "blocks" of basis functions. check that #basis fkt/IBLOCK is larger than you number of processors for #basis fkt do grep :rkm in TiC.scf1 for IBLOCK look in modules.F in SRC_lapw2 (usually 128) Fine grain parallelization makes no sense for small cases like TiC. Best wishes Georg 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 09:59:55 +0200 From: "Kevin Jorissen" Subject: Re: TETRA / Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Florent and Philippe, I have used the default .in1-file, specifying global LAPW (0) (as recommended in the UG) and APW (1) for all the choices on the next lines. Did you perform a 'full APW'-calculation? (I'll try). By the way, I did not receive the attachments to your mail. About the modification of tetra.f : I must apologize for being unclear. The modification we make is for F-case (ISPLIT=88), where tetra reads : read(4,208)(xqtl(isort,i1),i1=1,lxdos2) 208 FORMAT((10F10.5)) while outp.f writes : if(isplit(jatom).eq.88) then read(15,208) (xqtl(i,i,1),i=1,lxdos2) IF(jb.EQ.JBAND) WRITE(16,208) & (xqtl(i,i,1)/100.d0,i=1,lxdos2) ENDIF 208 FORMAT((10F10.5)) So, while your analysis is correct for the 99-case, there is still a conflict in the 88-case. What I did is changing in tetra.f : if(text(isort)(13:20).eq.'xdos(i,j') then if(lxdos.ne.3) stop 'LXDOS must be 3 for ISPLIT 99 or 88' read(4,208)(xqtl(isort,i1),i1=1,(lxdos2)*(lxdos2+1)) else if(text(isort)(13:20).eq.'xdos(i,i') then read(4,207)(xqtl(isort,i1),i1=1,lxdos2) endif 208 FORMAT((10F10.5)) 207 FORMAT(5(F10.5,10x)) and this works. Perhaps it would be preferable to make tetra read ALL the numbers, but I don't fully understand the working of tetra - maybe you can comment on this. Of course, one can always use 99-option (I don't use 88 often). Please do send me the files you intended to include, I promise to have a look at them asap. bye! Kevin. - ----- Original Message ----- From: "Florent Boucher" To: Sent: Tuesday, October 15, 2002 5:54 PM Subject: Re: TETRA / Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? > ==== Florent Boucher submitted the following contribution: ==== Dear Peter, > Dear Kevin, > we did with Philippe some more tests about the problem we found with the new WIEN2K and qtl files (ISPLIT=99). > If we still use the "old" way (standard LAPW, switch 0 in the in1 file) we have effectively the same results between wien97 and wien2K. > But if we use the "new" way (APW, switch 1 in the in1 file) we have completely different results for the elnes calculations. Please have a look at the two files included in attachments. > Your comments will be appreciated ... > > Besides, concerning the point about the read statment in tetra. > > I'd like to ask you a question : how do you cope with the reading of the > qtl-file by tetra? The xdos-matrix elements are written by outp.f as > complex numbers, but read by tetra as real numbers. To solve this problem, > we use a modified FORMAT-statement for reading, skipping the complex parts > and reading the real parts. Do you use a similar trick, or do you have > something better? > > All seems to be OK. There is a small trick: > outp.f writes (lxdos2*(lxdos2+1)/2=136 complex numbers -> lxdos2*(lxdos2+1)=272 real numbers) > tetra.f reads lxdos2*(lxdos2+1)=272 real numbers (The odd numbers correspond to real part of qtl and even numbers to the imaginary parts of qtl) > So, normally you do not need to change tetra > > Regards > Philippe, Florent > Kevin Jorissen a écrit: > > ==== > "Kevin Jorissen" > submitted the following contribution: > ==== > > Dear Philippe, > > > I perform ELNES calculations with WIEN2k, too. Sorry for taking so long to > respond. > After receiving Peter's new atpar.F, I too got good qtl-files. And yes, > from them I also calculate spectra : I calculated H-spectra (orientation > dependent) for graphite and they do compare to those calculated with WIEN97. > I have no idea what the problem might be in your situation (maybe you solved > it already). > > I'd like to ask you a question : how do you cope with the reading of the > qtl-file by tetra? The xdos-matrix elements are written by outp.f as > complex numbers, but read by tetra as real numbers. To solve this problem, > we use a modified FORMAT-statement for reading, skipping the complex parts > and reading the real parts. Do you use a similar trick, or do you have > something better? > > Good luck with the calculations, > thanks again to Peter Blaha for fixing the atpar.F, > > Kevin Jorissen > EMAT, University of Antwerp > > > ----- Original Message ----- > From: "Moreau Philippe" > To: > Sent: Thursday, October 10, 2002 3:18 PM > Subject: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? > > > ==== Moreau Philippe submitted the following contribution: ==== > > > Dear all, > > We reported a couple of days ago a problem with the calculation of ELNES > spectra with WIEN2K last version (ISPLIT=99). > Thanks to the changes proposed by Peter (changes in atpar.F , thank you) > no error message appears anymore and case.qtl is not filled with numerous > and only zeros. Nevertheless, the obtained spectra are completely different > (totally wrong compared to experiments) from previous WIEN97.10 > calculations. > we succesufully used the WIEN2K chain (initelnes, tetra, telnes) on a > former case.qtl WIEN97 file. > so the problem probabily comes from lapw2 generating a wrong case.qtl. > > has anyone performed ELNES calculations with WIEN2K ? and if yes with what > changes if any ? > thanks > > Philippe > > > > > > -------------------------------------------------------------------------- > -- > | Dr. Philippe MOREAU | > | | > | Maître de Conférences à l'Université de Nantes | > | Equipe PROSES (Propriétés, Réactivité, Organisation et Structure > Electro- | > | nique des Solides) | > | | > | INSTITUT DES MATERIAUX JEAN ROUXEL | Mailto:Philippe.Moreau@cnrs-imn.fr > | > | Laboratoire de Chimie des Solides | | > | 2, rue de la Houssiniere | Phone: (33) 2 40 37 64 14 | > | BP 32229 | Fax: (33) 2 40 37 39 95 | > | 44322 NANTES CEDEX 3 | http://www.cnrs-imn.fr | > | FRANCE | | > -------------------------------------------------------------------------- > -- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe > send mail to majordomo@zeus.theochem.tuwien.ac.at ==== > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > > -- > ------------------------------------------------------------------------- - - > | Florent BOUCHER | | > | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | > | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | > | BP 32229 | Fax: (33) 2 40 37 39 95 | > | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | > ------------------------------------------------------------------------- - - > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 18:06:16 +0900 From: Isao TANAKA Subject: [WIEN]: Post-Doc position in Kyoto ==== Isao TANAKA submitted the following contribution: ==== A joint program on computational materials science between Department of Materials Chemistry and Department of Materials Science & Engineering of Kyoto University, Japan has an immediate opening for a few Post-Doc scientists to support on-going activities in the group. Design and exploration of advanced materials by means of computational modeling and experimental works are the objectives of the group. Intimate collaborations with experimental groups in both academic and industry sites are being constructed. Materials of our interests include optical, electronic, functional, magnetic, structural, energy-storage, catalysis and other kinds of materials. For details visit http://cms.mtl.kyoto-u.ac.jp/users/tanaka/PostDocE.htm ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 17:56:36 +0800 (CST) From: whoming@sohu.com Subject: Re:Re: [WIEN]: About fine grained parallel computation in WIEN2K ==== whoming@sohu.com submitted the following contribution: ==== - ------=_Part_928_58566.1034762196703 Content-Type: multipart/alternative; boundary="----=_Part_927_825038.1034762196702" - ------=_Part_927_825038.1034762196702 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Dear Peter Blaha, Thanks very much for your replying! But I just can understand clearly your comment and suggestions. I have do grep :RKM of tic.scf1 and it looks like: :RKM : MATRIX SIZE 155LOs: 18 RKM= 6.93 WEIGHT= 1.00 PGR: In modules.F IBLOCK is 128. Would you please give me more suggestions on this problem?Thanks! Yours, whoming - ----- Original Message ----- From: Peter Blaha To: wien@zeus.theochem.tuwien.ac.at Subject: Re: [WIEN]: About fine grained parallel computation in WIEN2K Sent: Wed Oct 16 14:07:37 CST 2002 ==== Peter Blaha submitted the following contribution: ==== > Has anyone performed fine grained parallel calculation on SGI > Origin 2000/38000? > 2)But the difference appears from lapw2. "TOTAL CHARGE INSIDE > SPHERE" in tic.output2 produced by fine grained > parallel calculation differs from that either in "Serial calculation" or in > "k-point parallel calculation".(In the "k-point parallel > calculation",you have to add up all the correspond "TOTAL CHARGE INSIDE > SPHERE" from all the tic.output2_* files.) > This is the first difference.And also I found that there is "QTL-B Value > .EQ.7.30302!!!!!!" in tic.output2_1 in the fine grained calculation. Dear whoming Probably you are using more processors than you have "blocks" of basis functions. check that #basis fkt/IBLOCK is larger than you number of processors for #basis fkt do grep :rkm in TiC.scf1 for IBLOCK look in modules.F in SRC_lapw2 (usually 128) Fine grain parallelization makes no sense for small cases like TiC. Best wishes Georg 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - ------=_Part_927_825038.1034762196702 Content-Type: text/html Content-Transfer-Encoding: 8bit

Dear Peter Blaha,

           Thanks very much for your replying!

 But I just can understand clearly your comment and suggestions.

I have do grep :RKM of tic.scf1 and it looks like:


:RKM  : MATRIX SIZE  155LOs:  18  RKM= 6.93  WEIGHT= 1.00  PGR:

In modules.F IBLOCK is 128. 

        Would you please give me more suggestions on this problem?Thanks!

Yours,

       whoming

----- Original Message -----

From: Peter Blaha
To: wien@zeus.theochem.tuwien.ac.at
Subject: Re: [WIEN]: About fine grained parallel computation in WIEN2K
Sent: Wed Oct 16 14:07:37 CST 2002

====
Peter Blaha
submitted the following contribution:
====

> Has anyone performed fine grained parallel calculation on SGI
> Origin 2000/38000?
> 2)But the difference appears from lapw2. "TOTAL CHARGE INSIDE
> SPHERE" in tic.output2 produced by fine grained
> parallel calculation differs from that either in "Serial calculation" or in
> "k-point parallel calculation".(In the "k-point parallel
> calculation",you have to add up all the correspond "TOTAL CHARGE INSIDE
> SPHERE" from all the tic.output2_* files.)
> This is the first difference.And also I found that there is "QTL-B Value
> .EQ.7.30302!!!!!!" in tic.output2_1 in the fine grained calculation.

Dear whoming

Probably you are using more processors than you have "blocks" of basis
functions. check that
#basis fkt/IBLOCK is larger than you number of processors

for #basis fkt do grep :rkm in! TiC.scf1
for IBLOCK look in modules.F in SRC_lapw2 (usually 128)

Fine grain parallelization makes no sense for small cases like TiC.

Best wishes Georg


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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====





- ------=_Part_927_825038.1034762196702-- - ------=_Part_928_58566.1034762196703-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 14:38:40 +0200 From: Florent Boucher Subject: Re: TETRA / Re: [WIEN]: ELNES calculations with WIEN2k, wrong .qtl for isplit=99? ==== Florent Boucher submitted the following contribution: ==== Dear Kevin, I had also a look for the 88 option. Effectively, in this case there is a problem. outp writes lxdos2 complex numbers and tetra read lxdos2 real numbers... I check the outp part and it seems that this program should be change in order to write only the real part of xqtl (imaginary part is always zero). So I propose this change for outp.f if(isplit(jatom).eq.88) then read(15,208) (xqtl(i,i,1),i=1,lxdos2) IF(jb.EQ.JBAND) WRITE(16,208) & (real(xqtl(i,i,1))/100.d0,i=1,lxdos2) <== ENDIF 208 FORMAT((10F10.5)) Concerning the in1 options, we used LAPW(0) for all the Ylm except for those explicitely written in the in1 file. Regards Florent Kevin Jorissen a écrit: >==== >"Kevin Jorissen" >submitted the following contribution: >==== > >Dear Florent and Philippe, > >I have used the default .in1-file, specifying global LAPW (0) (as >recommended in the UG) and APW (1) for all the choices on the next lines. >Did you perform a 'full APW'-calculation? (I'll try). >By the way, I did not receive the attachments to your mail. > > >About the modification of tetra.f : I must apologize for being unclear. The >modification we make is for F-case (ISPLIT=88), where tetra reads : > read(4,208)(xqtl(isort,i1),i1=1,lxdos2) > 208 FORMAT((10F10.5)) > >while outp.f writes : > if(isplit(jatom).eq.88) then > read(15,208) (xqtl(i,i,1),i=1,lxdos2) > IF(jb.EQ.JBAND) WRITE(16,208) & > (xqtl(i,i,1)/100.d0,i=1,lxdos2) > ENDIF > 208 FORMAT((10F10.5)) > > >So, while your analysis is correct for the 99-case, there is still a >conflict in the 88-case. What I did is changing in tetra.f : > > if(text(isort)(13:20).eq.'xdos(i,j') then > if(lxdos.ne.3) stop 'LXDOS must be 3 for ISPLIT 99 or >88' > read(4,208)(xqtl(isort,i1),i1=1,(lxdos2)*(lxdos2+1)) > else if(text(isort)(13:20).eq.'xdos(i,i') then > read(4,207)(xqtl(isort,i1),i1=1,lxdos2) > endif > 208 FORMAT((10F10.5)) > 207 FORMAT(5(F10.5,10x)) > >and this works. Perhaps it would be preferable to make tetra read ALL the >numbers, but I don't fully understand the working of tetra - maybe you can >comment on this. >Of course, one can always use 99-option (I don't use 88 often). > > >Please do send me the files you intended to include, I promise to have a >look at them asap. bye! > >Kevin. > > > > > - -- -------------------------------------------------------------------------- | Florent BOUCHER | | | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 16 Oct 2002 15:14:51 +0200 From: georg@chem.au.dk Subject: Re:Re: [WIEN]: About fine grained parallel computation in WIEN2K ==== georg@chem.au.dk submitted the following contribution: ==== You have 155 basis functions (lo's aren't paralised) and you block size is 128. This means you have only two blocks and should max use two processors. Quoting whoming@sohu.com: > Dear Peter Blaha, > Thanks very much for your replying! > But I just can understand clearly your comment and suggestions. > I have do grep :RKM of tic.scf1 and it looks like: > > :RKM : MATRIX SIZE 155LOs: 18 RKM= 6.93 WEIGHT= 1.00 PGR: > In modules.F IBLOCK is 128. > Would you please give me more suggestions on this problem?Thanks! > Yours, > whoming > ----- Original Message ----- > > From: Peter Blaha > To: wien@zeus.theochem.tuwien.ac.at > Subject: Re: [WIEN]: About fine grained parallel computation in WIEN2K > Sent: Wed Oct 16 14:07:37 CST 2002 > > ==== > Peter Blaha > submitted the following contribution: > ==== > > > Has anyone performed fine grained parallel calculation on SGI > > Origin 2000/38000? > > 2)But the difference appears from lapw2. "TOTAL CHARGE INSIDE > > SPHERE" in tic.output2 produced by fine grained > > parallel calculation differs from that either in "Serial calculation" or > in > > "k-point parallel calculation".(In the "k-point parallel > > calculation",you have to add up all the correspond "TOTAL CHARGE INSIDE > > SPHERE" from all the tic.output2_* files.) > > This is the first difference.And also I found that there is "QTL-B Value > > .EQ.7.30302!!!!!!" in tic.output2_1 in the fine grained calculation. > > Dear whoming > > Probably you are using more processors than you have "blocks" of basis > functions. check that > #basis fkt/IBLOCK is larger than you number of processors > > for #basis fkt do grep :rkm in TiC.scf1 > for IBLOCK look in modules.F in SRC_lapw2 (usually 128) > > Fine grain parallelization makes no sense for small cases like TiC. > > Best wishes Georg > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 17 Oct 2002 17:55:08 -0600 From: Pablo de la Mora Subject: [WIEN]: total energy ==== Pablo de la Mora submitted the following contribution: ==== Dear Wien Users, Many times the total energy of the system jumps to a high (negative) value, most of the time it is not important but in other times it is. For example I was doing Ni for testing purposes and when I restarted the energy now was different. aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653578 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653534 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -6538.210862 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -8286.488860 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766858 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766826 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653536 aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653525 On other case a supercell of CaCuO2: :ENE : ********** TOTAL ENERGY IN Ry = -42866.543562 :ENE : ********** TOTAL ENERGY IN Ry = -42864.264895 :ENE : ********** TOTAL ENERGY IN Ry = -476714.854134 :ENE : ********** TOTAL ENERGY IN Ry = -476714.826215 ....15 iterations :ENE : ********** TOTAL ENERGY IN Ry = -476831.026046 :ENE : ********** TOTAL ENERGY IN Ry = -476870.308446 :ENE : ********** TOTAL ENERGY IN Ry = -42863.676057 :ENE : ********** TOTAL ENERGY IN Ry = -42871.305960 :ENE : ********** TOTAL ENERGY IN Ry = -42863.880914 :ENE : ********** TOTAL ENERGY IN Ry = -42864.285966 :ENE : ********** TOTAL ENERGY IN Ry = -42863.310026 Is there something I haven't done (this happens in differents computing systems!) Thank you Pablo de la Mora ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 09:56:08 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: MPI ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all I met a question about parallel using MPI. The system I used is Linux(dell cluster node0-8).I used pgf90 and pgcc as the specify compiler. When it asked "shared Memory achitechtrue?" answer "n" Remote shell 'rsh' "do you have MPI and Scalapack ......" y compiler:pgf90 Recommended options for system linuxpgi are: RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L /usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs - -lmpi FPOPT(par.comp.options): -Mfreeform -fast -Kieee MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ Current settings: RP RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L /usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs - -lmpi FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee MP MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ and I save it. but when I recompile lapw0,lapw1 and lapw2 it gives such error if [ -f .parallel ]; then \ rm -f .parallel modules.o reallocate.o energy.o gtfnam.o lapw0.o *.mod; \ fi touch .sequential make lapw0 FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee' make[1]: Entering directory `/home/ysz/wien2k/SRC_lapw0' pgcc -c cputim.c pgf90 -Mfreeform -fast -Kieee -c modules.F pgf90 -Mfreeform -fast -Kieee -c reallocate.f pgf90 -Mfreeform -fast -Kieee -c ainv.f pgf90 -Mfreeform -fast -Kieee -c blyp.f pgf90 -Mfreeform -fast -Kieee -c charg2.f pgf90 -Mfreeform -fast -Kieee -c charg3.f pgf90 -Mfreeform -fast -Kieee -c charge.f pgf90 -Mfreeform -fast -Kieee -c chfac.f pgf90 -Mfreeform -fast -Kieee -c chslv.f pgf90 -Mfreeform -fast -Kieee -c corgga.f pgf90 -Mfreeform -fast -Kieee -c cub_xc_back.f pgf90 -Mfreeform -fast -Kieee -c corlsd.f pgf90 -Mfreeform -fast -Kieee -c dlu.f pgf90 -Mfreeform -fast -Kieee -c drho.f pgf90 -Mfreeform -fast -Kieee -c dfxhpbe.f pgf90 -Mfreeform -fast -Kieee -c dylm.f pgf90 -Mfreeform -fast -Kieee -c efg.f pgf90 -Mfreeform -fast -Kieee -c energy.F pgf90 -Mfreeform -fast -Kieee -c errclr.f pgf90 -Mfreeform -fast -Kieee -c errflg.f pgf90 -Mfreeform -fast -Kieee -c ev92.f pgf90 -Mfreeform -fast -Kieee -c ev92ex.f pgf90 -Mfreeform -fast -Kieee -c exch.f pgf90 -Mfreeform -fast -Kieee -c exch17.f pgf90 -Mfreeform -fast -Kieee -c exrevpbe.f pgf90 -Mfreeform -fast -Kieee -c fithi.f pgf90 -Mfreeform -fast -Kieee -c fxhpbe.f pgf90 -Mfreeform -fast -Kieee -c gbass.f pgf90 -Mfreeform -fast -Kieee -c gcor.f pgf90 -Mfreeform -fast -Kieee -c gea.f pgf90 -Mfreeform -fast -Kieee -c geaex.f pgf90 -Mfreeform -fast -Kieee -c getfft.f pgf90 -Mfreeform -fast -Kieee -c getff1.f pgf90 -Mfreeform -fast -Kieee -c gpoint.f pgf90 -Mfreeform -fast -Kieee -c grans.f pgf90 -Mfreeform -fast -Kieee -c gtfnam.F pgf90 -Mfreeform -fast -Kieee -c hcth.f pgf90 -Mfreeform -fast -Kieee -c ifflim.f pgf90 -Mfreeform -fast -Kieee -c kcis.f pgf90 -Mfreeform -fast -Kieee -c lapw0.F pgf90 -Mfreeform -fast -Kieee -c latgen.f pgf90 -Mfreeform -fast -Kieee -c multfc.f pgf90 -Mfreeform -fast -Kieee -c multsu.f pgf90 -Mfreeform -fast -Kieee -c outerr.f pgf90 -Mfreeform -fast -Kieee -c pbe1.f pgf90 -Mfreeform -fast -Kieee -c poissn.f pgf90 -Mfreeform -fast -Kieee -c potfac.f pgf90 -Mfreeform -fast -Kieee -c pwxad4.f pgf90 -Mfreeform -fast -Kieee -c pwxad5.f pgf90 -Mfreeform -fast -Kieee -c qranf.f pgf90 -Mfreeform -fast -Kieee -c readstruct.f pgf90 -Mfreeform -fast -Kieee -c rean0.f pgf90 -Mfreeform -fast -Kieee -c rean1.f pgf90 -Mfreeform -fast -Kieee -c rean3.f pgf90 -Mfreeform -fast -Kieee -c rean4.f pgf90 -Mfreeform -fast -Kieee -c rotate.f pgf90 -Mfreeform -fast -Kieee -c rotdef.f pgf90 -Mfreeform -fast -Kieee -c setff0.f pgf90 -Mfreeform -fast -Kieee -c setff1.f pgf90 -Mfreeform -fast -Kieee -c setfft.f pgf90 -Mfreeform -fast -Kieee -c setff2.f pgf90 -Mfreeform -fast -Kieee -c seval.f pgf90 -Mfreeform -fast -Kieee -c sevald.f pgf90 -Mfreeform -fast -Kieee -c sevaldd.f pgf90 -Mfreeform -fast -Kieee -c sevali.f pgf90 -Mfreeform -fast -Kieee -c sevalin.f pgf90 -Mfreeform -fast -Kieee -c sicpbe.f pgf90 -Mfreeform -fast -Kieee -c sphbes.f pgf90 -Mfreeform -fast -Kieee -c spline.f pgf90 -Mfreeform -fast -Kieee -c srolyl.f pgf90 -Mfreeform -fast -Kieee -c stern.f pgf90 -Mfreeform -fast -Kieee -c sumfac.f pgf90 -Mfreeform -fast -Kieee -c suml.f pgf90 -Mfreeform -fast -Kieee -c th1.f pgf90 -Mfreeform -fast -Kieee -c th2.f pgf90 -Mfreeform -fast -Kieee -c vpw91.f pgf90 -Mfreeform -fast -Kieee -c vresp.f pgf90 -Mfreeform -fast -Kieee -c vs98.f pgf90 -Mfreeform -fast -Kieee -c ylm.f pgf90 -Mfreeform -fast -Kieee -c zfft3d.f pgf90 -o lapw0 cputim.o modules.o reallocate.o ainv.o blyp.o charg2.o charg3.o charge.o chfac.o chslv.o corgga.o cub_xc_back.o corlsd.o dlu.o drho.o dfxhpbe.o dylm.o efg.o energy.o errclr.o errflg.o ev92.o ev92ex.o exch.o exch17.o exrevpbe.o fithi.o fxhpbe.o gbass.o gcor.o gea.o geaex.o getfft.o getff1.o gpoint.o grans.o gtfnam.o hcth.o ifflim.o kcis.o lapw0.o latgen.o multfc.o multsu.o outerr.o pbe1.o poissn.o potfac.o pwxad4.o pwxad5.o qranf.o readstruct.o rean0.o rean1.o rean3.o rean4.o rotate.o rotdef.o setff0.o setff1.o setfft.o setff2.o seval.o sevald.o sevaldd.o sevali.o sevalin.o sicpbe.o sphbes.o spline.o srolyl.o stern.o sumfac.o suml.o th1.o th2.o vpw91.o vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o vxcpw2.o vxi35.o vxi35a.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o ylm.o zfft3d.o -L../SRC_lib /usr/pgi/linux86/lib/libpgf902.a(cnfg.o): In function `__hpfio_scratch_name': cnfg.o(.text+0x2a): the use of `tempnam' is dangerous, better use `mkstemp' Linking: make[1]: Leaving directory `/home/ysz/wien2k/SRC_lapw0' make: *** No rule to make target `complex'. Stop. if [ -f .sequential ]; then \ rm -f .sequential modules.o reallocate.o energy.o gtfnam.o lapw0.o *.mod; \ fi touch .parallel make PARALLEL='-DParallel' lapw0_mpi \ FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' make[1]: Entering directory `/home/ysz/wien2k/SRC_lapw0' pgf90 -Mfreeform -fast -Kieee -DParallel -c modules.F PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) 0 inform, 0 warnings, 1 severes, 0 fatal for begend make[1]: *** [modules.o] Error 1 make[1]: Leaving directory `/home/ysz/wien2k/SRC_lapw0' make: *** [para] Error 2 My computer is really exist MPI!!!!!! I am eager to your help!!!!!!!! -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 08:15:45 +0200 From: Torsten Andersen Subject: Re: [WIEN]: MPI ==== Torsten Andersen submitted the following contribution: ==== Try to specify the path to the MPI library... Torsten. yshzhang@theory.issp.ac.cn wrote: >==== >yshzhang@theory.issp.ac.cn >submitted the following contribution: >==== > >Dear all > >I met a question about parallel using MPI. >The system I used is Linux(dell cluster node0-8).I used pgf90 and pgcc as >the specify compiler. >When it asked "shared Memory achitechtrue?" answer "n" >Remote shell 'rsh' >"do you have MPI and Scalapack ......" y >compiler:pgf90 > > Recommended options for system linuxpgi are: > RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >/usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs >-lmpi > FPOPT(par.comp.options): -Mfreeform -fast -Kieee > MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >_EXEC_ > > Current settings: > RP RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >/usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs >-lmpi > FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee > MP MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >_EXEC_ > > > > >My computer is really exist MPI!!!!!! >I am eager to your help!!!!!!!! > -- Best Regards >YS Zhang > >------------------------------------------------------------------------ > Address: Institute of Solid State Physics > Chinese Academy of Sciences > P.O.BOX 1129,230031 Hefei > P.R~China > Tel: 086-551-5591464(Office) > 086-551-5592837(Home) > Fax: 086-551-5591434 > WWW: http://theory.issp.ac.cn/~yshzhang >------------------------------------------------------------------------ > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 08:54:54 +0200 From: Florent Boucher Subject: Re: [WIEN]: total energy ==== Florent Boucher submitted the following contribution: ==== Dear Pablo, the idea is to erase the scf (and may be broydens files) before you restart the job. It seems to me that this problem appears when you restart the same type of job. However, if you change RKMAX or number of kpoints there is no problem. Please, have a look in the :DIS line. I think the charge density is already converged. This is just the sum of the different contributions to the total energy that is done in a "bad way" by the mixer program. Regards Florent Pablo de la Mora a écrit: > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > Dear Wien Users, > Many times the total energy of the system jumps to a high > (negative) value, most of the time it is not important but in other > times it is. > For example I was doing Ni for testing purposes and when I > restarted the energy now was different. > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653578 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653534 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -6538.210862 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -8286.488860 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766858 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766826 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653536 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653525 > > On other case a supercell of CaCuO2: > :ENE : ********** TOTAL ENERGY IN Ry = -42866.543562 > :ENE : ********** TOTAL ENERGY IN Ry = -42864.264895 > :ENE : ********** TOTAL ENERGY IN Ry = -476714.854134 > :ENE : ********** TOTAL ENERGY IN Ry = -476714.826215 > ....15 iterations > :ENE : ********** TOTAL ENERGY IN Ry = -476831.026046 > :ENE : ********** TOTAL ENERGY IN Ry = -476870.308446 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.676057 > :ENE : ********** TOTAL ENERGY IN Ry = -42871.305960 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.880914 > :ENE : ********** TOTAL ENERGY IN Ry = -42864.285966 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.310026 > Is there something I haven't done (this happens in differents > computing systems!) > Thank you > > Pablo de la Mora > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- -------------------------------------------------------------------------- | Florent BOUCHER | | | Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr | | 2, rue de la Houssinière | Phone: (33) 2 40 37 39 24 | | BP 32229 | Fax: (33) 2 40 37 39 95 | | 44322 NANTES CEDEX 3 (FRANCE) | http://www.cnrs-imn.fr | -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 14:57:38 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: Re: [WIEN]: MPI ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear Prof. > Try to specify the path to the MPI library... Thanks for your replay. The MPI(the file of mpif.h) is set in /usr/lam-6.5.2/include.and I add a path in .cshrc as: set path = ( /usr/lam-6.5.2/include $path .) But it dosen't work.Even I put mpif.h in SRC_lib or modified it in ./siteconfig_lapw Recommended options for system linuxpgi are: RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L /usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs - -lmpi FPOPT(par.comp.options): -Mfreeform -fast -Kieee MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ Current settings: RP RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L /usr/local/BLACS/LIB -L /usr/lam-6.5.2/include -lpblas -lredist -ltools - -lscalapack -lfblacs -lblacs -lmpi FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee MP MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ The same error is occured as: PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) 0 inform, 0 warnings, 1 severes, 0 fatal for begend make[1]: *** [modules.o] Error 1 make[1]: Leaving directory `/home/ysz/wien2k/SRC_lapw0' make: *** [para] Error 2 Copying programs SRC_lapw0/lapw0 cp: cannot create regular file `/home/ysz/wien2k/lapw0': Permission denied done. Compile messages for each SRC_* directory can be found in the file "compile.msg". Compile time errors (if any) were: SRC_lapw0/compile.msg:make[1]: *** [modules.o] Error 1 SRC_lapw0/compile.msg:make: *** [para] Error 2 - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 09:43:40 +0200 From: Torsten Andersen Subject: Re: [WIEN]: MPI ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Chang, the mpif.h is only a header file (from C). What you need to do is probably two-fold. (1) you need to make sure that the mpif.h is in the path the compiler searches for headerfiles in. I am not sure that including it in the "path" is enough. It is typically in a shell environment variable, or added specifically during compilation. Consult the manual of the compiler or the system administrator. (2) You need a - -L/path/to/libmpi.a (or libmpi.so or whatever it is called) type of specification, just like it is done in the section with BLAS and LAPACK, but it appear that you have that, so check if it is correct. If anyone has specific experiences with linux and mpi, please make additional comments... Best regards, Torsten Andersen. yshzhang@theory.issp.ac.cn wrote: >==== >yshzhang@theory.issp.ac.cn >submitted the following contribution: >==== > >Dear Prof. > >>Try to specify the path to the MPI library... >> > >Thanks for your replay. >The MPI(the file of mpif.h) is set in /usr/lam-6.5.2/include.and I add a >path in .cshrc as: > set path = ( /usr/lam-6.5.2/include $path .) > >But it dosen't work.Even I put mpif.h in SRC_lib or modified it in >./siteconfig_lapw > > Recommended options for system linuxpgi are: > RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >/usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs >-lmpi > FPOPT(par.comp.options): -Mfreeform -fast -Kieee > MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >_EXEC_ > > Current settings: > RP RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >/usr/local/BLACS/LIB -L /usr/lam-6.5.2/include -lpblas -lredist -ltools >-lscalapack -lfblacs -lblacs -lmpi > FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee > MP MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >_EXEC_ > >The same error is occured as: >PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) > 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel >PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) > 0 inform, 0 warnings, 1 severes, 0 fatal for begend >make[1]: *** [modules.o] Error 1 >make[1]: Leaving directory `/home/ysz/wien2k/SRC_lapw0' >make: *** [para] Error 2 >Copying programs > SRC_lapw0/lapw0 >cp: cannot create regular file `/home/ysz/wien2k/lapw0': Permission denied > >done. > >Compile messages for each SRC_* directory can be found in the >file "compile.msg". > >Compile time errors (if any) were: >SRC_lapw0/compile.msg:make[1]: *** [modules.o] Error 1 >SRC_lapw0/compile.msg:make: *** [para] Error 2 > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 11:36:18 +0200 From: Peer Kruse Subject: Re: [WIEN]: MPI ==== Peer Kruse submitted the following contribution: ==== 1. Drop the .a after -L/path/to/libmpi it is inserted automatically After -L the path to the Library is set. This is necessary for linking. You are needing the header files. Their path is given by - -I/path_to_headerfiles Best Regards Peer Kruse Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Dear Mr. Chang, > > the mpif.h is only a header file (from C). What you need to do is > probably two-fold. (1) you need to make sure that the mpif.h is in the > path the compiler searches for headerfiles in. I am not sure that > including it in the "path" is enough. It is typically in a shell > environment variable, or added specifically during compilation. > Consult the manual of the compiler or the system administrator. (2) > You need a -L/path/to/libmpi.a (or libmpi.so or whatever it is called) > type of specification, just like it is done in the section with BLAS > and LAPACK, but it appear that you have that, so check if it is correct. > > If anyone has specific experiences with linux and mpi, please make > additional comments... > > Best regards, > Torsten Andersen. > > yshzhang@theory.issp.ac.cn wrote: > >> ==== >> yshzhang@theory.issp.ac.cn >> submitted the following contribution: >> ==== >> >> Dear Prof. >> >>> Try to specify the path to the MPI library... >>> >> >> Thanks for your replay. >> The MPI(the file of mpif.h) is set in /usr/lam-6.5.2/include.and I >> add a path in .cshrc as: >> set path = ( /usr/lam-6.5.2/include $path .) >> >> But it dosen't work.Even I put mpif.h in SRC_lib or modified it in >> ./siteconfig_lapw >> >> Recommended options for system linuxpgi are: >> RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >> /usr/local/BLACS/LIB -lpblas -lredist -ltools -lscalapack -lfblacs >> -lblacs -lmpi >> FPOPT(par.comp.options): -Mfreeform -fast -Kieee >> MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >> _EXEC_ >> >> Current settings: >> RP RP_LIB(SCALAPACK+PBLAS): -L /usr/local/SCALAPACK -L >> /usr/local/BLACS/LIB -L /usr/lam-6.5.2/include -lpblas -lredist >> -ltools -lscalapack -lfblacs -lblacs -lmpi >> FP FPOPT(par.comp.options): -Mfreeform -fast -Kieee >> MP MPIRUN commando : mpirun -np _NP_ -machinefile _HOSTS_ >> _EXEC_ >> >> The same error is occured as: >> PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) >> 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel >> PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) >> 0 inform, 0 warnings, 1 severes, 0 fatal for begend >> make[1]: *** [modules.o] Error 1 >> make[1]: Leaving directory `/home/ysz/wien2k/SRC_lapw0' >> make: *** [para] Error 2 >> Copying programs >> SRC_lapw0/lapw0 >> cp: cannot create regular file `/home/ysz/wien2k/lapw0': Permission >> denied >> >> done. >> >> Compile messages for each SRC_* directory can be found in the >> file "compile.msg". >> >> Compile time errors (if any) were: >> SRC_lapw0/compile.msg:make[1]: *** [modules.o] Error 1 >> SRC_lapw0/compile.msg:make: *** [para] Error 2 >> > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 10:31:31 -0600 From: Pablo de la Mora Subject: Re: [WIEN]: total energy ==== Pablo de la Mora submitted the following contribution: ==== Dear Florent, Thank you for your reply. Many times the total energy jumps when I restart the job but I do a clean and a save in between, this erases the scf and broyden files, but this time the energy jumped in the middle of a run. It surely jumps when the number of iterations reaches 99, then it changes, so a difficult convergency runs into this problem. Long time ago Peter Blaha told me to save before I resatart a run, I have not done it for these cases but I don't think it would work since the iterations number continues to increase. Yours Pablo Florent Boucher wrote: > ==== > Florent Boucher > submitted the following contribution: > ==== > > Dear Pablo, > the idea is to erase the scf (and may be broydens files) before you > restart the job. It seems to me that this problem appears when you > restart the same type of job. > However, if you change RKMAX or number of kpoints there is no problem. > Please, have a look in the :DIS line. I think the charge density is > already converged. This is just the sum of the different contributions > to the total energy that is done in a "bad way" by the mixer program. > Regards > Florent > > Pablo de la Mora a écrit: > >> ==== >> Pablo de la Mora >> submitted the following contribution: >> ==== >> >> Dear Wien Users, >> Many times the total energy of the system jumps to a high >> (negative) value, most of the time it is not important but in other >> times it is. >> For example I was doing Ni for testing purposes and when I >> restarted the energy now was different. >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653578 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653534 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -6538.210862 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -8286.488860 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766858 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766826 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653536 >> aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653525 >> >> On other case a supercell of CaCuO2: >> :ENE : ********** TOTAL ENERGY IN Ry = -42866.543562 >> :ENE : ********** TOTAL ENERGY IN Ry = -42864.264895 >> :ENE : ********** TOTAL ENERGY IN Ry = -476714.854134 >> :ENE : ********** TOTAL ENERGY IN Ry = -476714.826215 >> ....15 iterations >> :ENE : ********** TOTAL ENERGY IN Ry = -476831.026046 >> :ENE : ********** TOTAL ENERGY IN Ry = -476870.308446 >> :ENE : ********** TOTAL ENERGY IN Ry = -42863.676057 >> :ENE : ********** TOTAL ENERGY IN Ry = -42871.305960 >> :ENE : ********** TOTAL ENERGY IN Ry = -42863.880914 >> :ENE : ********** TOTAL ENERGY IN Ry = -42864.285966 >> :ENE : ********** TOTAL ENERGY IN Ry = -42863.310026 >> Is there something I haven't done (this happens in differents >> computing systems!) >> Thank you >> >> Pablo de la Mora >> >> ==== >> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> To (un)subscribe send mail to >> majordomo@zeus.theochem.tuwien.ac.at >> ==== >> > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 17:43:28 +0200 From: Torsten Andersen Subject: Re: [WIEN]: total energy ==== Torsten Andersen submitted the following contribution: ==== Dear Pablo, I experienced this a while back. Reducing the compilation optimisation was the solution in my case. I do not have a clear picture of what goes wrong, but it could have to do with sloppy rounding of numbers at higher (agressive) optimisation levels. In cases where an experimentally stable phase exists, 99 iterations are usually way too many, unless you have a very big system. Best regards, Torsten Andersen. Pablo de la Mora wrote: > ==== > Pablo de la Mora > submitted the following contribution: > ==== > > Dear Wien Users, > Many times the total energy of the system jumps to a high > (negative) value, most of the time it is not important but in other > times it is. > For example I was doing Ni for testing purposes and when I > restarted the energy now was different. > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653578 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653534 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -6538.210862 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -8286.488860 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766858 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -10034.766826 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653536 > aa.scf::ENE : ********** TOTAL ENERGY IN Ry = -3041.653525 > > On other case a supercell of CaCuO2: > :ENE : ********** TOTAL ENERGY IN Ry = -42866.543562 > :ENE : ********** TOTAL ENERGY IN Ry = -42864.264895 > :ENE : ********** TOTAL ENERGY IN Ry = -476714.854134 > :ENE : ********** TOTAL ENERGY IN Ry = -476714.826215 > ....15 iterations > :ENE : ********** TOTAL ENERGY IN Ry = -476831.026046 > :ENE : ********** TOTAL ENERGY IN Ry = -476870.308446 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.676057 > :ENE : ********** TOTAL ENERGY IN Ry = -42871.305960 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.880914 > :ENE : ********** TOTAL ENERGY IN Ry = -42864.285966 > :ENE : ********** TOTAL ENERGY IN Ry = -42863.310026 > Is there something I haven't done (this happens in differents > computing systems!) > Thank you > > Pablo de la Mora > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 17:40:36 +0100 From: "Xiangyuan Cui" Subject: Re: [WIEN]: total energy ==== "Xiangyuan Cui" submitted the following contribution: ==== Hi Pablo :) i think it is not a serious problom if i understand it correctly. when this behaviour occurs (more than 99 iterations) , i just change the case.scf file into another name. or delete some lines in the *.scf, then the convergence will go back to the normal behaviour after two more iterations. yours, xiangyuan > Dear Florent, > Thank you for your reply. Many times the total energy jumps when I > restart the job but I do a clean and a save in between, this erases the > scf and broyden files, but this time the energy jumped in the middle of > a run. > It surely jumps when the number of iterations reaches 99, then it > changes, so a difficult convergency runs into this problem. Long time > ago Peter Blaha told me to save before I resatart a run, I have not done > it for these cases but I don't think it would work since the iterations > number continues to increase. > Yours > > Pablo - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.389 / Virus Database: 220 - Release Date: 16/09/2002 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 18:39:54 -0600 From: Pablo de la Mora Subject: Re: [WIEN]: problems with parallel execution ==== Pablo de la Mora submitted the following contribution: ==== - --------------030909060102080607050106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Dr. Blaha, I did not respond earlier since the error was not reproduced immediatlely and I was busy. >The problems you have given below may have several reasons and one needs much >more info and tests. > >a) Does it never crash with the two 1 GHz machines ? > *** So far it works fine. >b) Does it always or sometimes crash when including the 500 MHz processors ? > *** Most all the time but now always >c) Only this case crashes or all/some others too ? > *** Many other cases crash >Common directory NFS mounted ? WIEN2k runs everywhere ? > *** Yes >can you connect to all machines without password ? > *** Yes >Slow network connection ? (In particular when the error occurs only >occasional) > *** I don't know but the cluster has a switch, so I presume that the connection is fast and good >Did lapw1 work in parallel ? > *** Yes >Do you see all vector_* fileswith proper (new) date ? > *** Yes >What happens when you run x lapw2 -p interactively ? > *** It crashes - ---------------------------------- end of nohup.out LAPW1 END 60.90user 1.16system 2:03.40elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (389major+107814minor)pagefaults 0swaps PGFIO-F-252/list-directed read/unit=29/operation attempted after end of file. File name = dos.energydn_19 formatted, sequential access record = 210 In source file fermi.f, at line number 63 cp: .in.tmp: No such file or directory rm: cannot remove `.in.tmp': No such file or directory rm: cannot remove `.in.tmp1': No such file or directory ************************************************** On other issues: First I still like 'Wien in the Box', I find it very friendly and using the navigator (I use netscape) I find it clumsy in the Struct Generator. Unfortunately it is not being mantained and sometimes it gives errors when the struct generator is used more than once for the same case (for correcting a coordinate or changeing the space group). Second Running lstart one of the important parameters is the charge that leaks outside the muffin tin sphere. case.outputst gives: TOTAL CORE-CHARGE: 2.000000000000460 TOTAL CORE-CHARGE INSIDE SPHERE: 1.999931688322383 I suggest that the second line should be changed to TOTAL CORE-CHARGE OUTSIDE SPHERE: That is, lstart.f should have: - ------------- 9120 continue CTEST=1.d0 CALL SOMM (DR,Dp,DQ,DPAS,CTEST,0,NP) WRITE(6,*) 'TOTAL CORE-CHARGE: ',CTEST CALL SOMM (DR,Dp,DQ,DPAS,CTEST1,0,NP0) WRITE(6,*) 'TOTAL CORE-CHARGE OUTSIDE SPHERE: ',CTEST1-CTEST <=== if(ctest-ctest1.gt.0.01) write(6,*) 'WARNING:',ctest-ctest1, & ' CORE electrons leak out of MT-sphere !!!!' - ------------------- CTEST1-CTEST has to be less than 0.001 (I think). In this way it is clearer. Thanks Pablo de la Mora >Regards > >>> I am having problems with parallel execution. I am doing a >>>supercell for doping, it worked fine with a supercell with 4 cells, >>>but with 2 cells it crashed. >>> >>>------------ End of the 'dayfile' >>>1.230u 0.930s 3:02.72 1.1% 0+0k 0+0io 60807pf+0w >>> >>>> lapw2 -up -p (02:06:41) running LAPW2 in parallel mode >>>> >>>** LAPW2 crashed! >>>0.080u 0.070s 0:00.15 100.0% 0+0k 0+0io 4056pf+0w >>> This has happened before in other cases. Sometimes the same case >>>crashes and sometimes it does not! >>> The cluster has 6 machines >>> two with two 1GHz intel processors each >>> four with one 500MHz intel processor >>> Thanks >>> >>I want to add that I did a calculation with the two dual (two 1GHz >>processors per machine; hydra and nodo1) the calculation did not crash: >> >>-------------------- .machines file >>2:hydra >>2:hydra >>2.nodo1 >>2:nodo1 >>---------------------- >> >>but with the non homogeneous cluster (including the 500MHz processors; >>nodo3,...) it did crash: >> >>-------------------- .machines file >>2:hydra >>2:hydra >>2.nodo1 >>2:nodo1 >>1:nodo3 >>1:nodo4 >>1:nodo5 >> > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > - --------------030909060102080607050106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Dr. Blaha,
    I did not respond earlier since the error was not reproduced immediatlely and I was busy.
The problems you have given below may have several reasons and one needs much
more info and tests.

a) Does it never crash with the two 1 GHz machines ?
***    So far it works fine.
b) Does it always or sometimes crash when including the 500 MHz processors ?
***    Most all the time but now always
c) Only this case crashes or all/some others too ?
***    Many other cases crash
Common directory NFS mounted ? WIEN2k runs everywhere ?
***    Yes
can you connect to all machines without password ?
***    Yes
Slow network connection ? (In particular when the error occurs only
occasional)
***    I don't know but the cluster has a switch, so I presume that the connection is fast and good
Did lapw1 work in parallel ?
***    Yes
Do you see all vector_* fileswith proper (new) date ?
***    Yes
What happens when you run  x lapw2 -p interactively ?
***    It crashes

- ---------------------------------- end of nohup.out
 LAPW1 END
60.90user 1.16system 2:03.40elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (389major+107814minor)pagefaults 0swaps
PGFIO-F-252/list-directed read/unit=29/operation attempted after end of file.
 File name = dos.energydn_19    formatted, sequential access   record = 210
 In source file fermi.f, at line number 63
cp: .in.tmp: No such file or directory
rm: cannot remove `.in.tmp': No such file or directory
rm: cannot remove `.in.tmp1': No such file or directory
**************************************************
    On other issues:
First
    I still like 'Wien in the Box', I find it very friendly and using the navigator (I use netscape) I find it clumsy in the Struct Generator.
    Unfortunately it is not being mantained and sometimes it gives errors when the struct generator is used more than once for the same case (for correcting a coordinate or changeing the space group).

Second
    Running lstart one of the important parameters is the charge that leaks outside the muffin tin sphere. case.outputst gives:

 TOTAL CORE-CHARGE:                  2.000000000000460    
 TOTAL CORE-CHARGE INSIDE SPHERE:    1.999931688322383    

I suggest that the second line should be changed to

TOTAL CORE-CHARGE OUTSIDE SPHERE:

That is, lstart.f should have:
- -------------
 9120 continue
      CTEST=1.d0
      CALL SOMM (DR,Dp,DQ,DPAS,CTEST,0,NP)
      WRITE(6,*) 'TOTAL CORE-CHARGE:               ',CTEST
      CALL SOMM (DR,Dp,DQ,DPAS,CTEST1,0,NP0)
      WRITE(6,*) 'TOTAL CORE-CHARGE OUTSIDE SPHERE: ',CTEST1-CTEST <===
      if(ctest-ctest1.gt.0.01) write(6,*) 'WARNING:',ctest-ctest1, &
        ' CORE electrons leak out of MT-sphere !!!!'
- -------------------
CTEST1-CTEST has to be less than 0.001 (I think). In this way it is clearer.

    Thanks
            Pablo de la Mora
Regards

   I am having problems with parallel execution. I am doing a
supercell for doping, it worked fine with a supercell with 4 cells,
but with 2 cells it crashed.

------------ End of the 'dayfile'
1.230u 0.930s 3:02.72 1.1%    0+0k 0+0io 60807pf+0w
  lapw2 -up -p    (02:06:41) running LAPW2 in parallel mode
**  LAPW2 crashed!
0.080u 0.070s 0:00.15 100.0%    0+0k 0+0io 4056pf+0w
   This has happened before in other cases. Sometimes the same case
crashes and sometimes it does not!
   The cluster has 6 machines
   two with two 1GHz intel processors each
   four with one 500MHz  intel processor
   Thanks
I want to add that I did a calculation with the two dual (two 1GHz
processors per machine; hydra and nodo1) the calculation did not crash:

-------------------- .machines file
2:hydra
2:hydra
2.nodo1
2:nodo1
----------------------

but with the non homogeneous cluster (including the 500MHz processors;
nodo3,...) it did crash:

-------------------- .machines file
2:hydra
2:hydra
2.nodo1
2:nodo1
1:nodo3
1:nodo4
1:nodo5

                                      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@theochem.tuwien.ac.at    WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====



- --------------030909060102080607050106-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 18 Oct 2002 22:50:19 -0700 (PDT) From: hamid salehi Subject: [WIEN]: OPtimize ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started optimize(v,c/a)and in ShowSTDOUT got this message(PGFIO-F-217/Formatted read/unit=20/attempt to read past end of file. ERROR Status in Case_Vol_ -10). what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 22 Oct 2002 10:23:45 +0200 From: Thomas Claesson Subject: [WIEN]: Problems with save/restore_lapw ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I have a question regarding saving and restoring a calulation. Working on a case I saved it in a new directory (save_lapw -f -d ). Then I made some changes and then I wanted to restore my previous calculation (restore_lapw -f -d ). The save and restore scripts seem to be workning properly (i.e. they do what they should do), but there is one thing I don't understand. After restore I immidiately calculated the band structure, but it had changed compared to the calculation I saved before. How is this possible? I also tried to run the SCF cycle to self consistency again and then calculated the band structure again, but it still didn't look like the one I saved before. It is not just the band structure that changes, also other quantities like Fermi energi and so on change as well. So I wonder, is there anything I have missed to do? Why can't I get back to my previous calculation? Are there any more files I should delete? Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #39 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #40 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Tuesday, October 29 2002 Volume 2002 : Number 040 ---------------------------------------------------------------------- Date: Tue, 22 Oct 2002 15:40:55 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Problems with save/restore_lapw ==== "Saeid Jalali" submitted the following contribution: ==== > I have a question regarding saving and restoring a calulation. Working > on a case I saved it in a new directory (save_lapw -f -d ). Then I > made some changes and then I wanted to restore my previous calculation > (restore_lapw -f -d ). The save and restore scripts seem to be > workning properly (i.e. they do what they should do), but there is one > thing I don't understand. After restore I immidiately calculated the > band structure, but it had changed compared to the calculation I saved > before. How is this possible? I also tried to run the SCF cycle to self > consistency again and then calculated the band structure again, but it > still didn't look like the one I saved before. It is not just the band > structure that changes, also other quantities like Fermi energi and so > on change as well. The case.scf is also saved and restored employing new scheme of these two scripts. So there is no possibility to find from one case.scf file different Fermi energies or other quantities. This shows how one can find what is going wrong checking the saved case.scf file in the specified directory right after saving and case.scf file in the work directory right after restoring: These two case.scf files should be identical, as they are! Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 22 Oct 2002 14:43:41 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Problems with save/restore_lapw ==== Peter Blaha submitted the following contribution: ==== > I have a question regarding saving and restoring a calulation. Working > on a case I saved it in a new directory (save_lapw -f -d ). Then I > made some changes and then I wanted to restore my previous calculation > (restore_lapw -f -d ). The save and restore scripts seem to be > workning properly (i.e. they do what they should do), but there is one > thing I don't understand. After restore I immidiately calculated the > band structure, but it had changed compared to the calculation I saved > before. How is this possible? This is clear! What you restored was the charge density (clmsum) (and all input files + case.struct). So you must first run x lapw0 to restore the old potential files (case.vsp, case.vns) and only then can rerun a bandstructure (x lapw1,.....) > I also tried to run the SCF cycle to self > consistency again and then calculated the band structure again, but it > still didn't look like the one I saved before. It is not just the band > structure that changes, also other quantities like Fermi energi and so > on change as well. Then there are 3 choices: a) You did not run to selfconsistency previously, therefore new iterations change the potential,bands, ef,... b) You made a mistake in saving/restoring ? (file permissions ?) c) Are you sure you continued to run scf with proper inputs! You did not change case.in1 for bandstructure,... ??? (Eventually you have even "saved" those modified standard-inputs. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 22 Oct 2002 21:18:03 -0400 From: xn22 Subject: [WIEN]: Questions about H atom ==== xn22 submitted the following contribution: ==== Hi, Dear WIEN users, I had some problems for calculating H atom involved systems: 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART and about 0 Ry with both GGA (PBE and PW91). This looks like very unphysics since we knew the H 1s level should be around 1 Ry. I tried one molecular program such as GAMESS for H atom. I got the H 1s level is close to 1 Ry. Whether does the WIEN (or generally all LDA ab initio programs) work for H atom? 2. I tried run wien with H atom including system. Two problems in the running and results. The first one is that the R_MTxK_max is too small. About 40APW/atom . I don't think the results are converged with respect to the APW since I tested isolated H atom by supercell. It asked about 500 APW/H atom for converged results. I tried to increase the R_MTxK_max, but there were lots of ghost bands. Could you let me know any parameter I can adjust so that I can increase R_MTxK_max without ghost bands? The second problem I cannot find any H s-character charge in energy level in identify the H atom contribution for the systems. Perhaps my SFC is totally wrong due to small R_MTxK_max or the wrong initial charge density (since the H 1s level is wrong for atom). In summary, my questions are: 1. Whether Wien can give right H atom 1s energy level? 2. How to overcome the too small R_MTxK_max in avoiding the ghost bands? 3. Whether we can still see some H s-character charge in certain energy levels even most of the charge are in interstitial? Please also cc to this email if you could answer my questions to WIEN mail-list since I am not sure whether I already subscribe to this list. Thanks in Advance. Best regards. Xiliang Nie Drexel University ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 10:08:21 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Questions about H atom ==== "Saeid Jalali" submitted the following contribution: ==== > 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART > and about 0 Ry with both GGA (PBE and PW91). This cannot be true!!! Below you would see the energy of 1s level in the scheme of GGA96 parametrization for the exchange-correalation, which is indeed the total enery too for this H case: OCCUPANCY ENERGY(RYD) (R4) (R2) (R) (R-1) (R-3) 1S 0.900 -5.5343654E-01 2.8859964E+01 3.2701173E+00 1.5496451E+00 9.8868262E-01 1S 0.100 -2.9298928E-01 7.6764833E+01 5.1154057E+00 1.9089852E+00 8.3795718E-01 TOTAL ENERGY (RYD): -0.966505 One sees that 5.5343654E-01-2.9298928E-01=-0.966505Ry is close to what is expected for the ground level of H, -1Ry. Your Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 09:34:21 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: Questions about H atom ==== "Kevin Jorissen" submitted the following contribution: ==== isn't -5,534 - 2,930 = -8,464? kevin. - ----- Original Message ----- From: "Saeid Jalali" To: Sent: Wednesday, October 23, 2002 8:38 AM Subject: Re: [WIEN]: Questions about H atom > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART > > and about 0 Ry with both GGA (PBE and PW91). > This cannot be true!!! Below you would see the energy of 1s level in the > scheme of GGA96 parametrization for the exchange-correalation, which is > indeed the total enery too for this H case: > > OCCUPANCY ENERGY(RYD) (R4) (R2) > (R) (R-1) (R-3) > > 1S 0.900 -5.5343654E-01 2.8859964E+01 3.2701173E+00 > 1.5496451E+00 9.8868262E-01 > 1S 0.100 -2.9298928E-01 7.6764833E+01 5.1154057E+00 > 1.9089852E+00 8.3795718E-01 > > TOTAL ENERGY (RYD): -0.966505 > One sees that 5.5343654E-01-2.9298928E-01=-0.966505Ry is close to what is > expected for the ground level of H, -1Ry. > > Your > Saeid. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 16:07:59 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Hi, I get following lines in file .outputs DETERMINATION OF POINTGROUP FOR ALL POSITIONS 2020 C : 16 Atoms, Index 1 to 16 C : 16 Atoms, Index 17 to 32 C : 16 Atoms, Index 33 to 48 C : 16 Atoms, Index 49 to 64 C : 208 Atoms, Index 65 to 272 C : 16 Atoms, Index 273 to 288 C : 16 Atoms, Index 289 to 304 C : 16 Atoms, Index 305 to 320 number of atoms: 320 ATOM: -1 no pointgroup found, isym = 0 lm: ============================================== ATOM: -2 no pointgroup found, isym = 0 lm: ============================================== ATOM: -3 no pointgroup found, isym = 0 lm: ============================================== ATOM: -4 no pointgroup found, isym = 0 lm: ============================================== ATOM: -5 no pointgroup found, isym = 0 lm: ============================================== ATOM: -6 no pointgroup found, isym = 0 lm: ============================================== ATOM: -7 no pointgroup found, isym = 0 lm: ============================================== ATOM: -8 no pointgroup found, isym = 0 lm: ============================================== Then, Is it something wrong in my structure file? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 10:38:40 +0200 From: "Kevin Jorissen" Subject: Re: [WIEN]: Question ==== "Kevin Jorissen" submitted the following contribution: ==== Maybe. Why not send it, so someone may have a look at it? kind regards, Kevin Jorissen University of Antwerp, Belgium - ----- Original Message ----- From: "Ma Chi Chiu" To: Sent: Wednesday, October 23, 2002 10:07 AM Subject: [WIEN]: Question > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Hi, > > I get following lines in file .outputs > > DETERMINATION OF POINTGROUP FOR ALL POSITIONS > 2020 > C : 16 Atoms, Index 1 to 16 > C : 16 Atoms, Index 17 to 32 > C : 16 Atoms, Index 33 to 48 > C : 16 Atoms, Index 49 to 64 > C : 208 Atoms, Index 65 to 272 > C : 16 Atoms, Index 273 to 288 > C : 16 Atoms, Index 289 to 304 > C : 16 Atoms, Index 305 to 320 > number of atoms: 320 > > ATOM: -1 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -2 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -3 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -4 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -5 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -6 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -7 > no pointgroup found, isym = 0 > lm: > ============================================== > > ATOM: -8 > no pointgroup found, isym = 0 > lm: > ============================================== > > Then, Is it something wrong in my structure file? > > Thank you very much > > Martin > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 11:16:41 +0200 (MESZ) From: "A. Postnikov" Subject: Re: [WIEN]: Questions about H atom ==== "A. Postnikov" submitted the following contribution: ==== Dear Xiliang, hopefully you calculate your H atom in spin-polarized regime? Recently there was already some discussion about H atom in a box, in wien-digest.2002-16 wien-digest.2002-17 - - check whether this helps. Good luck, Andrei Postnikov On Tue, 22 Oct 2002, xn22 wrote: > ==== > xn22 > submitted the following contribution: > ==== > > Hi, Dear WIEN users, > > I had some problems for calculating H atom involved systems: > > 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART > and about 0 Ry with both GGA (PBE and PW91). This looks like very unphysics > since we knew the H 1s level should be around 1 Ry. I tried one molecular > program such as GAMESS for H atom. I got the H 1s level is close to 1 Ry. > Whether does the WIEN (or generally all LDA ab initio programs) work for > H atom? > > 2. I tried run wien with H atom including system. Two problems in the running > and results. The first one is that the R_MTxK_max is too small. About > 40APW/atom . I don't think the results are converged with respect to the APW > since I tested > isolated H atom by supercell. It asked about 500 APW/H atom for converged > results. I tried to increase the R_MTxK_max, but there were lots of ghost > bands. Could you let me know any parameter I can adjust so that I can increase > R_MTxK_max without ghost bands? The second problem I cannot find any H > s-character charge in energy level in identify the H atom contribution for the > systems. Perhaps my SFC is totally wrong due to small R_MTxK_max or the wrong > initial charge density (since the H 1s level is wrong for atom). > > In summary, my questions are: > > 1. Whether Wien can give right H atom 1s energy level? > > 2. How to overcome the too small R_MTxK_max in avoiding the ghost bands? > > 3. Whether we can still see some H s-character charge in certain energy levels > even most of the charge are in interstitial? > > Please also cc to this email if you could answer my questions to WIEN > mail-list > since I am not sure whether I already subscribe to this list. Thanks in > Advance. > > Best regards. > > Xiliang Nie > > Drexel University > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 12:51:55 +0200 (MEST) From: Peter Blaha Subject: Re: [WIEN]: Questions about H atom ==== Peter Blaha submitted the following contribution: ==== > I had some problems for calculating H atom involved systems: > > 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART > and about 0 Ry with both GGA (PBE and PW91). This looks like very unphysics > since we knew the H 1s level should be around 1 Ry. I tried one molecular > program such as GAMESS for H atom. I got the H 1s level is close to 1 Ry. > Whether does the WIEN (or generally all LDA ab initio programs) work for > H atom? There was already quite some discussion about H in previous mails. Please check the digest. In GGA you cannot set an occupation of 1 and 0 for spin-up/dn respectively, since the program does not know what to do with zero density. In LDA you can do so. Nevertheless, you will never get an eigenvalue of -1 Ry. This resembles the well known fact, that DFT-eigenvalues are not observable exitation energies (but in principle just lagrange parameters) and that DFT is a theory of the groundstate. > 1. Whether Wien can give right H atom 1s energy level? Wien gives (for LDA) the "correct" H 1s energy level (which is far from experiment). > 2. How to overcome the too small R_MTxK_max in avoiding the ghost bands? I'm not sure what you are doing exactly. 1st, for pure H systems, don't do GGA. Second, it is perfectly ok that the number of PW changes with the unitcell size and is different for "bulk-H" or H in a supercell. > 3. Whether we can still see some H s-character charge in certain energy levels > even most of the charge are in interstitial? Yes you should see some H s-character (not 1 electron, but only a fraction. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 14:42:20 +0200 From: Thomas Claesson Subject: [WIEN]: Delete case.broydX files? ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! In the usersguide, section 7.9 about Mixer, you can read the following: "At the outset of a new calculation (for any changed computational parameter such as k-mesh, ma-trix size, lattice constant etc.), any existing case.broydX files must be deleted." Here I just wonder etc. includes, i.e. in which cases other than those explicitly mentioned above, do I have to delete the case.broydX files? Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 21:03:01 -0400 From: xn22 Subject: RE: [WIEN]: Questions about H atom ==== xn22 submitted the following contribution: ==== Dear Saeid and WIEN users, Thanks for your replying. But I could not understand why you combine two energy levels (I assumed they are spin up and spin down) to form the energy level of 1s for H atom in your email. Actually from the data you gave in your email. The lowest 1s level is about 0.5 Ry (spin up) that it is close to my calculation. My question is that whether we could calculate another lowest 1s level that is close to 1 Ry? By the way what's the reason you split 1 electron into 0.9 for spin-up and 0.1 for spin-down in your case.inst file for H atom? Also I am very strange you got those energy levels by GGA96 ( I got about 0 Ry). Is this the reason you put some electron in spin-down as Peter said the GGA cann't work for for 0 of spin-down charge? By the way I know someone did ice calculations from digest. Could you talk about your treatment for H2O molecular in your calculations if you read my email. Actually I am interested to do some water molecular supercell calculations. It is very much appreciated if anybody can send some suggestions and comments. I have impression that somebody published paper about water molecular on surface by ab initio but cann't find it. Anybody can give info about this paper? Best regards. Xiliang Nie Drexel University >===== Original Message From Saeid Jalali ===== >==== >"Saeid Jalali" >submitted the following contribution: >==== > >> 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART >> and about 0 Ry with both GGA (PBE and PW91). >This cannot be true!!! Below you would see the energy of 1s level in the >scheme of GGA96 parametrization for the exchange-correalation, which is >indeed the total enery too for this H case: > > OCCUPANCY ENERGY(RYD) (R4) (R2) >(R) (R-1) (R-3) > > 1S 0.900 -5.5343654E-01 2.8859964E+01 3.2701173E+00 >1.5496451E+00 9.8868262E-01 > 1S 0.100 -2.9298928E-01 7.6764833E+01 5.1154057E+00 >1.9089852E+00 8.3795718E-01 > > TOTAL ENERGY (RYD): -0.966505 >One sees that 5.5343654E-01-2.9298928E-01=-0.966505Ry is close to what is >expected for the ground level of H, -1Ry. > > Your > Saeid. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 21:10:39 -0400 From: xn22 Subject: RE: [WIEN]: Questions about H atom ==== xn22 submitted the following contribution: ==== Dear Saeid and WIEN users, Thanks for your replying. But I could not understand why you combine two energy levels (I assumed they are spin up and spin down) to form the energy level of 1s for H atom in your email. Actually from the data you gave in your email. The lowest 1s level is about 0.5 Ry (spin up) that it is close to my calculation. My question is that whether we could calculate another lowest 1s level that is close to 1 Ry? By the way what's the reason you split 1 electron into 0.9 for spin-up and 0.1 for spin-down in your case.inst file for H atom? Also I am very strange you got those energy levels by GGA96 ( I got about 0 Ry). Is this the reason you put some electron in spin-down as Peter said the GGA cann't work for for 0 of spin-down charge? By the way I know someone did ice calculations from digest. Could you talk about your treatment for H2O molecular in your calculations if you read my email. Actually I am interested to do some water molecular supercell calculations. It is very much appreciated if anybody can send some suggestions and comments. I have impression that somebody published paper about water molecular on surface by ab initio but cann't find it. Anybody can give info about this paper? Best regards. Xiliang Nie Drexel University >===== Original Message From Saeid Jalali ===== >==== >"Saeid Jalali" >submitted the following contribution: >==== > >> 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART >> and about 0 Ry with both GGA (PBE and PW91). >This cannot be true!!! Below you would see the energy of 1s level in the >scheme of GGA96 parametrization for the exchange-correalation, which is >indeed the total enery too for this H case: > > OCCUPANCY ENERGY(RYD) (R4) (R2) >(R) (R-1) (R-3) > > 1S 0.900 -5.5343654E-01 2.8859964E+01 3.2701173E+00 >1.5496451E+00 9.8868262E-01 > 1S 0.100 -2.9298928E-01 7.6764833E+01 5.1154057E+00 >1.9089852E+00 8.3795718E-01 > > TOTAL ENERGY (RYD): -0.966505 >One sees that 5.5343654E-01-2.9298928E-01=-0.966505Ry is close to what is >expected for the ground level of H, -1Ry. > > Your > Saeid. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 21:58:06 -0400 From: xn22 Subject: RE: [WIEN]: Questions about H atom ==== xn22 submitted the following contribution: ==== Dear Saeid and WIEN users, Thanks for your replying. But I could not understand why you combine two energy levels (I assumed they are spin up and spin down) to form the energy level of 1s for H atom in your email. Actually from the data you gave in your email. The lowest 1s level is about 0.5 Ry (spin up) that it is close to my calculation. My question is that whether we could calculate another lowest 1s level that is close to 1 Ry? By the way what's the reason you split 1 electron into 0.9 for spin-up and 0.1 for spin-down in your case.inst file for H atom? Also I am very strange you got those energy levels by GGA96 ( I got about 0 Ry). Is this the reason you put some electron in spin-down as Peter said the GGA cann't work for for 0 of spin-down charge? By the way I know someone did ice calculations from digest. Could you talk about your treatment for H2O molecular in your calculations if you read my email. Actually I am interested to do some water molecular supercell calculations. It is very much appreciated if anybody can send some suggestions and comments. I have impression that somebody published paper about water molecular on surface by ab initio but cann't find it. Anybody can give info about this paper? Best regards. Xiliang Nie Drexel University >===== Original Message From Saeid Jalali ===== >==== >"Saeid Jalali" >submitted the following contribution: >==== > >> 1. The 1s energy level is about -0.5 Ry with LDA for H atom from LSTART >> and about 0 Ry with both GGA (PBE and PW91). >This cannot be true!!! Below you would see the energy of 1s level in the >scheme of GGA96 parametrization for the exchange-correalation, which is >indeed the total enery too for this H case: > > OCCUPANCY ENERGY(RYD) (R4) (R2) >(R) (R-1) (R-3) > > 1S 0.900 -5.5343654E-01 2.8859964E+01 3.2701173E+00 >1.5496451E+00 9.8868262E-01 > 1S 0.100 -2.9298928E-01 7.6764833E+01 5.1154057E+00 >1.9089852E+00 8.3795718E-01 > > TOTAL ENERGY (RYD): -0.966505 >One sees that 5.5343654E-01-2.9298928E-01=-0.966505Ry is close to what is >expected for the ground level of H, -1Ry. > > Your > Saeid. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 23 Oct 2002 22:50:02 -0700 (PDT) From: hamid salehi Subject: [WIEN]: Xdstart ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started Initializ cale for large unite cel(in Pentium Four by RAM 768M ) and got this message(X dstart:Not enough memory). what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 24 Oct 2002 09:31:32 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Questions about H atom ==== "Saeid Jalali" submitted the following contribution: ==== > By the way I know someone did ice calculations from digest. Could you > talk about your treatment for H2O molecular in your calculations if you > read my email. Actually I am interested to do some water molecular supercell > calculations. It is very much appreciated if anybody can send some > suggestions and comments. Ice in its Fcc phase with the space group of 227_Fd-3m is constructed with 2 molecules of H2O in each site. One would use the following structure checking the lattice parameter surfacing literatures: Title F LATTICE,NONEQUIV. ATOMS: 2227_Fd-3m MODE OF CALC=RELA unit=bohr 22.676280 22.676280 22.676280 90.000000 90.000000 90.000000 ATOM= 1: X=0.12500000 Y=0.12500000 Z=0.12500000 MULT= 2 ISPLIT= 2 1: X=0.87500000 Y=0.87500000 Z=0.87500000 O NPT= 781 R0=0.00010000 RMT= 1.0000 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 4 ISPLIT= 4 -2: X=0.00000000 Y=0.25000000 Z=0.25000000 -2: X=0.25000000 Y=0.25000000 Z=0.00000000 -2: X=0.25000000 Y=0.00000000 Z=0.25000000 H NPT= 781 R0=0.00010000 RMT= 1.0000 Z: 1.0 LOCAL ROT MATRIX: 0.4082483-0.7071068 0.5773503 0.4082483 0.7071068 0.5773503 -0.8164966 0.0000000 0.5773503 48 NUMBER OF SYMMETRY OPERATIONS > Thanks for your replying. But I could not understand why you > combine two energy levels (I assumed they are spin up and spin down) > to form the energy level of 1s for H atom in your email. Yes, you are right. > Actually > from the data you gave in your email. The lowest 1s level is about > 0.5 Ry (spin up) that it is close to my calculation. That's okay. > My question > is that whether we could calculate another lowest 1s level that > is close to 1 Ry? Yes, but we don't need it, as lstart is an atomic program (a modified version of relativistic Dirack-Fick) to assess an initial case.clmsum for going through SCF procedure in the bulk. > By the way what's the reason you split 1 electron > into 0.9 for spin-up and 0.1 for spin-down in your case.inst file > for H atom? There is a technical and not physical restriction to select 0 and 1 occupations for spin down and up in H atom. One also finds that there is such a restriction for Yb atom to make a divalent configuration. There is a direct relationship between relativistic aspect and spin. Spin inherently introduces or defines itself once one writes Dirack equation, which is not the case once one writes Schrödinger equation. In the later case we should manually introduce or define spin from our physical knowledge. > Also I am very strange you got those energy levels by > GGA96 ( I got about 0 Ry). Me too! You would send us your case.struct, case.inst, and case.outputst. > Is this the reason you put some electron > in spin-down as Peter said the GGA cann't work for for 0 of spin-down > charge? Please notice that I did not change case.inst: I have just used the default case.inst. With 1 and 0 occupation numbers I have found: TOTAL ENERGY (RYD): -0.487945 which cannot be the ground level of H, and this is why Peter said that. > isn't -5,534 - 2,930 = -8,464? Yes, it is!!! With my roughly and fast choices of RMT and S.E, we have: TOTAL CHARGE FOR SPIN 1: 0.9000000000000002 TOTAL CHARGE FOR SPIN 1 INSIDE SPHERE: 0.6689781200590000 TOTAL CHARGE FOR SPIN 2: 0.1000000000000001 TOTAL CHARGE FOR SPIN 2 INSIDE SPHERE: 6.1910993220382204E-002 So, there are 0.9-0.668=0.232 up-electrons and 0.1-6.191E-002=0.0381 dn-electrons in the region. It appears that the energy of -0.966505-(-0.8464)=-0.12Ry is a contribution of interstitial electrons to tot-ENE. But it does not, as with a very large choice of RMT (!!!), one can confine almost all the electrons into the sphere. In this case we have: OCCUPANCY ENERGY(RYD) (R4) (R2) (R) (R-1) (R-3) 1S 0.900 -5.5343655E-01 2.8859969E+01 3.2701173E+00 1.5496451E+00 9.8868263E-01 1S 0.100 -2.9298928E-01 7.6766219E+01 5.1154126E+00 1.9089856E+00 8.3795713E-01 TOTAL CHARGE FOR SPIN 1: 0.9000000000000005 TOTAL CHARGE FOR SPIN 1 INSIDE SPHERE: 0.8988648475727096 TOTAL CHARGE FOR SPIN 2: 9.9999999999999964E-002 TOTAL CHARGE FOR SPIN 2 INSIDE SPHERE: 9.9137532098954502E-002 TOTAL ENERGY (RYD): -0.966505 SUM OF EI:-5.2739182E-01 NUC:-1.9472202E+00 COUL:-7.5003038E-01 V-XC SPIN 1:-6.8721928E-01 E-XC SPIN 1:-5.4051577E-01 V-XC SPIN 2:-4.1960715E-02 E-XC SPIN 2:-2.9182609E-02 So the difference cannot be due to the interstitial-electrons. Indeed, energy levels calculation exploiting lstart does not depend on RMT size: lstart is not lapw method! So, what is the reason? I don't know! Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 24 Oct 2002 08:17:28 +0200 From: Torsten Andersen Subject: Re: [WIEN]: Xdstart ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Salehi, it is very little information you give, so the answer will be a bit general... It means that either your unit cell is big, or rkmax/gmax is, or your computer uses the memory for something else. Try adding some swap space, or decrease rkmax and gmax (for a start, the problem will then appear later). Best regards, Torsten Andersen. hamid salehi wrote: >==== >hamid salehi >submitted the following contribution: >==== > >Dear wien users. >Ihave started Initializ cale for large unite cel(in >Pentium Four by RAM 768M ) and got this message(X >dstart:Not enough memory). what dose it mean?or What >is its reason? >What should be done for eliminating it? >Thank you for the guide. >H-Salehi >Dept of physics >Ferdowsi University >MASHHAD IRAN > > >===== >Hamdollah Salehi >Dept of Physics >Ferdowsi University >Mashhad IRAN >Post boxs 1436 >Post code 91775 >faxs > >__________________________________________________ >Do you Yahoo!? >Y! Web Hosting - Let the expert host your web site >http://webhosting.yahoo.com/ >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 24 Oct 2002 09:16:57 +0200 From: Thomas Claesson Subject: [WIEN]: Convergence problems ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am working on a case where I have big troubles with convergence. I want to add LDA+U with a U-value of 0.5 - 0.6 Ry and that is where I run into trouble. First I run the case without LDA+U to self-consistency and that works just fine. Then I can make it converge with a U-value of 0.15 Ry. After that I try to slowly increase U in small steps, running to self-consistency for each new value. That works until I get just above 0.2 Ry, but for larger U-values I get oscillations and cannot reach self-consistency. My case (NiO) has three atoms in the unit cell and so far I have been using 400 k-points the whole BZ (44 in IBZ) and R*K_max = 7.0. I have tried using PRATT mixing with a mixing parameter of just 0.01, still it doesn't converge. So I wonder, what can I do to improve convergency for larger U-values? Can a denser k-mesh make things better? Any suggestions are welcome! Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 24 Oct 2002 11:31:40 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Xdstart ==== "Saeid Jalali" submitted the following contribution: ==== Dear Hamid, Would you send us your struct file? You will make me so happy if you call me discussing your problem in more detail: +98-0311-391 2690. Your, Saeid. > ==== > hamid salehi > submitted the following contribution: > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 25 Oct 2002 21:52:13 +0800 From: joshua xie Subject: [WIEN]: Fermi level ==== joshua xie submitted the following contribution: ==== Dear wien user£¬ For impurity in semiconductor,such as N impurity which substutites C atom in some semicondcutor. To my knowledge,because the N has one more valence electron than C ,the fermi level should lie within the bottom of conduction band ,therefore make the semiconductor n-type. But After wien calculation, I find the fermi level lies at the bottom of conduction band, not within the conduction band, and also it is not consistent with the LMTO calculation from literatures. I do not know if it is a bug. Could someone explain it to me? or do I make a mistake? Best regards! Joshua xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 25 Oct 2002 19:26:03 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Fermi level ==== "Saeid Jalali" submitted the following contribution: ==== > For impurity in semiconductor,such as N impurity which substutites C atom in some semicondcutor. To my knowledge,because the N has one more valence electron than C ,the fermi level should lie within the bottom of conduction band ,therefore make the semiconductor n-type. But After wien calculation, I find the fermi level lies at the bottom of conduction band, not within the conduction band, and also it is not consistent with the LMTO calculation from literatures. > I do not know if it is a bug. Could someone explain it to me? or do I make a mistake? Integral of total density of state (tot-DOS) over an interval [E1, E2] yields number of electrons distributed on that interval of energy provided E2<=Fermi Energy=Ef. The condition is due to the fact that there is no electron for E2>Ef. This means that one can write at zero temperature (T=0): Ef=E_c-E0 or Ef=E_v+E0 provided that E0<=Eg, where E_c is the bottom of the lowest empty conduction band(s), E_v is the top of the highest filled valence band, and Eg is the gap between Ec and Ev (Eg=Ec-Ev). In this case charge conservation law is hold for E_c-E0=0 the story will be different, which is not the case in wien. Thus, one would not complain about the right position of E_f in T<>0 employing T=0 theory. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 27 Oct 2002 9:48:48 +0800 From: caimengqiu@yahoo.com.cn Subject: [WIEN]: help ==== caimengqiu@yahoo.com.cn submitted the following contribution: ==== Dear P.Blaha and Wien user I have a problem when I generate a file of case.struct.The space_group is B1a1 by the experimental result.But there is not the same space_group.I want to know how to transform the B1a1 group to equal group. Thank you very much ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 27 Oct 2002 10:22:50 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: help ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > caimengqiu@yahoo.com.cn > submitted the following contribution: > ==== > > I have a problem when I generate a file of case.struct.The > space_group is B1a1 by the experimental result.But there is not the same > space_group.I want to know how to transform the B1a1 group to equal > group. This is very little information... At least you should include your case.struct. Most probably the structure you defined in case.struct isn't the structure you wanted to define. Look at your case.struct by xcrysden, or draw it on paper by the coordinates that are abundantly available in case.outputnn. Is this what you wanted it to be? Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 27 Oct 2002 14:11:08 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: help ==== "Saeid Jalali" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0075_01C27DC2.B1F954B0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable > I have a problem when I generate a file of case.struct.The=20 > space_group is B1a1 by the experimental result.But there is not the = same=20 > space_group.I want to know how to transform the B1a1 group to equal=20 > group. Most likely the structure of your case is rutile, which is equal to the = space group of P42/MNM and the number of 136. One can specify the = crystallographic space groups using either the space group numbers from = the international tables or the character strings derived from the = Hermann Mauguin Symbols. For example B1A1, ICM2, PMAM, P21CNS, P42/MNM = are equal. So you would choose this #136 for you case, and fill the = atomic positions getting help from struct generator of wien, and then = try to plot your case to find out if you are in a right direction. Your, Saeid. - ------=_NextPart_000_0075_01C27DC2.B1F954B0 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
>   I have a problem when = I generate=20 a file of case.struct.The
> space_group is B1a1 by the = experimental=20 result.But there is not the same
> space_group.I want to know how = to=20 transform the B1a1 group to equal
>=20 group.
Most likely the structure of your case = is rutile,=20 which is equal to the space group of P42/MNM and the number of = 136.=20 One can  specify the crystallographic space groups using = either the=20 space group numbers from the international tables or the = character=20 strings derived from the Hermann Mauguin Symbols. For = example  = B1A1, ICM2, PMAM,=20 P21CNS, P42/MNM are equal. So you would choose this #136 for you case, = and fill=20 the atomic positions getting help from struct generator of wien, and = then try to=20 plot your case to find out if you are in a right direction.
       =20 Your,
       =20 Saeid.
- ------=_NextPart_000_0075_01C27DC2.B1F954B0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 22:00:06 +0800 (CST) From: =?gb2312?q?mengqiu=20cai?= Subject: [WIEN]: help ==== =?gb2312?q?mengqiu=20cai?= submitted the following contribution: ==== Dear Sir: Thank you much for your help .Now I did not resolve my problem.I provided the detail information.I am meeting with a problem when I generate a file of case.struct of the crystal of Bi3Ti4O12 with the parent struct that consists of perovskite-like An-1BnO3n+1 (n=3)slabs regularly interleaved with Bi2O2 with the interface wien2k_web.I want to obtain the equivalent atom coordinates of the characteristic atom by the crystal space group.The space group of the crystal Bi3Ti4O12 is B1a1 by the experimental refercnces.But there is not the same space group in the wien2k code.So I will not get the file of case.struct. I want to know how to transform the B1a1 group to equal group and how much is the transformed atom coordinates.On the other hand,The crystal is monoclinic struct and with small angle change in contrast to the orthogonal struct ,Whether or not I treat the crystal as rthogonal subscribe wien crystal with the crystal axial angle ¨»=90 ß=90 y =90. Thank you very much I am looking forward to hearing from you. Sinecerely yours! Enclosures: The experimental datas. space group : B1a1 a=5.450 , b=5.4059 ,c=32.832 Å ß=90.00 Bi(1) 0.0030 0.5023 0.5673 Bi(1)' 0.0013 0.4977 0.4336 Bi(2) -0.0021 0.4793 0.7113 Bi(2)' 0.0021 0.5185 0.2887 Ti(1) 0.0446 -0.0013 0.5007 Ti(2) 0.0520 0.0004 0.6289 Ti(2)' 0.0499 0.0002 0.3717 O(1) 0.2990 0.2760 0.5102 O(1)' 0.3548 -0.2179 0.4942 O(2) 0.2704 0.2442 0.2495 O(2)' 0.2736 0.7571 0.7489 O(3) 0.0913 -0.0705 0.5605 O(3)' 0.0918 0.0587 0.4424 O(4) 0.0552 0.0584 0.6825 O(4)' 0.0568 -0.0441 0.3195 O(5) 0.2904 0.2800 0.6121 O(5)' 0.2962 -0.2659 0.3892 O(6) 0.3677 -0.1959 0.6244 O(6)' 0.3496 0.2164 0.3773 Case.struct without the the equivalent atom coordinates of the characteristic atom subscribe wien by the crystal space group.Because the crystal is monoclinic struct and with small angle change in contrast to the orthogonal struct ,I treat the crystal as orthogonal crystal with the crystal axial angle ¨»=90 ß=90 y =90. bto P LATTICE,NONEQUIV. ATOMS:10 MODE OF CALC=RELA 10.299011 10.215675 62.043513 90.000000 90.000000 90.000000 Atom= -1: X=0.00300000 Y=0.50230000 subscribe wien Z=0.56730000 MULT= 2 ISPLIT= 8 Atom= -1: X=0.00130000 Y=0.49770000 Z=0.43360000 Bi NPT= 781 R0=0.00000500 RMT= 2.0000 Z: 81.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -2: X=0.99790000 Y=0.47930000 Z=0.71130000 MULT= 2 ISPLIT= 8 Atom= -2: X=0.21000000 Y=0.51850000 Z=0.28870000 Bi NPT=781 R0=0.00000500 RMT= 1.0000 Z: 83.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -3: X=0.04360000 Y=0.99870000 Z=0.50070000 MULT= 1 ISPLIT= 8 Tl NPT= 781 R0=0.00000500 RMT= 1.8000 Z: 81.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -4: X=0.05200000 Y=0.99960000 Z=0.62890000 MULT= 2 ISPLIT= 8 Atom= -4: X=0.04990000 Y=0.00020000 Z=0.37170000 Tl NPT= 781 R0=0.00000500 RMT= 1.8000 Z: 81.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -5: X=0.29900000 Y=0.27600000 Z=0.51020000 MULT= 2 ISPLIT= 8 Atom= -5: X=0.35480000 Y=0.78210000 Z=0.49420000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -6: X=0.27040000 Y=0.24420000 Z=0.24950000 MULT= 2 ISPLIT= 8 Atom= -6: X=0.27360000 Y=0.75710000 Z=0.74890000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -7: X=0.09130000 Y=0.92950000 Z=0.56050000 MULT= 2 ISPLIT= 8 Atom= -7: X=0.09180000 Y=0.05870000 Z=0.44240000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -8: X=0.05520000 Y=0.05840000 Z=0.68250000 MULT= 2 ISPLIT= 8 Atom= -8: X=0.56800000 Y=0.95590000 Z=0.31950000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -9: X=0.29040000 Y=0.28000000 Z=0.61210000 MULT= 2 ISPLIT= 8 Atom= -9: X=0.29620000 Y=0.73410000 Z=0.38920000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-10: X=0.36770000 Y=0.80410000 Z=0.62440000 MULT= 2 ISPLIT= 8 Atom=-10: X=0.34960000 Y=0.21640000 Z=0.37730000 O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 SYMMETRY OPERATIONS: end _________________________________________________________ Do You Yahoo!? "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" http://cn.promo.yahoo.com/cgi-bin/udb/u ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 06:50:43 -0800 (PST) From: Wenqing ZHANG Subject: [WIEN]: Pentinum IV cluster workstation ==== Wenqing ZHANG submitted the following contribution: ==== Deal All, I noticed that many people began to using cluster workstation using Pentinum IV CPU recently. May anyone answer me the following questions? -- 1. How is the speed of computation (per CPU) in comparion with HP PA-8700 (CPU 440MHZ) or SUN ultra-80 (CPU 550MHZ)? 2. Where can I find the product for sale? 3. What is the price if I want to have a Pentinum IV workstation with 16 CPUs? Thanks very much for help. Yours -- Wenqing ===== Wenqing ZHANG 1970 Crystal Lake Dr. Apt#E79 Shelby Twp., MI 48316 Tel: (810)254-9931(h), (810)323-1551(o) Fax: (810)323-9898 __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 09:59:02 -0800 (PST) From: Claudio Lee Subject: [WIEN]: OP - Obital polarization ==== Claudio Lee submitted the following contribution: ==== Hi all, Has onyone successfuly calculated the obital polarization (OP) involved in the spin polarized calculation. Please help me. As a test, my system is Fe bcc. First I calculated this system by running "runsp_lapw -so" (yet I have already involved spin-obit coupling), the final result is ok. After this first step has been done, what I now want to do is to get orbital polarization involved in my calculation. I have created these two files *.indm and *. inorb, they are: *.indm: === - -9. Emin cutoff energy 1 number of atoms 1 1 2 index of 1st atom, 0 0 r-index, (l,s)0index === *.inorb: 2 1 0 nmod, natorb, ipr, amix BROYD 0.3 Broyden mixing used with mix... 1 1 2 iatom, nlorb, lorb 0 nmodop 1 Ncalc 0. 0. 1. direction of M in terms of lattice .. === After all I used "runsp_lapw -so -orb" to run the program. When the program has stopped I got no errors from *. error files, and in the *.err file it looks like: === hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END === I have tried to find if there are any properly answers about this case so far, unfornately, there is no that answer! If anyone knows the answer could you please help me. Thank you in advance. Claudio. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 21:16:18 +0100 (MET) From: Pavel Novak Subject: Re: [WIEN]: OP - Obital polarization ==== Pavel Novak submitted the following contribution: ==== Dear Claudio, try to copy *.indm to *.indmc. Regards Pavel Novak On Mon, 28 Oct 2002, Claudio Lee wrote: > ==== > Claudio Lee > submitted the following contribution: > ==== > > Hi all, > Has onyone successfuly calculated the obital > polarization (OP) involved in the spin polarized > calculation. Please help me. > As a test, my system is Fe bcc. First I calculated > this system by running "runsp_lapw -so" (yet I have > already involved spin-obit coupling), the final result > is ok. > After this first step has been done, what I now want > to do is to get orbital polarization involved in my > calculation. I have created these two files *.indm > and *. inorb, > they are: > *.indm: > === > -9. Emin cutoff energy > 1 number of atoms > 1 1 2 index of 1st atom, > 0 0 r-index, (l,s)0index > === > *.inorb: > 2 1 0 nmod, natorb, ipr, amix > BROYD 0.3 Broyden mixing used with mix... > 1 1 2 iatom, nlorb, lorb > 0 nmodop > 1 Ncalc > 0. 0. 1. direction of M in terms of lattice .. > === > After all I used "runsp_lapw -so -orb" to run the > program. When the program has stopped I got no errors > from *. error files, and in the *.err file it looks > like: > === > hup: Command not found. > STOP LAPW0 END > STOP LAPW1 END > STOP LAPW1 END > STOP LAPWSO END > STOP LAPW2 END > STOP LAPW2 END > === > I have tried to find if there are any properly answers > about this case so far, unfornately, there is no that > answer! > If anyone knows the answer could you please help me. > > Thank you in advance. > > Claudio. > > > > > > > > __________________________________________________ > Do you Yahoo!? > Y! Web Hosting - Let the expert host your web site > http://webhosting.yahoo.com/ > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 14:10:13 -0800 (PST) From: yanming Ma Subject: [WIEN]: generate k mesh using Xcrysden ==== yanming Ma submitted the following contribution: ==== - --0-2049783500-1035843013=:90000 Content-Type: text/plain; charset=us-ascii Dear wien2k user, I try to use Xcrysden to generate K-mesh along high symmetry direction. My case structure is Cmca symmetry. After I run the Xcrysden, I choose Conventional BZ, other than primitive BZ because my input atomic positions are from conventional settings of international Crystalgraphic table. Then I select 7 special k points, the total k points along whole path is chosen as 60. The default value for ISS shringking factor is 2. Minium and Maxium energy are -1.0 Ry and 1.5 Ry, respectively. However there are only some zero values generated, the error messages in the generated case.klist file is as following. ERROR: IDV*NK to big! Decrease number of k points. I try to decrease K points, but it is useless. I try to use primitive BZ. It works. But in my Cmca Case, I can not use primitive BZ. Can someone help me to solve this problem? I will highly appreciate your help. Yanming Ma Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site - --0-2049783500-1035843013=:90000 Content-Type: text/html; charset=us-ascii

Dear wien2k user,

I try to use Xcrysden to generate K-mesh along high symmetry direction. My case structure is Cmca symmetry. After I run the Xcrysden, I choose Conventional BZ, other than primitive BZ because my input atomic positions are from conventional settings of international Crystalgraphic table. Then I select 7 special k points, the total k points along whole path is chosen as 60.  The default value for ISS shringking factor is 2. Minium and Maxium energy are  -1.0 Ry and 1.5 Ry, respectively.  However there are only some zero values generated, the error messages in the generated case.klist file is as following.

ERROR: IDV*NK to big! Decrease number of k points.

I try to decrease K points, but it is useless.

I try to use primitive BZ. It works. But in my Cmca Case, I can not use primitive BZ.

Can someone help me to solve this problem? I will highly appreciate your help.

Yanming Ma

 



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site - --0-2049783500-1035843013=:90000-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 14:16:13 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question about symmetry operator ==== Ma Chi Chiu submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --143914132-1867631754-1035872173=:9012 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all, I would like to consult about the symmetry found by wien. I get a .outputs file with lines like : ATOM: -1 no pointgroup found, isym = 0 lm: ============================================== ATOM: -2 no pointgroup found, isym = 0 lm: ============================================== ATOM: -3 ........ What is the problem? Thank you very much Martin PS .outputs file is attached with this mail - --143914132-1867631754-1035872173=:9012 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case.outputs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case.outputs" MjAyMA0KIEJyYXZhaXMgTWF0cml4Og0KICAgICAgICAxLjAwMDAwICAgICAg ICAwLjAwMDAwICAgICAgICAwLjAwMDAwDQogICAgICAgIDAuMDAwMDAgICAg ICAgIDEuMDAwMDAgICAgICAgIDAuMDAwMDANCiAgICAgICAgMC4wMDAwMCAg ICAgICAgMC4wMDAwMCAgICAgICAgMS4wMDAwMA0KICBBVE9NSUMgUE9TSVRJ T05TOg0KICAgIDEgICAgNTUuODc4Mzc0MDcgICAgMzAuMjM1NjMwMDAgICAg IDQuNjUxMDc5MDANCiAgICAyICAgIDMwLjIzNTYzMDAwICAgIDU1Ljg3ODM3 NDA3ICAgICA0LjY1MTA3OTAwDQogICAgMyAgICAgNC41OTI4ODU5MyAgICAz MC4yMzU2MzAwMCAgICAgNC42NTEwNzkwMA0KICAgIDQgICAgMzAuMjM1NjMw MDAgICAgIDQuNTkyODg1OTMgICAgIDQuNjUxMDc5MDANCiAgICA1ICAgIDU1 LjczNzkwMDU0ICAgIDMyLjkxNjAyNjQ2ICAgICA0LjY1MTA3OTAwDQogICAg NiAgICAyNy41NTUyMzM1NCAgICA1NS43Mzc5MDA1NCAgICAgNC42NTEwNzkw MA0KICAgIDcgICAgIDQuNzMzMzU5NDYgICAgMjcuNTU1MjMzNTQgICAgIDQu NjUxMDc5MDANCiAgICA4ICAgIDMyLjkxNjAyNjQ2ICAgICA0LjczMzM1OTQ2 ICAgICA0LjY1MTA3OTAwDQogICAgOSAgICA1NS41NjI2NjkzNSAgICAzNC4y NDcwMzg4MCAgICAgMi4zMjU1Mzk1MA0KICAgMTAgICAgMjYuMjI0MjIxMjAg ICAgNTUuNTYyNjY5MzUgICAgIDIuMzI1NTM5NTANCiAgIDExICAgICA0Ljkw ODU5MDY1ICAgIDI2LjIyNDIyMTIwICAgICAyLjMyNTUzOTUwDQogICAxMiAg ICAzNC4yNDcwMzg4MCAgICAgNC45MDg1OTA2NSAgICAgMi4zMjU1Mzk1MA0K ICAgMTMgICAgNTUuMDA0NjE4NzkgICAgMzYuODcyNDYwODQgICAgIDIuMzI1 NTM5NTANCiAgIDE0ICAgIDIzLjU5ODc5OTE2ICAgIDU1LjAwNDYxODc5ICAg ICAyLjMyNTUzOTUwDQogICAxNSAgICAgNS40NjY2NDEyMSAgICAyMy41OTg3 OTkxNiAgICAgMi4zMjU1Mzk1MA0KICAgMTYgICAgMzYuODcyNDYwODQgICAg IDUuNDY2NjQxMjEgICAgIDIuMzI1NTM5NTANCiAgIDE3ICAgIDU0LjYyMzMy ODc1ICAgIDM4LjE1OTY3Mzg1ICAgICA0LjY1MTA3OTAwDQogICAxOCAgICA1 My42NjE0NDI2NSAgICA0MC42NjU0NzM0NiAgICAgNC42NTEwNzkwMA0KICAg MTkgICAgNTMuMDgzNDgyNTQgICAgNDEuODc3MTkyMzMgICAgIDIuMzI1NTM5 NTANCiAgIDIwICAgIDUxLjc0MTQ0NTA3ICAgIDQ0LjIwMTY2OTQ3ICAgICAy LjMyNTUzOTUwDQogICAyMSAgICA1MC45ODEwNDU1OSAgICA0NS4zMDgwNTcw OSAgICAgNC42NTEwNzkwMA0KICAgMjIgICAgNDkuMjkxOTAyNDkgICAgNDcu MzkzOTc1MTAgICAgIDQuNjUxMDc5MDANCiAgIDIzICAgIDQ4LjM2Nzc4ODU1 ICAgIDQ4LjM2Nzc4ODU1ICAgICAyLjMyNTUzOTUwDQogICAyNCAgICA0Ni4z NzMxMzE5NSAgICA1MC4xNjM3ODQ5NyAgICAgMi4zMjU1Mzk1MA0KICAgMjUg ICAgNDUuMzA4MDU3MDkgICAgNTAuOTgxMDQ1NTkgICAgIDQuNjUxMDc5MDAN CiAgIDI2ICAgIDQzLjA1NzAwMjM0ICAgIDUyLjQ0Mjg5Nzc4ICAgICA0LjY1 MTA3OTAwDQogICAyNyAgICA0MS44NzcxOTIzMyAgICA1My4wODM0ODI1NCAg ICAgMi4zMjU1Mzk1MA0KICAgMjggICAgMzkuNDI1MTY3NDAgICAgNTQuMTc1 MTkzNzggICAgIDIuMzI1NTM5NTANCiAgIDI5ICAgIDM4LjE1OTY3Mzg1ICAg IDU0LjYyMzMyODc1ICAgICA0LjY1MTA3OTAwDQogICAzMCAgICAyMi4zMTE1 ODYxNSAgICA1NC42MjMzMjg3NSAgICAgNC42NTEwNzkwMA0KICAgMzEgICAg MTkuODA1Nzg2NTQgICAgNTMuNjYxNDQyNjUgICAgIDQuNjUxMDc5MDANCiAg IDMyICAgIDE4LjU5NDA2NzY3ICAgIDUzLjA4MzQ4MjU0ICAgICAyLjMyNTUz OTUwDQogICAzMyAgICAxNi4yNjk1OTA1MyAgICA1MS43NDE0NDUwNyAgICAg Mi4zMjU1Mzk1MA0KICAgMzQgICAgMTUuMTYzMjAyOTEgICAgNTAuOTgxMDQ1 NTkgICAgIDQuNjUxMDc5MDANCiAgIDM1ICAgIDEzLjA3NzI4NDkwICAgIDQ5 LjI5MTkwMjQ5ICAgICA0LjY1MTA3OTAwDQogICAzNiAgICAxMi4xMDM0NzE0 NSAgICA0OC4zNjc3ODg1NSAgICAgMi4zMjU1Mzk1MA0KICAgMzcgICAgMTAu MzA3NDc1MDMgICAgNDYuMzczMTMxOTUgICAgIDIuMzI1NTM5NTANCiAgIDM4 ICAgICA5LjQ5MDIxNDQxICAgIDQ1LjMwODA1NzA5ICAgICA0LjY1MTA3OTAw DQogICAzOSAgICAgOC4wMjgzNjIyMiAgICA0My4wNTcwMDIzNCAgICAgNC42 NTEwNzkwMA0KICAgNDAgICAgIDcuMzg3Nzc3NDYgICAgNDEuODc3MTkyMzMg ICAgIDIuMzI1NTM5NTANCiAgIDQxICAgICA2LjI5NjA2NjIyICAgIDM5LjQy NTE2NzQwICAgICAyLjMyNTUzOTUwDQogICA0MiAgICAgNS44NDc5MzEyNSAg ICAzOC4xNTk2NzM4NSAgICAgNC42NTEwNzkwMA0KICAgNDMgICAgIDUuODQ3 OTMxMjUgICAgMjIuMzExNTg2MTUgICAgIDQuNjUxMDc5MDANCiAgIDQ0ICAg ICA2LjgwOTgxNzM1ICAgIDE5LjgwNTc4NjU0ICAgICA0LjY1MTA3OTAwDQog ICA0NSAgICAgNy4zODc3Nzc0NiAgICAxOC41OTQwNjc2NyAgICAgMi4zMjU1 Mzk1MA0KICAgNDYgICAgIDguNzI5ODE0OTMgICAgMTYuMjY5NTkwNTMgICAg IDIuMzI1NTM5NTANCiAgIDQ3ICAgICA5LjQ5MDIxNDQxICAgIDE1LjE2MzIw MjkxICAgICA0LjY1MTA3OTAwDQogICA0OCAgICAxMS4xNzkzNTc1MSAgICAx My4wNzcyODQ5MCAgICAgNC42NTEwNzkwMCAgIA0KICAgNDkgICAgMTIuMTAz NDcxNDUgICAgMTIuMTAzNDcxNDUgICAgIDIuMzI1NTM5NTANCiAgIDUwICAg IDE0LjA5ODEyODA1ICAgIDEwLjMwNzQ3NTAzICAgICAyLjMyNTUzOTUwDQog ICA1MSAgICAxNS4xNjMyMDI5MSAgICAgOS40OTAyMTQ0MSAgICAgNC42NTEw NzkwMA0KICAgNTIgICAgMTcuNDE0MjU3NjYgICAgIDguMDI4MzYyMjIgICAg IDQuNjUxMDc5MDANCiAgIDUzICAgIDE4LjU5NDA2NzY3ICAgICA3LjM4Nzc3 NzQ2ICAgICAyLjMyNTUzOTUwDQogICA1NCAgICAyMS4wNDYwOTI2MCAgICAg Ni4yOTYwNjYyMiAgICAgMi4zMjU1Mzk1MA0KICAgNTUgICAgMjIuMzExNTg2 MTUgICAgIDUuODQ3OTMxMjUgICAgIDQuNjUxMDc5MDANCiAgIDU2ICAgIDM4 LjE1OTY3Mzg1ICAgICA1Ljg0NzkzMTI1ICAgICA0LjY1MTA3OTAwDQogICA1 NyAgICA0MC42NjU0NzM0NiAgICAgNi44MDk4MTczNSAgICAgNC42NTEwNzkw MA0KICAgNTggICAgNDEuODc3MTkyMzMgICAgIDcuMzg3Nzc3NDYgICAgIDIu MzI1NTM5NTANCiAgIDU5ICAgIDQ0LjIwMTY2OTQ3ICAgICA4LjcyOTgxNDkz ICAgICAyLjMyNTUzOTUwDQogICA2MCAgICA0NS4zMDgwNTcwOSAgICAgOS40 OTAyMTQ0MSAgICAgNC42NTEwNzkwMA0KICAgNjEgICAgNDcuMzkzOTc1MTAg ICAgMTEuMTc5MzU3NTEgICAgIDQuNjUxMDc5MDANCiAgIDYyICAgIDQ4LjM2 Nzc4ODU1ICAgIDEyLjEwMzQ3MTQ1ICAgICAyLjMyNTUzOTUwDQogICA2MyAg ICA1MC4xNjM3ODQ5NyAgICAxNC4wOTgxMjgwNSAgICAgMi4zMjU1Mzk1MA0K ICAgNjQgICAgNTAuOTgxMDQ1NTkgICAgMTUuMTYzMjAyOTEgICAgIDQuNjUx MDc5MDANCiAgIDY1ICAgIDUyLjQ0Mjg5Nzc4ICAgIDE3LjQxNDI1NzY2ICAg ICA0LjY1MTA3OTAwDQogICA2NiAgICA1My4wODM0ODI1NCAgICAxOC41OTQw Njc2NyAgICAgMi4zMjU1Mzk1MA0KICAgNjcgICAgNTQuMTc1MTkzNzggICAg MjEuMDQ2MDkyNjAgICAgIDIuMzI1NTM5NTANCiAgIDY4ICAgIDU0LjYyMzMy ODc1ICAgIDIyLjMxMTU4NjE1ICAgICA0LjY1MTA3OTAwDQogICA2OSAgICAz NS41NjcwNTYyNiAgICA1NS4zMTgwMTg5NiAgICAgNC42NTEwNzkwMA0KICAg NzAgICAgIDUuMTUzMjQxMDQgICAgMzUuNTY3MDU2MjYgICAgIDQuNjUxMDc5 MDANCiAgIDcxICAgIDI0LjkwNDIwMzc0ICAgICA1LjE1MzI0MTA0ICAgICA0 LjY1MTA3OTAwDQogICA3MiAgICA1NS4zMTgwMTg5NiAgICAyNC45MDQyMDM3 NCAgICAgNC42NTEwNzkwMA0KICAgNzMgICAgMzQuMjQ3MDM4ODAgICAgNTUu NTYyNjY5MzUgICAgIDIuMzI1NTM5NTANCiAgIDc0ICAgICA0LjkwODU5MDY1 ICAgIDM0LjI0NzAzODgwICAgICAyLjMyNTUzOTUwDQogICA3NSAgICAyNi4y MjQyMjEyMCAgICAgNC45MDg1OTA2NSAgICAgMi4zMjU1Mzk1MA0KICAgNzYg ICAgNTUuNTYyNjY5MzUgICAgMjYuMjI0MjIxMjAgICAgIDIuMzI1NTM5NTAN CiAgIDc3ICAgIDMxLjU3NzY2NzQ2ICAgIDU1Ljg0MzIzMTgwICAgICAyLjMy NTUzOTUwDQogICA3OCAgICAgNC42MjgwMjgyMCAgICAzMS41Nzc2Njc0NiAg ICAgMi4zMjU1Mzk1MA0KICAgNzkgICAgMjguODkzNTkyNTQgICAgIDQuNjI4 MDI4MjAgICAgIDIuMzI1NTM5NTANCiAgIDgwICAgIDU1Ljg0MzIzMTgwICAg IDI4Ljg5MzU5MjU0ICAgICAyLjMyNTUzOTUwDQogUEdMU1lNOiBUSEUgQ1JZ U1RBTCBTWVNURU0gSVMgVEVUUkFHT05BTA0KIFBHTFNZTTogT1JERVIgT0Yg TEFUVElDRSBQT0lOVCBHUk9VUCAoTk8gQkFTRSkgPSAgIDE2DQogUEdCU1lN OiBPUkRFUiBPRiBMQVRUSUNFIFNQQUNFIEdST1VQIChXSVRIIEJBU0UpID0g OA0KIFBHQlNZTTogU1BBQ0UgR1JPVVAgSVMgU1lNTU9SUEhJQw0KIFBHQlNZ TTogU1BBQ0UgR1JPVVAgQ09OVEFJTlMgSU5WRVJTSU9ODQogU3ltbWV0cnkg b3BlcmF0aW9uIDENCiAgICAgICAtMS4wMDAwMCAgICAgICAgMC4wMDAwMCAg ICAgICAgMC4wMDAwMA0KICAgICAgICAwLjAwMDAwICAgICAgIC0xLjAwMDAw ICAgICAgICAwLjAwMDAwDQogICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAw MDAgICAgICAgLTEuMDAwMDANCiAgICAgICAgMC4wMDAwMCAgICAgICAgMC4w MDAwMCAgICAgICAgMC4wMDAwMA0KICAgLTEuMDAwMCAgICAwLjAwMDAgICAg MC4wMDAwICAgIDAuMDAwMA0KICAgIDAuMDAwMCAgIC0xLjAwMDAgICAgMC4w MDAwICAgIDAuMDAwMA0KICAgIDAuMDAwMCAgICAwLjAwMDAgICAtMS4wMDAw ICAgIDAuMDAwMA0KIFN5bW1ldHJ5IG9wZXJhdGlvbiAyDQogICAgICAgLTEu MDAwMDAgICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDANCiAgICAgICAg MC4wMDAwMCAgICAgICAtMS4wMDAwMCAgICAgICAgMC4wMDAwMA0KICAgICAg ICAwLjAwMDAwICAgICAgICAwLjAwMDAwICAgICAgICAxLjAwMDAwDQogICAg ICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDANCiAg IC0xLjAwMDAgICAgMC4wMDAwICAgIDAuMDAwMCAgICAwLjAwMDANCiAgICAw LjAwMDAgICAtMS4wMDAwICAgIDAuMDAwMCAgICAwLjAwMDANCiAgICAwLjAw MDAgICAgMC4wMDAwICAgIDEuMDAwMCAgICAwLjAwMDANCiBTeW1tZXRyeSBv cGVyYXRpb24gMw0KICAgICAgICAwLjAwMDAwICAgICAgIC0xLjAwMDAwICAg ICAgICAwLjAwMDAwDQogICAgICAgIDEuMDAwMDAgICAgICAgIDAuMDAwMDAg ICAgICAgIDAuMDAwMDANCiAgICAgICAgMC4wMDAwMCAgICAgICAgMC4wMDAw MCAgICAgICAtMS4wMDAwMA0KICAgICAgICAwLjAwMDAwICAgICAgICAwLjAw MDAwICAgICAgICAwLjAwMDAwDQogICAgMC4wMDAwICAgIDEuMDAwMCAgICAw LjAwMDAgICAgMC4wMDAwDQogICAtMS4wMDAwICAgIDAuMDAwMCAgICAwLjAw MDAgICAgMC4wMDAwDQogICAgMC4wMDAwICAgIDAuMDAwMCAgIC0xLjAwMDAg ICAgMC4wMDAwDQogU3ltbWV0cnkgb3BlcmF0aW9uIDQNCiAgICAgICAgMC4w MDAwMCAgICAgICAtMS4wMDAwMCAgICAgICAgMC4wMDAwMA0KICAgICAgICAx LjAwMDAwICAgICAgICAwLjAwMDAwICAgICAgICAwLjAwMDAwDQogICAgICAg IDAuMDAwMDAgICAgICAgIDAuMDAwMDAgICAgICAgIDEuMDAwMDANCiAgICAg ICAgMC4wMDAwMCAgICAgICAgMC4wMDAwMCAgICAgICAgMC4wMDAwMA0KICAg IDAuMDAwMCAgICAxLjAwMDAgICAgMC4wMDAwICAgIDAuMDAwMA0KICAgLTEu MDAwMCAgICAwLjAwMDAgICAgMC4wMDAwICAgIDAuMDAwMA0KICAgIDAuMDAw MCAgICAwLjAwMDAgICAgMS4wMDAwICAgIDAuMDAwMA0KIFN5bW1ldHJ5IG9w ZXJhdGlvbiA1DQogICAgICAgIDAuMDAwMDAgICAgICAgIDEuMDAwMDAgICAg ICAgIDAuMDAwMDANCiAgICAgICAtMS4wMDAwMCAgICAgICAgMC4wMDAwMCAg ICAgICAgMC4wMDAwMA0KICAgICAgICAwLjAwMDAwICAgICAgICAwLjAwMDAw ICAgICAgIC0xLjAwMDAwDQogICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAw MDAgICAgICAgIDAuMDAwMDANCiAgICAwLjAwMDAgICAtMS4wMDAwICAgIDAu MDAwMCAgICAwLjAwMDANCiAgICAxLjAwMDAgICAgMC4wMDAwICAgIDAuMDAw MCAgICAwLjAwMDANCiAgICAwLjAwMDAgICAgMC4wMDAwICAgLTEuMDAwMCAg ICAwLjAwMDANCiBTeW1tZXRyeSBvcGVyYXRpb24gNg0KICAgICAgICAwLjAw MDAwICAgICAgICAxLjAwMDAwICAgICAgICAwLjAwMDAwDQogICAgICAgLTEu MDAwMDAgICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDANCiAgICAgICAg MC4wMDAwMCAgICAgICAgMC4wMDAwMCAgICAgICAgMS4wMDAwMA0KICAgICAg ICAwLjAwMDAwICAgICAgICAwLjAwMDAwICAgICAgICAwLjAwMDAwDQogICAg MC4wMDAwICAgLTEuMDAwMCAgICAwLjAwMDAgICAgMC4wMDAwDQogICAgMS4w MDAwICAgIDAuMDAwMCAgICAwLjAwMDAgICAgMC4wMDAwDQogICAgMC4wMDAw ICAgIDAuMDAwMCAgICAxLjAwMDAgICAgMC4wMDAwDQogU3ltbWV0cnkgb3Bl cmF0aW9uIDcNCiAgICAgICAgMS4wMDAwMCAgICAgICAgMC4wMDAwMCAgICAg ICAgMC4wMDAwMA0KICAgICAgICAwLjAwMDAwICAgICAgICAxLjAwMDAwICAg ICAgICAwLjAwMDAwDQogICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDAg ICAgICAgLTEuMDAwMDANCiAgICAgICAgMC4wMDAwMCAgICAgICAgMC4wMDAw MCAgICAgICAgMC4wMDAwMA0KICAgIDEuMDAwMCAgICAwLjAwMDAgICAgMC4w MDAwICAgIDAuMDAwMA0KICAgIDAuMDAwMCAgICAxLjAwMDAgICAgMC4wMDAw ICAgIDAuMDAwMA0KICAgIDAuMDAwMCAgICAwLjAwMDAgICAtMS4wMDAwICAg IDAuMDAwMA0KIFN5bW1ldHJ5IG9wZXJhdGlvbiA4DQogICAgICAgIDEuMDAw MDAgICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDANCiAgICAgICAgMC4w MDAwMCAgICAgICAgMS4wMDAwMCAgICAgICAgMC4wMDAwMA0KICAgICAgICAw LjAwMDAwICAgICAgICAwLjAwMDAwICAgICAgICAxLjAwMDAwDQogICAgICAg IDAuMDAwMDAgICAgICAgIDAuMDAwMDAgICAgICAgIDAuMDAwMDANCiAgICAx LjAwMDAgICAgMC4wMDAwICAgIDAuMDAwMCAgICAwLjAwMDANCiAgICAwLjAw MDAgICAgMS4wMDAwICAgIDAuMDAwMCAgICAwLjAwMDANCiAgICAwLjAwMDAg ICAgMC4wMDAwICAgIDEuMDAwMCAgICAwLjAwMDANCiANCiANCiANCkRFVEVS TUlOQVRJT04gT0YgUE9JTlRHUk9VUCBGT1IgQUxMIFBPU0lUSU9OUw0KMjAy MA0KQyAgICAgICAgIDogIDE2IEF0b21zLCBJbmRleCAgIDEgdG8gIDE2DQpD ICAgICAgICAgOiAgMTYgQXRvbXMsIEluZGV4ICAxNyB0byAgMzINCkMgICAg ICAgICA6ICAxNiBBdG9tcywgSW5kZXggIDMzIHRvICA0OA0KQyAgICAgICAg IDogIDE2IEF0b21zLCBJbmRleCAgNDkgdG8gIDY0DQpDICAgICAgICAgOiAy MDggQXRvbXMsIEluZGV4ICA2NSB0byAyNzINCkMgICAgICAgICA6ICAxNiBB dG9tcywgSW5kZXggMjczIHRvIDI4OA0KQyAgICAgICAgIDogIDE2IEF0b21z LCBJbmRleCAyODkgdG8gMzA0DQpDICAgICAgICAgOiAgMTYgQXRvbXMsIElu ZGV4IDMwNSB0byAzMjANCm51bWJlciBvZiBhdG9tczogMzIwDQogDQogQVRP TTogLTENCiAgbm8gcG9pbnRncm91cCBmb3VuZCwgaXN5bSA9IDANCmxtOg0K ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCiANCiBBVE9NOiAtMg0KICBubyBwb2ludGdyb3VwIGZvdW5kLCBpc3lt ID0gMA0KbG06DQogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KIA0KIEFUT006IC0zDQogIG5vIHBvaW50Z3JvdXAg Zm91bmQsIGlzeW0gPSAwDQpsbToNCiA9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQogDQogQVRPTTogLTQNCiAgbm8g cG9pbnRncm91cCBmb3VuZCwgaXN5bSA9IDANCmxtOg0KID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiANCiBBVE9N OiAtNQ0KICBubyBwb2ludGdyb3VwIGZvdW5kLCBpc3ltID0gMA0KbG06DQog PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KIA0KIEFUT006IC02DQogIG5vIHBvaW50Z3JvdXAgZm91bmQsIGlzeW0g PSAwDQpsbToNCiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQogDQogQVRPTTogLTcNCiAgbm8gcG9pbnRncm91cCBm b3VuZCwgaXN5bSA9IDANCmxtOg0KID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiANCiBBVE9NOiAtOA0KICBubyBw b2ludGdyb3VwIGZvdW5kLCBpc3ltID0gMA0KbG06DQogPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSANCg== - --143914132-1867631754-1035872173=:9012-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 09:18:53 +0100 From: "koitzsch" Subject: Re: [WIEN]: generate k mesh using Xcrysden ==== "koitzsch" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0196_01C27F2C.3320EE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable try to calculate the bandstructure in two steps, first path connecting = three special k-points and second path over the remaining four - but I = have to admit I never bothered to figure out, what the error message = really means, I just noticed that if you have a lot of special k-points = with not so many points in between, it does not work. Best Regards=20 Christian Koitzsch Universite de Fribourg Departement de Physique Groupe FK CH-1700 Fribourg Suisse ----- Original Message -----=20 From: yanming Ma=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Monday, October 28, 2002 11:10 PM Subject: [WIEN]: generate k mesh using Xcrysden Dear wien2k user, I try to use Xcrysden to generate K-mesh along high symmetry = direction. My case structure is Cmca symmetry. After I run the Xcrysden, = I choose Conventional BZ, other than primitive BZ because my input = atomic positions are from conventional settings of international = Crystalgraphic table. Then I select 7 special k points, the total k = points along whole path is chosen as 60. The default value for ISS = shringking factor is 2. Minium and Maxium energy are -1.0 Ry and 1.5 = Ry, respectively. However there are only some zero values generated, = the error messages in the generated case.klist file is as following. ERROR: IDV*NK to big! Decrease number of k points. I try to decrease K points, but it is useless.=20 I try to use primitive BZ. It works. But in my Cmca Case, I can not = use primitive BZ.=20 Can someone help me to solve this problem? I will highly appreciate = your help. Yanming Ma Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - -------------------------------------------------------------------------= - ----- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site - ------=_NextPart_000_0196_01C27F2C.3320EE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
try to calculate the bandstructure in = two steps,=20 first path connecting three special k-points and second path = over the=20 remaining four - but I have to admit I never bothered to figure out, = what the=20 error message really means, I just noticed that if you have a lot of = special=20 k-points with not so many points in between, it does not = work.
 
Best Regards
 
Christian Koitzsch
 
Universite de Fribourg
Departement de Physique
Groupe FK
CH-1700 Fribourg
Suisse
 
----- Original Message -----
From:=20 yanming = Ma
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Monday, October 28, 2002 = 11:10=20 PM
Subject: [WIEN]: generate k = mesh using=20 Xcrysden

Dear wien2k user,

I try to use Xcrysden to generate K-mesh along high symmetry = direction. My=20 case structure is Cmca symmetry. After I run the Xcrysden, I choose=20 Conventional BZ, other than primitive BZ because my input atomic = positions are=20 from conventional settings of international Crystalgraphic table. Then = I=20 select 7 special k points, the total k points along whole path is = chosen as=20 60.  The default value for ISS shringking factor is 2. Minium and = Maxium=20 energy are  -1.0 Ry and 1.5 Ry, respectively.  However=20 there are only some zero values generated, the error = messages in=20 the generated case.klist file is as following.

ERROR: IDV*NK to big! Decrease number of k points.

I try to decrease K points, but it is useless.

I try to use primitive BZ. It works. But in my Cmca Case, = I can not=20 use primitive BZ.

Can someone help me to solve this problem? I will highly appreciate = your=20 help.

Yanming Ma

 



Yanming Ma Ph.D
Steacie Institute for = Molecular=20 Sciences,
National Research Councils of Canada,
Ottawa, = Ontario
K1A=20 0R6
Canada


Do you Yahoo!?
Y! Web = Hosting -=20 Let the expert host your web site - ------=_NextPart_000_0196_01C27F2C.3320EE80-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 10:09:14 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: help ==== Peter Blaha submitted the following contribution: ==== I'm not a crystallographer, but I think B1A1 is actually the same as P42/MNM, which is, however, tetragonal and not monoclinic. Check this structure (using the original paper) with a good crystallographer. Regards > Dear Sir: > Thank you much for your help .Now I did not resolve my > problem.I provided the detail information.I am meeting > with a problem when I generate a file of case.struct > of the crystal of Bi3Ti4O12 with the parent struct > that consists of perovskite-like An-1BnO3n+1 > (n=3)slabs regularly interleaved with Bi2O2 > with the interface wien2k_web.I want to obtain the > equivalent atom coordinates of the characteristic atom > by the crystal space group.The space group of the > crystal Bi3Ti4O12 is B1a1 by the experimental > refercnces.But there is not the same space group in > the wien2k code.So I will not get the file of > case.struct. I want to know how to transform the B1a1 > group to equal group and how much is the transformed > atom coordinates.On the other hand,The crystal is > monoclinic struct and with small angle change in > contrast to the orthogonal > struct ,Whether or not I treat the crystal as > rthogonal subscribe wien crystal with the crystal > axial angle > ¨»=90 ß=90 y =90. > > Thank you very much > > I am looking forward to hearing from you. > > > Sinecerely yours! > > Enclosures: The experimental datas. > space group : B1a1 > a=5.450 , b=5.4059 ,c=32.832 Å > ß=90.00 > > Bi(1) 0.0030 0.5023 0.5673 > Bi(1)' 0.0013 0.4977 0.4336 > Bi(2) -0.0021 0.4793 0.7113 > Bi(2)' 0.0021 0.5185 0.2887 > Ti(1) 0.0446 -0.0013 0.5007 > Ti(2) 0.0520 0.0004 0.6289 > Ti(2)' 0.0499 0.0002 0.3717 > O(1) 0.2990 0.2760 0.5102 > O(1)' 0.3548 -0.2179 0.4942 > O(2) 0.2704 0.2442 0.2495 > O(2)' 0.2736 0.7571 0.7489 > O(3) 0.0913 -0.0705 0.5605 > O(3)' 0.0918 0.0587 0.4424 > O(4) 0.0552 0.0584 0.6825 > O(4)' 0.0568 -0.0441 0.3195 > O(5) 0.2904 0.2800 0.6121 > O(5)' 0.2962 -0.2659 0.3892 > O(6) 0.3677 -0.1959 0.6244 > O(6)' 0.3496 0.2164 0.3773 > > Case.struct without the the equivalent atom > coordinates of the characteristic atom subscribe wien > by the crystal space group.Because the crystal is > monoclinic struct and with small angle change in > contrast to the orthogonal struct ,I treat the > crystal as orthogonal crystal with the crystal axial > angle > ¨»=90 ß=90 y =90. > > > > bto > P LATTICE,NONEQUIV. > > ATOMS:10 > MODE OF CALC=RELA > 10.299011 10.215675 62.043513 90.000000 90.000000 > 90.000000 > Atom= -1: X=0.00300000 Y=0.50230000 subscribe wien > Z=0.56730000 > MULT= 2 ISPLIT= 8 > Atom= -1: X=0.00130000 Y=0.49770000 Z=0.43360000 > Bi NPT= 781 R0=0.00000500 RMT= 2.0000 > Z: 81.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -2: X=0.99790000 Y=0.47930000 Z=0.71130000 > MULT= 2 ISPLIT= 8 > Atom= -2: X=0.21000000 Y=0.51850000 Z=0.28870000 > Bi NPT=781 R0=0.00000500 RMT= 1.0000 Z: > 83.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -3: X=0.04360000 Y=0.99870000 Z=0.50070000 > MULT= 1 ISPLIT= 8 > Tl NPT= 781 R0=0.00000500 RMT= 1.8000 Z: > 81.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -4: X=0.05200000 Y=0.99960000 Z=0.62890000 > MULT= 2 ISPLIT= 8 > Atom= -4: X=0.04990000 Y=0.00020000 Z=0.37170000 > Tl NPT= 781 R0=0.00000500 RMT= 1.8000 Z: 81.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -5: X=0.29900000 Y=0.27600000 Z=0.51020000 > MULT= 2 ISPLIT= 8 > Atom= -5: X=0.35480000 Y=0.78210000 Z=0.49420000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -6: X=0.27040000 Y=0.24420000 Z=0.24950000 > MULT= 2 ISPLIT= 8 > Atom= -6: X=0.27360000 Y=0.75710000 Z=0.74890000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -7: X=0.09130000 Y=0.92950000 Z=0.56050000 > MULT= 2 ISPLIT= 8 > Atom= -7: X=0.09180000 Y=0.05870000 Z=0.44240000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: > 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -8: X=0.05520000 Y=0.05840000 Z=0.68250000 > MULT= 2 ISPLIT= 8 > Atom= -8: X=0.56800000 Y=0.95590000 Z=0.31950000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: > 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -9: X=0.29040000 Y=0.28000000 Z=0.61210000 > MULT= 2 ISPLIT= 8 > Atom= -9: X=0.29620000 Y=0.73410000 Z=0.38920000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: > 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-10: X=0.36770000 Y=0.80410000 Z=0.62440000 > MULT= 2 ISPLIT= 8 > Atom=-10: X=0.34960000 Y=0.21640000 Z=0.37730000 > O NPT= 781 R0=0.00010000 RMT= 1.6000 Z: > 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 0 SYMMETRY OPERATIONS: > > end > > > > > > > > > > > > > > _________________________________________________________ > Do You Yahoo!? > "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" > http://cn.promo.yahoo.com/cgi-bin/udb/u > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 10:13:05 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== Peter Blaha submitted the following contribution: ==== > I noticed that many people began to using cluster > workstation using Pentinum IV CPU recently. May anyone > answer me the following questions? -- > > 1. How is the speed of computation (per CPU) in > comparion with HP PA-8700 (CPU 440MHZ) or SUN ultra-80 > (CPU 550MHZ)? I would estimate that a P-IV may be 4-8 times faster than what you listed above. (Be carefull, I do NOT have any experiences with those CPUs, this is just an estimate) > 2. Where can I find the product for sale? Your next PC dealer... > 3. What is the price if I want to have a Pentinum IV > workstation with 16 CPUs? Just buy 16 PCs (or maybe 8 dual processor PCs) and connect them via a network (switch). 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 10:19:12 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Question about symmetry operator ==== Peter Blaha submitted the following contribution: ==== > I would like to consult about the symmetry found by wien. I get a .outputs file with lines like : > ATOM: -1 > no pointgroup found, isym = 0 Two possibilities: If you have angles far off from 90, set them close to (but not exactly) to 90 degree and run symmetry. (Reset them afterwards) Maybe your structure is incorrectly defined in case.struct. Did it pass through sgroup ? Without struct file further help is not possible. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 10:50:48 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== Torsten Andersen submitted the following contribution: ==== This has been discussed before... is there any way to make a "representative test suite" for Wien2k that would allow us to build a database of performance that could guide hardware buyers? Just a few comments on the subject... About the speed of the P-IV, I would say that it is probably an exaggeration. However, any business that wants to sell you these machines should be able to let you test. Last time I compared PC processors to workstation processors, the result was opposite. A PA-RISC at 180MHz was as fast as a dual-processor Pentium III at I think it was 500MHz, using a test based on Wien97. Simple extrapolation from that will put the P-IV at best at the same speed as one of the two workstation processors you mentioned. However, my test might be biased in another direction than your needs. However, price/performance-wise, if your programs parallelise well (many k-points in the Wien code) and use small amounts of memory (the limit for PC's is usually 2-3GB per PC), the PC cluster is probably the best solution. It probably requires more system administration time, though. PC's with more than 4GB are available (Xeon), but the slowdown due to addressing problems (more than the 32-bit address space) is rumoured to be prohibitively large. If raw performance per processor, and big memory (larger than the 2-3GB mentioned above) is required by some of your programs (assuming you do other and more demanding things than DFT, or DFT with big unit cells) is an issue, the current top of the line processors are the Alpha 21264C at 1GHz-1.25GHz and the IBM Power4 at 1GHz-1.3GHz. The Itanium-I/II sure looks good on paper, but the practical performance is not worth mentioning, imho. The newer UltraSparc III at 1.2GHz are probably also worth considering. In the end, it all depends on your budget. The best performers are the most expensive, just like with most other things. But if you choose the P-IV, I would recommend to stay with the "basic" version - no Xeon and no Celeron, and one processor per machine (current sweet spot in price seems to be 2.53GHz), and with the "533" MHz bus. Use some money on networking, though... a GBit interface from the "server" to the switch, and 100Mbit interfaces from the switch to the "slaves". Best regards, Torsten. Peter Blaha wrote: >==== >Peter Blaha >submitted the following contribution: >==== > >>I noticed that many people began to using cluster >>workstation using Pentinum IV CPU recently. May anyone >>answer me the following questions? -- >> >>1. How is the speed of computation (per CPU) in >>comparion with HP PA-8700 (CPU 440MHZ) or SUN ultra-80 >>(CPU 550MHZ)? >> > >I would estimate that a P-IV may be 4-8 times faster than what you listed >above. (Be carefull, I do NOT have any experiences with those CPUs, this is >just an estimate) > >>2. Where can I find the product for sale? >> > >Your next PC dealer... > >>3. What is the price if I want to have a Pentinum IV >>workstation with 16 CPUs? >> > >Just buy 16 PCs (or maybe 8 dual processor PCs) and connect them via a >network (switch). > > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 20:51:52 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: Question about symmetry operator ==== Ma Chi Chiu submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --143914132-1156411148-1035895912=:9971 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Prof. Peter Blaha, My case.struct file is attached with this mail. Thank you very much yours, Martin - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ "Here is your country, do not let anyone take its glory away ~~ ~~ from you. Do not let selfish men or greedy interests skin ~~ ~~ your country of its beauty, its riches, or its romance. The ~~ ~~ world and the future and your very children shall judge you ~~ ~~ according to the way you deal with this sacred trust." ~~ ~~ ~~ ~~ ~~ ~~ -- Theodore Roosevelt, Antiquities Act of 1906 ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - --143914132-1156411148-1035895912=:9971 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case.struct" MjAyMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUCAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiA4ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQpNT0RFIE9GIENBTEM9UkVMQQ0KIDYwLjQ3MTI2MCA2MC40NzEy NjAgIDQuNjUxMDc5IDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwDQpB dG9tPSAtMTogWD0wLjkyNDA0ODQ1IFk9MC41MDAwMDAwMCBaPTEuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KQXRv bT0gLTE6IFg9MC41MDAwMDAwMCBZPTAuOTI0MDQ4NDUgWj0xLjAwMDAwMDAw DQpBdG9tPSAtMTogWD0wLjA3NTk1MTU1IFk9MC41MDAwMDAwMCBaPTEuMDAw MDAwMDANCkF0b209IC0xOiBYPTAuNTAwMDAwMDAgWT0wLjA3NTk1MTU1IFo9 MS4wMDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAgICAgICAg ICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAg ICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAw MDAwDQpBdG9tPSAtMjogWD0wLjkyMTcyNTQ3IFk9MC41NDQzMjUxMyBaPTEu MDAwMDAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0g OA0KQXRvbT0gLTI6IFg9MC40NTU2NzQ4NyBZPTAuOTIxNzI1NDcgWj0xLjAw MDAwMDAwDQpBdG9tPSAtMjogWD0wLjA3ODI3NDUzIFk9MC40NTU2NzQ4NyBa PTEuMDAwMDAwMDANCkF0b209IC0yOiBYPTAuNTQ0MzI1MTMgWT0wLjA3ODI3 NDUzIFo9MS4wMDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAu MDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAg ICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAw MDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAg MS4wMDAwMDAwDQpBdG9tPSAtMzogWD0wLjkxODgyNzcxIFk9MC41NjYzMzU3 OSBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElT UExJVD0gOA0KQXRvbT0gLTM6IFg9MC40MzM2NjQyMSBZPTAuOTE4ODI3NzEg Wj0wLjUwMDAwMDAwDQpBdG9tPSAtMzogWD0wLjA4MTE3MjI5IFk9MC40MzM2 NjQyMSBaPTAuNTAwMDAwMDANCkF0b209IC0zOiBYPTAuNTY2MzM1NzkgWT0w LjA4MTE3MjI5IFo9MC41MDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAg ICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBdG9tPSAtNDogWD0wLjkwOTU5OTM1IFk9MC42 MDk3NTE4MiBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAg ICAgIElTUExJVD0gOA0KQXRvbT0gLTQ6IFg9MC4zOTAyNDgxOCBZPTAuOTA5 NTk5MzUgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNDogWD0wLjA5MDQwMDY1IFk9 MC4zOTAyNDgxOCBaPTAuNTAwMDAwMDANCkF0b209IC00OiBYPTAuNjA5NzUx ODIgWT0wLjA5MDQwMDY1IFo9MC41MDAwMDAwMA0KQyAgICAgICAgICBOUFQ9 ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4w DQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAu MDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAw MDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBdG9tPSAtNTogWD0wLjkwMzI5NDA0 IFk9MC42MzEwMzgxOCBaPTEuMDAwMDAwMDANCiAgICAgICAgICBNVUxUPTUy ICAgICAgICAgIElTUExJVD0gOA0KQXRvbT0gLTU6IFg9MC44ODczODc1NCBZ PTAuNjcyNDc2MDQgWj0xLjAwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjg3Nzgy OTk0IFk9MC42OTI1MTM5NyBaPTAuNTAwMDAwMDANCkF0b209IC01OiBYPTAu ODU1NjM2OTYgWT0wLjczMDk1MzM0IFo9MC41MDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC44NDMwNjI0MCBZPTAuNzQ5MjQ5NDMgWj0xLjAwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjgxNTEyOTQxIFk9MC43ODM3NDM4MCBaPTEuMDAwMDAwMDAN CkF0b209IC01OiBYPTAuNzk5ODQ3NTQgWT0wLjc5OTg0NzU0IFo9MC41MDAw MDAwMA0KQXRvbT0gLTU6IFg9MC43NjY4NjIzNCBZPTAuODI5NTQ3NTQgWj0w LjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjc0OTI0OTQzIFk9MC44NDMwNjI0 MCBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAuNzEyMDI0MjMgWT0wLjg2 NzIzNjczIFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6IFg9MC42OTI1MTM5NyBZ PTAuODc3ODI5OTQgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjY1MTk2 NTM3IFk9MC44OTU4ODMzMyBaPTAuNTAwMDAwMDANCkF0b209IC01OiBYPTAu NjMxMDM4MTggWT0wLjkwMzI5NDA0IFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC4zNjg5NjE4MiBZPTAuOTAzMjk0MDQgWj0xLjAwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjMyNzUyMzk2IFk9MC44ODczODc1NCBaPTEuMDAwMDAwMDAN CkF0b209IC01OiBYPTAuMzA3NDg2MDMgWT0wLjg3NzgyOTk0IFo9MC41MDAw MDAwMA0KQXRvbT0gLTU6IFg9MC4yNjkwNDY2NiBZPTAuODU1NjM2OTYgWj0w LjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjI1MDc1MDU3IFk9MC44NDMwNjI0 MCBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAuMjE2MjU2MjAgWT0wLjgx NTEyOTQxIFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6IFg9MC4yMDAxNTI0NiBZ PTAuNzk5ODQ3NTQgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjE3MDQ1 MjQ2IFk9MC43NjY4NjIzNCBaPTAuNTAwMDAwMDANCkF0b209IC01OiBYPTAu MTU2OTM3NjAgWT0wLjc0OTI0OTQzIFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC4xMzI3NjMyNyBZPTAuNzEyMDI0MjMgWj0xLjAwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjEyMjE3MDA2IFk9MC42OTI1MTM5NyBaPTAuNTAwMDAwMDAN CkF0b209IC01OiBYPTAuMTA0MTE2NjcgWT0wLjY1MTk2NTM3IFo9MC41MDAw MDAwMA0KQXRvbT0gLTU6IFg9MC4wOTY3MDU5NiBZPTAuNjMxMDM4MTggWj0x LjAwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjA5NjcwNTk2IFk9MC4zNjg5NjE4 MiBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAuMTEyNjEyNDYgWT0wLjMy NzUyMzk2IFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6IFg9MC4xMjIxNzAwNiBZ PTAuMzA3NDg2MDMgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjE0NDM2 MzA0IFk9MC4yNjkwNDY2NiBaPTAuNTAwMDAwMDANCkF0b209IC01OiBYPTAu MTU2OTM3NjAgWT0wLjI1MDc1MDU3IFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC4xODQ4NzA1OSBZPTAuMjE2MjU2MjAgWj0xLjAwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjIwMDE1MjQ2IFk9MC4yMDAxNTI0NiBaPTAuNTAwMDAwMDAN CkF0b209IC01OiBYPTAuMjMzMTM3NjYgWT0wLjE3MDQ1MjQ2IFo9MC41MDAw MDAwMA0KQXRvbT0gLTU6IFg9MC4yNTA3NTA1NyBZPTAuMTU2OTM3NjAgWj0x LjAwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjI4Nzk3NTc3IFk9MC4xMzI3NjMy NyBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAuMzA3NDg2MDMgWT0wLjEy MjE3MDA2IFo9MC41MDAwMDAwMA0KQXRvbT0gLTU6IFg9MC4zNDgwMzQ2MyBZ PTAuMTA0MTE2NjcgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjM2ODk2 MTgyIFk9MC4wOTY3MDU5NiBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAu NjMxMDM4MTggWT0wLjA5NjcwNTk2IFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC42NzI0NzYwNCBZPTAuMTEyNjEyNDYgWj0xLjAwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjY5MjUxMzk3IFk9MC4xMjIxNzAwNiBaPTAuNTAwMDAwMDAN CkF0b209IC01OiBYPTAuNzMwOTUzMzQgWT0wLjE0NDM2MzA0IFo9MC41MDAw MDAwMA0KQXRvbT0gLTU6IFg9MC43NDkyNDk0MyBZPTAuMTU2OTM3NjAgWj0x LjAwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjc4Mzc0MzgwIFk9MC4xODQ4NzA1 OSBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAuNzk5ODQ3NTQgWT0wLjIw MDE1MjQ2IFo9MC41MDAwMDAwMA0KQXRvbT0gLTU6IFg9MC44Mjk1NDc1NCBZ PTAuMjMzMTM3NjYgWj0wLjUwMDAwMDAwDQpBdG9tPSAtNTogWD0wLjg0MzA2 MjQwIFk9MC4yNTA3NTA1NyBaPTEuMDAwMDAwMDANCkF0b209IC01OiBYPTAu ODY3MjM2NzMgWT0wLjI4Nzk3NTc3IFo9MS4wMDAwMDAwMA0KQXRvbT0gLTU6 IFg9MC44Nzc4Mjk5NCBZPTAuMzA3NDg2MDMgWj0wLjUwMDAwMDAwDQpBdG9t PSAtNTogWD0wLjg5NTg4MzMzIFk9MC4zNDgwMzQ2MyBaPTAuNTAwMDAwMDAN CkF0b209IC01OiBYPTAuOTAzMjk0MDQgWT0wLjM2ODk2MTgyIFo9MS4wMDAw MDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB dG9tPSAtNjogWD0wLjU4ODE2NDYzIFk9MC45MTQ3ODE5OCBaPTEuMDAwMDAw MDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KQXRv bT0gLTY6IFg9MC4wODUyMTgwMiBZPTAuNTg4MTY0NjMgWj0xLjAwMDAwMDAw DQpBdG9tPSAtNjogWD0wLjQxMTgzNTM3IFk9MC4wODUyMTgwMiBaPTEuMDAw MDAwMDANCkF0b209IC02OiBYPTAuOTE0NzgxOTggWT0wLjQxMTgzNTM3IFo9 MS4wMDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAgICAgICAg ICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAg ICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAw MDAwDQpBdG9tPSAtNzogWD0wLjU2NjMzNTc5IFk9MC45MTg4Mjc3MSBaPTAu NTAwMDAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0g OA0KQXRvbT0gLTc6IFg9MC4wODExNzIyOSBZPTAuNTY2MzM1NzkgWj0wLjUw MDAwMDAwDQpBdG9tPSAtNzogWD0wLjQzMzY2NDIxIFk9MC4wODExNzIyOSBa PTAuNTAwMDAwMDANCkF0b209IC03OiBYPTAuOTE4ODI3NzEgWT0wLjQzMzY2 NDIxIFo9MC41MDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAu MDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAg ICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAw MDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAg MS4wMDAwMDAwDQpBdG9tPSAtODogWD0wLjUyMjE5Mjk4IFk9MC45MjM0Njcz MSBaPTAuNTAwMDAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElT UExJVD0gOA0KQXRvbT0gLTg6IFg9MC4wNzY1MzI2OSBZPTAuNTIyMTkyOTgg Wj0wLjUwMDAwMDAwDQpBdG9tPSAtODogWD0wLjQ3NzgwNzAyIFk9MC4wNzY1 MzI2OSBaPTAuNTAwMDAwMDANCkF0b209IC04OiBYPTAuOTIzNDY3MzEgWT0w LjQ3NzgwNzAyIFo9MC41MDAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEg IFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wDQogICAg ICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQogICAwIFNZTU1FVFJZIE9QRVJBVElPTlM6DQo= - --143914132-1156411148-1035895912=:9971-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #40 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #41 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Tuesday, November 5 2002 Volume 2002 : Number 041 ---------------------------------------------------------------------- Date: Tue, 29 Oct 2002 04:55:37 -0800 (PST) From: sayede adlane Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== sayede adlane submitted the following contribution: ==== Hi, get look at : http://agenda.ictp.trieste.it/agenda/current/askArchive.php?categ=a01127&id=a01127s12t10&ifd=10382&down=1&type=lecture_notes following My own experience the compaq alpha machine seems to be very good for clustering. Regards __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 28 Oct 2002 15:37:02 +0100 From: Peer Kruse Subject: [WIEN]: Wien2k on PC: Error in lapw1 ==== Peer Kruse submitted the following contribution: ==== Dear Wien users and developers, I tried to install Wien2k on 2 rather new PC's and get an "Error in lapw1" after a period of about 2 hours. This happens only for a larger number of k points, eg >500, with only 50 it is working fine. I should have Memory in abundance (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the memory is not used (in the first hour of the program at least). The limits are set to core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 32768 cpu time (seconds, -t) unlimited max user processes (-u) 7168 virtual memory (kbytes, -v) unlimited Is this ok? I compiled Wien2k with ifc and pgi, no difference, the same for the precompiled version. I' m running linux redhat 7.3. And it is running with the same parameters/structures on the old and slow and even smaller machines with every kind of architecture (dec, pc, notebook) without problem. Has anyone any experience or further ideas? Thank you Peer Kruse ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 16:49:01 +0100 From: Peer Kruse Subject: [WIEN]: PC: Error in lapw1 ==== Peer Kruse submitted the following contribution: ==== Dear Wien users and developers, I tried to install Wien2k on 2 rather new PC's and get an "Error in lapw1" after a period of about 2 hours. This happens only for a larger number of k points, eg >500, with only 50 it is working fine. I should have Memory in abundance (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the memory is not used (in the first hour of the program at least). The limits are set to core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 32768 cpu time (seconds, -t) unlimited max user processes (-u) 7168 virtual memory (kbytes, -v) unlimited Is this ok? I compiled Wien2k with ifc and pgi, no difference, the same for the precompiled version. I' m running linux redhat 7.3. And it is running with the same parameters/structures on the old and slow and even smaller machines with every kind of architecture (dec, pc, notebook) without problem. Has anyone any experience or further ideas? Thank you Peer Kruse ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 10:23:20 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: generate k mesh using Xcrysden ==== yanming Ma submitted the following contribution: ==== - --0-1334150953-1035915800=:80664 Content-Type: text/plain; charset=us-ascii Dear Christian, Thank you for your reply. I have tried to generate k mesh using 3 or 4 special k point. Also I tried to increase the points between two special k points. But the same error message appears. Any more comments are welcom. Best wishes Yanming Ma koitzsch wrote:try to calculate the bandstructure in two steps, first path connecting three special k-points and second path over the remaining four - but I have to admit I never bothered to figure out, what the error message really means, I just noticed that if you have a lot of special k-points with not so many points in between, it does not work. Best Regards Christian Koitzsch Universite de FribourgDepartement de PhysiqueGroupe FKCH-1700 FribourgSuisse ----- Original Message ----- From: yanming Ma To: wien@zeus.theochem.tuwien.ac.at Sent: Monday, October 28, 2002 11:10 PMSubject: [WIEN]: generate k mesh using Xcrysden Dear wien2k user, I try to use Xcrysden to generate K-mesh along high symmetry direction. My case structure is Cmca symmetry. After I run the Xcrysden, I choose Conventional BZ, other than primitive BZ because my input atomic positions are from conventional settings of international Crystalgraphic table. Then I select 7 special k points, the total k points along whole path is chosen as 60. The default value for ISS shringking factor is 2. Minium and Maxium energy are -1.0 Ry and 1.5 Ry, respectively. However there are only some zero values generated, the error messages in the generated case.klist file is as following. ERROR: IDV*NK to big! Decrease number of k points. I try to decrease K points, but it is useless. I try to use primitive BZ. It works. But in my Cmca Case, I can not use primitive BZ. Can someone help me to solve this problem? I will highly appreciate your help. Yanming Ma Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? HotJobs - Search new jobs daily now - --0-1334150953-1035915800=:80664 Content-Type: text/html; charset=us-ascii

Dear Christian,

Thank you for your reply. I have tried to generate k mesh using 3 or 4 special k point. Also I tried to increase the points between two special k points. But the same error message appears. Any more comments are welcom.

Best wishes

Yanming Ma

 koitzsch <Christian.Koitzsch@unifr.ch> wrote:

try to calculate the bandstructure in two steps, first path connecting three special k-points and second path over the remaining four - but I have to admit I never bothered to figure out, what the error message really means, I just noticed that if you have a lot of special k-points with not so many points in between, it does not work.
 
Best Regards
 
Christian Koitzsch
 
Universite de Fribourg
Departement de Physique
Groupe FK
CH-1700 Fribourg
Suisse
 
----- Original Message -----
From: yanming Ma
Sent: Monday, October 28, 2002 11:10 PM
Subject: [WIEN]: generate k mesh using Xcrysden

Dear wien2k user,

I try to use Xcrysden to generate K-mesh along high symmetry direction. My case structure is Cmca symmetry. After I run the Xcrysden, I choose Conventional BZ, other than primitive BZ because my input atomic positions are from conventional settings of international Crystalgraphic table. Then I select 7 special k points, the total k points along whole path is chosen as 60.  The default value for ISS shringking factor is 2. Minium and Maxium energy are  -1.0 Ry and 1.5 Ry, respectively.  However there are only some zero values generated, the error messages in the generated case.klist file is as following.

ERROR: IDV*NK to big! Decrease number of k points.

I try to decrease K points, but it is useless.

I try to use primitive BZ. It works. But in my Cmca Case, I can not use primitive BZ.

Can someone help me to solve this problem? I will highly appreciate your help.

Yanming Ma

 



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site


Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
HotJobs - Search new jobs daily now - --0-1334150953-1035915800=:80664-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 20:05:17 +0100 From: "koitzsch" Subject: Re: [WIEN]: generate k mesh using Xcrysden ==== "koitzsch" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_02D2_01C27F86.808350F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable if you want you can send me your struct file and I try it with our = version.=20 Bye Christian ----- Original Message -----=20 From: yanming Ma=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Tuesday, October 29, 2002 7:23 PM Subject: Re: [WIEN]: generate k mesh using Xcrysden Dear Christian,=20 Thank you for your reply. I have tried to generate k mesh using 3 or 4 = special k point. Also I tried to increase the points between two special = k points. But the same error message appears. Any more comments are = welcom.=20 Best wishes=20 Yanming Ma=20 koitzsch wrote:=20 try to calculate the bandstructure in two steps, first path = connecting three special k-points and second path over the remaining = four - but I have to admit I never bothered to figure out, what the = error message really means, I just noticed that if you have a lot of = special k-points with not so many points in between, it does not work. Best Regards=20 Christian Koitzsch Universite de Fribourg Departement de Physique Groupe FK CH-1700 Fribourg Suisse ----- Original Message -----=20 From: yanming Ma=20 To: wien@zeus.theochem.tuwien.ac.at=20 Sent: Monday, October 28, 2002 11:10 PM Subject: [WIEN]: generate k mesh using Xcrysden Dear wien2k user, I try to use Xcrysden to generate K-mesh along high symmetry = direction. My case structure is Cmca symmetry. After I run the Xcrysden, = I choose Conventional BZ, other than primitive BZ because my input = atomic positions are from conventional settings of international = Crystalgraphic table. Then I select 7 special k points, the total k = points along whole path is chosen as 60. The default value for ISS = shringking factor is 2. Minium and Maxium energy are -1.0 Ry and 1.5 = Ry, respectively. However there are only some zero values generated, = the error messages in the generated case.klist file is as following. ERROR: IDV*NK to big! Decrease number of k points. I try to decrease K points, but it is useless.=20 I try to use primitive BZ. It works. But in my Cmca Case, I can = not use primitive BZ.=20 Can someone help me to solve this problem? I will highly = appreciate your help. Yanming Ma Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada=20 - -------------------------------------------------------------------------= - - Do you Yahoo!? Y! Web Hosting - Let the expert host your web site Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - -------------------------------------------------------------------------= - ----- Do you Yahoo!? HotJobs - Search new jobs daily now - ------=_NextPart_000_02D2_01C27F86.808350F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
if you want you can send me your struct = file and I=20 try it with our version.
 
Bye
 
Christian
 
 
----- Original Message -----
From:=20 yanming = Ma
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Tuesday, October 29, 2002 = 7:23=20 PM
Subject: Re: [WIEN]: generate k = mesh=20 using Xcrysden

Dear Christian,=20

Thank you for your reply. I have tried to generate k mesh using 3 = or 4=20 special k point. Also I tried to increase the points between two = special=20 k points. But the same error message appears. Any more comments = are=20 welcom.=20

Best wishes=20

Yanming Ma=20

 koitzsch <Christian.Koitzsch@unifr.ch>=20 wrote:=20

try to calculate the bandstructure = in two=20 steps, first path connecting three special k-points and = second=20 path over the remaining four - but I have to admit I never bothered = to=20 figure out, what the error message really means, I just noticed that = if you=20 have a lot of special k-points with not so many points in between, = it does=20 not work.
 
Best Regards
 
Christian Koitzsch
 
Universite de Fribourg
Departement de = Physique
Groupe FK
CH-1700 Fribourg
Suisse
 
----- Original Message ----- =
From:=20 yanming Ma=20
To: wien@zeus.theochem.tuwien= .ac.at=20
Sent: Monday, October 28, = 2002 11:10=20 PM
Subject: [WIEN]: generate k = mesh=20 using Xcrysden

Dear wien2k user,

I try to use Xcrysden to generate K-mesh along high symmetry = direction.=20 My case structure is Cmca symmetry. After I run the Xcrysden, I = choose=20 Conventional BZ, other than primitive BZ because my input atomic = positions=20 are from conventional settings of international Crystalgraphic = table. Then=20 I select 7 special k points, the total k points along whole path = is chosen=20 as 60.  The default value for ISS shringking factor is 2. = Minium and=20 Maxium energy are  -1.0 Ry and 1.5 Ry, = respectively. =20 However there are only some zero values generated, the = error=20 messages in the generated case.klist file is as = following.

ERROR: IDV*NK to big! Decrease number of k points.

I try to decrease K points, but it is useless.

I try to use primitive BZ. It works. But in my Cmca Case, = I can=20 not use primitive BZ.

Can someone help me to solve this problem? I will highly = appreciate=20 your help.

Yanming Ma

 



Yanming Ma Ph.D
Steacie Institute for = Molecular=20 Sciences,
National Research Councils of Canada,
Ottawa,=20 Ontario
K1A 0R6
Canada=20


Do you Yahoo!?
Y! Web=20 Hosting - Let the expert host your web=20 site

Yanming Ma Ph.D
Steacie = Institute for=20 Molecular Sciences,
National Research Councils of = Canada,
Ottawa,=20 Ontario
K1A 0R6
Canada


Do you Yahoo!?
HotJobs=20 - Search new jobs daily now - ------=_NextPart_000_02D2_01C27F86.808350F0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 29 Oct 2002 22:39:46 -0600 (CST) From: Bing Zhou Subject: [WIEN]: "x lapw2" error ==== Bing Zhou submitted the following contribution: ==== Dear All: After the convergence of the SCF cycles, I changed the "TOT" to "EFG" in case.in2 file, and run "x lapw2" but failed with the following information: STOP: L2main - Error 0.0u 0.0s 0:02 0% 0+0k 0+0io 0pf+0w The lapw2.error file is as the following line: 'l2main' - NEFG.GT.23. Could you please let me how to fix it? Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 10:39:55 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: "x lapw2" error ==== "Saeid Jalali" submitted the following contribution: ==== > After the convergence of the SCF cycles, I changed the "TOT" to "EFG" in > case.in2 file, and run "x lapw2" but failed with the following > information: > > STOP: L2main - Error > 0.0u 0.0s 0:02 0% 0+0k 0+0io 0pf+0w > > The lapw2.error file is as the following line: > > 'l2main' - NEFG.GT.23. > > Could you please let me how to fix it? Have you changed manually LM combinations in your case.in2 file? I asked this because the error occurs due to the following restriction: RHOEFG(NRAD,3,23), LEFG(3,3,23), MEFG(3,3,23), where 23 is the maximum of NEFG(LQ), and LQ can be 1, 2, or 3 depending on some condition(s) on quantum numbers. So, if NEFG >23, then one encounters the 'l2main','NEFG.GT.23.' message. It appears max. of NEFG is limited to 23 because of a physical restriction on EFG (L=2, M=0). This means that it is not just a dummy variable. If this is true, then most likely the point groups of your atoms are not consistent with your LM combinations. If you have not changed LM combinations manually, then I think (this is just a guess) the 23 in l2main.F can be increased, at least to see what is going on. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 08:26:28 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: "x lapw2" error ==== Peter Blaha submitted the following contribution: ==== > > After the convergence of the SCF cycles, I changed the "TOT" to "EFG" in > > case.in2 file, and run "x lapw2" but failed with the following > > information: > > > > STOP: L2main - Error > > 0.0u 0.0s 0:02 0% 0+0k 0+0io 0pf+0w > > > > The lapw2.error file is as the following line: > > > > 'l2main' - NEFG.GT.23. > > > > Could you please let me how to fix it? > > Have you changed manually LM combinations in your case.in2 file? I asked > this because the error occurs due to the following restriction: In fact in a low symmetry case, where you have all possible L=2 combinations (case.in2), the possible contributions to the EFG might be more than 23, which is a hardcoded limit. To overcome this, modify your LM list and run x lapw2 twice, once only with LM=0 and e.g. 2 0,2 2, -2 2 combinations, then with 0 0 and 2 1 and -2 1. PS: for low symmetry the analysis is usually less meaningfull, nevertheless you may find out about the importance of p or d states. See the very good faq page provided by S.Cottenier (www.wien2k.at/reg_users) 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 08:46:11 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== Peter Blaha submitted the following contribution: ==== Some benchmark results of lapw1 (large matrices): Supermicro (dual Xeon 2.4 GHz, 2GB) ifc/mkl/omp=1: 5m54.817s ifc/mkl: 4m50.678s ifc/mkl/ht 5m42.164s - ----------------------------------------------------------------- Compaq ES45 (Alpha ev7, 1GHz, 16GB) 1 job: - ------------------------------------------------------------------ f90/cxml 6m29.61s 6m27.55s 0m1.68s - ------------------------------------------------------------------ 2 jobs: - ------------------------------------------------------------------ f90/cxml 6m55.68s 6m53.51s 0m1.76s - ------------------------------------------------------------------ IBM SP (PowerIII-2, 375 MHz, 16GB) 1 job: - ------------------------------------------------------------------ xlf90/essl 10m26.15s 10m20.93s 0m3.40s - ------------------------------------------------------------------ So the PC-based solutions outperform even a quite new Compaq EV7 (1 GHz). To my knowledge the fastest Itaniums and IBM Power-IV might be a little faster than fast P-IV (but only some percentage, not really big factors!!), but compare the price: A four processor EV7 costs 80.000 Euro, two dual Xeon machines 10.000 !!! 4 "normal" P-IV PCs 8.000. Either look for a new dual Xeon (with a new motherboard with two memory buses so that memory-access is not such a problem) or simply buy the cheapest P-IV single cpu machines (~2.4 GHz) with RAMBUS (faster) or 533 MHz bus (slower but cheaper). In addition one must thing for which systems you want to apply those machines. If you really need 16 Gb memory and fast communication (only one k-point), your P4-cluster must have at least a Gbit network (and still you may loose a lot of performance because of communication agains an e.g. EV7). However, for 99% of the applications a P4-cluster is certainly the best solution. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 09:02:56 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Question about symmetry operator ==== Peter Blaha submitted the following contribution: ==== > My case.struct file is attached with this mail. Your struct file violates almost everything: Atom= -1: X=0.92404845 Y=0.50000000 Z=1.00000000 All positions must be between 0 and .lt. 1 !!! (put z=0) Atom= -5: X=0.90329404 Y=0.63103818 Z=1.00000000 MULT=52 ISPLIT= 8 A multiplicity of 52 is not possible!! (The spacegroup symmetries limit the multiplicity to 48) Provided you entered correct positions (which I cannot check) sgroup provides a new struct file with 20 independent positions. Why did you not take it ? warning: !!! Number of inequivalent atoms has changed. !!! Old value= 8 New value= 20 warning: !!! Wrong multiplicity for atom 5 !!! Struct file is not consistent with space group found. nn can do the same, provided you "label" your atoms "C 1", C 2,.... Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 11:58:02 +0100 (CET) From: Max Winkelmann Subject: [WIEN]: Compiling WIEN2k ==== Max Winkelmann submitted the following contribution: ==== Hi I have a problem when compiling WIEN2k. Starting ./siteconfig_lapw and then recompiling (r) I get the error "undefined reference to 'getarg_' ". I'm using the intel ifc-compiler for linux-PCs. I know already that I have to implement the portability library. The library is in my library-path and I used the compiler-option "-Vaxlib". So referring to the manuals everything should be fine. Anyone any idea? Greetings Max Winkelmann ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 15:15:53 +0100 From: Thomas Claesson Subject: [WIEN]: Adapting files to run with -so ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am working on a case where I would like to add spin-orbit coupling, since this according to the userguide can reduce problems with charge oscillations caused by LDA+U. When I run the initso_lapw script I get this information: Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y FORTRAN STOP 2.370u 0.060s 0:02.98 81.5% 0+0k 0+0io 213pf+0w A new structure for SO calculations has been created (_so). If you commit it will create new Nio.struct, in1(c), in2c, inc, clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous calculations) NOTE: Files for -orb (Nio.indm(c),inorb,dmatup/dn) must be adapted manually My question concerns the last sentence. How should I adapt the files for - -orb? What changes must I do to the files I have been using before I added SO coupling? Thanks for your replies! Any suggestions are welcome! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 15:30:13 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Adapting files to run with -so ==== Peter Blaha submitted the following contribution: ==== > I am working on a case where I would like to add spin-orbit coupling, > since this according to the userguide can reduce problems with charge > oscillations caused by LDA+U. When I run the initso_lapw script I get If you have problems with LDA+U convergence for NiO, you will also have these problems when adding SO. NiO converges reasonably quick using LDA+U starting from a scf LDA (GGA) calculation. You do something wrong there! The recommended sequence would be: runsp save_lapw create inorb and indm-files x lapwdm -up/dn (to have a case.dmatup/dn file already in the first cycle) runsp -orb > Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y > FORTRAN STOP > 2.370u 0.060s 0:02.98 81.5% 0+0k 0+0io 213pf+0w > A new structure for SO calculations has been created (_so). > If you commit it will create new Nio.struct, in1(c), in2c, inc, > clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous > calculations) > > NOTE: Files for -orb (Nio.indm(c),inorb,dmatup/dn) must be adapted manually > > My question concerns the last sentence. How should I adapt the files for > -orb? What changes must I do to the files I have been using before I > added SO coupling? This depends on your case. For NiO probably nothing (exept that you need a case.indmc file instead of case.indm when SO is used) In other cases, atomic positions could split creating a new struct file (with more atoms) and then you must update those files. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 17:45:52 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Compiling WIEN2k ==== Peter Blaha submitted the following contribution: ==== > I have a problem when compiling WIEN2k. Starting ./siteconfig_lapw and > then recompiling (r) I get the error "undefined reference to 'getarg_' ". > I'm using the intel ifc-compiler for linux-PCs. I know already that I have > to implement the portability library. The library is in my library-path > and I used the compiler-option "-Vaxlib". So referring to the manuals > everything should be fine. Anyone any idea? Did you use the default options of the latest WIEN2k-release ? (Maybe download again). Just from your comments above: -Vaxlib must be in the loaderflags, not in the FOPT compiler options: LDFLAGS = -L../SRC_lib -Vaxlib -static -L/opt/intel/mkl/lib/32 Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 13:55:49 CST From: Yongbin Lee Subject: [WIEN]: SRC_lapw2/outp.f ==== Yongbin Lee submitted the following contribution: ==== Dear WIEN_user I got an error by x lapw2 -c -up -so -qtl -p The error was Input/Output Error 153: Input file ended In Procedure: outp At Line: 245 Statement: Formatted READ Unit: 12 Connected To: TEST.normsoup Form: Formatted Access: Sequential Records Read : 0 Records Written: 0 End of diagnostics It came from SRC_lapw2/outp.f ! Read norm file in spinpol. so case if(kso.eq.2.and.nspin1.eq.2) then rewind 12 allocate (sonorm(nbandmax,nk)) DO JK=1,NK read(12,'(4e20.11)') (sonorm(jb,jk), JB=1,NB(JK)) write(6,*) 'jk',jk write(6,'(4e20.11)') (sonorm(jb,jk), JB=1,NB(JK)) enddo endif ! The problem is I got "TEST.normsoup_*" files with the "empty TEST.normsoup " file by parallel calculation. I guess this routine is just for single processor job. What is this routine for? What do I need to do? Sincerely Yongbin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 14:29:31 -0800 (PST) From: Wenqing ZHANG Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== Wenqing ZHANG submitted the following contribution: ==== Peter, What do you mean by "Xeon machine"? Is it just a "supermicro" PC with P-IV-Xeon CPU (2.4GHZ, 1GB/CPU memory)? Where did you buy the machine? I noticed there is a type of server using P-IV-Xeon CPU from Dell company, named PowerEdge 8450 or so. That is very expensive. Any comment about that machine? Yours -- Wenqing > > A four processor EV7 costs 80.000 Euro, two dual > Xeon machines 10.000 !!! > 4 "normal" P-IV PCs 8.000. > > > Some benchmark results of lapw1 (large matrices): > > Supermicro (dual Xeon 2.4 GHz, 2GB) > ifc/mkl/omp=1: 5m54.817s > > ifc/mkl: 4m50.678s > ifc/mkl/ht 5m42.164s > ===== Wenqing ZHANG 1970 Crystal Lake Dr. Apt#E79 Shelby Twp., MI 48316 Tel: (810)254-9931(h), (810)323-1551(o) Fax: (810)323-9898 __________________________________________________ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 30 Oct 2002 20:19:08 -0600 (CST) From: Bing Zhou Subject: [WIEN]: "x lapw2" error ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1036030748=:22886 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Saeid and Peter: Thank you for your help, I appreciate that! Yes, my sample is a monolinic symmetry mineral, and I tried to change the LM combinations in case.in2 and run "x lapw2", the results were same as before. I don't understand what it meant either by "l2main.F" in Saeid email. So I attach the case.in2 file with this email, could you please take a look and give me more instructions about how to run "lapw2" for EFG analysis? Thank you in adavance! On Wed, 30 Oct 2002, Saeid Jalali wrote: > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > After the convergence of the SCF cycles, I changed the "TOT" to "EFG" in > > case.in2 file, and run "x lapw2" but failed with the following > > information: > > > > STOP: L2main - Error > > 0.0u 0.0s 0:02 0% 0+0k 0+0io 0pf+0w > > > > The lapw2.error file is as the following line: > > > > 'l2main' - NEFG.GT.23. > > > > Could you please let me how to fix it? > > Have you changed manually LM combinations in your case.in2 file? I asked > this because the error occurs due to the following restriction: > > RHOEFG(NRAD,3,23), LEFG(3,3,23), MEFG(3,3,23), where 23 is the maximum of > NEFG(LQ), and LQ can be 1, 2, or 3 depending on some condition(s) on quantum > numbers. > > So, if NEFG >23, then one encounters the 'l2main','NEFG.GT.23.' message. > > It appears max. of NEFG is limited to 23 because of a physical restriction > on EFG (L=2, M=0). This means that it is not just a dummy variable. If this > is true, then most likely the point groups of your atoms are not consistent > with your LM combinations. If you have not changed LM combinations manually, > then I think (this is just a guess) the 23 in l2main.F can be increased, at > least to see what is going on. > > Your, > Saeid. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 - ---559023410-851401618-1036030748=:22886 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="cryolite-new1.in2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="cryolite-new1.in2" RUZHICAgICAgICAgICAgIChUT1QsRk9SLFFUTCxFRkcsRkVSTUkpDQogICAg ICAtOS4wICAgICAxNTYuMCAwLjUwIDAuMDUgICAgICAgICAgICAgICAgRU1J TiwgTkUsIEVTRVBFUk1JTiwgRVNFUEVSMA0KVEVUUkEgICAgMC4wMDAgICAg ICAgICAgKEdBVVNTLFJPT1QsVEVNUCxURVRSQSxBTEwgICAgICBldmFsKQ0K IDAgMCAyIDAgMiAxLTIgMSAyIDItMiAyIDQgMCA0IDEtNCAxIDQgMi00IDIg NCAzLTQgMyA0IDQtNCA0IDYgMCA2IDEtNiAxIDYgMi02IDIgNiAzLTYgMyA2 IDQtNiA0IDYgNS02IDUgNiA2LTYgNg0KIDAgMCAyIDAgMiAxLTIgMSAyIDIt MiAyIDQgMCA0IDEtNCAxIDQgMi00IDIgNCAzLTQgMyA0IDQtNCA0IDYgMCA2 IDEtNiAxIDYgMi02IDIgNiAzLTYgMyA2IDQtNiA0IDYgNS02IDUgNiA2LTYg Ng0KIDAgMCAxIDAgMSAxLTEgMSAyIDAgMiAxLTIgMSAyIDItMiAyIDMgMCAz IDEtMyAxIDMgMi0zIDIgMyAzLTMgMyA0IDAgNCAxLTQgMSA0IDItNCAyIDQg My00IDMgNCA0LTQgNCA1IDAgNSAxLTUgMSA1IDItNSAyIDUgMy01IDMgNSA0 LTUgNCA1IDUtNSA1IDYgMCA2IDEtNiAxIDYgMi02IDIgNiAzLTYgMyA2IDQt NiA0IDYgNS02IDUgNiA2LTYgNg0KIDAgMCAxIDAgMSAxLTEgMSAyIDAgMiAx LTIgMSAyIDItMiAyIDMgMCAzIDEtMyAxIDMgMi0zIDIgMyAzLTMgMyA0IDAg NCAxLTQgMSA0IDItNCAyIDQgMy00IDMgNCA0LTQgNCA1IDAgNSAxLTUgMSA1 IDItNSAyIDUgMy01IDMgNSA0LTUgNCA1IDUtNSA1IDYgMCA2IDEtNiAxIDYg Mi02IDIgNiAzLTYgMyA2IDQtNiA0IDYgNS02IDUgNiA2LTYgNg0KIDAgMCAx IDAgMSAxLTEgMSAyIDAgMiAxLTIgMSAyIDItMiAyIDMgMCAzIDEtMyAxIDMg Mi0zIDIgMyAzLTMgMyA0IDAgNCAxLTQgMSA0IDItNCAyIDQgMy00IDMgNCA0 LTQgNCA1IDAgNSAxLTUgMSA1IDItNSAyIDUgMy01IDMgNSA0LTUgNCA1IDUt NSA1IDYgMCA2IDEtNiAxIDYgMi02IDIgNiAzLTYgMyA2IDQtNiA0IDYgNS02 IDUgNiA2LTYgNg0KIDAgMCAxIDAgMSAxLTEgMSAyIDAgMiAxLTIgMSAyIDIt MiAyIDMgMCAzIDEtMyAxIDMgMi0zIDIgMyAzLTMgMyA0IDAgNCAxLTQgMSA0 IDItNCAyIDQgMy00IDMgNCA0LTQgNCA1IDAgNSAxLTUgMSA1IDItNSAyIDUg My01IDMgNSA0LTUgNCA1IDUtNSA1IDYgMCA2IDEtNiAxIDYgMi02IDIgNiAz LTYgMyA2IDQtNiA0IDYgNS02IDUgNiA2LTYgNg0KIDE0LiAgICAgICAgICBH TUFYDQpGSUxFICAgICAgICBGSUxFL05PRklMRSAgd3JpdGUgcmVjcHJsaXN0 DQo= - ---559023410-851401618-1036030748=:22886-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 09:03:38 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: "x lapw2" error ==== "Saeid Jalali" submitted the following contribution: ==== > Yes, my sample is a monolinic symmetry mineral, and I tried to change the > LM combinations in case.in2 and run "x lapw2", the results were same as > before. I don't understand what it meant either by "l2main.F" in Saeid > email. So I attach the case.in2 file with this email, could you please > take a look and give me more instructions about how to run "lapw2" for EFG > analysis? Counting no. of LM combinations written in the sent case.in2 show that NEFG is 23 for the first point group of your case possessing 2 atoms -- that is okay -- but NEFG>23 for the second point group possessing 4 atoms, which contravenes the condition exceeding Max(NEFG)=23. The author nicely recommended that: "To overcome this, modify your LM list and run x lapw2 twice, once only with LM=0 and e.g. 2 0,2 2, -2 2 combinations, then with 0 0 and 2 1 and -2 1." And this is a task for us to realize how to use this way (idea). Breaking the following LM's 0 0 1 0 1 1-1 1 2 0 2 1-2 1 2 2-2 2 3 0 3 1-3 1 3 2-3 2 3 3-3 3 4 0 4 1-4 1 4 2-4 2 4 3-4 3 4 4-4 4 5 0 5 1-5 1 5 2-5 2 5 3-5 3 5 4-5 4 5 5-5 5 6 0 6 1-6 1 6 2-6 2 6 3-6 3 6 4-6 4 6 5-6 5 6 6-6 6 TO 0 0 1 0 2 0 2 2-2 2 3 0 3 2-3 2 4 0 4 2-4 2 4 4-4 4 5 0 5 2-5 2 5 4-5 4 6 0 6 2-6 2 6 4-6 4 6 6-6 6 AND 0 0 1 1-1 1 2 1-2 1 3 1-3 1 3 3-3 3 4 1-4 1 4 3-4 3 5 1-5 1 5 3-5 3 5 5-5 5 6 1-6 1 6 3-6 3 6 5-6 5 holds the condition on NEFG. Then one runs lapw2 distinctly for each set (please check the breaking to see if I did miss some LM's). Please notice that the condition on NEFG is checked once one turns the light of EFG on, so one does not need to break the LM's in a regular SCF. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 07:15:20 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== Torsten Andersen submitted the following contribution: ==== Wenqing, he means a machine with P-IV-Xeon CPU's, yes. Any one... and Supermicro refers to the motherboard. what you do is... go down to a local computer store and specify what you want (bamboo PC with dual P-IV-Xeon, or with single P-IV) and get a ton of them. Buy some switches and connect them. Put Linux on them, and you have a many-processor Linux cluster. The system administration is of course heavier than using the money on "big iron" but if your needs are related mostly to the Wien code, it might be the better option. Alternatively, take a 19" rack with 1U PC enclosures, buy the motherboards, RAM, CPU's and disks needed. Using a dual-processor (with angled RAM sockets to keep it inside a 1U box) motherboard, you get about 80 CPU's in a standard 42U cabinet + the network switch. However, stay below 4GB RAM in each Xeon machine for performance reasons. You might also have a look at "blade" servers, but I am not sure they come with P-IV based CPU's yet. They will give you the highest possible density of CPU's (working CPU's per cubic foot), if space is an issue. If space, power, and cooling are non-issues, the cheapest option is to go for standard P-IV's with SDRAM - I think there are some VIA-based motherboards that support SDRAM in a dual bank configuration - they are almost as fast as a single-bank DDR or RDRAM. Always take the ones with integrated graphics and network, unless you need huge calculations for a single k-point - then take "big iron" like Compaq ES-45 or IBM p630. Gbit ethernet is too expensive compared to what you get out of it with PC's, imho. Best regards, Torsten. Wenqing ZHANG wrote: >==== >Wenqing ZHANG >submitted the following contribution: >==== > > >Peter, > >What do you mean by "Xeon machine"? Is it just a >"supermicro" PC with P-IV-Xeon CPU (2.4GHZ, 1GB/CPU >memory)? Where did you buy the machine? > >I noticed there is a type of server using P-IV-Xeon >CPU from Dell company, named PowerEdge 8450 or so. >That is very expensive. Any comment about that >machine? > >Yours -- Wenqing > > >>A four processor EV7 costs 80.000 Euro, two dual >>Xeon machines 10.000 !!! >>4 "normal" P-IV PCs 8.000. >> >> >>Some benchmark results of lapw1 (large matrices): >> >>Supermicro (dual Xeon 2.4 GHz, 2GB) >>ifc/mkl/omp=1: 5m54.817s >> >>ifc/mkl: 4m50.678s >>ifc/mkl/ht 5m42.164s >> >> > > >===== >Wenqing ZHANG >1970 Crystal Lake Dr. Apt#E79 >Shelby Twp., MI 48316 >Tel: (810)254-9931(h), (810)323-1551(o) >Fax: (810)323-9898 > >__________________________________________________ >Yahoo! - We Remember >9-11: A tribute to the more than 3,000 lives lost >http://dir.remember.yahoo.com/tribute >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 09:10:39 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: SRC_lapw2/outp.f ==== Peter Blaha submitted the following contribution: ==== > I got an error by > x lapw2 -c -up -so -qtl -p > The error was > > Input/Output Error 153: Input file ended > > In Procedure: outp > At Line: 245 > > Statement: Formatted READ > Unit: 12 > Connected To: TEST.normsoup > > The problem is I got "TEST.normsoup_*" files with the > "empty TEST.normsoup " file by parallel calculation. > I guess this routine is just for single processor job. > What is this routine for? > What do I need to do? Thanks for this report. I added recently these normsoup/dn files, since this is needed to calculate the spin-up/dn projected DOS when SO is included. (So far you would always get the total DOS (spin up+dn) when SO is included, even when running x tetra -up) Of course I forgot to support parallel calculations. Please try simply: cat TEST.normsoup_1 TEST.normsoup_2 TEST.normsoup_3 ... > TEST.normsoup And test the up and dn-spin DOS (it should look similar to the non-SO DOS). If this works I will put it into the lapwso_para script. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 10:04:46 +0100 From: Thomas Claesson Subject: [WIEN]: Input for AFM calculations ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! In section 4.5.4 about input for AFM calculations it says, among other things, that you must do this: Edit case.inst and flip the spin of one of the AF atoms (i.e. invert the spin up and dn occupation numbers). In addition you must set a zero moment (identical spin up and dn oc-cupations) for all non-magnetic atoms, otherwise AFMINPUT cannot determine the proper input for CLMCOPY. My questions is, should you do these two modifications to the case.inst file even if you choose to not use AFMINPUT and runafm_lapw? Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 01:17:37 -0800 (PST) From: sayede adlane Subject: Re: [WIEN]: Pentinum IV cluster workstation ==== sayede adlane submitted the following contribution: ==== >I noticed there is a type of server using P-IV-Xeon >CPU from Dell company, named PowerEdge 8450 or so. >That is very expensive. Any comment about that >machine? This machine as you noticed is a server not realy a worksation, it is very expensive because its integrated a RED, hotplug disk storage etc .... And you dont need all thoes things to do Parallel caclulation. Regrads A. Sayede __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 10:24:54 +0100 From: "Stefaan Cottenier" Subject: Re: [WIEN]: Input for AFM calculations ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > Thomas Claesson > submitted the following contribution: > ==== > > In section 4.5.4 about input for AFM calculations it says, among other > things, that you must do this: > > Edit case.inst and flip the spin of one of the AF atoms (i.e. invert the > spin up and dn occupation numbers). In addition you must set a zero > moment (identical spin up and dn oc-cupations) for all non-magnetic > atoms, otherwise AFMINPUT cannot determine the proper input for CLMCOPY. > > My questions is, should you do these two modifications to the case.inst > file even if you choose to not use AFMINPUT and runafm_lapw? Even if you don't use runafm_lapw, you at least need to flip one of the moments, such that you start from an AF configuration. WIEN will never spontaneously find an AF solution if you start from a ferro or nonmagnetic one. Using runafm_lapw is equivalent to this, only it saves you one half of the time. Putting a zero moment on nonmagnetic atoms is less crucial if you don't use runafm, I think. Nevertheless, you avoid bias by starting from zero moments. Imagine that the AF atoms induce some positive or negative moment on a neighbouring atom. If you have made the moment positive at the beginning and the real solution is a negative moment, it could take longer to converge or in the worst case you might get trapped in solution with a positive moment which is not the ground state. If you don't have a specific reason to start with a moment on the non-magnetic atoms, then it seems safer to make it zero. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 13:22:29 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Adapting files to run with -so ==== "Yue Hai" submitted the following contribution: ==== Dear Peter: After reading your mail,I have some general questions about the sequence of runsp with SO or (and)ORB, I hope can get your help or advice. 1 : when runsp+SO , is there any difference between the two kinds of sequences list below: a: init_lapw initso_lapw-->accept the files it generated runsp_lapw -so b:the methods recommanded in the UG: run[sp]_lapw ---> after convergence, then save_lapw initso_lapw run[sp]_lapw -so 2:when runsp+ORB, is there any difference between the two kinds of sequences list below: a:init_lapw edit case.indm(c),inorb by hand runsp_lapw -orb b:the method in your mail: runsp save_lapw create inorb and indm-files x lapwdm -up/dn (to have a case.dmatup/dn file already in the first cycle) runsp -orb 3: runsp+SO+ORB, is the sequence listed below is right? init_lapw initso_lapw -->accept the struct files it generated edit case.indmc , case.inorb by hand runsp_lapw -so -orb is there any different sequence? If It also need to first runsp_lapw to achieve convergence, then save the result(like mentioned above), then runsp_lapw -so -orb? Thanks Yours Hai >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: WIEN >Subject: Re: [WIEN]: Adapting files to run with -so >Date: Wed, 30 Oct 2002 15:30:13 +0100 (MET) > >==== >Peter Blaha >submitted the following contribution: >==== > > > I am working on a case where I would like to add spin-orbit coupling, > > since this according to the userguide can reduce problems with charge > > oscillations caused by LDA+U. When I run the initso_lapw script I get > >If you have problems with LDA+U convergence for NiO, you will also have >these problems when adding SO. NiO converges reasonably quick using LDA+U >starting from a scf LDA (GGA) calculation. > >You do something wrong there! > >The recommended sequence would be: > >runsp >save_lapw >create inorb and indm-files >x lapwdm -up/dn (to have a case.dmatup/dn file already in the first cycle) >runsp -orb > > _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 15:40:00 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Adapting files to run with -so ==== Peter Blaha submitted the following contribution: ==== > After reading your mail,I have some general questions about the sequence > of runsp with SO or (and)ORB, I hope can get your help or advice. One cannot make general statements about these questions. It depends on your system which method is the proper one. You must know the physics and decide wether SO and/or orbital fields should be small corrections or big effects!!! In general it is true, that already for spinpolarized calculations without SO or orb.fields several scf solutions COULD occur (NOT WILL). It is even more true when SO and/or orbital fields are included. In particular, scf solution with orbital potentials depend often (NOT ALWAYS) on the starting density (i.e. an orbital A which is less populated then orbital B will usually be even less populated when -orb is added. So when you start the scf cycle with two densites, one with more A and the other with more B, there are good chances that you end up with two different scf solutions - check E-tot) > 1 : when runsp+SO , is there any difference between the two kinds of > sequences list below: > > a: init_lapw > initso_lapw-->accept the files it generated > runsp_lapw -so > > b:the methods recommanded in the UG: > run[sp]_lapw ---> > after convergence, then save_lapw > initso_lapw > run[sp]_lapw -so I would always do b) (maybe just because I also want to see the differences between so and no so). > 2:when runsp+ORB, is there any difference between the two kinds of > sequences list below: > > a:init_lapw > edit case.indm(c),inorb by hand > runsp_lapw -orb > > b:the method in your mail: > runsp > save_lapw > create inorb and indm-files > x lapwdm -up/dn (to have a case.dmatup/dn file already in the first > cycle) > runsp -orb Again I would always do b). One can "hope", that LDA (better GGA) produces at least the correct sequence of occupations, i.e. occupy orbital A slightly more than B (e.g. 0.45 and 0.41), when the "correct" occupation including orb is 0.8 and 0.06. > 3: runsp+SO+ORB, is the sequence listed below is right? > > init_lapw > initso_lapw -->accept the struct files it generated > edit case.indmc , case.inorb by hand > runsp_lapw -so -orb > > is there any different sequence? If It also need to first runsp_lapw to > achieve convergence, then save the result(like mentioned above), then > runsp_lapw -so -orb? Here the answer is most difficult. It depends a lot on the system and which effects are dominating, wether it is metallic or should be an insulator (but maybe is not in LDA,...). For 3d elements, where SO is usually the "smallest" correction, I would most likely do: init runsp runsp -orb runsp -orb -so For 5f, where SO is very important, maybe one adds first SO and then -orb Unfortunately for this advanced topic there is no black box solution. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 15:16:00 -0500 (EST) From: "G. Steinle-Neumann" Subject: [WIEN]: [WIEN] orbital moments (s-o) ==== "G. Steinle-Neumann" submitted the following contribution: ==== Dear all, performing s-o calculations for a magnetic system I can't find the orbital moments in any of the ouptut. Two questions: (1) Is it there, and am I missing it? (2) If not, where are they calculated, so I could get them output? Many thanks, Gerd. - -- Gerd Steinle-Neumann Geophysical Laboratory * 5251 Broad Branch Rd., NW * Washington, DC 20015 phone +1-202-478-8943 * fax +1-202-478-8901 * g.steinle-neumann@gl.ciw.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 31 Oct 2002 21:26:38 +0100 From: Andres Cantarero Subject: [WIEN]: question concerning parallel options?? ==== Andres Cantarero submitted the following contribution: ==== I installed the Wien2k version in a SGI. When I run the program it starts running several lapw1 processes in the same processor (iterative execution). Does anybody know how to eliminate this problem? Thanks in advance. Andres Cantarero ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 02:56:41 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Adapting files to run with -so ==== "Yue Hai" submitted the following contribution: ==== Dear Peter: Thank your instructive email,I think I have partly understood your meanning. That is to say, before add SO or(and)ORB, runsp_lapw first can creat at least qualitatively "correct" inintial configuration(especially for when ORB will be included),Is it right? . And I want to know , when I first runsp_lapw , is it necessary to convergence or just some cycles,like 20 or 40 ,and so on? >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: Adapting files to run with -so >Date: Thu, 31 Oct 2002 15:40:00 +0100 (MET) > >==== >Peter Blaha >submitted the following contribution: >==== > > > After reading your mail,I have some general questions about the sequence > > of runsp with SO or (and)ORB, I hope can get your help or advice. > >One cannot make general statements about these questions. It depends on >your system which method is the proper one. You must know the physics and >decide wether SO and/or orbital fields should be small corrections or big >effects!!! > >In general it is true, that already for spinpolarized calculations without >SO or orb.fields several scf solutions COULD occur (NOT WILL). > >It is even more true when SO and/or orbital fields are included. > >In particular, scf solution with orbital potentials depend often (NOT ALWAYS) >on the starting density (i.e. an orbital A which is less populated then >orbital B will usually be even less populated when -orb is added. So when >you start the scf cycle with two densites, one with more A and the other with >more B, there are good chances that you end up with two different scf >solutions - check E-tot) > > > 1 : when runsp+SO , is there any difference between the two kinds of > > sequences list below: > > > > a: init_lapw > > initso_lapw-->accept the files it generated > > runsp_lapw -so > > > > b:the methods recommanded in the UG: > > run[sp]_lapw ---> > > after convergence, then save_lapw > > initso_lapw > > run[sp]_lapw -so > >I would always do b) (maybe just because I also want to see the differences >between so and no so). > > > > 2:when runsp+ORB, is there any difference between the two kinds of > > sequences list below: > > > > a:init_lapw > > edit case.indm(c),inorb by hand > > runsp_lapw -orb > > > > b:the method in your mail: > > runsp > > save_lapw > > create inorb and indm-files > > x lapwdm -up/dn (to have a case.dmatup/dn file already in the first > > cycle) > > runsp -orb > >Again I would always do b). One can "hope", that LDA (better GGA) produces >at least the correct sequence of occupations, i.e. occupy orbital A slightly >more than B (e.g. 0.45 and 0.41), when the "correct" occupation including >orb is 0.8 and 0.06. > > > > 3: runsp+SO+ORB, is the sequence listed below is right? > > > > init_lapw > > initso_lapw -->accept the struct files it generated > > edit case.indmc , case.inorb by hand > > runsp_lapw -so -orb > > > > is there any different sequence? If It also need to first runsp_lapw to > > achieve convergence, then save the result(like mentioned above), then > > runsp_lapw -so -orb? > >Here the answer is most difficult. It depends a lot on the system and >which effects are dominating, wether it is metallic or should be an insulator >(but maybe is not in LDA,...). >For 3d elements, where SO is usually the "smallest" correction, I would most >likely do: > >init >runsp >runsp -orb >runsp -orb -so > >For 5f, where SO is very important, maybe one adds first SO and then -orb > > >Unfortunately for this advanced topic there is no black box solution. > >Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 02:55:44 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Adapting files to run with -so ==== "Yue Hai" submitted the following contribution: ==== Dear Peter: Thank your instructive email,I think I have partly understood your meanning. That is to say, before add SO or(and)ORB, runsp_lapw first can creat at least quantitatively "correct" inintial configuration(especially for when ORB will be included),Is it right? . And I want to know , when I first runsp_lapw , is it necessary to convergence or just some cycles,like 20 or 40 ,and so on? >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: Adapting files to run with -so >Date: Thu, 31 Oct 2002 15:40:00 +0100 (MET) > >==== >Peter Blaha >submitted the following contribution: >==== > > > After reading your mail,I have some general questions about the sequence > > of runsp with SO or (and)ORB, I hope can get your help or advice. > >One cannot make general statements about these questions. It depends on >your system which method is the proper one. You must know the physics and >decide wether SO and/or orbital fields should be small corrections or big >effects!!! > >In general it is true, that already for spinpolarized calculations without >SO or orb.fields several scf solutions COULD occur (NOT WILL). > >It is even more true when SO and/or orbital fields are included. > >In particular, scf solution with orbital potentials depend often (NOT ALWAYS) >on the starting density (i.e. an orbital A which is less populated then >orbital B will usually be even less populated when -orb is added. So when >you start the scf cycle with two densites, one with more A and the other with >more B, there are good chances that you end up with two different scf >solutions - check E-tot) > > > 1 : when runsp+SO , is there any difference between the two kinds of > > sequences list below: > > > > a: init_lapw > > initso_lapw-->accept the files it generated > > runsp_lapw -so > > > > b:the methods recommanded in the UG: > > run[sp]_lapw ---> > > after convergence, then save_lapw > > initso_lapw > > run[sp]_lapw -so > >I would always do b) (maybe just because I also want to see the differences >between so and no so). > > > > 2:when runsp+ORB, is there any difference between the two kinds of > > sequences list below: > > > > a:init_lapw > > edit case.indm(c),inorb by hand > > runsp_lapw -orb > > > > b:the method in your mail: > > runsp > > save_lapw > > create inorb and indm-files > > x lapwdm -up/dn (to have a case.dmatup/dn file already in the first > > cycle) > > runsp -orb > >Again I would always do b). One can "hope", that LDA (better GGA) produces >at least the correct sequence of occupations, i.e. occupy orbital A slightly >more than B (e.g. 0.45 and 0.41), when the "correct" occupation including >orb is 0.8 and 0.06. > > > > 3: runsp+SO+ORB, is the sequence listed below is right? > > > > init_lapw > > initso_lapw -->accept the struct files it generated > > edit case.indmc , case.inorb by hand > > runsp_lapw -so -orb > > > > is there any different sequence? If It also need to first runsp_lapw to > > achieve convergence, then save the result(like mentioned above), then > > runsp_lapw -so -orb? > >Here the answer is most difficult. It depends a lot on the system and >which effects are dominating, wether it is metallic or should be an insulator >(but maybe is not in LDA,...). >For 3d elements, where SO is usually the "smallest" correction, I would most >likely do: > >init >runsp >runsp -orb >runsp -orb -so > >For 5f, where SO is very important, maybe one adds first SO and then -orb > > >Unfortunately for this advanced topic there is no black box solution. > >Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 03:24:20 +0000 From: ecat@nfrn-mail.org.uk Subject: [WIEN]: Stop in lapw1up ==== ecat@nfrn-mail.org.uk submitted the following contribution: ==== Dear all, I am a new user of wien2k. When I ran runsp_lapw for the first time, it stopped in the second cycle. When I changed the mixing parameter in case.inm from 0.4 to 0.1, it stopped again in the eleventh cycle. What was written in uplapw1.error is: 'SELECT' - no energy limits found for L= 1 'SELECT' - E-bottom -200.00000 E-top -1.31500 I don't know what to do know.Could you tell me how to solve this problem,please? Thanks! Yours, Ecat ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 1 Nov 2002 10:37:54 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Stop in lapw1up ==== "Saeid Jalali" submitted the following contribution: ==== > I am a new user of wien2k. When I ran runsp_lapw for the first > time, it stopped in the second cycle. When I changed the mixing > parameter in case.inm from 0.4 to 0.1, it stopped again in the > eleventh cycle. What was written in uplapw1.error is: > > 'SELECT' - no energy limits found for L= 1 > 'SELECT' - E-bottom -200.00000 E-top -1.31500 > > I don't know what to do know.Could you tell me how to solve this > problem,please? Thanks! You would keep 0.1 and add -in1new 5 to your run to linearize the energies to get ride of that error: run -in1new 5 -cc 0.00001 -i 99 ... . Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 1 Nov 2002 10:57:41 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: [WIEN] orbital moments (s-o) ==== "Saeid Jalali" submitted the following contribution: ==== > performing s-o calculations for a magnetic system I can't find the orbital > moments in any of the ouptut. Two questions: > > (1) Is it there, and am I missing it? Did you miss -orb? To get orbital moment one must use orbital dependent potential(s) including spin-orbit coupling: runsp_lapw -so -orb. > (2) If not, where are they calculated, so I could get them output? Please, inspect now the output of lapwdm program or .scf. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 09:04:41 +0100 From: Thomas Claesson Subject: Re: [WIEN]: Adapting files to run with -so ==== Thomas Claesson submitted the following contribution: ==== Dear Peter, thanks for your answer! Peter Blaha wrote: > >If you have problems with LDA+U convergence for NiO, you will also have >these problems when adding SO. NiO converges reasonably quick using LDA+U >starting from a scf LDA (GGA) calculation. > >You do something wrong there! > Perhaps I do, but what? Could anyone help me out and find my mistake? I have been using RKmax = 7.0 and a k-mesh of up to 800 k-points in the entire BZ. These are the input files I am using: NiO.struct: NiO R LATTICE,NONEQUIV. ATOMS: 3 MODE OF CALC=RELA 5.605236 5.605236 27.459934 90.000000 90.000000 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 4 Ni1 NPT= 781 R0=0.00050000 RMT= 2.0000 Z: 28.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.50000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 4 Ni2 NPT= 781 R0=0.00050000 RMT= 2.0000 Z: 28.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.25000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 4 -3: X=0.75000000 Y=0.75000000 Z=0.75000000 O NPT= 781 R0=0.00050000 RMT= 1.7500 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 12 NUMBER OF SYMMETRY OPERATIONS Nio.inst: Ni Ar 3 5 3, 2,3.0 N 3, 2,1.0 N 3,-3,2.0 N 3,-3,2.0 N 4,-1,1.0 N 4,-1,1.0 N Ni Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,1.0 N 4,-1,1.0 N 4,-1,1.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,1.0 N 2,-2,1.0 N **** **** END of input (instgen_lapw) Nio.in1: WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 1 0.30 0.000 CONT 1 1 -4.96 0.005 STOP 1 2 0.30 0.010 CONT 1 0 0.30 0.000 CONT 1 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 1 0.30 0.000 CONT 1 1 -4.96 0.005 STOP 1 2 0.30 0.010 CONT 1 0 0.30 0.000 CONT 1 0.30 3 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 -1.55 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window Nio.indm: - -9. 2 1 1 2 2 1 2 0 0 Nio.inorb: 1 2 0 PRATT, 1.0 1 1 2 2 1 2 1 0.59 0.07 0.59 0.07 Any suggestions are welcome! Thanks for your replies! Best regards, Thomas Claesson > >>Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y >>FORTRAN STOP >>2.370u 0.060s 0:02.98 81.5% 0+0k 0+0io 213pf+0w >> A new structure for SO calculations has been created (_so). >> If you commit it will create new Nio.struct, in1(c), in2c, inc, >> clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous >> calculations) >> >>NOTE: Files for -orb (Nio.indm(c),inorb,dmatup/dn) must be adapted manually >> >>My question concerns the last sentence. How should I adapt the files for >>-orb? What changes must I do to the files I have been using before I >>added SO coupling? >> > >This depends on your case. For NiO probably nothing (exept that you need a >case.indmc file instead of case.indm when SO is used) > >In other cases, atomic positions could split creating a new struct file >(with more atoms) and then you must update those files. > >Regards > > P.Blaha > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 1 Nov 2002 16:39:21 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --143914132-568929606-1036139961=:15194 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all, I would like to consult about the following problem. Actually, I have asked the similar question about .struct file. and wien97 generated .struct file with multipicity equals 52 to me last time. And now, I make an .struct file with 40 atom position and start the calculation. After nn, WIEN97 generates another .struct file to me. However, this generated .struct file has 43 atom position. Where is the problem? Actually, I have tried to delete the 3 repeated atom positions from the generated .struct file but it didn't work, too. The molecule that I am interested in is carbon nanotube (10,10) and the unit cell should be only 40 atoms. The original inputed .struct file (1010.struct_init1 and 1010.struct_init2 (I have tried with 2 different original .struct files)) and the generated .struct file (1010.struct)are both attached. Thank you very much Martin - --143914132-568929606-1036139961=:15194 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="1010.struct_init1" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="1010.struct_init1" Y250MTAxMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClAgICBMQVRUSUNFLE5PTkVR VUlWLiBBVE9NUzogMQ0KTU9ERSBPRiBDQUxDPVJFTEENCiAzNC4wMTUwODQg MzQuMDE1MDg0ICA0LjY1MTA3OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAw MDAwMA0KQXRvbT0gLTE6IFg9MC44NzY5MzE5NiBZPTAuNTAwMDAwMDAgWj0w Ljc1MDAwMDAwDQogICAgICAgICAgTVVMVD00MCAgICAgICAgICBJU1BMSVQ9 IDgNCkF0b209IC0xOiBYPTAuNTAwMDAwMDAgWT0wLjg3NjkzMTk2IFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4xMjMwNjgwNCBZPTAuNTAwMDAwMDAg Wj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUwMDAwMDAwIFk9MC4xMjMw NjgwNCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuODY4Njk1MDkgWT0w LjU3ODM2ODU2IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC40MjE2MzE0 NCBZPTAuODY4Njk1MDkgWj0wLjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjEz MTMwNDkxIFk9MC40MjE2MzE0NCBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBY PTAuNTc4MzY4NTYgWT0wLjEzMTMwNDkxIFo9MC4yNTAwMDAwMA0KQXRvbT0g LTE6IFg9MC44NTg0ODM1OSBZPTAuNjE2NDc4MzggWj0wLjI1MDAwMDAwDQpB dG9tPSAtMTogWD0wLjM4MzUyMTYyIFk9MC44NTg0ODM1OSBaPTAuNzUwMDAw MDANCkF0b209IC0xOiBYPTAuMTQxNTE2NDEgWT0wLjM4MzUyMTYyIFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC42MTY0NzgzOCBZPTAuMTQxNTE2NDEg Wj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjgyNjQzMjY1IFk9MC42ODg0 NjU5OCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuMzExNTM0MDIgWT0w LjgyNjQzMjY1IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4xNzM1Njcz NSBZPTAuMzExNTM0MDIgWj0wLjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjY4 ODQ2NTk4IFk9MC4xNzM1NjczNSBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBY PTAuODA0OTQ0MzYgWT0wLjcyMTU1NTA1IFo9MC43NTAwMDAwMA0KQXRvbT0g LTE6IFg9MC43NTIyMTY3MSBZPTAuNzgwMTE1MDMgWj0wLjc1MDAwMDAwDQpB dG9tPSAtMTogWD0wLjcyMTU1NTA1IFk9MC44MDQ5NDQzNiBaPTAuMjUwMDAw MDANCkF0b209IC0xOiBYPTAuMjc4NDQ0OTUgWT0wLjgwNDk0NDM2IFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4yMTk4ODQ5NyBZPTAuNzUyMjE2NzEg Wj0wLjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjE5NTA1NTY0IFk9MC43MjE1 NTUwNSBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBYPTAuMTk1MDU1NjQgWT0w LjI3ODQ0NDk1IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4yNDc3ODMy OSBZPTAuMjE5ODg0OTcgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjI3 ODQ0NDk1IFk9MC4xOTUwNTU2NCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBY PTAuNzIxNTU1MDUgWT0wLjE5NTA1NTY0IFo9MC4yNTAwMDAwMA0KQXRvbT0g LTE6IFg9MC43ODAxMTUwMyBZPTAuMjQ3NzgzMjkgWj0wLjI1MDAwMDAwDQpB dG9tPSAtMTogWD0wLjgwNDk0NDM2IFk9MC4yNzg0NDQ5NSBaPTAuNzUwMDAw MDANCkF0b209IC0xOiBYPTAuNjUzMzEyMDQgWT0wLjg0NDM0NDQ4IFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4xNTU2NTU1MiBZPTAuNjUzMzEyMDQg Wj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjM0NjY4Nzk2IFk9MC4xNTU2 NTU1MiBaPTAuMjUwMDAwMDAgICAgIA0KQXRvbT0gLTE6IFg9MC44NDQzNDQ0 OCBZPTAuMzQ2Njg3OTYgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjYx NjQ3ODM4IFk9MC44NTg0ODM1OSBaPTAuNzUwMDAwMDAgICAgIA0KQXRvbT0g LTE6IFg9MC4xNDE1MTY0MSBZPTAuNjE2NDc4MzggWj0wLjI1MDAwMDAwICAg ICANCkF0b209IC0xOiBYPTAuMzgzNTIxNjIgWT0wLjE0MTUxNjQxIFo9MC43 NTAwMDAwMCAgICAgDQpBdG9tPSAtMTogWD0wLjg1ODQ4MzU5IFk9MC4zODM1 MjE2MiBaPTAuMjUwMDAwMDAgICAgIA0KQXRvbT0gLTE6IFg9MC41Mzk0MDAx MiBZPTAuODc0ODY3MDggWj0wLjc1MDAwMDAwICAgICANCkF0b209IC0xOiBY PTAuMTI1MTMyOTIgWT0wLjUzOTQwMDEyIFo9MC4yNTAwMDAwMCAgICAgDQpB dG9tPSAtMTogWD0wLjQ2MDU5OTg4IFk9MC4xMjUxMzI5MiBaPTAuNzUwMDAw MDAgICAgIA0KQXRvbT0gLTE6IFg9MC44NzQ4NjcwOCBZPTAuNDYwNTk5ODgg Wj0wLjI1MDAwMDAwICAgICANCkMgICAgICAgICAgTlBUPSAgNzgxICBSMD0w LjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMCAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwICAgDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMCAgIA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCiAgIDAgU1lNTUVUUlkgT1BFUkFU SU9OUzogDQo= - --143914132-568929606-1036139961=:15194 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="1010.struct_init2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="1010.struct_init2" Y250MTAxMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClAgICBMQVRUSUNFLE5PTkVR VUlWLiBBVE9NUzogNA0KTU9ERSBPRiBDQUxDPVJFTEENCiAzNC4wMTUwODQg MzQuMDE1MDg0ICA0LjY1MTA3OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAw MDAwMA0KQXRvbT0gLTE6IFg9MC44NzY5MzE5NiBZPTAuNTAwMDAwMDAgWj0w Ljc1MDAwMDAwDQogICAgICAgICAgTVVMVD0xMCAgICAgICAgICBJU1BMSVQ9 IDgNCkF0b209IC0xOiBYPTAuNTAwMDAwMDAgWT0wLjg3NjkzMTk2IFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4xMjMwNjgwNCBZPTAuNTAwMDAwMDAg Wj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUwMDAwMDAwIFk9MC4xMjMw NjgwNCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuODY4Njk1MDkgWT0w LjU3ODM2ODU2IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC40MjE2MzE0 NCBZPTAuODY4Njk1MDkgWj0wLjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjEz MTMwNDkxIFk9MC40MjE2MzE0NCBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBY PTAuNTc4MzY4NTYgWT0wLjEzMTMwNDkxIFo9MC4yNTAwMDAwMA0KQXRvbT0g LTE6IFg9MC44NTg0ODM1OSBZPTAuNjE2NDc4MzggWj0wLjI1MDAwMDAwDQpB dG9tPSAtMTogWD0wLjM4MzUyMTYyIFk9MC44NTg0ODM1OSBaPTAuNzUwMDAw MDANCkMgICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0g ICAgMS4yMDAwICAgWjogIDYuMCAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwICAgDQogICAgICAg ICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMCAg IA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAx LjAwMDAwMDANCkF0b209IC0yOiBYPTAuMTQxNTE2NDEgWT0wLjM4MzUyMTYy IFo9MC4yNTAwMDAwMA0KICAgICAgICAgIE1VTFQ9MTAgICAgICAgICAgSVNQ TElUPSA4DQpBdG9tPSAtMjogWD0wLjYxNjQ3ODM4IFk9MC4xNDE1MTY0MSBa PTAuNzUwMDAwMDANCkF0b209IC0yOiBYPTAuODI2NDMyNjUgWT0wLjY4ODQ2 NTk4IFo9MC4yNTAwMDAwMA0KQXRvbT0gLTI6IFg9MC4zMTE1MzQwMiBZPTAu ODI2NDMyNjUgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMjogWD0wLjE3MzU2NzM1 IFk9MC4zMTE1MzQwMiBaPTAuMjUwMDAwMDANCkF0b209IC0yOiBYPTAuNjg4 NDY1OTggWT0wLjE3MzU2NzM1IFo9MC43NTAwMDAwMA0KQXRvbT0gLTI6IFg9 MC44MDQ5NDQzNiBZPTAuNzIxNTU1MDUgWj0wLjc1MDAwMDAwDQpBdG9tPSAt MjogWD0wLjc1MjIxNjcxIFk9MC43ODAxMTUwMyBaPTAuNzUwMDAwMDANCkF0 b209IC0yOiBYPTAuNzIxNTU1MDUgWT0wLjgwNDk0NDM2IFo9MC4yNTAwMDAw MA0KQXRvbT0gLTI6IFg9MC4yNzg0NDQ5NSBZPTAuODA0OTQ0MzYgWj0wLjI1 MDAwMDAwDQpDICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBS TVQ9ICAgIDEuMjAwMCAgIFo6ICA2LjAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMCAgIA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAw MDAgICANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBdG9tPSAtMzogWD0wLjIxOTg4NDk3IFk9MC43NTIy MTY3MSBaPTAuMjUwMDAwMDANCiAgICAgICAgICBNVUxUPTEwICAgICAgICAg IElTUExJVD0gOA0KQXRvbT0gLTM6IFg9MC4xOTUwNTU2NCBZPTAuNzIxNTU1 MDUgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMzogWD0wLjE5NTA1NTY0IFk9MC4y Nzg0NDQ5NSBaPTAuNzUwMDAwMDANCkF0b209IC0zOiBYPTAuMjQ3NzgzMjkg WT0wLjIxOTg4NDk3IFo9MC43NTAwMDAwMA0KQXRvbT0gLTM6IFg9MC4yNzg0 NDQ5NSBZPTAuMTk1MDU1NjQgWj0wLjI1MDAwMDAwDQpBdG9tPSAtMzogWD0w LjcyMTU1NTA1IFk9MC4xOTUwNTU2NCBaPTAuMjUwMDAwMDANCkF0b209IC0z OiBYPTAuNzgwMTE1MDMgWT0wLjI0Nzc4MzI5IFo9MC4yNTAwMDAwMA0KQXRv bT0gLTM6IFg9MC44MDQ5NDQzNiBZPTAuMjc4NDQ0OTUgWj0wLjc1MDAwMDAw DQpBdG9tPSAtMzogWD0wLjY1MzMxMjA0IFk9MC44NDQzNDQ0OCBaPTAuMjUw MDAwMDANCkF0b209IC0zOiBYPTAuMTU1NjU1NTIgWT0wLjY1MzMxMjA0IFo9 MC43NTAwMDAwMA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjIwMDAgICBaOiAgNi4wICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAgICAN CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4w MDAwMDAwICAgDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4w MDAwMDAwIDEuMDAwMDAwMA0KQXRvbT0gLTQ6IFg9MC4zNDY2ODc5NiBZPTAu MTU1NjU1NTIgWj0wLjI1MDAwMDAwICAgICANCiAgICAgICAgICBNVUxUPTEw ICAgICAgICAgIElTUExJVD0gOA0KQXRvbT0gLTQ6IFg9MC44NDQzNDQ0OCBZ PTAuMzQ2Njg3OTYgWj0wLjc1MDAwMDAwDQpBdG9tPSAtNDogWD0wLjYxNjQ3 ODM4IFk9MC44NTg0ODM1OSBaPTAuNzUwMDAwMDAgICAgIA0KQXRvbT0gLTQ6 IFg9MC4xNDE1MTY0MSBZPTAuNjE2NDc4MzggWj0wLjI1MDAwMDAwICAgICAN CkF0b209IC00OiBYPTAuMzgzNTIxNjIgWT0wLjE0MTUxNjQxIFo9MC43NTAw MDAwMCAgICAgDQpBdG9tPSAtNDogWD0wLjg1ODQ4MzU5IFk9MC4zODM1MjE2 MiBaPTAuMjUwMDAwMDAgICAgIA0KQXRvbT0gLTQ6IFg9MC41Mzk0MDAxMiBZ PTAuODc0ODY3MDggWj0wLjc1MDAwMDAwICAgICANCkF0b209IC00OiBYPTAu MTI1MTMyOTIgWT0wLjUzOTQwMDEyIFo9MC4yNTAwMDAwMCAgICAgDQpBdG9t PSAtNDogWD0wLjQ2MDU5OTg4IFk9MC4xMjUxMzI5MiBaPTAuNzUwMDAwMDAg ICAgIA0KQXRvbT0gLTQ6IFg9MC44NzQ4NjcwOCBZPTAuNDYwNTk5ODggWj0w LjI1MDAwMDAwICAgICANCkMgICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAw MDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMCAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAw ICAgDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMCAgIA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCiAgIDAgU1lNTUVUUlkgT1BFUkFUSU9O UzogDQo= - --143914132-568929606-1036139961=:15194 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="1010.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="1010.struct" Y250MTAxMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClAgICBMQVRUSUNFLE5PTkVR VUlWLiBBVE9NUzogOA0KTU9ERSBPRiBDQUxDPVJFTEENCiAzNC4wMTUwODQg MzQuMDE1MDg0ICA0LjY1MTA3OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAw MDAwMA0KQXRvbT0gLTE6IFg9MC44NzY5MzE5NiBZPTAuNTAwMDAwMDAgWj0w Ljc1MDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9 IDgNCkF0b209IC0xOiBYPTAuNTAwMDAwMDAgWT0wLjg3NjkzMTk2IFo9MC4y NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4xMjMwNjgwNCBZPTAuNTAwMDAwMDAg Wj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUwMDAwMDAwIFk9MC4xMjMw NjgwNCBaPTAuMjUwMDAwMDANCkMgICAgICAgICAgTlBUPSAgNzgxICBSMD0w LjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0KICAgICAgICAg ICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAw IDEuMDAwMDAwMA0KQXRvbT0gLTI6IFg9MC44Njg2OTUwOSBZPTAuNTc4MzY4 NTYgWj0wLjc1MDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJ U1BMSVQ9IDgNCkF0b209IC0yOiBYPTAuNDIxNjMxNDQgWT0wLjg2ODY5NTA5 IFo9MC4yNTAwMDAwMA0KQXRvbT0gLTI6IFg9MC4xMzEzMDQ5MSBZPTAuNDIx NjMxNDQgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMjogWD0wLjU3ODM2ODU2IFk9 MC4xMzEzMDQ5MSBaPTAuMjUwMDAwMDANCkMgICAgICAgICAgTlBUPSAgNzgx ICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0KICAg ICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAw MDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4w MDAwMDAwIDEuMDAwMDAwMA0KQXRvbT0gLTM6IFg9MC44NTg0ODM1OSBZPTAu NjE2NDc4MzggWj0wLjI1MDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAg ICAgICBJU1BMSVQ9IDgNCkF0b209IC0zOiBYPTAuMzgzNTIxNjIgWT0wLjg1 ODQ4MzU5IFo9MC43NTAwMDAwMA0KQXRvbT0gLTM6IFg9MC4xNDE1MTY0MSBZ PTAuMzgzNTIxNjIgWj0wLjI1MDAwMDAwDQpBdG9tPSAtMzogWD0wLjYxNjQ3 ODM4IFk9MC4xNDE1MTY0MSBaPTAuNzUwMDAwMDANCkMgICAgICAgICAgTlBU PSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYu MA0KICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQXRvbT0gLTQ6IFg9MC44MjY0MzI2 NSBZPTAuNjg4NDY1OTggWj0wLjI1MDAwMDAwDQogICAgICAgICAgTVVMVD0g NCAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC00OiBYPTAuMzExNTM0MDIg WT0wLjgyNjQzMjY1IFo9MC43NTAwMDAwMA0KQXRvbT0gLTQ6IFg9MC4xNzM1 NjczNSBZPTAuMzExNTM0MDIgWj0wLjI1MDAwMDAwDQpBdG9tPSAtNDogWD0w LjY4ODQ2NTk4IFk9MC4xNzM1NjczNSBaPTAuNzUwMDAwMDANCkMgICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDYuMA0KICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAw MDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQXRvbT0gLTU6IFg9MC44 MDQ5NDQzNiBZPTAuNzIxNTU1MDUgWj0wLjc1MDAwMDAwDQogICAgICAgICAg TVVMVD0xNSAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC01OiBYPTAuNzUy MjE2NzEgWT0wLjc4MDExNTAzIFo9MC43NTAwMDAwMA0KQXRvbT0gLTU6IFg9 MC43MjE1NTUwNSBZPTAuODA0OTQ0MzYgWj0wLjI1MDAwMDAwDQpBdG9tPSAt NTogWD0wLjMxMTUzNDAyIFk9MC44MjY0MzI2NSBaPTAuNzUwMDAwMDANCkF0 b209IC01OiBYPTAuMjc4NDQ0OTUgWT0wLjgwNDk0NDM2IFo9MC4yNTAwMDAw MA0KQXRvbT0gLTU6IFg9MC4yMTk4ODQ5NyBZPTAuNzUyMjE2NzEgWj0wLjI1 MDAwMDAwDQpBdG9tPSAtNTogWD0wLjE5NTA1NTY0IFk9MC43MjE1NTUwNSBa PTAuNzUwMDAwMDANCkF0b209IC01OiBYPTAuMTczNTY3MzUgWT0wLjMxMTUz NDAyIFo9MC4yNTAwMDAwMA0KQXRvbT0gLTU6IFg9MC4xOTUwNTU2NCBZPTAu Mjc4NDQ0OTUgWj0wLjc1MDAwMDAwDQpBdG9tPSAtNTogWD0wLjI0Nzc4MzI5 IFk9MC4yMTk4ODQ5NyBaPTAuNzUwMDAwMDANCkF0b209IC01OiBYPTAuMjc4 NDQ0OTUgWT0wLjE5NTA1NTY0IFo9MC4yNTAwMDAwMA0KQXRvbT0gLTU6IFg9 MC42ODg0NjU5OCBZPTAuMTczNTY3MzUgWj0wLjc1MDAwMDAwDQpBdG9tPSAt NTogWD0wLjcyMTU1NTA1IFk9MC4xOTUwNTU2NCBaPTAuMjUwMDAwMDANCkF0 b209IC01OiBYPTAuNzgwMTE1MDMgWT0wLjI0Nzc4MzI5IFo9MC4yNTAwMDAw MA0KQXRvbT0gLTU6IFg9MC44MDQ5NDQzNiBZPTAuMjc4NDQ0OTUgWj0wLjc1 MDAwMDAwDQpDICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBS TVQ9ICAgIDEuMjAwMCAgIFo6ICA2LjANCiAgICAgICAgICAgICAgICAgICAg IDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAN CkF0b209IC02OiBYPTAuNjUzMzEyMDQgWT0wLjg0NDM0NDQ4IFo9MC4yNTAw MDAwMA0KICAgICAgICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4DQpB dG9tPSAtNjogWD0wLjE1NTY1NTUyIFk9MC42NTMzMTIwNCBaPTAuNzUwMDAw MDANCkF0b209IC02OiBYPTAuMzQ2Njg3OTYgWT0wLjE1NTY1NTUyIFo9MC4y NTAwMDAwMCAgICAgDQpBdG9tPSAtNjogWD0wLjg0NDM0NDQ4IFk9MC4zNDY2 ODc5NiBaPTAuNzUwMDAwMDANCkMgICAgICAgICAgTlBUPSAgNzgxICBSMD0w LjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMCAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAw MDAwMCAgIA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAw MDAwMCAwLjAwMDAwMDAgICANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwICAgDQpBdG9tPSAtNzogWD0wLjYx NjQ3ODM4IFk9MC44NTg0ODM1OSBaPTAuNzUwMDAwMDAgICAgIA0KICAgICAg ICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4ICAgICAgICAgICAgICAg ICANCkF0b209IC03OiBYPTAuMTQxNTE2NDEgWT0wLjYxNjQ3ODM4IFo9MC4y NTAwMDAwMCAgICAgDQpBdG9tPSAtNzogWD0wLjM4MzUyMTYyIFk9MC4xNDE1 MTY0MSBaPTAuNzUwMDAwMDAgICAgIA0KQXRvbT0gLTc6IFg9MC44NTg0ODM1 OSBZPTAuMzgzNTIxNjIgWj0wLjI1MDAwMDAwICAgICANCkMgICAgICAgICAg TlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjog IDYuMCAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwICAgDQogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMCAgIA0KICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAgICANCkF0 b209IC04OiBYPTAuNTM5NDAwMTIgWT0wLjg3NDg2NzA4IFo9MC43NTAwMDAw MCAgICAgDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgg ICAgICAgICAgICAgICAgIA0KQXRvbT0gLTg6IFg9MC4xMjUxMzI5MiBZPTAu NTM5NDAwMTIgWj0wLjI1MDAwMDAwICAgICANCkF0b209IC04OiBYPTAuNDYw NTk5ODggWT0wLjEyNTEzMjkyIFo9MC43NTAwMDAwMCAgICAgDQpBdG9tPSAt ODogWD0wLjg3NDg2NzA4IFk9MC40NjA1OTk4OCBaPTAuMjUwMDAwMDAgICAg IA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAg ICAxLjIwMDAgICBaOiAgNi4wICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAgICANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwICAg DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMCAgIA0KICAgMCBTWU1NRVRSWSBPUEVSQVRJT05TOg0K - --143914132-568929606-1036139961=:15194-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 15:37:23 +0000 From: Paula Subject: [WIEN]: TETRA segmentation fault ==== Paula submitted the following contribution: ==== Dear wien users, I have recently updated to wien2k and ran the 'TiC' example from UG to check for bugs. Using all the same inputs that l had for wien97 i have discovered that, though the scf calculation runs smoothly, when i try to calculate the DOS, TETRA produces a segmentation fault. Has anyone else had similar problems? Paula ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 01 Nov 2002 16:33:21 CST From: Yongbin Lee Subject: Re: [WIEN]: SRC_lapw2/outp.f ==== Yongbin Lee submitted the following contribution: ==== > Please try simply: > > cat TEST.normsoup_1 TEST.normsoup_2 TEST.normsoup_3 ... > TEST.normsoup > > And test the up and dn-spin DOS (it should look similar to the non-SO DOS). > > If this works I will put it into the lapwso_para script. > It seems to work. Thank you ! I put it into the lapw2c_para script ( "qtl" calculation routine) Another quick question. Is it possible "lapwso" has seriously smaller matrix size (about 3 times) than "lapw1" has? Does "lapwso" routine(WIEN2k) have parameters which can handle matrix size? WIEN97 lapw1(scf1) :RKM : MATRIX SIZE 3267LOs: 120 RKM= 7.00 WEIGHT= 8.00 PGR: lapwso(scfso) MATRIX SIZE= 3267 WEIGHT= 8.00 WIEN2k lapw1(scf1) :RKM : MATRIX SIZE 3690LOs: 544 RKM= 7.00 WEIGHT= 8.00 lapwso MATRIX SIZE= 1059 WEIGHT= 8.00 Thank you again Yongbin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 3 Nov 2002 14:51:29 +0100 (CET) From: =?iso-8859-1?q?youcef=20cherchab?= Subject: [WIEN]: optical properties ==== =?iso-8859-1?q?youcef=20cherchab?= submitted the following contribution: ==== Dear wien _user I would like to consult about the following problem . When i try to calculate optical properties ,step by step Iget some messages like this in LAPW2(weight writen statement executed)and in step X JOINT (fault segmentation ,core demped) I can't resolve this case ,any suggestion are welcome. thanks for yours hep. your cherchab ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 3 Nov 2002 15:11:04 +0100 (MET) From: Gilles Hug Subject: Re: [WIEN]: optical properties ==== Gilles Hug submitted the following contribution: ==== Hi, I think the segmentation fault deals with memory allocation. Either joint is not compiled with enough memory or you don't have the correct compilation options for your system. Check with someone with same architecture. Gilles On Sun, 3 Nov 2002, [iso-8859-1] youcef cherchab wrote: > ==== > =?iso-8859-1?q?youcef=20cherchab?= > submitted the following contribution: > ==== > > Dear wien _user > I would like to consult about the following problem . > When i try to calculate optical properties ,step by > step Iget some messages like this in LAPW2(weight > writen statement executed)and in step X JOINT (fault > segmentation ,core demped) > I can't resolve this case ,any suggestion are welcome. > thanks for yours hep. > > your cherchab > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 08:43:15 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: TETRA segmentation fault ==== "Kevin Jorissen" submitted the following contribution: ==== Hi Paula, on one of my machines, tetra produces core dumps when it is compiled with lxdos=3 (even when called with isplit different from 88 or 99). On other machines, compiling exactly the same source files gives me well-behaving executables. Maybe it's something compiler-dependent, I really don't have a clue (on the one machine I use f90, on the others ifc/pgi). I hope you'll work it out, Kevin. kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Paula" To: Sent: Friday, November 01, 2002 4:37 PM Subject: [WIEN]: TETRA segmentation fault > Paula > submitted the following contribution: > ==== > > Dear wien users, > > I have recently updated to wien2k and ran the 'TiC' example from UG to > check for bugs. Using all the same inputs that l had for wien97 i have > discovered that, though the scf calculation runs smoothly, when i try to > calculate the DOS, TETRA produces a segmentation fault. Has anyone else had > similar problems? > > Paula > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 16:14:46 +0800 From: "Wenhui Xie" Subject: [WIEN]: Fortran stop SECLR4 - ERROR ==== "Wenhui Xie" submitted the following contribution: ==== Dear all, I meet a quite strange error messages. the program stop at first lapw1dn cycle and give a error message: Cholesky INFO = 231 "SECLR4' - POTRF (Scalapack/LAPCK) failed What's wrong with it? Best Regards. Wenhui_xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 04 Nov 2002 17:33:22 +0900 From: Kodama Subject: [WIEN]: Si bandstructure ==== Kodama submitted the following contribution: ==== - --------------Boundary_:sTbpsx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear Wien users, I am interested in the bandstructure of SiGe and SiC alloys. I tried to calculate the bandstructure of Si using P lattice ( structure file is attached in this mail). The bandstructure using P lattice has some strange bands that don't exist in normal Si bandstructure. These bands do not disappear by changing some parameters (number of k, Rmt, El). I don't know the origin of these bands. Is this calculate wrong? Please give me some advices. Thank you very much your help. Hiroyuki Kodama - --------------Boundary_:sTbpsx Content-Type: application/octet-stream; name="Si.struct" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Si.struct" U2kgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzog OCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKTU9E RSBPRiBDQUxDPVJFTEEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogMTAuMjYxMjE3IDEwLjI2MTIxNyAxMC4yNjEyMTcg OTAuMDAwMDAwIDkwLjAwMDAwMCA5MC4wMDAwMDAgICAgICAgICAgICAgICAgICAgCkFUT009 IC0xOiBYPTAuMDAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9MC4wMDAwMDAwMAogICAgICAgICAg TVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgKU2kxICAgICAgICBOUFQ9ICA3ODEgIFIwPTAu MDAwMTAwMDAgUk1UPSAgICAyLjAwMDAgICBaOiAxNC4wICAgICAgICAgICAgICAgICAgIApM T0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAg ICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAg ICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPSAtMjog WD0wLjUwMDAwMDAwIFk9MC41MDAwMDAwMCBaPTAuMDAwMDAwMDAKICAgICAgICAgIE1VTFQ9 IDEgICAgICAgICAgSVNQTElUPSA4ClNpMiAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEw MDAwIFJNVD0gICAgMi4wMDAwICAgWjogMTQuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwg Uk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAg ICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0gLTM6IFg9MC4w MDAwMDAwMCBZPTAuNTAwMDAwMDAgWj0wLjUwMDAwMDAwCiAgICAgICAgICBNVUxUPSAxICAg ICAgICAgIElTUExJVD0gOApTaTMgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBS TVQ9ICAgIDIuMDAwMCAgIFo6IDE0LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBN QVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009IC00OiBYPTAuNTAwMDAw MDAgWT0wLjAwMDAwMDAwIFo9MC41MDAwMDAwMAogICAgICAgICAgTVVMVD0gMSAgICAgICAg ICBJU1BMSVQ9IDgKU2k0ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAg ICAyLjAwMDAgICBaOiAxNC4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklY OiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPSAtNTogWD0wLjI1MDAwMDAwIFk9 MC4yNTAwMDAwMCBaPTAuMjUwMDAwMDAKICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQ TElUPSA4ClNpNSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMi4w MDAwICAgWjogMTQuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAg MS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4w MDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAKQVRPTT0gLTY6IFg9MC43NTAwMDAwMCBZPTAuNzUw MDAwMDAgWj0wLjI1MDAwMDAwCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0g OApTaTYgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDIuMDAwMCAg IFo6IDE0LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAw LjAwMDAwMDAgMS4wMDAwMDAwCkFUT009IC03OiBYPTAuMjUwMDAwMDAgWT0wLjc1MDAwMDAw IFo9MC43NTAwMDAwMAogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BMSVQ9IDgKU2k3 ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAyLjAwMDAgICBaOiAx NC4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAg MC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4w MDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAw MDAwIDEuMDAwMDAwMApBVE9NPSAtODogWD0wLjc1MDAwMDAwIFk9MC4yNTAwMDAwMCBaPTAu NzUwMDAwMDAKICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4ClNpOCAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMi4wMDAwICAgWjogMTQuMCAg ICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAw MDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAw MCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAx LjAwMDAwMDAKICAgMSAgICAgIE5VTUJFUiBPRiBTWU1NRVRSWSBPUEVSQVRJT05TCiAxIDAg MCAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAwMAogMCAwIDEgMC4wMDAwMDAwCiAgICAgICAx Ci== - --------------Boundary_:sTbpsx-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 04 Nov 2002 09:33:22 +0100 From: Thomas Claesson Subject: Re: [WIEN]: TETRA segmentation fault ==== Thomas Claesson submitted the following contribution: ==== Dear Paula Actually I had similar problems with tetra a while ago. In my case there was a problem with the case.int file I was using. When I copied the case.int file from the SRC_templates directory and made my modifications to it, the problem disappeared. Best regards, Thomas Claesson Paula wrote: > ==== > Paula > submitted the following contribution: > ==== > > Dear wien users, > > I have recently updated to wien2k and ran the 'TiC' example from UG to > check for bugs. Using all the same inputs that l had for wien97 i have > discovered that, though the scf calculation runs smoothly, when i try > to calculate the DOS, TETRA produces a segmentation fault. Has anyone > else had similar problems? > > Paula > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 10:34:56 +0100 From: =?iso-8859-1?Q?Anders_Fr=F8seth?= Subject: [WIEN]: This_file_should_not_exist ==== =?iso-8859-1?Q?Anders_Fr=F8seth?= submitted the following contribution: ==== Dear wien users! When running one of my cases in parallel I get files with the names "This_file_should_not_exist". Can anyone tell me what this means? Anders F. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 12:09:04 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: SRC_lapw2/outp.f ==== Peter Blaha submitted the following contribution: ==== > Is it possible "lapwso" has seriously smaller matrix > size (about 3 times) than "lapw1" has? Yes of course. This is the "normal" way. lapwso uses "second variation", i.e. its basis functions are the eigenfunctions of lapw1 and usually your calculate them only in a small energy window. In your WIEN97 example below you calculated ALL eigenvalues !! which is timeconsuming and not the usual way. In WIEN2k you restrict the energy window in case.in1 (last "regular" line). > Does "lapwso" routine(WIEN2k) have parameters which > can handle matrix size? > > WIEN97 > > lapw1(scf1) > :RKM : MATRIX SIZE 3267LOs: 120 RKM= 7.00 WEIGHT= 8.00 PGR: > lapwso(scfso) > MATRIX SIZE= 3267 WEIGHT= 8.00 > > WIEN2k > lapw1(scf1) > :RKM : MATRIX SIZE 3690LOs: 544 RKM= 7.00 WEIGHT= 8.00 > lapwso > MATRIX SIZE= 1059 WEIGHT= 8.00 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 19:13:51 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: optics ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Actually, I got some very reasonable optical spectra from WIEN97 and I tried to increase the number of k-point in order to test the convergence of the spectra. Then, the spectra look very similiar. Suddenly, the spectrum become unreasonable when the number of k-point increased to around 1000. Is there any limit for the number of k-point for different unit-cell? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 12:26:04 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Fortran stop SECLR4 - ERROR ==== Peter Blaha submitted the following contribution: ==== > I meet a quite strange error messages. > the program stop at first lapw1dn cycle and give a error message: > Cholesky INFO = 231 > "SECLR4' - POTRF (Scalapack/LAPCK) failed > > What's wrong with it? Most likely your struct file. Double definition of atoms,.... ? Or unreasonable input parameters ? (RKMAX>10 ?) 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 12:29:23 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Stop in lapw1up ==== Peter Blaha submitted the following contribution: ==== > I am a new user of wien2k. When I ran runsp_lapw for the first > time, it stopped in the second cycle. When I changed the mixing > parameter in case.inm from 0.4 to 0.1, it stopped again in the > eleventh cycle. What was written in uplapw1.error is: > > 'SELECT' - no energy limits found for L= 1 > 'SELECT' - E-bottom -200.00000 E-top -1.31500 > > I don't know what to do know.Could you tell me how to solve this > problem,please? Thanks! Do: grep :DIS case.scf Is the "distance" converging ? or (I believe) diverging ? When you have a difficult case it could be that you need an even smaller value in case.inm Just do the same as the first time, but reduce mixing further. (Of course also other reasons might be possible,... (grep :NEC01 case.scf ) Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 15:42:57 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: question concerning parallel options?? ==== Peter Blaha submitted the following contribution: ==== > I installed the Wien2k version in a SGI. When I run the program it > starts running several lapw1 processes in the same processor (iterative > execution). Does anybody know how to eliminate this problem? I don't know if this is a problem or not. Is your SGI a shared memory machine or a cluster of machines ? What did you specify during installation ? What did you put into your .machines file ? If you put 3 lines with "localhost" it will of course span 3 lapw1 on the "local host". If you put 1:sgi1 1:sgi2 1:sgi3 it will create 3 jobs (with rsh or ssh (unless you said shared memory!!)) on the 3 computers with names scg1, sgi2 sgi3. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 15:37:14 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: [WIEN] orbital moments (s-o) ==== Peter Blaha submitted the following contribution: ==== > performing s-o calculations for a magnetic system I can't find the orbital > moments in any of the ouptut. Two questions: > > (1) Is it there, and am I missing it? > (2) If not, where are they calculated, so I could get them output? The orbital moment is calculated in lapwdm, which is not called during runsp -so. I added recently a switch -dm, so that also the orbital moment is calculated during scf. You need an input file case.indmc and use runsp -so -dm (But you need a recent version or update from www.wien2k.at!) Of course one can always calculate the orbital moment after scf using the same program lapwdm. (Only in case of runsp -so -orb the orbital moment will always be calculated during scf. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 15:52:51 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Adapting files to run with -so ==== Peter Blaha submitted the following contribution: ==== > >You do something wrong there! > > > Perhaps I do, but what? Could anyone help me out and find my mistake? I > have been using RKmax = 7.0 and a k-mesh of up to 800 k-points in the > entire BZ. > Nio.inst: > Ni > Ar 3 5 > 3, 2,3.0 N an occupation of 3 is not possible for kappa=2 > 3, 2,1.0 N But besides that, you define a spin of +2 in the > 3,-3,2.0 N Ni-3d(3/2) orbital > 3,-3,2.0 N > 4,-1,1.0 N > 4,-1,1.0 N > Ni > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,3.0 N here you have again a spin of +2 !!!, but now in the > 3,-3,1.0 N Ni-3d(5/2) orbital > 4,-1,1.0 N > 4,-1,1.0 N You want an AF start, so you must flip the spin. Aparently you tried that, but with this inst file it can't work and I think even lstart must have complained ? A reasonable inst file starts with: Ni Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,1.0 N 4,-1,1.0 N 4,-1,1.0 N Ni Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,1.0 N 3,-3,3.0 N 4,-1,1.0 N 4,-1,1.0 N Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 19:20:29 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Question ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-1612954989-1036434029=:10223 Content-Type: TEXT/PLAIN; charset=US-ASCII > I would like to consult about the following problem. Actually, I have > asked the similar question about .struct file. and wien97 generated > .struct file with multipicity equals 52 to me last time. > And now, I make an .struct file with 40 atom position and start the > calculation. After nn, WIEN97 generates another .struct file to me. > However, this generated .struct file has 43 atom position. Where is the > problem? Actually, I have tried to delete the 3 repeated atom > positions from the generated .struct file but it didn't work, too. The > molecule that I am interested in is carbon nanotube (10,10) and the unit > cell should be only 40 atoms. > > The original inputed .struct file (1010.struct_init1 and > 1010.struct_init2 (I have tried with 2 different original .struct > files)) and the generated .struct file (1010.struct)are both attached. I can hardly believe your report, that a new struct file with 43 atoms has been generated. WIEN2k has no problems with your structure. I started with 1010.struct_init1 and both, nn and sgroup are able to split your 40 atoms into 10x4 atoms without "adding" atoms to the unitcell!!! I suggest you register for WIEN2k. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-1612954989-1036434029=:10223 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="1010.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="1010.struct" Y250MTAxMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClAgICBMQVRUSUNFLE5PTkVR VUlWLiBBVE9NUzoxMCA4NCBQNDIvbQ0KTU9ERSBPRiBDQUxDPVJFTEENCiAz NC4wMTUwODQgMzQuMDE1MDg0ICA0LjY1MTA3OSA5MC4wMDAwMDAgOTAuMDAw MDAwIDkwLjAwMDAwMA0KQVRPTT0gIDE6IFg9MC44NzY5MzE5NiBZPTAuNTAw MDAwMDAgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAg ICBJU1BMSVQ9IDgNCiAgICAgICAxOiBYPTAuMTIzMDY4MDQgWT0wLjUwMDAw MDAwIFo9MC41MDAwMDAwMA0KICAgICAgIDE6IFg9MC41MDAwMDAwMCBZPTAu ODc2OTMxOTYgWj0wLjAwMDAwMDAwDQogICAgICAgMTogWD0wLjUwMDAwMDAw IFk9MC4xMjMwNjgwNCBaPTAuMDAwMDAwMDANCkMgMSAgICAgICAgTlBUPSAg NzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0K TE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gIDI6IFg9MC44Njg2OTUwOSBZ PTAuNTc4MzY4NTYgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAg ICAgICAgICBJU1BMSVQ9IDgNCiAgICAgICAyOiBYPTAuMTMxMzA0OTEgWT0w LjQyMTYzMTQ0IFo9MC41MDAwMDAwMA0KICAgICAgIDI6IFg9MC40MjE2MzE0 NCBZPTAuODY4Njk1MDkgWj0wLjAwMDAwMDAwDQogICAgICAgMjogWD0wLjU3 ODM2ODU2IFk9MC4xMzEzMDQ5MSBaPTAuMDAwMDAwMDANCkMgMiAgICAgICAg TlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjog IDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAw MCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAx LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gIDM6IFg9MC44NTg0 ODM1OSBZPTAuNjE2NDc4MzggWj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVM VD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgICAzOiBYPTAuMTQxNTE2 NDEgWT0wLjM4MzUyMTYyIFo9MC4wMDAwMDAwMA0KICAgICAgIDM6IFg9MC4z ODM1MjE2MiBZPTAuODU4NDgzNTkgWj0wLjUwMDAwMDAwDQogICAgICAgMzog WD0wLjYxNjQ3ODM4IFk9MC4xNDE1MTY0MSBaPTAuNTAwMDAwMDANCkMgMyAg ICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAw ICAgWjogIDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gIDQ6IFg9 MC44MjY0MzI2NSBZPTAuNjg4NDY1OTggWj0wLjAwMDAwMDAwDQogICAgICAg ICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgICA0OiBYPTAu MTczNTY3MzUgWT0wLjMxMTUzNDAyIFo9MC4wMDAwMDAwMA0KICAgICAgIDQ6 IFg9MC4zMTE1MzQwMiBZPTAuODI2NDMyNjUgWj0wLjUwMDAwMDAwDQogICAg ICAgNDogWD0wLjY4ODQ2NTk4IFk9MC4xNzM1NjczNSBaPTAuNTAwMDAwMDAN CkMgNCAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAg MS4yMDAwICAgWjogIDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g IDU6IFg9MC44MDQ5NDQzNiBZPTAuNzIxNTU1MDUgWj0wLjUwMDAwMDAwDQog ICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgICA1 OiBYPTAuMTk1MDU1NjQgWT0wLjI3ODQ0NDk1IFo9MC41MDAwMDAwMA0KICAg ICAgIDU6IFg9MC4yNzg0NDQ5NSBZPTAuODA0OTQ0MzYgWj0wLjAwMDAwMDAw DQogICAgICAgNTogWD0wLjcyMTU1NTA1IFk9MC4xOTUwNTU2NCBaPTAuMDAw MDAwMDANCkMgNSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS4yMDAwICAgWjogIDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAg MS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAg ICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0K QVRPTT0gIDY6IFg9MC4yMTk4ODQ5NyBZPTAuNzUyMjE2NzEgWj0wLjAwMDAw MDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAg ICAgICA2OiBYPTAuNzgwMTE1MDMgWT0wLjI0Nzc4MzI5IFo9MC4wMDAwMDAw MA0KICAgICAgIDY6IFg9MC4yNDc3ODMyOSBZPTAuMjE5ODg0OTcgWj0wLjUw MDAwMDAwDQogICAgICAgNjogWD0wLjc1MjIxNjcxIFk9MC43ODAxMTUwMyBa PTAuNTAwMDAwMDANCkMgNiAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEw MDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0KTE9DQUwgUk9UIE1BVFJJ WDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAw MDAwMA0KQVRPTT0gIDc6IFg9MC4yNzg0NDQ5NSBZPTAuMTk1MDU1NjQgWj0w LjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9 IDgNCiAgICAgICA3OiBYPTAuNzIxNTU1MDUgWT0wLjgwNDk0NDM2IFo9MC4w MDAwMDAwMA0KICAgICAgIDc6IFg9MC44MDQ5NDQzNiBZPTAuMjc4NDQ0OTUg Wj0wLjUwMDAwMDAwDQogICAgICAgNzogWD0wLjE5NTA1NTY0IFk9MC43MjE1 NTUwNSBaPTAuNTAwMDAwMDANCkMgNyAgICAgICAgTlBUPSAgNzgxICBSMD0w LjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0KTE9DQUwgUk9U IE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAw IDEuMDAwMDAwMA0KQVRPTT0gIDg6IFg9MC42NTMzMTIwNCBZPTAuODQ0MzQ0 NDggWj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJ U1BMSVQ9IDgNCiAgICAgICA4OiBYPTAuMzQ2Njg3OTYgWT0wLjE1NTY1NTUy IFo9MC4wMDAwMDAwMA0KICAgICAgIDg6IFg9MC4xNTU2NTU1MiBZPTAuNjUz MzEyMDQgWj0wLjUwMDAwMDAwDQogICAgICAgODogWD0wLjg0NDM0NDQ4IFk9 MC4zNDY2ODc5NiBaPTAuNTAwMDAwMDANCkMgOCAgICAgICAgTlBUPSAgNzgx ICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0KTE9D QUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAw MDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4w MDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gIDk6IFg9MC42MTY0NzgzOCBZPTAu ODU4NDgzNTkgWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAg ICAgICBJU1BMSVQ9IDgNCiAgICAgICA5OiBYPTAuMzgzNTIxNjIgWT0wLjE0 MTUxNjQxIFo9MC41MDAwMDAwMA0KICAgICAgIDk6IFg9MC4xNDE1MTY0MSBZ PTAuNjE2NDc4MzggWj0wLjAwMDAwMDAwDQogICAgICAgOTogWD0wLjg1ODQ4 MzU5IFk9MC4zODM1MjE2MiBaPTAuMDAwMDAwMDANCkMgOSAgICAgICAgTlBU PSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYu MA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gMTA6IFg9MC41Mzk0MDAx MiBZPTAuODc0ODY3MDggWj0wLjUwMDAwMDAwDQogICAgICAgICAgTVVMVD0g NCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIDEwOiBYPTAuNDYwNTk5ODgg WT0wLjEyNTEzMjkyIFo9MC41MDAwMDAwMA0KICAgICAgMTA6IFg9MC4xMjUx MzI5MiBZPTAuNTM5NDAwMTIgWj0wLjAwMDAwMDAwDQogICAgICAxMDogWD0w Ljg3NDg2NzA4IFk9MC40NjA1OTk4OCBaPTAuMDAwMDAwMDANCkMgMTAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAg WjogIDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAw MDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAw MCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgOCAgICAgIE5VTUJF UiBPRiBTWU1NRVRSWSBPUEVSQVRJT05TDQogMSAwIDAgMC4wMDAwMDAwDQog MCAxIDAgMC4wMDAwMDAwDQogMCAwIDEgMC4wMDAwMDAwDQogICAgICAgMQ0K LTEgMCAwIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAwMA0KIDAgMCAxIDAu MDAwMDAwMA0KICAgICAgIDINCiAwLTEgMCAwLjAwMDAwMDANCiAxIDAgMCAw LjAwMDAwMDANCiAwIDAgMSAwLjUwMDAwMDANCiAgICAgICAzDQogMCAxIDAg MC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMCAwIDEgMC41MDAwMDAw DQogICAgICAgNA0KLTEgMCAwIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAw MA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAgIDUNCiAxIDAgMCAwLjAwMDAw MDANCiAwIDEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAg ICA2DQogMCAxIDAgMC4wMDAwMDAwDQotMSAwIDAgMC4wMDAwMDAwDQogMCAw LTEgMC41MDAwMDAwDQogICAgICAgNw0KIDAtMSAwIDAuMDAwMDAwMA0KIDEg MCAwIDAuMDAwMDAwMA0KIDAgMC0xIDAuNTAwMDAwMA0KICAgICAgIDgNCg== - ---2105530234-1612954989-1036434029=:10223-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 19:25:09 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Si bandstructure ==== Peter Blaha submitted the following contribution: ==== On Mon, 4 Nov 2002, Kodama wrote: > Dear Wien users, > > I am interested in the bandstructure of SiGe and SiC alloys. > I tried to calculate the bandstructure of Si using P lattice ( > structure file is attached in this mail). > > The bandstructure using P lattice has some strange bands that > don't exist in normal Si bandstructure. These bands do not > disappear by changing some parameters (number of k, Rmt, El). I > don't know the origin of these bands. You did the calculation in a supercell without symmetry!!! Did you use the complex versions of the program (do you have a Si.in1c file or Si.in1 ???) You know that with this supercell you will find all the backfolded bands,... so a direct comparison with FCC Si is not so trivial. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 19:54:52 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: This_file_should_not_exist ==== Peter Blaha submitted the following contribution: ==== > When running one of my cases in parallel > I get files with the names "This_file_should_not_exist". > Can anyone tell me what this means? Don't worry, you can forget about this file. It is created by sumpara as default when you do not have *dmat* files Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 11:29:30 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Prof. P.Blaha, Thank you very much for your reply. However, I really have tried the .struct files in different machines and I really get the wrong .struct file from WIEN97. Would you mind trying the files I sent to you last time with WIEN97 again? If it works with your WIEN97, then I would uninstall my WIEN97 and re-install it again to see whether it works or not. (actually, I have already uninstalled WIEN97 and re-installed it and try the files but it doesn't work) Thank you very much Martin On Mon, 4 Nov 2002, Peter Blaha wrote: > > I would like to consult about the following problem. Actually, I have > > asked the similar question about .struct file. and wien97 generated > > .struct file with multipicity equals 52 to me last time. > > And now, I make an .struct file with 40 atom position and start the > > calculation. After nn, WIEN97 generates another .struct file to me. > > However, this generated .struct file has 43 atom position. Where is the > > problem? Actually, I have tried to delete the 3 repeated atom > > positions from the generated .struct file but it didn't work, too. The > > molecule that I am interested in is carbon nanotube (10,10) and the unit > > cell should be only 40 atoms. > > > > The original inputed .struct file (1010.struct_init1 and > > 1010.struct_init2 (I have tried with 2 different original .struct > > files)) and the generated .struct file (1010.struct)are both attached. > > I can hardly believe your report, that a new struct file with 43 atoms has > been generated. > > WIEN2k has no problems with your structure. > > I started with 1010.struct_init1 and both, nn and sgroup are able to > split your 40 atoms into 10x4 atoms without "adding" atoms to the unitcell!!! > > I suggest you register for WIEN2k. > > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > - ---------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 4 Nov 2002 22:24:58 -0600 (CST) From: Bing Zhou Subject: [WIEN]: L2main problem again ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1036470298=:2334 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all: I met the "L2main problem" in running lapw2 for my new crystal with EFG in case.in2 again. This time my crystal is in tetragonal symmetry (I4), the lapw2.error contains the following line as that for my monoclinic symmetry crytal: 'l2main' - NEFG.GT.23. Could you please give me some instructions about it? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 - ---559023410-851401618-1036470298=:2334 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tugtupite-new.in2_ls" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="tugtupite-new.in2_ls" VE9UICAgICAgICAgICAgIChUT1QsRk9SLFFUTCxFRkcsRkVSTUkpDQogICAg ICAtOS4wICAgICAxNDIuMCAwLjUwIDAuMDUgICAgICAgICAgICAgICAgRU1J TiwgTkUsIEVTRVBFUk1JTiwgRVNFUEVSMA0KVEVUUkEgICAgMC4wMDAgICAg ICAgICAgKEdBVVNTLFJPT1QsVEVNUCxURVRSQSxBTEwgICAgICBldmFsKQ0K - ---559023410-851401618-1036470298=:2334 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tugtupite-new.in2_st" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="tugtupite-new.in2_st" VE9UICAgICAgICAgICAgIChUT1QsRk9SLFFUTCxFRkcsRkVSTUkpDQogICAg ICAtOS4wICAgICAxNDIuMCAwLjUwIDAuMDUgICAgICAgICAgICAgICAgRU1J TiwgTkUsIEVTRVBFUk1JTiwgRVNFUEVSMA0KVEVUUkEgICAgMC4wMDAgICAg ICAgICAgKEdBVVNTLFJPT1QsVEVNUCxURVRSQSxBTEwgICAgICBldmFsKQ0K IDAgMCAyIDAgMyAyLTMgMiA0IDAgNCA0LTQgNCA1IDItNSAyIDYgMCA2IDQt NiA0DQogMCAwIDIgMCAzIDItMyAyIDQgMCA0IDQtNCA0IDUgMi01IDIgNiAw IDYgNC02IDQNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIg MiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAy LTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMt NSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02 IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEg MiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0z IDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUg MS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAx LTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYN CiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAx LTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMt NCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01 IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYg NCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0y IDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQg MS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAy LTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDIt NiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAw IDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDIt MyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00 IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUg NSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1 IDYgNi02IDYNCiAwIDAgMiAwIDMgMi0zIDIgNCAwIDQgNC00IDQgNSAyLTUg MiA2IDAgNiA0LTYgNA0KIDE0LiAgICAgICAgICBHTUFYDQpGSUxFICAgICAg ICBGSUxFL05PRklMRSAgd3JpdGUgcmVjcHJsaXN0DQo= - ---559023410-851401618-1036470298=:2334 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tugtupite-new.in2_sy" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="tugtupite-new.in2_sy" IDAgMCAyIDAgMyAyLTMgMiA0IDAgNCA0LTQgNCA1IDItNSAyIDYgMCA2IDQt NiA0DQogMCAwIDIgMCAzIDItMyAyIDQgMCA0IDQtNCA0IDUgMi01IDIgNiAw IDYgNC02IDQNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIg MiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAy LTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMt NSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02 IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEg MiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0z IDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUg MS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAx LTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYN CiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAx LTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMt NCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01 IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYg NCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0y IDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQg MS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAy LTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDIt NiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAw IDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDIt MyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00 IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUg NSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1 IDYgNi02IDYNCiAwIDAgMiAwIDMgMi0zIDIgNCAwIDQgNC00IDQgNSAyLTUg MiA2IDAgNiA0LTYgNA0KIDE0LiAgICAgICAgICBHTUFYDQpGSUxFICAgICAg ICBGSUxFL05PRklMRSAgd3JpdGUgcmVjcHJsaXN0DQo= - ---559023410-851401618-1036470298=:2334 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tugtupite-new.in2c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="tugtupite-new.in2c" RUZHICAgICAgICAgICAgIChUT1QsRk9SLFFUTCxFRkcsRkVSTUkpDQogICAg ICAtOS4wICAgICAxNDIuMCAwLjUwIDAuMDUgICAgICAgICAgICAgICAgRU1J TiwgTkUsIEVTRVBFUk1JTiwgRVNFUEVSMA0KVEVUUkEgICAgMC4wMDAgICAg ICAgICAgKEdBVVNTLFJPT1QsVEVNUCxURVRSQSxBTEwgICAgICBldmFsKQ0K IDAgMCAyIDAgMyAyLTMgMiA0IDAgNCA0LTQgNCA1IDItNSAyIDYgMCA2IDQt NiA0DQogMCAwIDIgMCAzIDItMyAyIDQgMCA0IDQtNCA0IDUgMi01IDIgNiAw IDYgNC02IDQNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIg MiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAy LTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMt NSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02 IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEg MiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0z IDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUg MS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAx LTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYN CiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAx LTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMt NCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01 IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYg NCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAwIDEgMS0xIDEgMiAwIDIgMS0y IDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDItMyAyIDMgMy0zIDMgNCAwIDQg MS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00IDQgNSAwIDUgMS01IDEgNSAy LTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUgNSA2IDAgNiAxLTYgMSA2IDIt NiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1IDYgNi02IDYNCiAwIDAgMSAw IDEgMS0xIDEgMiAwIDIgMS0yIDEgMiAyLTIgMiAzIDAgMyAxLTMgMSAzIDIt MyAyIDMgMy0zIDMgNCAwIDQgMS00IDEgNCAyLTQgMiA0IDMtNCAzIDQgNC00 IDQgNSAwIDUgMS01IDEgNSAyLTUgMiA1IDMtNSAzIDUgNC01IDQgNSA1LTUg NSA2IDAgNiAxLTYgMSA2IDItNiAyIDYgMy02IDMgNiA0LTYgNCA2IDUtNiA1 IDYgNi02IDYNCiAwIDAgMiAwIDMgMi0zIDIgNCAwIDQgNC00IDQgNSAyLTUg MiA2IDAgNiA0LTYgNA0KIDE0LiAgICAgICAgICBHTUFYDQpGSUxFICAgICAg ICBGSUxFL05PRklMRSAgd3JpdGUgcmVjcHJsaXN0DQo= - ---559023410-851401618-1036470298=:2334-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 08:54:48 +0100 From: Thomas Claesson Subject: Re: [WIEN]: Adapting files to run with -so ==== Thomas Claesson submitted the following contribution: ==== Thanks for your reply, Peter! So what should I look for in case.outputst and case.scf in order to know that I get an AF start? :MMIxx? Best regards, Thomas Claesson Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > >>>You do something wrong there! >>> >> >>Perhaps I do, but what? Could anyone help me out and find my mistake? I >>have been using RKmax = 7.0 and a k-mesh of up to 800 k-points in the >>entire BZ. >>Nio.inst: >>Ni >>Ar 3 5 >>3, 2,3.0 N an occupation of 3 is not possible for kappa=2 >>3, 2,1.0 N But besides that, you define a spin of +2 in the >>3,-3,2.0 N Ni-3d(3/2) orbital >>3,-3,2.0 N >>4,-1,1.0 N >>4,-1,1.0 N >>Ni >>Ar 3 5 >>3, 2,2.0 N >>3, 2,2.0 N >>3,-3,3.0 N here you have again a spin of +2 !!!, but now in the >>3,-3,1.0 N Ni-3d(5/2) orbital >>4,-1,1.0 N >>4,-1,1.0 N > > > You want an AF start, so you must flip the spin. Aparently you tried that, > but with this inst file it can't work and I think even lstart must have > complained ? > > A reasonable inst file starts with: > > Ni > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,3.0 N > 3,-3,1.0 N > 4,-1,1.0 N > 4,-1,1.0 N > Ni > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,1.0 N > 3,-3,3.0 N > 4,-1,1.0 N > 4,-1,1.0 N > > Regards > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 12:44:33 +0100 From: Sabine Wurmehl Subject: [WIEN]: Data ==== Sabine Wurmehl submitted the following contribution: ==== Dear Wien-users, I have calculated some DOS in postscript format. Now i would like to import the ouput-data in origin or excel. Can you help me? Thanks S.Wurmehl ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 12:49:23 +0100 From: Sabine Wurmehl Subject: [WIEN]: magnetic moments ==== Sabine Wurmehl submitted the following contribution: ==== Dear Wien-users, The magnetic moment of the complete cell is written in scf-file. Does the programm also calculate the magnetic moments of the single atoms and if, in which file can i find these values? Thanks S.Wurmehl ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 12:53:58 +0100 From: Torsten Andersen Subject: Re: [WIEN]: magnetic moments ==== Torsten Andersen submitted the following contribution: ==== They are given for all atoms in the scf file... look for :CHA01, etc. Best regards, Torsten Andersen. Sabine Wurmehl wrote: >==== >Sabine Wurmehl >submitted the following contribution: >==== > >Dear Wien-users, > >The magnetic moment of the complete cell is written in scf-file. Does >the programm also calculate the magnetic moments of the single atoms >and if, in which file can i find these values? > >Thanks S.Wurmehl >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 13:35:25 +0100 From: Torsten Andersen Subject: Re: [WIEN]: magnetic moments ==== Torsten Andersen submitted the following contribution: ==== Oops, sorry, I believe it should be :MMI01, etc. Best, Torsten. Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > They are given for all atoms in the scf file... look for :CHA01, etc. > > Best regards, > Torsten Andersen. > > Sabine Wurmehl wrote: > >> ==== >> Sabine Wurmehl >> submitted the following contribution: >> ==== >> >> Dear Wien-users, >> >> The magnetic moment of the complete cell is written in scf-file. Does >> the programm also calculate the magnetic moments of the single atoms >> and if, in which file can i find these values? >> >> Thanks S.Wurmehl >> ==== >> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> To (un)subscribe send mail to >> majordomo@zeus.theochem.tuwien.ac.at >> ==== >> >> > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 17:50:27 +0400 (SAMT) From: Lyudmila Dobysheva Subject: Re: [WIEN]: Adapting files to run with -so ==== Lyudmila Dobysheva submitted the following contribution: ==== On Tue, 5 Nov 2002, Thomas Claesson wrote: > So what should I look for in case.outputst and case.scf in order to know > that I get an AF start? :MMIxx? > >>Perhaps I do, but what? Could anyone help me out and find my mistake? I > >>have been using RKmax = 7.0 and a k-mesh of up to 800 k-points in the > >>entire BZ. Dear Thomas, Couldn't it be that you have a mistake in inso file? If you take the magnetization direction 001 in NiO with its Rhombohedral lattice you'll get such errors. Best regards Lyudmila Dobysheva - ------------------------------------------------------------------------ Phys.-Techn. Institute of | Tel.(home): 7 (3412) 442118 Ural Branch of Russian Ac. of Sci. | Tel.(office): 7 (3412) 218988 426001 Izhevsk, ul.Kirova 132 | Fax: 7 (3412) 250614 RUSSIA | E-mail: lyu@otf.fti.udmurtia.su - ------------------------------------------------------------------------ http://fti.udm.ru/ltt/personals/dobysh.htm - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 14:36:09 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: magnetic moments ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Oops, sorry, I believe it should be :MMI01, etc. > In addition to that: be careful when interpreting these values. This is the (spin) magnetic moment for each atom inside its muffin tin sphere, and therefore this value does depend on the sphere size. The moment in the interstitial region is given in :MMI, but that value cannot be attributed to any specific atom. These values are therefore always arbitrary to some degree, unless you have something simple as bcc-Fe where the moment per atom is (:MMI01 + :MMI). But the same ambiguity exist in experiment: every measurement of a magnetic moment implicitely or explicitely has to define a boundary for the atom. A way to divide the total unit cell in regions that unambiguously belong to one atom each -- and which hence give you a well-defined magnetic moment that does not depend on sphere size -- is by Bader analysis. However, this is just a convention as any other. There is no physics in it, but it is at least unique. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #41 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #42 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Wednesday, November 13 2002 Volume 2002 : Number 042 ---------------------------------------------------------------------- Date: Tue, 5 Nov 2002 14:39:03 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: Data ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Sabine Wurmehl > submitted the following contribution: > ==== > > I have calculated some DOS in postscript format. Now i would like to > import the ouput-data in origin or excel. Can you help me? In excel: import the ascii-files case.dos* (or case.dos*ev) and create an excel-plot. Similarly for other spreadsheets or plotting programs. It might help to remove the firt few comment lines from case.dos*, such that only the data columns remain (some programs got confused by this). Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 05:56:37 -0800 (PST) From: Claudio Lee Subject: [WIEN]: error in OP calculation! ==== Claudio Lee submitted the following contribution: ==== Hi all, I'm calculating this spinpolarized Fe bcc as a test. Using only "runsp_lapw -so" then the final result is good. However, when the orbital polarized -orb has been taken into account,I got problem with the output. With these two files *.indmc and *inorb were created, after running "runsp_lapw -so -orb" I got the result with the errors appear in the *.err file. The *.err file looks like: ===== hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END STOP lapwdm END 1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP orbital potential calculation END 1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP orbital potential calculation END STOP CORE END STOP CORE END STOP MIXER END hup: Command not found. STOP LAPW0 END STOP LAPW1 END ... ... (repeat for number of iterations, and the error appears after "lapwdm" has been executed). ===== So I think it must be wrong somewhere in my input files, *.indmc and *.inorb (or somewhere else?) Here they are: *.indmc: - -9.0 Emin cutoff energy 1 number of atoms for ... 1 1 2 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)0index - --- *.inorb: 2 1 0 nmod, natorb, ipr, amix BROYD 0.3 Broyden mixing 1 1 2 iatom, nlorb, lorb 0 nmodop 1 Ncalc 1. 0. 0. direction of M If anyone knows what is wrong in my case please help me. Thank you in advance. Claudio. __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 09:30:43 -0500 From: Fred Nastos Subject: Re: [WIEN]: Data ==== Fred Nastos submitted the following contribution: ==== > I have calculated some DOS in postscript format. Now i would like to > import the ouput-data in origin or excel. Can you help me? I believe the numerical data is in files like case.dos. You can import that data into another plotting program with minor editing. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 5 Nov 2002 23:41:12 -0800 (PST) From: hamid salehi Subject: Re: [WIEN]: magnetic moments ==== hamid salehi submitted the following contribution: ==== Dear User They are found for all atoms in "SCF-FILE" look for :CHAO1, CHAO2 , et best wishes H Salehi - --- Sabine Wurmehl wrote: > ==== > Sabine Wurmehl > submitted the following contribution: > ==== > > Dear Wien-users, > > The magnetic moment of the complete cell is written > in scf-file. Does > the programm also calculate the magnetic moments of > the single atoms > and if, in which file can i find these values? > > Thanks S.Wurmehl > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 6 Nov 2002 10:13:46 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: error in OP calculation! ==== Peter Blaha submitted the following contribution: ==== Did you use initso (with symmetso) ? (Reduced symmetry !!!??). If not, also your -so calculation is wrong (although it might converge). > I'm calculating this spinpolarized Fe bcc as a test. > Using only "runsp_lapw -so" then the final result is > good. However, when the orbital polarized -orb has > been taken into account,I got problem with the output. > With these two files *.indmc and *inorb were created, > after running "runsp_lapw -so -orb" I got the result > with the errors appear in the *.err file. > The *.err file looks like: > ===== > hup: Command not found. > STOP LAPW0 END > STOP LAPW1 END > STOP LAPW1 END > STOP LAPWSO END > STOP LAPW2 END > STOP LAPW2 END > STOP lapwdm END > 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The > program will recover by assuming a zero in its place. > STOP orbital potential calculation END > 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The > program will recover by assuming a zero in its place. > STOP orbital potential calculation END > STOP CORE END > STOP CORE END > STOP MIXER END > hup: Command not found. > STOP LAPW0 END > STOP LAPW1 END > ... > ... > (repeat for number of iterations, and the error > appears after "lapwdm" has been executed). > ===== > So I think it must be wrong somewhere in my input > files, *.indmc and *.inorb (or somewhere else?) > Here they are: > *.indmc: > -9.0 Emin cutoff energy > 1 number of atoms for ... > 1 1 2 index of 1st atom, number of L's, L1 > 0 0 r-index, (l,s)0index > --- > *.inorb: > 2 1 0 nmod, natorb, ipr, amix > BROYD 0.3 Broyden mixing > 1 1 2 iatom, nlorb, lorb > 0 nmodop > 1 Ncalc > 1. 0. 0. direction of M > > If anyone knows what is wrong in my case please help > me. > > Thank you in advance. > > Claudio. > > > > > > > > __________________________________________________ > Do you Yahoo!? > HotJobs - Search new jobs daily now > http://hotjobs.yahoo.com/ > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 6 Nov 2002 03:38:21 -0800 (PST) From: Claudio Lee Subject: Re: [WIEN]: error in OP calculation! ==== Claudio Lee submitted the following contribution: ==== Dear Peter, Yes, I did. After running initso (symmetry reduced from 48 to 16)I have everything in order to calculate with runsp_lapw - -so switch. The convergency in "runsp_lapw -so" is good, I mean, after the program has finished I have no any errors in *err file. And then I have problem (the errors eppear in *err file) when I created two files *inorb and *.indmc (following U.G) and run runsp_lapw -so -orb. Thank you so much for any suggestions. Claudio. > Did you use initso (with symmetso) ? (Reduced > symmetry !!!??). > > If not, also your -so calculation is wrong (although > it might converge). > > > > I'm calculating this spinpolarized Fe bcc as a > test. > > Using only "runsp_lapw -so" then the final result > is > > good. However, when the orbital polarized -orb > has > > been taken into account,I got problem with the > output. > > With these two files *.indmc and *inorb were > created, > > after running "runsp_lapw -so -orb" I got the > result > > with the errors appear in the *.err file. > > The *.err file looks like: > > ===== > > hup: Command not found. > > STOP LAPW0 END > > STOP LAPW1 END > > STOP LAPW1 END > > STOP LAPWSO END > > STOP LAPW2 END > > STOP LAPW2 END > > STOP lapwdm END > > 1525-097 A READ statement using decimal base input > > found the invalid digit '.' in the input file. > The > > program will recover by assuming a zero in its > place. > > STOP orbital potential calculation END > > 1525-097 A READ statement using decimal base input > > found the invalid digit '.' in the input file. > The > > program will recover by assuming a zero in its > place. > > STOP orbital potential calculation END > > STOP CORE END > > STOP CORE END > > STOP MIXER END > > hup: Command not found. > > STOP LAPW0 END > > STOP LAPW1 END > > ... > > ... > > (repeat for number of iterations, and the error > > appears after "lapwdm" has been executed). > > ===== > > So I think it must be wrong somewhere in my input > > files, *.indmc and *.inorb (or somewhere else?) > > Here they are: > > *.indmc: > > -9.0 Emin cutoff energy > > 1 number of atoms for ... > > 1 1 2 index of 1st atom, number of L's, L1 > > 0 0 r-index, (l,s)0index > > --- > > *.inorb: > > 2 1 0 nmod, natorb, ipr, amix > > BROYD 0.3 Broyden mixing > > 1 1 2 iatom, nlorb, lorb > > 0 nmodop > > 1 Ncalc > > 1. 0. 0. direction of M > > > > If anyone knows what is wrong in my case please > help > > me. > > > > Thank you in advance. > > > > Claudio. > > > > > > > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > HotJobs - Search new jobs daily now > > http://hotjobs.yahoo.com/ > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > - -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 05 Nov 2002 15:17:41 +0100 From: Peer Kruse Subject: [WIEN]: Wien2k on PC: Error in lapw1 ==== Peer Kruse submitted the following contribution: ==== Dear Wien Users and developers, I still have the Error in lapw1. As nobody seems to have an idea, I' d like to ask, if anyone is using redhat 7.3 and/or newer Athlon processors without problems to exclude this possibility. Thank you Peer > ==== > Peer Kruse > submitted the following contribution: > ==== > > Dear Wien users and developers, > I tried to install Wien2k on 2 rather new PC's and get an > "Error in lapw1" after a period of about 2 hours. > This happens only for a larger number of k points, eg >500, > with only 50 it is working fine. I should have Memory in abundance > (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the > memory is not used (in the first hour of the program at least). > The limits are set to > > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > file size (blocks, -f) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > stack size (kbytes, -s) 32768 > cpu time (seconds, -t) unlimited > max user processes (-u) 7168 > virtual memory (kbytes, -v) unlimited > Is this ok? > > I compiled Wien2k with ifc and pgi, no difference, the same for the > precompiled version. > I' m running linux redhat 7.3. And it is running with the same > parameters/structures > on the old and slow and even smaller machines with every kind of > architecture (dec, pc, notebook) without problem. > > Has anyone any experience or further ideas? > > Thank you > > Peer Kruse > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 06 Nov 2002 15:34:02 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Wien2k on PC: Error in lapw1 ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Kruse, "Error in lapw1" is not much information. Wasn't there any additional information in the dayfile or the output files? Usually when lapw1 crashes during runtime just by increasing the number of k-points, it has to do with memory. And usually, there is additional information in the dayfile and/or the screen output (on dec when run in background, the default file name here is nohup.out). Is NMATMAX big enough? Do you have swap space? On any of the mentioned systems? Did a core dump? Have you tried to increase the Stack size? So that was a few ideas... I am pretty sure it has to do with your setup, not the code. Best regards, Torsten. Peer Kruse wrote: > ==== > Peer Kruse > submitted the following contribution: > ==== > > Dear Wien Users and developers, > I still have the Error in lapw1. As nobody seems to have an idea, I' d > like to ask, if anyone is using > redhat 7.3 and/or newer Athlon processors without problems to exclude > this possibility. > > Thank you > > Peer > >> ==== >> Peer Kruse >> submitted the following contribution: >> ==== >> >> Dear Wien users and developers, >> I tried to install Wien2k on 2 rather new PC's and get an >> "Error in lapw1" after a period of about 2 hours. >> This happens only for a larger number of k points, eg >500, >> with only 50 it is working fine. I should have Memory in abundance >> (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the >> memory is not used (in the first hour of the program at least). >> The limits are set to >> >> core file size (blocks, -c) 0 >> data seg size (kbytes, -d) unlimited >> file size (blocks, -f) unlimited >> max locked memory (kbytes, -l) unlimited >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> stack size (kbytes, -s) 32768 >> cpu time (seconds, -t) unlimited >> max user processes (-u) 7168 >> virtual memory (kbytes, -v) unlimited >> Is this ok? >> >> I compiled Wien2k with ifc and pgi, no difference, the same for the >> precompiled version. >> I' m running linux redhat 7.3. And it is running with the same >> parameters/structures >> on the old and slow and even smaller machines with every kind of >> architecture (dec, pc, notebook) without problem. >> >> Has anyone any experience or further ideas? >> >> Thank you >> >> Peer Kruse >> > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 6 Nov 2002 14:48:13 -0500 From: "Dadi Dai" Subject: [WIEN]: w2web and Space Group #15 ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_00F8_01C285A3.885FFA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was using w2web to generate input files for NiP2 calculations. The = cell parameters that I have are: Spacegroup #15 C12/c1 (unique axis b, = cell choice 1), a=3D6.500, b=3D5.628, c=3D6.156 A, and beta=3D127.07. The w2web StructGen accepts only B2/b (unique axis a, cell choice 1) for = space group 15. Therefore, I changed the order sequence and let = a=3D5.628, b=3D6.156, c=3D6.500, and alpha=3D127.07. But the step "x = sgroup" in "init" gave an error message: "alpha =3D 127.07 and not equal = 90. Exiting now." Did I misunderstand the symbol of space group #15 in w2web StuctGen or = the order sequence of the cell parameters? Thanks! Dadi Dai - ------=_NextPart_000_00F8_01C285A3.885FFA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was using w2web to generate input files for NiP2 = calculations.  The=20 cell parameters that I have are: Spacegroup #15 C12/c1 (unique axis b, = cell=20 choice 1), a=3D6.500, b=3D5.628, c=3D6.156 A, and beta=3D127.07.
 
The w2web StructGen accepts only B2/b (unique axis a, cell choice = 1) for=20 space group 15.  Therefore, I changed the order sequence and let = a=3D5.628,=20 b=3D6.156, c=3D6.500, and alpha=3D127.07.  But the step "x sgroup" = in "init" gave=20 an error message: "alpha =3D 127.07 and not equal 90.  Exiting = now."
 
Did I misunderstand the symbol of space group #15 in w2web StuctGen = or the=20 order sequence of the cell parameters?
 
Thanks!
 
Dadi Dai
 - ------=_NextPart_000_00F8_01C285A3.885FFA30-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 07:16:34 +0900 (KST) From: Joo Yull Rhee Subject: Re:[WIEN]: Wien2k on PC: Error in lapw1 ==== Joo Yull Rhee submitted the following contribution: ====

Dear WIEN2k users,

 

I want to share my experience with others who are using PC with AMD  Athlon processors. I purchased 4 nodes of AMD Athlon Dual-processor  machines last year. It kept failed. Initially I thought it was heat  problem with AMD CPU. I checked every possible problems. I, actually a  guy from the comppany sold these computers, swapped almost everything,  mainboard, memories, video cards, and even he installed fancy  water-cooling system. It was not successful. I bought new  airconditioner to keep the room cool. It did not help. I usually run  WIEN2k code in k-point parallelization mode. Sometimes just the  program stops. Sometimes the whole computer system just stops. I mean  it hangs without any response to the key stroke or mouse movement.  Then I have to reboot the system. Eventually, I exchanged the whole  system with 4 nodes of XEON dual-processor machines. Now, it is OK-no  down, no hanging, no rebooting. Th! e guy from the company said that  this kind of problem never happened. Th! e company sold a systme with  a single AMD Athlon Dual-processor machine for main node and 64 AMD  Athlon Single-processor machines for subnodes and it did not have any  problem except for the notorious heat problem for Athlon processors,  but by installing powerful fans or water-cooling system there was no  problem. I was not sure, but I realized the problem has happened in  the NFS system. If the calculation requires an extensive reading and  writing of files to the hard disk through NFS, the AMD CPU, especially  for dual-processor machine, could not handle this situation properly.  Either CPU or mainboard, or both could be a problem.  

I hope this experience will help you.

 

Sincerely,

 

Joo Yull Rhee 

-----¿øº»¸Þ½ÃÁö-----
º¸³½»ç¶÷: kruse@lem.uni-karlsruhe.de
¹Þ´Â»ç¶÷: rheejy@office.hoseo.ac.kr
³¯Â¥: 2002³â 11¿ù 05ÀÏ 23:17
Á¦¸ñ: [WIEN]: Wien2k on PC: Error in lapw1

==== Peer Kruse submitted the following contribution: ==== Dear Wien Users and developers, I still have the Error in lapw1. As nobody seems to have an idea, I' d like to ask, if anyone is using redhat 7.3 and/or newer Athlon processors without problems to exclude this possibility. Thank you Peer > ==== > Peer Kruse > submitted the following contribution: > ==== > > Dear Wien users and developers, > I tried to install Wien2k on 2 rather new PC's and get an > "Error in lapw1" after a period of about 2 hours. > This happens only for a larger number of k points, eg >500, > ! with only 50 it is working fine. I should have Memory in abundance > (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the > memory is not used (in the first hour of the program at least). > The limits are set to > > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > file size (blocks, -f) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > stack size (kbytes, -s) 32768 > cpu time (seconds, -t) unlimited > max user processes (-u) 7168 > virtual memory (kbytes, -v) unlimited > Is this ok? > > I compiled Wien2k with ifc and pgi, no difference, the same for the > precompiled version. > I' m running linux redhat 7.3. And it is running with the same > parameters/structures > on the old and slow and even smaller machines with every kind of > architecture (dec, pc, notebook) without prob! lem. > > Has anyone any experience or further ideas? > > Thank you > > Peer Kruse > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ====
==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 6 Nov 2002 19:38:00 -0600 (CST) From: Bing Zhou Subject: [WIEN]: problem with the H atoms in my unit cell ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1036633080=:18249 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all: There is a water (H2O) in my unit cell, I failed in running "lstart" because nothing came out from running it. I attached the case.struct and case.inst files with this email, could you please take a look and give some ideas about how to run it? any instructions, suggestion and comment is highly appreciated! Thank you in adavance! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 - ---559023410-851401618-1036633080=:18249 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="thomsenolite.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="thomsenolite.struct" VGhvbXNlbm9saXRlIHN0cnVjdHVyZSBkYXRhIGZyb20gQ2FuLiBKLiBDaGVt LiwgMTk4NSAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUCAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOjEyICAgICAgICAgICAgICAgICAgICAgIDE0 IFAyMS9jICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDEwLjUxMjU1MSAxMC40NzA5NzcgMzAuNDUy OTQ5IDkwLjAwMDAwMCA5Ni4zMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4yNTQ1MDAwMCBZPTAuMTQ1NDAwMDAg Wj0wLjI0ODQwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BM SVQ9IDgNCiAgICAgIC0xOiBYPTAuNzQ1NTAwMDAgWT0wLjg1NDYwMDAwIFo9 MC43NTE2MDAwMA0KICAgICAgLTE6IFg9MC43NDU1MDAwMCBZPTAuNjQ1NDAw MDAgWj0wLjI1MTYwMDAwDQogICAgICAtMTogWD0wLjI1NDUwMDAwIFk9MC4z NTQ2MDAwMCBaPTAuNzQ4NDAwMDANCk5hICAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDUwMDAwIFJNVD0gICAgMi44MDAwICAgWjogIDAuMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBY PTAuMTg5NDAwMDAgWT0wLjY3NDUwMDAwIFo9MC4wOTkwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4DQogICAgICAtMjogWD0w LjgxMDYwMDAwIFk9MC4zMjU1MDAwMCBaPTAuOTAxMDAwMDANCiAgICAgIC0y OiBYPTAuODEwNjAwMDAgWT0wLjE3NDUwMDAwIFo9MC40MDEwMDAwMA0KICAg ICAgLTI6IFg9MC4xODk0MDAwMCBZPTAuODI1NTAwMDAgWj0wLjU5OTAwMDAw DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDIuODAwMCAgIFo6IDIwLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjcxNzcwMDAwIFk9MC4xNzk2 MDAwMCBaPTAuMTM5MTAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAg IElTUExJVD0gOA0KICAgICAgLTM6IFg9MC4yODIzMDAwMCBZPTAuODIwNDAw MDAgWj0wLjg2MDkwMDAwDQogICAgICAtMzogWD0wLjI4MjMwMDAwIFk9MC42 Nzk2MDAwMCBaPTAuMzYwOTAwMDANCiAgICAgIC0zOiBYPTAuNzE3NzAwMDAg WT0wLjMyMDQwMDAwIFo9MC42MzkxMDAwMA0KQWwgICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjgwMDAgICBaOiAxMy4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTQ6IFg9MC41NDk2MDAwMCBZPTAuNDY0MzAwMDAgWj0wLjEyNjcwMDAwDQog ICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC00 OiBYPTAuNDUwNDAwMDAgWT0wLjUzNTcwMDAwIFo9MC44NzMzMDAwMA0KICAg ICAgLTQ6IFg9MC40NTA0MDAwMCBZPTAuOTY0MzAwMDAgWj0wLjM3MzMwMDAw DQogICAgICAtNDogWD0wLjU0OTYwMDAwIFk9MC4wMzU3MDAwMCBaPTAuNjI2 NzAwMDANCkYgICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS40MDAwICAgWjogIDkuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC01OiBYPTAuOTg4MDAwMDAgWT0w LjM2NTEwMDAwIFo9MC4xNTYzMDAwMA0KICAgICAgICAgIE1VTFQ9IDQgICAg ICAgICAgSVNQTElUPSA4DQogICAgICAtNTogWD0wLjAxMjAwMDAwIFk9MC42 MzQ5MDAwMCBaPTAuODQzNzAwMDANCiAgICAgIC01OiBYPTAuMDEyMDAwMDAg WT0wLjg2NTEwMDAwIFo9MC4zNDM3MDAwMA0KICAgICAgLTU6IFg9MC45ODgw MDAwMCBZPTAuMTM0OTAwMDAgWj0wLjY1NjMwMDAwDQpGICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNDAwMCAgIFo6ICA5 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtNjogWD0wLjQ0MDgwMDAwIFk9MC4wMTAyMDAwMCBaPTAuMTI3MzAw MDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KICAg ICAgLTY6IFg9MC41NTkyMDAwMCBZPTAuOTg5ODAwMDAgWj0wLjg3MjcwMDAw DQogICAgICAtNjogWD0wLjU1OTIwMDAwIFk9MC41MTAyMDAwMCBaPTAuMzcy NzAwMDANCiAgICAgIC02OiBYPTAuNDQwODAwMDAgWT0wLjQ4OTgwMDAwIFo9 MC42MjczMDAwMA0KRiAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjQwMDAgICBaOiAgOS4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTc6IFg9MC45MDM5MDAw MCBZPTAuOTE2NjAwMDAgWj0wLjE1NzYwMDAwDQogICAgICAgICAgTVVMVD0g NCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC03OiBYPTAuMDk2MTAwMDAg WT0wLjA4MzQwMDAwIFo9MC44NDI0MDAwMA0KICAgICAgLTc6IFg9MC4wOTYx MDAwMCBZPTAuNDE2NjAwMDAgWj0wLjM0MjQwMDAwDQogICAgICAtNzogWD0w LjkwMzkwMDAwIFk9MC41ODM0MDAwMCBaPTAuNjU3NjAwMDANCkYgICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS40MDAwICAg WjogIDkuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009IC04OiBYPTAuNjg3MzAwMDAgWT0wLjE5ODUwMDAwIFo9MC4y NDk3MDAwMA0KICAgICAgICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4 DQogICAgICAtODogWD0wLjMxMjcwMDAwIFk9MC44MDE1MDAwMCBaPTAuNzUw MzAwMDANCiAgICAgIC04OiBYPTAuMzEyNzAwMDAgWT0wLjY5ODUwMDAwIFo9 MC4yNTAzMDAwMA0KICAgICAgLTg6IFg9MC42ODczMDAwMCBZPTAuMzAxNTAw MDAgWj0wLjc0OTcwMDAwDQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuNDAwMCAgIFo6ICA5LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtOTogWD0wLjcz NTcwMDAwIFk9MC4xNjY4MDAwMCBaPTAuMDI5NDAwMDANCiAgICAgICAgICBN VUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KICAgICAgLTk6IFg9MC4yNjQz MDAwMCBZPTAuODMzMjAwMDAgWj0wLjk3MDYwMDAwDQogICAgICAtOTogWD0w LjI2NDMwMDAwIFk9MC42NjY4MDAwMCBaPTAuNDcwNjAwMDANCiAgICAgIC05 OiBYPTAuNzM1NzAwMDAgWT0wLjMzMzIwMDAwIFo9MC41Mjk0MDAwMA0KRiAg ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjQw MDAgICBaOiAgOS4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTA6IFg9MC44MDA4MDAwMCBZPTAuNjU5OTAwMDAg Wj0wLjAwNTkwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BM SVQ9IDgNCiAgICAgLTEwOiBYPTAuMTk5MjAwMDAgWT0wLjM0MDEwMDAwIFo9 MC45OTQxMDAwMA0KICAgICAtMTA6IFg9MC4xOTkyMDAwMCBZPTAuMTU5OTAw MDAgWj0wLjQ5NDEwMDAwDQogICAgIC0xMDogWD0wLjgwMDgwMDAwIFk9MC44 NDAxMDAwMCBaPTAuNTA1OTAwMDANCk8gICAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4xMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTExOiBY PTAuNzM1NDAwMDAgWT0wLjYyMjMwMDAwIFo9MC4wNTgzMDAwMA0KICAgICAg ICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4DQogICAgIC0xMTogWD0w LjI2NDYwMDAwIFk9MC4zNzc3MDAwMCBaPTAuOTQxNzAwMDANCiAgICAgLTEx OiBYPTAuMjY0NjAwMDAgWT0wLjEyMjMwMDAwIFo9MC40NDE3MDAwMA0KICAg ICAtMTE6IFg9MC43MzU0MDAwMCBZPTAuODc3NzAwMDAgWj0wLjU1ODMwMDAw DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDAuNzAwMCAgIFo6ICAxLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjc0ODYwMDAwIFk9MC44MjE2 MDAwMCBaPTAuOTg3MzAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAg IElTUExJVD0gOA0KICAgICAtMTI6IFg9MC4yNTE0MDAwMCBZPTAuMTc4NDAw MDAgWj0wLjAxMjcwMDAwDQogICAgIC0xMjogWD0wLjI1MTQwMDAwIFk9MC4z MjE2MDAwMCBaPTAuNTEyNzAwMDANCiAgICAgLTEyOiBYPTAuNzQ4NjAwMDAg WT0wLjY3ODQwMDAwIFo9MC40ODczMDAwMA0KSCAgICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAwLjcwMDAgICBaOiAgMS4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgNCAg ICAgIE5VTUJFUiBPRiBTWU1NRVRSWSBPUEVSQVRJT05TDQotMSAwIDAgMC4w MDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQog ICAgICAgMQ0KIDEgMCAwIDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0K IDAgMCAxIDAuMDAwMDAwMA0KICAgICAgIDINCi0xIDAgMCAwLjAwMDAwMDAN CiAwIDEgMCAwLjUwMDAwMDANCiAwIDAtMSAwLjUwMDAwMDANCiAgICAgICAz DQogMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC41MDAwMDAwDQogMCAwIDEg MC41MDAwMDAwDQogICAgICAgNA0K - ---559023410-851401618-1036633080=:18249 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="thomsenolite.inst" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="thomsenolite.inst" TmEgDQpOZSAxIDUNCjMsLTEsMS4wICBODQozLC0xLDAuMCAgTg0KQ2EgDQpB ciAxIDUNCjQsLTEsMS4wICBODQo0LC0xLDEuMCAgTg0KQWwgDQpOZSAyIDUN CjMsLTEsMS4wICBODQozLC0xLDEuMCAgTg0KMywgMSwxLjAgIE4NCjMsIDEs MC4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpPIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MC4wICBODQpIIA0KMSA1DQoxLC0xLDAuOSAgTg0KMSwtMSwwLjEgIE4NCkgg DQoxIDUNCjEsLTEsMC45ICBODQoxLC0xLDAuMSAgTg0KKioqKiAgICAgRW5k IG9mIElucHV0DQoqKioqICAgICBFbmQgb2YgSW5wdXQNCg== - ---559023410-851401618-1036633080=:18249-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 13:46:11 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Actually, my question is very straight-forward. I put a molecule in a simple cubic lattice and start calculation. Then, WIEN detected that my molecule does not contain inversion symmetry but the lattice type (simple cubic) should have it. Then, WIEN asks me to add INVERSION OR NOT! Actually, my molecule does not contain inversion symmetry. Is the inversion here means the below operation? X' -1 0 0 X ( Y' ) = ( 0 -1 0 )( Y ) Z' 0 0 -1 Z Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 08:41:42 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Question ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Ma Chi Chiu, if you refer to the initialisation procedure kgen, then don't worry too much. Inversion will not be added to your struct-file if you accept. You will still have to do lapw1C etc. Inversion symmetry is only used to generate of the k-mesh. So, if you accept, you will have a k-mesh with higher symmetry., ie -k will be equivalent to +k. But for all other programs except kgen, your system will not have inversion symmetry. Usually you should 'add inversion' in kgen. Kevin Jorissen University of Antwerp, Belgium kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Ma Chi Chiu" To: Sent: Thursday, November 07, 2002 6:46 AM Subject: [WIEN]: Question > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > Actually, my question is very straight-forward. > > I put a molecule in a simple cubic lattice and start calculation. Then, > WIEN detected that my molecule does not contain inversion symmetry but the > lattice type (simple cubic) should have it. Then, WIEN asks me to add > INVERSION OR NOT! Actually, my molecule does not contain inversion > symmetry. Is the inversion here means the below operation? > > X' -1 0 0 X > ( Y' ) = ( 0 -1 0 )( Y ) > Z' 0 0 -1 Z > > Thank you very much > > Martin > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 07 Nov 2002 08:53:10 +0100 From: Florent Boucher Subject: Re: [WIEN]: w2web and Space Group #15 ==== Florent Boucher submitted the following contribution: ==== - --------------000606040101080909000800 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
I think the space group accepted by WIEN is B112/b.
CXZ b-base-centered (orthorh. and monoclinic) [a sin($\gamma$ )/2, a cos($\gamma$ )/2, -c/2], [0, b, 0], [a sin($\gamma$ )/2, a cos($\gamma$ )/2, c/2]
So the transformation should be
a' = a
b' = c
c' = -b
This should work normally.
Regards
Florent

Dadi Dai a écrit:
I was using w2web to generate input files for NiP2 calculations.  The cell parameters that I have are: Spacegroup #15 C12/c1 (unique axis b, cell choice 1), a=6.500, b=5.628, c=6.156 A, and beta=127.07.
 
The w2web StructGen accepts only B2/b (unique axis a, cell choice 1) for space group 15.  Therefore, I changed the order sequence and let a=5.628, b=6.156, c=6.500, and alpha=127.07.  But the step "x sgroup" in "init" gave an error message: "alpha = 127.07 and not equal 90.  Exiting now."
 
Did I misunderstand the symbol of space group #15 in w2web StuctGen or the order sequence of the cell parameters?
 
Thanks!
 
Dadi Dai
 

-- 
 --------------------------------------------------------------------------
| Florent BOUCHER                    |                                     |
| Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr  |
| 2, rue de la Houssinière           | Phone: (33) 2 40 37 39 24           |
| BP 32229                           | Fax:   (33) 2 40 37 39 95           |
| 44322 NANTES CEDEX 3 (FRANCE)      | http://www.cnrs-imn.fr              |
 --------------------------------------------------------------------------

- --------------000606040101080909000800 Content-Type: image/gif; name="img48.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="img48.gif" R0lGODlhDQAPAPMAAAAAAGxsbEdHRycnJ8fHxxEREaWlpQUFBYCAgFlZWTY2NtfX1xsbG7a2 tgoKCpOTkyH5BAEAAAsALAAAAAANAA8AAAQ6cMlJ6yIp0UYmAsXhdMtAEowhKdqjSclDCYtC Lurc0NaUDLne4sEQTgIIo0RwExaVBJ4R8TIqGkphBAA7 - --------------000606040101080909000800 Content-Type: image/gif; name="img48.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="img48.gif" R0lGODlhDQAPAPMAAAAAAGxsbEdHRycnJ8fHxxEREaWlpQUFBYCAgFlZWTY2NtfX1xsbG7a2 tgoKCpOTkyH5BAEAAAsALAAAAAANAA8AAAQ6cMlJ6yIp0UYmAsXhdMtAEowhKdqjSclDCYtC Lurc0NaUDLne4sEQTgIIo0RwExaVBJ4R8TIqGkphBAA7 - --------------000606040101080909000800 Content-Type: image/gif; name="img48.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="img48.gif" R0lGODlhDQAPAPMAAAAAAGxsbEdHRycnJ8fHxxEREaWlpQUFBYCAgFlZWTY2NtfX1xsbG7a2 tgoKCpOTkyH5BAEAAAsALAAAAAANAA8AAAQ6cMlJ6yIp0UYmAsXhdMtAEowhKdqjSclDCYtC Lurc0NaUDLne4sEQTgIIo0RwExaVBJ4R8TIqGkphBAA7 - --------------000606040101080909000800 Content-Type: image/gif; name="img48.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="img48.gif" R0lGODlhDQAPAPMAAAAAAGxsbEdHRycnJ8fHxxEREaWlpQUFBYCAgFlZWTY2NtfX1xsbG7a2 tgoKCpOTkyH5BAEAAAsALAAAAAANAA8AAAQ6cMlJ6yIp0UYmAsXhdMtAEowhKdqjSclDCYtC Lurc0NaUDLne4sEQTgIIo0RwExaVBJ4R8TIqGkphBAA7 - --------------000606040101080909000800-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 07 Nov 2002 09:06:21 +0100 From: Florent Boucher Subject: Re: [WIEN]: Question ==== Florent Boucher submitted the following contribution: ==== Dear Martin,
this problem is a common one for non centrosymmetric space group.
So, if you don't use spin orbit coupling you can introduce the inversion center for the generation of the irreducible k-points.
Regards
Florent
Here is an answer from Peter (04/08/2002)  about this point :
====
Peter Blaha <pblaha@theochem.tuwien.ac.at>
submitted the following contribution:
====


> "Kevin Jorissen" <serelenka@hotmail.com>
  

Thanks to Keven Jorissen, who analized nicely the program KGEN.

I just want to add a few remarks:


> Next is the routine GROUPS.  This is strange.  It contains a list of all
  

GROUPS is not really used anymore, but we use the symmetry operations of
our struct file. (It is a left-over).



Adding inversion: You should always add inversion, except in

     spin-polarized relativistic spin-orbit calculations.

This can be made, since timeinversion
acts usually like the inversion and ensures that +k and -k have identical
eigenvalues.



Shift of k-mesh: This will decrease the number of points at the same k-mesh
density. Consider a 1D case:
A mesh of 3 k-points in 1D: (0; .25; .5) has a "spacing" of 0.25.

The same spacing (i.e. the same density) can be achieved by a mesh of
2 points: (1/8; 3/8). Now these two points have the same weight
(while previously I had Gamma and X with lower weight!) and I do
the calculation at the same density of k-points, but with smaller number of
points.

The counterargument is: Often bandgaps,... originate at Gamma or X, i.e.
at the BZ center or boundary. When you omit those points in your mesh,
don't expect to obtain a correct gap from this k-mesh (E.g. Your EF will be at
the highest energy of band "4", but the fourth band at Gamma is higher!
thus you may overestimate the gap in this example) .
Thus I do the scf calculation with a shifted mesh, but for semiconductors
I change the mesh before I calculate the DOS.

Regards


Ma Chi Chiu a écrit:
====
Ma Chi Chiu <martin@yangtze.hku.hk>
submitted the following contribution:
====

Dear all,

Actually, my question is very straight-forward. 

I put a molecule in a simple cubic lattice and start calculation. Then, 
WIEN detected that my molecule does not contain inversion symmetry but the 
lattice type (simple cubic) should have it. Then, WIEN asks me to add 
INVERSION OR NOT! Actually, my molecule does not contain inversion 
symmetry. Is the inversion here means the below operation?

  X'         -1  0  0    X
( Y' )  =  (  0 -1  0 )( Y )
  Z'          0  0 -1    Z 

Thank you very much

Martin

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====

  

-- 
 --------------------------------------------------------------------------
| Florent BOUCHER                    |                                     |
| Institut des Matériaux Jean Rouxel | Mailto:Florent.Boucher@cnrs-imn.fr  |
| 2, rue de la Houssinière           | Phone: (33) 2 40 37 39 24           |
| BP 32229                           | Fax:   (33) 2 40 37 39 95           |
| 44322 NANTES CEDEX 3 (FRANCE)      | http://www.cnrs-imn.fr              |
 --------------------------------------------------------------------------

==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 09:24:54 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Question ==== Peter Blaha submitted the following contribution: ==== > I put a molecule in a simple cubic lattice and start calculation. Then, > WIEN detected that my molecule does not contain inversion symmetry but the > lattice type (simple cubic) should have it. Then, WIEN asks me to add > INVERSION OR NOT! Actually, my molecule does not contain inversion > symmetry. Is the inversion here means the below operation? In addition to what was said before: If you want to study a free molecule, you need a big box, and then you need only one k-point (gamma). k-dispersion should be zero. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 20:56:56 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Thank you very much for the replies. Actually, I am interested in the optical properties of my molecule and freom the replies, it seems that the inversion symmetry is a must in order to generate a better k-mesh. Should I add the inversionif I am interested in the optical properties? The reason is that the spectra are quite different. On the other hand, I have calculated the bandstructure of another molecule with only 20 k-point (inequivalent k-point = 4). Then, I get case.spaghetti_ps and case.spaghetti_ene. Is it we can get the bandstructure by plotting the column 4 and 5 of case.spaghetti_ene file? Also, I found that the case.spaghetti_ene file has lines like "bandindex: 1", "bandindex: 2" and etc. Does it mean the lines below "bandindex: 1" are the components of band 1 of different k? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 06 Nov 2002 14:18:22 +0100 From: Peer Kruse Subject: [WIEN]: PC: Error in lapw1 ==== Peer Kruse submitted the following contribution: ==== Thank you for your ideas, I checked the files and indeed I found an > lapw1 -c (09:40:47) Speicherschutzverletzung in the dayfile. But how to interpret this? I think it is something similar to a segmentation fault. In the output1 file the table after Initialize parallelization variables is interrupted half way down it's last few lines are 1667 0.59857210 0 1 -1 0.21216 0.16977 - -0.37017 1668 0.59857210 0 0 0 0.21216 0.02425 0.17534 1669 0.59857210 0 -1 0 0.21216 -0.12126 0.17534 1670 0.59857210 so they are broken in the middle of the line. But no corefiles were generated and there is no output to the terminal. And why is it running fine on a much smaller pc (same code so same NMATMAX, same init files) but less memory and same or even smaller stack? On the smaller machine is by the way an older system and a intel CPU. I still don't understand this. Best regards Peer > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Dear Mr. Kruse, > > "Error in lapw1" is not much information. Wasn't there any additional > information in the dayfile or the output files? Usually when lapw1 > crashes during runtime just by increasing the number of k-points, it > has to do with memory. And usually, there is additional information in > the dayfile and/or the screen output (on dec when run in background, > the default file name here is nohup.out). Is NMATMAX big enough? Do > you have swap space? On any of the mentioned systems? Did a core dump? > Have you tried to increase the Stack size? > > So that was a few ideas... I am pretty sure it has to do with your > setup, not the code. > > Best regards, > Torsten. > > Peer Kruse wrote: > >> ==== >> Peer Kruse >> submitted the following contribution: >> ==== >> >> Dear Wien Users and developers, >> I still have the Error in lapw1. As nobody seems to have an idea, I' >> d like to ask, if anyone is using >> redhat 7.3 and/or newer Athlon processors without problems to exclude >> this possibility. >> >> Thank you >> >> Peer >> >>> ==== >>> Peer Kruse >>> submitted the following contribution: >>> ==== >>> >>> Dear Wien users and developers, >>> I tried to install Wien2k on 2 rather new PC's and get an >>> "Error in lapw1" after a period of about 2 hours. >>> This happens only for a larger number of k points, eg >500, >>> with only 50 it is working fine. I should have Memory in abundance >>> (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the >>> memory is not used (in the first hour of the program at least). >>> The limits are set to >>> >>> core file size (blocks, -c) 0 >>> data seg size (kbytes, -d) unlimited >>> file size (blocks, -f) unlimited >>> max locked memory (kbytes, -l) unlimited >>> max memory size (kbytes, -m) unlimited >>> open files (-n) 1024 >>> pipe size (512 bytes, -p) 8 >>> stack size (kbytes, -s) 32768 >>> cpu time (seconds, -t) unlimited >>> max user processes (-u) 7168 >>> virtual memory (kbytes, -v) unlimited >>> Is this ok? >>> >>> I compiled Wien2k with ifc and pgi, no difference, the same for the >>> precompiled version. >>> I' m running linux redhat 7.3. And it is running with the same >>> parameters/structures >>> on the old and slow and even smaller machines with every kind of >>> architecture (dec, pc, notebook) without problem. >>> >>> Has anyone any experience or further ideas? >>> >>> Thank you >>> >>> Peer Kruse >>> >> >> >> >> ==== >> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> To (un)subscribe send mail to >> majordomo@zeus.theochem.tuwien.ac.at >> ==== >> >> > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 21:56:26 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I get a message likes: > dstart (22:11:51) STOP DSTART ENDS statement executed 245.130u 0.190s 4:05.36 99.9% 0+0k 0+0io 192pf+0w - -----> check in 80.outputd if gmax > gmin, normalization In my case.outputd file, it appears like : gmin 12.3076923 gmax 10. Then, what and how should I do? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 07 Nov 2002 14:50:47 +0100 From: Torsten Andersen Subject: Re: [WIEN]: PC: Error in lapw1 ==== Torsten Andersen submitted the following contribution: ==== Yeah, that's a segmentation violation fault. You probably have turned core files off (limit coredumpsize=0 or something like that), otherwise there would have been a core file. It is an abrupt termination of the program due to what the OS or processor sees as an illegal address, and the sudden end of the file as you describe is a direct consequence of that. As far as I know it is different from "out of memory", but in some instances programs terminate with a segmentation fault there, too, although I am not sure why. Did you address the question of swap space? Because newer versions of Linux are real memory hogs if you use KDE, for example... The next question would be "Does it also happen if you compile without optimisation?", i.e., with -O0 in stead of whatever value it has now (-O5?). Are the Linux kernels identical on the different machines? It could be an OS issue... and linux is known to have problems in various kernel versions with dual processors when combined with software RAID, for example. Best regards, Torsten. Peer Kruse wrote: > ==== > Peer Kruse > submitted the following contribution: > ==== > > Thank you for your ideas, > I checked the files and indeed I found an > lapw1 -c (09:40:47) > Speicherschutzverletzung > in the dayfile. But how to interpret this? I think it is something > similar to a segmentation fault. > In the output1 file the table after Initialize parallelization > variables is interrupted > half way down it's last few lines are > > 1667 0.59857210 0 1 -1 0.21216 0.16977 > -0.37017 > 1668 0.59857210 0 0 0 0.21216 > 0.02425 0.17534 > 1669 0.59857210 0 -1 0 0.21216 > -0.12126 0.17534 > 1670 0.59857210 > > so they are broken in the middle of the line. > > But no corefiles were generated and there is no output to the terminal. > And why is it running fine on a much smaller pc (same code so same > NMATMAX, > same init files) but less memory and same or even smaller stack? > On the smaller machine is by the way an older system and a intel CPU. > I still don't understand this. > > > Best regards > > > Peer > >> ==== >> Torsten Andersen >> submitted the following contribution: >> ==== >> >> Dear Mr. Kruse, >> >> "Error in lapw1" is not much information. Wasn't there any additional >> information in the dayfile or the output files? Usually when lapw1 >> crashes during runtime just by increasing the number of k-points, it >> has to do with memory. And usually, there is additional information >> in the dayfile and/or the screen output (on dec when run in >> background, the default file name here is nohup.out). Is NMATMAX big >> enough? Do you have swap space? On any of the mentioned systems? Did >> a core dump? Have you tried to increase the Stack size? >> >> So that was a few ideas... I am pretty sure it has to do with your >> setup, not the code. >> >> Best regards, >> Torsten. >> >> Peer Kruse wrote: >> >>> ==== >>> Peer Kruse >>> submitted the following contribution: >>> ==== >>> >>> Dear Wien Users and developers, >>> I still have the Error in lapw1. As nobody seems to have an idea, I' >>> d like to ask, if anyone is using >>> redhat 7.3 and/or newer Athlon processors without problems to >>> exclude this possibility. >>> >>> Thank you >>> >>> Peer >>> >>>> ==== >>>> Peer Kruse >>>> submitted the following contribution: >>>> ==== >>>> >>>> Dear Wien users and developers, >>>> I tried to install Wien2k on 2 rather new PC's and get an >>>> "Error in lapw1" after a period of about 2 hours. >>>> This happens only for a larger number of k points, eg >500, >>>> with only 50 it is working fine. I should have Memory in abundance >>>> (1BG) for my structure of 12 atoms (6 atoms inequivalent) nad the >>>> memory is not used (in the first hour of the program at least). >>>> The limits are set to >>>> >>>> core file size (blocks, -c) 0 >>>> data seg size (kbytes, -d) unlimited >>>> file size (blocks, -f) unlimited >>>> max locked memory (kbytes, -l) unlimited >>>> max memory size (kbytes, -m) unlimited >>>> open files (-n) 1024 >>>> pipe size (512 bytes, -p) 8 >>>> stack size (kbytes, -s) 32768 >>>> cpu time (seconds, -t) unlimited >>>> max user processes (-u) 7168 >>>> virtual memory (kbytes, -v) unlimited >>>> Is this ok? >>>> >>>> I compiled Wien2k with ifc and pgi, no difference, the same for the >>>> precompiled version. >>>> I' m running linux redhat 7.3. And it is running with the same >>>> parameters/structures >>>> on the old and slow and even smaller machines with every kind of >>>> architecture (dec, pc, notebook) without problem. >>>> >>>> Has anyone any experience or further ideas? >>>> >>>> Thank you >>>> >>>> Peer Kruse >>>> >>> >>> >>> >>> ==== >>> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>> To (un)subscribe send mail to >>> majordomo@zeus.theochem.tuwien.ac.at >>> ==== >>> >>> >> > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 07 Nov 2002 14:53:45 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Question ==== Torsten Andersen submitted the following contribution: ==== Go back to 80.in2 or 80.in2c and change gmax to 13... Best regards, Torsten. Ma Chi Chiu wrote: >==== >Ma Chi Chiu >submitted the following contribution: >==== > >Dear all, > >I get a message likes: > >> dstart (22:11:51) STOP DSTART ENDS statement executed >> >245.130u 0.190s 4:05.36 99.9% 0+0k 0+0io 192pf+0w >-----> check in 80.outputd if gmax > gmin, normalization > >In my case.outputd file, it appears like : > > gmin 12.3076923 > gmax 10. > > >Then, what and how should I do? > > >Thank you very much > >Martin > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 07 Nov 2002 16:06:59 +0100 From: Vladimir Timochevski Subject: Re: [WIEN]: Question ==== Vladimir Timochevski submitted the following contribution: ==== Dear Martin, As it was pointed out in the previous comment by Prof. Blaha, you have "zero dispersion" for a molecule, cluster, or any other unperiodic solid. This means that your results should not depend on the number and position of K-points. Try to compare eigenvalues for different K-points (or plot the "spaghetti", if it does not take time). If the eigenvalues are different, it means that your "box" is not large enough. Try to increase it. When your box is large enough you will need only Gamma-point sampling. Yours, Vladimir Ma Chi Chiu wrote: > > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > Thank you very much for the replies. > > Actually, I am interested in the optical properties of my molecule and > freom the replies, it seems that the inversion symmetry is a must in order > to generate a better k-mesh. Should I add the inversionif I am interested > in the optical properties? The reason is that the spectra are quite > different. > > On the other hand, I have calculated the bandstructure of another molecule > with only 20 k-point (inequivalent k-point = 4). Then, I get > case.spaghetti_ps and case.spaghetti_ene. Is it we can get the bandstructure > by plotting the column 4 and 5 of case.spaghetti_ene file? Also, I found that > the case.spaghetti_ene file has lines like "bandindex: 1", "bandindex: 2" and > etc. Does it mean the lines below "bandindex: 1" are the components of band 1 > of different k? > > Thank you very much > > Martin > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - -- - --------------------------------------------- Vladimir Timoshevskii Departement de Physique de Materiaux Universite Claude Bernard - Lyon 1 Lyon, France Tel.: +33 472 431564 Fax: +33 472 432648 email: Vladimir.Timochevski@dpm.univ-lyon1.fr - --------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 09:46:49 -0700 (MST) From: Martin Gelfand Subject: Re:[WIEN]: Wien2k on PC: Error in lapw1 ==== Martin Gelfand submitted the following contribution: ==== It would be interesting to have a bit more information about how the AMD systems were configured---I'd guess they're running linux, but what distribution? Kernel or userland nfsd? Which kind of networking (presumably ethernet, but what chipset)? Motherboard...? I'm considering setting up a bunch of single-processor Athlon diskless nodes because it seems to be the most cost-effective setup, but I'd rather not go through your pain (particularly since I'd be building everything myself, and won't be able to return "working" motherboards/CPUs). Every detail is potentially useful. Please reply off-list if you feel this is getting too far afield for Wien2K discussions. Regards, Martin Gelfand On Thu, 7 Nov 2002, Joo Yull Rhee wrote: > ==== Joo Yull Rhee submitted the following contribution: ==== P > {margin-top:2px;margin-bottom:2px;} > > Dear WIEN2k users, > > > > I want to share my experience with others who are using PC with AMD Athlon > processors. I purchased 4 nodes of AMD Athlon Dual-processor machines last > year. It kept failed. Initially I thought it was heat problem with AMD CPU. > I checked every possible problems. I, actually a guy from the comppany sold > these computers, swapped almost everything, mainboard, memories, video > cards, and even he installed fancy water-cooling system. It was not > successful. I bought new airconditioner to keep the room cool. It did not > help. I usually run WIEN2k code in k-point parallelization mode. Sometimes > just the program stops. Sometimes the whole computer system just stops. I > mean it hangs without any response to the key stroke or mouse movement. > Then I have to reboot the system. Eventually, I exchanged the whole system > with 4 nodes of XEON dual-processor machines. Now, it is OK-no down, no > hanging, no rebooting. Th! e guy from the company said that this kind of > problem never happened. Th! e company sold a systme with a single AMD > Athlon Dual-processor machine for main node and 64 AMD Athlon > Single-processor machines for subnodes and it did not have any problem > except for the notorious heat problem for Athlon processors, but by > installing powerful fans or water-cooling system there was no problem. I > was not sure, but I realized the problem has happened in the NFS system. If > the calculation requires an extensive reading and writing of files to the > hard disk through NFS, the AMD CPU, especially for dual-processor machine, > could not handle this situation properly. Either CPU or mainboard, or both > could be a problem. > > I hope this experience will help you. > > > > Sincerely, > > > > Joo Yull Rhee > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 7 Nov 2002 20:09:26 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Question ==== "Saeid Jalali" submitted the following contribution: ==== > I get a message likes: > > > dstart (22:11:51) STOP DSTART ENDS statement executed > 245.130u 0.190s 4:05.36 99.9% 0+0k 0+0io 192pf+0w > -----> check in 80.outputd if gmax > gmin, normalization > > In my case.outputd file, it appears like : > > gmin 12.3076923 > gmax 10. It happens (gmin>gmax) when one uses small rmt or large rkmax, i..e. in organic atoms, due to the relation of gmin=rkm/rrmt*2, and demands a larger gmax to generate more planewave to expand charge density and potential (and not wavefunctions) out of the sphere(s). There is a constraint in dstart on gmax: it is limited to the upper value 25. Based on the indicated relation (gmin=rkm/rrmt*2), upper limit 25, and the case of study one justifies how to get ride of this problem. Your, Saeid. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 11:37:00 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Sorry, how to compare eigenvalues for different K-points? Which file stores the information? Also, I always the similar lines in my case.outputsp files: band 68 char-min/max: 1. 0. ERROR reading QTLs: band: 69 k-point: 38 execution continued .... Why? And how to fix this problem? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 15:23:44 +0800 From: "Wenhui Xie" Subject: [WIEN]: "Address error" and struct error in initso_lapw ==== "Wenhui Xie" submitted the following contribution: ==== Dear all, I use WIEN2k to calculate the Spin-orbit effect in CsCl Cr2 (just for training). Following the usersguide, I first runsp_lapw and save_lapw. However, In initso_lapw, two error messages occurs and the calcaulation have to stop. The Messages are pasted below: Do you have a spinpolarized case ( and want to run symmetryso)? (y/N)y ** Address Error ** End of diagnostics Do you want to use new structure for SO calculation? (y/N)y We run kgen to generate a new kmesh for the SO calculation: Input/Output Error 153: Input file ended In Procdure: main program At Line: 150 Statement: Formatted READ Unit : 20 Connected To: cr_cscl.struct Form : Formatted Access: Sequential Records Read : 0 Records Writen : 0 End of diagnostics And this is my inso file: WFFIL 4 1 0 llmax,ipr,kpot -10.0000 1.50000 emin,emax (output energy window) 0. 0. 1. direction of magnetization (lattice vectors) 2 number of atoms for which RLO is added 1 -4.97 0.005 atom number,e-lo,de (case.in1), repeat NX times 1 -4.97 0.005 0 0 0 0 0 number of atoms for which SO is switch off; atoms This is my struct files. Cs P LATTICE,NONEQUIV. ATOMS: 2 MODE OF CALC=RELA unit=bohr 5.000000 5.000000 5.000000 90.000000 90.000000 90.000000 ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Cr1 NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 24.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= 2: X=0.50000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 2 Cr2 NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 24.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 48 NUMBER OF SYMMETRY OPERATIONS I would appreciate you if I can share your experience in such a problem. Best Regards Wenhui Xie xiewh@sun20.iphy.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-08 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 19:57:51 +1100 From: chen0130@flinders.edu.au Subject: [WIEN]: automatic geometry optimisation ==== chen0130@flinders.edu.au submitted the following contribution: ==== Dear Wien users, Can any one tell me if there is any automatic geometry optimisation of any degree in Wien97? Thanks Cheng ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 08 Nov 2002 09:55:01 +0100 From: Torsten Andersen Subject: Re: [WIEN]: "Address error" and struct error in initso_lapw ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Xie, you probably need to recompile symetso (look in SRC_symmetso) with lower optimisation. I get other funny errors (wrong A and B symmetry sorting) if optimisation is too high. Change FOPT in the Makefile to "-O0". The other error is a consequence of the first error, I think... so it should disappear once you have conquered the first error. Best regards, Torsten. Wenhui Xie wrote: >==== >"Wenhui Xie" >submitted the following contribution: >==== > >Dear all, > >I use WIEN2k to calculate the Spin-orbit effect in CsCl Cr2 (just for training). >Following the usersguide, I first runsp_lapw and save_lapw. However, >In initso_lapw, two error messages occurs and the calcaulation have to stop. >The Messages are pasted below: > >Do you have a spinpolarized case ( and want to run symmetryso)? (y/N)y >** Address Error ** >End of diagnostics > >Do you want to use new structure for SO calculation? (y/N)y > We run kgen to generate a new kmesh for the SO calculation: >Input/Output Error 153: Input file ended > In Procdure: main program > At Line: 150 > Statement: Formatted READ > Unit : 20 > Connected To: cr_cscl.struct > Form : Formatted > Access: Sequential >Records Read : 0 >Records Writen : 0 >End of diagnostics > >And this is my inso file: > >WFFIL > 4 1 0 llmax,ipr,kpot > -10.0000 1.50000 emin,emax (output energy window) > 0. 0. 1. direction of magnetization (lattice vectors) > 2 number of atoms for which RLO is added > 1 -4.97 0.005 atom number,e-lo,de (case.in1), repeat NX times > 1 -4.97 0.005 > 0 0 0 0 0 number of atoms for which SO is switch off; atoms > >This is my struct files. > >Cs >P LATTICE,NONEQUIV. ATOMS: 2 >MODE OF CALC=RELA unit=bohr > 5.000000 5.000000 5.000000 90.000000 90.000000 90.000000 >ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 2 >Cr1 NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 24.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM= 2: X=0.50000000 Y=0.50000000 Z=0.50000000 > MULT= 1 ISPLIT= 2 >Cr2 NPT= 781 R0=0.00010000 RMT= 2.0000 Z: 24.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 48 NUMBER OF SYMMETRY OPERATIONS > > >I would appreciate you if I can share your experience in such a problem. > >Best Regards > >Wenhui Xie >xiewh@sun20.iphy.ac.cn >¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-08 > > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 17:17:58 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Thank you very much for the replies. My last question is : > I get a message likes: > > > dstart (22:11:51) STOP DSTART ENDS statement executed > 245.130u 0.190s 4:05.36 99.9% 0+0k 0+0io 192pf+0w > -----> check in 80.outputd if gmax > gmin, normalization > > In my case.outputd file, it appears like : > > gmin 12.3076923 > gmax 10. From the replies, I understand that I need to increase the value of gmax. However, actually, how will this two values affect the bandstructure plot or the fermi energy level of my calculation? If gmax less than gmax, will the bandstructure plot and the fermi energy level become wrong? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 08 Nov 2002 10:23:21 +0100 From: Torsten Andersen Subject: Re: [WIEN]: automatic geometry optimisation ==== Torsten Andersen submitted the following contribution: ==== min_lapw and mini (see, e.g., sec. 8.14 in UG). chen0130@flinders.edu.au wrote: >==== >chen0130@flinders.edu.au >submitted the following contribution: >==== > >Dear Wien users, > >Can any one tell me if there is any automatic geometry optimisation of any >degree in Wien97? > >Thanks > >Cheng > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 19:58:03 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: automatic geometry optimisation ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I have a question : In my .klist file, I have the following lines: - ------ 1 0 0 0 42 1.0 -7.0 1.5 200 k, div: ( 3 3 14) 2 0 0 3 42 2.0 3 0 0 6 42 2.0 . . . . . . 37 14 28 12 42 4.0 38 14 28 15 42 4.0 39 14 28 18 42 4.0 40 14 28 21 42 2.0 END - ------ In my .outputkgen, I have the following lines: - ------ length of reciprocal lattic vectors: 3.66489516 3.66489516 14.8904178 SUBMESH SHIFTED; SHIFT: 0 0 0 NO. OF MESH POINTS IN THE BRILLOUIN ZONE = 126 DIVISION OF RECIPROCAL LATTICE VECTORS (INTERVALS)= 3 3 14 weights of k-points: NO. OF INEQUIVALENT K-POINTS 40 INEQUIVALENT BLOCH VECTORS - ------ Then, how do the k-points distribute? What is the meaning for div: ( 3 3 14) {DIVISION OF RECIPROCAL LATTICE VECTORS (INTERVALS)}? My unit cell parameter is 10Ax10Ax2.46A. Actually, I am interested in how many k-points are distributed along the z-axis. How would I get the information or calculated it out? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 08 Nov 2002 14:01:16 +0100 From: Torsten Andersen Subject: Re: [WIEN]: automatic geometry optimisation ==== Torsten Andersen submitted the following contribution: ==== The k-points are distributed according to what is written in Bloechls paper. Read it. Best regards, Torsten. Ma Chi Chiu wrote: >==== >Ma Chi Chiu >submitted the following contribution: >==== > >Dear all, > >I have a question : > >In my .klist file, I have the following lines: >------ > 1 0 0 0 42 1.0 -7.0 1.5 200 k, div: ( 3 3 14) > 2 0 0 3 42 2.0 > 3 0 0 6 42 2.0 > . . . . . . > 37 14 28 12 42 4.0 > 38 14 28 15 42 4.0 > 39 14 28 18 42 4.0 > 40 14 28 21 42 2.0 >END >------ > >In my .outputkgen, I have the following lines: > >------ > length of reciprocal lattic vectors: 3.66489516 3.66489516 14.8904178 > SUBMESH SHIFTED; SHIFT: 0 0 0 > NO. OF MESH POINTS IN THE BRILLOUIN ZONE = 126 > DIVISION OF RECIPROCAL LATTICE VECTORS (INTERVALS)= 3 3 14 > weights of k-points: > NO. OF INEQUIVALENT K-POINTS 40 > INEQUIVALENT BLOCH VECTORS >------ > >Then, how do the k-points distribute? What is the meaning for div: ( 3 3 14) >{DIVISION OF RECIPROCAL LATTICE VECTORS (INTERVALS)}? My unit cell parameter is >10Ax10Ax2.46A. >Actually, I am interested in how many k-points are distributed along the z-axis. >How would I get the information or calculated it out? > >Thank you very much > >Martin > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 08 Nov 2002 15:34:31 +0000 From: "Yue Hai" Subject: [WIEN]: LDA+U ==== "Yue Hai" submitted the following contribution: ==== Dear wien2k_02 users: I want to know if someone has the successful experience with wien2k_02 to calcualte a system with SO and ORB. I have used wien2k_02 to calculate a AB system to include SO and ORB.But the result puzzled me, the situtation I found is listed as belows(the value list are just for example): 1.if I runsp_lapw, the spin momnt is : MMTOT :0.81 MMI01: 0.78____________>the spin moment of A MMI02 0.02 2:runsp_lapw -so, the result is MMTOT: 0.67 MMIO1: 0.66 3:when I runsp_lapw -so -orb ,the result are puzzled: if I use OP,the result: MMI01: 0.39 ORB01 -2.67 this may be possible , for A is 4f element and the experimental momnet is above 2.0 but if I use SIC(AMf), I found when U and J are increase ,the MMI01 are decrease,and even change form positive to negative value,for example, change form 0.63 to -0.35 ,and orb01 change form -0.59 to 0.42(just for example) when U increase from 0.11 to 0.48(experimental velue), I have change the sequence of runsp_lpw with SO and ORB just like Dear Peter answered several days ago. but no improvement. Some one also report this question before, but they use lower version wien, so the in1 must be changed to inlc, but I use the latest wien2k_02, real lapw1 is good if system obtain inversion when runsp_Lapw -so -orb because orb is added in lapwso, So it seems that in runsp+SO+SIC(AMF), the U will decrease the value of spin and orbit mometn and may change the positive(negative)value to negative(positive)value. This is obvious different from LMTO method and the prediction. Who can tell me the reason? Thanks Hai my input files are listed below: case.inso WFFIL 4 0 0 llmax,ipr,kpot -10.0000 1.5000 Emin, Emax 0 0 1 h,k,l (direction of magnetization) 0 number of atoms with RLO 1 2 number of atoms without SO, atomnumbers case.indmc - -9. Emin cutoff energy 1 number of atoms for which density matrix is calculated 1 1 3 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)-index when use U(SIC)case.inorb 1 1 0 nmod, natorb, ipr PRATT,1.0 mixmod, amix 1 1 3 iatom nlorb, lorb 1 nsic (LDA+U(SIC) used) 0.48 0.048 U J when use OP, case.inorb is 2 1 0 nmod, natorb, ipr PRATT, 1.0 mixmod, amix 1 1 3 iatom nlorb, lorb 0 nmodop 1 Ncalc 0. 0. 1. direction of M in terms of lattice vectors _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 9 Nov 2002 03:34:59 +1100 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: automatic geometry optimisation ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks, I guess I am asking a silly question, but my emphasis is on 'automatic'! (ie something done in symmetry?) without the expensive mini_lapw could someone suggest some generic reasons why geometry optimisations are not necessarily performed for solid state structures? there seems to be publications without relaxing supercells... sorry to be so broad, appreciating any remarks, Thanks, Cheng Quoting Torsten Andersen : > ==== > Torsten Andersen > submitted the following contribution: > ==== > > min_lapw and mini (see, e.g., sec. 8.14 in UG). > > chen0130@flinders.edu.au wrote: > > >==== > >chen0130@flinders.edu.au > >submitted the following contribution: > >==== > > > >Dear Wien users, > > > >Can any one tell me if there is any automatic geometry optimisation of any > > >degree in Wien97? > > > >Thanks > > > >Cheng > > > > > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > > > > -- > Dr. Torsten Andersen > Department of Physics, Condensed Matter Theory Group, Uppsala University > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace > News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 11:36:10 -0500 From: Jeff Spirko Subject: [WIEN]: Address Error in lapw1 ==== Jeff Spirko submitted the following contribution: ==== I'm having a problem with lapw1 in a large (> 1 GB RAM, 10000 matrix size, RKM=7.0) job. I have already checked the available RAM, diskspace, and stack size. Version: WIEN2k_02 from Oct 24, 2002 Computer: Pentium IV with 2 GB RDRAM Operating System: Redhat Linux 8.0 Compiler: IFC 6.0 FOPT: -O0 -FR -mp -w -tpp7 LDFLAGS: -Vaxlib -L../SRC_lib R_LIBS: -llapack_lapw -lmkl_p4 -lguide -lpthread I have successfully run the job on an SGI, and I just transferred over the .struct, .in*, .kgen, .klist, and .clmsum files. When lapw1c runs, after about 2 hours it crashes with the following message printed to the screen: ** Address Error ** End of diagnostics If I decrease the matrix size by reducing NMATMAX to 5000, so it's only a 500 MB job, it runs fine. Any ideas on why this would be happening? - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 08 Nov 2002 19:41:44 +0200 From: thor Subject: Re: [WIEN]: automatic geometry optimisation ==== thor submitted the following contribution: ==== Well, it is the best available option. The only other one is 'by hand', writing your own automatisation scripts. Anyway, it is not so difficult to use, once it is started. It is, however, rather expensive, but if you want to do optimisation of the internal parameters in the structure, it is the only way to do it. It seems like vasp takes just as long time (at least for systems containing W and Fe), and what comes out of it says more about the pseudopotential than about the structure :-( The terms of the Hamiltonian that would make it 'do it by itself' are generally left out in DFT, and they would probably make it much slower, if at all possible. Did that answer your question? Best regards, Torsten Andersen. chen0130@flinders.edu.au wrote: > ==== > chen0130@flinders.edu.au > submitted the following contribution: > ==== > > Thanks, I guess I am asking a silly question, but my emphasis is on > 'automatic'! (ie something done in symmetry?) without the expensive mini_lapw > > could someone suggest some generic reasons why geometry optimisations are not > necessarily performed for solid state structures? > > there seems to be publications without relaxing supercells... > > sorry to be so broad, appreciating any remarks, > > Thanks, > > Cheng > > Quoting Torsten Andersen : > > > ==== > > Torsten Andersen > > submitted the following contribution: > > ==== > > > > min_lapw and mini (see, e.g., sec. 8.14 in UG). > > > > chen0130@flinders.edu.au wrote: > > > > >==== > > >chen0130@flinders.edu.au > > >submitted the following contribution: > > >==== > > > > > >Dear Wien users, > > > > > >Can any one tell me if there is any automatic geometry optimisation of any > > > > >degree in Wien97? > > > > > >Thanks > > > > > >Cheng > > > > > > > > >==== > > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > >To (un)subscribe send mail to > > >majordomo@zeus.theochem.tuwien.ac.at > > >==== > > > > > > > > > > -- > > Dr. Torsten Andersen > > Department of Physics, Condensed Matter Theory Group, Uppsala University > > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace > > News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics > > > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 16:06:35 -0600 (CST) From: Bing Zhou Subject: [WIEN]: dstart problem ==== Bing Zhou submitted the following contribution: ==== Dear All: After I run "run_lapw" for my mineral thomsenolite with H2O in the unit cell, I was told: no thomsenolite.clmsum(_old) file found, which is necessary for lapw0 ! So I re-run dstart, I meet such a problem as in dstart.error: 'DSTART' - can't open unit: 15 'DSTART' - filename: thomsenolite.in2 'DSTART' - status: old form: formatted Could you please help me out? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 8 Nov 2002 17:22:39 -0600 (CST) From: Bing Zhou Subject: [WIEN]: dstart problem ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-1804928587-1036797759=:14957 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi again: I attach the case.struct and case.inst files with this email for help. Dear All: After I run "run_lapw" for my mineral thomsenolite with H2O in the unit cell, I was told: no thomsenolite.clmsum(_old) file found, which is necessary for lapw0 ! So I re-run dstart, I meet such a problem as in dstart.error: 'DSTART' - can't open unit: 15 'DSTART' - filename: thomsenolite.in2 'DSTART' - status: old form: formatted Could you please help me out? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 - ---559023410-1804928587-1036797759=:14957 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="thomsenolite.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="thomsenolite.struct" VGhvbXNlbm9saXRlIHN0cnVjdHVyZSBkYXRhIGZyb20gQ2FuLiBKLiBDaGVt LiwgMTk4NSAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KUCAgIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOjEyICAgICAgICAgICAgICAgICAgICAgIDE0 IFAyMS9jICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDEwLjUxMjU1MSAxMC40NzA5NzcgMzAuNDUy OTQ5IDkwLjAwMDAwMCA5Ni4zMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4yNTQ1MDAwMCBZPTAuMTQ1NDAwMDAg Wj0wLjI0ODQwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BM SVQ9IDgNCiAgICAgIC0xOiBYPTAuNzQ1NTAwMDAgWT0wLjg1NDYwMDAwIFo9 MC43NTE2MDAwMA0KICAgICAgLTE6IFg9MC43NDU1MDAwMCBZPTAuNjQ1NDAw MDAgWj0wLjI1MTYwMDAwDQogICAgICAtMTogWD0wLjI1NDUwMDAwIFk9MC4z NTQ2MDAwMCBaPTAuNzQ4NDAwMDANCk5hICAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDUwMDAwIFJNVD0gICAgMi44MDAwICAgWjogIDAuMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBY PTAuMTg5NDAwMDAgWT0wLjY3NDUwMDAwIFo9MC4wOTkwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4DQogICAgICAtMjogWD0w LjgxMDYwMDAwIFk9MC4zMjU1MDAwMCBaPTAuOTAxMDAwMDANCiAgICAgIC0y OiBYPTAuODEwNjAwMDAgWT0wLjE3NDUwMDAwIFo9MC40MDEwMDAwMA0KICAg ICAgLTI6IFg9MC4xODk0MDAwMCBZPTAuODI1NTAwMDAgWj0wLjU5OTAwMDAw DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAg IDIuODAwMCAgIFo6IDIwLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPSAtMzogWD0wLjcxNzcwMDAwIFk9MC4xNzk2 MDAwMCBaPTAuMTM5MTAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAg IElTUExJVD0gOA0KICAgICAgLTM6IFg9MC4yODIzMDAwMCBZPTAuODIwNDAw MDAgWj0wLjg2MDkwMDAwDQogICAgICAtMzogWD0wLjI4MjMwMDAwIFk9MC42 Nzk2MDAwMCBaPTAuMzYwOTAwMDANCiAgICAgIC0zOiBYPTAuNzE3NzAwMDAg WT0wLjMyMDQwMDAwIFo9MC42MzkxMDAwMA0KQWwgICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjgwMDAgICBaOiAxMy4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0g LTQ6IFg9MC41NDk2MDAwMCBZPTAuNDY0MzAwMDAgWj0wLjEyNjcwMDAwDQog ICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC00 OiBYPTAuNDUwNDAwMDAgWT0wLjUzNTcwMDAwIFo9MC44NzMzMDAwMA0KICAg ICAgLTQ6IFg9MC40NTA0MDAwMCBZPTAuOTY0MzAwMDAgWj0wLjM3MzMwMDAw DQogICAgICAtNDogWD0wLjU0OTYwMDAwIFk9MC4wMzU3MDAwMCBaPTAuNjI2 NzAwMDANCkYgICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJN VD0gICAgMS40MDAwICAgWjogIDkuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC01OiBYPTAuOTg4MDAwMDAgWT0w LjM2NTEwMDAwIFo9MC4xNTYzMDAwMA0KICAgICAgICAgIE1VTFQ9IDQgICAg ICAgICAgSVNQTElUPSA4DQogICAgICAtNTogWD0wLjAxMjAwMDAwIFk9MC42 MzQ5MDAwMCBaPTAuODQzNzAwMDANCiAgICAgIC01OiBYPTAuMDEyMDAwMDAg WT0wLjg2NTEwMDAwIFo9MC4zNDM3MDAwMA0KICAgICAgLTU6IFg9MC45ODgw MDAwMCBZPTAuMTM0OTAwMDAgWj0wLjY1NjMwMDAwDQpGICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNDAwMCAgIFo6ICA5 LjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAx LjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAg ICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpB VE9NPSAtNjogWD0wLjQ0MDgwMDAwIFk9MC4wMTAyMDAwMCBaPTAuMTI3MzAw MDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KICAg ICAgLTY6IFg9MC41NTkyMDAwMCBZPTAuOTg5ODAwMDAgWj0wLjg3MjcwMDAw DQogICAgICAtNjogWD0wLjU1OTIwMDAwIFk9MC41MTAyMDAwMCBaPTAuMzcy NzAwMDANCiAgICAgIC02OiBYPTAuNDQwODAwMDAgWT0wLjQ4OTgwMDAwIFo9 MC42MjczMDAwMA0KRiAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAw MDAgUk1UPSAgICAxLjQwMDAgICBaOiAgOS4wICAgICAgICAgICAgICAgICAg IA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTc6IFg9MC45MDM5MDAw MCBZPTAuOTE2NjAwMDAgWj0wLjE1NzYwMDAwDQogICAgICAgICAgTVVMVD0g NCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC03OiBYPTAuMDk2MTAwMDAg WT0wLjA4MzQwMDAwIFo9MC44NDI0MDAwMA0KICAgICAgLTc6IFg9MC4wOTYx MDAwMCBZPTAuNDE2NjAwMDAgWj0wLjM0MjQwMDAwDQogICAgICAtNzogWD0w LjkwMzkwMDAwIFk9MC41ODM0MDAwMCBaPTAuNjU3NjAwMDANCkYgICAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS40MDAwICAg WjogIDkuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkFUT009IC04OiBYPTAuNjg3MzAwMDAgWT0wLjE5ODUwMDAwIFo9MC4y NDk3MDAwMA0KICAgICAgICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4 DQogICAgICAtODogWD0wLjMxMjcwMDAwIFk9MC44MDE1MDAwMCBaPTAuNzUw MzAwMDANCiAgICAgIC04OiBYPTAuMzEyNzAwMDAgWT0wLjY5ODUwMDAwIFo9 MC4yNTAzMDAwMA0KICAgICAgLTg6IFg9MC42ODczMDAwMCBZPTAuMzAxNTAw MDAgWj0wLjc0OTcwMDAwDQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4w MDAxMDAwMCBSTVQ9ICAgIDEuNDAwMCAgIFo6ICA5LjAgICAgICAgICAgICAg ICAgICAgDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtOTogWD0wLjcz NTcwMDAwIFk9MC4xNjY4MDAwMCBaPTAuMDI5NDAwMDANCiAgICAgICAgICBN VUxUPSA0ICAgICAgICAgIElTUExJVD0gOA0KICAgICAgLTk6IFg9MC4yNjQz MDAwMCBZPTAuODMzMjAwMDAgWj0wLjk3MDYwMDAwDQogICAgICAtOTogWD0w LjI2NDMwMDAwIFk9MC42NjY4MDAwMCBaPTAuNDcwNjAwMDANCiAgICAgIC05 OiBYPTAuNzM1NzAwMDAgWT0wLjMzMzIwMDAwIFo9MC41Mjk0MDAwMA0KRiAg ICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjQw MDAgICBaOiAgOS4wICAgICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0tMTA6IFg9MC44MDA4MDAwMCBZPTAuNjU5OTAwMDAg Wj0wLjAwNTkwMDAwDQogICAgICAgICAgTVVMVD0gNCAgICAgICAgICBJU1BM SVQ9IDgNCiAgICAgLTEwOiBYPTAuMTk5MjAwMDAgWT0wLjM0MDEwMDAwIFo9 MC45OTQxMDAwMA0KICAgICAtMTA6IFg9MC4xOTkyMDAwMCBZPTAuMTU5OTAw MDAgWj0wLjQ5NDEwMDAwDQogICAgIC0xMDogWD0wLjgwMDgwMDAwIFk9MC44 NDAxMDAwMCBaPTAuNTA1OTAwMDANCk8gICAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDEwMDAwIFJNVD0gICAgMS4xMDAwICAgWjogIDguMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009LTExOiBY PTAuNzM1NDAwMDAgWT0wLjYyMjMwMDAwIFo9MC4wNTgzMDAwMA0KICAgICAg ICAgIE1VTFQ9IDQgICAgICAgICAgSVNQTElUPSA4DQogICAgIC0xMTogWD0w LjI2NDYwMDAwIFk9MC4zNzc3MDAwMCBaPTAuOTQxNzAwMDANCiAgICAgLTEx OiBYPTAuMjY0NjAwMDAgWT0wLjEyMjMwMDAwIFo9MC40NDE3MDAwMA0KICAg ICAtMTE6IFg9MC43MzU0MDAwMCBZPTAuODc3NzAwMDAgWj0wLjU1ODMwMDAw DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDAuNzAwMCAgIFo6ICAxLjAgICAgICAgICAgICAgICAgICAgDQpMT0NBTCBS T1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0K ICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAw MDAgMS4wMDAwMDAwDQpBVE9NPS0xMjogWD0wLjc0ODYwMDAwIFk9MC44MjE2 MDAwMCBaPTAuOTg3MzAwMDANCiAgICAgICAgICBNVUxUPSA0ICAgICAgICAg IElTUExJVD0gOA0KICAgICAtMTI6IFg9MC4yNTE0MDAwMCBZPTAuMTc4NDAw MDAgWj0wLjAxMjcwMDAwDQogICAgIC0xMjogWD0wLjI1MTQwMDAwIFk9MC4z MjE2MDAwMCBaPTAuNTEyNzAwMDANCiAgICAgLTEyOiBYPTAuNzQ4NjAwMDAg WT0wLjY3ODQwMDAwIFo9MC40ODczMDAwMA0KSCAgICAgICAgICBOUFQ9ICA3 ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAwLjcwMDAgICBaOiAgMS4wICAg ICAgICAgICAgICAgICAgIA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAg IDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgNCAg ICAgIE5VTUJFUiBPRiBTWU1NRVRSWSBPUEVSQVRJT05TDQotMSAwIDAgMC4w MDAwMDAwDQogMC0xIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAwDQog ICAgICAgMQ0KIDEgMCAwIDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0K IDAgMCAxIDAuMDAwMDAwMA0KICAgICAgIDINCi0xIDAgMCAwLjAwMDAwMDAN CiAwIDEgMCAwLjUwMDAwMDANCiAwIDAtMSAwLjUwMDAwMDANCiAgICAgICAz DQogMSAwIDAgMC4wMDAwMDAwDQogMC0xIDAgMC41MDAwMDAwDQogMCAwIDEg MC41MDAwMDAwDQogICAgICAgNA0K - ---559023410-1804928587-1036797759=:14957 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="thomsenolite.inst" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="thomsenolite.inst" TmEgDQpOZSAxIDUNCjMsLTEsMS4wICBODQozLC0xLDAuMCAgTg0KQ2EgDQpB ciAxIDUNCjQsLTEsMS4wICBODQo0LC0xLDEuMCAgTg0KQWwgDQpOZSAyIDUN CjMsLTEsMS4wICBODQozLC0xLDEuMCAgTg0KMywgMSwxLjAgIE4NCjMsIDEs MC4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MS4wICBODQpPIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4N CjIsIDEsMS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIs MC4wICBODQpIIA0KMSA1DQoxLC0xLDAuOSAgTg0KMSwtMSwwLjEgIE4NCkgg DQoxIDUNCjEsLTEsMC45ICBODQoxLC0xLDAuMSAgTg0KKioqKiAgICAgRW5k IG9mIElucHV0DQoqKioqICAgICBFbmQgb2YgSW5wdXQNCg== - ---559023410-1804928587-1036797759=:14957-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 9 Nov 2002 08:57:51 +0330 From: "akbarzad" Subject: [WIEN]: Fellowship at Isfahan University of Technology ==== "akbarzad" submitted the following contribution: ==== Fellowship available at Isfahan University of Technology The computational condensed matter group physics department of Isfahan University of Technology (IUT) is going to expand its regional scientific activity by acting as an ICTP Affiliated Centre. Following such a mission, the Abdus Salam International Centre for Theoretical Physics (ICTP) and IUT have agreed to support the below mentioned fellowships for the year 2003: One) 2 Fellowship for young researchers ( possessing a PhD degree or at the final stages of getting it) from the regional countries (Western South Asia, Central Asia, and Middle East ) to come and work in the center as long term visitors (3-6 months). Two) 2 Fellowship for senior researchers from the regional countries to come and work in the center as short term visitors (4-12 weeks). The applicants are expected to have a keen interest in computational condensed matter physics, with some hands on experience on first principle methods. The fellowships are available from 1st of January 2003. Applications including, a full CV, a list of publications, an abstract of her/his research achievements (within one page of an A4 sheet), a proposal of about 500 words explaining the details of the research project that the applicant is going to perform during the stay in the center, and names and addresses (email) of two or three referees should be sent to the following address: Professor Hadi Akbarzadeh Department of Physics , Isfahan University of Technology, Isfahan, Iran email: akbarzad@cc.iut.ac.ir, Tel: +98-311-3912375 (or 3913700), fax: +98-311-3912376. Accepted candidates are entitled for the following supports: 1. Travel expenses by economy round trip air ticket. 2. Accommodation in IUT Guest House. 3. 400 Euro per month for living expenses ( For senior researchers it can be increased to 500 Euro). 4. One full meal per day. Current research interests of the center Electronic structure calculations, as a valuable tool for understanding the properties of condensed matter, are the main current activity in the computational condensed matter group in physics department of Isfahan University of Technology. Our calculations are within the density functional theory using FP-LAPW method. We have access and hands on experience to work with WIEN2k code (www.wien2k.at). This general purpose electronic structure code is a very appropriate tool to calculate many properties of a solid: band structure, density of states, equilibrium geometry, magnetic structure, electric-field gradients, hyperfine fields, and X-ray spectra, etc. The code contains LDA+U to study highly correlated systems. The ongoing research projects in the group are as follow: 1. Structural, electronic and magnetic properties of MnAs. 2. Structural and electronic properties of CeFe2. 3. Investigation the valency of rare earth elements in RIn3 and RSn3: Ab initio analysis of electric field gradients 4. Investigation of the valency of Actanides in USn3, UIn3, and NpIn3 by ab-initio methods. 5. First principle calculation of hyperfine fields and local relaxation at 4d and 5sp impurities in bcc Cr. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 9 Nov 2002 15:22:16 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear all, I am sorry that I already have question with WIEN97. Actually, I would like to put the same molecule (20 carbon atoms) in boxes with different dimensions and perform the calculations. And all the 3 inputed .struct files with only 1 inequivalent atom (I just list all the 20 carbon atoms together). However, WIEN97 classifies this 3 cases differently. Why? For my input value of nn=2 for all 3 cases. Case 1 : The box's dimensions are 10AX10AX2.46124419755538A After NN, WIEN97 generates 10 inequvialent atoms to me. Case 2 : The box's dimensions are 12AX12AX2.46124419755538A After NN, WIEN97 generates 8 inequivalent atoms to me. Case 3 : The box's dimensions are 14AX14AX2.46124419755538A After NN, WIEN97 generates 1 inequivalent atoms to me. I have attached the following files with the mail. original.xyz ------ original XYZ coordinates file case10A.struct_init ------ initial .struct file inputed by my own with the box's dimension of 10X10X2.461244 case12A.struct_init ------ initial .struct file inputed by my own with the box's dimension of 12X12X2.461244 case14A.struct_orig ------ initial .struct file inputed by my own with the box's dimension of 14X14X2.461244 case10A.struct ------ .struct file generated by WIEN97 after NN with the box's dimension of 10X10X2.461244 case12A.struct ------ .struct file generated by WIEN97 after NN with the box's dimension of 12X12X2.461244 case14A.struct ------ .struct file generated by WIEN97 after NN with the box's dimension of 14X14X2.461244 Thank you very much Martin - --143914132-1593261418-1036826536=:16879 Content-Type: chemical/x-pdb; name="original.xyz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="original.xyz" ICAgMjAKCiBDICAzLjM5MjM4NzYxMjAwMzc1ICAwLjAwMDAwMDAwMDAwMDAw MCAgMC4wMDAwMDAwMDAwMDAwMDAKIEMgIDMuMDk5MTAwMjkzNTA5MDYgIDEu Mzc5ODA4MzQ5MzE4MzQgIDAuMDAwMDAwMDAwMDAwMDAwCiBDICAyLjc0NDQ5 OTIyOTYxODA4ICAxLjk5Mzk5NTQwODM5NTQ4IC0xLjIzMDYyMjA5ODc3NzY5 CiBDICAxLjY5NjE5MzgwNjAwMTg4ICAyLjkzNzg5Mzg1MTQ3ODg3IC0xLjIz MDYyMjA5ODc3NzY5CiBDICAxLjA0ODMwNTQyMzYxNjIwICAzLjIyNjM1MjM0 NDE5NTEyICAwLjAwMDAwMDAwMDAwMDAwMAogQyAtMC4zNTQ2MDEwNjM4OTA5 NzYgIDMuMzczODAzNzU3NzEzODIgIDAuMDAwMDAwMDAwMDAwMDAwCiBDIC0x LjA0ODMwNTQyMzYxNjIwICAzLjIyNjM1MjM0NDE5NTEyIC0xLjIzMDYyMjA5 ODc3NzY5CiBDIC0yLjI2OTk1MDM3OTgyNDM1ICAyLjUyMTAzNTI5OTg3NDIw IC0xLjIzMDYyMjA5ODc3NzY5CiBDIC0yLjc0NDQ5OTIyOTYxODA4ICAxLjk5 Mzk5NTQwODM5NTQ4ICAwLjAwMDAwMDAwMDAwMDAwMAogQyAtMy4zMTgyNTU4 MDM0NDA1NSAgMC43MDUzMTcwNDQzMjA5MjAgIDAuMDAwMDAwMDAwMDAwMDAw CiBDIC0zLjM5MjM4NzYxMjAwMzc1ICA0LjE1NDMzOTQyNDI4ODExMkUtMDE2 IC0xLjIzMDYyMjA5ODc3NzY5CiBDIC0zLjA5OTEwMDI5MzUwOTA2IC0xLjM3 OTgwODM0OTMxODMzIC0xLjIzMDYyMjA5ODc3NzY5CiBDIC0yLjc0NDQ5OTIy OTYxODA4IC0xLjk5Mzk5NTQwODM5NTQ4ICAwLjAwMDAwMDAwMDAwMDAwMAog QyAtMS42OTYxOTM4MDYwMDE4OCAtMi45Mzc4OTM4NTE0Nzg4NyAgMC4wMDAw MDAwMDAwMDAwMDAKIEMgLTEuMDQ4MzA1NDIzNjE2MjAgLTMuMjI2MzUyMzQ0 MTk1MTIgLTEuMjMwNjIyMDk4Nzc3NjkKIEMgIDAuMzU0NjAxMDYzODkwOTc1 IC0zLjM3MzgwMzc1NzcxMzgyIC0xLjIzMDYyMjA5ODc3NzY5CiBDICAxLjA0 ODMwNTQyMzYxNjIwIC0zLjIyNjM1MjM0NDE5NTEyICAwLjAwMDAwMDAwMDAw MDAwMAogQyAgMi4yNjk5NTAzNzk4MjQzNSAtMi41MjEwMzUyOTk4NzQyMCAg MC4wMDAwMDAwMDAwMDAwMDAKIEMgIDIuNzQ0NDk5MjI5NjE4MDggLTEuOTkz OTk1NDA4Mzk1NDggLTEuMjMwNjIyMDk4Nzc3NjkKIEMgIDMuMzE4MjU1ODAz NDQwNTUgLTAuNzA1MzE3MDQ0MzIwOTIyIC0xLjIzMDYyMjA5ODc3NzY5Cg== - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case10A.struct_init" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case10A.struct_init" Y250NTUxMEENClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogMQ0KTU9E RSBPRiBDQUxDPVJFTEENCiAxOC44OTcyNjkgMTguODk3MjY5ICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQXRvbT0gLTE6IFg9 MC44MzkyMzg3NiBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0yMCAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC0xOiBYPTAu ODA5OTEwMDMgWT0wLjYzNzk4MDgzIFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC43NzQ0NDk5MiBZPTAuNjk5Mzk5NTQgWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjY2OTYxOTM4IFk9MC43OTM3ODkzOSBaPTAuMjUwMDAwMDAN CkF0b209IC0xOiBYPTAuNjA0ODMwNTQgWT0wLjgyMjYzNTIzIFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC40NjQ1Mzk4OSBZPTAuODM3MzgwMzggWj0w Ljc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjM5NTE2OTQ2IFk9MC44MjI2MzUy MyBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuMjczMDA0OTYgWT0wLjc1 MjEwMzUzIFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4yMjU1NTAwOCBZ PTAuNjk5Mzk5NTQgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjE2ODE3 NDQyIFk9MC41NzA1MzE3MCBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBYPTAu MTYwNzYxMjQgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC4xOTAwODk5NyBZPTAuMzYyMDE5MTcgWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjIyNTU1MDA4IFk9MC4zMDA2MDA0NiBaPTAuNzUwMDAwMDAN CkF0b209IC0xOiBYPTAuMzMwMzgwNjIgWT0wLjIwNjIxMDYxIFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC4zOTUxNjk0NiBZPTAuMTc3MzY0NzcgWj0w LjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUzNTQ2MDExIFk9MC4xNjI2MTk2 MiBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuNjA0ODMwNTQgWT0wLjE3 NzM2NDc3IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC43MjY5OTUwNCBZ PTAuMjQ3ODk2NDcgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjc3NDQ0 OTkyIFk9MC4zMDA2MDA0NiBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAu ODMxODI1NTggWT0wLjQyOTQ2ODMwIFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjMwMDAgICBa OiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAwIFNZTU1FVFJZIE9Q RVJBVElPTlM6DQo= - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case12A.struct_init" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case12A.struct_init" Y250NTUxMEENClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogMQ0KTU9E RSBPRiBDQUxDPVJFTEENCiAyMi42NzY3MjMgMjIuNjc2NzIzICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQXRvbT0gLTE6IFg9 MC43ODI2OTg5NyBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0yMCAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC0xOiBYPTAu NzU4MjU4MzYgWT0wLjYxNDk4NDAzIFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC43Mjg3MDgyNyBZPTAuNjY2MTY2MjggWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjY0MTM0OTQ4IFk9MC43NDQ4MjQ0OSBaPTAuMjUwMDAwMDAN CkF0b209IC0xOiBYPTAuNTg3MzU4NzkgWT0wLjc2ODg2MjcwIFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC40NzA0NDk5MSBZPTAuNzgxMTUwMzEgWj0w Ljc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjQxMjY0MTIxIFk9MC43Njg4NjI3 MCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuMzEwODM3NDcgWT0wLjcx MDA4NjI3IFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4yNzEyOTE3MyBZ PTAuNjY2MTY2MjggWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjIyMzQ3 ODY4IFk9MC41NTg3NzY0MiBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBYPTAu MjE3MzAxMDMgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC4yNDE3NDE2NCBZPTAuMzg1MDE1OTcgWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjI3MTI5MTczIFk9MC4zMzM4MzM3MiBaPTAuNzUwMDAwMDAN CkF0b209IC0xOiBYPTAuMzU4NjUwNTIgWT0wLjI1NTE3NTUxIFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC40MTI2NDEyMSBZPTAuMjMxMTM3MzAgWj0w LjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUyOTU1MDA5IFk9MC4yMTg4NDk2 OSBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuNTg3MzU4NzkgWT0wLjIz MTEzNzMwIFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC42ODkxNjI1MyBZ PTAuMjg5OTEzNzMgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjcyODcw ODI3IFk9MC4zMzM4MzM3MiBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAu Nzc2NTIxMzIgWT0wLjQ0MTIyMzU4IFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjMwMDAgICBa OiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAwIFNZTU1FVFJZIE9Q RVJBVElPTlM6DQo= - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case14A.struct_orig" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case14A.struct_orig" Y250NTUxNEENClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogMQ0KTU9E RSBPRiBDQUxDPVJFTEENCiAyNi40NTYxNzYgMjYuNDU2MTc2ICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQXRvbT0gLTE6IFg9 MC43NDIzMTM0MCBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0yMCAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC0xOiBYPTAu NzIxMzY0MzEgWT0wLjU5ODU1Nzc0IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC42OTYwMzU2NiBZPTAuNjQyNDI4MjQgWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjYyMTE1NjcwIFk9MC43MDk4NDk1NiBaPTAuMjUwMDAwMDAN CkF0b209IC0xOiBYPTAuNTc0ODc4OTYgWT0wLjczMDQ1Mzc0IFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC40NzQ2NzEzNSBZPTAuNzQwOTg1OTggWj0w Ljc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjQyNTEyMTA0IFk9MC43MzA0NTM3 NCBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuMzM3ODYwNjkgWT0wLjY4 MDA3Mzk1IFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6IFg9MC4zMDM5NjQzNCBZ PTAuNjQyNDI4MjQgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjI2Mjk4 MTczIFk9MC41NTAzNzk3OSBaPTAuNzUwMDAwMDANCkF0b209IC0xOiBYPTAu MjU3Njg2NjAgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KQXRvbT0gLTE6 IFg9MC4yNzg2MzU2OSBZPTAuNDAxNDQyMjYgWj0wLjI1MDAwMDAwDQpBdG9t PSAtMTogWD0wLjMwMzk2NDM0IFk9MC4zNTc1NzE3NiBaPTAuNzUwMDAwMDAN CkF0b209IC0xOiBYPTAuMzc4ODQzMzAgWT0wLjI5MDE1MDQ0IFo9MC43NTAw MDAwMA0KQXRvbT0gLTE6IFg9MC40MjUxMjEwNCBZPTAuMjY5NTQ2MjYgWj0w LjI1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjUyNTMyODY1IFk9MC4yNTkwMTQw MiBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAuNTc0ODc4OTYgWT0wLjI2 OTU0NjI2IFo9MC43NTAwMDAwMA0KQXRvbT0gLTE6IFg9MC42NjIxMzkzMSBZ PTAuMzE5OTI2MDUgWj0wLjc1MDAwMDAwDQpBdG9tPSAtMTogWD0wLjY5NjAz NTY2IFk9MC4zNTc1NzE3NiBaPTAuMjUwMDAwMDANCkF0b209IC0xOiBYPTAu NzM3MDE4MjcgWT0wLjQ0OTYyMDIxIFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjMwMDAgICBa OiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAwIFNZTU1FVFJZIE9Q RVJBVElPTlM6DQo= - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case14A.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case14A.struct" Y250NTUxNEENClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogMQ0KTU9E RSBPRiBDQUxDPVJFTEENCiAyNi40NTYxNzYgMjYuNDU2MTc2ICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQVRPTT0gLTE6IFg9 MC43NDIzMTM0MCBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0yMCAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC0xOiBYPTAu NzIxMzY0MzEgWT0wLjU5ODU1Nzc0IFo9MC43NTAwMDAwMA0KICAgICAgLTE6 IFg9MC42OTYwMzU2NiBZPTAuNjQyNDI4MjQgWj0wLjI1MDAwMDAwDQogICAg ICAtMTogWD0wLjYyMTE1NjcwIFk9MC43MDk4NDk1NiBaPTAuMjUwMDAwMDAN CiAgICAgIC0xOiBYPTAuNTc0ODc4OTYgWT0wLjczMDQ1Mzc0IFo9MC43NTAw MDAwMA0KICAgICAgLTE6IFg9MC40NzQ2NzEzNSBZPTAuNzQwOTg1OTggWj0w Ljc1MDAwMDAwDQogICAgICAtMTogWD0wLjQyNTEyMTA0IFk9MC43MzA0NTM3 NCBaPTAuMjUwMDAwMDANCiAgICAgIC0xOiBYPTAuMzM3ODYwNjkgWT0wLjY4 MDA3Mzk1IFo9MC4yNTAwMDAwMA0KICAgICAgLTE6IFg9MC4zMDM5NjQzNCBZ PTAuNjQyNDI4MjQgWj0wLjc1MDAwMDAwDQogICAgICAtMTogWD0wLjI2Mjk4 MTczIFk9MC41NTAzNzk3OSBaPTAuNzUwMDAwMDANCiAgICAgIC0xOiBYPTAu MjU3Njg2NjAgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KICAgICAgLTE6 IFg9MC4yNzg2MzU2OSBZPTAuNDAxNDQyMjYgWj0wLjI1MDAwMDAwDQogICAg ICAtMTogWD0wLjMwMzk2NDM0IFk9MC4zNTc1NzE3NiBaPTAuNzUwMDAwMDAN CiAgICAgIC0xOiBYPTAuMzc4ODQzMzAgWT0wLjI5MDE1MDQ0IFo9MC43NTAw MDAwMA0KICAgICAgLTE6IFg9MC40MjUxMjEwNCBZPTAuMjY5NTQ2MjYgWj0w LjI1MDAwMDAwDQogICAgICAtMTogWD0wLjUyNTMyODY1IFk9MC4yNTkwMTQw MiBaPTAuMjUwMDAwMDANCiAgICAgIC0xOiBYPTAuNTc0ODc4OTYgWT0wLjI2 OTU0NjI2IFo9MC43NTAwMDAwMA0KICAgICAgLTE6IFg9MC42NjIxMzkzMSBZ PTAuMzE5OTI2MDUgWj0wLjc1MDAwMDAwDQogICAgICAtMTogWD0wLjY5NjAz NTY2IFk9MC4zNTc1NzE3NiBaPTAuMjUwMDAwMDANCiAgICAgIC0xOiBYPTAu NzM3MDE4MjcgWT0wLjQ0OTYyMDIxIFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjMwMDAgICBa OiAgNi4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAwIFNZTU1FVFJZIE9Q RVJBVElPTlM6DQo= - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case12A.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case12A.struct" Y250NTUxMEENClAgICBMQVRUSUNFLE5PTkVRVUlWLiBBVE9NUzogOA0KTU9E RSBPRiBDQUxDPVJFTEENCiAyMi42NzY3MjMgMjIuNjc2NzIzICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQXRvbT0gLTE6IFg9 MC43ODI2OTg5NyBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC0xOiBYPTAu MjE3MzAxMDMgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBa OiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBdG9tPSAtMjogWD0wLjc1 ODI1ODM2IFk9MC42MTQ5ODQwMyBaPTAuNzUwMDAwMDANCiAgICAgICAgICBN VUxUPSAyICAgICAgICAgIElTUExJVD0gOA0KQXRvbT0gLTI6IFg9MC4yNDE3 NDE2NCBZPTAuMzg1MDE1OTcgWj0wLjI1MDAwMDAwDQpDICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA2 LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4w MDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC0zOiBYPTAuNzI4NzA4 MjcgWT0wLjY2NjE2NjI4IFo9MC4yNTAwMDAwMA0KICAgICAgICAgIE1VTFQ9 IDYgICAgICAgICAgSVNQTElUPSA4DQpBdG9tPSAtMzogWD0wLjMxMDgzNzQ3 IFk9MC43MTAwODYyNyBaPTAuMjUwMDAwMDANCkF0b209IC0zOiBYPTAuMjcx MjkxNzMgWT0wLjY2NjE2NjI4IFo9MC43NTAwMDAwMA0KQXRvbT0gLTM6IFg9 MC4yNzEyOTE3MyBZPTAuMzMzODMzNzIgWj0wLjc1MDAwMDAwDQpBdG9tPSAt MzogWD0wLjY4OTE2MjUzIFk9MC4yODk5MTM3MyBaPTAuNzUwMDAwMDANCkF0 b209IC0zOiBYPTAuNzI4NzA4MjcgWT0wLjMzMzgzMzcyIFo9MC4yNTAwMDAw MA0KQyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAg ICAxLjIwMDAgICBaOiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAw MDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAg ICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBdG9t PSAtNDogWD0wLjY0MTM0OTQ4IFk9MC43NDQ4MjQ0OSBaPTAuMjUwMDAwMDAN CiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0gOA0KQXRvbT0g LTQ6IFg9MC4zNTg2NTA1MiBZPTAuMjU1MTc1NTEgWj0wLjc1MDAwMDAwDQpD ICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEu MjAwMCAgIFo6ICA2LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAw MCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAg ICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC01 OiBYPTAuNTg3MzU4NzkgWT0wLjc2ODg2MjcwIFo9MC43NTAwMDAwMA0KICAg ICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4DQpBdG9tPSAtNTog WD0wLjQxMjY0MTIxIFk9MC4yMzExMzczMCBaPTAuMjUwMDAwMDANCkMgICAg ICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAw ICAgWjogIDYuMA0KICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAu MDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAw MDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQXRvbT0gLTY6IFg9 MC40NzA0NDk5MSBZPTAuNzgxMTUwMzEgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgNCkF0b209IC02OiBYPTAu NTI5NTUwMDkgWT0wLjIxODg0OTY5IFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1UPSAgICAxLjIwMDAgICBa OiAgNi4wDQogICAgICAgICAgICAgICAgICAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBdG9tPSAtNzogWD0wLjQx MjY0MTIxIFk9MC43Njg4NjI3MCBaPTAuMjUwMDAwMDANCiAgICAgICAgICBN VUxUPSAyICAgICAgICAgIElTUExJVD0gOA0KQXRvbT0gLTc6IFg9MC41ODcz NTg3OSBZPTAuMjMxMTM3MzAgWj0wLjc1MDAwMDAwDQpDICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMjAwMCAgIFo6ICA2 LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4w MDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC04OiBYPTAuMjIzNDc4 NjggWT0wLjU1ODc3NjQyIFo9MC43NTAwMDAwMA0KICAgICAgICAgIE1VTFQ9 IDIgICAgICAgICAgSVNQTElUPSA4DQpBdG9tPSAtODogWD0wLjc3NjUyMTMy IFk9MC40NDEyMjM1OCBaPTAuMjUwMDAwMDANCkMgICAgICAgICAgTlBUPSAg NzgxICBSMD0wLjAwMDEwMDAwIFJNVD0gICAgMS4yMDAwICAgWjogIDYuMA0K ICAgICAgICAgICAgICAgICAgICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MC4wMDAwMDAwIDEuMDAwMDAwMA0KICAgMCBTWU1NRVRSWSBPUEVSQVRJT05T Og0K - --143914132-1593261418-1036826536=:16879 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="case10A.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="case10A.struct" Y250NTUxMEENClAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMA0KICAg ICAgICAgICAgIFJFTEENCiAxOC44OTcyNjkgMTguODk3MjY5ICA0LjY1MTA3 OSA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMA0KQVRPTT0gLTE6IFg9 MC44MzkyMzg3NiBZPTAuNTAwMDAwMDAgWj0wLjc1MDAwMDAwDQogICAgICAg ICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC0xOiBYPTAu MTYwNzYxMjQgWT0wLjUwMDAwMDAwIFo9MC4yNTAwMDAwMA0KQyAgICAgICAg ICAgICAgICA3ODEgICAgIDAuMDAwMTAwMDAgICAgICAgICAxLjMwMDAgICAg ICAgNi4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAu MDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtMjogWD0wLjgw OTkxMDAzIFk9MC42Mzc5ODA4MyBaPTAuNzUwMDAwMDANCiAgICAgICAgICBN VUxUPSAyICAgICAgICAgIElTUExJVD0gOA0KICAgICAgLTI6IFg9MC4xOTAw ODk5NyBZPTAuMzYyMDE5MTcgWj0wLjI1MDAwMDAwDQpDICAgICAgICAgICAg ICAgIDc4MSAgICAgMC4wMDAxMDAwMCAgICAgICAgIDEuMzAwMCAgICAgICA2 LjANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAg MC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4w MDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAw MDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0zOiBYPTAuNzc0NDQ5 OTIgWT0wLjY5OTM5OTU0IFo9MC4yNTAwMDAwMA0KICAgICAgICAgIE1VTFQ9 IDIgICAgICAgICAgSVNQTElUPSA4DQogICAgICAtMzogWD0wLjIyNTU1MDA4 IFk9MC4zMDA2MDA0NiBaPTAuNzUwMDAwMDANCkMgICAgICAgICAgICAgICAg NzgxICAgICAwLjAwMDEwMDAwICAgICAgICAgMS4zMDAwICAgICAgIDYuMA0K TE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAw MDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAg MC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRPTT0gLTQ6IFg9MC42Njk2MTkzOCBZ PTAuNzkzNzg5MzkgWj0wLjI1MDAwMDAwDQogICAgICAgICAgTVVMVD0gMiAg ICAgICAgICBJU1BMSVQ9IDgNCiAgICAgIC00OiBYPTAuMzMwMzgwNjIgWT0w LjIwNjIxMDYxIFo9MC43NTAwMDAwMA0KQyAgICAgICAgICAgICAgICA3ODEg ICAgIDAuMDAwMTAwMDAgICAgICAgICAxLjMwMDAgICAgICAgNi4wDQpMT0NB TCBST1QgTUFUUklYOiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAw MA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAw LjAwMDAwMDANCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwDQpBVE9NPSAtNTogWD0wLjYwNDgzMDU0IFk9MC44 MjI2MzUyMyBaPTAuNzUwMDAwMDANCiAgICAgICAgICBNVUxUPSAyICAgICAg ICAgIElTUExJVD0gOA0KICAgICAgLTU6IFg9MC4zOTUxNjk0NiBZPTAuMTc3 MzY0NzcgWj0wLjI1MDAwMDAwDQpDICAgICAgICAgICAgICAgIDc4MSAgICAg MC4wMDAxMDAwMCAgICAgICAgIDEuMzAwMCAgICAgICA2LjANCkxPQ0FMIFJP VCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkFUT009IC02OiBYPTAuNDY0NTM5ODkgWT0wLjgzNzM4 MDM4IFo9MC43NTAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAg SVNQTElUPSA4DQogICAgICAtNjogWD0wLjUzNTQ2MDExIFk9MC4xNjI2MTk2 MiBaPTAuMjUwMDAwMDANCkMgICAgICAgICAgICAgICAgNzgxICAgICAwLjAw MDEwMDAwICAgICAgICAgMS4zMDAwICAgICAgIDYuMA0KTE9DQUwgUk9UIE1B VFJJWDogICAgMS4wMDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAw DQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEu MDAwMDAwMA0KQVRPTT0gLTc6IFg9MC4zOTUxNjk0NiBZPTAuODIyNjM1MjMg Wj0wLjI1MDAwMDAwDQogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BM SVQ9IDgNCiAgICAgIC03OiBYPTAuNjA0ODMwNTQgWT0wLjE3NzM2NDc3IFo9 MC43NTAwMDAwMA0KQyAgICAgICAgICAgICAgICA3ODEgICAgIDAuMDAwMTAw MDAgICAgICAgICAxLjMwMDAgICAgICAgNi4wDQpMT0NBTCBST1QgTUFUUklY OiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAg ICAgICAgICAgICAgMC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAw MDAwDQpBVE9NPSAtODogWD0wLjI3MzAwNDk2IFk9MC43NTIxMDM1MyBaPTAu MjUwMDAwMDANCiAgICAgICAgICBNVUxUPSAyICAgICAgICAgIElTUExJVD0g OA0KICAgICAgLTg6IFg9MC43MjY5OTUwNCBZPTAuMjQ3ODk2NDcgWj0wLjc1 MDAwMDAwDQpDICAgICAgICAgICAgICAgIDc4MSAgICAgMC4wMDAxMDAwMCAg ICAgICAgIDEuMzAwMCAgICAgICA2LjANCkxPQ0FMIFJPVCBNQVRSSVg6ICAg IDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAg ICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAg ICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDAN CkFUT009IC05OiBYPTAuMjI1NTUwMDggWT0wLjY5OTM5OTU0IFo9MC43NTAw MDAwMA0KICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4DQog ICAgICAtOTogWD0wLjc3NDQ0OTkyIFk9MC4zMDA2MDA0NiBaPTAuMjUwMDAw MDANCkMgICAgICAgICAgICAgICAgNzgxICAgICAwLjAwMDEwMDAwICAgICAg ICAgMS4zMDAwICAgICAgIDYuMA0KTE9DQUwgUk9UIE1BVFJJWDogICAgMS4w MDAwMDAwIDAuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAgICAg ICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMC4wMDAwMDAwIDEuMDAwMDAwMA0KQVRP TT0tMTA6IFg9MC4xNjgxNzQ0MiBZPTAuNTcwNTMxNzAgWj0wLjc1MDAwMDAw DQogICAgICAgICAgTVVMVD0gMiAgICAgICAgICBJU1BMSVQ9IDgNCiAgICAg LTEwOiBYPTAuODMxODI1NTggWT0wLjQyOTQ2ODMwIFo9MC4yNTAwMDAwMA0K QyAgICAgICAgICAgICAgICA3ODEgICAgIDAuMDAwMTAwMDAgICAgICAgICAx LjMwMDAgICAgICAgNi4wDQpMT0NBTCBST1QgTUFUUklYOiAgICAxLjAwMDAw MDAgMC4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDEuMDAwMDAwMCAwLjAwMDAwMDANCiAgICAgICAgICAgICAg ICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwDQogICAwIFNZ TU1FVFJZIE9QRVJBVElPTlM6DQo= - --143914132-1593261418-1036826536=:16879-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 9 Nov 2002 21:33:59 +1100 From: chen0130@flinders.edu.au Subject: Re: [WIEN]: automatic geometry optimisation ==== chen0130@flinders.edu.au submitted the following contribution: ==== Thanks for you reply! I wonder then, there are surely good reasons (apart from the expense) that people will not relax their structures? Could someone share their experience? Many thanks! Cheng Quoting thor : > ==== > thor > submitted the following contribution: > ==== > > Well, it is the best available option. The only other one is 'by hand', > writing > your own automatisation scripts. > > Anyway, it is not so difficult to use, once it is started. It is, however, > rather expensive, but if you want to do optimisation of the internal > parameters > in the structure, it is the only way to do it. > > It seems like vasp takes just as long time (at least for systems containing > W > and Fe), and what comes out of it says more about the pseudopotential than > about > the structure :-( > > The terms of the Hamiltonian that would make it 'do it by itself' are > generally > left out in DFT, and they would probably make it much slower, if at all > possible. > > Did that answer your question? > > Best regards, > Torsten Andersen. > > chen0130@flinders.edu.au wrote: > > > ==== > > chen0130@flinders.edu.au > > submitted the following contribution: > > ==== > > > > Thanks, I guess I am asking a silly question, but my emphasis is on > > 'automatic'! (ie something done in symmetry?) without the expensive > mini_lapw > > > > could someone suggest some generic reasons why geometry optimisations are > not > > necessarily performed for solid state structures? > > > > there seems to be publications without relaxing supercells... > > > > sorry to be so broad, appreciating any remarks, > > > > Thanks, > > > > Cheng > > > > Quoting Torsten Andersen : > > > > > ==== > > > Torsten Andersen > > > submitted the following contribution: > > > ==== > > > > > > min_lapw and mini (see, e.g., sec. 8.14 in UG). > > > > > > chen0130@flinders.edu.au wrote: > > > > > > >==== > > > >chen0130@flinders.edu.au > > > >submitted the following contribution: > > > >==== > > > > > > > >Dear Wien users, > > > > > > > >Can any one tell me if there is any automatic geometry optimisation of > any > > > > > > >degree in Wien97? > > > > > > > >Thanks > > > > > > > >Cheng > > > > > > > > > > > >==== > > > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > > >To (un)subscribe send mail to > > > >majordomo@zeus.theochem.tuwien.ac.at > > > >==== > > > > > > > > > > > > > > -- > > > Dr. Torsten Andersen > > > Department of Physics, Condensed Matter Theory Group, Uppsala > University > > > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: > http://deep.at/myspace > > > News on TA-WWW: Two publ. articles on ab initio nonlinear > magneto-optics > > > > > > > > > > > > ==== > > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > > To (un)subscribe send mail to > > > majordomo@zeus.theochem.tuwien.ac.at > > > ==== > > > > > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 10 Nov 2002 10:04:39 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: automatic geometry optimisation ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > chen0130@flinders.edu.au > submitted the following contribution: > ==== > > I wonder then, there are surely good reasons (apart from the expense) that > people will not relax their structures? Everything depends on the accuracy you need. If you can afford it, relaxing is always the better (=more accurate option). If you cannot afford it for all aspects of your problem, then you must at least test to what extent omitting relaxation will affect the properties in which you're interested. Imagine you compare total energies of two cases, and you want to decide which of both is lowest. If the difference is 0.1 Ry, and you have checked that relaxation affects the energy at the 0.01 Ry level, then it is save to neglect relaxation. If relaxation has a 0.1 Ry effect as well, then your results without relaxation are useless. Some properties are very sensitive to relaxation (electric-field gradients (:EFG) can be changed by 100% or more), others are usually much less affected (e.g. magnetic moments (:MMI)). If you don't need high accuracy because you want to make conclusions on a qualitative level, then relaxation is often not needed at all. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 15:18:23 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I get a question like : How to increase the number of k-point in the bandstructure plot? Actually, I have used 1000 k-point for KGEN and SCF cycle and my bandstructure plot only having 20 k-point from R to gramma. After the SCF, I modify the .in1 file by inserting the k-point by copying the $WIENROOT/SRC_templates/simple_cublic.klist into .in1 file and change unit to 5. Is it something mismatch for my action? On the other hand, what are the meaning for the data in columns 2 to 6 in the file $WIENROOT/SRC_templates/simple_cublic.klist? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 09:09:17 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Question ==== Peter Blaha submitted the following contribution: ==== > I am sorry that I already have question with WIEN97. > > Actually, I would like to put the same molecule (20 carbon atoms) in boxes > with different dimensions and perform the calculations. And all the 3 > inputed .struct files with only 1 inequivalent atom (I just list all the > 20 carbon atoms together). However, WIEN97 classifies this 3 cases > differently. Why? > > For my input value of nn=2 for all 3 cases. > > Case 1 : The box's dimensions are 10AX10AX2.46124419755538A > > After NN, WIEN97 generates 10 inequvialent atoms to me. > > Case 2 : The box's dimensions are 12AX12AX2.46124419755538A > > After NN, WIEN97 generates 8 inequivalent atoms to me. > > Case 3 : The box's dimensions are 14AX14AX2.46124419755538A > > After NN, WIEN97 generates 1 inequivalent atoms to me. This is because nn has certain limits up to which nn-distances are considered and for large boxes it will not "count" any cell-cell interactions. WIEN2k (sgroup) gives for all struct files 10 inequivalent atoms. Regards PS: Maybe you should upgrade ? Or get yourself a book about cristallography. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 10 Nov 2002 09:24:40 +0100 From: Peer Kruse Subject: Re: [WIEN]: Address Error in lapw1 ==== Peer Kruse submitted the following contribution: ==== Have you checked the amount of ram with ulimit or the quality of your ram with memtest86? If it's a new machine I would recommend testing the ram as well as I have been told it is rather erraneous in the last time. But I don't know if this is the reason behind your problem. Have a look at www.memtest86.com for the (free) software. Peer Jeff Spirko wrote: >==== >Jeff Spirko >submitted the following contribution: >==== > >I'm having a problem with lapw1 in a large (> 1 GB RAM, 10000 matrix >size, RKM=7.0) job. I have already checked the available RAM, >diskspace, and stack size. > > Version: WIEN2k_02 from Oct 24, 2002 > Computer: Pentium IV with 2 GB RDRAM > Operating System: Redhat Linux 8.0 > Compiler: IFC 6.0 > FOPT: -O0 -FR -mp -w -tpp7 > LDFLAGS: -Vaxlib -L../SRC_lib > R_LIBS: -llapack_lapw -lmkl_p4 -lguide -lpthread > >I have successfully run the job on an SGI, and I just transferred >over the .struct, .in*, .kgen, .klist, and .clmsum files. When >lapw1c runs, after about 2 hours it crashes with the following >message printed to the screen: > ** Address Error ** > End of diagnostics > >If I decrease the matrix size by reducing NMATMAX to 5000, so it's >only a 500 MB job, it runs fine. > >Any ideas on why this would be happening? > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 11:10:16 +0100 From: KOITZSCH Christian Subject: [WIEN]: H saturation of slab surface ==== KOITZSCH Christian submitted the following contribution: ==== Hi Everybody, I have a question regarding slab calculations. I am trying to calculate an adsorbed layer of atoms A (in my case yttrium) on a substrate B (silicon). Now I would like to get rid of the contributions from the substrate "surface" - so I thought about saturating the bottom of my slab with hydrogen atoms, but it turns out, that this method is really expensive, since the resulting small muffin tin radii, gives me a lot of plane waves and correspondingly a lot of computation time. Can somebody give me an advise, how to proceed in a more clever way? I used a bondlength of 1.55 Angstroem for the Si-H bond, is this reasonable? Thanks a lot Christian Koitzsch University of Fribourg Department of Physics CH-1700 Fribourg ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 12:14:21 +0100 (MEZ) From: "A. Postnikov" Subject: Re: [WIEN]: H saturation of slab surface ==== "A. Postnikov" submitted the following contribution: ==== On Mon, 11 Nov 2002, KOITZSCH Christian wrote: > ==== > KOITZSCH Christian > submitted the following contribution: > ==== > > Hi Everybody, > > I have a question regarding slab calculations. I am trying to calculate an > adsorbed layer of atoms A (in my case yttrium) on a substrate B (silicon). > Now I would like to get rid of the contributions from the substrate > "surface" - so I thought about saturating the bottom of my slab with > hydrogen atoms, but it turns out, that this method is really expensive, > since the resulting small muffin tin radii, gives me a lot of plane waves > and correspondingly a lot of computation time. Can somebody give me an > advise, how to proceed in a more clever way? I used a bondlength of 1.55 > Angstroem for the Si-H bond, is this reasonable? > Dear Christian, why don't you put Y on both sides of your slab? (if you are not interested in the free Si surface anyway). Just make sure that your Y-Y distance is large enough both across the substrate and across the vacuum. As you'll hopefully make use of some extra symmetry in your supercell, the introduction of extra atoms will probably pay off. Regards, Andrei Postnikov ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 15:43:09 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: H saturation of slab surface ==== Peter Blaha submitted the following contribution: ==== > I have a question regarding slab calculations. I am trying to calculate an > adsorbed layer of atoms A (in my case yttrium) on a substrate B (silicon). > Now I would like to get rid of the contributions from the substrate > "surface" - so I thought about saturating the bottom of my slab with > hydrogen atoms, but it turns out, that this method is really expensive, > since the resulting small muffin tin radii, gives me a lot of plane waves > and correspondingly a lot of computation time. Can somebody give me an > advise, how to proceed in a more clever way? I used a bondlength of 1.55 > Angstroem for the Si-H bond, is this reasonable? As was mentioned before, at least when you have inversion symmetry, it often makes sense to add the adlayer on both sides. (I must admit, sometimes the adlayer-adlayer interaction through the "bulk" is strong and one needs many layers, but there is also no guarantee that there is not some spurious interaction between two different surfaces) If you want to saturate one surface with H, choose small spheres for H (do not change the Si-radius), and adjust RKMAX according to the ratio of R_Si/R-H to 3-4. This way the number of PW is not increased, Si and Y are as accurately converged as you like and H is even with a RKMax=3 reasonably converged and in addition poor H-convergence should not matter too much. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 11 Nov 2002 08:35:53 -0800 (PST) From: Claudio Lee Subject: [WIEN]: OP calcualtion (again!) ==== Claudio Lee submitted the following contribution: ==== Dear Pavel, Gerd and all, After I have installeded for the latest vesion I got a new problem when runing -so -orb (my system is still the same as my previous mentioned one). After initialling for input files (with initso has been involved in it, files *inorb and *indmc have been created as well), I use runsp_lapw -so -orb -i 5 to calculate it. The first iteration seems okay but after that (second iteraion and so on) the errors happen in *err file as I give below: ==== hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END STOP lapwdm END STOP CORE END STOP CORE END STOP MIXER END hup: Command not found. STOP LAPW0 END 1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP orbital potential calculation END 1525-097 A READ statement using decimal base input found the invalid digit '.' in the input file. The program will recover by assuming a zero in its place. STOP orbital potential calculation END if: Badly formed number. ==== If however, after runsp_lapw -so (not yet -orb) has converged I allowed -orb to be involved following this by running runsp_lapw -so -orb then the program has been stopped just after lapw2 done (from first iteration), in *err it looks like (nothing happens in *error files): === hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END === So Pavel or Gerd (or anyone), if you do know how to solve this problem could you please help me? Thank you so much in advance. Claudio. __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 12 Nov 2002 09:20:04 +0100 From: Torsten Andersen Subject: [WIEN]: NWAV too small in rdswar.f ==== Torsten Andersen submitted the following contribution: ==== Dear developers, after upgrading to Wien2k_02 (19/9-2) I get a peculiar little message from lapw1, telling me that "NWAV too small in rdswar.f" in the case.dayfile. Is that something to worry about? What can I do about it? I don't see NWAV in rdswar.f, and in the param.inc file it is not present, so it must be internal. I have 50749 plane-waves, but I remember that in Wien2k_01 the maximum allowed PW's were increased to 1 million. Best regards, Torsten Andersen. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 12 Nov 2002 14:02:43 +0100 From: Torsten Andersen Subject: Re: [WIEN]: NWAV too small in rdswar.f ==== Torsten Andersen submitted the following contribution: ==== I am sorry for that... I mixed up my path, so the wrong executable was selected. Now it is ok. Best regards, Torsten Andersen. Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Dear developers, > > after upgrading to Wien2k_02 (19/9-2) I get a peculiar little message > from lapw1, telling me that "NWAV too small in rdswar.f" in the > case.dayfile. Is that something to worry about? What can I do about it? > > I don't see NWAV in rdswar.f, and in the param.inc file it is not > present, so it must be internal. I have 50749 plane-waves, but I > remember that in Wien2k_01 the maximum allowed PW's were increased to > 1 million. > > Best regards, > Torsten Andersen. > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 12 Nov 2002 12:01:51 -0800 (PST) From: yanming Ma Subject: [WIEN]: fblacs lib error ==== yanming Ma submitted the following contribution: ==== - --0-877359211-1037131311=:47798 Content-Type: text/plain; charset=us-ascii Dear wien2k users, When I try to setup Wien2k in our SGI machines to use Fine Grained parallel calculation, I get a error message from library "fblacs" as the following I/O error (-Lfblacs): no such file or directory. I just wonder where can I get the library "lfblacs". Please help me. I will highly appreciate your help. Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD - --0-877359211-1037131311=:47798 Content-Type: text/html; charset=us-ascii

Dear wien2k users,

When I try to setup Wien2k in our SGI machines to use Fine Grained parallel calculation, I get a error message from library "fblacs" as the following

I/O error (-Lfblacs): no such file or directory.

I just wonder where can I get the library "lfblacs".

Please help me. I will highly appreciate your help. 



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD - --0-877359211-1037131311=:47798-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 12 Nov 2002 20:57:58 -0500 (EST) From: Harry Gotsis Subject: Re: [WIEN]: Question ==== Harry Gotsis submitted the following contribution: ==== On Mon, 11 Nov 2002, Ma Chi Chiu wrote: Dear Martin: In order to have more k-points (let's say twice) in the band-structure plot, simply double the number of divisions in simple_cubic.klist (i.e. change idv from 40 to 80) and then add manually more k-points. Regards, Harry Gotsis > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > I get a question like : How to increase the number of k-point in the > bandstructure plot? > > Actually, I have used 1000 k-point for KGEN and SCF cycle and my > bandstructure plot only having 20 k-point from R to gramma. After the > SCF, I modify the .in1 file by inserting the k-point by copying the > $WIENROOT/SRC_templates/simple_cublic.klist into .in1 file and change > unit to 5. > > Is it something mismatch for my action? > > On the other hand, what are the meaning for the data in columns 2 to 6 in > the file $WIENROOT/SRC_templates/simple_cublic.klist? > > Thank you very much > > Martin > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #42 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #43 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, November 14 2002 Volume 2002 : Number 043 ---------------------------------------------------------------------- Date: Wed, 13 Nov 2002 09:20:55 +0100 From: Torsten Andersen Subject: Re: [WIEN]: fblacs lib error ==== Torsten Andersen submitted the following contribution: ==== Dear Ms. Ma, you can search for it using the "find" command. If it is not there, maybe MPI is not installed correct? As this is supposed to be a "standard library", ask your system administrator, or search for it in SGI's documentation, which should be online on your system. Best regards, Torsten Andersen. yanming Ma wrote: > Dear wien2k users, > > When I try to setup Wien2k in our SGI machines to use Fine Grained > parallel calculation, I get a error message from library "fblacs" as > the following > > I/O error (-Lfblacs): no such file or directory. > > I just wonder where can I get the library "lfblacs". > > Please help me. I will highly appreciate your help. > > > > Yanming Ma Ph.D > Steacie Institute for Molecular Sciences, > National Research Councils of Canada, > Ottawa, Ontario > K1A 0R6 > Canada > > > ------------------------------------------------------------------------ > Do you Yahoo!? > U2 on LAUNCH > - > Exclusive medley & videos from Greatest Hits CD - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 13:50:54 +0000 From: ecat@nfrn-mail.org.uk Subject: [WIEN]: To ask about case.vector ==== ecat@nfrn-mail.org.uk submitted the following contribution: ==== Dear all, We often need this file case.vector when we calculate properties. Please,tell me, how and when is this file created? Thanks! Ecat ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 14:59:43 +0100 From: Torsten Andersen Subject: Re: [WIEN]: To ask about case.vector ==== Torsten Andersen submitted the following contribution: ==== in LAPW1, every time you run it. But wait, that information is in the manual... so read the manual. Best regards, Torsten Andersen. ecat@nfrn-mail.org.uk wrote: >==== >ecat@nfrn-mail.org.uk >submitted the following contribution: >==== > >Dear all, > >We often need this file case.vector when we calculate properties. >Please,tell me, how and when is this file created? Thanks! > >Ecat >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 14:21:46 +0000 (GMT) From: David Pankhurst Subject: Re: [WIEN]: fblacs lib error ==== David Pankhurst submitted the following contribution: ==== Dear Yanming, It looks to me like you have mistyped the linker option. Should be - -lfblacs, not -Lfblacs. A big -L should be followed by a directory to add to the library search path, a little -l should be followed by the name of the library you want to link with the "lib" prefix removed. i.e. to link libfblacs.a use -lfblacs. best regards, Dave Pankhurst On Tue, 12 Nov 2002, yanming Ma wrote: > > Dear wien2k users, > > When I try to setup Wien2k in our SGI machines to use Fine Grained parallel calculation, I get a error message from library "fblacs" as the following > > I/O error (-Lfblacs): no such file or directory. > > I just wonder where can I get the library "lfblacs". > > Please help me. I will highly appreciate your help. > > > Yanming Ma Ph.D > Steacie Institute for Molecular Sciences, > National Research Councils of Canada, > Ottawa, Ontario > K1A 0R6 > Canada > > > --------------------------------- > Do you Yahoo!? > U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD +---------------------------------+------------------------------------+ | Dr David Pankhurst, | Tel : +44 1865 283325/283326 | | Department of Materials, | Fax : +44 1865 273789 | | University of Oxford, | | | Parks Road, Oxford OX1 3PH, UK | david.pankhurst@materials.ox.ac.uk | +---------------------------------+------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 18:29:43 +0100 From: Maciej Luszczek Subject: [WIEN]: kgen ==== Maciej Luszczek submitted the following contribution: ==== Dear WIEN2k users, I have just installed wien2k on the machine (SGI Origin 2000/Onyx 2, 16 MIPS R12000 and 8 MIPS R10000 processors, 16 GB RAM, 80 GB disk storage, 12.8 GFLOPs) and some problems with kgen are occurring: > kgen kgen.def (or >x kgen) Segmentation fault (core dumped) The program was compiled with the following options (in Makefile): FC = f90 FOPT = -O -mips4 -r10000 -freeform -64 FGEN = LDFLAGS = -mips4 -r10000 -64 LIBS = DESTDIR = ./ EXECNAME = kgen Surprisingly, the previous version of kgen (from WIEN97 package) works properly... The compilation has been performed with the low optimization, so, perhaps it is a bug? I would be grateful if someone could help me with this. Best regards, Maciej Luszczek - -- Dr. Maciej Luszczek Faculty of Applied Physics and Mathematics Gdansk University of Technology G. Narutowicza 11/12 80-952 Gdansk POLAND Phone: +4858 3471095 Fax: +4858 3472821 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 17:02:27 -0200 (BDB) From: vivienne denise falcao Subject: [WIEN]: X-Ray Spectra ==== vivienne denise falcao submitted the following contribution: ==== Dear All, My problems with energy range for x-ray absorption spectra remains. I am using an old version of Wien97 and the case.in1 that I get is =============================================================================== WFFIL (WFPRI, SUPWF) 9.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT .30 4 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 1 .30 .000 CONT 1 -4.49 .005 STOP 2 .30 .010 CONT 0 .30 .000 CONT .30 5 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) 2 .30 .000 CONT 2 -2.92 .005 STOP 0 -.77 .010 CONT 0 .30 .000 CONT 1 .30 .000 CONT K-VECTORS FROM UNIT:4 =============================================================================== In this file there insn't limit of energy window. I tryed to include the limit of energy window in this file but the maximum energy didn't change. The case.int that I obtain is =============================================================================== Autocreate Title: Atom 1 L3 absorption spectrum -0.141130343782713830 0.146996137513085530E-02 1.69632137513085546 2 1 3 l+1 0 1 tot =============================================================================== I already did all that Saeid and Torsten suggested and I didn't exchange the energy range. What can I do? How can I to obtain a new version of Wien97? ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 06:09:10 +0530 (IST) From: Nitya Nath Subject: Re: [WIEN]: kgen ==== Nitya Nath submitted the following contribution: ==== Hi.. Please use this command 'unlimit' before running x kgen. It is not a bug.. with regards.. Nitya > ==== > Maciej Luszczek > submitted the following contribution: > ==== > > Dear WIEN2k users, > I have just installed wien2k on the machine (SGI Origin 2000/Onyx 2, 16 > MIPS R12000 and 8 MIPS R10000 processors, 16 GB RAM, 80 GB disk storage, 12.8 > GFLOPs) and some problems with kgen are occurring: > > > kgen kgen.def (or >x kgen) > Segmentation fault (core dumped) > > > The program was compiled with the following options (in Makefile): > FC = f90 > FOPT = -O -mips4 -r10000 -freeform -64 > FGEN = > LDFLAGS = -mips4 -r10000 -64 > LIBS = > DESTDIR = ./ > EXECNAME = kgen > > Surprisingly, the previous version of kgen (from WIEN97 package) works > properly... The compilation has been performed with the low > optimization, so, perhaps it is a bug? > > I would be grateful if someone could help me with this. > > Best regards, > Maciej Luszczek > > > > > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 13 Nov 2002 15:05:55 -0500 From: Jeff Spirko Subject: Re: [WIEN]: kgen ==== Jeff Spirko submitted the following contribution: ==== More specifically, if you use a Bourne-type shell (bash, sh, ksh), enter (You may have to pick a number instead of unlimited.): ulimit -s unlimited If you use a c-shell, enter: limit stacksize unlimited You have to do this every time you log in, so you may want to put it in your .profile or .login. On Thu, Nov 14, 2002 at 06:09:10AM +0530, Nitya Nath wrote: > Please use this command 'unlimit' before running x kgen. > It is not a bug.. > with regards.. > Nitya > > > kgen kgen.def (or >x kgen) > > Segmentation fault (core dumped) - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 08:13:29 +0100 From: Torsten Andersen Subject: Re: [WIEN]: X-Ray Spectra ==== Torsten Andersen submitted the following contribution: ==== We were just assuming you used Wien2k. The energy range in Wien97 is in case.klist. 1st line to the right. Best regards, Torsten Andersen. vivienne denise falcao wrote: >==== >vivienne denise falcao >submitted the following contribution: >==== > > Dear All, > > My problems with energy range for x-ray absorption spectra remains. >I am using an old version of Wien97 and the case.in1 that I get is > > >=============================================================================== >WFFIL (WFPRI, SUPWF) > 9.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT > .30 4 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) > 1 .30 .000 CONT > 1 -4.49 .005 STOP > 2 .30 .010 CONT > 0 .30 .000 CONT > .30 5 (GLOBAL E-PARAMETER WITH n OTHER CHOICES) > 2 .30 .000 CONT > 2 -2.92 .005 STOP > 0 -.77 .010 CONT > 0 .30 .000 CONT > 1 .30 .000 CONT >K-VECTORS FROM UNIT:4 >=============================================================================== > >In this file there insn't limit of energy window. I tryed to include the >limit of energy window in this file but the maximum energy didn't >change. >The case.int that I obtain is > >=============================================================================== > >Autocreate Title: Atom 1 L3 absorption spectrum > -0.141130343782713830 0.146996137513085530E-02 1.69632137513085546 > 2 > 1 3 l+1 > 0 1 tot >=============================================================================== > >I already did all that Saeid and Torsten suggested and I didn't exchange >the energy range. > >What can I do? >How can I to obtain a new version of Wien97? > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #43 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #44 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, November 21 2002 Volume 2002 : Number 044 ---------------------------------------------------------------------- Date: Thu, 14 Nov 2002 08:27:11 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: X-Ray Spectra ==== Peter Blaha submitted the following contribution: ==== > My problems with energy range for x-ray absorption spectra remains. > I am using an old version of Wien97 and the case.in1 that I get is In WIEN97 the energy range was set in the first line of case.klist. > How can I to obtain a new version of Wien97? Have a look at www.wien2k.at 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 09:06:21 +0000 From: Paula Subject: [WIEN]: hup: Command not found ==== Paula submitted the following contribution: ==== Dear Wien users, I am using wien2k on a dec compaq operating system. The c-shell command 'hup' is not recognised and l have copied the first part of the STDOUT file below. The scf cycle continues, but when l try to run any tasks (elnes, dos etc.) they crash. I would like to know if anyone else has found a similar error message and what l can do about it. Is it possible to write a script to replace this command? What does this command actually do? Thanks for your help, Paula STDOUT: hup: Command not found. LAPW0 END LAPW1 END LAPW1 END LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END SUMPARA END SUMPARA END CORE END MIXER END in cycle 2 ETEST: 0 CTEST: 0 hup: Command not found. LAPW0 END LAPW1 END LAPW1 END LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END SUMPARA END SUMPARA END CORE END ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 11:30:22 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: hup: Command not found ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Paula, the hup command is not important. You can safely ignore this message. If it bothers you, remove the hup command from run_lapw-script. Or just ignore it. kind regards, Kevin. kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Paula" To: Sent: Thursday, November 14, 2002 10:06 AM Subject: [WIEN]: hup: Command not found > ==== > Paula > submitted the following contribution: > ==== > > Dear Wien users, > > I am using wien2k on a dec compaq operating system. The c-shell command > 'hup' is not recognised and l have copied the first part of the STDOUT file > below. The scf cycle continues, but when l try to run any tasks (elnes, dos > etc.) they crash. I would like to know if anyone else has found a similar > error message and what l can do about it. Is it possible to write a script > to replace this command? What does this command actually do? > Thanks for your help, > > Paula > > STDOUT: > hup: Command not found. > LAPW0 END > LAPW1 END > LAPW1 END > LAPW2 - FERMI; weighs written > LAPW2 END > LAPW2 END > SUMPARA END > SUMPARA END > CORE END > MIXER END > in cycle 2 ETEST: 0 CTEST: 0 > hup: Command not found. > LAPW0 END > LAPW1 END > LAPW1 END > LAPW2 - FERMI; weighs written > LAPW2 END > LAPW2 END > SUMPARA END > SUMPARA END > CORE END > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 11:25:47 -0200 (BDB) From: vivienne denise falcao Subject: [WIEN]: Error in LAPW2 ==== vivienne denise falcao submitted the following contribution: ==== Dear All, I changed the energy range in case.klist, ran lapw1 again and began a calculate of X-Ray Spectra using Wien97 (an old version) but, when I run lapw2 there is an error. The error message in lapw2.error file is as follows: 'l2for' - QTL-B VALUE GT. 40. What is happening? How can I correct this error? What can I do to calculate the x-ray absorption and emission spectra with the maximum energy range around 25 eV using Wien97 (an old version)? Sorry, I`m a beginner and I don`t know a lot about Wien97 package. Thankfull. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 15:40:43 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Error in LAPW2 ==== "Kevin Jorissen" submitted the following contribution: ==== Hello Vivienne, There's some information on this problem in the UG (usersguide - I don't know if it was already included in the WIEN97-manual?) about ghostbands (chapter 12.1, I believe) that you may want to read. Also check out the faq-pages on the wien2k-webpage about 'selecting muffin tin radius' and 'scf cycle fails after some iterations'. As you know, wien uses an LAPW-basis, which you can think of as a radial basis function plus a linear correction inside the muffin-tin sphere, and plane waves in the interstitial region between the spheres. The QTL-B-value measures the contribution of this linear correction (a sort of first order term - the 'B' coefficients in the formula in the introduction of the UG) basis function to the charge density. If this contribution becomes large (for a given atom,band,k-point ...) you may get linearisation errors. In WIEN97, the calculation therefore terminates and warns you that you may have ghost bands. [In Wien2k, things are more complicated since you also have lo's. Therefore the calculation will not stop because of a high QTL-B-value, but a warning will be printed to case.scf(2) and case.output2.] What you can try : - -increase muffin tin size if you have core charge leakage (check in case.outputst) and if possible - -check the linearisation energies in case.in1(c) and change them if necessary, or add LO's - -restart your calculation with different mixing etc. There's more info in the UG, on the faq-pages provided by P. Blaha, and in the wien mail digest. And you can always ask, of course. Kevin. kevin.jorissen@ua.ac.be PS : If you're not really into WIEN97 yet, why not start straightaway with WIEN2k? It's newer, faster, has more options and applications, and it's what most active users on this mailing list are using anyway. - ----- Original Message ----- From: "vivienne denise falcao" To: "Wien" Sent: Thursday, November 14, 2002 2:25 PM Subject: [WIEN]: Error in LAPW2 > ==== > vivienne denise falcao > submitted the following contribution: > ==== > > Dear All, > > I changed the energy range in case.klist, ran lapw1 again and began a > calculate of X-Ray Spectra using Wien97 (an old version) but, when I run > lapw2 there is an error. The error message in lapw2.error file is as > follows: > 'l2for' - QTL-B VALUE GT. 40. > What is happening? How can I correct this error? > What can I do to calculate the x-ray absorption and emission spectra with > the maximum energy range around 25 eV using Wien97 (an old version)? > Sorry, I`m a beginner and I don`t know a lot about Wien97 package. > > Thankfull. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 12:39:33 +0000 From: Paula Subject: [WIEN]: Parallel Testerror ==== Paula submitted the following contribution: ==== - --=====================_4123937==_ Content-Type: multipart/alternative; boundary="=====================_4123937==.ALT" - --=====================_4123937==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear wien users, I have updated to wien2k recently and am having a few problems. When l run the scf cycle for the perovskite system, SrTiO3, (which runs fine on wien97) i get the message: hup: Command not found. LAPW0 END LAPW1 END LAPW1 END LAPW2 - FERMI; weighs written cp: .in.tmp: No such file or directory rm: .in.tmp: No such file or directory rm: .in.tmp1: No such file or directory when i check error files all l am told is: lapw2.error 0 ** testerror: Error in Parallel LAPW2 I have enclosed the .struct file and ran it with all the usual inputs suggested in the UG with 550 k-points. I have a duel processor machine and use the .machines file, also attached. I would appreciate any help that you could give. Paula - --=====================_4123937==.ALT Content-Type: text/html; charset="us-ascii" Dear wien users,
I have updated to wien2k recently and am having a few problems. When l run the scf cycle for the perovskite system, SrTiO3, (which runs fine on wien97) i get the message:

hup: Command not found.
 LAPW0 END
 LAPW1 END
 LAPW1 END
LAPW2 - FERMI; weighs written
cp: .in.tmp: No such file or directory
rm: .in.tmp: No such file or directory
rm: .in.tmp1: No such file or directory

when i check error files all l am told is:
lapw2.error 0
**  testerror: Error in Parallel LAPW2

I have enclosed the .struct file and ran it with all the usual inputs suggested in the UG with 550 k-points. I have a duel processor machine and use the .machines file, also attached. I would appreciate any help that you could give.
Paula - --=====================_4123937==.ALT-- - --=====================_4123937==_ Content-Type: application/octet-stream; name="strontium.test.struct" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="strontium.test.struct" VGVzdCAtIEN1YmljIFNyVGlPMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIApQICAgTEFUVElDRSxOT05FUVVJVi4gQVRPTVM6IDMyMjFf UG0tM20gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCk1PREUgT0YgQ0FM Qz1SRUxBIHVuaXQ9Ym9ociAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICA3LjM3OTM4MCAgNy4zNzkzODAgIDcuMzc5MzgwIDkwLjAwMDAwMCA5MC4w MDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAgICAgICAgIApBVE9NPSAgMTogWD0wLjAwMDAwMDAw IFk9MC4wMDAwMDAwMCBaPTAuMDAwMDAwMDAKICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQ TElUPSAyClNyICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDAxMDAwIFJNVD0gICAgMi4zMDAw ICAgWjogMzguMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDAKQVRPTT0gIDI6IFg9MC41MDAwMDAwMCBZPTAuNTAwMDAwMDAgWj0wLjUwMDAw MDAwCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0gMgpUaSAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDIuMDAwMCAgIFo6IDIyLjAgICAgICAgICAgICAg ICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAw CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009IC0zOiBY PTAuNTAwMDAwMDAgWT0wLjUwMDAwMDAwIFo9MC4wMDAwMDAwMAogICAgICAgICAgTVVMVD0gMyAg ICAgICAgICBJU1BMSVQ9LTIKICAgICAgLTM6IFg9MC4wMDAwMDAwMCBZPTAuNTAwMDAwMDAgWj0w LjUwMDAwMDAwCiAgICAgIC0zOiBYPTAuNTAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9MC41MDAwMDAw MApPICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNjUwMCAgIFo6 ICA4LjAgICAgICAgICAgICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAw MDAgMC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4w MDAwMDAwCiAgNDggICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUwotMSAwIDAgMC4w MDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAgMQotMSAwIDAg MC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgMgotMSAw IDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogICAgICAgMwot MSAwIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogICAgICAg NAotMSAwIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAwMAogICAg ICAgNQotMSAwIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAwMAog ICAgICAgNgotMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAw MAogICAgICAgNwotMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAw MDAwMAogICAgICAgOAogMC0xIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAgMC0xIDAu MDAwMDAwMAogICAgICAgOQogMC0xIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAgMCAx IDAuMDAwMDAwMAogICAgICAxMAogMCAwLTEgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAt MSAwIDAuMDAwMDAwMAogICAgICAxMQogMCAwIDEgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAK IDAtMSAwIDAuMDAwMDAwMAogICAgICAxMgogMCAwLTEgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAw MDAKIDAgMSAwIDAuMDAwMDAwMAogICAgICAxMwogMCAwIDEgMC4wMDAwMDAwCi0xIDAgMCAwLjAw MDAwMDAKIDAgMSAwIDAuMDAwMDAwMAogICAgICAxNAogMCAxIDAgMC4wMDAwMDAwCi0xIDAgMCAw LjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAxNQogMCAxIDAgMC4wMDAwMDAwCi0xIDAg MCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAxNgogMC0xIDAgMC4wMDAwMDAwCiAw IDAtMSAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAxNwogMC0xIDAgMC4wMDAwMDAw CiAwIDAgMSAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAxOAogMCAwLTEgMC4wMDAw MDAwCiAwLTEgMCAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAxOQogMCAwIDEgMC4w MDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAyMAogMCAwLTEg MC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAyMQogMCAw IDEgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAyMgog MCAxIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAgICAy MwogMCAxIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKLTEgMCAwIDAuMDAwMDAwMAogICAg ICAyNAogMC0xIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKIDEgMCAwIDAuMDAwMDAwMAog ICAgICAyNQogMC0xIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKIDEgMCAwIDAuMDAwMDAw MAogICAgICAyNgogMCAwLTEgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDEgMCAwIDAuMDAw MDAwMAogICAgICAyNwogMCAwIDEgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDEgMCAwIDAu MDAwMDAwMAogICAgICAyOAogMCAwLTEgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDEgMCAw IDAuMDAwMDAwMAogICAgICAyOQogMCAwIDEgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDEg MCAwIDAuMDAwMDAwMAogICAgICAzMAogMCAxIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAK IDEgMCAwIDAuMDAwMDAwMAogICAgICAzMQogMCAxIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAw MDAKIDEgMCAwIDAuMDAwMDAwMAogICAgICAzMgogMC0xIDAgMC4wMDAwMDAwCiAxIDAgMCAwLjAw MDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAzMwogMC0xIDAgMC4wMDAwMDAwCiAxIDAgMCAw LjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAzNAogMCAwLTEgMC4wMDAwMDAwCiAxIDAg MCAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogICAgICAzNQogMCAwIDEgMC4wMDAwMDAwCiAx IDAgMCAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogICAgICAzNgogMCAwLTEgMC4wMDAwMDAw CiAxIDAgMCAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAwMAogICAgICAzNwogMCAwIDEgMC4wMDAw MDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAwMAogICAgICAzOAogMCAxIDAgMC4w MDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAzOQogMCAxIDAg MC4wMDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICA0MAogMSAw IDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICA0MQog MSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICA0 MgogMSAwIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogICAg ICA0MwogMSAwIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAog ICAgICA0NAogMSAwIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKIDAgMSAwIDAuMDAwMDAw MAogICAgICA0NQogMSAwIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKIDAgMSAwIDAuMDAw MDAwMAogICAgICA0NgogMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMC0xIDAu MDAwMDAwMAogICAgICA0NwogMSAwIDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMCAx IDAuMDAwMDAwMAogICAgICA0OAo= - --=====================_4123937==_ Content-Type: application/octet-stream; name=".machines"; x-mac-type="50494354"; x-mac-creator="6450726F" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=".machines" IyAKIyAubWFjaGluZXMgaXMgdGhlIGNvbnRyb2wgZmlsZSBmb3IgcGFyYWxsZWwgZXhlY3V0aW9u CiMgc3ludGF4IGlzIAojCiMgICB3ZWlnaHQ6bWFjaGluZV9uYW1lCiMKIyB3aGVyZSB3ZWlnaHQg aXMgdGhlIHJlbGF0aXZlIHNwZWVkIG9mIHRoZSBtYWNoaW5lCiMgd2l0aCByZXNwZWN0IHRvIHRo ZSBvdGhlciBtYWNoaW5lcyB1c2VkCiMgZnVydGhlciBvcHRpb25zIGFyZToKIwojICAgZ3JhbnVs YXJpdHk6bnVtYmVyCiMKIyBncmFudWxhcml0eSBzZXRzIHRoZSBudW1iZXIgb2YgZmlsZXMgdGhh dCB3aWxsIGJlIGFwcHJveGltYXRlbHkKIyBiZSBnZW5lcmF0ZWQgYnkgZWFjaCBwcm9jZXNzb3I7 IHRoaXMgaXMgdXNlZCBmb3IgbG9hZC1iYWxhbmNpbmcuCiMgT24gdmVyeSBob21vZ2VuZW91cyBz eXN0ZW1zIHNldCBudW1iZXIgdG8gMQojCiMgICByZXNpZHVlOm1hY2hpbmVfbmFtZQojCiMgaWYg YWZ0ZXIgZGlzdHJpYnV0aW5nIHRoZSBrLXBvaW50cyB0byB0aGUgdmFyaW91cyBtYWNoaW5lcyBy ZXNpZHVhbAojIGstcG9pbnRzIGFyZSBsZWZ0LCB0aGV5IHdpbGwgYmUgZGlzdHJpYnV0ZWQgdG8g bWFjaGluZV9uYW1lLiAKIwoxOmxvY2FsaG9zdAoxOmxvY2FsaG9zdApncmFudWxhcml0eToxCg== - --=====================_4123937==_-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 17:18:47 +0100 From: Torsten Andersen Subject: [WIEN]: min_lapw ==== Torsten Andersen submitted the following contribution: ==== Dear all, I am probably missing something with respect to min_lapw. After running a few cycles I realised that an atom that should have been fixed in position was being moved. I changed the corresponding line in case.inM to 0.0 in all four variables (I use NEWT), and to my surprise, min_lapw keeps changing the position of that atom several cycles later. I have checked several times that case.inM has 0.0 for all variables for that atom in case.struct. What do I have to do to make it stop doing that? Remove case.tmpM? The atoms that were fixed when I began min_lapw are kept fixed... Best regards, Torsten Andersen. - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 17:31:55 +0100 From: Thomas Claesson Subject: [WIEN]: Strange message in the output ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am running Wien2k on an AIX system and I wonder about some info I keep getting in the output. Both when I run calculations in parallel and serial mode I get output like this: STOP LAPW0 END STOP LAPW1 END cp: Nio.energyup_1: A file or directory in the path name does not exist. cp: Nio.energyup_10: A file or directory in the path name does not exist. cp: Nio.energyup_11: A file or directory in the path name does not exist. cp: Nio.energyup_12: A file or directory in the path name does not exist. cp: Nio.energyup_13: A file or directory in the path name does not exist. cp: Nio.energyup_14: A file or directory in the path name does not exist. cp: Nio.energyup_15: A file or directory in the path name does not exist. cp: Nio.energyup_2: A file or directory in the path name does not exist. STOP LAPW2 END STOP CORE END STOP CORE END STOP MIXER END Why is it complaining about these case.energyup_* files? Is it serious? Can/should I do anything about it? Thanks for your replies! Any suggestions are welcome! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 13:06:50 -0600 (CST) From: Bing Zhou Subject: [WIEN]: problem with lstart ==== Bing Zhou submitted the following contribution: ==== Dear All: After running "lstart" during "init_lapw", I got the warning in the case.outputst file as following: WARNING !!!! For good atomic total energies you should probably change the radial mesh (reduce NRAD or increase R0), or increase PARAMETERS NPT and NPT00 1071 RADIAL MESH POINTS REACH UP TO 11.263190327106805 A.U. I increased NPT and R0, but the warning still persisted. Can I ignore it? if not, how to remedy it? Any suggestion, comments and help is highly appreciated! Best wishes! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 20:42:49 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: problem with lstart ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Bing Zhou > submitted the following contribution: > ==== > > After running "lstart" during "init_lapw", I got the warning in the > case.outputst file as following: > > WARNING !!!! For good atomic total energies you should probably change the > radial mesh (reduce NRAD or increase R0), or increase PARAMETERS NPT and > NPT00 1071 RADIAL MESH POINTS REACH UP TO 11.263190327106805 A.U. > > I increased NPT and R0, but the warning still persisted. Can I ignore it? > if not, how to remedy it? You can ignore this, unless you are interested in properties of the free atoms that are calculated by lstart. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 15 Nov 2002 15:11:55 -0600 (CST) From: Bing Zhou Subject: Re: [WIEN]: problem with lstart ==== Bing Zhou submitted the following contribution: ==== Dear Stefaan: Thank you for your kind help again! Have a nice weekend! On Fri, 15 Nov 2002, Stefaan Cottenier wrote: > ==== > Stefaan Cottenier > submitted the following contribution: > ==== > > > ==== > > Bing Zhou > > submitted the following contribution: > > ==== > > > > After running "lstart" during "init_lapw", I got the warning in the > > case.outputst file as following: > > > > WARNING !!!! For good atomic total energies you should probably change the > > radial mesh (reduce NRAD or increase R0), or increase PARAMETERS NPT and > > NPT00 1071 RADIAL MESH POINTS REACH UP TO 11.263190327106805 A.U. > > > > I increased NPT and R0, but the warning still persisted. Can I ignore it? > > if not, how to remedy it? > > You can ignore this, unless you are interested in properties of the free > atoms that are calculated by lstart. > > Stefaan > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 16 Nov 2002 01:59:39 CST From: Yongbin Lee Subject: [WIEN]: ixcpot 4 : VBH ==== Yongbin Lee submitted the following contribution: ==== Dear WIEN2k users I got a question about "ixcpot" option "4" in input *.in0. ! IXCPOT : = 1 : JMW SPIN-POLARIZED ! = 2 : HL-NEW ! = 3 : HL-OLD (FREEMAN) ! = 4 : VBH I think option "4" is for U.von.Barth and L.Hedin exchange-correlation and it should work for spin polarized case. But it seems not to work for spin polarized case. With this option, "*.vnsup" is exactly same with *.vnsdn" and "*.vspup also same with *.vspdn" . I checked SRC_lapw0/xcpot.f, xcener.f. These functions were written to use just "RHO", not "RHOUP","RHODN". RS=(0.75D0/PI/RHO)**(1.D0/3.D0) BETA=1.0d0 RHOH=2.0d0*RHOSP IF(IEX.EQ.1) GOTO 100 - ----> RHOH=RHO IF(IEX.EQ.2) THEN BETA=1.d0+0.0316D0*RS*LOG(1.D0+24.3D0/RS) . . ELSE IF(IEX.EQ.4) THEN BETA=1.d0+0.0545D0*RS*LOG(1.D0+11.4D0/RS) ELSE IF(IEX.EQ.5) THEN BETA=1.0d0 RHOH=2.0d0*RHOSP END IF - ----> XCPOT=-BETA*2.D0*(3.D0/PI*RHOH)**(1.D0/3.D0) RETURN Here are my questions. Are these options(2,3,4) not completely implemented yet? Are these options(2,3,4) just for unpolarized case ? Can these options(2,3,4) work for polarized case after comment out that line ? What do I need more for spin polarized calculation with option '4' ? Thank you Yongbin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 18 Nov 2002 09:52:56 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: U+SO ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all I met a question about caculating a system with U and SO. After convege of 'runsp', I added U(create case.inorb and case.indm) and it converged also. Then I wanted to add SO, after 'initso', it create a new structure. And I only mv case.indm to case.indmc. So "runsp -orb -so ' begin to run. but it gives these errors when 'x orb -du'. PGFIO-F-217/list-directed read/unit=11/attempt to read past end of file. File name = v.dmatud formatted, sequential access record = 1 In source file init.f, at line number 227 0.030u 0.010s 0:00.10 40.0% 0+0k 0+0io 187pf+0w Another question: I found the struct file is changed after 'initso'. Some equal V split to unequal V, so I add some corresponing lines in the case.indmc and case.inorb. There gives some errors when 'x orb -up', PGFIO-F-217/list-directed read/unit=10/attempt to read past end of file. File name = v.dmatup formatted, sequential access record = 35 In source file init.f, at line number 227 Did I also change case.inst to adapt the new case.struct. - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 14 Nov 2002 11:30:22 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: hup: Command not found ==== "Kevin Jorissen" submitted the following contribution: ==== ==== "Kevin Jorissen" submitted the following contribution: ==== Dear Paula, the hup command is not important. You can safely ignore this message. If it bothers you, remove the hup command from run_lapw-script. Or just ignore it. kind regards, Kevin. kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Paula" To: Sent: Thursday, November 14, 2002 10:06 AM Subject: [WIEN]: hup: Command not found > ==== > Paula > submitted the following contribution: > ==== > > Dear Wien users, > > I am using wien2k on a dec compaq operating system. The c-shell command > 'hup' is not recognised and l have copied the first part of the STDOUT file > below. The scf cycle continues, but when l try to run any tasks (elnes, dos > etc.) they crash. I would like to know if anyone else has found a similar > error message and what l can do about it. Is it possible to write a script > to replace this command? What does this command actually do? > Thanks for your help, > > Paula > > STDOUT: > hup: Command not found. > LAPW0 END > LAPW1 END > LAPW1 END > LAPW2 - FERMI; weighs written > LAPW2 END > LAPW2 END > SUMPARA END > SUMPARA END > CORE END > MIXER END > in cycle 2 ETEST: 0 CTEST: 0 > hup: Command not found. > LAPW0 END > LAPW1 END > LAPW1 END > LAPW2 - FERMI; weighs written > LAPW2 END > LAPW2 END > SUMPARA END > SUMPARA END > CORE END > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 18 Nov 2002 16:08:40 -0600 (CST) From: Bing Zhou Subject: [WIEN]: space group F2/d ==== Bing Zhou submitted the following contribution: ==== Dear All: I have a crystal with monoclinic symmetry, but, the space group is F2/d, which is not in the list of the 230 space groups! The F2/d is related to C2/c by the following relationship: Af=2Ac+Cc Bf=Bc Cf=Cc so can I use C2/c for F2/d? if not, how should I fiddle with the space group F2/d? Thank you in adavance! Best wishes! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 12:44:37 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: SO ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear all I have a trivial question about how to choose the direction of magnetization (h,k,l) in case.inso. I am caculating a AFI V2O3. The spin moment of vanadium do not along the 0 0 1. Must I change the (h,k,l) along the spin moment of vanadium? If yes, how can use only one (h,k,l) because the spin moments of two vanadium in the cell are antiparallel? - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 07:47:18 +0100 From: Torsten Andersen Subject: Re: [WIEN]: SO ==== Torsten Andersen submitted the following contribution: ==== yes, and the numbers are floating point, I think. BR, Torsten Andersen. yshzhang@theory.issp.ac.cn wrote: >==== >yshzhang@theory.issp.ac.cn >submitted the following contribution: >==== > >Dear all > >I have a trivial question about how to choose the direction of >magnetization (h,k,l) in case.inso. > >I am caculating a AFI V2O3. The spin moment of vanadium do not along the >0 0 1. Must I change the (h,k,l) along the spin moment of vanadium? >If yes, how can use only one (h,k,l) because the spin moments of two >vanadium in the cell are antiparallel? > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 07:56:41 +0100 From: Torsten Andersen Subject: Re: [WIEN]: SO ==== Torsten Andersen submitted the following contribution: ==== sorry, I didn't read the last line too well. I think there should be hints about that in the FAQ about doing antiferromagnetic calculations. Best regards, Torsten. Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > yes, and the numbers are floating point, I think. > > BR, > Torsten Andersen. > > yshzhang@theory.issp.ac.cn wrote: > >> ==== >> yshzhang@theory.issp.ac.cn >> submitted the following contribution: >> ==== >> >> Dear all >> >> I have a trivial question about how to choose the direction of >> magnetization (h,k,l) in case.inso. >> >> I am caculating a AFI V2O3. The spin moment of vanadium do not along >> the 0 0 1. Must I change the (h,k,l) along the spin moment of vanadium? >> If yes, how can use only one (h,k,l) because the spin moments of two >> vanadium in the cell are antiparallel? >> > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 15:49:38 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: [WIEN]: AFI ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Dear ALL To AFI system, if I didn't use 'runafm_lapw' but 'runsp_lapw' during converge. Do I have to put the spin moment of nonmagnetic atoms to zero in case.inst? - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 09:06:15 +0100 From: georg@chem.au.dk Subject: Re: [WIEN]: space group F2/d ==== georg@chem.au.dk submitted the following contribution: ==== There are no F centered monoclinic groups! If you've made your cell by distorting some other F centered unit cell the easiest thing is to generate all your atoms(make your cell primitive and type in (or make a little program to do it for you) all the F atoms. Then use sgroup to find your correct space group. Georg Quoting Bing Zhou : > ==== > Bing Zhou > submitted the following contribution: > ==== > > Dear All: > > I have a crystal with monoclinic symmetry, but, the space group is F2/d, > which is not in the list of the 230 space groups! > The F2/d is related to C2/c by the following relationship: > > Af=2Ac+Cc > Bf=Bc > Cf=Cc > > so can I use C2/c for F2/d? if not, how should I fiddle with the space > group F2/d? > > Thank you in adavance! > > Best wishes! > > > > Bing Zhou > Dept. of Geological Sc. > The Univ. of Manitoba > Canada R3T 2N2 > Tel: (204)474-8395 > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 09:07:37 +0100 From: georg@chem.au.dk Subject: Re: [WIEN]: AFI ==== georg@chem.au.dk submitted the following contribution: ==== > Do I have to put the spin moment of nonmagnetic atoms to zero in > case.inst? If you start from a non-magnetic solution you'll probably stay there. You should start from the AFM solution you're looking for > > -- > Best Regards > YS Zhang > > ------------------------------------------------------------------------ > Address: Institute of Solid State Physics > Chinese Academy of Sciences > P.O.BOX 1129,230031 Hefei > P.R~China > Tel: 086-551-5591464(Office) > 086-551-5592837(Home) > Fax: 086-551-5591434 > WWW: http://theory.issp.ac.cn/~yshzhang > ------------------------------------------------------------------------ > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 09:13:57 +0100 From: "Stefaan Cottenier" Subject: Re: [WIEN]: SO ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > yshzhang@theory.issp.ac.cn > submitted the following contribution: > ==== > > If yes, how can use only one (h,k,l) because the spin moments of two > vanadium in the cell are antiparallel? In addition to Torsten : (h,k,l) indicates the direction only, without indicating the sense. You must make you V-up and V-dn atoms inequivalent in case.struct, and give them an antiparallel starting configuration in case.inst (which you probably did already). This takes care of the antiparallelism. Specifying one (h,k,l) in case.inso takes care of the (common) direction of both moments. This would not have been possible for non-collinear magnetism (if one V would have its moment at 90 deg with the other, e.g.), which is a situation that cannot be dealt with by wien2k (by the way, are there any plans to add this feature at some time?) Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 09:19:35 +0100 (MET) From: Pavel Novak Subject: Re: [WIEN]: SO ==== Pavel Novak submitted the following contribution: ==== In AF calculation spin on one atom is up, on other atom it is down. You put magnetization along the spin up. Regards Pavel Novak On Tue, 19 Nov 2002 yshzhang@theory.issp.ac.cn wrote: > ==== > yshzhang@theory.issp.ac.cn > submitted the following contribution: > ==== > > Dear all > > I have a trivial question about how to choose the direction of > magnetization (h,k,l) in case.inso. > > I am caculating a AFI V2O3. The spin moment of vanadium do not along the > 0 0 1. Must I change the (h,k,l) along the spin moment of vanadium? > If yes, how can use only one (h,k,l) because the spin moments of two > vanadium in the cell are antiparallel? > > -- > Best Regards > YS Zhang > > ------------------------------------------------------------------------ > Address: Institute of Solid State Physics > Chinese Academy of Sciences > P.O.BOX 1129,230031 Hefei > P.R~China > Tel: 086-551-5591464(Office) > 086-551-5592837(Home) > Fax: 086-551-5591434 > WWW: http://theory.issp.ac.cn/~yshzhang > ------------------------------------------------------------------------ > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 16:32:36 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: Re: [WIEN]: AFI ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== > If you start from a non-magnetic solution you'll probably stay there. You should > start from the AFM solution you're looking for I have been edited case.inst and fliped the spin of one of the AF atoms ( invert the spin up and dn occupation numbers). But the userguide also said: In addition you must set a zero moment (identical spin up and dn oc-cupations) for all non-magnetic atoms, otherwise AFMINPUT cannot determine the proper input for CLMCOPY. I don't know these is special for the AFMINPUT. If I don't use AFMINPUT. Should I also do these(set a zero moment for all non-magnetic atoms? And does it affect property very large? ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 10:47:17 +0100 From: georg@chem.au.dk Subject: Re: [WIEN]: AFI ==== georg@chem.au.dk submitted the following contribution: ==== > But the userguide also said: > In addition you must set a zero moment (identical spin up and dn > oc-cupations) for all non-magnetic atoms, otherwise AFMINPUT cannot > determine the proper input for CLMCOPY. > I don't know these is special for the AFMINPUT. > If I don't use AFMINPUT. Should I also do these(set a zero moment > for all non-magnetic atoms? And does it affect property very large? This isn't necesarry when you don't use AFMINPUT. However if your magnetism is strongly localized on some atoms, while others only have very little spin-density, sometimes you'll get a better convergence if you start with the "non-magnetic" atoms as non-magnetic. Whatever you do your starting density shouldn't affect your self consistent density. Unless off-course, you start so far from the solution that you're looking for that you never get the correct solution. Georg ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 11:56:37 +0100 From: Doru-Cristian Torumba Subject: [WIEN]: MD ==== Doru-Cristian Torumba submitted the following contribution: ==== Dear Wien-users, I try to use the molecular dynamics option of wien2k (MOLD or NOSE in case.inM). I do not succeed to obtain output. My case is documented below. There is not much information in the usersguide about this option. Are there references available of work where the MOLD or NOSE have been used ? Thanks a lot, Doru Torumba University of Leuven - - - - example case : nonmagnetic bcc Fe, both Fe in the conventional unit cell are made inequivalent, all symmetry is removed except for the identity (including all symmetry and/or using a B-lattice with 1 inequivalent Fe gives the same problems). Fe P 2 RELA 5.416900 5.416900 5.416900 90.000000 90.000000 90.000000 ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 2 Fe 781 0.00001000 2.2000 26.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= 1: X=0.50000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 2 Fe 781 0.00001000 2.2000 26.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 1 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 This is the case.inM (MOLD gives same problem): NOSE #(NOSE, NEWT, BFGS, MOLD, tolf (a4,f5.2)) 55.845 400.0 300.0 1.0 # Atom1 (NOSE, MOLD:Masse, delta t, T, nose-frequency) 55.845 400.0 300.0 1.0 # Atom1 (NOSE, MOLD:Masse, delta t, T, nose-frequency) Here is the sequence of commands I used (from :log) : > (min_lapw) options: -j runfile > (min_lapw) recover inm-file & call job runfile > (run_lapw) options: -i 80 -cc 0.000001 Mon Nov 18 15:25:45 CET 2002> (x) lapw0 testfe2 lapw0 Mon Nov 18 15:25:50 CET 2002> (x) lapw1 testfe2 lapw1 Mon Nov 18 15:25:56 CET 2002> (x) lapw2 testfe2 lapw2 Mon Nov 18 15:26:01 CET 2002> (x) lcore testfe2 lcore Mon Nov 18 15:26:02 CET 2002> (x) mixer testfe2 mixer (...) Mon Nov 18 15:26:02 CET 2002> (x) mini testfe2 mini This is the screen output : doru/testfe2> min_lapw -j runfile runfile LAPW0 END LAPW1 END LAPW2 END CORE END MIXER END ...... (-deleted-) ..... LAPW0 END LAPW1 END LAPW2 END CORE END MIXER END PGFIO-F-217/list-directed read/unit=15/attempt to read past end of file. File name = testfe2.finM formatted, sequential access record = 2 In source file haupt.f, at line number 224 The case is well-converged, that's not the problem : :DIS : CHARGE DISTANCE 0.0000001 It does not read case.finM correctly. This file contains only 1 line : -5090.992118 and this number seems to be the total energy of the last iteration : :ENE : ********** TOTAL ENERGY IN Ry = -5090.992118 Output files related to mini are empty : - -rw-r--r-- 1 doru users 0 Nov 18 15:26 testfe2.outputM - -rw-r--r-- 1 doru users 0 Nov 18 15:24 testfe2.tmpM - -rw-r--r-- 1 doru users 0 Nov 18 15:24 testfe2.tmpM1 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 13:08:22 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: SO ==== Peter Blaha submitted the following contribution: ==== > This would not have been possible for non-collinear magnetism (if one V > would have its moment at 90 deg with the other, e.g.), which is a situation > that cannot be dealt with by wien2k (by the way, are there any plans to add > this feature at some time?) Yes, there are. Actually, we have a first working version developed by Robert Laskowsky in our group. One word of warning: When I see the many problems for inexperienced users arising from including SO coupling and/or LDA+U, the inclusion of non-collinear magnetism requires even more knowledge by the user. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 13:22:37 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: MD ==== Peter Blaha submitted the following contribution: ==== > I try to use the molecular dynamics option of wien2k (MOLD or NOSE in > case.inM). I do not succeed to obtain output. My case is documented below. > There is not much information in the usersguide about this option. Are there > references available of work where the MOLD or NOSE have been used ? MD (MOLD) is nothing else than structural minimization (NEWT) without a friction term. NOSE allows in additon to specify a "temperature", i.e. a mean kinetic energy. From the above you must have: i) A setup which allows the atoms to move freely (i.e. usually you must start with some arbitrarely distorted structure). This is more than just putting only the identity symmetry operation into case.struct, but also all LM terms in case.in2c must appear. > ATOM= 1: X=0.00000000 Y=0.00000000 Z=0.00000000 > ATOM= 1: X=0.50000000 Y=0.50000000 Z=0.50000000 Distort the positions! > NOSE #(NOSE, NEWT, BFGS, MOLD, tolf (a4,f5.2)) > 55.845 400.0 300.0 1.0 # Atom1 (NOSE, MOLD:Masse, delta t, T, > nose-frequency) > 55.845 400.0 300.0 1.0 # Atom1 (NOSE, MOLD:Masse, delta t, T, > nose-frequency) A temperature of 1 K will move the atoms very slowly! > > (run_lapw) options: -i 80 -cc 0.000001 Of course for MD one needs the forces on the atoms (otherwise we don't know where we should move the atoms!). Use -fc 1.0 instead of -cc > PGFIO-F-217/list-directed read/unit=15/attempt to read past end of file. > File name = testfe2.finM formatted, sequential access record = 2 > In source file haupt.f, at line number 224 > > The case is well-converged, that's not the problem : > > :DIS : CHARGE DISTANCE 0.0000001 > > It does not read case.finM correctly. This file contains only 1 line : > > -5090.992118 > > and this number seems to be the total energy of the last iteration : Yes, and the forces are missing, because your setup is for a highly symmetric configuration where "symmetry" found out that the atoms are at an equillibrium position and thus no forces will appear. Regards PS: One must find a good example, where MD is usefull at all. Many processes in solids require a much too long simulation time to learn anything from a short simulation of a very small ensamble (supercell). In most cases in literature MD is applied a) to molecules b) used only for structural relaxation (with some friction term and not free MD) c) with some additional constraints 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 13:32:29 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: min_lapw ==== Peter Blaha submitted the following contribution: ==== > I am probably missing something with respect to min_lapw. After running > a few cycles I realised that an atom that should have been fixed in > position was being moved. I changed the corresponding line in case.inM > to 0.0 in all four variables (I use NEWT), and to my surprise, min_lapw > keeps changing the position of that atom several cycles later. I have > checked several times that case.inM has 0.0 for all variables for that > atom in case.struct. What do I have to do to make it stop doing that? > Remove case.tmpM? The atoms that were fixed when I began min_lapw are > kept fixed... Fixing the positions using inM means that the forces on these atoms are set to zero. However, since you started with some non-zero values, these attoms aquiered some speed and they continue moving "with constant speed" even when all forces are zero for this atom. The speed is calculated using the "history"-file case.tmpM and thus it is required that you remove this file whenever you make changes to case.inM. (This is like the "broyden"-files in the scf cycle....) PS: I know that minimization is unnecessary clumsy because one must always remove case.tmpM when one changes case.inM. mini could easily be improved, but time is lacking so far. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 17:28:11 +0100 From: KOITZSCH Christian Subject: [none] ==== KOITZSCH Christian submitted the following contribution: ==== Hi Everybody, I guess I am another of the unexperienced users, who tries to calculate spin-orbit for a Ferromagnet, in my case Gd... I used runsp_lapw and everything goes fine, I obtain results very similar to D. Singh's paper, just that some bands are not split, because I omitted spin-orbit interaction. Now if I want to include that, I save the calculation and run initso_lapw. I get the following output: ****************************************************************** initso_lapw Edit input file Gd.inso select the direction of the moment ( h k l ) (For R-lattice in R coordinates) select atoms for which a Relativistic-LO should be added (heavier elements) or SO should be switched off (light elements) edit: Command not found. Edit input file Gd.in1 select a larger emax value for the energy window in Gd.in1 edit: Command not found. The file Gd.in2c has been generated automatically In spinpolarized case SO may reduce symmetry. The program symmetso dedects the proper symmetry and creates new struct and input files. (Note, equivalent atoms could become inequivalent in some cases). Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y FORTRAN STOP 0.380u 0.020s 0:00.40 100.0% 0+0k 0+0io 204pf+0w edit: Command not found. A new structure for SO calculations has been created (_so). If you commit it will create new Gd.struct, in1(c), in2c, inc, clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous calculations) NOTE: Files for -orb (Gd.indm(c),inorb,dmatup/dn) must be adapted manually Do you want to use the new structure for SO calculations ? (y/N)n Spinorbit is now ready to run. ****************************************************************** I am worried that he does not find "edit", is there way to specify the default editor? And if I then try to run runsp_lapw -so I get the following output: *************************************************************** LAPW0 END LAPW1 END LAPW1 END PGFIO-F-225/list-directed read/unit=5/lexical error-- unknown token type. File name = Gd.inso formatted, sequential access record = 5 In source file init.f, at line number 74 PGFIO-F-217/formatted read/unit=30/attempt to read past end of file. File name = Gd.energysoup formatted, sequential access record = 1 In source file fermi.f, at line number 41 ************************************************************* my initso looks like this: ************************************************************* WFFIL 4 1 0 llmax,ipr,kpot -10.0000 1.50000 emin,emax (output energy window) 0. 0. 1. direction of magnetization (lattice vectors) NX number of atoms for which RLO is added NX1 -4.97 0.005 atom number,e-lo,de (case.in1), repeat NX times 0 0 0 0 0 number of atoms for which SO is switch off; atoms Am I correct that my problem arises because I have to specify something for NX? And what is this for hcp Gd? Thanks a lot Christian Koitzsch ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 19 Nov 2002 17:46:40 +0100 From: "Stefaan Cottenier" Subject: [WIEN]: Re: ==== "Stefaan Cottenier" submitted the following contribution: ==== > ==== > KOITZSCH Christian > submitted the following contribution: > ==== > > I am worried that he does not find "edit", is there way to specify the > default editor? Yes, the editor is specified in the section that wien2k has added to your .cshrc (if you use csh, similar for other shells) : setenv EDITOR "pico" > ************************************************************* > WFFIL > 4 1 0 llmax,ipr,kpot > -10.0000 1.50000 emin,emax (output energy window) > 0. 0. 1. direction of magnetization (lattice vectors) > NX number of atoms for which RLO is added > NX1 -4.97 0.005 atom number,e-lo,de (case.in1), repeat NX > times > 0 0 0 0 0 number of atoms for which SO is switch off; > atoms > > > Am I correct that my problem arises because I have to specify something for > NX? And what is this for hcp Gd? Right. NX should be a number, the number of atoms for which you want to add an RLO (Relativistic Local Orbital). See Kunes et al, PRB64-153102. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 10:41:37 +0900 From: akai Subject: [WIEN]: Deleted a part of a vector file in lapw1. ==== akai submitted the following contribution: ==== Dear WIEN users, I have a trouble about a vector file. I calculate the band structure of Ba8Ga16Ge30. In the calculation a large vector file about 5GB or more is, it seems, made in a temporary area. In running lapw1 the file size become more than 5GB, but when the law1 stoped regularly the file size is only about 2GB. But I can not found any other error signals. When I checked the vector file,the later part of it did not exist,i.e. data for last some k-points are missing. But the output1 file shows that the calculation was carried out until the final k-point. In the calculation I took 172 k-points in the irreducible wedge. When a k-sampling is 60, I have no trouble. We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the compiler is ifc and icc with the intel MKL. MPI_CH is installed , but not used in the calculation. ############## FC = ifc MPF = f90 CC = icc FOPT = -O -FR -mp FPOPT = -O DParallel = '-DParallel' FGEN = $(PARALLEL) LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide ############## - -- ################################## Akai Koji Media and Information Technology Center Yamaguchi University phone: +81 836 85 9900 fax: +81 836 85 9901 e-mail: akai@po.cc.yamaguchi-u.ac.jp ################################## ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 07:25:09 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Deleted a part of a vector file in lapw1. ==== Torsten Andersen submitted the following contribution: ==== Dear Mr. Akai. If you at 60 k-points have 2GB, then 172 k-points will give you around 5.8GB in the vector file. There is no surprise in that. It contains the expansion coefficients to the basis set and the eigenenergies, saved per k-point, so it should scale with the number of k-points. If some data is missing at the end of the vector file, I would worry about the integrity of the file system, or a full disk - alternatively that the core dumps and the program exits - is the error file empty? Best regards, Torsten Andersen. akai wrote: > ==== > akai > submitted the following contribution: > ==== > > Dear WIEN users, > > I have a trouble about a vector file. I calculate the band structure > of Ba8Ga16Ge30. > In the calculation a large vector file about 5GB or more is, it > seems, made in a temporary > area. In running lapw1 the file size become more than 5GB, but when > the law1 stoped > regularly the file size is only about 2GB. But I can not found any > other error signals. > When I checked the vector file,the later part of it did not exist,i.e. > data for last some > k-points are missing. But the output1 file shows that the calculation > was carried out > until the final k-point. In the calculation I took 172 k-points in the > irreducible > wedge. When a k-sampling is 60, I have no trouble. > > We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the > compiler is ifc and > icc with the intel MKL. MPI_CH is installed , but not used in the > calculation. > > ############## > FC = ifc > MPF = f90 > CC = icc > FOPT = -O -FR -mp > FPOPT = -O > DParallel = '-DParallel' > FGEN = $(PARALLEL) > LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib > R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide > ############## > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 22:11:08 +0900 From: akai Subject: Re: [WIEN]: Deleted a part of a vector file in lapw1. ==== akai submitted the following contribution: ==== Dear Mr. Andersen Thank you for your response. The trouble does not due to the file system, because I can make a unformated output file larger than 6GB by executing a simple fortran program. I could not find any error message: lapw1.error is empty, there are no I/O error messages and no core files. I have never seen like this trouble; when the lapw1 is running the vector file become 5GB ormore, but at the time when it stops a part of file is deleted and the size turns small( about 2GB). I can not guess the reason at all. If someone know similar behaviors, would you like to let me known about that. >==== >Torsten Andersen >submitted the following contribution: >==== > >Dear Mr. Akai. > >If you at 60 k-points have 2GB, then 172 k-points will give you >around 5.8GB in the vector file. There is no surprise in that. It >contains the expansion coefficients to the basis set and the >eigenenergies, saved per k-point, so it should scale with the number >of k-points. If some data is missing at the end of the vector file, >I would worry about the integrity of the file system, or a full disk >- alternatively that the core dumps and the program exits - is the >error file empty? > >Best regards, >Torsten Andersen. > >akai wrote: > >>==== >>akai >>submitted the following contribution: >>==== >> >>Dear WIEN users, >> >>I have a trouble about a vector file. I calculate the band >>structure of Ba8Ga16Ge30. >>In the calculation a large vector file about 5GB or more is, it >>seems, made in a temporary >>area. In running lapw1 the file size become more than 5GB, but when >>the law1 stoped >>regularly the file size is only about 2GB. But I can not found any >>other error signals. >>When I checked the vector file,the later part of it did not >>exist,i.e. data for last some >>k-points are missing. But the output1 file shows that the >>calculation was carried out >>until the final k-point. In the calculation I took 172 k-points in >>the irreducible >> wedge. When a k-sampling is 60, I have no trouble. >> >>We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the >>compiler is ifc and >>icc with the intel MKL. MPI_CH is installed , but not used in the >>calculation. >> >>############## >>FC = ifc >>MPF = f90 >>CC = icc >>FOPT = -O -FR -mp >>FPOPT = -O >>DParallel = '-DParallel' >>FGEN = $(PARALLEL) >>LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib >>R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide >>############## >> > > - -- ################################## Akai Koji Media and Information Technology Center Yamaguchi University phone: +81 836 85 9900 fax: +81 836 85 9901 e-mail: akaikoji@po.cc.yamaguchi-u.ac.jp ################################## ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 14:27:04 +0100 From: georg@chem.au.dk Subject: Re: [WIEN]: Deleted a part of a vector file in lapw1. ==== georg@chem.au.dk submitted the following contribution: ==== I know that if you are using the PGI compiler you need to set a -Mlfs swithch to support large files, but I don't know whether this is necesaary with ifc. The man-pages might tell you something Georg BTW. We are finishing a paper at the moment on Ba8Ga16Ge30 (among other clathrates). Quoting akai : > ==== > akai > submitted the following contribution: > ==== > > Dear Mr. Andersen > > Thank you for your response. > > The trouble does not due to the file system, because I can make a > unformated output file larger than 6GB by executing a simple fortran > program. I could not find any error message: lapw1.error is empty, > there are no I/O error messages and no core files. I have never seen > like this trouble; when the lapw1 is running the vector file become > 5GB ormore, but at the time when it stops a part of file is deleted > and the size turns small( about 2GB). I can not guess the reason at all. > > If someone know similar behaviors, would you like to let me known about > that. > > >==== > >Torsten Andersen > >submitted the following contribution: > >==== > > > >Dear Mr. Akai. > > > >If you at 60 k-points have 2GB, then 172 k-points will give you > >around 5.8GB in the vector file. There is no surprise in that. It > >contains the expansion coefficients to the basis set and the > >eigenenergies, saved per k-point, so it should scale with the number > >of k-points. If some data is missing at the end of the vector file, > >I would worry about the integrity of the file system, or a full disk > >- alternatively that the core dumps and the program exits - is the > >error file empty? > > > >Best regards, > >Torsten Andersen. > > > >akai wrote: > > > >>==== > >>akai > >>submitted the following contribution: > >>==== > >> > >>Dear WIEN users, > >> > >>I have a trouble about a vector file. I calculate the band > >>structure of Ba8Ga16Ge30. > >>In the calculation a large vector file about 5GB or more is, it > >>seems, made in a temporary > >>area. In running lapw1 the file size become more than 5GB, but when > >>the law1 stoped > >>regularly the file size is only about 2GB. But I can not found any > >>other error signals. > >>When I checked the vector file,the later part of it did not > >>exist,i.e. data for last some > >>k-points are missing. But the output1 file shows that the > >>calculation was carried out > >>until the final k-point. In the calculation I took 172 k-points in > >>the irreducible > >> wedge. When a k-sampling is 60, I have no trouble. > >> > >>We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the > >>compiler is ifc and > >>icc with the intel MKL. MPI_CH is installed , but not used in the > >>calculation. > >> > >>############## > >>FC = ifc > >>MPF = f90 > >>CC = icc > >>FOPT = -O -FR -mp > >>FPOPT = -O > >>DParallel = '-DParallel' > >>FGEN = $(PARALLEL) > >>LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib > >>R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide > >>############## > >> > > > > > > -- > ################################## > Akai Koji > Media and Information Technology Center > Yamaguchi University > > > phone: +81 836 85 9900 > fax: +81 836 85 9901 > e-mail: akaikoji@po.cc.yamaguchi-u.ac.jp > ################################## > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 14:31:55 +0100 From: georg@chem.au.dk Subject: Re: [WIEN]: Deleted a part of a vector file in lapw1. ==== georg@chem.au.dk submitted the following contribution: ==== Just thought of that you could also run a "parallel" job sequentially: Make a machines file with f.ex. two entries. Remove the rsh from the program calls in the parallel scripts Remove the & after the program calls in the parallel script Then your vector file will be split into two, but you'll still run sequentially Georg Quoting akai : > ==== > akai > submitted the following contribution: > ==== > > Dear Mr. Andersen > > Thank you for your response. > > The trouble does not due to the file system, because I can make a > unformated output file larger than 6GB by executing a simple fortran > program. I could not find any error message: lapw1.error is empty, > there are no I/O error messages and no core files. I have never seen > like this trouble; when the lapw1 is running the vector file become > 5GB ormore, but at the time when it stops a part of file is deleted > and the size turns small( about 2GB). I can not guess the reason at all. > > If someone know similar behaviors, would you like to let me known about > that. > > >==== > >Torsten Andersen > >submitted the following contribution: > >==== > > > >Dear Mr. Akai. > > > >If you at 60 k-points have 2GB, then 172 k-points will give you > >around 5.8GB in the vector file. There is no surprise in that. It > >contains the expansion coefficients to the basis set and the > >eigenenergies, saved per k-point, so it should scale with the number > >of k-points. If some data is missing at the end of the vector file, > >I would worry about the integrity of the file system, or a full disk > >- alternatively that the core dumps and the program exits - is the > >error file empty? > > > >Best regards, > >Torsten Andersen. > > > >akai wrote: > > > >>==== > >>akai > >>submitted the following contribution: > >>==== > >> > >>Dear WIEN users, > >> > >>I have a trouble about a vector file. I calculate the band > >>structure of Ba8Ga16Ge30. > >>In the calculation a large vector file about 5GB or more is, it > >>seems, made in a temporary > >>area. In running lapw1 the file size become more than 5GB, but when > >>the law1 stoped > >>regularly the file size is only about 2GB. But I can not found any > >>other error signals. > >>When I checked the vector file,the later part of it did not > >>exist,i.e. data for last some > >>k-points are missing. But the output1 file shows that the > >>calculation was carried out > >>until the final k-point. In the calculation I took 172 k-points in > >>the irreducible > >> wedge. When a k-sampling is 60, I have no trouble. > >> > >>We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the > >>compiler is ifc and > >>icc with the intel MKL. MPI_CH is installed , but not used in the > >>calculation. > >> > >>############## > >>FC = ifc > >>MPF = f90 > >>CC = icc > >>FOPT = -O -FR -mp > >>FPOPT = -O > >>DParallel = '-DParallel' > >>FGEN = $(PARALLEL) > >>LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib > >>R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide > >>############## > >> > > > > > > -- > ################################## > Akai Koji > Media and Information Technology Center > Yamaguchi University > > > phone: +81 836 85 9900 > fax: +81 836 85 9901 > e-mail: akaikoji@po.cc.yamaguchi-u.ac.jp > ################################## > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 20 Nov 2002 19:24:41 +0100 From: Peer Kruse Subject: Re: [WIEN]: Deleted a part of a vector file in lapw1. ==== Peer Kruse submitted the following contribution: ==== - --------------010701080109070404040906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have a similar problem but my vector file seems to be to big. I don't know how you checked your filesystem it's at least not only a question of limits. I did the following: I created a file of a size half of my partition size with dd if=/dev/zero of= bigfile1 bs=131072 count=88888 That worked. Even cp bigfile1 bigfile2 works and there is no difference in them tested with diff bigfile1 bigfile2 *But* deleting bigfile1 and copying back doesn't work, so I can't check the diffs again. Additionaly random numbers of /dev/random don't even create bigfile1. This was an indication that it is a hard disc problem. I migrated my data to an other disk an now it seems to run, at least the first cycle is through. Best wishes Peer georg@chem.au.dk wrote: >==== >georg@chem.au.dk >submitted the following contribution: >==== > >Just thought of that you could also run a "parallel" job sequentially: >Make a machines file with f.ex. two entries. >Remove the rsh from the program calls in the parallel scripts >Remove the & after the program calls in the parallel script > >Then your vector file will be split into two, but you'll still run sequentially > > Georg > >Quoting akai : > > > >>==== >>akai >>submitted the following contribution: >>==== >> >>Dear Mr. Andersen >> >>Thank you for your response. >> >>The trouble does not due to the file system, because I can make a >>unformated output file larger than 6GB by executing a simple fortran >>program. I could not find any error message: lapw1.error is empty, >>there are no I/O error messages and no core files. I have never seen >>like this trouble; when the lapw1 is running the vector file become >>5GB ormore, but at the time when it stops a part of file is deleted >>and the size turns small( about 2GB). I can not guess the reason at all. >> >>If someone know similar behaviors, would you like to let me known about >>that. >> >> >> >>>==== >>>Torsten Andersen >>>submitted the following contribution: >>>==== >>> >>>Dear Mr. Akai. >>> >>>If you at 60 k-points have 2GB, then 172 k-points will give you >>>around 5.8GB in the vector file. There is no surprise in that. It >>>contains the expansion coefficients to the basis set and the >>>eigenenergies, saved per k-point, so it should scale with the number >>>of k-points. If some data is missing at the end of the vector file, >>>I would worry about the integrity of the file system, or a full disk >>>- alternatively that the core dumps and the program exits - is the >>>error file empty? >>> >>>Best regards, >>>Torsten Andersen. >>> >>>akai wrote: >>> >>> >>> >>>>==== >>>>akai >>>>submitted the following contribution: >>>>==== >>>> >>>>Dear WIEN users, >>>> >>>>I have a trouble about a vector file. I calculate the band >>>>structure of Ba8Ga16Ge30. >>>>In the calculation a large vector file about 5GB or more is, it >>>>seems, made in a temporary >>>>area. In running lapw1 the file size become more than 5GB, but when >>>>the law1 stoped >>>>regularly the file size is only about 2GB. But I can not found any >>>>other error signals. >>>>When I checked the vector file,the later part of it did not >>>>exist,i.e. data for last some >>>>k-points are missing. But the output1 file shows that the >>>>calculation was carried out >>>>until the final k-point. In the calculation I took 172 k-points in >>>>the irreducible >>>> wedge. When a k-sampling is 60, I have no trouble. >>>> >>>>We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the >>>>compiler is ifc and >>>>icc with the intel MKL. MPI_CH is installed , but not used in the >>>>calculation. >>>> >>>>############## >>>>FC = ifc >>>>MPF = f90 >>>>CC = icc >>>>FOPT = -O -FR -mp >>>>FPOPT = -O >>>>DParallel = '-DParallel' >>>>FGEN = $(PARALLEL) >>>>LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib >>>>R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide >>>>############## >>>> >>>> >>>> >>> >>> >>-- >>################################## >> Akai Koji >> Media and Information Technology Center >> Yamaguchi University >> >> >> phone: +81 836 85 9900 >> fax: +81 836 85 9901 >> e-mail: akaikoji@po.cc.yamaguchi-u.ac.jp >>################################## >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> >> >> > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - --------------010701080109070404040906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have a similar problem but my vector file seems to be to big. I don't know how you checked your filesystem
it's at least not only a question of limits.
I did the following:

I created a file of a size half of my partition size  with
dd if=/dev/zero of= bigfile1 bs=131072 count=88888
That worked.  Even
cp bigfile1 bigfile2
works and there is no difference in them tested with
diff bigfile1 bigfile2
*But* deleting  bigfile1 and copying back doesn't work, so I can't check the diffs again.
Additionaly random numbers of /dev/random don't even create bigfile1.
This was an indication that it is a hard disc problem. I migrated my data to an other disk
an now it seems to run, at least the first cycle is through.

Best wishes

Peer

georg@chem.au.dk wrote:
====
georg@chem.au.dk
submitted the following contribution:
====

Just thought of that you could also run a "parallel" job sequentially:
Make a machines file with f.ex. two entries.
Remove the rsh from the program calls in the parallel scripts
Remove the & after the program calls in the parallel script

Then your vector file will be split into two, but you'll still run sequentially

 Georg

Quoting akai <akai@po.cc.yamaguchi-u.ac.jp>:

  
====
akai <akai@po.cc.yamaguchi-u.ac.jp>
submitted the following contribution:
====

Dear Mr. Andersen

Thank you for your response.

The trouble does not due to the file system, because I can make a 
unformated output file larger than 6GB by executing  a simple fortran 
program. I could not find any error message: lapw1.error is empty, 
there are no I/O error messages and no core files. I have never seen 
like this trouble; when the lapw1 is running the vector file become 
5GB ormore, but at the time when it stops a part of file is deleted
and the size turns small( about 2GB). I can not guess the reason at all.

If someone know similar behaviors, would you like to let me known about
that.

    
====
Torsten Andersen <Torsten.Andersen@Fysik.UU.se>
submitted the following contribution:
====

Dear Mr. Akai.

If you at 60 k-points have 2GB, then 172 k-points will give you 
around 5.8GB in the vector file. There is no surprise in that. It 
contains the expansion coefficients to the basis set and the 
eigenenergies, saved per k-point, so it should scale with the number 
of k-points. If some data is missing at the end of the vector file, 
I would worry about the integrity of the file system, or a full disk 
- - alternatively that the core dumps and the program exits - is the 
error file empty?

Best regards,
Torsten Andersen.

akai wrote:

      
====
akai <akai@po.cc.yamaguchi-u.ac.jp>
submitted the following contribution:
====

Dear WIEN users,

I have a trouble about a vector file. I calculate the band 
structure of Ba8Ga16Ge30.
In the calculation a large vector file about 5GB or more  is, it 
seems,  made in a temporary
area. In running lapw1 the file size become more than 5GB, but when 
the law1 stoped
regularly the file size is only about 2GB. But I can not found any 
other error signals.
When I checked the vector file,the later part of it did not 
exist,i.e. data for last some
k-points are missing. But the output1 file shows that the 
calculation was carried out
until the final k-point. In the calculation I took 172 k-points in 
the irreducible
 wedge. When a k-sampling is 60, I have no trouble.

We use a Pentium 4 machine with 1GB RIMM, OS is Hed hat 7.2, the 
compiler is ifc and
icc with the intel MKL. MPI_CH is installed , but not used in the 
calculation.

##############
FC = ifc
MPF = f90
CC = icc
FOPT =  -O -FR -mp
FPOPT = -O
DParallel = '-DParallel'
FGEN = $(PARALLEL)
LDFLAGS = -L/opt/intel/mkl/lib/32 -Vaxlib
R_LIBS = -lmkl_p4 -lmkl_lapack -lpthread -lguide
##############

        
      
-- 
##################################
         Akai Koji
         Media and Information Technology Center
         Yamaguchi University


         phone: +81 836 85 9900
         fax: +81 836 85 9901
         e-mail: akaikoji@po.cc.yamaguchi-u.ac.jp
##################################
====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====

    


====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


- --------------010701080109070404040906-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 10:59:06 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: ixcpot 4 : VBH ==== Peter Blaha submitted the following contribution: ==== > I got a question about "ixcpot" option "4" in input *.in0. > > ! IXCPOT : = 1 : JMW SPIN-POLARIZED > ! = 2 : HL-NEW > ! = 3 : HL-OLD (FREEMAN) > ! = 4 : VBH > > I think option "4" is for U.von.Barth and L.Hedin exchange-correlation and > it should work for spin polarized case. > But it seems not to work for spin polarized case. With this option, > "*.vnsup" is exactly same with *.vnsdn" and > "*.vspup also same with *.vspdn" . > Here are my questions. > Are these options(2,3,4) not completely implemented yet? > Are these options(2,3,4) just for unpolarized case ? Options 2,3,4 are for unpolarized case only! > Can these options(2,3,4) work for polarized case after comment out > that line ? > What do I need more for spin polarized calculation with option '4' ? I don't know ! From those old options only 1 is spinpolarized and if I remember correctly, JMW reduces to VBH in unpolarized case (but this is long time ago...)? Why would you want to use old and obsolete LSDA Versions ? Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #44 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #45 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, November 28 2002 Volume 2002 : Number 045 ---------------------------------------------------------------------- Date: Thu, 21 Nov 2002 11:09:03 +0100 From: Thomas Claesson Subject: [WIEN]: Piping stdout to a file ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! I am running wien2k on an AIX multiprocessor system, where I submit my jobs to a queuing system. When the job is finished I get an email with everything wien2k has written to stdout during the run. I wonder if it is possible to pipe the output written by wien to a file that grows continuously during the run, so that I don't have to wait until the whole run is completed before I can read it? I found this answer to a similar question in an old email from the list: >I can provide an answer if you are using the bash shell (typical for >linux). To background a job, do: > run_lapw options run.output & However, I am using the tcsh shell. What should I do to prevent the output to go to stdout and instead go to a file? Thanks for your replies! Any suggestions are welcome! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 12:22:54 +0100 (MET) From: buero@luitz.at Subject: Re: [WIEN]: Piping stdout to a file ==== buero@luitz.at submitted the following contribution: ==== On Thu, 21 Nov 2002, Thomas Claesson wrote: > >I can provide an answer if you are using the bash shell (typical for > >linux). To background a job, do: > > > run_lapw options run.output & > > However, I am using the tcsh shell. What should I do to prevent the > output to go to stdout and instead go to a file? This line to me looks like for tcsh for bash it should read however it contains a severe typo: instead of "&>" it must read ">&" ">" redirects std.out and ">&" redirects std.out and std.err. &> would try to send the first part of the line to the background and gives an error because it tries to redirect the output of a null command. In bash the line should read run_lapw -options run.output 2>&1 & ( 2>&1 means send stderr [channel 2] to the same file where stdout [channel 1] goes) regards joachim /---------------------------------------------------------\ ( luitz.at - Interfacing Art, Science and Technology ) )---------------------------------------------------------( ( Büro für Informationstechnologie \ ) und Technisches Büro für Technische Chemie ) ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( ) Wohlmuthgasse 18 0676 31 61254 ) ( A-3003 Gablitz Fax: 022 31 67443 ( \ http://www.luitz.at buero@luitz.at ) \---------------------------------------------------------/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 15:19:50 +0100 From: Thomas Claesson Subject: Re: [WIEN]: Piping stdout to a file ==== Thomas Claesson submitted the following contribution: ==== Thanks for your reply Joachim! In principle it works, but the result is not what I want it to be. When I submit my job to the queuing system, like this: >> spsubmit [submit_options] runsp_lapw [run_options] [pipe_characters] I get a short message back confirming that my job has been submitted to the que and that is all that gets printed in my run.output file. All the output produced by wien2k is still directed to stdout as usual. Can I modify the suggested pipe command in some way to get around this problem, or do I have to modify the wien shell scripts (run_lapw, runsp_lapw,...)? Thanks for your replies! Best reagrds, Thomas Claesson buero@luitz.at wrote: > ==== > buero@luitz.at > submitted the following contribution: > ==== > > On Thu, 21 Nov 2002, Thomas Claesson wrote: > > >> >I can provide an answer if you are using the bash shell (typical for >> >linux). To background a job, do: >> >> > run_lapw options run.output & >> >>However, I am using the tcsh shell. What should I do to prevent the >>output to go to stdout and instead go to a file? > > > This line to me looks like for tcsh for bash it should read however it > contains a severe typo: instead of "&>" it must read ">&" > > ">" redirects std.out and ">&" redirects std.out and std.err. > > &> would try to send the first part of the line to the background and > gives an error because it tries to redirect the output of a null > command. > > In bash the line should read > > run_lapw -options run.output 2>&1 & > > ( 2>&1 means send stderr [channel 2] to the same file where stdout > [channel 1] goes) > > > regards > joachim > > /---------------------------------------------------------\ > ( luitz.at - Interfacing Art, Science and Technology ) > )---------------------------------------------------------( > ( Büro für Informationstechnologie \ > ) und Technisches Büro für Technische Chemie ) > ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( > ) Wohlmuthgasse 18 0676 31 61254 ) > ( A-3003 Gablitz Fax: 022 31 67443 ( > \ http://www.luitz.at buero@luitz.at ) > \---------------------------------------------------------/ > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 09:32:12 -0500 From: Jeff Spirko Subject: Re: [WIEN]: Piping stdout to a file ==== Jeff Spirko submitted the following contribution: ==== On Thu, Nov 21, 2002 at 12:22:54PM +0100, buero@luitz.at wrote: > On Thu, 21 Nov 2002, Thomas Claesson wrote: > > >I can provide an answer if you are using the bash shell (typical for > > >linux). To background a job, do: > > > run_lapw options run.output & > > However, I am using the tcsh shell. What should I do to prevent the > > output to go to stdout and instead go to a file? > This line to me looks like for tcsh for bash it should read however it > contains a severe typo: instead of "&>" it must read ">&" > ">" redirects std.out and ">&" redirects std.out and std.err. > &> would try to send the first part of the line to the background and > gives an error because it tries to redirect the output of a null > command. With bash, both >& and &> are allowed, as well as using the 2>&1 (it must appear after the >run.output). With tcsh, only >& works. > In bash the line should read > run_lapw -options run.output 2>&1 & It is important to make sure your job doesn't get killed when you log out or your connection dies. (Bash protects from a logout, but not a hangup.) For that, use nohup. It has the added benefit of doing the output redirection for you (to nohup.out). So my preferred form of background running is now: nohup run_lapw -options The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 15:32:16 +0100 (MET) From: buero@luitz.at Subject: Re: [WIEN]: Piping stdout to a file ==== buero@luitz.at submitted the following contribution: ==== On Thu, 21 Nov 2002, Thomas Claesson wrote: > I submit my job to the queuing system, like this: > > >> spsubmit [submit_options] runsp_lapw [run_options] [pipe_characters] If you redirect this line, it is obvious that every redirection is applied to the first command specified, and that is spsubmit ! Write your commandline in a small script file like myscriptfile: #!/bin/bash run_lapw [options] [redirection] and submit this to the queue spsubmit myscriptfile or try using w2web, this automatically creates a ".command" file, which is submitted to the queue and the output redirected to a file called STDOUT Regards Joachim /---------------------------------------------------------\ ( luitz.at - Interfacing Art, Science and Technology ) )---------------------------------------------------------( ( Büro für Informationstechnologie \ ) und Technisches Büro für Technische Chemie ) ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( ) Wohlmuthgasse 18 0676 31 61254 ) ( A-3003 Gablitz Fax: 022 31 67443 ( \ http://www.luitz.at buero@luitz.at ) \---------------------------------------------------------/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 15:35:22 +0100 (MET) From: buero@luitz.at Subject: Re: [WIEN]: Piping stdout to a file ==== buero@luitz.at submitted the following contribution: ==== On Thu, 21 Nov 2002, Jeff Spirko wrote: > I just wish I could watch the case.output* files grow. For some > reason, they're buffered instead of printing line-by-line. > I've even tried inserting call setlinebuf(6) in SRC_lapw1/inilpw.f, > and it still gets buffered. That's FORTAN-magic ,-) Only standard output is unbuffered. Big hello to Lehigh Joachim /---------------------------------------------------------\ ( luitz.at - Interfacing Art, Science and Technology ) )---------------------------------------------------------( ( Büro für Informationstechnologie \ ) und Technisches Büro für Technische Chemie ) ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( ) Wohlmuthgasse 18 0676 31 61254 ) ( A-3003 Gablitz Fax: 022 31 67443 ( \ http://www.luitz.at buero@luitz.at ) \---------------------------------------------------------/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 09:38:49 -0500 From: Jeff Spirko Subject: Re: [WIEN]: Piping stdout to a file ==== Jeff Spirko submitted the following contribution: ==== On Thu, Nov 21, 2002 at 03:19:50PM +0100, Thomas Claesson wrote: > In principle it works, but the result is not what I want it to be. When > I submit my job to the queuing system, like this: > > >> spsubmit [submit_options] runsp_lapw [run_options] [pipe_characters] > > I get a short message back confirming that my job has been submitted to > the que and that is all that gets printed in my run.output file. Your current shell is grabbing your redirections instead of passing them on to the queuing system. You can try putting the redirection symbols in quotation marks, or you may have to do something drastic like: spsubmit bash -c "run_lapw ..." with all of your redirects in the quotes. Or you can put your commands in a script file and submit that. - -- Jeff Spirko spirko@lehigh.edu spirko@yahoo.com WD3V |=> The study of non-linear physics is like the study of non-elephant biology. All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 16:07:37 +0000 (GMT) From: David Pankhurst Subject: Re: [WIEN]: Piping stdout to a file ==== David Pankhurst submitted the following contribution: ==== Hi Thomas, Queue submission commands generally have options to redirect standard error (stderr) and standard output (stdout). I've never used spsubmit but having done a quick web search I think the following might give the desired result: spsubmit -Email no -stdout outfilename -stderr errfilename run_lapw I guess you could also make errfilename and outfilename the same file if you want both output streams in one file. best regards, Dave On Thu, 21 Nov 2002, Thomas Claesson wrote: > ==== > Thomas Claesson > submitted the following contribution: > ==== > > Thanks for your reply Joachim! > > In principle it works, but the result is not what I want it to be. When > I submit my job to the queuing system, like this: > > >> spsubmit [submit_options] runsp_lapw [run_options] [pipe_characters] > > I get a short message back confirming that my job has been submitted to > the que and that is all that gets printed in my run.output file. All the > output produced by wien2k is still directed to stdout as usual. Can I > modify the suggested pipe command in some way to get around this > problem, or do I have to modify the wien shell scripts (run_lapw, > runsp_lapw,...)? > > Thanks for your replies! > > Best reagrds, > Thomas Claesson > > buero@luitz.at wrote: > > ==== > > buero@luitz.at > > submitted the following contribution: > > ==== > > > > On Thu, 21 Nov 2002, Thomas Claesson wrote: > > > > > >> >I can provide an answer if you are using the bash shell (typical for > >> >linux). To background a job, do: > >> > >> > run_lapw options run.output & > >> > >>However, I am using the tcsh shell. What should I do to prevent the > >>output to go to stdout and instead go to a file? > > > > > > This line to me looks like for tcsh for bash it should read however it > > contains a severe typo: instead of "&>" it must read ">&" > > > > ">" redirects std.out and ">&" redirects std.out and std.err. > > > > &> would try to send the first part of the line to the background and > > gives an error because it tries to redirect the output of a null > > command. > > > > In bash the line should read > > > > run_lapw -options run.output 2>&1 & > > > > ( 2>&1 means send stderr [channel 2] to the same file where stdout > > [channel 1] goes) > > > > > > regards > > joachim > > > > /---------------------------------------------------------\ > > ( luitz.at - Interfacing Art, Science and Technology ) > > )---------------------------------------------------------( > > ( Büro für Informationstechnologie \ > > ) und Technisches Büro für Technische Chemie ) > > ( Dipl.-Ing. Joachim Luitz KEG Tel: 022 31 61254 ( > > ) Wohlmuthgasse 18 0676 31 61254 ) > > ( A-3003 Gablitz Fax: 022 31 67443 ( > > \ http://www.luitz.at buero@luitz.at ) > > \---------------------------------------------------------/ > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > +---------------------------------+------------------------------------+ | Dr David Pankhurst, | Tel : +44 1865 283325/283326 | | Department of Materials, | Fax : +44 1865 273789 | | University of Oxford, | | | Parks Road, Oxford OX1 3PH, UK | david.pankhurst@materials.ox.ac.uk | +---------------------------------+------------------------------------+ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 16:01:43 +0000 From: Paula Subject: [WIEN]: 'SECLR4' ==== Paula submitted the following contribution: ==== - --=====================_15541845==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, I have tried to run an scf cycle fo the perovskite systen PbTiO3. The calculation immediately crashes with the following error message. I have not seen this message before, any ideas? I have attached the .struct file and the .in1c file. Thanks, Paula ** Error in Parallel LAPW1 ** LAPW1 STOPPED at Thu Nov 21 15:44:49 GMT 2002 ** check ERROR FILES! Cholesky INFO = 1147 'SECLR4' - POTRF (Scalapack/LAPACK) failed. Cholesky INFO = 1149 'SECLR4' - POTRF (Scalapack/LAPACK) failed. - --=====================_15541845==_ Content-Type: application/octet-stream; name="pbtio3.struct" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pbtio3.struct" UGJUaU8zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIApQICAgTEFUVElDRSxOT05FUVVJVi4gQVRPTVM6IDQ5OV9Q NG1tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCk1PREUgT0YgQ0FM Qz1SRUxBIHVuaXQ9YW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICA3LjM2ODA0NSAgNy4zNjgwNDUgIDcuODc0NDkyIDkwLjAwMDAwMCA5MC4w MDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAgICAgICAgIApBVE9NPSAtMTogWD0wLjAwMDAwMDAw IFk9MC4wMDAwMDAwMCBaPTAuMDAwMDAwMDAKICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQ TElUPS0yClBiICAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDAwNTAwIFJNVD0gICAgMi4xNTAw ICAgWjogODIuMCAgICAgICAgICAgICAgICAgICAKTE9DQUwgUk9UIE1BVFJJWDogICAgMS4wMDAw MDAwIDAuMDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDEu MDAwMDAwMCAwLjAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDAKQVRPTT0gLTI6IFg9MC41MDAwMDAwMCBZPTAuNTAwMDAwMDAgWj0wLjU0MTAw MDAwCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElTUExJVD0tMgpUaSAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAwNTAwMCBSTVQ9ICAgIDEuODUwMCAgIFo6IDIyLjAgICAgICAgICAgICAg ICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAw CiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAgICAg ICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCkFUT009IC0zOiBY PTAuNTAwMDAwMDAgWT0wLjUwMDAwMDAwIFo9MC4xMTQ4MDAwMAogICAgICAgICAgTVVMVD0gMSAg ICAgICAgICBJU1BMSVQ9LTIKTyAgICAgICAgICBOUFQ9ICA3ODEgIFIwPTAuMDAwMTAwMDAgUk1U PSAgICAxLjUwMDAgICBaOiAgOC4wICAgICAgICAgICAgICAgICAgIApMT0NBTCBST1QgTUFUUklY OiAgICAxLjAwMDAwMDAgMC4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAw LjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMAogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMC4wMDAwMDAwIDEuMDAwMDAwMApBVE9NPSAtNDogWD0wLjUwMDAwMDAwIFk9MC4wMDAwMDAw MCBaPTAuMDAwMDAwMDAKICAgICAgICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4CiAgICAg IC00OiBYPTAuMDAwMDAwMDAgWT0wLjUwMDAwMDAwIFo9MC4wMDAwMDAwMApPICAgICAgICAgIE5Q VD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNTAwMCAgIFo6ICA4LjAgICAgICAgICAg ICAgICAgICAgCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAgMC4wMDAwMDAwCiAg ICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAwMDAwMDAgMS4wMDAwMDAwCiAgIDggICAg ICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUwotMSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAw LjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgMQotMSAwIDAgMC4wMDAwMDAwCiAwIDEg MCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgMgogMC0xIDAgMC4wMDAwMDAwCi0x IDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgMwogMCAxIDAgMC4wMDAwMDAw Ci0xIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgNAogMC0xIDAgMC4wMDAw MDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgNQogMCAxIDAgMC4w MDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgNgogMSAwIDAg MC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgNwogMSAw IDAgMC4wMDAwMDAwCiAwIDEgMCAwLjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgOAo= - --=====================_15541845==_ Content-Type: application/octet-stream; name="pbtio3.in1c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pbtio3.in1c" V0ZGSUwgICAgICAgIChXRlBSSSwgU1VQV0YpCiAgOC4wMCAgICAgICAxMiAgICA0IChSLU1UKkst TUFYOyBNQVggTCBJTiBXRiwgVi1OTVQKICAwLjMwICAgIDUgIDAgKEdMT0JBTCBFLVBBUkFNRVRF UiBXSVRIIG4gT1RIRVIgQ0hPSUNFUywgZ2xvYmFsIEFQVy9MQVBXKQogMiAgIC0xLjE1ICAgICAg MC4wMTAgQ09OVCAxCiAyICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEKIDAgICAgMC4zMCAgICAg IDAuMDAwIENPTlQgMQogMSAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAxCiAwICAgLTcuMzAgICAg ICAwLjAwMCBDT05UIDEKICAwLjMwICAgIDYgIDAgKEdMT0JBTCBFLVBBUkFNRVRFUiBXSVRIIG4g T1RIRVIgQ0hPSUNFUywgZ2xvYmFsIEFQVy9MQVBXKQogMCAgICAxLjMwICAgICAgMC4wMDAgQ09O VCAxCiAwICAgLTQuMzUgICAgICAwLjAwNSBTVE9QIDEKIDEgICAtMi41OCAgICAgIDAuMDEwIENP TlQgMQogMSAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAxCiAyICAgIDAuMzAgICAgICAwLjAxMCBD T05UIDEKIDIgICAgMi4zMCAgICAgIDAuMDAwIENPTlQgMQogIDAuMzAgICAgNCAgMCAoR0xPQkFM IEUtUEFSQU1FVEVSIFdJVEggbiBPVEhFUiBDSE9JQ0VTLCBnbG9iYWwgQVBXL0xBUFcpCiAwICAg LTEuNTUgICAgICAwLjAxMCBDT05UIDEKIDAgICAgMS4zMCAgICAgIDAuMDAwIENPTlQgMQogMSAg ICAwLjMwICAgICAgMC4wMDAgQ09OVCAxCiAxICAgIDIuMzAgICAgICAwLjAwMCBDT05UIDEKICAw LjMwICAgIDQgIDAgKEdMT0JBTCBFLVBBUkFNRVRFUiBXSVRIIG4gT1RIRVIgQ0hPSUNFUywgZ2xv YmFsIEFQVy9MQVBXKQogMCAgIC0xLjU1ICAgICAgMC4wMTAgQ09OVCAxCiAwICAgIDEuMzAgICAg ICAwLjAwMCBDT05UIDEKIDEgICAgMC4zMCAgICAgIDAuMDAwIENPTlQgMQogMSAgICAyLjMwICAg ICAgMC4wMDAgQ09OVCAxCkstVkVDVE9SUyBGUk9NIFVOSVQ6NCAgIC03LjAgICAgICAgNC4wICAg ICAgZW1pbi9lbWF4IHdpbmRvdwo= - --=====================_15541845==_-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 18:19:41 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: 'SECLR4' ==== "Kevin Jorissen" submitted the following contribution: ==== Hi Paula, lstart gives charge leakage of about 0.03 e when you select -6 Ry as separation energy between core and valence region. You have to include the Pb 5p-states to remedy this. You'll have to select Esep about -7.5 - -8 instead of -6. Maybe this solves your problem already? Kevin. kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Paula" To: Sent: Thursday, November 21, 2002 5:01 PM Subject: [WIEN]: 'SECLR4' > Hello, > > I have tried to run an scf cycle fo the perovskite systen PbTiO3. The > calculation immediately crashes with the following error message. I have > not seen this message before, any ideas? I have attached the .struct file > and the .in1c file. > > Thanks, > Paula > > > ** Error in Parallel LAPW1 > ** LAPW1 STOPPED at Thu Nov 21 15:44:49 GMT 2002 > ** check ERROR FILES! > Cholesky INFO = 1147 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. > Cholesky INFO = 1149 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 18:22:31 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: 'SECLR4' ==== "Kevin Jorissen" submitted the following contribution: ==== a quick test with lower rkmax finished an scf-cycle without any problem let me know if you still have trouble kevin. - ----- Original Message ----- From: "Paula" To: Sent: Thursday, November 21, 2002 5:01 PM Subject: [WIEN]: 'SECLR4' > Hello, > > I have tried to run an scf cycle fo the perovskite systen PbTiO3. The > calculation immediately crashes with the following error message. I have > not seen this message before, any ideas? I have attached the .struct file > and the .in1c file. > > Thanks, > Paula > > > ** Error in Parallel LAPW1 > ** LAPW1 STOPPED at Thu Nov 21 15:44:49 GMT 2002 > ** check ERROR FILES! > Cholesky INFO = 1147 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. > Cholesky INFO = 1149 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 19:14:05 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: 'SECLR4' ==== Peter Blaha submitted the following contribution: ==== > I have tried to run an scf cycle fo the perovskite systen PbTiO3. The > calculation immediately crashes with the following error message. I have > not seen this message before, any ideas? I have attached the .struct file > and the .in1c file. > Cholesky INFO = 1147 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. > Cholesky INFO = 1149 > 'SECLR4' - POTRF (Scalapack/LAPACK) failed. Such messages mean either: Your struct file is wrong (2 atoms at the same place,....) (Yours seems ok) You have an numerically overcomplete basis leading to linear dependency: You are using RKMAX=8, APW+lo method for ALL atoms AND have quite different RMT (1.5 for Oxygen and 2.15 for Pb). This input gives an effective RKMAX=11.5 with APW+lo for Pb (which is a "soft" element and converges pretty easy.) I suggest either you reduce RKMAX back to 7 or 7.5, or you remove the APW+lo basis for Pb. WFFIL (WFPRI, SUPWF) 8.00 12 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 2 -1.15 0.010 CONT 0 2 0.30 0.000 CONT 0 0 0.30 0.000 CONT 0 1 0.30 0.000 CONT 0 0 -7.30 0.000 CONT 0 <---put zeros here Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 21 Nov 2002 22:08:11 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: Isomer shift ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Win2k users: I am trying to calculate the Isomer Shift(IS) of the Fe in MgNi3-xFexC compounds. I use the density of the charge at nucleus from *.scf file to calculate the IS. I found that IS is too small. I think that I should take the contact charge density at a certain radius. But I do not know the information about this charge density. Would you please give some suggestions? Could someone tell me whether the charge density at nucleus from *.scf can be used or not? What is the unit for this charge density? Is it in e/au^3? Do I need to use the charge density at a certain radius? I calculated the bcc Fe, I got charge density at nucleus: total= 14889.794645. I read Dr. Blaha and Shwarz's paper( J. De Physique 1988, C8-101), and their result was total=15222.00. Thank you so much best regard Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165 Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 10:50:46 +0100 From: Vladimir Timochevski Subject: Re: [WIEN]: Isomer shift ==== Vladimir Timochevski submitted the following contribution: ==== "Yang, Jinbo (UMR-Student)" wrote: > > ==== > "Yang, Jinbo (UMR-Student)" > submitted the following contribution: Dear Jinbo, The "density at the nucleus", which you find in the *.scf file is the density taken at the first point of the radial mesh. Typically this value depends on Rmt, size of the basis set (if you add LO for Fe3d or not), etc. So, to compare this value with somebody else you need to use exactly the same parameters as they did. Or, you can calculate your own "calibration constant" by doing a number of calculations for iron compounds, but still you need to take exactly the same parameters for Fe atom in all compounds. After that you do calculation for your system under study and determine theoretical value of the isomer shift by using your own "calibration constant". From my own experience, I obtained better results when I took "density at the nucleus" not at the first point of the mesh, but the average value in the sphere with the approximate nuclear radius: Rnuc=1.2*(A)^(1/3)*10^(-5) (Ang), where A-number of nucleons in the nucleus. The density you take from the file *.clmsum (only the spherically symmetric Y00 part for Fe atom), but do not forget that you have a log-scale. Regards, Vladimir. > ==== > > Dear Win2k users: > > I am trying to calculate the Isomer Shift(IS) of the Fe in MgNi3-xFexC compounds. I use the density of the charge at nucleus from *.scf file to calculate the IS. I found that IS is too small. I think that I should take the contact charge density at a certain radius. But I do not know the information about this charge density. Would you please give some suggestions? > > Could someone tell me whether the charge density at nucleus from *.scf can be used or not? What is the unit for this charge density? Is it in e/au^3? Do I need to use the charge density at a certain radius? > > I calculated the bcc Fe, I got charge density at nucleus: total= 14889.794645. I read Dr. Blaha and Shwarz's paper( J. De Physique 1988, C8-101), and their result was total=15222.00. > > Thank you so much > > best regard > > Jinbo Yang > Materials Research Center > University Of Missouri-Rolla > Rolla, MO 65409 > Phone:+01-573-341-6165 > Fax: 573-341-2071 > E-mail:jinbo@umr.edu > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - -- - --------------------------------------------- Vladimir Timoshevskii Departement de Physique de Materiaux Universite Claude Bernard - Lyon 1 Lyon, France Tel.: +33 472 431564 Fax: +33 472 432648 email: Vladimir.Timochevski@dpm.univ-lyon1.fr - --------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 10:59:55 +0000 From: Paula Subject: Re: [WIEN]: 'SECLR4' ==== Paula submitted the following contribution: ==== Many thanks to both Peter and Kevin for the advice. lapw1 now runs with no problems. Paula ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 08:53:27 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: Isomer shift ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Dr. Vladimir Thank you so much. Your advice is very helpful. Could you tell me what is the unit of this charge density? best regard Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165(O), 573-308-1062(H) Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 17:31:22 +0100 From: Vladimir Timochevski Subject: Re: [WIEN]: Isomer shift ==== Vladimir Timochevski submitted the following contribution: ==== Dear Jinbo, The units of the density are e/bohr. But the numbers in *.clmsum file are written as r^2*rho(r), and the spherically symmetric Y00 part (which you are interested in !!) is written as 4*pi*r^2*rho(r). Good luck, Vladimir. "Yang, Jinbo (UMR-Student)" wrote: > > ==== > "Yang, Jinbo (UMR-Student)" > submitted the following contribution: > ==== > > Dear Dr. Vladimir > > Thank you so much. > Your advice is very helpful. > Could you tell me what is the unit of this charge density? > > best regard > > Jinbo Yang > Materials Research Center > University Of Missouri-Rolla > Rolla, MO 65409 > Phone:+01-573-341-6165(O), 573-308-1062(H) > Fax: 573-341-2071 > E-mail:jinbo@umr.edu > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - --------------------------------------------- Vladimir Timoshevskii Departement de Physique de Materiaux Universite Claude Bernard - Lyon 1 Lyon, France Tel.: +33 472 431564 Fax: +33 472 432648 email: Vladimir.Timochevski@dpm.univ-lyon1.fr - --------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 17:34:09 +0100 From: Vladimir Timochevski Subject: Re: [WIEN]: Isomer shift ==== Vladimir Timochevski submitted the following contribution: ==== Small correction to my previous email: the units are e/(borh)^3, of course. Sorry for that. Vladimir. "Yang, Jinbo (UMR-Student)" wrote: > > ==== > "Yang, Jinbo (UMR-Student)" > submitted the following contribution: > ==== > > Dear Dr. Vladimir > > Thank you so much. > Your advice is very helpful. > Could you tell me what is the unit of this charge density? > > best regard > > Jinbo Yang > Materials Research Center > University Of Missouri-Rolla > Rolla, MO 65409 > Phone:+01-573-341-6165(O), 573-308-1062(H) > Fax: 573-341-2071 > E-mail:jinbo@umr.edu > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - -- - --------------------------------------------- Vladimir Timoshevskii Departement de Physique de Materiaux Universite Claude Bernard - Lyon 1 Lyon, France Tel.: +33 472 431564 Fax: +33 472 432648 email: Vladimir.Timochevski@dpm.univ-lyon1.fr - --------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 10:26:31 -0700 From: gelfand Subject: [WIEN]: Peculiar error during lapw1 start-up ==== gelfand submitted the following contribution: ==== Recently it has become impossible for me to run lapw1c: the following message goes to STDOUT and program terminates. A(an) READ statement cannot be executed for a unit in which the value of the ACTION specifier of an OPEN statement is write (unit= 0). Error occurs at or near line 401 of inilpw_ Called from or near line 39 of MAIN__ A(an) READ statement cannot be executed for a unit in which the value of the ACTION specifier of an OPEN statement is write (unit= 0). Error occurs at or near line 401 of inilpw_ Called from or near line 39 of MAIN__ This is from lf95-compiled wien2k on x86/linux. I'm trying to run spin-polarized, parallel calculations (but I have run this before many times, without this error). The section of the code referenced involves reading in k-point information. There's no unit 0 in the relevant .def file (uplapw1.def, right?). Does anyone have any idea as to what might be going on? Thanks, Martin Gelfand Department of Physics Colorado State University ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 11:33:30 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: Isomer shift ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Dr. Blaha and Wien2k users: I am new user of Wien2k. I try to obtain the charge density p(r) of Fe atoms using "run program" Task" "Electron density plots". I want to plot total charge density p(r) of Fe, therefore I can use it to average the contact charge density of Fe at a certain radius. I relapce case.clmvalup with case.clmsum in the lapw5.def. I found the value of total charge density p(r=0) is in the order of 100, however, I see the value of charge density at nucleus in *.scf is in the order of 1000. I do not know if there is any differnce between the charge density from *.scf and "Electron density plots". Does anyboday know the difference and how to get the contact charge density p(r) from Wien2K. thank you so much Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165(O), 573-308-1062(H) Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 22 Nov 2002 23:37:54 -0800 (PST) From: mehrdad dadsetani Subject: [WIEN]: optic properties of HgI2 ==== mehrdad dadsetani submitted the following contribution: ==== I am user wien97 i am study to optic properties of HgI2.i run optic succecfuly and generate *.outmat and *.outputop. but when i run joint, i have message that "invalid integer:read unexpected character apparent state: unit 5 named HgI2.injoint last format: list io lately reading sequential formatted external I0 Abort(core dumped)" HgI2.inop and HgI2.injoint are 150 1 number of k-points, first k-point - -5.0 2.0 Emin, Emax for matrix elements 2 number of choices (columns in *outmat) 1 Re xx 3 Re zz - ---------------------------------------------- 1 40 : LOWER AND UPPER BANDINDEX -5.0000 0.0100 2.0000 : EMIN DE EMAX FOR ENERGYGRID IN ryd ryd : output units eV / ryd / cm-1 4 : SWITCH 2 : NUMBER OF COLUMNS 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - ONLY) - ------------------------------------------------------ HgI2.outputjoint and HgI2 joint are empyty Thanks, Mehrdad dadsetani Department of Physics lorestan University __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 23 Nov 2002 21:09:49 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: charge density ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Win2k Users: I try to obtain the total charge density at different sites by running lapw5. However, no matter where I put my origin of the plot, I always get the same values in the case.rho. I already changed the case.clmval to case.clmsum in the lapw5.def and also change the origin of plot in case.in5. Does anyone has some experience or give some suggestion? Thank you so much best regard Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165(O), 573-308-1062(H) Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 24 Nov 2002 02:40:50 -0800 (PST) From: hamid salehi Subject: [WIEN]: SCF ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started SCf and got this message( in Lapwo ,"SELECT ERROR" "SELECT" -no energy limits found for l=2 "SELECT" -E-bottom -2.48500,E-top -200.00000). what dose it mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 25 Nov 2002 14:20:55 +0100 (MET) From: Peter Blaha Subject: RE: [WIEN]: Isomer shift ==== Peter Blaha submitted the following contribution: ==== > I try to obtain the charge density p(r) of Fe atoms using "run program" Task" "Electron density plots". I want to plot total charge density p(r) of Fe, therefore I can use it to average the contact charge density of Fe at a certain radius. I relapce case.clmvalup with case.clmsum in the lapw5.def. I found the value of total charge density p(r=0) is in the order of 100, however, I see the value of charge density at nucleus in *.scf is in the order of 1000. I do not know if there is any differnce between the charge density from *.scf and "Electron density plots". Does anyboday know the difference and how to get the contact charge density p(r) from Wien2K. You cannot use lapw5 to calculate rho at the position of the nucleus!! We use a radial mesh (r_i=R0*exp(dx*(i-1)) for the numerical values of the density inside the sphere. The first mesh point is called R0 and something like 0.0005 bohr (Z-dependend), thus when you want to get rho at r=0 you must extrapolate (in a very clever way!). Since this extrapolation might be hard to achieve, one usually takes the density at the first radial mesh point as an approximation for r=0 and this value is printed in the scf file (Maybe others have more experience and take some average,... however, I as far as I understand this averaging is justified only for HFF (where we do it anyway in mixer)). If you don't want to use the value of the scf file, you must grab the density directly from the clmsum file. As was mentioned before, for IS you should make several calculations (at least "source" and "absorber" with identical r0, RMT, RKMAX and GMAX. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 25 Nov 2002 09:31:41 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: Isomer shift ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Dr. Blaha and Wien2k Users: Thank you so much for your advice. However, I still do not understand why I got same output(case.rho)if I change the origin and end of the x y plot in the case.in5. I used case.clmsum to replace the case.clmval in lapw5.def. Did I make any mistake? Please give me some suggestion. Thank you again Jinbo Yang Materials Research Center University of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165(O), 573-308-1062(H) Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 25 Nov 2002 16:36:00 +0100 (MET) From: Peter Blaha Subject: RE: [WIEN]: Isomer shift ==== Peter Blaha submitted the following contribution: ==== > However, I still do not understand why I got same output(case.rho)if I change the origin and end of the x y plot in the case.in5. I used case.clmsum to replace the case.clmval in lapw5.def. > Did I make any mistake? Please give me some suggestion. Yes, you probably did. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 25 Nov 2002 14:49:08 -0800 (PST) From: Michelle Johannes Subject: [WIEN]: qtl-b questions ==== Michelle Johannes submitted the following contribution: ==== Dear users, I have a question about the qtl-b values in some of my calculations. I noticed in checking through the *.scf* files that I had a small (approx. 2.1) qtl-b value. So I carefully checked to see where the bands were, adjusted the linearization energies and obtained a nicely converged calculation with no qtl-b value reported. However, when I run lapw2 -qtl -up/dn, they return - and much bigger (around 12.0). Is this something to worry about? Are the orbitally resolved DOS values reliable given this value? And one more question if anyone yet has patience: At what qtl-b value should I begin to fiddle with my linearization energies? Can I ignore a small value (1.0 or so) since it will obviously not cause ghostbands? I realize much has been written about qtl-b values in this user's group as well as the manual and also in S. Cottenier's tutorial, so I apologize if I have missed the answers. Thank you for your input, Michelle ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 10:12:43 +0900 From: "Ichiro Nagano" Subject: [WIEN]: Large-scale DFT calculations? ==== "Ichiro Nagano" submitted the following contribution: ==== Dear WIEN2k users, I would like to try more large-scale crystals (100-300 atoms in a unit cell). If it is possible fast and cost effectively, could you give me an advice? Alternatively, should I use order-N method? Thanks for any help, Ichiro Nagano ******************************************************************** Advanced Technology Research Center, Mitsubishi Heavy Industries, Ltd. 8-1, Sachiura, 1-Chome, Kanazawa-ku, Yokohama, 236-8515, Japan Ichiro Nagano E-mail: TEL: + 81 (45) 771-1222 FAX: + 81 (45) 771-3879 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 12:40:48 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question about parallel calculation ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I have finished a SCF parallel calculation. Then, I would like to analyse the optical properties. However, whenn I start calculate the x lapw2 -c. Error message likes executing: x lapw2 -c start: end of file apparent state: unit 10 named /tmp/wien97_tmp/opticsp6412A.vector last format: list io lately reading sequential unformatted external IO Abort (core dumped) 0.060u 0.110s 0:01.61 10.5% 0+0k 0+0io 161pf+0w RETURN key to continue ... What should I do then? Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 12:30:49 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: Re: [WIEN]: Question about parallel calculation ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== > I have finished a SCF parallel calculation. Then, I would like to analyse > the optical properties. However, whenn I start calculate the x lapw2 -c. > Error message likes You'd better use 'x lapw2 -c -p' because of SCF with parallel caculation. Please try it. - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 13:35:54 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: Question about parallel calculation ==== Ma Chi Chiu submitted the following contribution: ==== Dear Prof. Zhang, Thank you for your reply. Actually, I have also tried "x lapw2 -c -p", too. The error message likes: executing: x lapw2 -c -p running in single mode start: end of file apparent state: unit 10 named /tmp/wien97_tmp/opticsp6412A.vector last format: list io lately reading sequential unformatted external IO Abort (core dumped) 0.050u 0.170s 0:01.71 12.8% 0+0k 0+0io 501pf+0w RETURN key to continue ... How could I fix the problem? Thank you very much Martin On Tue, 26 Nov 2002 yshzhang@theory.issp.ac.cn wrote: > ==== > yshzhang@theory.issp.ac.cn > submitted the following contribution: > ==== > > > > I have finished a SCF parallel calculation. Then, I would like to analyse > > the optical properties. However, whenn I start calculate the x lapw2 -c. > > Error message likes > > You'd better use 'x lapw2 -c -p' because of SCF with parallel caculation. > Please try it. > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 08:54:13 +0100 From: Georg Madsen Subject: Re: [WIEN]: qtl-b questions ==== Georg Madsen submitted the following contribution: ==== > I have a question about the qtl-b values in some of my > calculations. I noticed in checking through the *.scf* files that I had a > small (approx. 2.1) qtl-b value. So I carefully checked to see where the > bands were, adjusted the linearization energies and obtained a nicely > converged calculation with no qtl-b value reported. However, when I run > lapw2 -qtl -up/dn, they return - and much bigger (around 12.0). Is this > something to worry about? Are the orbitally resolved DOS values reliable > given this value? doing qtl's lapw2 in effect sets the Fermi enrgy to infinite, this means that the linearization might be strained for bands high above the Fermilevel. It might mean that your states far above the Fermi level aren't optimal. But I don't think 12 is a big problem. The problem could be solved by allowing several LO's for the same l. Setting then far above Ef wouldn't affect the SCF cycle, but might give better optics/non-occupied bands. This isn't implemented yet. > And one more question if anyone yet has > patience: At what qtl-b value should I begin to fiddle with my > linearization energies? Can I ignore a small value (1.0 or so) since it > will obviously not cause ghostbands? I think WIEN97 only warned you for qtl-b's above 40. > I realize much has been written about qtl-b values in this user's > group as well as the manual and also in S. Cottenier's tutorial, so I > apologize if I have missed the answers. > > Thank you for your input, > Michelle > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - ---------------------------- Georg Madsen Dept. of Inorganic Chemistry University of Aarhus DK-8000 Århus C Denmark - ---------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 09:02:22 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Large-scale DFT calculations? ==== Peter Blaha submitted the following contribution: ==== > I would like to try more large-scale crystals (100-300 atoms in a unit > cell). > If it is possible fast and cost effectively, could you give me an advice? > > Alternatively, should I use order-N method? Such decisions depend not only on the number of atoms, but their type and what's the "goal" of the calculations. 300 atoms of Si or C-H-N-O-atoms or similar, high accuracy not needed: I would go for e.g. SIESTA (order N-method). Be prepared that the actual calculations migth be very fast (maybe a factor of 100 ? compared to WIEN2k), but that you need long testing about the bet basis set, testing of the achievable reliability,... and that for some systems reasonable accuracy cannot be reached at all. 300 atoms including some transition metals or even rare earth or 5f atoms: Get yourself the biggest and fastest parallel computer available ...... Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 09:06:57 +0100 From: Georg Madsen Subject: Re: [WIEN]: Large-scale DFT calculations? ==== Georg Madsen submitted the following contribution: ==== depends on what is "cost effective" We geometry optimized a system with 120 Ba and Ge atoms on a PC. This was very fast because it was a favorable case of APWs (high symmetry/large spheres). I'm doing an organic molecule with a 128 atoms in the unit cell at the moment. This has no symmetry and very small spheres and is thus a large calculation. But as we are interested in properties near the core, where APW are very good, it's worth it. It depends on the type of system and the properties you're interested in. If you want to geometry optimize 300 atoms you can download several pseudo potential codes for free. If you do more than 100 nonequivalent atoms you'll need to modify the code as the struct file format only supports 99. This will be improved in a future version. Georg Quoting Ichiro Nagano : > ==== > "Ichiro Nagano" > submitted the following contribution: > ==== > > Dear WIEN2k users, > > I would like to try more large-scale crystals (100-300 atoms in a unit > cell). > If it is possible fast and cost effectively, could you give me an advice? > > Alternatively, should I use order-N method? > > Thanks for any help, > > Ichiro Nagano > > ******************************************************************** > Advanced Technology Research Center, Mitsubishi Heavy Industries, Ltd. > 8-1, Sachiura, 1-Chome, Kanazawa-ku, Yokohama, 236-8515, Japan > Ichiro Nagano > E-mail: > TEL: + 81 (45) 771-1222 > FAX: + 81 (45) 771-3879 > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - ---------------------------- Georg Madsen Dept. of Inorganic Chemistry University of Aarhus DK-8000 Århus C Denmark - ---------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 16:17:48 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: Question about parallel calculation for optic ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I have finished the SCF calculation with parallel mode. Then, I tried to calculate the Optic. Then, I run "x lapw2 -p" as "x lapw2 " will generate error as can't find .vector file. Then, I try to run "x optic" but it get error as can't find .vector again. How can I solve the problem? Is it possible to run optic in parallel mode (manual claims possible but I got "permission denied when I tried "x optic -r")? Actually, I am using WIEN97 with graphic interface. Thank you very much Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 11:10:59 -0300 (ARST) From: Ruben Weht Subject: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Ruben Weht submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --1621662274-1305773784-1038319859=:2560 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Dear Wien's users, We have a project pointing to perform electronic structure calculations of several Ce-systems. As they need the application of both LDA+U formalism and SO coupling in the last weeks we have tried to gain some experience doing quite simple examples but have found really very puzzling results. We will appreciate it a lot if someone in the group could help us. As a first test we started with Ce-fcc, trying to reproduce a previous calculation done by Alexander Shick, Warren Pickett and Sasha Lichtenstein (condmat 0001255). There they found several metastable states with different occupation matrix (n_mm´) using another LAPW code. All of these states consist in one 4f electron located at about 2.5eV bellow the Fermi energy, as expected for the Ce-fcc Gamma phase. For the ground state the spin magnetic moment was 1.18 and the orbital magnetic moment -1.87 (bohr magnetons), of course mainly of 4f character. Our procedure to reproduce those findings was more or less the following (always using the last version of Wien2k): - - We first obtained the LDA self-consistent solution. Things went as usual giving a spin magnetic moment = 0.7 - - Then we lowered the symmetry to allow SO coupling (for this end we used INITSO but also checked by hand that the symmetries were OK) Running LDA+U (SIC option) gives an almost correct result, with magnetic moment of 1.17 and the f-peak located very near to the Shick´s result. - - Then we turned on the SO coupling but surprisingly the magnetic moment went down to almost zero after several iterations (it converges very slowly). The 4f states split giving an equal occupation for spin up and down (but always located at about 2eV bellow EF). We think this is a non-physical result at all. We have already tried to invert the sequence, applying first the SO coupling and then LDA+U but the result was the same. We have also tried other variants as putting the SO coupling along different directions (changing the corresponding symmetries) or doing different structures to see if the problem was related with the symmetry. For instance, we have tried with a rhombohedral structure but again the result was the same. To see if our ignorance about SO and LDA+U was so big, we have proved with Gd and things were fine in this case. Included, we have tried with Gd in a fictitious FCC structure, similar to Ce-FCC, but as expected the result was similar to the standard HCP case. We don't know if we are doing some very stupid mistake and what kind of error can produce this type of problems. We have attached in a tarfile inputs we have used (struct, in1, in2c, indmc, inorb and inso) in case someone wants to check them. Really we will thank a lot any help the network could give us. Our best regards, Veronica and Ruben *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* - --1621662274-1305773784-1038319859=:2560 Content-Type: APPLICATION/octet-stream; name=data Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=data Q2UuaW4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADAxMDA2NDQAMDAwMDc2NAAwMDAwMTQ0ADAwMDAwMDAwNjQ1 ADA3NTcwNjc3NDY3ADAxMTMxNgAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJ1d2Vo dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXNlcnMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABXRkZJTCAgICAgICAgKFdGUFJJLCBTVVBXRikK ICA3LjAwICAgICAgIDEwICAgIDQgKFItTVQqSy1NQVg7IE1BWCBMIElOIFdG LCBWLU5NVAogIDAuMzAgICAgNiAgMCAgICAgIChHTE9CQUwgRS1QQVJBTUVU RVIgV0lUSCBuIE9USEVSIENIT0lDRVMsIGdsb2JhbCBBUFcvTEFQVykgCiAw ICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEgCiAwICAgLTIuNzEgICAgICAw LjAwNSBTVE9QIDEgCiAxICAgLTEuMzcgICAgICAwLjAxMCBDT05UIDEgCiAx ICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEgCiAzICAgIDAuMzAgICAgICAw LjAxMCBDT05UIDEgCiAyICAgIDAuMzAgICAgICAwLjAxMCBDT05UIDEgCkst VkVDVE9SUyBGUk9NIFVOSVQ6NCAgIC03LjAgICAgICAgNC41ICAgICAgZW1p bi9lbWF4IHdpbmRvdyAgICAgICAgICAgICAgICAgICAKAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENlLmluMmMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw MTAwNjQ0ADAwMDA3NjQAMDAwMDE0NAAwMDAwMDAwMDU2NwAwNzU3MDY3NzQ3 NgAwMTE0NjUAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIgIABydXdlaHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHVzZXJzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAVE9UICAgICAgICAgICAgIChUT1QsRk9SLFFUTCxFRkcsRkVSTUkp ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgIC05LjAgICAg ICAxMi4wIDAuNTAgMC4wNSAgICAgICAgICAgICAgICBFTUlOLCBORSwgRVNF UEVSTUlOLCBFUwpURVRSQSAgICAwLjAwMCAgICAgICAgICAoR0FVU1MsUk9P VCxURU1QLFRFVFJBLEFMTCAgICAgIGV2YWwpICAgICAgICAKIDAgMCAyIDAg NCAwIDQgNCA2IDAgNiA0CiAxNC4gICAgICAgICAgR01BWCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApGSUxF ICAgICAgICBGSUxFL05PRklMRSAgd3JpdGUgcmVjcHJsaXN0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDZS5pbmRtYwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAw NzY0ADAwMDAxNDQAMDAwMDAwMDAzMjQAMDc1NzA2Nzc3NzMAMDExNzEzACAw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHVzdGFyICAAcnV3ZWh0AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB1c2VycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC05LiAg ICAgICAgICAgICAgICAgICAgICBFbWluIGN1dG9mZiBlbmVyZ3kKIDEgICAg ICAgICAgICAgICAgICAgICAgIG51bWJlciBvZiBhdG9tcyBmb3Igd2hpY2gg ZGVuc2l0eSBtYXRyaXggaXMgY2FsY3VsYXRlZAogMSAgMSAgMyAgICAgIGlu ZGV4IG9mIDFzdCBhdG9tLCBudW1iZXIgb2YgTCdzLCBMMQogMCAwICAgICAg ICAgICByLWluZGV4LCAobCxzKWluZGV4ICAKAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQ2UuaW5vcmIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDc2NAAwMDAwMTQ0 ADAwMDAwMDAwNDAwADA3NTcwNjc3NzY0ADAxMTcyNQAgMAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1 c3RhciAgAHJ1d2VodAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXNlcnMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgIDEgIDEgIDEgICAgICAg ICAgICAgICAgICAgICBubW9kLCBuYXRvcmIsIGlwcgpQUkFUVCAgMS4wICAg ICAgICAgICAgICAgICAgICBCUk9ZRC9QUkFUVCwgbWl4aW5nCiAgMSAxIDMg ICAgICAgICAgICAgICAgICAgICAgICAgIGlhdG9tIG5sb3JiLCBsb3JiCiAg MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5zaWMgMC4uQUZNLCAx Li5TSUMsIDIuLkhGTQogICAwLjUgICAgIDAuMDUxICAgICAgICAgICAgICAg ICAgICAgVSBKIChSeSkKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AENlLmluc28AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDA3NjQAMDAwMDE0NAAwMDAwMDAwMDUy MwAwNzU3MDY3Njc2MwAwMTE1NzAAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIgIABydXdl aHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzZXJzAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAV0ZGSUwKIDQgIDEgIDAgICAgICAgICAgICAg ICAgICAgICAgbGxtYXgsaXByLGtwb3QgCiAtMTAuMDAwMCAgIDEuNTAwMDAg ICAgICAgICAgIGVtaW4sZW1heCAob3V0cHV0IGVuZXJneSB3aW5kb3cpCiAg IDAuICAwLiAgMS4gICAgICAgICAgICAgICAgIGRpcmVjdGlvbiBvZiBtYWdu ZXRpemF0aW9uIChsYXR0aWNlIHZlY3RvcnMpCiAgMCAgICAgICAgICAgICAg ICAgICAgICAgICAgIG51bWJlciBvZiBhdG9tcyBmb3Igd2hpY2ggUkxPIGlz IGFkZGVkCiAgMCAwIDAgMCAwICAgICAgICAgICAgICAgICAgIG51bWJlciBv ZiBhdG9tcyBmb3Igd2hpY2ggU08gaXMgc3dpdGNoIG9mZjsgYXRvbXMKAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDZS5zdHJ1Y3QA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MDEwMDY0NAAwMDAwNzY0ADAwMDAxNDQAMDAwMDAwMDM0MDQAMDc1NzA2NzY3 NDYAMDEyMTQ2ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcnV3ZWh0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB1c2VycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAENlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcy1vIGNhbGMuIE18fCAgMC4wMCAgMC4wMCAgMS4wMCAgICAgICAKRiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg UkVMQSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgOS45MDAwMDAgIDkuOTAwMDAwICA5 LjkwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwIDkwLjAwMDAwMCAgICAgICAg ICAgICAgICAgICAKQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAw MDAgWj0wLjAwMDAwMDAwCiAgICAgICAgICBNVUxUPSAxICAgICAgICAgIElT UExJVD0gMgpDZSAgICAgICAgIE5QVD0gIDc4MSAgUjA9LjAwMDAxMDAwMCBS TVQ9ICAgMi44MDAwMCAgIFo6ICA1OC4wMDAwMCAgICAgICAgICAgICAgCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAxLjAwMDAwMDAg MC4wMDAwMDAwCiAgICAgICAgICAgICAgICAgICAgIDAuMDAwMDAwMCAwLjAw MDAwMDAgMS4wMDAwMDAwCiAgMTYgICAgICBOVU1CRVIgT0YgU1lNTUVUUlkg T1BFUkFUSU9OUwotMSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAK IDAgMC0xIDAuMDAwMDAwMAogICAgICAgMSAgIEEgICAzIHNvLiBvcGVyLiAg dHlwZSAgb3JpZy4gaW5kZXgKIDAgMSAwIDAuMDAwMDAwMAotMSAwIDAgMC4w MDAwMDAwCiAwIDAtMSAwLjAwMDAwMDAKICAgICAgIDIgICBBICAgNQogMC0x IDAgMC4wMDAwMDAwCiAxIDAgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAw MAogICAgICAgMyAgIEEgIDE0CiAxIDAgMCAwLjAwMDAwMDAKIDAgMSAwIDAu MDAwMDAwMAogMCAwLTEgMC4wMDAwMDAwCiAgICAgICA0ICAgQSAgMTcKLTEg MCAwIDAuMDAwMDAwMAogMC0xIDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAw MDAKICAgICAgIDUgICBBICAzMgogMCAxIDAgMC4wMDAwMDAwCi0xIDAgMCAw LjAwMDAwMDAKIDAgMCAxIDAuMDAwMDAwMAogICAgICAgNiAgIEEgIDM1CiAw LTEgMCAwLjAwMDAwMDAKIDEgMCAwIDAuMDAwMDAwMAogMCAwIDEgMC4wMDAw MDAwCiAgICAgICA3ICAgQSAgNDQKIDEgMCAwIDAuMDAwMDAwMAogMCAxIDAg MC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKICAgICAgIDggICBBICA0Ngog MSAwIDAgMC4wMDAwMDAwCiAwLTEgMCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAw MDAwMAogICAgICAgOSAgIEIgICAxCiAwIDEgMCAwLjAwMDAwMDAKIDEgMCAw IDAuMDAwMDAwMAogMCAwLTEgMC4wMDAwMDAwCiAgICAgIDEwICAgQiAgIDcK IDAtMSAwIDAuMDAwMDAwMAotMSAwIDAgMC4wMDAwMDAwCiAwIDAtMSAwLjAw MDAwMDAKICAgICAgMTEgICBCICAxMwotMSAwIDAgMC4wMDAwMDAwCiAwIDEg MCAwLjAwMDAwMDAKIDAgMC0xIDAuMDAwMDAwMAogICAgICAxMiAgIEIgIDE4 CiAxIDAgMCAwLjAwMDAwMDAKIDAtMSAwIDAuMDAwMDAwMAogMCAwIDEgMC4w MDAwMDAwCiAgICAgIDEzICAgQiAgMzEKIDAgMSAwIDAuMDAwMDAwMAogMSAw IDAgMC4wMDAwMDAwCiAwIDAgMSAwLjAwMDAwMDAKICAgICAgMTQgICBCICAz NgogMC0xIDAgMC4wMDAwMDAwCi0xIDAgMCAwLjAwMDAwMDAKIDAgMCAxIDAu MDAwMDAwMAogICAgICAxNSAgIEIgIDQyCi0xIDAgMCAwLjAwMDAwMDAKIDAg MSAwIDAuMDAwMDAwMAogMCAwIDEgMC4wMDAwMDAwCiAgICAgIDE2ICAgQiAg NDgKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== - --1621662274-1305773784-1038319859=:2560-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 09:36:35 -0500 From: Xing Gao Subject: [WIEN]: About LSTART ==== Xing Gao submitted the following contribution: ==== Dear wien2k user, When I run the lstart there is an error called: "lib-4190 : UNRECOVERABLE library error Encountered during a list-directed READ from unit 100 Fortran unit 100 is connected to a sequential formatted text file (standard input). IOT Trap" I don't know it is something wrong in the Library of our system, or the definition of "unit 100" in the code is not suitable, or something else. If you know please give me some suggestion. Thank you very much. Xing ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 16:34:18 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Peter Blaha submitted the following contribution: ==== > We have a project pointing to perform electronic structure calculations of > several Ce-systems. > As they need the application of both LDA+U formalism and SO coupling in > the last weeks we have tried to gain some experience doing quite simple > examples but have found really very puzzling results. Please make the following test: Edit your runsp_lapw script: .... lapw1: ... #if ( "$so" == "-so" ) then # total_exec lapw1 $it0 -up $para $nohns #else total_exec lapw1 $it0 -up $para $nohns $orb #endif ... #if ( "$so" == "-so" ) then # total_exec lapw1 $it0 -dn $para $nohns #else total_exec lapw1 $it0 -dn $para $nohns $orb #endif ... lapwso: if ( -e $file.scfso ) rm $file.scfso if ( "$so" == "-so" ) then testinput $file.inso error_input # total_exec lapwso -up $orb $para total_exec lapwso -up $para Explanation: Recently WIEN2k was updated such that it adds LDA+U in lapw1 when SO is NOT included, but adds LDA+U in lapwso when SO is switched on. This has the advantage of a) saving time b) including crossterms between up/dn By the above changes you go back to the "non-SO" scheme, i.e. adding the LDA+U potential in lapw1 and SO in lapwso and I would like to test this option. Normally, practically the same results should come out. If not, then there must be a problem somewhere in the code. Please let me know the results of your tests. If the problems persist, I'll have a look on them. Regards > > We will appreciate it a lot if someone in the group could help us. > > As a first test we started with Ce-fcc, trying to reproduce a previous > calculation done by Alexander Shick, Warren Pickett and Sasha Lichtenstein > (condmat 0001255). > There they found several metastable states with different occupation > matrix (n_mm´) using another LAPW code. All of these states consist in one > 4f electron located at about 2.5eV bellow the Fermi energy, as expected for > the Ce-fcc Gamma phase. > For the ground state the spin magnetic moment was 1.18 and the orbital > magnetic moment -1.87 (bohr magnetons), of course mainly of 4f character. > > Our procedure to reproduce those findings was more or less the following > (always using the last version of Wien2k): > > - We first obtained the LDA self-consistent solution. > Things went as usual giving a spin magnetic moment = 0.7 > > - Then we lowered the symmetry to allow SO coupling > (for this end we used INITSO but also checked by hand that the > symmetries were OK) > > Running LDA+U (SIC option) gives an almost correct result, with magnetic > moment of 1.17 and the f-peak located very near to the Shick´s result. > > - Then we turned on the SO coupling but surprisingly the magnetic moment > went down to almost zero after several iterations (it converges very slowly). > The 4f states split giving an equal occupation for spin up and down (but > always located at about 2eV bellow EF). > > We think this is a non-physical result at all. > > We have already tried to invert the sequence, applying first the SO > coupling and then LDA+U but the result was the same. > > We have also tried other variants as putting the SO coupling along > different directions (changing the corresponding symmetries) or doing > different structures to see if the problem was related with the symmetry. > For instance, we have tried with a rhombohedral structure but again the > result was the same. > > To see if our ignorance about SO and LDA+U was so big, we have proved with > Gd and things were fine in this case. Included, we have tried with Gd in a > fictitious FCC structure, similar to Ce-FCC, but as expected the result > was similar to the standard HCP case. > > We don't know if we are doing some very stupid mistake and what kind of > error can produce this type of problems. > > We have attached in a tarfile inputs we have used (struct, in1, in2c, > indmc, inorb and inso) in case someone wants to check them. > > Really we will thank a lot any help the network could give us. > > Our best regards, > > Veronica and Ruben > > > *====================================================================* > | Ruben Weht | ruweht@cnea.gov.ar | > | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | > | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | > | 1650 - San Martin - ARGENTINA | | > *====================================================================* > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 08:43:11 -0800 (PST) From: Claudio Lee Subject: [WIEN]: runsp_c_lapw and runsp_lapw ==== Claudio Lee submitted the following contribution: ==== Dear all, Is there anyone out there know the reason why I use "runsp_c_lapw -so -orb " to run for my calculation then it works, if however, with the same that calculation, using "runsp_lapw -so -orb " then it has trouble after first iteration. For spin-polarized calculation + SO + (LDA+U), using "runsp_lapw -so -orb " I got the error file like this: === hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END STOP lapwdm END STOP CORE END STOP CORE END STOP MIXER END hup: Command not found. STOP LAPW0 END STOP orbital potential calculation END STOP orbital potential calculation END if: Badly formed number. <=========== what is this? === Since I want to obtain magnetic moment in my calculation so I've got to choose this "runsp_lapw - -so -orb". So if you know the answer about this please help me. Sincerely, Claudio __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 13:48:00 -0300 (ARST) From: Ruben Weht Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Ruben Weht submitted the following contribution: ==== Dear Peter, Thanks a lot for your quick reply. Things worked perfectly with the new script. After our previous LDA+U calculations, as before, we added SO coupling but now it converged in just five new iterations giving the correct result. Do you think there is any problem with the code? Well, thanks a lot again and with our best regards, Veronica and Ruben On Tue, 26 Nov 2002, Peter Blaha wrote: > ==== > Peter Blaha > submitted the following contribution: > ==== > > > We have a project pointing to perform electronic structure calculations of > > several Ce-systems. > > As they need the application of both LDA+U formalism and SO coupling in > > the last weeks we have tried to gain some experience doing quite simple > > examples but have found really very puzzling results. > > Please make the following test: > > Edit your runsp_lapw script: > > .... > lapw1: > ... > #if ( "$so" == "-so" ) then > # total_exec lapw1 $it0 -up $para $nohns > #else > total_exec lapw1 $it0 -up $para $nohns $orb > #endif > ... > #if ( "$so" == "-so" ) then > # total_exec lapw1 $it0 -dn $para $nohns > #else > total_exec lapw1 $it0 -dn $para $nohns $orb > #endif > ... > lapwso: > if ( -e $file.scfso ) rm $file.scfso > if ( "$so" == "-so" ) then > testinput $file.inso error_input > # total_exec lapwso -up $orb $para > total_exec lapwso -up $para > > Explanation: Recently WIEN2k was updated such that it adds LDA+U in lapw1 > when SO is NOT included, but adds LDA+U in lapwso when SO is switched on. > This has the advantage of a) saving time b) including crossterms between up/dn > > By the above changes you go back to the "non-SO" scheme, i.e. > adding the LDA+U potential in lapw1 and SO in lapwso and I would like to > test this option. Normally, practically the same results should come out. > If not, then there must be a problem somewhere in the code. > > Please let me know the results of your tests. If the problems persist, I'll > have a look on them. > > Regards > > > > > We will appreciate it a lot if someone in the group could help us. > > > > As a first test we started with Ce-fcc, trying to reproduce a previous > > calculation done by Alexander Shick, Warren Pickett and Sasha Lichtenstein > > (condmat 0001255). > > There they found several metastable states with different occupation > > matrix (n_mm´) using another LAPW code. All of these states consist in one > > 4f electron located at about 2.5eV bellow the Fermi energy, as expected for > > the Ce-fcc Gamma phase. > > For the ground state the spin magnetic moment was 1.18 and the orbital > > magnetic moment -1.87 (bohr magnetons), of course mainly of 4f character. > > > > Our procedure to reproduce those findings was more or less the following > > (always using the last version of Wien2k): > > > > - We first obtained the LDA self-consistent solution. > > Things went as usual giving a spin magnetic moment = 0.7 > > > > - Then we lowered the symmetry to allow SO coupling > > (for this end we used INITSO but also checked by hand that the > > symmetries were OK) > > > > Running LDA+U (SIC option) gives an almost correct result, with magnetic > > moment of 1.17 and the f-peak located very near to the Shick´s result. > > > > - Then we turned on the SO coupling but surprisingly the magnetic moment > > went down to almost zero after several iterations (it converges very slowly). > > The 4f states split giving an equal occupation for spin up and down (but > > always located at about 2eV bellow EF). > > > > We think this is a non-physical result at all. > > > > We have already tried to invert the sequence, applying first the SO > > coupling and then LDA+U but the result was the same. > > > > We have also tried other variants as putting the SO coupling along > > different directions (changing the corresponding symmetries) or doing > > different structures to see if the problem was related with the symmetry. > > For instance, we have tried with a rhombohedral structure but again the > > result was the same. > > > > To see if our ignorance about SO and LDA+U was so big, we have proved with > > Gd and things were fine in this case. Included, we have tried with Gd in a > > fictitious FCC structure, similar to Ce-FCC, but as expected the result > > was similar to the standard HCP case. > > > > We don't know if we are doing some very stupid mistake and what kind of > > error can produce this type of problems. > > > > We have attached in a tarfile inputs we have used (struct, in1, in2c, > > indmc, inorb and inso) in case someone wants to check them. > > > > Really we will thank a lot any help the network could give us. > > > > Our best regards, > > > > Veronica and Ruben > > > > > > *====================================================================* > > | Ruben Weht | ruweht@cnea.gov.ar | > > | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | > > | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | > > | 1650 - San Martin - ARGENTINA | | > > *====================================================================* > > > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 26 Nov 2002 09:30:18 -0800 (PST) From: Michelle Johannes Subject: Re: [WIEN]: qtl-b questions ==== Michelle Johannes submitted the following contribution: ==== Thank you, Georg, your answer was very helpful. Michelle On Tue, 26 Nov 2002, Georg Madsen wrote: > ==== > Georg Madsen > submitted the following contribution: > ==== > > > I have a question about the qtl-b values in some of my > > calculations. I noticed in checking through the *.scf* files that I had a > > small (approx. 2.1) qtl-b value. So I carefully checked to see where the > > bands were, adjusted the linearization energies and obtained a nicely > > converged calculation with no qtl-b value reported. However, when I run > > lapw2 -qtl -up/dn, they return - and much bigger (around 12.0). Is this > > something to worry about? Are the orbitally resolved DOS values reliable > > given this value? > doing qtl's lapw2 in effect sets the Fermi enrgy to infinite, this means that > the linearization might be strained for bands high above the Fermilevel. It > might mean that your states far above the Fermi level aren't optimal. But I > don't think 12 is a big problem. The problem could be solved by allowing several > LO's for the same l. Setting then far above Ef wouldn't affect the SCF cycle, > but might give better optics/non-occupied bands. This isn't implemented yet. > > > And one more question if anyone yet has > > patience: At what qtl-b value should I begin to fiddle with my > > linearization energies? Can I ignore a small value (1.0 or so) since it > > will obviously not cause ghostbands? > I think WIEN97 only warned you for qtl-b's above 40. > > > I realize much has been written about qtl-b values in this user's > > group as well as the manual and also in S. Cottenier's tutorial, so I > > apologize if I have missed the answers. > > > > Thank you for your input, > > Michelle > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > > ---------------------------- > Georg Madsen > Dept. of Inorganic Chemistry > University of Aarhus > DK-8000 Århus C > Denmark > ---------------------------- > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 27 Nov 2002 14:56:38 -0600 From: "Yang, Jinbo (UMR-Student)" Subject: RE: [WIEN]: ==== "Yang, Jinbo (UMR-Student)" submitted the following contribution: ==== Dear Wien2k Users: I see there is an item "Nocubic" in the StructGen. Does it represent the symmetry of the atom at that position or something related to MT sphere? Should I neglect it or take a serious consideration about it? I found I got same result whether I select it or not. Thank you so much Jinbo Yang Materials Research Center University Of Missouri-Rolla Rolla, MO 65409 Phone:+01-573-341-6165 Fax: 573-341-2071 E-mail:jinbo@umr.edu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 28 Nov 2002 00:34:40 -0600 (CST) From: Bing Zhou Subject: [WIEN]: problems with lapw1 and lapw2 ==== Bing Zhou submitted the following contribution: ==== Dear All: I can run "x lapw0" and "x mixer" without problem, however, after I run "x lapw1" or "x lapw2", I met the following problem: /home/wt/wien97/lapw1: Command not found or /home/wt/wien97/lapw2: Command not found What are the possible reasons for that? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 28 Nov 2002 08:35:39 +0100 From: Torsten Andersen Subject: [WIEN]: [Fwd: MKL 6.0 beta!] - BLAS, FFT, etc... from Intel for free ==== Torsten Andersen submitted the following contribution: ==== Dear All, I just thought you should know, too. Best regards, Torsten Andersen. - -------- Original Message -------- Subject: MKL 6.0 beta! Date: Tue, 26 Nov 2002 21:55:05 +0100 From: Mattias Klintenberg Organization: LBNL To: fysik4@fysik.uu.se Greetings, Intel is now offering their Math Kernel Library for free!!! This library is highly optimized so now we will be able to use the true floating point power of PIII and PIV processors. The library includes BLAS, LAPACK, DFT's , 2-D and 3-D FFT's, VML, VSL, etc. http://www.intel.com/software/products/perflib/ (see MKL 6.0 beta) Regards, /mattias - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 28 Nov 2002 03:37:01 -0800 (PST) From: mehrdad dadsetani Subject: [WIEN]: Joint of HgI2 ==== mehrdad dadsetani submitted the following contribution: ==== I am user wien97 i am study to optic properties of HgI2.i run optic succecfuly and generate *.outmat and *.outputop. but when i run joint, i have message that "invalid integer:read unexpected character apparent state: unit 5 named HgI2.injoint last format: list io lately reading sequential formatted external I0 Abort(core dumped)" HgI2.inop and HgI2.injoint are 150 1 number of k-points, first k-point - -5.0 2.0 Emin, Emax for matrix elements 2 number of choices (columns in *outmat) 1 Re xx 3 Re zz - ---------------------------------------------- 1 40 : LOWER AND UPPER BANDINDEX -5.0000 0.0100 2.0000 : EMIN DE EMAX FOR ENERGYGRID IN ryd ryd : output units eV / ryd / cm-1 4 : SWITCH 2 : NUMBER OF COLUMNS 0.1 0.1 0.3 : BROADENING (FOR DRUDE MODEL - switch 6,7 - ONLY) - ------------------------------------------------------ HgI2.outputjoint and HgI2 joint are empyty Thanks, Mehrdad dadsetani Department of Physics lorestan University __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #45 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #46 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, December 5 2002 Volume 2002 : Number 046 ---------------------------------------------------------------------- Date: Thu, 28 Nov 2002 14:33:49 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: ==== "Kevin Jorissen" submitted the following contribution: ==== WIEN sets this automatically. However, if you start editing the struct-file manually (eg to break symmetry), then you SHOULD also consider cubic/noncubic case (change atom number to negative values). If not, some program (lapw0 or lapw2, I don't remember) fails. Maybe it works the other way round (negative numbers though you have a cubic system), but why would you want to do that? kind regards, Kevin Jorissen kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Yang, Jinbo (UMR-Student)" To: Sent: Wednesday, November 27, 2002 9:56 PM Subject: RE: [WIEN]: > ==== > "Yang, Jinbo (UMR-Student)" > submitted the following contribution: > ==== > > Dear Wien2k Users: > > I see there is an item "Nocubic" in the StructGen. Does it represent the symmetry of the atom at that position or something related to MT sphere? Should I neglect it or take a serious consideration about it? I found I got same result whether I select it or not. > > > Thank you so much > > > Jinbo Yang > Materials Research Center > University Of Missouri-Rolla > Rolla, MO 65409 > Phone:+01-573-341-6165 > Fax: 573-341-2071 > E-mail:jinbo@umr.edu > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 28 Nov 2002 15:21:33 -0300 (ARST) From: Ruben Weht Subject: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Ruben Weht submitted the following contribution: ==== Dear Peter and members of the Wien club, We think we were too optimistic in our last message regarding LDA+U+SO calculations. We did the changes you suggested and as we told you in our reply it seemed to work properly: the spin magnetic moment had the correct value and the density of states looked fine. However, after a message by Michelle and other tests we did, we realized that the solution was not completely correct: this time the orbital moment had gone to zero. After some thinking, we realized that with the changes you suggested we should have run the complex version of lapw1 (because you are adding the orbital potential directly to it). After doing this new test and (with a quite painful convergence process) we have obtained the same result than before: the spin magnetic moment goes to zero again. We suspect now than the original runsp_lapw is OK but there are some other problem when both LDA+U and SO coupling are used together. We really don't understand what kind of error it could be. We apologize for the confusion we made. Is there any member of the list who has succeeded in running LDA+U+SO for other 4f systems? (we have already tried with Gd and it was fine, however, this system is quite different from Ce because it has a half filled 4f shell and in fact LDA itself gives a non so bad result). Thanks a lot for any help, Veronica and Ruben - -- *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 28 Nov 2002 15:30:41 -0300 (ARST) From: Ruben Weht Subject: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Ruben Weht submitted the following contribution: ==== Peter, Just in case it can help. We have also run a fictitious Cerium with HCP structure. We obtained a reasonable spin magnetic moment and density of states but zero orbital moment. Thanks again, Veronica and Ruben - -- *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 29 Nov 2002 08:54:16 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Peter Blaha submitted the following contribution: ==== > We think we were too optimistic in our last message regarding LDA+U+SO > calculations. > > We did the changes you suggested and as we told you in our reply it seemed > to work properly: the spin magnetic moment had the correct value and the > density of states looked fine. > > However, after a message by Michelle and other tests we did, we realized > that the solution was not completely correct: this time the orbital moment > had gone to zero. I've also done some Ce calculations by now, but I cannot verify your last message. However, I agree, the solution proposed in my last mail requires lapw1c. In my tests I have simply removed after orb: rm $file.vorbdu and than apply vorb in lapwso. Please do not forget, that one can obtain many different LDA+U solutions depending on the starting density (and density matrix). When starting with a density from lda + SO and adding LDA+U I get including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and very slow convergence) without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and quick) As usual I can also obtain other solutions, starting with SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 (since I started with a "negative" moment it remains negative) a density matrix with large m=+3 occupation: -1.18891 2.87868 So you see all three solutions without cross term give a spin moment of 1.2, while the orbital moment depends crucially on the starting dmat and was 0, 1 or 3 (and I'm sure I could also converge other orbital moments). However, the solution with +1.2 has by far the lowest total energy of those three tests and is thus the best solution (and is also the one which you get from my recommended procedure: runsp -so x lapwdm -so -up runsp -so -orb I'll test this further and discuss it with others, but my impression is that the cross-term in case.vorbdu is either not correct (or it's usage in lapwso is not ok) and at the moment one should remove it. After that LDA+U +SO gives expected results. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 29 Nov 2002 21:41:47 +0800 From: "whoming" Subject: [WIEN]: "Word too long" failure after lstart during init_lapw ==== "whoming" submitted the following contribution: ==== Dear all, Today I have met a proble during init_lapw, just after lstart, it looks like this: > lstart (21:36:49) SELECT XCPOT: recommended: 13: GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 14: GGA (Perdew-Wang 91) 5 SELECT ENERGY to separate core and valence states: recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) - -6.0 STOP LSTART ENDS STOP 6.7u 0.0s 0:11 61% 0+0k 0+0io 0pf+0w Word too long What's the problem?Thank you very much! Yours, whoming ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 1 Dec 2002 11:45:16 +0800 From: "whoming" Subject: Re: [WIEN]: "Word too long" failure after lstart during init_lapw ==== "whoming" submitted the following contribution: ==== Dear all, I have found the reason causing this problem. Just do things following "grep WARNING $file.outputst"! - ----- Original Message ----- From: "whoming" To: Sent: Friday, November 29, 2002 9:41 PM Subject: [WIEN]: "Word too long" failure after lstart during init_lapw > ==== > "whoming" > submitted the following contribution: > ==== > > Dear all, > Today I have met a proble during init_lapw, > just after lstart, it looks like this: > > > lstart (21:36:49) SELECT XCPOT: > recommended: 13: GGA (Perdew-Burke-Ernzerhof 96) > 5: LSDA > 14: GGA (Perdew-Wang 91) > 5 > SELECT ENERGY to separate core and valence states: > recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) > -6.0 > STOP LSTART ENDS > STOP > 6.7u 0.0s 0:11 61% 0+0k 0+0io 0pf+0w > Word too long > > > What's the problem?Thank you very much! > Yours, > whoming > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 01 Dec 2002 12:57:51 +0000 From: "Yue Hai" Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== "Yue Hai" submitted the following contribution: ==== Dear Ruben: I have also calculate the system include Ce. I have change runsp_lapw likes this: lapw1c:-------->not lapw1 ... #if ( "$so" == "-so" ) then # total_exec lapw1 $it0 -up $para $nohns #else total_exec lapw1 $it0 -up -c $para $nohns $orb #endif ... #if ( "$so" == "-so" ) then # total_exec lapw1 $it0 -dn $para $nohns #else total_exec lapw1 $it0 -dn -c $para $nohns $orb #endif ... lapwsoc:---------->not lapwso if ( -e $file.scfso ) rm $file.scfso if ( "$so" == "-so" ) then testinput $file.inso error_input # total_exec lapwso -up $orb $para total_exec lapwso -up -c $para-------->include parameter "-c" change in1 to inlc runsp+so runsp+so+U This means that you use complex version lapw1c, not lapw1.and orb is include in lapw1c, not in lapwso, and the result is good, so you can try it. The execute is: >From: Ruben Weht >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: WIEN >Subject: [WIEN]: Problems with LDA+U+SO in Cerium systems. >Date: Thu, 28 Nov 2002 15:21:33 -0300 (ARST) > >==== >Ruben Weht >submitted the following contribution: >==== > >Dear Peter and members of the Wien club, > >We think we were too optimistic in our last message regarding LDA+U+SO >calculations. > >We did the changes you suggested and as we told you in our reply it seemed >to work properly: the spin magnetic moment had the correct value and the >density of states looked fine. > >However, after a message by Michelle and other tests we did, we realized >that the solution was not completely correct: this time the orbital moment >had gone to zero. > >After some thinking, we realized that with the changes you suggested we >should have run the complex version of lapw1 (because you are adding the >orbital potential directly to it). > >After doing this new test and (with a quite painful convergence process) >we have obtained the same result than before: the spin magnetic moment >goes to zero again. > >We suspect now than the original runsp_lapw is OK but there are some other >problem when both LDA+U and SO coupling are used together. > >We really don't understand what kind of error it could be. > >We apologize for the confusion we made. > >Is there any member of the list who has succeeded in running LDA+U+SO for >other 4f systems? (we have already tried with Gd and it was fine, however, >this system is quite different from Ce because it has a half filled 4f >shell and in fact LDA itself gives a non so bad result). > >Thanks a lot for any help, > > Veronica and Ruben > >-- >*====================================================================* >| Ruben Weht | ruweht@cnea.gov.ar | >| Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | >| Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | >| 1650 - San Martin - ARGENTINA | | >*====================================================================* > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 1 Dec 2002 05:13:04 -0800 (PST) From: Hadi Arabi Subject: [WIEN]: total core charge ==== Hadi Arabi submitted the following contribution: ==== Dear wien user I work on Ice Cubic phase. I put Rmt=0.7 for H and Rmt=1.4 for O. After initialise we found the following data in case.outputst file for hydrogen. The total core Charge and total core charge inside sphere comes out zero. Does it makes sence? and what is the reason for it? H RHFS OCCUPANCY ENERGY(RYD) (R4) (R2) (R) (R-1) (R-3) 1S 0.900 -5.5343653E-01 2.8859959E+01 3.2701173E+00 1.5496451E+00 9.8868262E-01 1S 0.100 -2.9298928E-01 7.6763743E+01 5.1153976E+00 1.9089845E+00 8.3795725E-01 TOTAL CHARGE FOR SPIN 1: 0.9000000000000004 TOTAL CHARGE FOR SPIN 1 INSIDE SPHERE: 0.1484428774001257 TOTAL CHARGE FOR SPIN 2: 0.1000000000000000 TOTAL CHARGE FOR SPIN 2 INSIDE SPHERE: 1.2145117228393798E-002 TOTAL CHARGE in sigma FOR SPIN 1: 0.0000000000000000E+000 TOTAL CHARGE in sigma FOR SPIN 1INSIDE SPHERE: 0.0000000000000000E+000 TOTAL CHARGE in sigma FOR SPIN 2: 0.0000000000000000E+000 TOTAL CHARGE in sigma FOR SPIN 2INSIDE SPHERE: 0.0000000000000000E+000 TOTAL CORE-CHARGE: 0.0000000000000000E+000 TOTAL CORE-CHARGE INSIDE SPHERE: 0.0000000000000000E+000 TOTAL ENERGY (RYD): -0.966505 SUM OF EI:-5.2739181E-01 NUC:-1.9472202E+00 COUL:-7.5003037E-01 V-XC SPIN 1:-6.8721924E-01 E-XC SPIN 1:-5.4051577E-01 V-XC SPIN 2:-4.1960721E-02 E-XC SPIN 2:-2.9182614E-02 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 09:08:25 +0800 From: "whoming" Subject: [WIEN]: What's the matter? ==== "whoming" submitted the following contribution: ==== Dear all, After 8 cycles, it show such error message: in cycle 8 ETEST: .0018260000000000 CTEST: .0056579 hup - Command not found STOP LAPW0 END STOP STOP LAPW1 END STOP STOP LAPW2 END STOP STOP CORE END STOP STOP MIXER END STOP tkerror failed to handle background error. Original error: can't read "s_lattice": no such variable Error in tkerror: can't invoke "after" command: application has been destoyed Any comments on this? Thank you very much! yours, whoming - ----- Original Message ----- From: "Peter Blaha" To: "WIEN" Sent: Friday, November 29, 2002 3:54 PM Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > ==== > Peter Blaha > submitted the following contribution: > ==== > > > We think we were too optimistic in our last message regarding LDA+U+SO > > calculations. > > > > We did the changes you suggested and as we told you in our reply it seemed > > to work properly: the spin magnetic moment had the correct value and the > > density of states looked fine. > > > > However, after a message by Michelle and other tests we did, we realized > > that the solution was not completely correct: this time the orbital moment > > had gone to zero. > > I've also done some Ce calculations by now, but I cannot verify your last > message. However, I agree, the solution proposed in my last mail requires > lapw1c. > > In my tests I have simply removed after orb: > > rm $file.vorbdu > > and than apply vorb in lapwso. > > Please do not forget, that one can obtain many different LDA+U solutions > depending on the starting density (and density matrix). > > When starting with a density from lda + SO and adding LDA+U I get > > including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and > very slow convergence) > without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and quick) > > As usual I can also obtain other solutions, starting with > > SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 > (since I started with a "negative" moment it remains negative) > > a density matrix with large m=+3 occupation: -1.18891 2.87868 > > So you see all three solutions without cross term give a spin moment of 1.2, > while the orbital moment depends crucially on the starting dmat and was > 0, 1 or 3 (and I'm sure I could also converge other orbital moments). > > However, the solution with +1.2 has by far the lowest total energy of those > three tests and is thus the best solution (and is also the one which you > get from my recommended procedure: > > runsp -so > x lapwdm -so -up > runsp -so -orb > > I'll test this further and discuss it with others, but my impression is > that the cross-term in case.vorbdu is either not correct (or it's usage in > lapwso is not ok) and at the moment one should remove it. After that LDA+U > +SO gives expected results. > > Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 09:52:53 +0800 From: "whoming" Subject: [WIEN]: A question ==== "whoming" submitted the following contribution: ==== Dear all, In one of my calculation,there is one WARNING message in case.scf file: :WARN : WARNING: RKmax reduced due to NMATMAX How dose it influence the result? To avoid such, what should I do? Thank you very much! yours, whoming - ----- Original Message ----- From: "Peter Blaha" To: "WIEN" Sent: Friday, November 29, 2002 3:54 PM Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > ==== > Peter Blaha > submitted the following contribution: > ==== > > > We think we were too optimistic in our last message regarding LDA+U+SO > > calculations. > > > > We did the changes you suggested and as we told you in our reply it seemed > > to work properly: the spin magnetic moment had the correct value and the > > density of states looked fine. > > > > However, after a message by Michelle and other tests we did, we realized > > that the solution was not completely correct: this time the orbital moment > > had gone to zero. > > I've also done some Ce calculations by now, but I cannot verify your last > message. However, I agree, the solution proposed in my last mail requires > lapw1c. > > In my tests I have simply removed after orb: > > rm $file.vorbdu > > and than apply vorb in lapwso. > > Please do not forget, that one can obtain many different LDA+U solutions > depending on the starting density (and density matrix). > > When starting with a density from lda + SO and adding LDA+U I get > > including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and > very slow convergence) > without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and quick) > > As usual I can also obtain other solutions, starting with > > SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 > (since I started with a "negative" moment it remains negative) > > a density matrix with large m=+3 occupation: -1.18891 2.87868 > > So you see all three solutions without cross term give a spin moment of 1.2, > while the orbital moment depends crucially on the starting dmat and was > 0, 1 or 3 (and I'm sure I could also converge other orbital moments). > > However, the solution with +1.2 has by far the lowest total energy of those > three tests and is thus the best solution (and is also the one which you > get from my recommended procedure: > > runsp -so > x lapwdm -so -up > runsp -so -orb > > I'll test this further and discuss it with others, but my impression is > that the cross-term in case.vorbdu is either not correct (or it's usage in > lapwso is not ok) and at the moment one should remove it. After that LDA+U > +SO gives expected results. > > Regards > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 11:43:19 +0800 (HKT) From: Ma Chi Chiu Subject: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, I have some questions about parallel calculation. The parallel calculation always dead with the error message in lapw1.error like: ** Error in Parallel LAPW1 ** LAPW1 STOPPED at Sun Dec 1 22:15:17 HKT 2002 ** check ERROR FILES! Error in LAPW1 Error in LAPW1 Actually, the calculation has already finished 2 SCF cycyles. Then, why does the calculation stop not in the 1 cycle if I got some mistake in the parallelization? What should I do now? Also, I got error in doing optic parallelization. The error is "OPTIC CRASHED!" Why? Thank you Martin ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 01 Dec 2002 10:31:24 +0100 From: Peer Kruse Subject: Re: [WIEN]: A question ==== Peer Kruse submitted the following contribution: ==== Deaer Whoming, you have two possibilities, you can redeuce RKmax from the start and if this gives you not the desired accuracy you can increase NMATMAX to cover it. But then you have to recompile the WIEN code. yours Peer whoming wrote: >==== >"whoming" >submitted the following contribution: >==== > >Dear all, > In one of my calculation,there is one WARNING message in case.scf >file: >:WARN : WARNING: RKmax reduced due to NMATMAX > How dose it influence the result? To avoid such, what should I do? >Thank you very much! >yours, >whoming >----- Original Message ----- >From: "Peter Blaha" >To: "WIEN" >Sent: Friday, November 29, 2002 3:54 PM >Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > > > > >>==== >>Peter Blaha >>submitted the following contribution: >>==== >> >> >> >>>We think we were too optimistic in our last message regarding LDA+U+SO >>>calculations. >>> >>>We did the changes you suggested and as we told you in our reply it >>> >>> >seemed > > >>>to work properly: the spin magnetic moment had the correct value and the >>>density of states looked fine. >>> >>>However, after a message by Michelle and other tests we did, we realized >>>that the solution was not completely correct: this time the orbital >>> >>> >moment > > >>>had gone to zero. >>> >>> >>I've also done some Ce calculations by now, but I cannot verify your last >>message. However, I agree, the solution proposed in my last mail requires >>lapw1c. >> >>In my tests I have simply removed after orb: >> >>rm $file.vorbdu >> >>and than apply vorb in lapwso. >> >>Please do not forget, that one can obtain many different LDA+U solutions >>depending on the starting density (and density matrix). >> >>When starting with a density from lda + SO and adding LDA+U I get >> >>including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and >> very slow convergence) >>without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and >> >> >quick) > > >>As usual I can also obtain other solutions, starting with >> >>SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 >> (since I started with a "negative" moment it remains negative) >> >>a density matrix with large m=+3 occupation: -1.18891 2.87868 >> >>So you see all three solutions without cross term give a spin moment of >> >> >1.2, > > >>while the orbital moment depends crucially on the starting dmat and was >>0, 1 or 3 (and I'm sure I could also converge other orbital moments). >> >>However, the solution with +1.2 has by far the lowest total energy of >> >> >those > > >>three tests and is thus the best solution (and is also the one which you >>get from my recommended procedure: >> >>runsp -so >>x lapwdm -so -up >>runsp -so -orb >> >>I'll test this further and discuss it with others, but my impression is >>that the cross-term in case.vorbdu is either not correct (or it's usage in >>lapwso is not ok) and at the moment one should remove it. After that LDA+U >>+SO gives expected results. >> >>Regards >> 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@theochem.tuwien.ac.at WWW: >> >> >http://info.tuwien.ac.at/theochem/ > > >>-------------------------------------------------------------------------- >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> >> >> >> > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 08:49:20 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: total core charge ==== "Kevin Jorissen" submitted the following contribution: ==== the energy of your 1s-orbital is higher than the (default) energy (-6.0 Ry) to distinguish between core and valence states. So you don't have core states for H. The 1s-orbital is treated as a valence orbital. kind regards, Kevin Jorissen kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Hadi Arabi" To: Sent: Sunday, December 01, 2002 2:13 PM Subject: [WIEN]: total core charge > ==== > Hadi Arabi > submitted the following contribution: > ==== > > Dear wien user > I work on Ice Cubic phase. I put Rmt=0.7 for H and > Rmt=1.4 for O. After initialise we found the following > data in case.outputst file for hydrogen. > The total core Charge and total core charge inside > sphere comes out zero. Does it makes sence? and what > is the reason for it? > > > H > RHFS > > OCCUPANCY ENERGY(RYD) (R4) > (R2) (R) (R-1) > (R-3) > > 1S 0.900 -5.5343653E-01 2.8859959E+01 > 3.2701173E+00 1.5496451E+00 9.8868262E-01 > 1S 0.100 -2.9298928E-01 7.6763743E+01 > 5.1153976E+00 1.9089845E+00 8.3795725E-01 > > TOTAL CHARGE FOR SPIN 1: > 0.9000000000000004 > TOTAL CHARGE FOR SPIN 1 INSIDE SPHERE: > 0.1484428774001257 > TOTAL CHARGE FOR SPIN 2: > 0.1000000000000000 > TOTAL CHARGE FOR SPIN 2 INSIDE SPHERE: > 1.2145117228393798E-002 > TOTAL CHARGE in sigma FOR SPIN 1: > 0.0000000000000000E+000 > TOTAL CHARGE in sigma FOR SPIN 1INSIDE > SPHERE: > 0.0000000000000000E+000 > TOTAL CHARGE in sigma FOR SPIN 2: > 0.0000000000000000E+000 > TOTAL CHARGE in sigma FOR SPIN 2INSIDE > SPHERE: > 0.0000000000000000E+000 > TOTAL CORE-CHARGE: > 0.0000000000000000E+000 > TOTAL CORE-CHARGE INSIDE SPHERE: > 0.0000000000000000E+000 > > TOTAL ENERGY (RYD): -0.966505 > SUM OF EI:-5.2739181E-01 NUC:-1.9472202E+00 > COUL:-7.5003037E-01 > V-XC SPIN 1:-6.8721924E-01 E-XC SPIN > 1:-5.4051577E-01 > V-XC SPIN 2:-4.1960721E-02 E-XC SPIN > 2:-2.9182614E-02 > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 08:54:59 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: A question ==== "Kevin Jorissen" submitted the following contribution: ==== There is a compilation parameter called NMATMAX. This parameter limits the maximum matrix size allowed for lapw1 and lapw2. If you have a large system, then a certain value of rkmax may require such a large basis that the resulting matrix is larger than NMATMAX. In this case, rkmax is diminished until the matrixsize does not exceed nmatmax anymore. In your case.scf1 and case.output1 you can check the resulting rkmax. If you need larger rkmax, you have to configure wien (siteconfig, then dimension parameters, then make nmatmax larger and recompile lapw1 and lapw2). kind regards, Kevin Jorissen kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "whoming" To: Sent: Monday, December 02, 2002 2:52 AM Subject: [WIEN]: A question > ==== > "whoming" > submitted the following contribution: > ==== > > Dear all, > In one of my calculation,there is one WARNING message in case.scf > file: > :WARN : WARNING: RKmax reduced due to NMATMAX > How dose it influence the result? To avoid such, what should I do? > Thank you very much! > yours, > whoming > ----- Original Message ----- > From: "Peter Blaha" > To: "WIEN" > Sent: Friday, November 29, 2002 3:54 PM > Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > > > > ==== > > Peter Blaha > > submitted the following contribution: > > ==== > > > > > We think we were too optimistic in our last message regarding LDA+U+SO > > > calculations. > > > > > > We did the changes you suggested and as we told you in our reply it > seemed > > > to work properly: the spin magnetic moment had the correct value and the > > > density of states looked fine. > > > > > > However, after a message by Michelle and other tests we did, we realized > > > that the solution was not completely correct: this time the orbital > moment > > > had gone to zero. > > > > I've also done some Ce calculations by now, but I cannot verify your last > > message. However, I agree, the solution proposed in my last mail requires > > lapw1c. > > > > In my tests I have simply removed after orb: > > > > rm $file.vorbdu > > > > and than apply vorb in lapwso. > > > > Please do not forget, that one can obtain many different LDA+U solutions > > depending on the starting density (and density matrix). > > > > When starting with a density from lda + SO and adding LDA+U I get > > > > including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and > > very slow convergence) > > without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and > quick) > > > > As usual I can also obtain other solutions, starting with > > > > SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 > > (since I started with a "negative" moment it remains negative) > > > > a density matrix with large m=+3 occupation: -1.18891 2.87868 > > > > So you see all three solutions without cross term give a spin moment of > 1.2, > > while the orbital moment depends crucially on the starting dmat and was > > 0, 1 or 3 (and I'm sure I could also converge other orbital moments). > > > > However, the solution with +1.2 has by far the lowest total energy of > those > > three tests and is thus the best solution (and is also the one which you > > get from my recommended procedure: > > > > runsp -so > > x lapwdm -so -up > > runsp -so -orb > > > > I'll test this further and discuss it with others, but my impression is > > that the cross-term in case.vorbdu is either not correct (or it's usage in > > lapwso is not ok) and at the moment one should remove it. After that LDA+U > > +SO gives expected results. > > > > Regards > > 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@theochem.tuwien.ac.at WWW: > http://info.tuwien.ac.at/theochem/ > > -------------------------------------------------------------------------- > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 12:19:46 +0100 From: Stefaan Cottenier Subject: [WIEN]: case.scfdmup ==== Stefaan Cottenier submitted the following contribution: ==== Dear wien-users, I am puzzled by an unexpected factor 2 in the output of lapwdm. After running a converged scf-cycle with spin-polarization and spin-orbit coupling, I want to obtain the orbital moment of a Co-atom in my structure. Therefore, I first test the output of lapwdm with quantities that are known in the scf-file too. 1) Obtain the number of valence electrons inside Rmt : case.indmc = - -9. Emin cutoff energy 5 number of atoms for which density matrix is calculated 1 4 0 1 2 3 index of 1st atom, number of L's, L1 1 1 r-index, (l,s)index (the Co-atom is the first atom in case.struct) After running 'x lapwdm -c -so - -up', this is case.scfdmup : atom L upup updn dndn total :XOP01 0 1.16264 0.00000 1.14548 2.30812 :XOP01 1 3.11761 0.00000 3.11894 6.23655 :XOP01 2 4.46323 0.00000 1.53959 6.00282 :XOP01 3 0.00657 0.00000 0.00630 0.01286 The last column sums to 14.5603, which is almost identical to :CHA01up + :CHA01dn = 14.5639 in case.scf. No problems here. 2) Obtain the spin moment of Co : case.indmc = 1 2 for r-index, (l,s)index case.scfdmup = atom L upup updn dndn total :XOP01 0 0.58132 0.00000 -0.57274 0.00858 :XOP01 1 1.55880 0.00000 -1.55947 -0.00067 :XOP01 2 2.23161 0.00000 -0.76980 1.46182 :XOP01 3 0.00328 0.00000 -0.00315 0.00013 The upup and dndn columns are exactly ONE HALF of what is found at :QTL01 in case.scf. The sum of the last column (1.4699) too is about ONE HALF of :MMI01 (2.93994). QUESTION : For the total charge, lapwdm gives outputd that is directly comparable to case.scf. For the spin moment, one has to multiply this by 2. What about the other properties, that are not available in case.scf? I have the following values calculated by lapwdm : orbital Co-moment = 0.079 spin Co-hff = -2.5 T orbital Co-hff = 4.4 T Should they be multiplied by two or not? I did these tests (running the scf-cycle and lapwdm) with the release of May 27 and with the latest release. Both gave identical results. Thanks ! Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 13:56:16 +0100 (MET) From: Pavel Novak Subject: Re: [WIEN]: case.scfdmup ==== Pavel Novak submitted the following contribution: ==== Dear Stefaan, there may be some misunderstanding - the factor two is factor which makes from the electronic spin the spin magnetic moment in Bohr magnetons: m_S = gS, g=2.00 You can readily check the density matrix d: its trace is number of electrons, trace(d) up - trace(d) dn = m_S in Bohr magnetons, l_z = sum_m m.d_mm (sum over both up and down) orbital momentum is calculated automatically - you do not need to write the last line in .indmc. Best regards Pavel On Mon, 2 Dec 2002, Stefaan Cottenier wrote: > ==== > Stefaan Cottenier > submitted the following contribution: > ==== > > > Dear wien-users, > > I am puzzled by an unexpected factor 2 in the output of lapwdm. After running > a converged scf-cycle with spin-polarization and spin-orbit coupling, I want > to obtain the orbital moment of a Co-atom in my structure. Therefore, I first > test the output of lapwdm with quantities that are known in the scf-file too. > > 1) Obtain the number of valence electrons inside Rmt : > > case.indmc = > > -9. Emin cutoff energy > 5 number of atoms for which density matrix is > calculated > 1 4 0 1 2 3 index of 1st atom, number of L's, L1 > 1 1 r-index, (l,s)index > > (the Co-atom is the first atom in case.struct) After running 'x lapwdm -c -so > -up', this is case.scfdmup : > > atom L upup updn dndn total > :XOP01 0 1.16264 0.00000 1.14548 2.30812 > :XOP01 1 3.11761 0.00000 3.11894 6.23655 > :XOP01 2 4.46323 0.00000 1.53959 6.00282 > :XOP01 3 0.00657 0.00000 0.00630 0.01286 > > The last column sums to 14.5603, which is almost identical to :CHA01up + > :CHA01dn = 14.5639 in case.scf. No problems here. > > 2) Obtain the spin moment of Co : > > case.indmc = 1 2 for r-index, (l,s)index > > case.scfdmup = > > atom L upup updn dndn total > :XOP01 0 0.58132 0.00000 -0.57274 0.00858 > :XOP01 1 1.55880 0.00000 -1.55947 -0.00067 > :XOP01 2 2.23161 0.00000 -0.76980 1.46182 > :XOP01 3 0.00328 0.00000 -0.00315 0.00013 > > The upup and dndn columns are exactly ONE HALF of what is found at :QTL01 in > case.scf. The sum of the last column (1.4699) too is about ONE HALF of :MMI01 > (2.93994). > > QUESTION : For the total charge, lapwdm gives outputd that is directly > comparable to case.scf. For the spin moment, one has to multiply this by 2. > What about the other properties, that are not available in case.scf? I have > the following values calculated by lapwdm : > > orbital Co-moment = 0.079 > spin Co-hff = -2.5 T > orbital Co-hff = 4.4 T > > Should they be multiplied by two or not? > > I did these tests (running the scf-cycle and lapwdm) with the release of May > 27 and with the latest release. Both gave identical results. > > Thanks ! > Stefaan > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 21:34:29 +0800 From: "whoming" Subject: Re: [WIEN]: A question ==== "whoming" submitted the following contribution: ==== Thank you very much! - ----- Original Message ----- From: "Kevin Jorissen" To: Sent: Monday, December 02, 2002 3:54 PM Subject: Re: [WIEN]: A question > ==== > "Kevin Jorissen" > submitted the following contribution: > ==== > > There is a compilation parameter called NMATMAX. This parameter limits the > maximum matrix size allowed for lapw1 and lapw2. If you have a large > system, then a certain value of rkmax may require such a large basis > that the resulting matrix is larger than NMATMAX. In this case, rkmax is > diminished until the matrixsize does not exceed nmatmax anymore. In your > case.scf1 and case.output1 you can check the resulting rkmax. > If you need larger rkmax, you have to configure wien (siteconfig, then > dimension parameters, then make nmatmax larger and recompile lapw1 and > lapw2). > > kind regards, > Kevin Jorissen > kevin.jorissen@ua.ac.be > > ----- Original Message ----- > From: "whoming" > To: > Sent: Monday, December 02, 2002 2:52 AM > Subject: [WIEN]: A question > > > > ==== > > "whoming" > > submitted the following contribution: > > ==== > > > > Dear all, > > In one of my calculation,there is one WARNING message in case.scf > > file: > > :WARN : WARNING: RKmax reduced due to NMATMAX > > How dose it influence the result? To avoid such, what should I > do? > > Thank you very much! > > yours, > > whoming > > ----- Original Message ----- > > From: "Peter Blaha" > > To: "WIEN" > > Sent: Friday, November 29, 2002 3:54 PM > > Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > > > > > > > ==== > > > Peter Blaha > > > submitted the following contribution: > > > ==== > > > > > > > We think we were too optimistic in our last message regarding LDA+U+SO > > > > calculations. > > > > > > > > We did the changes you suggested and as we told you in our reply it > > seemed > > > > to work properly: the spin magnetic moment had the correct value and > the > > > > density of states looked fine. > > > > > > > > However, after a message by Michelle and other tests we did, we > realized > > > > that the solution was not completely correct: this time the orbital > > moment > > > > had gone to zero. > > > > > > I've also done some Ce calculations by now, but I cannot verify your > last > > > message. However, I agree, the solution proposed in my last mail > requires > > > lapw1c. > > > > > > In my tests I have simply removed after orb: > > > > > > rm $file.vorbdu > > > > > > and than apply vorb in lapwso. > > > > > > Please do not forget, that one can obtain many different LDA+U solutions > > > depending on the starting density (and density matrix). > > > > > > When starting with a density from lda + SO and adding LDA+U I get > > > > > > including cross terms: spin: -0.26032 orb: -0.54422 (with very poor > and > > > very slow convergence) > > > without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and > > quick) > > > > > > As usual I can also obtain other solutions, starting with > > > > > > SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 > > > (since I started with a "negative" moment it remains negative) > > > > > > a density matrix with large m=+3 occupation: -1.18891 2.87868 > > > > > > So you see all three solutions without cross term give a spin moment of > > 1.2, > > > while the orbital moment depends crucially on the starting dmat and was > > > 0, 1 or 3 (and I'm sure I could also converge other orbital moments). > > > > > > However, the solution with +1.2 has by far the lowest total energy of > > those > > > three tests and is thus the best solution (and is also the one which you > > > get from my recommended procedure: > > > > > > runsp -so > > > x lapwdm -so -up > > > runsp -so -orb > > > > > > I'll test this further and discuss it with others, but my impression is > > > that the cross-term in case.vorbdu is either not correct (or it's usage > in > > > lapwso is not ok) and at the moment one should remove it. After that > LDA+U > > > +SO gives expected results. > > > > > > Regards > > > 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@theochem.tuwien.ac.at WWW: > > http://info.tuwien.ac.at/theochem/ > > > > -------------------------------------------------------------------------- > > > > > > ==== > > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > > To (un)subscribe send mail to > > > majordomo@zeus.theochem.tuwien.ac.at > > > ==== > > > > > > > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 21:34:38 +0800 From: "whoming" Subject: Re: [WIEN]: A question ==== "whoming" submitted the following contribution: ==== Thanks! - ----- Original Message ----- From: "Peer Kruse" To: Sent: Sunday, December 01, 2002 5:31 PM Subject: Re: [WIEN]: A question > ==== > Peer Kruse > submitted the following contribution: > ==== > > Deaer Whoming, > you have two possibilities, you can redeuce RKmax from the start and if > this gives you not the desired > accuracy you can increase NMATMAX to cover it. But then you have to > recompile the WIEN code. > > yours > > Peer > > whoming wrote: > > >==== > >"whoming" > >submitted the following contribution: > >==== > > > >Dear all, > > In one of my calculation,there is one WARNING message in case.scf > >file: > >:WARN : WARNING: RKmax reduced due to NMATMAX > > How dose it influence the result? To avoid such, what should I do? > >Thank you very much! > >yours, > >whoming > >----- Original Message ----- > >From: "Peter Blaha" > >To: "WIEN" > >Sent: Friday, November 29, 2002 3:54 PM > >Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. > > > > > > > > > >>==== > >>Peter Blaha > >>submitted the following contribution: > >>==== > >> > >> > >> > >>>We think we were too optimistic in our last message regarding LDA+U+SO > >>>calculations. > >>> > >>>We did the changes you suggested and as we told you in our reply it > >>> > >>> > >seemed > > > > > >>>to work properly: the spin magnetic moment had the correct value and the > >>>density of states looked fine. > >>> > >>>However, after a message by Michelle and other tests we did, we realized > >>>that the solution was not completely correct: this time the orbital > >>> > >>> > >moment > > > > > >>>had gone to zero. > >>> > >>> > >>I've also done some Ce calculations by now, but I cannot verify your last > >>message. However, I agree, the solution proposed in my last mail requires > >>lapw1c. > >> > >>In my tests I have simply removed after orb: > >> > >>rm $file.vorbdu > >> > >>and than apply vorb in lapwso. > >> > >>Please do not forget, that one can obtain many different LDA+U solutions > >>depending on the starting density (and density matrix). > >> > >>When starting with a density from lda + SO and adding LDA+U I get > >> > >>including cross terms: spin: -0.26032 orb: -0.54422 (with very poor and > >> very slow convergence) > >>without crossterms (see above): spin: 1.16665 orb: -1.18953 (nice and > >> > >> > >quick) > > > > > >>As usual I can also obtain other solutions, starting with > >> > >>SO + LDA+U (including crossterms): spin -1.18519 orb: 0.07087 > >> (since I started with a "negative" moment it remains negative) > >> > >>a density matrix with large m=+3 occupation: -1.18891 2.87868 > >> > >>So you see all three solutions without cross term give a spin moment of > >> > >> > >1.2, > > > > > >>while the orbital moment depends crucially on the starting dmat and was > >>0, 1 or 3 (and I'm sure I could also converge other orbital moments). > >> > >>However, the solution with +1.2 has by far the lowest total energy of > >> > >> > >those > > > > > >>three tests and is thus the best solution (and is also the one which you > >>get from my recommended procedure: > >> > >>runsp -so > >>x lapwdm -so -up > >>runsp -so -orb > >> > >>I'll test this further and discuss it with others, but my impression is > >>that the cross-term in case.vorbdu is either not correct (or it's usage in > >>lapwso is not ok) and at the moment one should remove it. After that LDA+U > >>+SO gives expected results. > >> > >>Regards > >> 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@theochem.tuwien.ac.at WWW: > >> > >> > >http://info.tuwien.ac.at/theochem/ > > > > > >>-------------------------------------------------------------------------- > >> > >>==== > >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >>To (un)subscribe send mail to > >>majordomo@zeus.theochem.tuwien.ac.at > >>==== > >> > >> > >> > >> > > > > > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > > > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 02 Dec 2002 16:47:57 +0100 From: Thomas Claesson Subject: [WIEN]: Error message in the output ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! When running wien2k in parallel I error messages like the one below in the output: STOP LAPW0 END STOP orbital potential calculation END STOP orbital potential calculation END STOP LAPW1 END STOP LAPW1 END STOP LAPW1 END STOP LAPW1 END STOP LAPW1 END STOP LAPW1 END STOP LAPW2 - FERMI; weighs written STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. The program will recover by assuming a zero in its place. 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. The program will recover by assuming a zero in its place. STOP SUMPARA END STOP SUMPARA END STOP LAPW2 - FERMI; weighs written STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END STOP LAPW2 END 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. The program will recover by assuming a zero in its place. 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. The program will recover by assuming a zero in its place. 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. The program will recover by assuming a zero in its place. STOP SUMPARA END STOP SUMPARA END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file. STOP SUMPARA END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END STOP lapwdm END 1525-097 A READ statement using decimal base input found the invalid digit '*' in th e input file.STOP SUMPARA END STOP CORE END STOP CORE END STOP MIXER END in cycle 2 ETEST: 0 CTEST: 0 hup: Command not found. STOP LAPW0 END STOP orbital potential calculation END STOP orbital potential calculation END STOP LAPW1 END STOP LAPW1 END ... As far as I can understand this READ statement error occurrs in SUMPARA when it is trying to read the case.scf2_* files. How could the case.scf2_* files be wrong in any way, I have NOT manipulated any of them? Is this a serious error? How can I avoid it? Thanks for your replies! Any suggestions are welcome! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 17:00:08 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: Error message in the output ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Thomas Claesson > submitted the following contribution: > ==== > > When running wien2k in parallel I error messages like the one below in > the output: > > STOP LAPW0 END > STOP orbital potential calculation END > STOP orbital potential calculation END > STOP LAPW1 END >(...) > STOP LAPW2 END > 1525-097 A READ statement using decimal base input found the invalid > digit '*' in th > e input file. The program will recover by assuming a zero in its place. > 1525-097 A READ statement using decimal base input found the invalid > digit '*' in th > e input file. The program will recover by assuming a zero in its place. > STOP SUMPARA END > STOP SUMPARA END > > As far as I can understand this READ statement error occurrs in SUMPARA > when it is trying to read the case.scf2_* files. How could the > case.scf2_* files be wrong in any way, I have NOT manipulated any of > them? Is this a serious error? How can I avoid it? Have a look at the case.scf2_* and search for the '*'. Probably you somewhere have a field with '*****' where a number should be. This means wien has produced an output number that is to large to fit into the provided field, and that is usually an indication that something went wrong in the part of the scf-cycle prior to the place where the error happens. But what exactly could have gone wrong is difficult to tell with this information. Check your output for anything unusual, and try to trace back the origin of the error that way. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 18:00:20 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: case.scfdmup ==== Stefaan Cottenier submitted the following contribution: ==== Hello Pavel, Thanks for your answer. I understand the reason now, but apparently the terminology in the manual is confusing : > there may be some misunderstanding - the factor two is factor which makes > from the electronic spin the spin magnetic moment in Bohr magnetons: > m_S = gS, g=2.00 According to section 7.7 (lapwdm) of the usersguide, (r,l)=(1,2) is "the projection of the spin moment inside the atomic sphere". Maybe this should be stated more unambigously? I keep doubting about the orbital magnetic moment : is its value the number given in case.scfdmup/dn, or should this same factor 'g' be used? For orbital and dipolar contributions to the hyperfine field, I assume this 'g'-problem does not occur. And as the header of case.scfdmup/dn states that 'X' is e.g. the orbital hff in Tesla : Calculation of , X=c*Xr(r)*Xls(l,s) Xr(r) = (1/r**3)S (large component only) Xls(l,s) = L(dzeta) c= 12.51690 X=Bhf(orb) in Tesla , I can be confident that here no conversion is needed. Thanks ! Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 05:21:38 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: ==== Ma Chi Chiu submitted the following contribution: ==== Dear all, Actually, I found that I got " LAPW2 crashed!", too. Is there any limit for the number of machines to perform the parallel calculation? Or my .machines has problem? The few lines added to .machines : 1:147.8.148.180 1:147.8.148.181 1:147.8.148.182 1:147.8.148.183 1:147.8.148.184 1:147.8.148.185 1:147.8.148.186 1:147.8.148.187 1:147.8.148.188 1:147.8.148.189 granularity:3 How could I fix the problem? Actually, I have successfully got the results with 4 machines before with other fewer k-point. Thank you very much Martin On Mon, 2 Dec 2002, Ma Chi Chiu wrote: > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Dear all, > > I have some questions about parallel calculation. The parallel calculation > always dead with the error message in lapw1.error like: > ** Error in Parallel LAPW1 > ** LAPW1 STOPPED at Sun Dec 1 22:15:17 HKT 2002 > ** check ERROR FILES! > Error in LAPW1 > Error in LAPW1 > > Actually, the calculation has already finished 2 SCF cycyles. Then, why does > the calculation stop not in the 1 cycle if I got some mistake in the > parallelization? What should I do now? > > Also, I got error in doing optic parallelization. The error is "OPTIC CRASHED!" Why? > Thank you > > Martin > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 2 Dec 2002 18:40:33 -0300 (ARST) From: Ruben Weht Subject: Re: [WIEN]: Problems with LDA+U+SO in Cerium systems. ==== Ruben Weht submitted the following contribution: ==== Dear Hai, You are completely right. We changed runsp_lapw according to Peter's suggestion but we did it just in the real version of lapw1 and not in lapw1c. As you said doing it correctly we have obtained the right result for Ce-FCC, getting both magnetic and orbital moment different to zero for the ground state. We are very sorry for our mistake. We also agree with you that both cases, using orb in lapw1c or removing ##.vorbdu, seem to prove that crossterms should not be included in LDA+U+SO calculations. One more problem we have found regarding this kind of calculations (life is not so easy sometimes...): We have repeated the calculations starting with several density matrixes to obtain the metastable states found by Shick et al. However, we can say that we have obtained too many states that look like metastable ones. For instance if we start with a density matrix (for the majority spin) n_(m1,m2) equal to a pure (+3,+3) state it ends up very near to the initial matrix. But if you begin with a dmat with equal components for +3 and -1 you will finish in a state much lower in energy (500 meV). and with components n(-1,-1)=0.73, n(-1,-1)=0.24 and n(-1,+3)=-0.42 that is in a very good agreement with the one obtained by Shick et. al. We still don't understand why, if the +3 and -1 states can mix in the FCC structure, you can not go from the pure (+3,+3) state to the one with the minimum energy inside that subspace. We think in this way one can get some "false" metastable states..... Something important is that we did obtain the correct ground state just starting with the density matrix got from a LDA calculation. Well, thanks a lot to you and Peter for your replies, Best regards, Veronica and Ruben *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 6772-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 6772-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 12:26:50 +0800 (CST) From: =?gb2312?q?=B4=F3=CE=AA=20=D6=DC?= Subject: [WIEN]: Error in Mixer ==== =?gb2312?q?=B4=F3=CE=AA=20=D6=DC?= submitted the following contribution: ==== Dear Prof. P.Blaha and all wien user: When I run SCF cycle, there is an error message in the 43 step (five days later!). Error message just give me "Error in Mixer". I don't know where the questions is. I appreciate any help! With best regardes! zouweidong _________________________________________________________ Do You Yahoo!? "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" http://cn.promo.yahoo.com/cgi-bin/udb/u ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 07:53:06 +0100 (MET) From: Pavel Novak Subject: Re: [WIEN]: case.scfdmup ==== Pavel Novak submitted the following contribution: ==== Hello Stefaan, you are right - no conversion factors are needed for Bhf, lapwdm gives the orbital momentum again no conversion factor. Regards Pavel On Mon, 2 Dec 2002, Stefaan Cottenier wrote: > ==== > Stefaan Cottenier > submitted the following contribution: > ==== > > > Hello Pavel, > > Thanks for your answer. I understand the reason now, but apparently the > terminology in the manual is confusing : > > > there may be some misunderstanding - the factor two is factor which makes > > from the electronic spin the spin magnetic moment in Bohr magnetons: > > m_S = gS, g=2.00 > > According to section 7.7 (lapwdm) of the usersguide, (r,l)=(1,2) is "the > projection of the spin moment inside the atomic sphere". Maybe this should be > stated more unambigously? > > I keep doubting about the orbital magnetic moment : is its value the number > given in case.scfdmup/dn, or should this same factor 'g' be used? > > For orbital and dipolar contributions to the hyperfine field, I assume this > 'g'-problem does not occur. And as the header of case.scfdmup/dn states that > 'X' is e.g. the orbital hff in Tesla : > > Calculation of , X=c*Xr(r)*Xls(l,s) > Xr(r) = (1/r**3)S (large component only) > Xls(l,s) = L(dzeta) > c= 12.51690 X=Bhf(orb) in Tesla , > > I can be confident that here no conversion is needed. > > Thanks ! > Stefaan > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 09:23:14 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > Ma Chi Chiu > submitted the following contribution: > ==== > > Actually, I found that I got " LAPW2 crashed!", too. Is there any limit for > the number of machines to perform the parallel calculation? Or my .machines > has problem? > > The few lines added to .machines : > > 1:147.8.148.180 > 1:147.8.148.181 > 1:147.8.148.182 > 1:147.8.148.183 > 1:147.8.148.184 > 1:147.8.148.185 > 1:147.8.148.186 > 1:147.8.148.187 > 1:147.8.148.188 > 1:147.8.148.189 > granularity:3 > > How could I fix the problem? Actually, I have successfully got the results > with 4 machines before with other fewer k-point. I don't know the details of your case, but pay attention to the following points : * You have 10 machines in your .machines. That means you should have at least 10 k-points, otherwise it is useless to use that many machines. Use testpara_lapw to find an optimal distribution of k-points over your machines. For instance, if you have 16 k-points and use 10 machines, 6 machines will do 2 k-points each, and 4 will do 1 each. If you use 8 machines, then all of them will do 2 points, and your calculation will take just as much time as with 10 machines, while you now have 2 machines free for other work. All this only effects efficiency however, it cannot explain your errors. * If you are not sure exactly what you are doing, you risk to play too much in one directory, and left-over files from previous testing can spoil a next scf-cycle. Therefore, try to reinitialize the case your are trying in a clean new directory. Often this is sufficient to remove many problems. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 02:20:51 -0800 (PST) From: hamid salehi Subject: [WIEN]: SCF ==== hamid salehi submitted the following contribution: ==== Dear wien users. Ihave started SCF and In Lapw1 got this message"Cholsky INFO=269 SECLRA-ZPOTRE (LAPACK) failed what this mean?or What is its reason? What should be done for eliminating it? Thank you for the guide. H-Salehi Dept of physics Ferdowsi University MASHHAD IRAN ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 14:57:10 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: case.scfdmup ==== Peter Blaha submitted the following contribution: ==== > Thanks for your answer. I understand the reason now, but apparently the > terminology in the manual is confusing : > > > there may be some misunderstanding - the factor two is factor which makes > > from the electronic spin the spin magnetic moment in Bohr magnetons: > > m_S = gS, g=2.00 Thank's, I'll change that for the next release! 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 02 Dec 2002 17:43:13 +0100 From: Peer Kruse Subject: [WIEN]: This_file_should_not_exist ==== Peer Kruse submitted the following contribution: ==== Dear Wien Community, I set up two Linux PC for parallel computation and everything seems to work fine with the precompiled Wien2k. But a sequence of This_file_should_not_exist files is generated. Is this harmful or is it only garbage from sumpara initialization? thank you Peer ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peer Kruse Laboratorium für Elektronenmikroskopie Engesserstr. 7 76128 Universität Karlsruhe Tel 0721/608 8682 Fax 0721/608 3721 peer.kruse@lem.uni-karlsruhe.de ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 3 Dec 2002 17:56:32 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: This_file_should_not_exist ==== Peter Blaha submitted the following contribution: ==== > I set up two Linux PC for parallel computation and everything seems to > work fine with the precompiled > Wien2k. But a sequence of This_file_should_not_exist files is generated. > Is this harmful or is it only > garbage from sumpara initialization? It is harmless and is just a "trial_name" when testing wether case.dmatup/dn files exist. I agree, it could have been done in a more clever way or at least a less confusing name would be "This_file_should_be_empty". Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Dec 2002 02:06:42 -0800 (PST) From: hamid salehi Subject: [WIEN]: SCF ==== hamid salehi submitted the following contribution: ==== DearMr Hashemifar salam I hope you and your family are ok. Ihave started SCF and got this message"SELECT-no energy Limits found for l=2 'SELECT' -E-bottom -2.48500 E-top -200.00000 what this mean?or What is its reason?What should be done for eliminating it? Thank you for the guide. H-Salehi ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Dec 2002 02:10:00 -0800 (PST) From: hamid salehi Subject: [WIEN]: SCF ==== hamid salehi submitted the following contribution: ==== Dear All Ihave started SCF and got this message"SELECT-no energy Limits found for l=2 'SELECT' -E-bottom -2.48500 E-top -200.00000 what this mean?or What is its reason?What should be done for eliminating it? Thank you for the guide. H-Salehi ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Dec 2002 02:12:05 -0800 (PST) From: hamid salehi Subject: [WIEN]: SCF-2 ==== hamid salehi submitted the following contribution: ==== Dear All Ihave started SCF and In Lapw1 got this message"Cholsky INFO=269SECLRA-ZPOTRE (LAPACK) failed what this mean?or What is its reason?What should be done for eliminating it? would you please send me paper: Thank you for the guide. H-Salehi ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Dec 2002 11:18:23 +0100 (MET) From: Pio =?ISO-8859-1?Q?B=E4ttig?= Subject: [WIEN]: Wien Compile Warnings ==== Pio =?ISO-8859-1?Q?B=E4ttig?= submitted the following contribution: ==== Dear Wien users I compiled Wien2k, 28.11.02 on a Digital Personal Workstation Alpha 21164-433, using the Compaq F90 compiler and the default settings. I got the following warnings: > cat SRC_*/compile.msg | grep -i warn f90: Warning: i1mach.f, line 881: Variable IMACH is used before its value has been defined f90: Warning: joint.f, line 288: Variable ISIWITCH is used before its value has been defined f90: Warning: fermi.f, line 348: Variable IUNIT is used before its value has been defined f90: Warning: fermi.f, line 352: Variable STATUS is used before its value has been defined f90: Warning: fermi.f, line 352: Variable FORM is used before its value has been defined f90: Warning: outp.f, line 234: Variable ITAPE is used before its value has been defined f90: Warning: fermi.f, line 348: Variable IUNIT is used before its value has been defined f90: Warning: fermi.f, line 352: Variable STATUS is used before its value has been defined f90: Warning: fermi.f, line 352: Variable FORM is used before its value has been defined f90: Warning: outp.f, line 234: Variable ITAPE is used before its value has been defined f90: Warning: sumlm.f, line 106: Variable C3 is used before its value has been defined f90: Warning: sumlm.f, line 106: Variable C3 is used before its value has been defined f90: Warning: gtfnam2.f, line 127: A jump into a block from outside the block has occurred. [900] f90: Warning: gtfnam2.f, line 127: A jump into a block from outside the block has occurred. [900] f90: Warning: couple.f, line 47: Variable THETA is used before its value has been defined f90: Warning: parop.f, line 94: Variable IS is used before its value has been defined f90: Warning: parop.f, line 94: Variable E3 is used before its value has been defined f90: Warning: gtfnam2.f, line 127: A jump into a block from outside the block has occurred. [900] f90: Warning: psplit.f, line 46: Variable DUMMY is used before its value has been defined f90: Warning: lomain.f, line 12: Because of COMMON, the alignment of object is inconsistent with its type [BKROT] f90: Warning: lomain.f, line 12: Because of COMMON, the alignment of object is inconsistent with its type [BKRLOC] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: param.inc, line 9: Because of COMMON, the alignment of object is inconsistent with its type [SHIFTSG] f90: Warning: gtfnam2.f, line 127: A jump into a block from outside the block has occurred. [900] f90: Warning: atpar.f, line 260: Variable L is used before its value has been defined f90: Warning: atpar.f, line 237: Variable L is used before its value has been defined Should I change any of the compiler options? Thank you very much in advance for every hint. Kind regards Pio Bättig University of Fribourg Department of chemistry - -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Dec 2002 11:21:25 +0100 From: Torsten Andersen Subject: Re: [WIEN]: About LSTART ==== Torsten Andersen submitted the following contribution: ==== Dear Xing, there should be no unit 100... look in lstart.def. Some runtime environments does not allow Fortran units larger than 99, so if there is a unit 100 (the first number in each line of lstart.def is the "unit"), change it to something else. Best regards, Torsten. Xing Gao wrote: >==== >Xing Gao >submitted the following contribution: >==== > >Dear wien2k user, > >When I run the lstart there is an error called: > >"lib-4190 : UNRECOVERABLE library error > >Encountered during a list-directed READ from unit 100 >Fortran unit 100 is connected to a sequential formatted text file > (standard input). >IOT Trap" > >I don't know it is something wrong in the Library of our system, or the >definition of "unit 100" in the code is not suitable, or something >else. If you know please give me some suggestion. Thank you very much. > >Xing > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 04 Dec 2002 11:41:27 +0100 From: Thomas Claesson Subject: [WIEN]: Data missing in output files ==== Thomas Claesson submitted the following contribution: ==== Dear Wien users and developers! Trying to run AFII NiO with LDA+U I discovered that instead of data there are only "******" in two places in my output files. In case.scf2dn and case.scf2up the first line is :GMA : POTENTIAL AND CHARGE CUT-OFF 14.00 Ry**.5 In case.outputdmdn and case.outputdmup these lines are present: :ORB01: ORBITAL MOMENT: 0.00000 0.00000 0.00000 PROJECTION ON M 0.00000 :SPI01: SPIN MOMENT:****************************** PROJECTION ON M********* :ORB02: ORBITAL MOMENT: 0.00000 0.00000 0.00000 PROJECTION ON M 0.00000 :SPI02: SPIN MOMENT:****************************** PROJECTION ON M********* My case.indm file looks like: - -9. 2 1 1 2 2 1 2 0 0 and my case.in2 looks like: TOT (TOT,FOR,QTL,EFG,FERMI) -9.0 44.0 0.50 0.05 EMIN, NE, ESEPERMIN, ESEPER0 TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA,ALL eval) 0 0 2 0 4 0 4 3 6 0 6 3 6 6 0 0 2 0 4 0 4 3 6 0 6 3 6 6 0 0 1 0 2 0 3 0 3 3 4 0 4 3 5 0 5 3 6 0 6 3 6 6 14. GMAX FILE FILE/NOFILE write recprlist Something obviously has gone wrong here! I would appreciate if someone could give a hint about what and why. Thanks for your replies! Best regards, Thomas Claesson ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 4 Dec 2002 10:40:28 -0700 (MST) From: Martin Gelfand Subject: Re: [WIEN]: Wien Compile Warnings ==== Martin Gelfand submitted the following contribution: ==== The "used before defined" warnings are not unique to you, and you shouldn't worry about them. They arise because those variables are "output arguments" in a subroutine, so they actually _are_ defined before being used in the routine in question, but there is no way for the compiler to recognize that. You could tell your compiler not to report warnings, but there's not much of a point. Regards, Martin Gelfand Dept of Physics Colorado State University On Wed, 4 Dec 2002, Pio [ISO-8859-1] Bättig wrote: > ==== > Pio =?ISO-8859-1?Q?B=E4ttig?= > submitted the following contribution: > ==== > > Dear Wien users > > I compiled Wien2k, 28.11.02 on a Digital Personal Workstation Alpha > 21164-433, using the Compaq F90 compiler and the default settings. I got the > following warnings: > > > cat SRC_*/compile.msg | grep -i warn > f90: Warning: i1mach.f, line 881: Variable IMACH is used before its value > has been defined >.... > f90: Warning: atpar.f, line 260: Variable L is used before its value has > been defined > f90: Warning: atpar.f, line 237: Variable L is used before its value has > been defined > > Should I change any of the compiler options? > > Thank you very much in advance for every hint. > > Kind regards > > Pio Bättig > University of Fribourg > Department of chemistry > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 05 Dec 2002 08:39:32 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Wien Compile Warnings ==== Torsten Andersen submitted the following contribution: ==== Actually, the "ISIWITCH" should probably be corrected to ISWITCH, but otherwise it looks harmless, I think. Best regards, Torsten Andersen. Martin Gelfand wrote: >==== >Martin Gelfand >submitted the following contribution: >==== > >The "used before defined" warnings are not unique to you, >and you shouldn't worry about them. They arise because >those variables are "output arguments" in a subroutine, >so they actually _are_ defined before being used in the >routine in question, but there is no way for the compiler >to recognize that. > >You could tell your compiler not to report warnings, but >there's not much of a point. > >Regards, >Martin Gelfand >Dept of Physics >Colorado State University > >On Wed, 4 Dec 2002, Pio [ISO-8859-1] Bättig wrote: > >>==== >>Pio =?ISO-8859-1?Q?B=E4ttig?= >>submitted the following contribution: >>==== >> >>Dear Wien users >> >>I compiled Wien2k, 28.11.02 on a Digital Personal Workstation Alpha >>21164-433, using the Compaq F90 compiler and the default settings. I got the >>following warnings: >> >>>cat SRC_*/compile.msg | grep -i warn >>> >>f90: Warning: i1mach.f, line 881: Variable IMACH is used before its value >>has been defined >>.... >>f90: Warning: atpar.f, line 260: Variable L is used before its value has >>been defined >>f90: Warning: atpar.f, line 237: Variable L is used before its value has >>been defined >> >>Should I change any of the compiler options? >> >>Thank you very much in advance for every hint. >> >>Kind regards >> >>Pio Bättig >>University of Fribourg >>Department of chemistry >> >>-- >>+++ GMX - Mail, Messaging & more http://www.gmx.net +++ >>NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== >> > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Dec 2002 23:8:17 +0800 From: "Wenhui Xie" Subject: [WIEN]: 'LOPW' - Plane waves exhausted ==== "Wenhui Xie" submitted the following contribution: ==== Dear Sir, We miss a strange error in a tetrahedral structure. It stop at the lapw1 of first cycle. We get a error message in uplapw1.error: 'LOPW' - Plane waves exhausted Thanks for your replies! Yours Wenhui Xie ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #46 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #47 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, December 12 2002 Volume 2002 : Number 047 ---------------------------------------------------------------------- Date: Thu, 05 Dec 2002 16:15:55 +0100 From: Torsten Andersen Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== Torsten Andersen submitted the following contribution: ==== In which version of the wien code? This should not happen for normal cases in Wien2k... Anyway, it has been discussed before, so read the digest. Best regards, Torsten. Wenhui Xie wrote: >==== >"Wenhui Xie" >submitted the following contribution: >==== > >Dear Sir, > >We miss a strange error in a tetrahedral structure. >It stop at the lapw1 of first cycle. >We get a error message in uplapw1.error: > 'LOPW' - Plane waves exhausted > >Thanks for your replies! > > >Yours >Wenhui Xie > > > > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Dec 2002 17:56:45 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== Peter Blaha submitted the following contribution: ==== > We miss a strange error in a tetrahedral structure. > It stop at the lapw1 of first cycle. > We get a error message in uplapw1.error: > 'LOPW' - Plane waves exhausted This means your struct file is wrong! 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Dec 2002 23:48:18 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== "Saeid Jalali" submitted the following contribution: ==== > > We miss a strange error in a tetrahedral structure. > > It stop at the lapw1 of first cycle. > > We get a error message in uplapw1.error: > > 'LOPW' - Plane waves exhausted > > This means your struct file is wrong! In addition to the Peter's comment, this error occurs in lapw1 (up/dn) if Rmt*Kmax<4.45 in case.in1. One can check the above given condition selecting Rmt*Kmax=4.44 or less than this value even for every simple case, e.g. fcc structure containing one atom! The version of the code had been nicely touched by Torsten, which in this point I did agree and remember that old versions of wien2k code worked even employing cutoff less than 4.45 for the plane waves. In the mailing list, as it was mentioned by Torsten, there is a discussion between us in this respect. At that time I used Rmt*Kmax<3 to just speed up to perform some tests due to many atoms in the structure we were struggling with it. But, the "LOPW' - Plane waves exhausted" error did not allow me to conquer the problem. I said this story, since I would emphasis on this point that I allowed myself to use such an small Rmt*Kmax, because I had used before even Rmt*Kmax=2 successfully. This would be considered as a telltale to show that old versions of wien2k worked for small cutoff's. It will be great if the authors fix this problem, so that we can use again small cutoff's for doing test to run one cycle or more to just see what is going on in the cases containing many atoms per their cells before going through them within well-converged SCF's. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 5 Dec 2002 17:52:23 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: .machine file ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Wien2k users We compiled WIEN2k_02(release 21 Oct 02) on a shared memory IBM architecture(AIX) (total of 4 nodes, each node having 16 power4 processors) with xlf90 for serial and mpxlf90, MPI, scalapack, pblas etc. for fine grained parallel compilation. The compilation and linking was successful producing *.para *_mpi executables in addition to serial executables. We tested the executables on GaAs in serial mode. It works fine. 1) What could be the structure of .machines file for running the fine grained parallel mode? For example, suppose I have 8 kpoints in the IBZ for GaAs. how they should be distributed for running on only one node having 16 processors say. The node has a name say name1. all the processors have same speed so do all the nodes. I think of the following .machines file: 8:longhorn1:8 where longhorn1 node(one of the four node) get 8 k-points and it will be distributed among 8 processors out of 16 processors in this node. 2) During compilation, the MPI command selected was poe _EXEC_ -shared_memory yes -procs _NP_ -hfile _HOSTS_ We have poe(parallel opterating environment to run the parallel job). will the following command in the batch job file for fine-grained parallel run work? poe ./run_lapw -p -hfile .machines will poe pick up the lapw0_mpi so on for the run during the scf cycle? is -p necessary? ( the information about the number of processors will already be there in the batch script and poe should recognize the mpi executable so no need to put -shared_meomory yes in the above "poe" line i feel). I have gone through the users-manual. I will appreciate of any help in this regard. regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Dec 2002 09:21:00 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: .machine file ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > "Dr. B.R.Sahu" > submitted the following contribution: > ==== > > 1) What could be the structure of .machines file for running the > fine grained parallel mode? For example, suppose I have 8 kpoints > in the IBZ for GaAs. how they should be distributed for running on only > one node having 16 processors say. The node has a name say name1. > all the processors have same speed so do all the nodes. > > I think of the following .machines file: > > 8:longhorn1:8 > > where longhorn1 node(one of the four node) get 8 k-points and it will be > distributed among 8 processors out of 16 processors in this node. I'm not sure whether I understand your question correctly, but it seems you are mixing two things. If you want to use the mpi version, you can in your example run a case with 8 k-points on 16 machines simultaneously, i.e. all 16 machines are effectively used. But from your trial .machines, I assume you are satisfied with using 1 machine for each of the 8 k-points, and leaving the 8 other machines unused. For that purpose, you don't need mpi. Use the following .machines : 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 granularity:1 and use the -p switch with your run(sp)-command. The queing system in our SP3 system distributes the jobs to any machine of the system that is available at that time. You never know before which one it will be. Therefore, if you are in such a case, you have to create your .machines on-the-fly. The following script : #! /bin/csh setenv kortenaam `hostname` setenv langenaam $kortenaam'.cc.kuleuven.ac.be' setenv lijn1 '14:'$langenaam setenv lijn2 '14:'$langenaam setenv lijn3 '14:'$langenaam setenv gran 'granularity:1' echo $lijn1 > .machines echo $lijn2 >> .machines echo $lijn3 >> .machines echo $gran >> .machines cat .machines generates the following .machines : 14:sp27.cc.kuleuven.ac.be 14:sp27.cc.kuleuven.ac.be 14:sp27.cc.kuleuven.ac.be granularity:1 when the queing system detects it has to run the job on machine sp27.cc.kuleuven.ac.be. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Dec 2002 10:33:06 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== Peter Blaha submitted the following contribution: ==== > In addition to the Peter's comment, this error occurs in lapw1 (up/dn) if > Rmt*Kmax<4.45 in case.in1. One can check the above given condition selecting > Rmt*Kmax=4.44 or less than this value even for every simple case, e.g. fcc > structure containing one atom! The version of the code had been nicely > touched by Torsten, which in this point I did agree and remember that old > versions of wien2k code worked even employing cutoff less than 4.45 for the > plane waves. In the mailing list, as it was mentioned by Torsten, there is a > discussion between us in this respect. At that time I used Rmt*Kmax<3 to > just speed up to perform some tests due to many atoms in the structure we > were struggling with it. But, the "LOPW' - Plane waves exhausted" error did > not allow me to conquer the problem. I said this story, since I would > emphasis on this point that I allowed myself to use such an small Rmt*Kmax, > because I had used before even Rmt*Kmax=2 successfully. This would be > considered as a telltale to show that old versions of wien2k worked for > small cutoff's. It will be great if the authors fix this problem, so that we > can use again small cutoff's for doing test to run one cycle or more to > just see what is going on in the cases containing many atoms per their cells > before going through them within well-converged SCF's. a) I don't believe that we have changed anything or introduced anything preventing a small RKMax in newer WIEN2k versions. b) There could be a difference between WIEN97 and WIEN2k, because in APW+lo additional "local orbitals" are introduced and you need more PWs for them. This brings me to the main point: c) Each LO is attatched to a "symmetry-adapted" plane-wave. So: i) when your basis set (RKmax) is rediculous small than it migth not find such a plane wave (You should it, when you have more LOs than PWs ???) ii) When your struct file is wrong (e.g it contains one atom twice) than it cannot find a "symmetry-adapted" plane-wave and the message "LOPW' - Plane waves exhausted" appears. This is the "common" problem. > because I had used before even Rmt*Kmax=2 successfully. What is "successfully" ??? This is completely rediculous and I'm tempted to insert some code which definitely prevents such calculations !!!! Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Dec 2002 14:52:37 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== "Saeid Jalali" submitted the following contribution: ==== > a) I don't believe that we have changed anything or introduced anything > preventing a small RKMax in newer WIEN2k versions. Please trust one more!!! > b) There could be a difference between WIEN97 and WIEN2k > > because I had used before even Rmt*Kmax=2 successfully. I would paste below something submitted from you in August 22, 2002, when we were using wien2k code and not wien97 code in an e-mail with the subject of "large system with hydrogens". "With 84 DIFFICULT atoms (because of small spheres) it is certainly a big calculation, but should be feasable eventually (start with RKmax=2.5)" > What is "successfully" ??? Doing one cycle or more with no LOPW error emploing EKmax<4.45 is successfully perfomed, whcih does not men a successfull caculation!!! > This is completely rediculous and I'm tempted to > insert some code which definitely prevents such calculations !!!! As one now is tempted to believe that it is prevented. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Dec 2002 12:16:44 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: hello ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Dr. Stefaan thanx and I very much appreciate your help. 1) your suggested .machine file , 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 1:longhorn1 granularity:1 is for k-point parallaization run if I wish to use only 8 processors out of 16 processors availble on longhorn1 and leaving 8 others idle. am I right? for launching such runs, do I have to include in the batch job script poe ./run(sp) -p .machines or some different command to run k-point parallization. 2) I do wish to use "mpi" executable. I do wish to use all the 16 machines for 8 k-points for example. Then according to your suggestion, I should include in the job script(given below), the following: _______________________________________________________________ setenv kortenaam `hostname` setenv langenaam $kortenaam'.cc.kuleuven.ac.be'(here .cc.kuleuven.ac.be would be replaced by appropriate address) setenv lijn1 '14:'$langenaam setenv lijn2 '14:'$langenaam setenv lijn3 '14:'$langenaam setenv gran 'granularity:1' echo $lijn1 > .machines echo $lijn2 >> .machines echo $lijn3 >> .machines echo $gran >> .machines cat .machines ____________________________________________________________________________ what does "granularity" does? if I change the granularity value to some other values how does it affect the the code? _____________________________________________________________ 2) The job script for submitting the MPI parallel jobs on our SP4 looks like: #!/usr/bin/csh #@ job_name = gamo-nonmag #@ output =$(job_name).o$(jobid) #@ error = $(job_name).o$(jobid) #@ initialdir = /gpfs/utexas/ph/phaa406/GaMo #@ job_type = parallel #@ environment = COPY_ALL; MP_SHARED_MEMORY=yes; #@ resources = ConsumableCpus(1) ConsumableMemory(1gb) #@ notify_user = sahu@matter3.ph.utexas.edu #@ node = 1 #@ tasks_per_node = 16 #@ class = normal #@ notification=error #@ wall_clock_limit = 24:00:00 #@ notification=error #@ notification = complete #@ queue poe ./(WIEN2k executable) ____________________________________ while compiling the code, I selected the MPI command to be: poe _EXEC_ -shared_memory yes -procs _NP_ -hfile _HOSTS_ then in the above job script file, what should come after poe ./(WIEN2k executable)? for launching WIEN2k MPI jobs on SP$? Do I need to put "-p" with the "WIEN executable" for MPI parallel jobs? Pl. let me know If I am not clear this time. regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 6 Dec 2002 13:15:13 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: hello ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Dr. Stefaan 1) K-point parallelization is now clear and the run is successful. I played with differnet k-points with different no. of processors with the .machines file you suggested and it works fine. I used in the batch script just ./run(sp) -p. No "poe". thanx 2) pl. let me know about my query about "mpi" run. regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 06 Dec 2002 08:43:18 +0100 From: Torsten Andersen Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== Torsten Andersen submitted the following contribution: ==== Sorry, Saeid, but I have to correct you on this one. I have a calculation with CO_2 where I use rmt*kmax=4 to speed things up in the beginning, and there are no problems running it. It affects the quality of the total energy convergence, but I can live with that. Best regards, Torsten Andersen. Saeid Jalali wrote: >==== >"Saeid Jalali" >submitted the following contribution: >==== > >>>We miss a strange error in a tetrahedral structure. >>>It stop at the lapw1 of first cycle. >>>We get a error message in uplapw1.error: >>> 'LOPW' - Plane waves exhausted >>> >>This means your struct file is wrong! >> >In addition to the Peter's comment, this error occurs in lapw1 (up/dn) if >Rmt*Kmax<4.45 in case.in1. One can check the above given condition selecting >Rmt*Kmax=4.44 or less than this value even for every simple case, e.g. fcc >structure containing one atom! The version of the code had been nicely >touched by Torsten, which in this point I did agree and remember that old >versions of wien2k code worked even employing cutoff less than 4.45 for the >plane waves. In the mailing list, as it was mentioned by Torsten, there is a >discussion between us in this respect. At that time I used Rmt*Kmax<3 to >just speed up to perform some tests due to many atoms in the structure we >were struggling with it. But, the "LOPW' - Plane waves exhausted" error did >not allow me to conquer the problem. I said this story, since I would >emphasis on this point that I allowed myself to use such an small Rmt*Kmax, >because I had used before even Rmt*Kmax=2 successfully. This would be >considered as a telltale to show that old versions of wien2k worked for >small cutoff's. It will be great if the authors fix this problem, so that we >can use again small cutoff's for doing test to run one cycle or more to >just see what is going on in the cases containing many atoms per their cells >before going through them within well-converged SCF's. > Your, > S. Jalali. > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 7 Dec 2002 02:49:19 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== "Saeid Jalali" submitted the following contribution: ==== Thank you Torsten. According to the valuable comment of Peter the lowest value of RKmax depends on the number of LO's. I have checked this fact and found that it is 2.8 for C or O with the same no. of LO's, and thus for your CO_2 case, while this is 4.45 for Yb. You will see LOPW error using 2.7 instead of 4. Now everything is clear, and confirms the fact indicated by Peter that nothing has been changed or introduced preventing a small RKMax in newer WIEN2k versions (at least up to now!). At that time, when I exploited a ridiculously small value 2, I had to work on H systems with no LO's. Your, S. Jalali. > Sorry, Saeid, but I have to correct you on this one. I have a > calculation with CO_2 where I use rmt*kmax=4 to speed things up in the > beginning, and there are no problems running it. It affects the quality > of the total energy convergence, but I can live with that. > > Best regards, > Torsten Andersen. > > Saeid Jalali wrote: > > >==== > >"Saeid Jalali" > >submitted the following contribution: > >==== > > > >>>We miss a strange error in a tetrahedral structure. > >>>It stop at the lapw1 of first cycle. > >>>We get a error message in uplapw1.error: > >>> 'LOPW' - Plane waves exhausted > >>> > >>This means your struct file is wrong! > >> > >In addition to the Peter's comment, this error occurs in lapw1 (up/dn) if > >Rmt*Kmax<4.45 in case.in1. One can check the above given condition selecting > >Rmt*Kmax=4.44 or less than this value even for every simple case, e.g. fcc > >structure containing one atom! The version of the code had been nicely > >touched by Torsten, which in this point I did agree and remember that old > >versions of wien2k code worked even employing cutoff less than 4.45 for the > >plane waves. In the mailing list, as it was mentioned by Torsten, there is a > >discussion between us in this respect. At that time I used Rmt*Kmax<3 to > >just speed up to perform some tests due to many atoms in the structure we > >were struggling with it. But, the "LOPW' - Plane waves exhausted" error did > >not allow me to conquer the problem. I said this story, since I would > >emphasis on this point that I allowed myself to use such an small Rmt*Kmax, > >because I had used before even Rmt*Kmax=2 successfully. This would be > >considered as a telltale to show that old versions of wien2k worked for > >small cutoff's. It will be great if the authors fix this problem, so that we > >can use again small cutoff's for doing test to run one cycle or more to > >just see what is going on in the cases containing many atoms per their cells > >before going through them within well-converged SCF's. > > Your, > > S. Jalali. > > > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > > > > -- > Dr. Torsten Andersen > Department of Physics, Condensed Matter Theory Group, Uppsala University > UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace > News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 7 Dec 2002 09:24:52 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: hello ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > "Dr. B.R.Sahu" > submitted the following contribution: > ==== > > 1) your suggested .machine file , > > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > 1:longhorn1 > granularity:1 > > is for k-point parallaization run if I wish to use only 8 processors > out of 16 processors availble on longhorn1 and leaving 8 others idle. > am I right? Yes. > for launching such runs, do I have to include in the batch job script > > poe ./run(sp) -p .machines or some different command to run k-point > parallization. Assume you are starting a serial run by e.g. 'run_lapw -i 30 -cc 0.00001'. For a parallel run, you use exactly the same command, with the -p added : 'run_lapw - -i 30 -cc 0.00001 -p'. (this is only an example, use the command you have been using before, just add -p) > 2) I do wish to use "mpi" executable. I do wish to use all the 16 > machines for 8 k-points for example. Then according to your suggestion, I > should include in the job script(given below), the following: > _______________________________________________________________ > setenv kortenaam `hostname` > setenv langenaam $kortenaam'.cc.kuleuven.ac.be'(here .cc.kuleuven.ac.be > would be replaced by appropriate address) > setenv lijn1 '14:'$langenaam > setenv lijn2 '14:'$langenaam > setenv lijn3 '14:'$langenaam > setenv gran 'granularity:1' > echo $lijn1 > .machines > echo $lijn2 >> .machines > echo $lijn3 >> .machines > echo $gran >> .machines > cat .machines > ____________________________________________________________________________ > No. This script was only for k-point parallelization on an SP whit a queing system that doesn't allow you to know before on which machine a job will run. > what does "granularity" does? if I change > the granularity value to some other values how does it affect the > the code? It determines how the k-points are distributed. If you have 4 k-points and 2 nodes, you can distribute them as 2+2 or 2x(1+1). When you have as many k-points as nodes, granularity:1 is fine (see UG for a more detailed explanation, or experiment yourself by using testpara_lapw) > _____________________________________________________________ > 2) The job script for submitting the MPI parallel jobs on our SP4 looks > like: > #!/usr/bin/csh > #@ job_name = gamo-nonmag > #@ output =$(job_name).o$(jobid) > #@ error = $(job_name).o$(jobid) > #@ initialdir = /gpfs/utexas/ph/phaa406/GaMo > #@ job_type = parallel > #@ environment = COPY_ALL; MP_SHARED_MEMORY=yes; > #@ resources = ConsumableCpus(1) ConsumableMemory(1gb) > #@ notify_user = sahu@matter3.ph.utexas.edu > #@ node = 1 > #@ tasks_per_node = 16 > #@ class = normal > #@ notification=error > #@ wall_clock_limit = 24:00:00 > #@ notification=error > #@ notification = complete > #@ queue > poe ./(WIEN2k executable) > ____________________________________ > > while compiling the code, I selected the MPI command to be: > > poe _EXEC_ -shared_memory yes -procs _NP_ -hfile _HOSTS_ > > then in the above job script file, what should come after poe ./(WIEN2k > executable)? for launching WIEN2k MPI jobs on SP$? Do I need to put "-p" > with the "WIEN executable" for MPI parallel jobs? I never used the mpi option so far, and never looked at it in detail, maybe somebody else can help you here. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 7 Dec 2002 21:25:46 +0800 (CST) From: music@theory.issp.ac.cn Subject: [WIEN]: DSTART ERROR ==== music@theory.issp.ac.cn submitted the following contribution: ==== Dear wien users, I want to calculate the supercell of tio2 in 2a*2b*c, and substiute A Ti atom with other atom. And when doing dstart, error occurs in dstart.error file : 'ROTDEF' - no symmetry operation found. 'ROTDEF' - for jatom, index 1 2 'ROTDEF' - atomposition of jatom 0.0000000 0.0000000 0.0000000 'ROTDEF' - atomposition of index 0.0000000 0.5000000 0.0000000 ~ I think the struct file is right but I dont know why dstart cant do. Could anyone help me ? THANKS IN ADVANCE!A - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 07 Dec 2002 16:47:38 +0200 From: "B. Yanchitsky" Subject: Re: [WIEN]: DSTART ERROR ==== "B. Yanchitsky" submitted the following contribution: ==== Most probably your struct file is incorrect. This looks that positions (0,0,0) and (0,0.5,0) are connected by a lattice translation. Use sgroup to check the struct file, or check atomic positions using Intern. Tables if space group is known and the unit cell has been chosen properly. Regards, Bogdan > > Dear wien users, > I want to calculate the supercell of tio2 in 2a*2b*c, and substiute A Ti > atom with other atom. And when doing dstart, error occurs in > dstart.error file : > 'ROTDEF' - no symmetry operation found. > 'ROTDEF' - for jatom, index 1 2 > 'ROTDEF' - atomposition of jatom 0.0000000 0.0000000 0.0000000 > 'ROTDEF' - atomposition of index 0.0000000 0.5000000 0.0000000 > ~ > I think the struct file is right but I dont know why dstart cant do. > Could anyone help me ? > THANKS IN ADVANCE!A > -- > sincerely yours > > Ying.X > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 01:29:03 +0800 (HKT) From: Ma Chi Chiu Subject: Re: [WIEN]: Question ==== Ma Chi Chiu submitted the following contribution: ==== Dear Prof. Blaha, Actually, I would like to consult the procedure for register for WIEN2K. We have bought WIEN97 and now we would like to upgrade to WIEN2K. What is the procedure for register for WIEN2K? Thank you very much Martin On Mon, 4 Nov 2002, Peter Blaha wrote: > > WIEN2k has no problems with your structure. > > I suggest you register for WIEN2k. > > > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 08 Dec 2002 01:52:26 +0800 From: =?gb2312?B?1dQg1r684Q==?= Subject: [none] ==== =?gb2312?B?1dQg1r684Q==?= submitted the following contribution: ==== Dear sir: I have a question, when I execute lapw2 in parallel model. I have 8 nodes together, and my .machines file like this: granularity:3 1:node0 1:node1 1:node2 1:node3 1:node4 1:node5 1:node6 1:node7 I have 68 irreducibal k-points,so the case.klist file like this: ##################################################### # TESTPARA # ##################################################### Test: LAPW1 in parallel mode (using .machines) Granularity set to 3 Extrafine unset klist: 68 machines: node0 node1 node2 node3 node4 node5 node6 node7 procs: 8 weigh(old): 1 1 1 1 1 1 1 1 sumw: 8 granularity: 3 weigh(new): 2 2 2 2 2 2 2 2 Distribution of k-point (under ideal conditions) will be: 1 : node0(2) 2k 2 : node1(2) 2k 3 : node2(2) 2k 4 : node3(2) 2k 5 : node4(2) 2k 6 : node5(2) 2k 7 : node6(2) 2k 8 : node7(2) 2k 9 : node0(2) 2k 10 : node1(2) 2k 11 : node2(2) 2k 12 : node3(2) 2k 13 : node4(2) 2k 14 : node5(2) 2k 15 : node6(2) 2k 16 : node7(2) 2k 17 : node0(2) 2k 18 : node1(2) 2k 19 : node2(2) 2k 20 : node3(2) 2k 21 : node4(2) 2k 22 : node5(2) 2k 23 : node6(2) 2k 24 : node7(2) 2k 25 : node0(2) 2k 26 : node1(2) 2k 27 : node2(2) 2k 28 : node3(2) 2k 29 : node4(2) 2k 30 : node5(2) 2k 31 : node6(2) 2k 32 : node7(2) 2k 33 : node0(2) 2k 34 : node1(2) 2k Firstly, I type the command: run_lapw -p, then, I run the program: testpara2, I find the file like this: ##################################################### # TESTPARA2 # ##################################################### Sun Dec 8 01:38:03 CST 2002 lapw2para is running 27 of 34 (79%) junks distributed machines(processors) in calling order are: node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 node0 wait a minute,I again run testpara2,finding like this: ##################################################### # TESTPARA2 # ##################################################### Sun Dec 8 01:39:00 CST 2002 lapw2para has finished The question is I want to know whether the performance of "lapw2 -p" is correct according to the above information. If it is wrong,what should I do? Thank you very much. Best regards. J.Zhao 12/8/2002 _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 00:46:21 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: DSTART ERROR ==== "Kevin Jorissen" submitted the following contribution: ==== Dear mr. Ying, it would really be easier to help you if had sent the struct-file. When you create a supercell and add an impurity, you reduce the symmetry of your system. Thus, atoms that were (crystallographically) equivalent before will now become inequivalent, and you may have to change your lattice type, and enter more atom coordinates (eg. if you have to go from F to P-lattice). So it's best to do the whole initialization from scratch. Start with a struct-file where all atoms of the same kind are equivalent, run nn, and sgroup, and symmetry, and by the time you get there, wien will provide you with a struct-file that looks totally different. Check this file to see whether it looks reasonable (eg. equivalent atoms should at least be of the same kind and at equal distances to the impurity; also, they should be connected by one of the 48 'legal' symmetry operations). Usually it's errors in the struct-file related to atom equivalency that produce the kind of messages that you get. If you keep having problems, please send the struct-file. kind regards, Kevin Jorissen. PS These are the WIEN criteria for equivalency : - - atoms must have the same atomic number (nn) - - atoms must have the same environment, i.e. for equivalent atoms, the same number of atoms of the same atomic number have to be found at the same distances of these equivalent atoms, and this up to a certain distance determined by the input you give to nn (for super cells, it may be safer to check with a higher value than the default '2') (nn) - - the coordinates of equivalent atoms in the global coordinate system must transform into one another by application of one symmetry operations of your structure (these are the ones out of the 48 known operations that can be applied to every atom in the unit cell) (symmetry) - ----- Original Message ----- From: To: Sent: Saturday, December 07, 2002 2:25 PM Subject: [WIEN]: DSTART ERROR > ==== > music@theory.issp.ac.cn > submitted the following contribution: > ==== > > Dear wien users, > I want to calculate the supercell of tio2 in 2a*2b*c, and substiute A Ti > atom with other atom. And when doing dstart, error occurs in > dstart.error file : > 'ROTDEF' - no symmetry operation found. > 'ROTDEF' - for jatom, index 1 2 > 'ROTDEF' - atomposition of jatom 0.0000000 0.0000000 0.0000000 > 'ROTDEF' - atomposition of index 0.0000000 0.5000000 0.0000000 > ~ > I think the struct file is right but I dont know why dstart cant do. > Could anyone help me ? > THANKS IN ADVANCE!A > -- > sincerely yours > > Ying.X > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 14:29:42 +0800 (CST) From: music@theory.issp.ac.cn Subject: Re: [WIEN]: DSTART ERROR ==== music@theory.issp.ac.cn submitted the following contribution: ==== Dear Mr Jorissen, Thank you very much for your instructive advise! I did not notice that a new struct was out after sgroup. NN produce a new struct refer to the distance of atoms, and sgroup brings out new inequivalent atoms. So now it's ok. > ==== > "Kevin Jorissen" > submitted the following contribution: > ==== > > Dear mr. Ying, > > it would really be easier to help you if had sent the struct-file. > When you create a supercell and add an impurity, you reduce the symmetry of > your system. Thus, atoms that were (crystallographically) equivalent before > will now become inequivalent, and you may have to change your lattice type, > and enter more atom coordinates (eg. if you have to go from F to P-lattice). > So it's best to do the whole initialization from scratch. Start with a > struct-file where all atoms of the same kind are equivalent, run nn, and > sgroup, and symmetry, and by the time you get there, wien will provide you > with a struct-file that looks totally different. Check this file to see > whether it looks reasonable (eg. equivalent atoms should at least be of the > same kind and at equal distances to the impurity; also, they should be > connected by one of the 48 'legal' symmetry operations). Usually it's > errors in the struct-file related to atom equivalency that produce the kind > of messages that you get. > If you keep having problems, please send the struct-file. > > kind regards, > Kevin Jorissen. > > PS These are the WIEN criteria for equivalency : > - atoms must have the same atomic number (nn) > - atoms must have the same environment, i.e. for equivalent atoms, the same > number of atoms of the same atomic number have to be found at the same > distances of these equivalent atoms, and this up to a certain distance > determined by the input you give to nn (for super cells, it may be safer to > check with a higher value than the default '2') (nn) > - the coordinates of equivalent atoms in the global coordinate system must > transform into one another by application of one symmetry operations of your > structure (these are the ones out of the 48 known operations that can be > applied to every atom in the unit cell) (symmetry) > > > ----- Original Message ----- > From: > To: > Sent: Saturday, December 07, 2002 2:25 PM > Subject: [WIEN]: DSTART ERROR > > > > ==== > > music@theory.issp.ac.cn > > submitted the following contribution: > > ==== > > > > Dear wien users, > > I want to calculate the supercell of tio2 in 2a*2b*c, and substiute A Ti > > atom with other atom. And when doing dstart, error occurs in > > dstart.error file : > > 'ROTDEF' - no symmetry operation found. > > 'ROTDEF' - for jatom, index 1 2 > > 'ROTDEF' - atomposition of jatom 0.0000000 0.0000000 0.0000000 > > 'ROTDEF' - atomposition of index 0.0000000 0.5000000 0.0000000 > > ~ > > I think the struct file is right but I dont know why dstart cant do. > > Could anyone help me ? > > THANKS IN ADVANCE!A > > -- > > sincerely yours > > > > Ying.X > > > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 10:09:45 +0100 From: Stefaan Cottenier Subject: [WIEN]: Re: ==== Stefaan Cottenier submitted the following contribution: ==== > I have a question, when I execute lapw2 in parallel model. > I have 8 nodes together, and my .machines file like this: > granularity:3 > 1:node0 > 1:node1 > 1:node2 > 1:node3 > 1:node4 > 1:node5 > 1:node6 > 1:node7 > I have 68 irreducibal k-points,so the case.klist file like this: If you don't have to share these 8 nodes with other users during the execution of your job, you can use also 9:node0 9:node1 9:node2 9:node3 9:node4 9:node5 9:node6 5:node7 granularity:1 This will give 8x1=8 jobs to each node (node 7 is occupied somewhat less). > Firstly, I type the command: run_lapw -p, Do 'run_lapw -p -i 1'. This will execute 1 iteration in parallel. Then check *.dayfile, to see how much time each of the sub-jobs took, and whether they used the processors efficiently. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 23:3:42 +0800 From: "Wenhui Xie" Subject: [WIEN]: Symmetry operation of Group No. 119 and No. 139 ==== "Wenhui Xie" submitted the following contribution: ==== Dear Sir£¬ The symmetry operation of Group No.119 and No. 139 given by Wien2k are 8 and 16, respectively. However, someone claim that the operation is 16 and 32, respectively, like this website: http://autodep.ebi.ac.uk/sgtable.html I am puzzle about it. I would appreciate if someone could give a hint about what and why. Your Sincerely Wenhui Xie xiewh@sun20.iphy.ac.cn 2002-12-08 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 8 Dec 2002 23:9:41 +0800 From: "Wenhui Xie" Subject: Re: Re: [WIEN]: 'LOPW' - Plane waves exhausted ==== "Wenhui Xie" submitted the following contribution: ==== Dear Peter Blaha, We check the struct file and find that the beta angle is wrong. Now, everything is OK. Thank the instructive advise of Prof. Plaha and other people in here. Yours Sincerely Wenhui Xie xiewh@sun20.iphy.ac.cn 2002-12-08 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 12:55:53 +0100 (MET) From: Peter Blaha Subject: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== > I have a question, when I execute lapw2 in parallel model. > lapw2para has finished > > The question is I want to know whether the performance of "lapw2 -p" is > correct according to the above information. If it is wrong,what should I > do? Thank you very much. > Best regards. It seems to be ok. Just make a run with and without -p and compare. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 13:45:00 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: hello ==== Peter Blaha submitted the following contribution: ==== Parallel calculations: You really need to read the UG (at least section about parallelization!!!!) In all circumstances you use only run_lapw -p for parallel execution. When you have configured WIEN2k properly during siteconfig, the rest is done by the .machines file. > 1:longhorn1 > 1:longhorn1 > granularity:1 This does k-point parallelization (with two processors) If you want to use the fine-grain mpi parallelization (NOTE: this works only reasonably well when you have a large case (matrix sizes of 5000 and more), It is absolutely nonsense to use this for smaller matrices and may even run slower than on 1 processor). To select mpi parallelization your machines file should contain lines like: lapw0:longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 This runs lapw0 on 2 processors and 2-k-point parallel lapw1_mpi jobs, where each lapw1_mpi runs on 2 processors in parallel. Please note: You were saying you are using an IBM with the "loadleveler". At least on our IBM-SP3 a loadleveler script with a line: > #@ tasks_per_node = 16 will always use 16 processors for an mpi-executable, and completely ignore any values for _NP_ in the actual "poe" command line (which is called internally in lapw1para). poe _EXEC_ -shared_memory yes -procs _NP_ -hfile _HOSTS_ Thus on our IBM we cannot use the loadleveler and use k-point and mpi-parallelization at once. (We run it in background and this works nicely, but you may have to negotioate with your computing center to operate in this mode). PS: If anybody knows how to override the "tasks_per_node" value in the actual job, please let me know). If you have to use the loadleveler, I strongly recommend to use the k-parallel version only (and start a second project on the other 8 processors), unless you have a really big case with just 1-2 k-points. If you run a queuing system, you may have to create the .machines file "on the fly" with the script decribed by Stefaan. (Although on a cluster of shared memory machines it is not really necessary). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 14:18:06 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Symmetry operation of Group No. 119 and No. 139 ==== Peter Blaha submitted the following contribution: ==== > The symmetry operation of Group No.119 and No. 139 given by > Wien2k are 8 and 16, respectively. However, someone claim that > the operation is 16 and 32, respectively, like this website: > http://autodep.ebi.ac.uk/sgtable.html > > I am puzzle about it. I would appreciate if someone > could give a hint about what and why. Because they do not use the primitive cell ! There is a difference of 2 (or 4) for I or F centered cells. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 20:48:59 +0400 (SAMT) From: Lyudmila Dobysheva Subject: [WIEN]: BROYD mixing parameter ==== Lyudmila Dobysheva submitted the following contribution: ==== Dear WIEN-users, How the BROYD mixing scheme works? I have made an scf-cycle, it gave such charge distances: :DIS : CHARGE DISTANCE 0.0005600 :DIS : CHARGE DISTANCE 0.0004390 :DIS : CHARGE DISTANCE 0.0004751 :DIS : CHARGE DISTANCE 0.0004486 :DIS : CHARGE DISTANCE 0.0002515 :DIS : CHARGE DISTANCE 0.0002113 :DIS : CHARGE DISTANCE 0.0001803 :DIS : CHARGE DISTANCE 0.0001699 :DIS : CHARGE DISTANCE 0.0001136 :DIS : CHARGE DISTANCE 0.0000699 When I looked at mixing parameter used, I saw that it's rather low as compared to the parameter given in case.inm (0.40) and equal in all cycles: BROYD MIXING SCHEME WITH 0.182 BROYD MIXING SCHEME WITH 0.182 BROYD MIXING SCHEME WITH 0.182 Another scf-cycle gave such a convergency: :DIS : CHARGE DISTANCE 0.0489381 :DIS : CHARGE DISTANCE 0.0888596 :DIS : CHARGE DISTANCE 0.0172118 :DIS : CHARGE DISTANCE 0.0090646 :DIS : CHARGE DISTANCE 0.0182707 :DIS : CHARGE DISTANCE 0.0022858 :DIS : CHARGE DISTANCE 0.0018873 :DIS : CHARGE DISTANCE 0.0015986 :DIS : CHARGE DISTANCE 0.0011595 :DIS : CHARGE DISTANCE 0.0008809 :DIS : CHARGE DISTANCE 0.0006736 :DIS : CHARGE DISTANCE 0.0005523 :DIS : CHARGE DISTANCE 0.0004370 :DIS : CHARGE DISTANCE 0.0003596 :DIS : CHARGE DISTANCE 0.0003257 And again, the mixing parameter from the scf file was in all cycles: BROYD MIXING SCHEME WITH 0.182 Why it is not larger, especially in the first case? And why it has the same magnitude in both cases? I thought it should depend on the :DIS value. Best regards, Lyudmila Dobysheva - ------------------------------------------------------------------------ Phys.-Techn. Institute of | Tel.(home): 7 (3412) 442118 Ural Branch of Russian Ac. of Sci. | Tel.(office): 7 (3412) 218988 426001 Izhevsk, ul.Kirova 132 | Fax: 7 (3412) 250614 RUSSIA | E-mail: lyu@otf.fti.udmurtia.su - ------------------------------------------------------------------------ http://fti.udm.ru/ltt/personals/dobysh.htm - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 15:03:50 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI run ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Peter (and other w2k users) thanx. 1) k-point parallelization works fine with the load leveler. 2) with the help of the loadleveler on SP4, the job is always put in the background using the batch job script : #!/usr/bin/csh #@ job_name = test #@ output =$(job_name).o$(jobid) #@ error = $(job_name).o$(jobid) #@ initialdir = /gpfs/utexas/ph/phaa406/gaas #@ job_type = parallel #@ environment = COPY_ALL; MP_SHARED_MEMORY=yes; #@ resources = ConsumableCpus(1) ConsumableMemory(1gb) #@ notify_user = sahu@matter3.ph.utexas.edu #@ node = 1 #@ tasks_per_node = 16 #@ class = normal #@ notification=error #@ wall_clock_limit = 24:00:00 #@ notification=error #@ notification = complete #@ queue poe executable ________________________________________________ in this case poe will use number of processors(here 16) for the run and the loadleveler assigns the next available node depending upon the info in the jobscript(tested for MPI parallel codes like VASP, CPMD etc where other parallelization strategies might have been used) now, if I have a system say 60 atoms with 1-2 k-pt, then as per the userguide and your suggestion, mpi parallel jobs are preferable. but in this case can poe ./wien_executables(run(sp)_lapw -p) in the above jobscript work without - -shared_memory yes -procs _NP_ -hfile _HOSTS_ explicitly specified? (by assuming that "poe" picks up lapw0_mpi, lapw1_mpi etc instead of lapw1_para, lapw2_para ) your example of the .machines file for the mpi parallel run has 2 processors and 2 k-point. However, if I wish to use all the 16 processors available in the given node(here longhorn1) with 2 k-points then the machine file can be: lapw0: longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 (where I wish to use all 16 processors for lapw0) 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 where I have distributed 2 kpoints over 8 processors each(in total 16 processors). is this correct? do we need "granularity" here too? 2) If I wish to calculate the orbital magnetic moment on a particular atom in the unit cell by adding SOC nonselfconsistently, hen will -so switch in run(sp)_lapw -so calulates it with the proper case.inso file generated by initso_lapw(where I have the results of previous scf cycle without -so i.e. run(sp)_lapw -p). I dont have to use -p switch for adding SOC by non-scf. only for adding SOC selfconsistently, I need to use from the begining run(sp)_lapw -so -p. am I right? 3) If I understand correctly, for volume or internal parameter optimization, the userguide says, we need to "renormalize" the charge density using 'MIXER'(with -renorm). what does the switch "-renorm" exactly do and why it is necessary to renormalize the charge density for a new calculation with different lattice parameters(as done in vol. optimization procedure).If I have a situation where I am using a shell script(optimize.job) for vol optimization after every scf cycle for each lattice paramter I do save_lapw -d "directory" then anyway *broydX files are deleted then what does the -renorm parameter do for the next scf cycle for the next lattice parameter? regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 15:58:34 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: hi ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear w2kusers Is there an article, where the "orbital polarization" method is described in detail including the self-consistent calculation of OP parameters. Userguide gives Eriksson et.al ref( J.Phys:Cond. Matter vol 1 pg 4005(1989) and Brooks Physica B130 pg 6 1985) where these authors used OP method to describe magnetic properties of Uranium ternary alloys the method itself is not described in detail.In Eriksson et.al's paper there is reference to OP method but in the reference list it is "unpublished" regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 08:03:31 +0800 From: gyguo Subject: Re: [WIEN]: hi ==== gyguo submitted the following contribution: ==== Hi, It might be helpful to take a look at a paper of mine and references therein [PRB 55, 11619 (1997)]. Cheers, Guang-Yu "Dr. B.R.Sahu" ¼g¹D¡G > ==== > "Dr. B.R.Sahu" > submitted the following contribution: > ==== > > Dear w2kusers > > Is there an article, where the "orbital polarization" method is > described in detail including the self-consistent calculation of OP > parameters. Userguide gives Eriksson et.al ref( J.Phys:Cond. Matter vol 1 > pg 4005(1989) and Brooks Physica B130 pg 6 1985) where these authors > used OP method to describe magnetic properties of Uranium ternary alloys > the method itself is not described in detail.In Eriksson et.al's paper > there is reference to OP method but in the reference list it is > "unpublished" > > regards > sahu > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== - -- Dr. G.Y. Guo Professor Department of Physics National Taiwan University 1 Roosevelt Road, Sec. 4 Taipei 106, Taiwan, R.O.C. Tel. ++886-2-33665180 Fax. ++886-2-23639984 E-mail: gyguo@phys.ntu.edu.tw ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 9 Dec 2002 23:02:35 -0600 (CST) From: Bing Zhou Subject: [none] ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear All: I don't know my case.struct failed to be run with "init_lapw", could you please take a look of the attached file and give me some ideas about how to fix my case.struct file? Thanks! Pacholite (Hawthorne) P LATTICE,NONEQUIV. ATOMS:13 15 C2/c MODE OF CALC=RELA 18.778216 19.679616 29.630917 90.000000142.442600 90.000000 Atom= -1: X=0.17281000 Y=0.12590000 Z=0.71803000 MULT= 1 ISPLIT= 8 Al NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 13.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -2: X=0.18750000 Y=0.17360000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -3: X=0.18750000 Y=0.56940000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -4: X=0.31460000 Y=0.12740000 Z=0.62520000 MULT= 1 ISPLIT= 8 Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -5: X=0.02710000 Y=0.99910000 Z=0.19380000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -6: X=0.12995000 Y=0.99070000 Z=0.36130000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -7: X=0.15725000 Y=0.11380000 Z=0.57470000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -8: X=0.18960000 Y=0.14300000 Z=0.86440000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -9: X=0.09910000 Y=0.25050000 Z=0.30210000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-10: X=0.99540000 Y=0.25300000 Z=0.12490000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-11: X=0.19650000 Y=0.37530000 Z=0.42790000 MULT= 1 ISPLIT= 8 O NPT= 781 R0=0.00010000 RMT= 1.5000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-12: X=0.17550000 Y=0.37100000 Z=0.35100000 MULT= 1 ISPLIT= 8 H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-13: X=0.23050000 Y=0.36000000 Z=0.48800000 MULT= 1 ISPLIT= 8 H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 SYMMETRY OPERATIONS: - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pachnolite-new.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="pachnolite-new.struct" UGFjaG9saXRlIChIYXd0aG9ybmUpDQpQICAgTEFUVElDRSxOT05FUVVJVi4g QVRPTVM6MTMgICAgICAgICAgICAgICAgICAgICAgIDE1IEMyL2MNCk1PREUg T0YgQ0FMQz1SRUxBDQogMTguNzc4MjE2IDE5LjY3OTYxNiAyOS42MzA5MTcg OTAuMDAwMDAwMTQyLjQ0MjYwMCA5MC4wMDAwMDANCkF0b209IC0xOiBYPTAu MTcyODEwMDAgWT0wLjEyNTkwMDAwIFo9MC43MTgwMzAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpBbCAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuODAwMCAgIFo6IDEzLjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC0yOiBYPTAuMTg3NTAwMDAg WT0wLjE3MzYwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAwNTAwMCBSTVQ9ICAgIDEuODAwMCAgIFo6IDIwLjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209IC0zOiBYPTAuMTg3NTAwMDAgWT0wLjU2OTQw MDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAw MCBSTVQ9ICAgIDEuODAwMCAgIFo6IDIwLjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkF0b209IC00OiBYPTAuMzE0NjAwMDAgWT0wLjEyNzQwMDAwIFo9MC42 MjUyMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpOYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuODAwMCAgIFo6IDExLjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209 IC01OiBYPTAuMDI3MTAwMDAgWT0wLjk5OTEwMDAwIFo9MC4xOTM4MDAwMA0K ICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAg ICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAg IFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC02OiBYPTAu MTI5OTUwMDAgWT0wLjk5MDcwMDAwIFo9MC4zNjEzMDAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC03OiBYPTAuMTU3MjUwMDAg WT0wLjExMzgwMDAwIFo9MC41NzQ3MDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209IC04OiBYPTAuMTg5NjAwMDAgWT0wLjE0MzAw MDAwIFo9MC44NjQ0MDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAw MCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkF0b209IC05OiBYPTAuMDk5MTAwMDAgWT0wLjI1MDUwMDAwIFo9MC4z MDIxMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209 LTEwOiBYPTAuOTk1NDAwMDAgWT0wLjI1MzAwMDAwIFo9MC4xMjQ5MDAwMA0K ICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAg ICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAg IFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209LTExOiBYPTAu MTk2NTAwMDAgWT0wLjM3NTMwMDAwIFo9MC40Mjc5MDAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPICAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNTAwMCAgIFo6ICA4LjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209LTEyOiBYPTAuMTc1NTAwMDAg WT0wLjM3MTAwMDAwIFo9MC4zNTEwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICAxLjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209LTEzOiBYPTAuMjMwNTAwMDAgWT0wLjM2MDAw MDAwIFo9MC40ODgwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAw MCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICAxLjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCiAgIDAgU1lNTUVUUlkgT1BFUkFUSU9OUzoNCg== - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pachnolite-new.inst" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="pachnolite-new.inst" QWwgDQpOZSAyIDUNCjMsLTEsMS4wICBODQozLC0xLDEuMCAgTg0KMywgMSwx LjAgIE4NCjMsIDEsMC4wICBODQpDYSANCkFyIDEgNQ0KNCwtMSwxLjAgIE4N CjQsLTEsMS4wICBODQpDYSANCkFyIDEgNQ0KNCwtMSwxLjAgIE4NCjQsLTEs MS4wICBODQpOYSANCk5lIDEgNQ0KMywtMSwxLjAgIE4NCjMsLTEsMC4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpPIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMC4wICBO DQpIIA0KMSA1DQoxLC0xLDAuOSAgTg0KMSwtMSwwLjEgIE4NCkggDQoxIDUN CjEsLTEsMC45ICBODQoxLC0xLDAuMSAgTg0KKioqKiAgICAgRW5kIG9mIElu cHV0DQoqKioqICAgICBFbmQgb2YgSW5wdXQNCg== - ---559023410-1804928587-1039496555=:16285-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 09:53:41 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: MPI run ==== Peter Blaha submitted the following contribution: ==== > 2) with the help of the loadleveler on SP4, the job is always put in the > background using the batch job script : > > #!/usr/bin/csh > #@ job_name = test > #@ output =$(job_name).o$(jobid) > #@ error = $(job_name).o$(jobid) > #@ initialdir = /gpfs/utexas/ph/phaa406/gaas > #@ job_type = parallel > #@ environment = COPY_ALL; MP_SHARED_MEMORY=yes; > #@ resources = ConsumableCpus(1) ConsumableMemory(1gb) > #@ notify_user = sahu@matter3.ph.utexas.edu > #@ node = 1 > #@ tasks_per_node = 16 > #@ class = normal > #@ notification=error > #@ wall_clock_limit = 24:00:00 > #@ notification=error > #@ notification = complete > #@ queue > poe executable > > ________________________________________________ > > in this case poe will use number of processors(here 16) for the run and > the loadleveler assigns the next available node depending upon the info in > the jobscript(tested for MPI parallel codes like VASP, CPMD etc where > other parallelization strategies might have been used) > > now, if I have a system say 60 atoms with 1-2 k-pt, then as per the > userguide and your suggestion, mpi parallel jobs are preferable. > but > > in this case can > > poe ./wien_executables(run(sp)_lapw -p) > > in the above jobscript work without > > -shared_memory yes -procs _NP_ -hfile _HOSTS_ explicitly specified? > (by assuming that "poe" picks up lapw0_mpi, lapw1_mpi etc instead of > lapw1_para, lapw2_para ) No, just use run_lapw -p This script calls internally lapw0/1/2para and those scripts will then issue the necessary poe commands. > > your example of the .machines file for the mpi parallel run has > 2 processors and 2 k-point. However, if I wish to use all the 16 > processors available in the given node(here longhorn1) with 2 k-points > then the machine file can be: > > lapw0: longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > (where I wish to use all 16 processors for lapw0) > 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 > 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 > > where I have distributed 2 kpoints over 8 processors each(in total 16 > processors). Yes, this would be the suggested .machines file. The idea is to span two jobs, one for the first k-point using 8 mpi-parallel processors and another for the second k-point (again with 8 mpi-processors. However, remember my previous email: On our SP3 the loadleveler ignores the NP command and takes always 16 processors (when tasks_per_nodes=16) and then crashes with the second k-point (since he has already used 16 processors for the first k-point.) I know only 2 ways out (and if somebody could provide a better solution?!): a) Do not use the loadleveler (if you are allowed to do so) b) Remove the last line from .machines. This will use all 16 processors for the first k-point and AFTER this has finished, it will do the second k-point again with 16 processors. (This is less efficient, but maybe the only way you can do it) > do we need "granularity" here too? You don't need "granularity" here (When you have 30 k-points, a larger granularity will submit not 15 and 15 k-points, but first eg. 5 and 5 and once one of these jobs has finished, the next junk is submitted. This allows for some loadballancing on clusters, but on shared memory machines always use granularity=1 (and for 2k points it has no effect at all). > > 2) If I wish to calculate the orbital magnetic moment on a particular atom > in the unit cell by adding SOC nonselfconsistently, hen will -so switch in > run(sp)_lapw -so calulates it with the proper case.inso file generated by > initso_lapw(where I have the results of previous scf cycle without -so > i.e. run(sp)_lapw -p). I dont have to use -p switch for adding SOC by > non-scf. only for adding SOC selfconsistently, I need to use > from the begining run(sp)_lapw -so -p. > am I right? You can do it with or without "-p" (k-point parallel only for lapwso) > 3) If I understand correctly, for volume or internal parameter > optimization, the userguide says, we need to "renormalize" the charge > density using 'MIXER'(with -renorm). what does the switch "-renorm" > exactly do and why it is necessary to renormalize the charge density for a > new calculation with different lattice parameters(as done in vol. > optimization procedure).If I have a situation where I am using a shell > script(optimize.job) for vol optimization after every scf cycle for each > lattice paramter I do save_lapw -d "directory" then anyway *broydX files > are deleted then what does the -renorm parameter do for the next scf > cycle for the next lattice parameter? If you change the lattice parameters, the planewave charge density in the interstital does not give the correct number of electrons when you integrate it. Renormalization just fixes this problem. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 09:58:45 +0100 From: Georg Madsen Subject: [WIEN]: Re: ==== Georg Madsen submitted the following contribution: ==== You have typed in your C centered lattice as primitive. This could be a good idea because you want sgroup to convert it to B2/b. But then you have to type in all your atoms. This means also the atoms from the (1/2,1/2,0) translation. Quoting Bing Zhou : > Dear All: > > I don't know my case.struct failed to be run with "init_lapw", could you > please take a look of the attached file and give me some ideas about how > to fix my case.struct file? > > Thanks! > > Pacholite (Hawthorne) > P LATTICE,NONEQUIV. ATOMS:13 15 C2/c > MODE OF CALC=RELA > 18.778216 19.679616 29.630917 90.000000142.442600 90.000000 > Atom= -1: X=0.17281000 Y=0.12590000 Z=0.71803000 > MULT= 1 ISPLIT= 8 > Al NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 13.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -2: X=0.18750000 Y=0.17360000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -3: X=0.18750000 Y=0.56940000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -4: X=0.31460000 Y=0.12740000 Z=0.62520000 > MULT= 1 ISPLIT= 8 > Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -5: X=0.02710000 Y=0.99910000 Z=0.19380000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -6: X=0.12995000 Y=0.99070000 Z=0.36130000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -7: X=0.15725000 Y=0.11380000 Z=0.57470000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -8: X=0.18960000 Y=0.14300000 Z=0.86440000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -9: X=0.09910000 Y=0.25050000 Z=0.30210000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-10: X=0.99540000 Y=0.25300000 Z=0.12490000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-11: X=0.19650000 Y=0.37530000 Z=0.42790000 > MULT= 1 ISPLIT= 8 > O NPT= 781 R0=0.00010000 RMT= 1.5000 Z: 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-12: X=0.17550000 Y=0.37100000 Z=0.35100000 > MULT= 1 ISPLIT= 8 > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-13: X=0.23050000 Y=0.36000000 Z=0.48800000 > MULT= 1 ISPLIT= 8 > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 0 SYMMETRY OPERATIONS: > > - ---------------------------- Georg Madsen Dept. of Inorganic Chemistry University of Aarhus DK-8000 Århus C Denmark - ---------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 11:05:48 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: BROYD mixing parameter ==== Peter Blaha submitted the following contribution: ==== > How the BROYD mixing scheme works? > I have made an scf-cycle, it gave such charge distances: > :DIS : CHARGE DISTANCE 0.0005600 > > When I looked at mixing parameter used, I saw that it's rather low > as compared to the parameter given in case.inm (0.40) and equal in all > cycles: > BROYD MIXING SCHEME WITH 0.182 > Why it is not larger, especially in the first case? And why it has the > same magnitude in both cases? I thought it should depend on the :DIS value. Yes, it depends on :DIS, but your :DIS values are too small to have any effect. Besides that, the mixing depends on the number of (heavier) atoms in your cell and is reduced automatically the more atoms you have. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 08:39:45 -0600 (CST) From: Bing Zhou Subject: [WIEN]: case.struct file ==== Bing Zhou submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Dear All: I don't know my case.struct failed to be run with "init_lapw", could you please take a look of the attached file and give me some ideas about how to fix my case.struct file? Thanks! Pacholite (Hawthorne) P LATTICE,NONEQUIV. ATOMS:13 15 C2/c MODE OF CALC=RELA 18.778216 19.679616 29.630917 90.000000142.442600 90.000000 Atom= -1: X=0.17281000 Y=0.12590000 Z=0.71803000 MULT= 1 ISPLIT= 8 Al NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 13.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -2: X=0.18750000 Y=0.17360000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -3: X=0.18750000 Y=0.56940000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -4: X=0.31460000 Y=0.12740000 Z=0.62520000 MULT= 1 ISPLIT= 8 Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -5: X=0.02710000 Y=0.99910000 Z=0.19380000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -6: X=0.12995000 Y=0.99070000 Z=0.36130000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -7: X=0.15725000 Y=0.11380000 Z=0.57470000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -8: X=0.18960000 Y=0.14300000 Z=0.86440000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom= -9: X=0.09910000 Y=0.25050000 Z=0.30210000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-10: X=0.99540000 Y=0.25300000 Z=0.12490000 MULT= 1 ISPLIT= 8 F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-11: X=0.19650000 Y=0.37530000 Z=0.42790000 MULT= 1 ISPLIT= 8 O NPT= 781 R0=0.00010000 RMT= 1.5000 Z: 8.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-12: X=0.17550000 Y=0.37100000 Z=0.35100000 MULT= 1 ISPLIT= 8 H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 Atom=-13: X=0.23050000 Y=0.36000000 Z=0.48800000 MULT= 1 ISPLIT= 8 H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0 SYMMETRY OPERATIONS: - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="pachnolite-new.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="pachnolite-new.struct" UGFjaG9saXRlIChIYXd0aG9ybmUpDQpQICAgTEFUVElDRSxOT05FUVVJVi4g QVRPTVM6MTMgICAgICAgICAgICAgICAgICAgICAgIDE1IEMyL2MNCk1PREUg T0YgQ0FMQz1SRUxBDQogMTguNzc4MjE2IDE5LjY3OTYxNiAyOS42MzA5MTcg OTAuMDAwMDAwMTQyLjQ0MjYwMCA5MC4wMDAwMDANCkF0b209IC0xOiBYPTAu MTcyODEwMDAgWT0wLjEyNTkwMDAwIFo9MC43MTgwMzAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpBbCAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuODAwMCAgIFo6IDEzLjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC0yOiBYPTAuMTg3NTAwMDAg WT0wLjE3MzYwMDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAwNTAwMCBSTVQ9ICAgIDEuODAwMCAgIFo6IDIwLjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209IC0zOiBYPTAuMTg3NTAwMDAgWT0wLjU2OTQw MDAwIFo9MC41MDAwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpDYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAwNTAw MCBSTVQ9ICAgIDEuODAwMCAgIFo6IDIwLjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkF0b209IC00OiBYPTAuMzE0NjAwMDAgWT0wLjEyNzQwMDAwIFo9MC42 MjUyMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpOYSAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuODAwMCAgIFo6IDExLjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209 IC01OiBYPTAuMDI3MTAwMDAgWT0wLjk5OTEwMDAwIFo9MC4xOTM4MDAwMA0K ICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAg ICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAg IFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC02OiBYPTAu MTI5OTUwMDAgWT0wLjk5MDcwMDAwIFo9MC4zNjEzMDAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209IC03OiBYPTAuMTU3MjUwMDAg WT0wLjExMzgwMDAwIFo9MC41NzQ3MDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209IC04OiBYPTAuMTg5NjAwMDAgWT0wLjE0MzAw MDAwIFo9MC44NjQ0MDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAw MCBSTVQ9ICAgIDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCkF0b209IC05OiBYPTAuMDk5MTAwMDAgWT0wLjI1MDUwMDAwIFo9MC4z MDIxMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4 DQpGICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAg IDEuMzAwMCAgIFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAw MDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAg ICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAg ICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209 LTEwOiBYPTAuOTk1NDAwMDAgWT0wLjI1MzAwMDAwIFo9MC4xMjQ5MDAwMA0K ICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpGICAgICAg ICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMzAwMCAg IFo6ICA5LjANCiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAw MDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAw MDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAg MC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209LTExOiBYPTAu MTk2NTAwMDAgWT0wLjM3NTMwMDAwIFo9MC40Mjc5MDAwMA0KICAgICAgICAg IE1VTFQ9IDEgICAgICAgICAgSVNQTElUPSA4DQpPICAgICAgICAgIE5QVD0g IDc4MSAgUjA9MC4wMDAxMDAwMCBSTVQ9ICAgIDEuNTAwMCAgIFo6ICA4LjAN CiAgICAgICAgICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4w MDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAw MDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAw IDAuMDAwMDAwMCAxLjAwMDAwMDANCkF0b209LTEyOiBYPTAuMTc1NTAwMDAg WT0wLjM3MTAwMDAwIFo9MC4zNTEwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEg ICAgICAgICAgSVNQTElUPSA4DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9 MC4wMDAxMDAwMCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICAxLjANCiAgICAgICAg ICAgICAgICAgICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQog ICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAw MDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAw MCAxLjAwMDAwMDANCkF0b209LTEzOiBYPTAuMjMwNTAwMDAgWT0wLjM2MDAw MDAwIFo9MC40ODgwMDAwMA0KICAgICAgICAgIE1VTFQ9IDEgICAgICAgICAg SVNQTElUPSA4DQpIICAgICAgICAgIE5QVD0gIDc4MSAgUjA9MC4wMDAxMDAw MCBSTVQ9ICAgIDEuMTAwMCAgIFo6ICAxLjANCiAgICAgICAgICAgICAgICAg ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCiAgIDAgU1lNTUVUUlkgT1BFUkFUSU9OUzoNCg== - ---559023410-1804928587-1039496555=:16285 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="pachnolite-new.inst" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="pachnolite-new.inst" QWwgDQpOZSAyIDUNCjMsLTEsMS4wICBODQozLC0xLDEuMCAgTg0KMywgMSwx LjAgIE4NCjMsIDEsMC4wICBODQpDYSANCkFyIDEgNQ0KNCwtMSwxLjAgIE4N CjQsLTEsMS4wICBODQpDYSANCkFyIDEgNQ0KNCwtMSwxLjAgIE4NCjQsLTEs MS4wICBODQpOYSANCk5lIDEgNQ0KMywtMSwxLjAgIE4NCjMsLTEsMC4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpGIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMS4wICBO DQpPIA0KSGUgMyA1DQoyLC0xLDEuMCAgTg0KMiwtMSwxLjAgIE4NCjIsIDEs MS4wICBODQoyLCAxLDEuMCAgTg0KMiwtMiwyLjAgIE4NCjIsLTIsMC4wICBO DQpIIA0KMSA1DQoxLC0xLDAuOSAgTg0KMSwtMSwwLjEgIE4NCkggDQoxIDUN CjEsLTEsMC45ICBODQoxLC0xLDAuMSAgTg0KKioqKiAgICAgRW5kIG9mIElu cHV0DQoqKioqICAgICBFbmQgb2YgSW5wdXQNCg== - ---559023410-1804928587-1039496555=:16285-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 16:27:22 +0100 (CET) From: =?iso-8859-1?q?sham=20fred?= Subject: [WIEN]: question about electron density input? ==== =?iso-8859-1?q?sham=20fred?= submitted the following contribution: ==== - --0-1159391477-1039534042=:538 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear All: Actually, I would like to consult the procedure for Edit TiC.in5 choose the offered template input file. To select the (100) plane for plotting specify the following input: - -1 -1 0 4 # origin of plot (x,y,z,denominator)-1 3 0 4 # x-end of plot 3 -1 0 4 # y-end of plot3 2 3 # x,y,z number of shells100 100 # number of x and y points, ratio should be # similar to x,y length RHO ANG VAL NODEBUGORTHO for why this choose ,and what is solution for other direction ? and is possible with xcrysden for get input of electron density properties? any suggestions or helps are welcome! thanks - --------------------------------- Soyez solidaire soutenez l’action du Téléthon avec Yahoo! France. Cliquez ici pour faire un don ! - --0-1159391477-1039534042=:538 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Dear All:

Actually, I would like to consult the procedure for

Edit TiC.in5 choose the offered template input file. To select the (100) plane for plotting specify the following input: 

-1 -1 0 4     # origin of plot (x,y,z,denominator)
- -1  3 0 4     # x-end of plot
 3 -1 0 4     # y-end of plot
3 2 3         # x,y,z number of shells
100 100       # number of x and y points, ratio should be  
              # similar to x,y length 
RHO               
ANG VAL NODEBUG
ORTHO

for why this choose ,and what is solution for other direction ? and  is possible with xcrysden for get input of electron density properties?

any suggestions or helps are welcome!

thanks

 


Soyez solidaire soutenez l’action du Téléthon avec Yahoo! France.
Cliquez ici pour faire un don ! - --0-1159391477-1039534042=:538-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 17:01:59 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: question about electron density input? ==== Stefaan Cottenier submitted the following contribution: ==== > Actually, I would like to consult the procedure for > > Edit TiC.in5 choose the offered template input file. To select the (100) > plane for plotting specify the following input: > > -1 -1 0 4 # origin of plot (x,y,z,denominator)-1 3 0 4 # x-end of > plot 3 -1 0 4 # y-end of plot3 2 3 # x,y,z number of shells100 > 100 # number of x and y points, ratio should be # > similar to x,y length RHO ANG VAL NODEBUGORTHO > > for why this choose ,and what is solution for other direction ? and is > possible with xcrysden for get input of electron density properties? I think you better read the section 8.6 on lapw5 in the usersguide first. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 19:05:13 +0200 From: "B. Yanchitsky" Subject: Re: [WIEN]: case.struct file ==== "B. Yanchitsky" submitted the following contribution: ==== Dear Bing, This seems to be a bug in symmetry. Because your structure is triclinic (not monoclinic!) and symmetry is unable to determine point groups for atoms. Note also, that there exists an overlap of MT's. ps Georg gave you some trick how to convert monoclinic C-base centered with unique axis b to monoclinic B-base centered with unique axis c. But it seems that the problem is not related to this point, because the structure is triclinic. Regards, Bogdan Yanchitsky Bing Zhou wrote: > > Dear All: > > I don't know my case.struct failed to be run with "init_lapw", could you > please take a look of the attached file and give me some ideas about how > to fix my case.struct file? > > Thanks! > > Pacholite (Hawthorne) > P LATTICE,NONEQUIV. ATOMS:13 15 C2/c > MODE OF CALC=RELA > 18.778216 19.679616 29.630917 90.000000142.442600 90.000000 > Atom= -1: X=0.17281000 Y=0.12590000 Z=0.71803000 > MULT= 1 ISPLIT= 8 > Al NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 13.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -2: X=0.18750000 Y=0.17360000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -3: X=0.18750000 Y=0.56940000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -4: X=0.31460000 Y=0.12740000 Z=0.62520000 > MULT= 1 ISPLIT= 8 > Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -5: X=0.02710000 Y=0.99910000 Z=0.19380000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -6: X=0.12995000 Y=0.99070000 Z=0.36130000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -7: X=0.15725000 Y=0.11380000 Z=0.57470000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -8: X=0.18960000 Y=0.14300000 Z=0.86440000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom= -9: X=0.09910000 Y=0.25050000 Z=0.30210000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-10: X=0.99540000 Y=0.25300000 Z=0.12490000 > MULT= 1 ISPLIT= 8 > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-11: X=0.19650000 Y=0.37530000 Z=0.42790000 > MULT= 1 ISPLIT= 8 > O NPT= 781 R0=0.00010000 RMT= 1.5000 Z: 8.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-12: X=0.17550000 Y=0.37100000 Z=0.35100000 > MULT= 1 ISPLIT= 8 > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > Atom=-13: X=0.23050000 Y=0.36000000 Z=0.48800000 > MULT= 1 ISPLIT= 8 > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 0 SYMMETRY OPERATIONS: > > -------------------------------------------------------------------------------------------------------------------------------- > Name: pachnolite-new.struct > pachnolite-new.struct Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 > > Name: pachnolite-new.inst > pachnolite-new.inst Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 12:48:28 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear peter thanx 1) If I understand your suggestion correctly, to use the lapw0/1/2_mpi scripts for large systems(having large number of atoms but small number of k-points say 1 or 2 ), I need to use run(sp)_lapw -p in the batch job script. but this is the same command used for k-point parallelization batch job run. how does the run(sp)_lapw -p command knows which script to call whether lapw0/1/2_mpi OR lapw0/1/2_para? In short, what could be the command for running mpi scripts (and not para scripts) in the batch job script using load leveler? 2) Here on SP4, the batch queue jobs are always scheduled using loadleveler, so one can not avoid using loadleveler for batch queue jobs. Your second suggestion seems to be promising(although less efficient) until some other w2k users sugget a way out of this problem. With your second suggestion it means, If I have 2 k-point then I put only 1 k-point in the .machines file and once for this k-point(with tasks_per_node = number of processors) has finished the job, it will automatically go for the 2nd k-point with the same number of processors. am I right? 3) about volume/internal parameter optimization: If I have set of case.struct files for volume optimization generated by the script opitmize and wish to run these struct files using optimize.job shell-script without having any previous scf results to start with, then for the first struct file, and first iterataion would be calling "MIXER" and from second iteration onwards, the scf cycle starts and it would be same procedure for all struct files, ie the first iteration for each struct file would be calling the "MIXER" and renormalizing the interstitial charge density (if it is available from the previous run). am I right? Also Is the order of switches important in the following: ie run(sp)_lapw -p -ec 0.0000001 -renorm OR run(sp)_lapw -ec 0.00000001 -renorm -p do the same job? regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 14:54:19 -0600 (CST) From: Bing Zhou Subject: [WIEN]: case.struct file ==== Bing Zhou submitted the following contribution: ==== Dear Bogdan: Good to hear from you agian and thank for your kind help! Originally I used the structure data from Hawthorne (F. Hawthorne et al, 1983, Canadian Mineralogist, p.561-566) for pachnolite, however, WIEN2k and WIEN97 could not recognize the space group F2/d (a=12.117, b=10.414, c=15.690, beta=90.37). Both the papers of Hawthorne (F. Hawthorn et al., 1983) and Adhikesavalu (D. Adhikesavalu et al., Canadian Journal of Chemistry, Vol.63, 1985, p.3322-3327) argued pachnolite was in monoclinic symmetry. Adhikesavalu et al. (1985, p.3325) expressed that Hawthorne et al (1983) adopted for its description the F2/d setting of C2/c by the following relationship: a(F)=2a(C)+c(C) b(F)=b(C) C(F)=c(C) Therefore, I transformed the F2/d space group to C2/c for pachnolite. I calculated the new a, b, c and beta for C2/c space group from the geometry as 9.939, 10.414, 15.68 and 142.4426. I also transformed all the atom coordinates in the F2/d unit cell to C2/c using the following matrix: 2 0 1 0 1 0 0 0 1 That is how I got the pachnolite.struct file. I list the original F2/d unit cell data from Hawthorne (F. Hawthorne, 1983) as following: Space Group: F2/d a=12.117, b=10.414, c=15.68, beta=90.37 Atoms x y z Al 0.34562 0.1259 0.37421 Ca1 3/8 0.1736 1/8 Ca2 3/8 0.5694 1/8 Na 0.6292 0.1274 -0.0040 F1 0.0542 -0.0009 0.1396 F2 0.2599 -0.0093 0.1014 F3 0.3145 0.1138 0.2602 F4 0.3792 0.1430 0.4852 F5 0.1982 0.2505 0.1039 F6 -0.0092 0.2530 0.134 O 0.3930 0.3753 0.0349 H1 0.351 0.371 -0.000 H2 0.461 0.360 0.027 As the result, I got the structure data for new C2/c group as the following: Space Group: C2/c a=9.939, b=10.414, c=16.680, beta=142.4426 Atoms x y z Al 0.17281 0.1259 0.91803 Ca1 0.1875 0.1376 0.5 Ca2 0.1875 0.5694 0.5 Na 0.3146 0.1274 0.6252 F1 0.0271 -0.0009 0.1938 F2 0.12995 -0.0093 0.3613 F3 0.15725 0.1138 0.5747 F4 0.1896 0.1430 0.8644 F5 0.0991 0.2505 0.3021 F6 -0.0046 0.2530 0.1249 O 0.1965 0.3753 0.4279 H1 0.1755 0.371 0.351 H2 0.2305 0.360 0.488 So, could you please help me out and let me know how to work out the proper pachnolite.struct file from the original F2/d data? Looking forward to hearing from you, thanks! Best wishes! On Tue, 10 Dec 2002, B. Yanchitsky wrote: > ==== > "B. Yanchitsky" > submitted the following contribution: > ==== > > Dear Bing, > > This seems to be a bug in symmetry. Because your structure is triclinic > (not monoclinic!) and symmetry is unable to determine point groups > for atoms. Note also, that there exists an overlap of MT's. > > ps > Georg gave you some trick how to convert monoclinic C-base centered > with unique axis b to monoclinic B-base centered with unique axis c. > But it seems that the problem is not related to this > point, because the structure is triclinic. > > Regards, > Bogdan Yanchitsky > > Bing Zhou wrote: > > > > Dear All: > > > > I don't know my case.struct failed to be run with "init_lapw", could you > > please take a look of the attached file and give me some ideas about how > > to fix my case.struct file? > > > > Thanks! > > > > Pacholite (Hawthorne) > > P LATTICE,NONEQUIV. ATOMS:13 15 C2/c > > MODE OF CALC=RELA > > 18.778216 19.679616 29.630917 90.000000142.442600 90.000000 > > Atom= -1: X=0.17281000 Y=0.12590000 Z=0.71803000 > > MULT= 1 ISPLIT= 8 > > Al NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 13.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -2: X=0.18750000 Y=0.17360000 Z=0.50000000 > > MULT= 1 ISPLIT= 8 > > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -3: X=0.18750000 Y=0.56940000 Z=0.50000000 > > MULT= 1 ISPLIT= 8 > > Ca NPT= 781 R0=0.00005000 RMT= 1.8000 Z: 20.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -4: X=0.31460000 Y=0.12740000 Z=0.62520000 > > MULT= 1 ISPLIT= 8 > > Na NPT= 781 R0=0.00010000 RMT= 1.8000 Z: 11.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -5: X=0.02710000 Y=0.99910000 Z=0.19380000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -6: X=0.12995000 Y=0.99070000 Z=0.36130000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -7: X=0.15725000 Y=0.11380000 Z=0.57470000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -8: X=0.18960000 Y=0.14300000 Z=0.86440000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom= -9: X=0.09910000 Y=0.25050000 Z=0.30210000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom=-10: X=0.99540000 Y=0.25300000 Z=0.12490000 > > MULT= 1 ISPLIT= 8 > > F NPT= 781 R0=0.00010000 RMT= 1.3000 Z: 9.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom=-11: X=0.19650000 Y=0.37530000 Z=0.42790000 > > MULT= 1 ISPLIT= 8 > > O NPT= 781 R0=0.00010000 RMT= 1.5000 Z: 8.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom=-12: X=0.17550000 Y=0.37100000 Z=0.35100000 > > MULT= 1 ISPLIT= 8 > > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > Atom=-13: X=0.23050000 Y=0.36000000 Z=0.48800000 > > MULT= 1 ISPLIT= 8 > > H NPT= 781 R0=0.00010000 RMT= 1.1000 Z: 1.0 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > 0 SYMMETRY OPERATIONS: > > > > -------------------------------------------------------------------------------------------------------------------------------- > > Name: pachnolite-new.struct > > pachnolite-new.struct Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > > > > Name: pachnolite-new.inst > > pachnolite-new.inst Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 10 Dec 2002 20:58:40 -0800 (PST) From: hamid salehi Subject: Re: [WIEN]: question about electron density input? ==== hamid salehi submitted the following contribution: ==== Dear sir You have select the (100) plane for plotting of Flowing. 0 0 0 1 0 1 0 1 0 0 1 1 best wishes - --- sham fred wrote: > > Dear All: > > Actually, I would like to consult the procedure for > > Edit TiC.in5 choose the offered template input file. > To select the (100) plane for plotting specify the > following input: > > -1 -1 0 4 # origin of plot (x,y,z,denominator)-1 > 3 0 4 # x-end of plot 3 -1 0 4 # y-end of > plot3 2 3 # x,y,z number of shells100 100 > # number of x and y points, ratio should be > # similar to x,y length RHO > ANG VAL NODEBUGORTHO > > for why this choose ,and what is solution for other > direction ? and is possible with xcrysden for get > input of electron density properties? > > any suggestions or helps are welcome! > > thanks > > > > > > --------------------------------- > Soyez solidaire soutenez l’action du Téléthon avec > Yahoo! France. > Cliquez ici pour faire un don ! ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 10:28:22 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: MPI ==== Peter Blaha submitted the following contribution: ==== > 1) If I understand your suggestion correctly, to use the lapw0/1/2_mpi > scripts for large systems(having large number of atoms but small > number of k-points say 1 or 2 ), I need to > use run(sp)_lapw -p in the batch job script. > > but this is the same command used for k-point parallelization batch job > run. how does the run(sp)_lapw -p command knows which script to call > whether lapw0/1/2_mpi OR lapw0/1/2_para? from the .machines file!!! If it has lines 1:host 1:host it does k-point parallelization, but with 1:host:1 host:1 it does mpi-parallelization and calls the poe command automatically. > 2) Here on SP4, the batch queue jobs are always scheduled using > loadleveler, so one can not avoid using loadleveler for batch queue jobs. > Your second suggestion seems to be promising(although less efficient) > until some other w2k users sugget a way out of this problem. With your > second suggestion it means, If I have 2 k-point then I put only > 1 k-point in the .machines file and once for this k-point(with > tasks_per_node = number of processors) has finished the job, it will > automatically go for the 2nd k-point with the same number of processors. > am I right? Yes you are right. > > 3) about volume/internal parameter optimization: > > If I have set of case.struct files for volume optimization generated by > the script opitmize and wish to run these struct files using optimize.job > shell-script without having any previous scf results to start with, then > for the first struct file, and first iterataion would be calling "MIXER" > and from second iteration onwards, the scf cycle starts and it would be > same procedure for all struct files, ie the first iteration for each > struct file would be calling the "MIXER" and renormalizing the > interstitial charge density (if it is available from the previous run). > am I right? One cannot give a unique answer to this. Sometimes it is better to start with an existing clmsum file (and renormalize it, although this does not help too much in some cases), while sometimes it is better to start with a clmsum file generated by x dstart (-c) for the actual struct file. > Also Is the order of switches important in the following: > > ie > > run(sp)_lapw -p -ec 0.0000001 -renorm > > OR > > run(sp)_lapw -ec 0.00000001 -renorm -p > > do the same job? Yes it does the same job, BUT: - -ec 0.00000001 !!!! We calculate E-total only up to 6 figures after the comma!!! Even -ec 0.000001 is usually not possible (for large cells) and not at all necessary. E.g.: A volume optimization changes E-tot by several 10 or even 100 mRy, so convergence up to 0.0001 or maybe 0.00001 is completely sufficient. Usually you can rely on the WIEN2k default parameters unless you are getting more experienced. PS: Your question about volume optimization brings me to another point: It is by far more efficient to run each volume using "k-parallel" instead of "mpi-parallel" and do all volumes simultaneously!!! (Each one in a different subdirectory!! but for convenience having the same name: i.e.: vol1/case vol2/case vol3/case and so on. Only a "force"-minimization (internal coordinates) needs to be done sequentially. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 10:44:18 +0000 From: Paula Subject: [WIEN]: segmentation fault ==== Paula submitted the following contribution: ==== - --=====================_6349963==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Dear wienusers, I get a segmentation fault during lapw2 whenever l increase Emax value to 4.0. If l leave it at the default value of 1.5 then lapw2 runs okay. However when l try to run ELNES, specifically the x tetra part, then l get another segmentation fault. This occurs even when l leave the original default values. I have previously run the same .struct file on wien97 and found good results. Does anyone know why a segmentation fault is occurring now? Thanks for your advice, Paula Paula Harkins Room A3-31C - Materials Chemistry Group Department of Chemistry University of Glasgow Glasgow G12 8QQ Scotland, UK 0141 330 4941 - --=====================_6349963==_ Content-Type: application/octet-stream; name="batio3.in1c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="batio3.in1c" V0ZGSUwgICAgICAgIChXRlBSSSwgU1VQV0YpCiAgNy4wMCAgICAgICAxMCAgICA0IChSLU1UKkst TUFYOyBNQVggTCBJTiBXRiwgVi1OTVQKICAwLjMwICAgIDQgIDAgICAgICAoR0xPQkFMIEUtUEFS QU1FVEVSIFdJVEggbiBPVEhFUiBDSE9JQ0VTLCBnbG9iYWwgQVBXL0xBUFcpCiAwICAgLTIuMTcg ICAgICAwLjAxMCBDT05UIDEKIDAgICAgMC4zMCAgICAgIDAuMDAwIENPTlQgMQogMSAgIC0xLjAz ICAgICAgMC4wMTAgQ09OVCAxCiAxICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEKICAwLjMwICAg IDUgIDAgICAgICAoR0xPQkFMIEUtUEFSQU1FVEVSIFdJVEggbiBPVEhFUiBDSE9JQ0VTLCBnbG9i YWwgQVBXL0xBUFcpCiAwICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEKIDAgICAtNC4zNSAgICAg IDAuMDA1IFNUT1AgMQogMSAgIC0yLjU4ICAgICAgMC4wMTAgQ09OVCAxCiAxICAgIDAuMzAgICAg ICAwLjAwMCBDT05UIDEKIDIgICAgMC4zMCAgICAgIDAuMDEwIENPTlQgMQogIDAuMzAgICAgMyAg MCAgICAgIChHTE9CQUwgRS1QQVJBTUVURVIgV0lUSCBuIE9USEVSIENIT0lDRVMsIGdsb2JhbCBB UFcvTEFQVykKIDAgICAtMS41NSAgICAgIDAuMDEwIENPTlQgMQogMCAgICAwLjMwICAgICAgMC4w MDAgQ09OVCAxCiAxICAgIDAuMzAgICAgICAwLjAwMCBDT05UIDEKICAwLjMwICAgIDMgIDAgICAg ICAoR0xPQkFMIEUtUEFSQU1FVEVSIFdJVEggbiBPVEhFUiBDSE9JQ0VTLCBnbG9iYWwgQVBXL0xB UFcpCiAwICAgLTEuNTUgICAgICAwLjAxMCBDT05UIDEKIDAgICAgMC4zMCAgICAgIDAuMDAwIENP TlQgMQogMSAgICAwLjMwICAgICAgMC4wMDAgQ09OVCAxCkstVkVDVE9SUyBGUk9NIFVOSVQ6NCAg IC03LjAgICAgICAgMS41ICAgICAgZW1pbi9lbWF4IHdpbmRvdwo= - --=====================_6349963==_-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 07:43:00 -0800 (PST) From: xin gao Subject: [WIEN]: about k-point parallel ==== xin gao submitted the following contribution: ==== - --0-1045039590-1039621380=:11706 Content-Type: text/plain; charset=us-ascii Dear wien2k user, The following total energy of the same system was calculated with the same parameters (RKmax, Gmax, et.al) by using k-point parallelization version and serial version of WIEN2k respectively. for k-point parallelization version: :ENE : ********** TOTAL ENERGY IN Ry = -3848.486870 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129313 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486873 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129309 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486869 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486871 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486871 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486873 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486873 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129311 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129312 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486874 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486874 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486882 :ENE : ********** TOTAL ENERGY IN Ry = -3848.486874 for serial version: :ENE : ********** TOTAL ENERGY IN Ry = -6828.129306 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129299 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129307 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129296 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129295 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129297 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129295 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129314 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129313 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129316 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129306 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129316 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129316 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129313 :ENE : ********** TOTAL ENERGY IN Ry = -6828.129316 I had checked all the energies outputed in case.scf (there seems no double count term), i.e., the sum of eigenvalues, energies of core states, both of them are nearly equal, but I don't know why the total energies are not equal. Had you ever met this problem, and how did you deal with it? I am looking forward for your kindly replying. Thank you very much. Best regards, - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1045039590-1039621380=:11706 Content-Type: text/html; charset=us-ascii

Dear wien2k user,

The following total energy of the same system was calculated with the same parameters (RKmax, Gmax, et.al) by using k-point parallelization version and serial version of WIEN2k respectively.

for k-point parallelization version: 

:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486870
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129313
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486873
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129309
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486869
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486871
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486871
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486873
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486873
:ENE  : ********** TOTAL ENERGY IN Ry =  &nb! sp;     -6828.129311
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129312
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486874
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486874
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486882
:ENE  : ********** TOTAL ENERGY IN Ry =        -3848.486874

for serial version:

:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129306
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129299
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129307
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129296
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129295
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129297
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129295
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129314
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129313
:ENE  : ********** TOTAL ENERGY IN Ry =  &nb! sp;     -6828.129316
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129306
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129316
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129316
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129313
:ENE  : ********** TOTAL ENERGY IN Ry =        -6828.129316

I had checked all the energies outputed in case.scf (there seems no double count term), i.e., the sum of eigenvalues, energies of core states, both of them are nearly equal, but I don't know why the total energies are not equal.

Had you ever met this problem, and how did you deal with it? I am looking forward for your kindly replying. Thank you very much.

Best regards,


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1045039590-1039621380=:11706-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 15:40:12 -0600 (CST) From: Bing Zhou Subject: [WIEN]: SELECT error ==== Bing Zhou submitted the following contribution: ==== Dear all: When I run "run_lapw" for my mineral of pachnolite (in monoclinic symmetry), the calcualtion was crashed in the first lapw1 with message "SELECT error", and the lapw1.error contains the following information: 'SELECT' - no energy limits found for L= 0 'SELECT' - E-bottom -5.97500 E-top -200.00000 How can I fix it? Looking forward to hearing from you, thank you in advance! Best wishes! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 15:17:03 -0800 (PST) From: yanming Ma Subject: [WIEN]: QTL-B = 1220.43 ==== yanming Ma submitted the following contribution: ==== - --0-2095760556-1039648623=:24630 Content-Type: text/plain; charset=us-ascii Dear WIEN2k users, When I do the calculation for CsBiTe including SO coupling, I try to follow the following procedure init_lapw--runsp_lapw--initso_lapw--runsp_lapw -so But When I do runsp_lapw, the warning of OTL-B=1220.43 occurred. There are two possibility for this warning as in userguide: (1)atoms with very different atomic sphere radii. In my case, the atomic sphere radii are 2.8, 2.8 ,and 3.2 for Te, Bi, and Cs respectively. I choose the energy cut off to seperate the core and valance electrons as -7 Ryd. I have already checked the charge leakage for Te, Bi, and Cs. They are 0.0002, 0.0006, 0.0000002, respectively. (2)one doesn't use a proper set of local orbitals. In my case, the case.in1 file is as follows WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT ) 0.30 5 0 (Bi) 2 -1.54 0.010 CONT 1 2 0.30 0.000 CONT 1 0 -0.73 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 0.30 5 0 (Cs) 2 0.30 0.000 CONT 1 2 -5.08 0.005 STOP 1 0 -1.66 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 0.30 5 0 (Te) 2 -2.70 0.010 CONT 1 2 0.30 0.000 CONT 1 0 -0.84 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 K-VECTORS FROM UNIT:4 -7.0 1.5 emin/emax window I know I can use "run_lapw -in1new 1" to choose the proper local orbitals. But, in my such big case (one iteration will cost 4 days using 9 cpus), it is difficult to do many tries. So can you kindly help me to analyz what is the possible reason for the large QTL-B values? Any comments are welcom. Thanks in advance. Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-2095760556-1039648623=:24630 Content-Type: text/html; charset=us-ascii

Dear WIEN2k  users,

When I do the calculation for CsBiTe including SO coupling, I try to follow the following procedure

init_lapw--runsp_lapw--initso_lapw--runsp_lapw -so

But When I do runsp_lapw, the warning of OTL-B=1220.43 occurred.
There are two possibility for this warning as in userguide:

(1)atoms with very different atomic sphere radii.
In my case, the atomic sphere radii are 2.8, 2.8 ,and 3.2 for Te, Bi, and Cs respectively.
I choose the energy cut off to seperate the core and valance electrons as -7 Ryd.
I have already checked the charge leakage for Te, Bi, and Cs.
They are 0.0002, 0.0006, 0.0000002, respectively.

(2)one doesn't use a proper set of local orbitals.
In my case, the case.in1 file is as follows
WFFIL        (WFPRI, SUPWF)
7.00       10    4 (R-MT*K-MAX; MAX L IN WF, V-NMT )

0.30    5  0   (Bi)
2   -1.54     0.010 CONT 1
2    0.30      0.000 CONT 1
0   -0.73      0.010 CONT 1
0    0.30      0.000 CONT 1
1    0.30      0.000 CONT 1

0.30    5  0   (Cs)
2    0.30      0.000 CONT 1
2   -5.08      0.005 STOP 1
0   -1.66      0.010 CONT 1
0    0.30      0.000 CONT 1
1    0.30      0.000 CONT 1

0.30    5  0   (Te)
2   -2.70      0.010 CONT 1
2    0.30      0.000 CONT 1
0   -0.84      0.010 CONT 1
0    0.30      0.000 CONT 1
1    0.30      0.000 CONT 1
K-VECTORS FROM UNIT:4   -7.0       1.5      emin/emax window

I know I can use "run_lapw -in1new 1" to choose the proper local orbitals.
But, in my such big case (one iteration will cost 4 days using 9 cpus),
it is difficult to do many tries. So can you kindly help me to analyz what is the possible reason for the large QTL-B values? Any comments are welcom.

Thanks in advance.



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-2095760556-1039648623=:24630-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 11 Dec 2002 18:36:03 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Peter thanx 1) I try your suggestion for MPI-parallel run and get back to you by tomorrow. 2)about spin-orbit run: what could be the run command to get an orbital moment on an atom with SOC when it is included a) non-selfconsistently i.e after a spinpolarized scf run without SOC, and assuming that proper case.inso file is created using initso_lapw script. OR b) selfconsistenly with spin polarization, ie from scratch(assuming that proper case.inso file is already created using initso_lapw script). Your reply in the mailing list on 4th Nov 2002 says lapwdm calculates orbital moments but it is not called during runsp - -so.one needs the updated version to use the switch -dm for this. I downloaded the entire w2k code on Nov 19(which is much after 4th Nov).does it include -dm switch then? if yes, is runsp -so -dm for including the SOC selfconsistently? using this for nonselfconsistent inclusion will do by default 20 iteration? so one need to force it to have only one iteration ie runsp -so -dm -i 1 . am I right? 3) I am not clear about doing volume optimization simultaneously using k-point parallelization. can you be little more descriptive? for a given volume, scf cycle is performed and then it is repeated for all volumes in optimized.job script ie volume optimization is done sequentially with scf cycle in k-point parallelization for each volume. how to launch simultaneous volume optimization using the same optimization file? is not we need as many machines files as there are subdirectories ie vol1 vol2 etc. regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 08:09:09 +0100 From: Torsten Andersen Subject: Re: [WIEN]: SELECT error ==== Torsten Andersen submitted the following contribution: ==== Dear Bing, this is a FAQ. Read the website documentation, please. And scan the mailing list digest if the FAQ does not help you. This you can do by downloading the digest and use an editor (or grep) to search it. There are tons of mail with this subject. Best regards, Torsten. Bing Zhou wrote: >==== >Bing Zhou >submitted the following contribution: >==== > >Dear all: > >When I run "run_lapw" for my mineral of pachnolite (in monoclinic >symmetry), the calcualtion was crashed in the first lapw1 with message >"SELECT error", and the lapw1.error contains the following information: > >'SELECT' - no energy limits found for L= 0 >'SELECT' - E-bottom -5.97500 E-top -200.00000 > >How can I fix it? > >Looking forward to hearing from you, thank you in advance! > >Best wishes! > > > >Bing Zhou >Dept. of Geological Sc. >The Univ. of Manitoba >Canada R3T 2N2 >Tel: (204)474-8395 > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 09:17:03 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: about k-point parallel ==== Peter Blaha submitted the following contribution: ==== > The following total energy of the same system was calculated with the same parameters (RKmax, Gmax, et.al) by using k-point parallelization version and serial version of WIEN2k respectively. > > for k-point parallelization version: > > :ENE : ********** TOTAL ENERGY IN Ry = -3848.486870 <--- > :ENE : ********** TOTAL ENERGY IN Ry = -6828.129313 <--- > :ENE : ********** TOTAL ENERGY IN Ry = -3848.486873 <--- > :ENE : ********** TOTAL ENERGY IN Ry = -6828.129309 > :ENE : ********** TOTAL ENERGY IN Ry = -3848.486869 > > for serial version: > > :ENE : ********** TOTAL ENERGY IN Ry = -6828.129306 > :ENE : ********** TOTAL ENERGY IN Ry = -6828.129299 If you see jumps like this the problem is always the same: You must save_lapw save_name your calculations before you start/continue with the next one. If in the scf file an iteration number xx appears twice, the calculated E-tot will be wrong. PS: In the last version of WIEN2k, a warning should be printed if this occurs. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 10:31:12 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: QTL-B = 1220.43 ==== Peter Blaha submitted the following contribution: ==== > But When I do runsp_lapw, the warning of OTL-B=1220.43 occurred. When you see this warning, have a look into case.output2. For instance search for 1220 and find out for which atom/state these QTL-Bs occur. > In my case, the atomic sphere radii are 2.8, 2.8 ,and 3.2 for Te, Bi, and Cs respectively. I would not have chosen 3.2 for Cs, but kept it also at 2.8 > 0.30 5 0 (Cs) > 2 0.30 0.000 CONT 1 > 2 -5.08 0.005 STOP 1 > 0 -1.66 0.010 CONT 1 > 0 0.30 0.000 CONT 1 > 1 0.30 0.000 CONT 1 Is it really the default input ? I would have guessed that Cs has p-semicore states and thus has also an lo for l=1 (But I hav'n't checked it myself)? So my guess is that Cs p states produce this QTL-B (but I could be wrong) Also: Where is your EF ? Only than one can estimate if the energy parameters are ok or need to be changed about 0.2 Ry below EF Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 10:42:11 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: segmentation fault ==== Peter Blaha submitted the following contribution: ==== > I get a segmentation fault during lapw2 whenever l increase Emax value to > 4.0. If l leave it at the default value of 1.5 then lapw2 runs okay. Enough memory and swap space configured ? Check the *help* files for '****'. Maybe for those high energies some ghost states appear? > However when l try to run ELNES, specifically the x tetra part, then l get > another segmentation fault. This occurs even when l leave the original > default values. I have previously run the same .struct file on wien97 and > found good results. Does anyone know why a segmentation fault is occurring now? DO you use the latest version of lapw2 ? We had some problems for elnes calculations, but they have been fixed some weeks ago (see www.wien2k.at). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 16:54:00 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: SELECT error ==== "Saeid Jalali" submitted the following contribution: ==== > When I run "run_lapw" for my mineral of pachnolite (in monoclinic > symmetry), the calcualtion was crashed in the first lapw1 with message > "SELECT error", and the lapw1.error contains the following information: > > 'SELECT' - no energy limits found for L= 0 > 'SELECT' - E-bottom -5.97500 E-top -200.00000 This error in FIRST cycle is not described in FAQ so that reducing mixing factor from 0.4 is not a cure. Also one cannot get a chance to check linearization, as it needs at least one preformed cycle. In addition no heavy elements are there in the struct file of Pachnolite with the formula NaCaAlF6·(H2O), in order to one can be convinced about changing the default E-paparemetr. > How can I fix it? I think your struct file is wrong. The output of sgroup program is empty employing your structure file, which is an indication that they are not consistent. The space group of Pachnolite is F2/d. This space group can be converted to B2/b or C2/c with the # of 15. Only B2/b is included in the struct generator of WIEN2K. Thus, one possible way is to convert F2/d to B2/b and then use the facility of WIEN2K, which the conversion would be done carefully. Another (more suitable) way was described by Madsen, which appears that one needs more description for more realization. I see you claim that, your struct file works well employing wien97 code! I don't access to wien97, but I am interested to know how it is possible. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 22:50:31 +0800 From: =?gb2312?B?1dQg1r684Q==?= Subject: [none] ==== =?gb2312?B?1dQg1r684Q==?= submitted the following contribution: ==== Dear sir: I have a question when I do "runsp_lapw -p".I want to calculate the magnetic moment of W(tungsten) bulk. So I select the "spin polarize" model during "init_lapw". I use 3000 k-points(there are 100 irreducible k-points), and have 5 nodes. My .machines like this : 20:node13 20:node14 20:node15 20:node16 20:node17 granularity:1 After "runsp_lapw -p", I do "testpara", and get the following information: #################################################### # TESTPARA # ##################################################### Test: LAPW1 in parallel mode (using .machines) Granularity set to 1 Extrafine unset klist: 100 machines: node13 node14 node15 node16 node17 procs: 5 weigh(old): 20 20 20 20 20 sumw: 100 granularity: 1 weigh(new): 20 20 20 20 20 Distribution of k-point (under ideal conditions) will be: 1 : node13(20) 20k 2 : node14(20) 20k 3 : node15(20) 20k 4 : node16(20) 20k 5 : node17(20) 20k furthermore run "testpara1" and get the information like this: ##################################################### # TESTPARA1 # ##################################################### Thu Dec 12 21:43:42 CST 2002 lapw1para is running 100 of 100 (100%) k-points distributed node13: running node14: running node15: running node16: running node17: running But unfortunately when I rlogin to every node(node13,node14,etc), I find these nodes' CPUs are doing noting really! because of the command "top" giving the information like this: CPU states: 0.0% user, 0.1% system, 0.0% nice, 99.8% idle And I get the *.dayfile like this : Calculating wbulk in /home/d0/jzhao/wien/work/wbulk on node0 start (Thu Dec 12 21:24:36 CST 2002) with lapw0 (2/20 to go) > lapw0 -p (21:24:36) starting parallel lapw0 at Thu Dec 12 21:24:36 CST 2002 - -------- running lapw0 in single mode 3.660u 0.090s 0:04.05 92.5% 0+0k 0+0io 2321pf+0w > lapw1 -up -p (21:24:40) starting parallel lapw1 at Thu Dec 12 21:24:41 CST 2002 - -> starting parallel LAPW1 jobs at Thu Dec 12 21:24:41 CST 2002 running LAPW1 in parallel mode (using .machines) 5 number_of_parallel_jobs node13(20) node14(20) node15(20) node16(20) node17(20) Summary of lapw1para: node13 k=20 user=0 wallclock=20 node14 k=20 user=0 wallclock=20 node15 k=20 user=0 wallclock=20 node16 k=20 user=0 wallclock=20 node17 k=20 user=0 wallclock=20 0.220u 0.320s 0:08.12 6.6% 0+0k 0+0io 22048pf+0w > lapw1 -dn -p (21:24:49) starting parallel lapw1 at Thu Dec 12 21:24:49 CST 2002 - -> starting parallel LAPW1 jobs at Thu Dec 12 21:24:49 CST 2002 running LAPW1 in parallel mode (using .machines.help) 5 number_of_parallel_jobs [1] 9780 [2] 9796 [3] 9811 [1] Done ( $remote $machine[$p] ... [4] 9826 [2] Done ( $remote $machine[$p] ... [5] 9841 [3] Done ( $remote $machine[$p] ... [4] - Done ( $remote $machine[$p] ... [5] + Done ( $remote $machine[$p] ... After 10 hours, I find the *.dayfile has nothing different compared with the file 10 hours before! So, I want to know : 1.why it takes me so long time to do "runsp_lapw -p", but get nothing result. 2.during the calculation of "runsp_lapw -p", WIEN2K gave me a information: GETARG: argument index (2) out of range whether it is harmful? Thank you very much in advance. Best regards. J.Zhao 12/12/2002 _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 16:36:56 +0100 From: Stefaan Cottenier Subject: [WIEN]: Re: ==== Stefaan Cottenier submitted the following contribution: ==== > 1.why it takes me so long time to do "runsp_lapw -p", but get nothing > result. Perform this command : 'rlogin node13'. Does it ask you for a password? If yes, then put in your home directory af file with the name .rhosts that contains the lines node13 node14 node15 node16 node17 Now you should be able to rlogin to all of these nodes without a password. I guess that your calculation just is waiting for a password that will never come. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #47 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #48 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Thursday, December 19 2002 Volume 2002 : Number 048 ---------------------------------------------------------------------- Date: Thu, 12 Dec 2002 07:59:56 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: QTL-B = 1220.43 ==== yanming Ma submitted the following contribution: ==== - --0-850918627-1039708796=:71525 Content-Type: text/plain; charset=us-ascii Dear Peter, Thanks very much for your reply. >> 0.30 5 0 (Cs) >> 2 0.30 0.000 CONT 1 >>2 -5.08 0.005 STOP 1 >> 0 -1.66 0.010 CONT 1 >> 0 0.30 0.000 CONT 1 >> 1 0.30 0.000 CONT 1 >Is it really the default input ? I would have guessed that Cs has p-semicore >states and thus has also an lo for l=1 (But I hav'n't checked it myself)? Yes, it is the default input. No semicore is chosen in Cs by default. >So my guess is that Cs p states produce this QTL-B (but I could be wrong) I aslo doubt about Cs, there are 36 electrons in core states 1s2s2p3s3p3d4s4p, while the other 19 electrons 4d5s5p6s are treated as valence electrons, no seimcore states. >Also: Where is your EF ? Only than one can estimate if the energy parameters >are ok or need to be changed about 0.2 Ry below EF The EF is around 0.32 Ryd in my case. So do you mean I should change the energy parameters for s, p, d orbitals from 0.3 to 0.12, But how about the energy values for local orbital? When I check the case.scf file, I also find the following messages 6 eighvalues below the energy -7.0 ( energy cut off in Lstart) From this message, do I need to increase the energy cut off in Lstart? Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-850918627-1039708796=:71525 Content-Type: text/html; charset=us-ascii

Dear Peter,

Thanks very much for your reply.

>> 0.30 5 0 (Cs)
>> 2 0.30 0.000 CONT 1
>>2 -5.08 0.005 STOP 1
>> 0 -1.66 0.010 CONT 1
>> 0 0.30 0.000 CONT 1
>> 1 0.30 0.000 CONT 1

>Is it really the default input ? I would have guessed that Cs has p-semicore
>states and thus has also an lo for l=1 (But I hav'n't checked it myself)?

Yes, it is the default input. No semicore is chosen in Cs by default.


>So my guess is that Cs p states produce this QTL-B (but I could be wrong)
I aslo doubt about Cs, there are 36 electrons in core states 1s2s2p3s3p3d4s4p, while the other 19 electrons 4d5s5p6s are treated as valence electrons, no seimcore states. 


>Also: Where is your EF ? Only than one can estimate if the energy parameters
>are ok or need to be changed about 0.2 Ry below EF

The EF is around 0.32 Ryd in my case. So do you mean I should change the energy parameters for s, p, d orbitals from 0.3 to 0.12, But how about the energy values for local orbital?

When I check the case.scf file, I also find the following messages

6 eighvalues below the energy -7.0 ( energy cut off in Lstart)

From this message, do I need to increase the energy cut off in Lstart?



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-850918627-1039708796=:71525-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 12 Dec 2002 16:15:36 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Peter and other Wieners 1) I tested a unit cell containing 13 atoms with 1 k-point for MPI run. my .machines file: lapw0:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 (where lapw0 is assigned 8 processor and the 1 k-point 8 processors) in the job script for for load leveler the run command was: ../w2k/runsp_lapw -p the case.dayfile is: ______________________________________________________________________________ Calculating GaMo1 in /gpfs/utexas/ph/phaa406/GaMo1 on longhorn5.tacc.utexas.edu start (Thu Dec 12 14:58:23 CST 2002) with lapw0 (20/20 to go) > lapw0 -p (14:58:23) starting parallel lapw0 at Thu Dec 12 14:58:24 CST 2002 - -------- .machine1 : 8 processors longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 - -------- 0.0u 0.1s 0:28 0% 106+682k 0+0io 0pf+0w > lapw1 -c -up -p (14:58:52) starting parallel lapw1 at Thu Dec 12 14:58:52 CST 2002 - -> starting parallel LAPW1 jobs at Thu Dec 12 14:58:52 CST 2002 running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs [1] 38132 ___________________ as you can see, it does not pick up lapw0_mpi(although it runs lapw0 on 8 processors in parallel) and lapw1_mpi(instead it picks lapw1) and says 1 number_of_parallel_jobs? My idea was If MPI-script works for 13 atom unit cell with 1 k-point(although the scf output will not be correct), there will not be any problem for doing a cell with very large number of atoms and 1-2 kpoints(ie small BZ). Is it the correct message in the case.dayfile? is lapw1_mpi is running on 8 processors in parallel using mpi scripts? Pl. let me know. 2) Pl. let me know about my yesterday's query about SOC and simultaneous optimization in k-point parallelization? Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 14:15:37 +0900 From: Li Wang Subject: [WIEN]: Dstart error ==== Li Wang submitted the following contribution: ==== This is a multi-part message in MIME format. - --------------020002030808090606030205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I am calculating a slab with H2 molecule. A error file is created when begining running "x start" in a "Initialize calculation" progress, which only contaion "Error in Dstart" message. The process (dstart) will finish in 1~2 hours. Can you tell me the reason and if I can ignore it? Li Wang Hydrogen Isotope Research Center, Toyama University, 3190 Gofuku, Toyama 930-8555 Japan - --------------020002030808090606030205 Content-Type: text/plain; name="dstart.error" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dstart.error" - --------------020002030808090606030205 Content-Type: text/plain; name="test6.struct" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test6.struct" Wien2k struct file generated by XCrySDen program CXY LATTICE,NONEQUIV. ATOMS 935_Cmm2 MODE OF CALC=NREL unit=bohr 11.451745 16.195213105.000000 90.000000 90.000000 90.000000 ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 8 V 1 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -2: X=0.25000000 Y=0.25000000 Z=0.00000000 MULT= 2 ISPLIT= 8 -2: X=0.75000000 Y=0.25000000 Z=0.00000000 V 2 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -3: X=0.00000000 Y=0.50000000 Z=0.00000000 MULT= 1 ISPLIT= 8 V 3 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -4: X=0.25000000 Y=0.50000000 Z=0.95161951 MULT= 2 ISPLIT= 8 -4: X=0.75000000 Y=0.50000000 Z=0.95161951 V 4 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 1.0000000 0.0000000 0.0000000 ATOM -5: X=0.00000000 Y=0.25000000 Z=0.95161951 MULT= 2 ISPLIT= 8 -5: X=0.00000000 Y=0.75000000 Z=0.95161951 V 5 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 ATOM -6: X=0.00000000 Y=0.50000000 Z=0.90323901 MULT= 1 ISPLIT= 8 V 6 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -7: X=0.25000000 Y=0.75000000 Z=0.90323901 MULT= 2 ISPLIT= 8 -7: X=0.75000000 Y=0.75000000 Z=0.90323901 V 7 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -8: X=0.00000000 Y=0.00000000 Z=0.90323901 MULT= 1 ISPLIT= 8 V 8 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM -9: X=0.00000000 Y=0.90000000 Z=0.00000000 MULT= 2 ISPLIT= 8 -9: X=0.00000000 Y=0.10000000 Z=0.00000000 H 1 NPT= 781 R0=0.00010000 RMT= 0.4561 Z: 1.0 LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 2 1 0 0 0.0000000 0-1 0 0.0000000 0 0 1 0.0000000 3 - -1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 4 - --------------020002030808090606030205-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 08:18:59 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Dstart error ==== Torsten Andersen submitted the following contribution: ==== If the file is still there when dstart finishes (and containing some error message) you can usually not ignore it. But in case.outbutd or case.dayfile, or on your screen there may be further hints as to what went wrong. Best regards, Torsten Andersen. Li Wang wrote: > Dear all, > I am calculating a slab with H2 molecule. A error file is created > when begining running "x start" in a "Initialize calculation" > progress, which only contaion "Error in Dstart" message. > The process (dstart) will finish in 1~2 hours. Can you tell me the > reason and if I can ignore it? > > > Li Wang > Hydrogen Isotope Research Center, > Toyama University, > 3190 Gofuku, > Toyama 930-8555 > Japan > > >------------------------------------------------------------------------ > >Wien2k struct file generated by XCrySDen program >CXY LATTICE,NONEQUIV. ATOMS 935_Cmm2 >MODE OF CALC=NREL unit=bohr > 11.451745 16.195213105.000000 90.000000 90.000000 90.000000 >ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 >V 1 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -2: X=0.25000000 Y=0.25000000 Z=0.00000000 > MULT= 2 ISPLIT= 8 > -2: X=0.75000000 Y=0.25000000 Z=0.00000000 >V 2 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -3: X=0.00000000 Y=0.50000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 >V 3 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -4: X=0.25000000 Y=0.50000000 Z=0.95161951 > MULT= 2 ISPLIT= 8 > -4: X=0.75000000 Y=0.50000000 Z=0.95161951 >V 4 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 >ATOM -5: X=0.00000000 Y=0.25000000 Z=0.95161951 > MULT= 2 ISPLIT= 8 > -5: X=0.00000000 Y=0.75000000 Z=0.95161951 >V 5 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 >ATOM -6: X=0.00000000 Y=0.50000000 Z=0.90323901 > MULT= 1 ISPLIT= 8 >V 6 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -7: X=0.25000000 Y=0.75000000 Z=0.90323901 > MULT= 2 ISPLIT= 8 > -7: X=0.75000000 Y=0.75000000 Z=0.90323901 >V 7 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -8: X=0.00000000 Y=0.00000000 Z=0.90323901 > MULT= 1 ISPLIT= 8 >V 8 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 >LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 >ATOM -9: X=0.00000000 Y=0.90000000 Z=0.00000000 > MULT= 2 ISPLIT= 8 > -9: X=0.00000000 Y=0.10000000 Z=0.00000000 >H 1 NPT= 781 R0=0.00010000 RMT= 0.4561 Z: 1.0 >LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 4 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 >-1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 2 > 1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 3 >-1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 4 > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 11:54:36 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: Dstart error ==== "Saeid Jalali" submitted the following contribution: ==== > I am calculating a slab with H2 molecule. A error file is created > when begining running "x start" in a "Initialize calculation" progress, > which only contaion "Error in Dstart" message. > The process (dstart) will finish in 1~2 hours. Can you tell me the > reason and if I can ignore it? I noticed that the size of your sent dstart.error file is zero byte. This means that x dstart -c was performed with no error. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 09:38:23 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: QTL-B = 1220.43 ==== Peter Blaha submitted the following contribution: ==== > The EF is around 0.32 Ryd in my case. So do you mean I should change the energy parameters for s, p, d orbitals from 0.3 to 0.12, But how about the energy values for local orbital? No, not necessary. > > When I check the case.scf file, I also find the following messages > > 6 eighvalues below the energy -7.0 ( energy cut off in Lstart) Ah !!!! As I expected, you got ghostbands. Increasing of the energy cutoff will not help. Reduce the Cs sphere and start all over again. (You might need to put a Cs-p LO by hand (e.g. at -0.6 Ry) and for security set the p-LAPW to e.g. 1.0 Ry). I checked it, the default input does not give a l=1 LO, because the semicore 5p level is at -0.95 and thus just above the -1.0 Ry criteria). 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 10:07:19 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Dstart error ==== Peter Blaha submitted the following contribution: ==== > I am calculating a slab with H2 molecule. A error file is created > when begining running "x start" in a "Initialize calculation" progress, > which only contaion "Error in Dstart" message. > The process (dstart) will finish in 1~2 hours. Can you tell me the > reason and if I can ignore it? As long as dstart is running, the file dstart.error contains the message you mentioned above. As soon as dstart finishes, this file still exists, but must be empty. If it is NOT empty, you cannot ignore it. H2 with it's small sphere is a difficult task for WIEN. Are you sure your structure is what you want to calculate?? H is in exactly the same surface hight as V ? and leads to exceptional small distances between H and V ? At least your structure is NOT an H2-molecule!! If you really want to do such a structure, you will need to reduce RKMAX from the default (7) to 3-4 (test it?). You also may need a higher GMAX (20-24 ?) for correct forces! If you correct the positions, use larger spheres for both, H and V (if possible). 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 10:23:24 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Dstart error ==== "Kevin Jorissen" submitted the following contribution: ==== This is just the way wien handles its error files. At the beginning of each program (eg dstart), an error file is created containing the line 'error in program'. When the program is able to end succesfully, the file is emptied. But during the execution of the program, there is a non-empty error file. The advantage of this is simple : even if the program crashes in the most spectacular way and has no chance whatsoever to give you any message, there will still be an error message. On the other hand, if the machine would only write an error file in case something does go wrong, it might not be able to do this after all, and you would not know there's something wrong with your calculation. Don't worry, the errorfile will be empty at the end of dstart. Good luck with the calculations. Kevin Jorissen kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Li Wang" To: Sent: Friday, December 13, 2002 6:15 AM Subject: [WIEN]: Dstart error > Dear all, > I am calculating a slab with H2 molecule. A error file is created > when begining running "x start" in a "Initialize calculation" progress, > which only contaion "Error in Dstart" message. > The process (dstart) will finish in 1~2 hours. Can you tell me the > reason and if I can ignore it? > > > Li Wang > Hydrogen Isotope Research Center, > Toyama University, > 3190 Gofuku, > Toyama 930-8555 > Japan > - ---------------------------------------------------------------------------- - ---- > - ---------------------------------------------------------------------------- - ---- > Wien2k struct file generated by XCrySDen program > CXY LATTICE,NONEQUIV. ATOMS 935_Cmm2 > MODE OF CALC=NREL unit=bohr > 11.451745 16.195213105.000000 90.000000 90.000000 90.000000 > ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > V 1 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -2: X=0.25000000 Y=0.25000000 Z=0.00000000 > MULT= 2 ISPLIT= 8 > -2: X=0.75000000 Y=0.25000000 Z=0.00000000 > V 2 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -3: X=0.00000000 Y=0.50000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > V 3 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -4: X=0.25000000 Y=0.50000000 Z=0.95161951 > MULT= 2 ISPLIT= 8 > -4: X=0.75000000 Y=0.50000000 Z=0.95161951 > V 4 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 > ATOM -5: X=0.00000000 Y=0.25000000 Z=0.95161951 > MULT= 2 ISPLIT= 8 > -5: X=0.00000000 Y=0.75000000 Z=0.95161951 > V 5 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > ATOM -6: X=0.00000000 Y=0.50000000 Z=0.90323901 > MULT= 1 ISPLIT= 8 > V 6 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -7: X=0.25000000 Y=0.75000000 Z=0.90323901 > MULT= 2 ISPLIT= 8 > -7: X=0.75000000 Y=0.75000000 Z=0.90323901 > V 7 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -8: X=0.00000000 Y=0.00000000 Z=0.90323901 > MULT= 1 ISPLIT= 8 > V 8 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM -9: X=0.00000000 Y=0.90000000 Z=0.00000000 > MULT= 2 ISPLIT= 8 > -9: X=0.00000000 Y=0.10000000 Z=0.00000000 > H 1 NPT= 781 R0=0.00010000 RMT= 0.4561 Z: 1.0 > LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 4 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 > -1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 2 > 1 0 0 0.0000000 > 0-1 0 0.0000000 > 0 0 1 0.0000000 > 3 > -1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 4 > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: 13 Dec 2002 21:34:36 +0900 From: Li Wang Subject: Re: [WIEN]: Dstart error ==== Li Wang submitted the following contribution: ==== Dear Prof. P.Blaha, Thank you for your reply. The structure file is not a correct, and it is only a test. Now I am studying absorption of Hydrogen molecule on metal surface with Wien2k and other package. As you said, it is a difficult task for Wien. Li wang ÔÚ 2002-12-13 Îå µÄ 18:07£¬ Peter Blaha дµÀ£º > ==== > Peter Blaha > submitted the following contribution: > ==== > > > I am calculating a slab with H2 molecule. A error file is created > > when begining running "x start" in a "Initialize calculation" progress, > > which only contaion "Error in Dstart" message. > > The process (dstart) will finish in 1~2 hours. Can you tell me the > > reason and if I can ignore it? > > As long as dstart is running, the file dstart.error contains the message > you mentioned above. As soon as dstart finishes, this file still exists, but > must be empty. If it is NOT empty, you cannot ignore it. > > H2 with it's small sphere is a difficult task for WIEN. > > Are you sure your structure is what you want to calculate?? > > H is in exactly the same surface hight as V ? and leads to exceptional small > distances between H and V ? At least your structure is NOT an H2-molecule!! > > If you really want to do such a structure, you will need to reduce RKMAX from > the default (7) to 3-4 (test it?). You also may need a higher GMAX (20-24 ?) > for correct forces! > > If you correct the positions, use larger spheres for both, H and V (if > possible). > > 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ > -------------------------------------------------------------------------- > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: 13 Dec 2002 21:38:17 +0900 From: Li Wang Subject: Re: [WIEN]: Dstart error ==== Li Wang submitted the following contribution: ==== Dear Jalali, Thank you for your reply. Sincerely, yous Li Wang ÔÚ 2002-12-13 Îå µÄ 17:24£¬ Saeid Jalali дµÀ£º > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > I am calculating a slab with H2 molecule. A error file is created > > when begining running "x start" in a "Initialize calculation" progress, > > which only contaion "Error in Dstart" message. > > The process (dstart) will finish in 1~2 hours. Can you tell me the > > reason and if I can ignore it? > I noticed that the size of your sent dstart.error file is zero byte. This > means that x dstart -c was performed with no error. > Your, > S. Jalali. > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: 13 Dec 2002 21:39:48 +0900 From: Li Wang Subject: Re: [WIEN]: Dstart error ==== Li Wang submitted the following contribution: ==== Dear Jorissen, Thank you for your reply. Sincerely,yous Li Wang ÔÚ 2002-12-13 Îå µÄ 18:23£¬ Kevin Jorissen дµÀ£º > ==== > "Kevin Jorissen" > submitted the following contribution: > ==== > > This is just the way wien handles its error files. At the beginning of each > program (eg dstart), an error file is created containing the line 'error in > program'. When the program is able to end succesfully, the file is emptied. > But during the execution of the program, there is a non-empty error file. > The advantage of this is simple : even if the program crashes in the most > spectacular way and has no chance whatsoever to give you any message, there > will still be an error message. On the other hand, if the machine would > only write an error file in case something does go wrong, it might not be > able to do this after all, and you would not know there's something wrong > with your calculation. > > Don't worry, the errorfile will be empty at the end of dstart. > > Good luck with the calculations. > > Kevin Jorissen > kevin.jorissen@ua.ac.be > > ----- Original Message ----- > From: "Li Wang" > To: > Sent: Friday, December 13, 2002 6:15 AM > Subject: [WIEN]: Dstart error > > > > Dear all, > > I am calculating a slab with H2 molecule. A error file is created > > when begining running "x start" in a "Initialize calculation" progress, > > which only contaion "Error in Dstart" message. > > The process (dstart) will finish in 1~2 hours. Can you tell me the > > reason and if I can ignore it? > > > > > > Li Wang > > Hydrogen Isotope Research Center, > > Toyama University, > > 3190 Gofuku, > > Toyama 930-8555 > > Japan > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > > ---------------------------------------------------------------------------- > ---- > > > > Wien2k struct file generated by XCrySDen program > > CXY LATTICE,NONEQUIV. ATOMS 935_Cmm2 > > MODE OF CALC=NREL unit=bohr > > 11.451745 16.195213105.000000 90.000000 90.000000 90.000000 > > ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000 > > MULT= 1 ISPLIT= 8 > > V 1 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -2: X=0.25000000 Y=0.25000000 Z=0.00000000 > > MULT= 2 ISPLIT= 8 > > -2: X=0.75000000 Y=0.25000000 Z=0.00000000 > > V 2 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -3: X=0.00000000 Y=0.50000000 Z=0.00000000 > > MULT= 1 ISPLIT= 8 > > V 3 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -4: X=0.25000000 Y=0.50000000 Z=0.95161951 > > MULT= 2 ISPLIT= 8 > > -4: X=0.75000000 Y=0.50000000 Z=0.95161951 > > V 4 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > 1.0000000 0.0000000 0.0000000 > > ATOM -5: X=0.00000000 Y=0.25000000 Z=0.95161951 > > MULT= 2 ISPLIT= 8 > > -5: X=0.00000000 Y=0.75000000 Z=0.95161951 > > V 5 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > ATOM -6: X=0.00000000 Y=0.50000000 Z=0.90323901 > > MULT= 1 ISPLIT= 8 > > V 6 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -7: X=0.25000000 Y=0.75000000 Z=0.90323901 > > MULT= 2 ISPLIT= 8 > > -7: X=0.75000000 Y=0.75000000 Z=0.90323901 > > V 7 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -8: X=0.00000000 Y=0.00000000 Z=0.90323901 > > MULT= 1 ISPLIT= 8 > > V 8 NPT= 781 R0=0.00005000 RMT= 1.0634 Z: 23.0 > > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 0.0000000 0.0000000 1.0000000 > > ATOM -9: X=0.00000000 Y=0.90000000 Z=0.00000000 > > MULT= 2 ISPLIT= 8 > > -9: X=0.00000000 Y=0.10000000 Z=0.00000000 > > H 1 NPT= 781 R0=0.00010000 RMT= 0.4561 Z: 1.0 > > LOCAL ROT MATRIX: 0.0000000 0.0000000 1.0000000 > > 1.0000000 0.0000000 0.0000000 > > 0.0000000 1.0000000 0.0000000 > > 4 NUMBER OF SYMMETRY OPERATIONS > > 1 0 0 0.0000000 > > 0 1 0 0.0000000 > > 0 0 1 0.0000000 > > 1 > > -1 0 0 0.0000000 > > 0-1 0 0.0000000 > > 0 0 1 0.0000000 > > 2 > > 1 0 0 0.0000000 > > 0-1 0 0.0000000 > > 0 0 1 0.0000000 > > 3 > > -1 0 0 0.0000000 > > 0 1 0 0.0000000 > > 0 0 1 0.0000000 > > 4 > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 06:36:00 -0800 (PST) From: Wenqing ZHANG Subject: [WIEN]: MPI lib for intel/linux fortran ==== Wenqing ZHANG submitted the following contribution: ==== Hi, Can anyone tell me what is the best MPI lib for intel/Fortran? Where can download the package? I am currently trying to run WIEN on xeon machine. Thanks for help. Yours -- Wenqing ===== Wenqing ZHANG 1970 Crystal Lake Dr. Apt#E79 Shelby Twp., MI 48316 Tel: (810)254-9931(h), (810)323-1551(o) Fax: (810)323-9898 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 06:47:36 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: QTL-B = 1220.43 ==== yanming Ma submitted the following contribution: ==== - --0-288855027-1039790856=:77978 Content-Type: text/plain; charset=us-ascii Dear Peter, Thanks for your answers. I will try under your suggestion and let you know the results. But due to the long computing time, I may reply you a little bit later. Best Regards. Yanming Ma Peter Blaha wrote:==== Peter Blaha submitted the following contribution: ==== > The EF is around 0.32 Ryd in my case. So do you mean I should change the energy parameters for s, p, d orbitals from 0.3 to 0.12, But how about the energy values for local orbital? No, not necessary. > > When I check the case.scf file, I also find the following messages > > 6 eighvalues below the energy -7.0 ( energy cut off in Lstart) Ah !!!! As I expected, you got ghostbands. Increasing of the energy cutoff will not help. Reduce the Cs sphere and start all over again. (You might need to put a Cs-p LO by hand (e.g. at -0.6 Ry) and for security set the p-LAPW to e.g. 1.0 Ry). I checked it, the default input does not give a l=1 LO, because the semicore 5p level is at -0.95 and thus just above the -1.0 Ry criteria). 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-288855027-1039790856=:77978 Content-Type: text/html; charset=us-ascii

Dear Peter,

Thanks for your answers. I will try under your suggestion and let you know the results. But due to the long computing time, I may reply you a little bit later.

Best Regards.

Yanming Ma

 Peter Blaha <pblaha@theochem.tuwien.ac.at> wrote:

====
Peter Blaha
submitted the following contribution:
====

> The EF is around 0.32 Ryd in my case. So do you mean I should change the energy parameters for s, p, d orbitals from 0.3 to 0.12, But how about the energy values for local orbital?

No, not necessary.

>
> When I check the case.scf file, I also find the following messages
>
> 6 eighvalues below the energy -7.0 ( energy cut off in Lstart)

Ah !!!! As I expected, you got ghostbands. Increasing of the energy cutoff
will not help. Reduce the Cs sphere and start all over again.

(You might need to put a Cs-p LO by hand (e.g. at -0.6 Ry) and for security
set the p-LAPW to e.g. 1.0 Ry). I checked it, the default input does
not give a l=1 LO, because the semicore 5p level is at -0.95 and thus just
above the -1.0 Ry criteria).


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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------

====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-288855027-1039790856=:77978-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 13 Dec 2002 19:23:11 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: meta-GGA ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers 1) From the Peter's reply in the mailing list,it seems that meta-gga(perdew et.al 2000) is possible with w2k. However in the userguide, script "lstart" gives only three options of XC-potentials (LSDA and two GGA). In the description of "case.in0" file, it is said option 12(meta-GGA) is possible. That means one has to put manually(by hand) number 12 for meta-GGA case in 'case.in0' before starting the scf cycle. am I right? the procedure would be(from Peter's reply in the mailing list) 1) run atleast one iteration with GGA option( number 13). 2) copy case.inm to case.inm_vresp. 3) set NORM = NO in case.inm_vresp and change GMAX to 24 in case.in2. 4) start the scf cycle. Have any user tested this option for bulk systems say for optimized lattice parameters?any problems encountered? any special precautions? 2) In case.inso (for SO run), one needs to specify the number of atoms for which RLO's should be added(if one wish to) and in case.indm file , we need to specify number of atoms for which DM should be calculated.If I have a test case in which there are two inequivalant atoms in the structure each having multiplicity two ie total four atoms in the cell. and if I wish to add a RLO and calcualte the DM for only the 1st inequivalant atom then number of atoms in the case.inso and case.indm should be 1 or 2. Suppose I wish to switch-off SOC for the 2nd inequivalant atom(multiplicity two) then the last line in case.inso look like: 1 2 ----> assuming we have to put only the inequivalant atom and '2' is inequivalant atom number 2 ie ATOM 2 in the case.struct file. In short, do we have to put the number of atom of inequivalant type or include its multiplicity also in case.inso and case.indm. 3) I use run(sp)_lapw -so -dm available with the recent update to add the spin-orbit coupling after non-SOC spinpolarized scf run or from the begining. It calculates the orbital moments on the atom specified in the case.inso and case.indm(in the file case.scfdmup). So the query about the running procedure for SOC is now clear which I posed in my last mail to the list. Please let me know about the MPI run query. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 08:49:05 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: meta-GGA ==== "Saeid Jalali" submitted the following contribution: ==== > 1) From the Peter's reply in the mailing list,it seems that > meta-gga(perdew et.al 2000) is possible with w2k. However in the > userguide, script "lstart" gives only three options of XC-potentials (LSDA > and two GGA). In the description of "case.in0" file, it is said option > 12(meta-GGA) is possible. That means one has to put manually(by hand) > number 12 for meta-GGA case in 'case.in0' before starting the scf cycle. > am I right? Yes, you are right. > the procedure would be(from Peter's reply in the mailing list) > > 1) run atleast one iteration with GGA option( number 13). > > 2) copy case.inm to case.inm_vresp. > 3) set NORM = NO in case.inm_vresp and change GMAX to 24 in case.in2. > 4) start the scf cycle. Required large Gmax is due to the fact that Meta-GGA also requires the orbital kinetic energy density, which is byond (meta) of GGA, where in GGA only local density and its first gradient are required. > Have any user tested this option for bulk systems say for optimized > lattice parameters?any problems encountered? any special precautions? I have not tested it yet, but it is reported that: 1) such schemes are not yet self-consistent (user guied). 2) Molecular atomization energies and metal surface energies are significantly improved (PRL 82, 2544 (1999)). 3) Lattice constants are little changed (PRL 82, 2544 (1999)). Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 18:23:00 +0800 (CST) From: music@theory.issp.ac.cn Subject: [WIEN]: LAPW and APW ==== music@theory.issp.ac.cn submitted the following contribution: ==== Dear wien users, When we modify the case.in1 file, How to determine the selecting of LAPW or APW ? Does the appearance of ghost band have relation to to the selecting ? Could anyone could help me ? THANKS IN ADVANCE! - -- sincerely yours Ying.X ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 19:08:33 +0800 (CST) From: yshzhang@theory.issp.ac.cn Subject: Re: [WIEN]: LAPW and APW ==== yshzhang@theory.issp.ac.cn submitted the following contribution: ==== Hi > When we modify the case.in1 file, How to determine the selecting > of LAPW or APW ? Please read the UG page 79. For example: WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) In this case.in1, it use LAPW. Change the file as the following: WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 6 1 the APW is using. Does the appearance of ghost band have relation to > to the selecting ? Yes, I think the 0(LAPW) is better than 1 (APW) if ghost bands exist. - -- Best Regards YS Zhang - ------------------------------------------------------------------------ Address: Institute of Solid State Physics Chinese Academy of Sciences P.O.BOX 1129,230031 Hefei P.R~China Tel: 086-551-5591464(Office) 086-551-5592837(Home) Fax: 086-551-5591434 WWW: http://theory.issp.ac.cn/~yshzhang - ------------------------------------------------------------------------ ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 10:05:54 -0500 From: "michel certier" Subject: [WIEN]: test ==== "michel certier" submitted the following contribution: ==== sorry this is just test !!! - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 10:22:40 -0500 From: "michel certier" Subject: [WIEN]: about kgen ==== "michel certier" submitted the following contribution: ==== Hi, I am novice so excuse me if my question appear some stupid. I am doing some test on orthorhombic system (62_Pnm) when I run x kgen it ask me Number of k-points:, so I choose 8, if I use Shift k-mesh (if applicable) its give me 4 kpoint in the irreducible part of Brillouin zone otherwise its give me 2 kpoint. Cans some one explain me the scheme used here and the difference between the two choice. Thanks Michele - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 10:26:08 -0500 From: "michel certier" Subject: [WIEN]: question ==== "michel certier" submitted the following contribution: ==== Hi, Its against me :-). Whene I read somme paper of electronic band structute (ab initio) for exampel for the semi conductor usally the authors says ...we have shift the fermi level to the top of band valence ( in principal in sc the fermi level lie at the half of Ec-Eg) So can somme explain me this .... Thanks once more Michele - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 16:30:02 +0100 From: Torsten Andersen Subject: Re: [WIEN]: about kgen ==== Torsten Andersen submitted the following contribution: ==== Dear Michele, If you had read the manual (Sec. 6.5, I think), it would be clear to you. Shifting the k-mesh shifts it away from high-symmetry points, thus giving more k-points. The k-points are generated according to the paper of Bloechl et. al. cited in the manual. Best regards, Torsten Andersen. michel certier wrote: >==== >"michel certier" >submitted the following contribution: >==== > >Hi, I am novice so excuse me if my question appear some stupid. I am doing some test on orthorhombic system (62_Pnm) when I run x kgen it ask me Number of k-points:, so I choose 8, if I use Shift k-mesh (if applicable) its give me 4 kpoint in the irreducible part of Brillouin zone otherwise its give me 2 kpoint. Cans some one explain me the scheme used here and the difference between the two choice. Thanks > >Michele > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 14 Dec 2002 16:34:41 +0100 From: Torsten Andersen Subject: Re: [WIEN]: question ==== Torsten Andersen submitted the following contribution: ==== I'll bet this is one of the variants of the "scissors operator"... because the calculated band structure is wrong, one adjusts the bandgap by cutting, moving, etc. the spaghetties (which are Kohn-Sham eigenvalues, and in principle unphysical, but "works very well in practice" as people usually say). Alternatively, it is referred to because these methods do not calculate the Fermi energy explicitly. The Wien code calculates the Fermi energy for you. Best regards, Torsten Andersen. michel certier wrote: >==== >"michel certier" >submitted the following contribution: >==== > >Hi, Its against me :-). Whene I read somme paper of electronic band structute (ab initio) for exampel for the semi conductor usally the authors says ...we have shift the fermi level to the top of band valence ( in principal in sc the fermi level lie at the half of Ec-Eg) So can somme explain me this .... >Thanks once more >Michele > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 15 Dec 2002 18:44:58 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: question ==== Peter Blaha submitted the following contribution: ==== > Hi, Its against me :-). Whene I read somme paper of electronic band structute (ab initio) for exampel for the semi conductor usally the authors says ...we have shift the fermi level to the top of band valence ( in principal in sc the fermi level lie at the half of Ec-Eg) So can somme explain me this .... In theory the Fermi level is the highest occupied state and this is (for our idealized semiconductor) the top of the valence band. Also remember: Usually the energy gap comes out 50% too small in theory. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 16 Dec 2002 13:35:00 +0100 (CET) From: =?iso-8859-1?q?amm=E9=20marcel?= Subject: [WIEN]: need to help ==== =?iso-8859-1?q?amm=E9=20marcel?= submitted the following contribution: ==== - --0-2051491089-1040042100=:56799 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Wien users H! Please, could you explain to me what is the origin of this message in lapw1.error file : 'DPHTRF' - DPHTR4 aborded unsuccessfully Thank you best ragrds Marcel - --------------------------------- Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Testez le nouveau Yahoo! Mail - --0-2051491089-1040042100=:56799 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Dear Wien users

H!

Please, could you explain to me what is the origin of this message in lapw1.error file :

'DPHTRF'  -  DPHTR4  aborded unsuccessfully

Thank you

best ragrds

Marcel


Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail - --0-2051491089-1040042100=:56799-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 16 Dec 2002 13:56:46 +0100 From: Torsten Andersen Subject: Re: [WIEN]: need to help ==== Torsten Andersen submitted the following contribution: ==== It probably means that your struct file is wrong. It is from BLAS, I think. Best regards, Torsten Andersen. ammé marcel wrote: > Dear Wien users > > H! > > Please, could you explain to me what is the origin of this message in > lapw1.error file : > > 'DPHTRF' - DPHTR4 aborded unsuccessfully > > Thank you > > best ragrds > > Marcel > > > ------------------------------------------------------------------------ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Testez le nouveau Yahoo! Mail - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 16 Dec 2002 11:08:02 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: QTL-B = 1220.43 ==== yanming Ma submitted the following contribution: ==== - --0-532721984-1040065682=:6778 Content-Type: text/plain; charset=us-ascii Dear Peter, >Ah !!!! As I expected, you got ghostbands. Increasing of the energy cutoff >will not help. Reduce the Cs sphere and start all over again. I reduced the Cs sphere from 3.2 to 2.8. Bi and Te sphere are also set as 2.8. I restart the calculation and use the default values for Case.in1. But I still got the ghostbands as indicated by warnings of QTL- B = 1922. and 6 eighnvectors are below -7.0 Ryd. >(You might need to put a Cs-p LO by hand (e.g. at -0.6 Ry) and for security >set the p-LAPW to e.g. 1.0 Ry). I checked it, the default input does >not give a l=1 LO, because the semicore 5p level is at -0.95 and thus just >above the -1.0 Ry criteria). The default energy parameters in Case.in1 are 0.3 5 0 2 0.30 0.000 CONT 1 2 -5.08 0.005 STOP 1 0 -1.66 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 I changed to the following 0.3 5 0 2 0.30 0.000 CONT 1 2 -5.08 0.005 STOP 1 0 -1.66 0.010 CONT 1 0 0.30 0.000 CONT 1 1 0.30 0.000 CONT 1 1 -0.60 0.010 CONT 1 ------ added line for p lo Using this changed Case.in1 file, the lapw1 crashed. I also tried in this way, 0.3 5 0 2 0.30 0.000 CONT 1 2 -5.08 0.005 STOP 1 0 -1.66 0.010 CONT 1 0 0.30 0.000 CONT 1 1 1.00 0.000 CONT 1 ------- changed line 1 -0.60 0.010 CONT 1 ------- added line for p lo The lapw1 still crashed. So any other ideas? Best Regards Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-532721984-1040065682=:6778 Content-Type: text/html; charset=us-ascii

Dear Peter,


>Ah !!!! As I expected, you got ghostbands. Increasing of the energy cutoff
>will not help. Reduce the Cs sphere and start all over again.

I reduced the Cs sphere from 3.2 to 2.8. Bi and Te sphere are also set as 2.8.
I restart the calculation and use the default values for Case.in1.
But I still got the ghostbands as indicated by warnings of
QTL- B = 1922. and 6 eighnvectors are below -7.0 Ryd.

>(You might need to put a Cs-p LO by hand (e.g. at -0.6 Ry) and for security
>set the p-LAPW to e.g. 1.0 Ry). I checked it, the default input does
>not give a l=1 LO, because the semicore 5p level is at -0.95 and thus just
>above the -1.0 Ry criteria).

The default energy parameters in Case.in1 are

0.3     5      0
2      0.30        0.000    CONT 1
2     -5.08        0.005    STOP  1
0     -1.66        0.010    CONT 1
0      0.30        0.000    CONT 1
1      0.30        0.000    CONT 1

I changed  to the following

0.3     5      0
2      0.30        0.000    CONT 1
2     -5.08        0.005    STOP  1
0     -1.66        0.010    CONT 1
0      0.30        0.000    CONT 1
1      0.30        0.000    CONT 1
1     -0.60        0.010    CONT 1    ------   added line for p lo

Using this changed Case.in1 file, the lapw1 crashed. I also tried in this way,
 
0.3     5      0
2      0.30        0.000    CONT 1
2     -5.08        0.005    STOP  1
0     -1.66        0.010    CONT 1
0      0.30        0.000    CONT 1
1      1.00        0.000    CONT 1   ------- changed line
1     -0.60        0.010    CONT 1   ------- added line for p lo

The lapw1 still crashed.

So any other ideas?

Best Regards



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-532721984-1040065682=:6778-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Dec 2002 08:42:33 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: QTL-B = 1220.43 ==== Peter Blaha submitted the following contribution: ==== > I changed to the following > > 0.3 5 0 <====================== > 2 0.30 0.000 CONT 1 > 2 -5.08 0.005 STOP 1 > 0 -1.66 0.010 CONT 1 > 0 0.30 0.000 CONT 1 > 1 0.30 0.000 CONT 1 > 1 -0.60 0.010 CONT 1 ------ added line for p lo > > Using this changed Case.in1 file, the lapw1 crashed. Of course!!! You must change the 5 to 6 in the first line! 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Dec 2002 12:20:27 -0500 From: "michel certier" Subject: [WIEN]: Wien2K instalation on dual PIV ==== "michel certier" submitted the following contribution: ==== Dear wien users. Can some one explain me how ti install WIEN2K in Dual Pentium Machime I have some problem to this task (do I need mpi for ex etc ...) Thank you once More Michel - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 17 Dec 2002 18:30:12 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Wien2K instalation on dual PIV ==== Torsten Andersen submitted the following contribution: ==== If you want to distribute one k-point over the two processors, you need MPI. If you want to distribute two or more, you don't need it. Best regards, Torsten. michel certier wrote: >==== >"michel certier" >submitted the following contribution: >==== > >Dear wien users. Can some one explain me how ti install WIEN2K in Dual Pentium Machime I have some problem to this task (do I need mpi for ex etc ...) > >Thank you once More > >Michel > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Dec 2002 09:01:14 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Wien2K instalation on dual PIV ==== Peter Blaha submitted the following contribution: ==== > Dear wien users. Can some one explain me how ti install WIEN2K in Dual Pentium Machime I have some problem to this task (do I need mpi for ex etc ...) All you need is a f90 compiler. We recommend the free Intel ifc 6.0 together with the mkl 5.2 (also from www.intel.com). Then follow the instructions from the download page and finally run siteconfig and userconfig. It should be quite easy. If you want to run WIEN2k just on ONE dual Pentium machine, select "shared memory", if you have more usable PCs on your network, say no. If you want to use parallelization over more PCs make sure you configure your machines such that you have a common NFS-filesystem (Your files must be accessible on all machines under the same path) and that you can logon with rsh or ssh without a password. It depends what you want to study, but for "regular" cases you don't need mpi. Only for very large cases with just one k-point (usually more than 50 atoms/cell) the mpi-parallel version is a valuable option. It is clearly an "expert" option. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Dec 2002 20:44:01 +0900 From: Li Wang Subject: [WIEN]: Allocate error ==== Li Wang submitted the following contribution: ==== Dear all , The lapw1 crashed when I run "x lapw -c". The message is: "Allocate error 494: Allocation of Array with extent of 143952004 failed End of diagnostics", Can some one can tell me the possible reason. Thanks. Li Wang ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Dec 2002 12:44:40 +0100 From: Torsten Andersen Subject: Re: [WIEN]: Allocate error ==== Torsten Andersen submitted the following contribution: ==== Out of memory (virtual memory). The program requests a chunk of data (roughly 137MB) from the system main memory, and it is not available. Try to increase the swap size. Best regards, Torsten Andersen. Li Wang wrote: > ==== > Li Wang > submitted the following contribution: > ==== > > Dear all , > > The lapw1 crashed when I run "x lapw -c". The message is: > "Allocate error 494: Allocation of Array with extent of 143952004 failed > End of diagnostics", > Can some one can tell me the possible reason. > > Thanks. > > Li Wang > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Dec 2002 10:00:32 +0900 From: Li Wang Subject: Re: [WIEN]: Allocate error ==== Li Wang submitted the following contribution: ==== Torsten Andersen wrote: > ==== > Torsten Andersen > submitted the following contribution: > ==== > > Out of memory (virtual memory). The program requests a chunk of data > (roughly 137MB) from the system main memory, and it is not available. > Try to increase the swap size. > > Best regards, > Torsten Andersen. > > Li Wang wrote: > >> ==== >> Li Wang >> submitted the following contribution: >> ==== >> >> Dear all , >> >> The lapw1 crashed when I run "x lapw -c". The message is: >> "Allocate error 494: Allocation of Array with extent of 143952004 failed >> End of diagnostics", >> Can some one can tell me the possible reason. >> >> Thanks. >> >> Li Wang >> >> >> >> ==== >> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> To (un)subscribe send mail to >> majordomo@zeus.theochem.tuwien.ac.at >> ==== >> >> > Dear Dr. Andersen, Thank you for your reply. But I have 2G memory and 2G swap space. I think that there should be another reason. Best regrads, Li Wang ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 18 Dec 2002 12:20:02 +0100 From: Peer Kruse Subject: Re: [WIEN]: Allocate error ==== Peer Kruse submitted the following contribution: ==== Have you checked your ulimits? It's not enough to have the memory but you have to be allowed to use it. Try a "ulimit -a" if you have Linux, often data seg size and stack size are critical points, unlimited is somtimes good value but be aware not to write too big core files. regards Peer Li Wang wrote: > ==== > Li Wang > submitted the following contribution: > ==== > > Torsten Andersen wrote: > >> ==== >> Torsten Andersen >> submitted the following contribution: >> ==== >> >> Out of memory (virtual memory). The program requests a chunk of data >> (roughly 137MB) from the system main memory, and it is not available. >> Try to increase the swap size. >> >> Best regards, >> Torsten Andersen. >> >> Li Wang wrote: >> >>> ==== >>> Li Wang >>> submitted the following contribution: >>> ==== >>> >>> Dear all , >>> >>> The lapw1 crashed when I run "x lapw -c". The message is: >>> "Allocate error 494: Allocation of Array with extent of 143952004 >>> failed >>> End of diagnostics", >>> Can some one can tell me the possible reason. >>> >>> Thanks. >>> >>> Li Wang >>> >>> >>> >>> ==== >>> WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>> To (un)subscribe send mail to >>> majordomo@zeus.theochem.tuwien.ac.at >>> ==== >>> >>> >> > Dear Dr. Andersen, > Thank you for your reply. But I have 2G memory and 2G swap space. I > think that there should be another reason. > > Best regrads, > > Li Wang > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 19 Dec 2002 08:22:26 -0800 (PST) From: Claudio Lee Subject: [WIEN]: error in .dayfile ==== Claudio Lee submitted the following contribution: ==== Dear all, Is there anyone there knows this problem please help me out. My problem is: In the case.dayfile I got something like this: > lapw0 (18:55:26) ABBRUCH: DIE EFG-MATRIX IST DIE NULLMATRIX ! ABBRUCH: DIE EFG-MATRIX IST DIE NULLMATRIX ! 19.0u 0.0s 0:19 96% 0+0k 0+0io 0pf+0w > lapw1 -c -up (18:55:46) 1199.0u 7.0s 20:18 98% 0+0k 0+0io 0pf+0w > lapw1 -c -dn (19:16:05) 1198.0u 8.0s 20:22 98% 0+0k 0+0io 0pf+0w > lapwso -up -c (19:36:27) 8986.0u 17.0s 2:31:23 99% 0+0k 0+0io 0pf+0w > lapw2 -c -up -so (22:07:51) 632.0u 41.0s 11:16 99% 0+0k 0+0io 0pf+0w > lapw2 -c -dn -so (22:19:07) 633.0u 46.0s 11:21 99% 0+0k 0+0io 0pf+0w > lcore -up (22:30:29) 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w > lcore -dn (22:30:30) 0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w > mixer (22:30:30) INFO: LM-LIST in CLMSUM changed in MIXER INFO: LM-LIST in CLMSUM changed in MIXER INFO: LM-LIST in CLMSUM changed in MIXER INFO: LM-LIST in CLMSUM changed in MIXER INFO: LM-LIST in CLMSUM changed in MIXER INFO: K-LIST in CLMSUM changed in MIXER 3 INFO: K-LIST in CLMSUM changed in MIXER 4 INFO: K-LIST in CLMSUM changed in MIXER 5 INFO: K-LIST in CLMSUM changed in MIXER 6 ... ... For next iterations everything seems going well. What does that mean as K-LIST and LM-LIST changed in MIXER? Thank you in advance. Sincerely, Claudio. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #48 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #49 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, December 27 2002 Volume 2002 : Number 049 ---------------------------------------------------------------------- Date: Thu, 19 Dec 2002 15:51:25 -0500 (EST) From: Neme Nnolim Subject: [WIEN]: Symmetry decomposed electron density plots? ==== Neme Nnolim submitted the following contribution: ==== Dear WIEN users, I am interested in calculating symmetry decomposed (for example d-eg, d-t2g) valence electron density plots. How do I go about it? I think this question has been asked before on this mailing list, although my search keywords do not seem to be bringing them up. Thanks and regards, Neme - ------------------------------------------------------------------------------ Neme Okechukwu Nnolim Department of Applied Physics, Material Science Program New Jersey Institute of Technology Room 302, Tiernan Hall, 161 Warren Street, University Heights Newark, New Jersey 07102-1982 Tel: (973) 596-8283, FAX: (973) 596-5794 - ------------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Dec 2002 09:12:58 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Symmetry decomposed electron density plots? ==== Peter Blaha submitted the following contribution: ==== > I am interested in calculating symmetry decomposed (for example > d-eg, d-t2g) valence electron density plots. How do I go about it? > I think this question has been asked before on this mailing list, > although my search keywords do not seem to be bringing them up. This is not possible. All you can do is select a specific energy range in case.in2 and plot the density only for states in this range. And when you analyse the partial DOS first, you might be able to separate such states approximately. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Dec 2002 09:18:29 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: error in .dayfile ==== Peter Blaha submitted the following contribution: ==== > Is there anyone there knows this problem please help > me out. > My problem is: In the case.dayfile I got something > like this: > > > lapw0 (18:55:26) ABBRUCH: DIE EFG-MATRIX > IST DIE NULLMATRIX ! > ABBRUCH: DIE EFG-MATRIX IST DIE NULLMATRIX ! > 19.0u 0.0s 0:19 96% 0+0k 0+0io 0pf+0w > > mixer (22:30:30) INFO: LM-LIST in CLMSUM > changed in MIXER > INFO: LM-LIST in CLMSUM changed in MIXER > INFO: LM-LIST in CLMSUM changed in MIXER > INFO: LM-LIST in CLMSUM changed in MIXER > INFO: LM-LIST in CLMSUM changed in MIXER > INFO: K-LIST in CLMSUM changed in MIXER 3 > INFO: K-LIST in CLMSUM changed in MIXER 4 > INFO: K-LIST in CLMSUM changed in MIXER 5 > INFO: K-LIST in CLMSUM changed in MIXER 6 > ... > ... > For next iterations everything seems going well. > What does that mean as K-LIST and LM-LIST changed in > MIXER? You must have done something one should never do in WIEN2k: In the directory "case" you have initialized a certain case and run scf. After that you have changed the symmetry of your case (either by putting different lattice parameters or by putting atoms in positions which breaks symmetry. After that you must have "initialized" again leading to a new LM list in case.in2, new symmetry operations in case.struct,... But you still had an "old" clmsum file (with LMs and a K-list for the old symmetry) and you tried to "mix" this old list with the new one. Most likely mixer took care of that and it is ok. Nevertheless: my recommendation is: never mix different symmetries in ONE case. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 20 Dec 2002 19:38:34 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: supercell error ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Prof. Blaha and W2k users I generated using recently added utility to w2k "supercell", 3x3x3 cell of Na(starting from 2 atom bcc cell).The target lattice chosen was P. It generated a supercell struct file in which there are 54 Na atoms which are all inequivalant. and I replaced one of sodium at (1/2a, 1/2a, 1/2a) by a transition metal say Ti.Total 54 atoms(53 Na+ one TM). using the supercell struct file, 1) " sgroup" gave a struct file where the number of inequivalant atoms changed from 54 to 8 due to Ti. I copied case.struct_sgroup to case.struct. 2)" symmetry" struct file is also same. 3) using "instgen_lapw" generated "case.inst" file. 4) and continued with lstart, kgen, dstart [-up/dn] NO ERROR anywhere, NO WARNINGS. checked case.in0,case.in1, case.in2 etc. All are generated properly. 1 k-point chosen and .machines file in MPI parallel format, 4 processor for lapw0 and 1 kpt distribued on 4 processors. however, I get error: case.dayfile: ________________________________________________________________________ start (Fri Dec 20 15:11:43 CST 2002) with lapw0 (20/20 to go) > lapw0 -p (15:11:43) starting parallel lapw0 at Fri Dec 20 15:11:43 CST 2002 - -------- .machine1 : 4 processors longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 - -------- ** lapw0 crashed! 0.0u 0.2s 0:03 7% 65+461k 0+0io 0pf+0w > stop error _____________________________ I checked the four case.output000* files generated it has some important message while generating multipole moments (in all four files) ______________________________________________________________ M U L T I P O L M O M E N T S ------------------------------ ATOM= 1 Ti Z=22.00 LM= 5 POSITION= 0.500 0.500 0.500 L= 0 M= 0 SPHERE MM = 0.720283455 0.000000000 L= 4 M= 0 SPHERE MM = 0.000662637 0.000000000 L= 4 M= 4 SPHERE MM = 0.000396001 0.000000000 L= 6 M= 0 SPHERE MM = -0.000160274 0.000000000 L= 6 M= 4 SPHERE MM = 0.000299845 0.000000000 ATOM= 2 Na1 Z=11.00 LM=10 POSITION= 0.833 0.500 0.500 UNCORRECT LM LIST FOR CUBIC STRUCTURE MULTSU.F L= 1 M= 0 _____________________________________ this error is from SRC_lapw0/multsu.f. the terminal output error: _________________________________________________________________ hup: Command not found. ERROR: 0032-184 MPI was not finalized in routine unknown, task 1 ERROR: 0032-184 MPI was not finalized in routine unknown, task 2 ERROR: 0032-184 MPI was not finalized in routine unknown, task 3 ERROR: 0032-184 MPI was not finalized in routine unknown, task 0 No match _________________________________________________________________ I checked while compiling the code there were no complilation error and linking error message in SRC_lapw0/compile.msg etc(SCALAPACK and BLACS linking are then OK). lapw0_mpi, lapw1_mpi, law2_mpi are indeed created. If any w2k have experience in running MPI parallel job with huge supercell have clue as to where I have gone wrong in the procedure, pl. let me know. thanx in advance Regards sahu PS: If you would like to check struct and any other files, pl. let me know ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Dec 2002 10:31:18 +0800 From: gyguo Subject: [WIEN]: AFM calculations ==== gyguo submitted the following contribution: ==== Dear Dr. Blaha and WIEN users, I tried to do AFM calculations for bcc Cr using runafm_lapw. I followed the procedure in UG. However, the run was stuck after lapw1. The run kept copying case.vectorup to case.vectordn till the whole disc space was full, and in this way, the file "case.vectordn" is far much large than case.vectorup. Can anyone help to solve this problem? Guang-Yu Guo ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Dec 2002 08:12:53 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: AFM calculations ==== "Saeid Jalali" submitted the following contribution: ==== > I tried to do AFM calculations for bcc Cr using runafm_lapw. > I followed the procedure in UG. However, the run was stuck after > lapw1. The run kept copying case.vectorup to case.vectordn till > the whole disc space was full, and in this way, the file "case.vectordn" > is far much large than case.vectorup. > > Can anyone help to solve this problem? One can after labeling the two Cr's (Cr1, Cr2) and flipping the spins also use the runsp_lapw script: runafm_lapw script just saves the time calculating only spin up, which for this bcc-Cr with no impurity may not be serious. Your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 21 Dec 2002 17:10:35 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: QTL-B = 1220.43 ==== yanming Ma submitted the following contribution: ==== - --0-2106486406-1040519435=:79981 Content-Type: text/plain; charset=us-ascii Dear Peter, > >I changed to the following > > 0.3 5 0 <====================== > 2 0.30 0.000 CONT 1 > 2 -5.08 0.005 STOP 1 > 0 -1.66 0.010 CONT 1 > 0 0.30 0.000 CONT 1 > 1 0.30 0.000 CONT 1 > 1 -0.60 0.010 CONT 1 ------ added line for p lo >> >> Using this changed Case.in1 file, the lapw1 crashed. >Of course!!! You must change the 5 to 6 in the first line! I changed the 5 to 6 in the first line. The lapw1 works fine. But When the runsp_lapw -up finish, I still found the warning "8 Eignvalue below the -8.0 Ry" in Case.scfup file. I aslo tried to using the following energy parameters. 0.3 6 0 <====================== > 2 0.30 0.000 CONT 1 > 2 -5.08 0.005 STOP 1 > 0 -1.66 0.010 CONT 1 > 0 0.30 0.000 CONT 1 > 1 1.00 0.000 CONT 1 > 1 -0.60 0.010 CONT 1 ------ added line for p lo I also got the similar warning in Case.scfup files. Are there other possible reasons for this ghost band problem? Best Wishes Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-2106486406-1040519435=:79981 Content-Type: text/html; charset=us-ascii

Dear Peter,

> >I changed to the following
> > 0.3     5      0                          <======================
> 2      0.30        0.000    CONT 1
> 2     -5.08        0.005    STOP  1
> 0     -1.66        0.010    CONT 1
> 0      0.30        0.000    CONT 1
> 1      0.30        0.000    CONT 1
> 1     -0.60        0.010    CONT 1!     ------   added line for p lo
>>
>> Using this changed Case.in1 file, the lapw1 crashed.

>Of course!!! You must change the 5 to 6 in the first line!

I changed the 5 to 6 in the first line. The lapw1 works fine. But When the runsp_lapw -up finish, I still found the warning "8 Eignvalue below the -8.0 Ry" in Case.scfup file. I aslo tried to using the following energy parameters. 

 0.3     6      0                          <======================
> 2      0.30        0.000    CONT 1
> 2     -5.08        0.005    STOP  1
> 0     -1.66        0.010    CONT 1
> 0      0.30        0.000    CONT 1
> 1      1.00        0.000    CONT 1
> 1     -0.60        0.010    CONT 1    ------ &n! bsp; added line for p lo

I also got the similar warning in Case.scfup files.

Are there other possible reasons for this ghost band problem?

Best Wishes

 



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-2106486406-1040519435=:79981-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Dec 2002 16:48:18 +0800 From: "liu wan" Subject: [WIEN]: question about "iterative diagonalization" ==== "liu wan" submitted the following contribution: ==== Dear WIEN users, In order to save time, I tired to use iterative diagonalization. I run "run_lapw -it". But after LAPW2, the program exit and report "Arguments too long". If I run "run_lapw", everything is OK, and I can get self-consistent. Can anyone help me to solve this problem? Thanks. Liu _________________________________________________________________ The new MSN 8: smart spam protection and 3 months FREE*. http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 22 Dec 2002 16:49:29 +0800 From: "liu wan" Subject: [WIEN]: question about reference ==== "liu wan" submitted the following contribution: ==== Dear all, For the exchange-correlation potential, I had set 5 in the case.in0 which reference correspond to this choice? Thank you in advance. Sincerely, Liu _________________________________________________________________ MSN 8 with e-mail virus protection service: 3 months FREE*. http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 09:29:49 +0800 From: gyguo Subject: Re: [WIEN]: AFM calculations ==== gyguo submitted the following contribution: ==== Saeid Jalali ¼g¹D¡G > ==== > "Saeid Jalali" > submitted the following contribution: > ==== > > > I tried to do AFM calculations for bcc Cr using runafm_lapw. > > I followed the procedure in UG. However, the run was stuck after > > lapw1. The run kept copying case.vectorup to case.vectordn till > > the whole disc space was full, and in this way, the file "case.vectordn" > > is far much large than case.vectorup. > > > > Can anyone help to solve this problem? > One can after labeling the two Cr's (Cr1, Cr2) and flipping the spins also > use the runsp_lapw script: runafm_lapw script just saves the time > calculating only spin up, which for this bcc-Cr with no impurity may not be > serious. > Your, > S. Jalali. Dear Dr. Jalali, Thanks for your e-mail. I have done AF calculations for bcc Cr using "runsp_lapw" before [PRB 62,5136 (2000)]. Here, I just wanted to see whether "runafm_lapw" works or not since it will save substantial CPU time. It obviously does not work for me here. Cheers, Guang-Yu Guo > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 08:15:14 +0330 From: "Saeid Jalali" Subject: Re: [WIEN]: AFM calculations ==== "Saeid Jalali" submitted the following contribution: ==== > > > I tried to do AFM calculations for bcc Cr using runafm_lapw. > > > I followed the procedure in UG. However, the run was stuck after > > > lapw1. The run kept copying case.vectorup to case.vectordn till > > > the whole disc space was full, and in this way, the file "case.vectordn" > > > is far much large than case.vectorup. > > > Can anyone help to solve this problem? > > One can after labeling the two Cr's (Cr1, Cr2) and flipping the spins also > > use the runsp_lapw script: runafm_lapw script just saves the time > > calculating only spin up, which for this bcc-Cr with no impurity may not be > > serious. > Thanks for your e-mail. I have done AF calculations for bcc Cr using > "runsp_lapw" before [PRB 62,5136 (2000)]. Here, I just wanted to see > whether "runafm_lapw" works or not since it will save substantial CPU > time. It obviously does not work for me here. Then, did you also copy case.struct of nonmagnetic bcc-Cr (with B symmetry and one Cr at 0 0 0) to case.struct_supergroup, where you have the antiferromagnetic bcc-Cr (with P symmetry and two Cr's)? your, S. Jalali. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 10:18:56 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: question about reference ==== Peter Blaha submitted the following contribution: ==== > For the exchange-correlation potential, I had set 5 in the case.in0 > > which reference correspond to this choice? Look into the Userguide! 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 10:31:46 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: supercell error ==== Peter Blaha submitted the following contribution: ==== > ATOM= 1 Ti Z=22.00 LM= 5 POSITION= 0.500 0.500 > 0.500 > > L= 0 M= 0 SPHERE MM = 0.720283455 0.000000000 > L= 4 M= 0 SPHERE MM = 0.000662637 0.000000000 > L= 4 M= 4 SPHERE MM = 0.000396001 0.000000000 > L= 6 M= 0 SPHERE MM = -0.000160274 0.000000000 > L= 6 M= 4 SPHERE MM = 0.000299845 0.000000000 > > > ATOM= 2 Na1 Z=11.00 LM=10 POSITION= 0.833 0.500 > 0.500 > > UNCORRECT LM LIST FOR CUBIC STRUCTURE > MULTSU.F > L= 1 M= 0 Please have a look into your struct file. It could be that sgroup has made an error: Compare your struct file with the output of outputs: There it tells you for each atom the "pointgroup" and selects the LM list. If it is a "non-cubic" atom (see UG for explanation), this atom should have a "negative atomnumber", while if it is cubic, it should be positive. For your output above I can see that the first atom is "cubic", i.e. in the struct file it should have a positive counter, while the second should be non-cubic, i.e. have a negative number. My suggestion: Put the "number of symmetry operations" to zero (w2web) and reinitialize starting with symmetry. In case that my analysis is correct (and you have not made any other mistake?) please send (to my private email) the struct file generated by "supercell"+the replaced TM ion. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 18:27:23 +0800 From: "liu wan" Subject: Re: [WIEN]: question about reference ==== "liu wan" submitted the following contribution: ==== Dear Dr. Peter Blaha Thank you very much for your reply. The reference corresponding to "5" in case.in0 is "Perdew J.P. and Wang Y. 1992, Phys.Rev. B45, 13244"? Could you please help me to solve another problem? In order to save time, I tired to use iterative diagonalization. I run "run_lapw -it". But after LAPW2, the program exit and report "Arguments too long". If I run "run_lapw", everything is OK, and I can get self-consistent. Thank you Liu >From: Peter Blaha >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: question about reference >Date: Mon, 23 Dec 2002 10:18:56 +0100 (MET) > >==== >Peter Blaha >submitted the following contribution: >==== > > > For the exchange-correlation potential, I had set 5 in the case.in0 > > > > which reference correspond to this choice? > >Look into the Userguide! > > 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@theochem.tuwien.ac.at WWW: >http://info.tuwien.ac.at/theochem/ >-------------------------------------------------------------------------- > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_addphotos_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 11:50:54 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: question about reference ==== Peter Blaha submitted the following contribution: ==== > In order to save time, I tired to use iterative diagonalization. I run > "run_lapw -it". But after LAPW2, the program exit and report "Arguments > too long". If I run "run_lapw", everything is OK, and I can get > self-consistent. I don't know what to do with this. Maybe change in run_lapw the first line to -xf to get more debugging output. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 23 Dec 2002 11:28:20 -0500 From: "Dadi Dai" Subject: [WIEN]: Error message in Bandstructure in w2web ==== "Dadi Dai" submitted the following contribution: ==== I met an error message when I was using w2web to generate bandstructure. I click "x lapw1 -band -up", and then an error appears: if - Malformed file inquiry I don't know where this error comes from. The wien2k package that I am using was downloaded on Nov. 5. I haven't seen any update on lapw1 on the update info list since then. As I remembered, the previous versions of wien2k doesn't have such problem. Unfortunately, however, I haven't kept the old versions. Could anyone help me? Thank you very much! Dadi Dai ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Dec 2002 14:07:29 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI parallel ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users I have a problem in running MPI parallel job(54 atom cell, 1 k-point, .machines file in MPI parallel format). initialization is correct(ie correct struct and other files). the Machine is SP4 with 4 nodes each node having 16 POWER4 processors(shared memory machine). With 1 k-point, .machines file in MPI parallel format lapw0:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 granularity:1 (8 processors for laow0 and 8 processors for 1 k-point MPI parallel) I launched the job on SP4. the dayfile: start (Tue Dec 24 12:06:03 CST 2002) with lapw0 (20/20 to go) > lapw0 -p (12:06:03) starting parallel lapw0 at Tue Dec 24 12:06:03 CST 2002 - -------- .machine1 : 8 processors longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 - -------- 0.0u 0.1s 0:50 0% 101+829k 0+0io 0pf+0w > lapw1 -up -p (12:06:53) starting parallel lapw1 at Tue Dec 24 12:06:54 CST 2002 - -> starting parallel LAPW1 jobs at Tue Dec 24 12:06:54 CST 2002 running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs [1] 52146 ________________________ As you can see lapw0 now passes smoothly. I checked the case.output000* files. No error message like I was getting before. BUT at lapw1 -up it spends enormous amount of time. I waited for 24 hours but nothing is written to Na.output1_up and does not stop with any error. It seems it stuck at lapw1 -up. What it is waiting for?It should not take so much time in my opinion to complete even a subpart of 1st iteration. I have the executables lapw0_mpi, lapw1_mpi etc. On such fast machine(I have tested 54 atom using VASP, another MPI parallel code and very efficiently), the on-node(ie I am using only 1 node with 8 processors here longhorn1 is 1 node with 8 processors) communication is done by high performance dual-plane SP switch 2 interconnect rather than ethernet GigE networks. so communication between the processors on the given node(here longhorn1) is really very fast and may not be cause of the problem. lapw0_mpi, lapw1_mpi,lapw2_mpi etc are created properly without any error in compile.msg during compilation and linking. I suspected whether it is waiting for passwd on longhorn1(It should not as it is a shared memory machine). so I put .rhosts file with the longhorn1 node in it. but no success. I have done 13 atoms cell with different k-point mesh in k-point parallel mode on the same machine. there is no problem. thank you in advance for your suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 24 Dec 2002 16:01:13 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI parallel ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users I have a problem in running MPI parallel job(54 atom cell, 1 k-point, .machines file in MPI parallel format). initialization is correct(ie correct struct and other files). the Machine is SP4 with 4 nodes each node having 16 POWER4 processors(shared memory machine). With 1 k-point, .machines file in MPI parallel format lapw0:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 granularity:1 (8 processors for laow0 and 8 processors for 1 k-point MPI parallel) I launched the job on SP4. the dayfile: start (Tue Dec 24 12:06:03 CST 2002) with lapw0 (20/20 to go) > lapw0 -p (12:06:03) starting parallel lapw0 at Tue Dec 24 12:06:03 CST 2002 - -------- .machine1 : 8 processors longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 - -------- 0.0u 0.1s 0:50 0% 101+829k 0+0io 0pf+0w > lapw1 -up -p (12:06:53) starting parallel lapw1 at Tue Dec 24 12:06:54 CST 2002 - -> starting parallel LAPW1 jobs at Tue Dec 24 12:06:54 CST 2002 running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs [1] 52146 ________________________ As you can see lapw0 now passes smoothly. I checked the case.output000* files. No error message like I was getting before. BUT at lapw1 -up it spends enormous amount of time. I waited for 24 hours but nothing is written to Na.output1_up and does not stop with any error. It seems it stuck at lapw1 -up. What it is waiting for?It should not take so much time in my opinion to complete even a subpart of 1st iteration. I have the executables lapw0_mpi, lapw1_mpi etc. On such fast machine(I have tested 54 atom using VASP, another MPI parallel code and very efficiently), the on-node(ie I am using only 1 node with 8 processors here longhorn1 is 1 node with 8 processors) communication is done by high performance dual-plane SP switch 2 interconnect rather than ethernet GigE networks. so communication between the processors on the given node(here longhorn1) is really very fast and may not be cause of the problem. lapw0_mpi, lapw1_mpi,lapw2_mpi etc are created properly without any error in compile.msg during compilation and linking. I suspected whether it is waiting for passwd on longhorn1(It should not as it is a shared memory machine). so I put .rhosts file with the longhorn1 node in it. but no success. I have done 13 atoms cell with different k-point mesh in k-point parallel mode on the same machine. there is no problem. thank you in advance for your suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Dec 2002 04:16:44 -0800 (PST) From: hamid salehi Subject: [WIEN]: instal ==== hamid salehi submitted the following contribution: ==== Dear wien Users I want instal the WIEN2k_02-executables.tar.gz Package. would you please Write step by step with details of installing WIEN2k_02-executables.tar.gz best wishes ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Dec 2002 05:52:03 -0800 (PST) From: hamid salehi Subject: [WIEN]: install ==== hamid salehi submitted the following contribution: ==== Dear wien Users I want instal the WIEN2k_02-executables.tar.gz Package. would you please Write step by step with details of installing WIEN2k_02-executables.tar.gz best wishes ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------DreamInTech.nfra21WAS2.Mail.Engine3e09ace042433-- ===== Hamdollah Salehi Dept of Physics Ferdowsi University Mashhad IRAN Post boxs 1436 Post code 91775 faxs __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 01:56:06 +0000 From: ecat@nfrn-mail.org.uk Subject: [WIEN]: The problem about Etop and Ebottom ==== ecat@nfrn-mail.org.uk submitted the following contribution: ==== Dear friends, I have some difficulty in running Wien2k.Could you please give any help? The problem is: In uplapw1.error,there is something like: 'SELECT' - no energy limits found for L= 1 'SELECT' - E-bottom 1.97000 E-top -200.00000 In my case.in1,there are lines like: WFFIL (WFPRI, SUPWF) 7.00 10 4 (R-MT*K-MAX; MAX L IN WF, V-NMT 0.30 4 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 0.30 0.000 CONT 1 0 -5.57 0.005 CONT 1 1 0.30 0.000 CONT 1 1 -3.12 0.005 STOP 1 0.30 5 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW) 0 0.30 0.000 CONT 1 0 -7.93 0.005 CONT 1 1 0.30 0.000 CONT 1 1 -4.96 0.005 STOP 1 2 0.30 0.010 CONT 1 K-VECTORS FROM UNIT:4 -10.0 1.5 emin/emax window If the Etop or the Ebottom for l=1 cannot be found,the scf cycle will stop. How to solve this problem? If the Etop or the Ebottom cannot be found,how to make the scf program run well? Thanks a lot! Yours, Ecat ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 25 Dec 2002 21:18:23 -0800 From: "aparna chakrabarti" Subject: [WIEN]: (No Subject) ==== "aparna chakrabarti" submitted the following contribution: ==== Has anyone simulated the NiAs phase for some binary semiconductors? I get the wurtzite phase right, lattice constant and bulk modulus. For NiAs lattice constant is fine but bulk modulus is almost doubled. Does anyone have an answer?! Thanks in advance. Regards Aparna _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 08:54:23 -0500 From: "Dadi Dai" Subject: [WIEN]: w2web, Bandstructure, Error Message ==== "Dadi Dai" submitted the following contribution: ==== I met an error message when I was using w2web to generate bandstructure. I click "x lapw1 -band -up", and then an error appears: if - Malformed file inquiry I don't know where this error comes from. The wien2k package that I am using was downloaded on Nov. 5. I haven't seen any update on lapw1 on the update info list since then. As I remembered, the previous versions of wien2k doesn't have such problem. Unfortunately, however, I haven't kept the old versions. Could anyone help me? Thank you very much! Dadi Dai ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 21:52:50 +0800 From: "liu wan" Subject: [WIEN]: question about c/a in "OPTIMIZE" ==== "liu wan" submitted the following contribution: ==== Dear all, Merry X'mas & Happy new year! I try to use "OPTIMIZE" to change c/a. By runing "OPTIMIZE" I get several file. D-V=-12_initial.struct 10.836754 9.571427 17.740615 93.069000 90.000000 90.000000 D-V=-12_coa___1.5.struct 10.345935 10.345935 17.191161 93.069000 90.000000 90.000000 D-V=-12_coa___3.0.struct 10.295466 10.295466 17.360118 93.069000 90.000000 90.000000 I am very surprised that, in the initial structure lattice parameter a is not equal to b, but in the other two file a is equal to b! Another question is: when I run optimize, I input c/a increase 3%, then I get D-V=-12_coa___3.0.struct. But the c/a in D-V=-12_initial.struct is 1.637, the c/a in D-V=-12_initial.struct is 1.686! Who can tell me the rule about changing c/a in "OPTIMIZE"? Thank you in advance. Sincerely, Liu _________________________________________________________________ MSN 8 limited-time offer: Join now and get 3 months FREE*. http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 22:40:13 +0530 From: "R.K.Thapa" Subject: [WIEN]: greetings ==== "R.K.Thapa" submitted the following contribution: ==== To all WIEN users, Happy XMAS and New Year. R.K.Thapa ============= Condensed Matter Theory Research Group Department of Physics Pachhunga University College Mizoram University Aizawl 796 001 Mizroam India Ph. No. 0091-0389-2328044 FAX : 0091-0389-2323491 E-mails : rktt@sancharnet.in ramkumar_thapa@yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 12:55:07 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MPI parallel ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users I have a problem in running MPI parallel job(54 atom cell, 1 k-point, .machines file in MPI parallel format). initialization is correct(ie correct struct and other files). the Machine is SP4 with 4 nodes each node having 16 POWER4 processors(shared memory machine). With 1 k-point, .machines file in MPI parallel format lapw0:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 granularity:1 (8 processors for laow0 and 8 processors for 1 k-point MPI parallel) I launched the job on SP4. the dayfile: start (Tue Dec 24 12:06:03 CST 2002) with lapw0 (20/20 to go) > lapw0 -p (12:06:03) starting parallel lapw0 at Tue Dec 24 12:06:03 CST 2002 - -------- .machine1 : 8 processors longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 - -------- 0.0u 0.1s 0:50 0% 101+829k 0+0io 0pf+0w > lapw1 -up -p (12:06:53) starting parallel lapw1 at Tue Dec 24 12:06:54 CST 2002 - -> starting parallel LAPW1 jobs at Tue Dec 24 12:06:54 CST 2002 running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs [1] 52146 ________________________ As you can see lapw0 now passes smoothly. I checked the case.output000* files. No error message like I was getting before. BUT at lapw1 -up it spends enormous amount of time. I waited for 24 hours but nothing is written to Na.output1_up and does not stop with any error. It seems it stuck at lapw1 -up. What it is waiting for?It should not take so much time in my opinion to complete even a subpart of 1st iteration. I have the executables lapw0_mpi, lapw1_mpi etc. On such fast machine(I have tested 54 atom using VASP, another MPI parallel code and very efficiently), the on-node(ie I am using only 1 node with 8 processors here longhorn1 is 1 node with 8 processors) communication is done by high performance dual-plane SP switch 2 interconnect rather than ethernet GigE networks. so communication between the processors on the given node(here longhorn1) is really very fast and may not be cause of the problem. lapw0_mpi, lapw1_mpi,lapw2_mpi etc are created properly without any error in compile.msg during compilation and linking. I suspected whether it is waiting for passwd on longhorn1(It should not as it is a shared memory machine). so I put .rhosts file with the longhorn1 node in it. but no success. I have tested 13 atoms cell with 1 k-point mesh MPI mode on the same machine.but the same problem. it stucks at lapw1. However, it doesnot give any problem wiht k-point parallel mode. thank you in advance for your suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 26 Dec 2002 20:08:24 +0100 (MET) From: Gilles Hug Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== Gilles Hug submitted the following contribution: ==== Hi, Happy New Year Wienners. I think the script optimize uses the cell parameters of the case_initial.struct file to compute a change from this value by the percentage you specify. It doesn't use the case.struct file. So if you want to make several c/a variation with several starting volume you have to copy the case.struct file to the case_initial.struct file. And, of course, you need to keep trace of what you are doing! :) Best Gilles On Thu, 26 Dec 2002, liu wan wrote: > ==== > "liu wan" > submitted the following contribution: > ==== > > Dear all, > > Merry X'mas & Happy new year! > > I try to use "OPTIMIZE" to change c/a. By runing "OPTIMIZE" I get several > file. > > D-V=-12_initial.struct > 10.836754 9.571427 17.740615 93.069000 90.000000 90.000000 > > D-V=-12_coa___1.5.struct > 10.345935 10.345935 17.191161 93.069000 90.000000 90.000000 > > D-V=-12_coa___3.0.struct > 10.295466 10.295466 17.360118 93.069000 90.000000 90.000000 > > I am very surprised that, in the initial structure lattice parameter a is > not equal to b, but in the other two file a is equal to b! Another question > is: when I run optimize, I input c/a increase 3%, then I get > D-V=-12_coa___3.0.struct. But the c/a in D-V=-12_initial.struct is 1.637, > the c/a in D-V=-12_initial.struct is 1.686! > > Who can tell me the rule about changing c/a in "OPTIMIZE"? > > Thank you in advance. Sincerely, > > Liu > > > _________________________________________________________________ > MSN 8 limited-time offer: Join now and get 3 months FREE*. > http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU= > http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Dec 2002 10:15:07 +0800 From: "liu wan" Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== "liu wan" submitted the following contribution: ==== Dear Dr. Gilles Hug Thank you very much for your reply! Yes, the program use the initial.struct as the origin file. My initial file has a=10.836754, b=9.571427l and c=17.740615, and I set the change of c/a is 1.5% and 3.0%, but from the file coa___1.5.struct, and coa___3.0.struct, I found that a=b in these two file!!! And the c/a=1.637 in inital.struct, but is 1.661 in coa___1.5.struct and c/a is 1.686 in coa___3.0.struct! I want to know the rule of changing c/a in "OPTIMIZE". Best wish liu >From: Gilles Hug >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: >Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" >Date: Thu, 26 Dec 2002 20:08:24 +0100 (MET) > >==== >Gilles Hug >submitted the following contribution: >==== > >Hi, >Happy New Year Wienners. > >I think the script optimize uses the cell parameters of the >case_initial.struct file to compute a change from this value by the >percentage you specify. It doesn't use the case.struct file. So if you >want to make several c/a variation with several starting volume you have >to copy the case.struct file to the case_initial.struct file. >And, of course, you need to keep trace of what you are doing! :) >Best >Gilles > > >On Thu, 26 Dec 2002, liu wan wrote: > > > ==== > > "liu wan" > > submitted the following contribution: > > ==== > > > > Dear all, > > > > Merry X'mas & Happy new year! > > > > I try to use "OPTIMIZE" to change c/a. By runing "OPTIMIZE" I get >several > > file. > > > > D-V=-12_initial.struct > > 10.836754 9.571427 17.740615 93.069000 90.000000 90.000000 > > > > D-V=-12_coa___1.5.struct > > 10.345935 10.345935 17.191161 93.069000 90.000000 90.000000 > > > > D-V=-12_coa___3.0.struct > > 10.295466 10.295466 17.360118 93.069000 90.000000 90.000000 > > > > I am very surprised that, in the initial structure lattice parameter a >is > > not equal to b, but in the other two file a is equal to b! Another >question > > is: when I run optimize, I input c/a increase 3%, then I get > > D-V=-12_coa___3.0.struct. But the c/a in D-V=-12_initial.struct is >1.637, > > the c/a in D-V=-12_initial.struct is 1.686! > > > > Who can tell me the rule about changing c/a in "OPTIMIZE"? > > > > Thank you in advance. Sincerely, > > > > Liu > > > > > > _________________________________________________________________ > > MSN 8 limited-time offer: Join now and get 3 months FREE*. > > >http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU= > > >http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf > > > > ==== > > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > > To (un)subscribe send mail to > > majordomo@zeus.theochem.tuwien.ac.at > > ==== > > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #49 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #50 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Friday, January 3 2003 Volume 2002 : Number 050 ---------------------------------------------------------------------- Date: Fri, 27 Dec 2002 23:27:58 +0800 From: "liu wan" Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== "liu wan" submitted the following contribution: ==== Dear all, Who can tell me the rule of of changing c/a in "OPTIMIZE"? Set 3% means the the c/a ratio will increase 3%, it is right? When c/a change, the b/a will also change??? When lattice constant a is not equal to b in the initial structure file, if I change c/a ratio using "OPTIMIZE", the a will equal to b! Who can tell me? Thank you. Liu >From: "liu wan" >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: wien@zeus.theochem.tuwien.ac.at >Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" >Date: Fri, 27 Dec 2002 10:15:07 +0800 > >==== >"liu wan" >submitted the following contribution: >==== > >Dear Dr. Gilles Hug > >Thank you very much for your reply! > >Yes, the program use the initial.struct as the origin file. My initial file >has a=10.836754, b=9.571427l and c=17.740615, and I set the change of c/a >is 1.5% and 3.0%, but from the file coa___1.5.struct, and coa___3.0.struct, >I found that a=b in these two file!!! And the c/a=1.637 in inital.struct, >but is 1.661 in coa___1.5.struct and c/a is 1.686 in coa___3.0.struct! I >want to know the rule of changing c/a in "OPTIMIZE". > >Best wish > >liu > >>From: Gilles Hug >>Reply-To: wien@zeus.theochem.tuwien.ac.at >>To: >>Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" >>Date: Thu, 26 Dec 2002 20:08:24 +0100 (MET) >> >>==== >>Gilles Hug >>submitted the following contribution: >>==== >> >>Hi, >>Happy New Year Wienners. >> >>I think the script optimize uses the cell parameters of the >>case_initial.struct file to compute a change from this value by the >>percentage you specify. It doesn't use the case.struct file. So if you >>want to make several c/a variation with several starting volume you have >>to copy the case.struct file to the case_initial.struct file. >>And, of course, you need to keep trace of what you are doing! :) >>Best >>Gilles >> >> >>On Thu, 26 Dec 2002, liu wan wrote: >> >> > ==== >> > "liu wan" >> > submitted the following contribution: >> > ==== >> > >> > Dear all, >> > >> > Merry X'mas & Happy new year! >> > >> > I try to use "OPTIMIZE" to change c/a. By runing "OPTIMIZE" I get >>several >> > file. >> > >> > D-V=-12_initial.struct >> > 10.836754 9.571427 17.740615 93.069000 90.000000 90.000000 >> > >> > D-V=-12_coa___1.5.struct >> > 10.345935 10.345935 17.191161 93.069000 90.000000 90.000000 >> > >> > D-V=-12_coa___3.0.struct >> > 10.295466 10.295466 17.360118 93.069000 90.000000 90.000000 >> > >> > I am very surprised that, in the initial structure lattice parameter a >>is >> > not equal to b, but in the other two file a is equal to b! Another >>question >> > is: when I run optimize, I input c/a increase 3%, then I get >> > D-V=-12_coa___3.0.struct. But the c/a in D-V=-12_initial.struct is >>1.637, >> > the c/a in D-V=-12_initial.struct is 1.686! >> > >> > Who can tell me the rule about changing c/a in "OPTIMIZE"? >> > >> > Thank you in advance. Sincerely, >> > >> > Liu >> > >> > >> > _________________________________________________________________ >> > MSN 8 limited-time offer: Join now and get 3 months FREE*. >> > >>http://join.msn.com/?page=dept/dialup&xAPID=42&PS=47575&PI=7324&DI=7474&SU= >> > >>http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_newmsn8ishere_3mf >> > >> > ==== >> > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >> > To (un)subscribe send mail to >> > majordomo@zeus.theochem.tuwien.ac.at >> > ==== >> > >> >>==== >>WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >>To (un)subscribe send mail to >>majordomo@zeus.theochem.tuwien.ac.at >>==== > > >_________________________________________________________________ >Protect your PC - get McAfee.com VirusScan Online >http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ The new MSN 8: smart spam protection and 3 months FREE*. http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Dec 2002 17:35:45 +0100 (MEZ) From: "A. Postnikov" Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== "A. Postnikov" submitted the following contribution: ==== Addressing the "mistery" of changing C/A in "optimize": Without a fresh look into the "optimize" script - that used to be quite straightforward - I'd guess that the option of changing C/A assumes you have tetragonal (or, hex or rhombo) structure, i.e., lattice parameters A A C, that's why the script forces B=A in your case. This makes sense because if your structure is orthorhombic the script doesn't know what you want to do with the third parameter - keep it fixed? Scale along with A? Or with C? That is an example of situation where the user has better to understand what he/she is doing. For optimizing the structure you'd need to vary all three parameters in some way, for each trial volume, that makes TWO independent parameters to vary, and not just C/A. A foolproof advice: prepare a sequence of struct files by hand, varying the parameters in a way (and within limits) that make sense for your structure, for example changing A and B independently so as to keep A*B*C=const, then fit the total energy as function of these two variables to find the local minimum for the given volume, refine if necessary, etc. And don't forget, if you have internal coordinates you must in principle vary them simultaneously... Hopefully it helps, Andrei Postnikov +---------- Dr. habil. Andrei Postnikov ----- apostnik@uos.de ----------+ | Universitaet Osnabrueck - Fachbereich Physik, D-49069 Osnabrueck, Germany | +---------- Tel. +49-541-9692377 ------- Fax +49-541-9692351 ----------+ > ==== > "liu wan" > submitted the following contribution: > ==== > > Dear Dr. Gilles Hug > > Thank you very much for your reply! > > Yes, the program use the initial.struct as the origin file. My initial file > has a=10.836754, b=9.571427l and c=17.740615, and I set the change of c/a is > 1.5% and 3.0%, but from the file coa___1.5.struct, and coa___3.0.struct, I > found that a=b in these two file!!! And the c/a=1.637 in inital.struct, but > is 1.661 in coa___1.5.struct and c/a is 1.686 in coa___3.0.struct! I want to > know the rule of changing c/a in "OPTIMIZE". > > Best wish > > liu > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 27 Dec 2002 12:31:58 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: "orb" error ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users I have a magnetic system containing Mo atoms where orbital potentials are important for the correct physics. So first I did scf LSDA calculation without SO. Then initso_lapw step produced the proper files with case.inso. I have case.indmc(the system dont have inversion symmetry) and case.inorb file(the mode is LDA+U). I used "runsp_lapw -so -orb" to introduce the orbital potential selfconsistencly with SO into the system.It always stops at second iteration WITHOUT any errors. There are no errors in any step in the first iteration.I checked all case.error files. the dayfile is: ____________________________________________________________________________________ the first iteration is OK as :log file shows: 19/19 to go > lapw0 -p (19:25:14) starting parallel lapw0 at Thu Dec 26 19:25:14 CST 2002 - -------- running lapw0 in single mode 33.9u 0.3s 0:34 98% 371+51469k 0+0io 0pf+0w > orb -up -p (19:25:49) 0.0u 0.0s 0:00 0% 0+0k 0+0io 19pf+0w > orb -dn -p (19:25:49) 0.0u 0.0s 0:00 10% 0+0k 0+0io 0pf+0w __________________________________________________________________________________________ the :log file: > (runsp_lapw) options: -so -orb -p Thu Dec 26 18:50:49 CST 2002> (x) lapw0 -p Thu Dec 26 18:51:15 CST 2002> (x) lapw1 -c -up -p Thu Dec 26 19:01:57 CST 2002> (x) lapw1 -c -dn -p Thu Dec 26 19:12:35 CST 2002> (x) lapwso -up -c -orb -p Thu Dec 26 19:19:59 CST 2002> (x) lapw2 -c -up -so -p Thu Dec 26 19:22:06 CST 2002> (x) sumpara -up -d Thu Dec 26 19:22:08 CST 2002> (x) sumpara_vresp -up -d Thu Dec 26 19:22:09 CST 2002> (x) lapw2 -c -dn -so -p Thu Dec 26 19:24:17 CST 2002> (x) sumpara -dn -d Thu Dec 26 19:24:19 CST 2002> (x) sumpara_vresp -dn -d Thu Dec 26 19:24:20 CST 2002> (x) lapwdm -up -p -so -c Thu Dec 26 19:25:06 CST 2002> (x) sumpara -du -d Thu Dec 26 19:25:07 CST 2002> (x) lcore -up Thu Dec 26 19:25:07 CST 2002> (x) lcore -dn Thu Dec 26 19:25:09 CST 2002> (x) mixer Thu Dec 26 19:25:14 CST 2002> (x) lapw0 -p Thu Dec 26 19:25:49 CST 2002> (x) orb -up -p Thu Dec 26 19:25:49 CST 2002> (x) orb -dn -p _________________________________________________________ the terminal output is: ___________________________________________________________________ in cycle 2 ETEST: 106.6573260000000000 CTEST: 1.8484003 hup: Command not found. STOP LAPW0 END STOP ORB END STOP ORB END if: Badly formed number.---> it stops here _____________________________________________________________ While initializing the system for SO using initso_lapw, at somepoint of the procedure, it asks whether Do you want to rerun kgen ? (y/N) If I say yes, with the same k-point info as in the previous step then it runs x kgen -so and again asks Do you want to rerun kgen ? (y/N) this time If I say 'No' then it stops with if: Badly formed number if I say again it continues again, and again, and again. How to get out of the loop? surprisingly the same message "if: Badly formed number" appears in the terminal output file above before the execution stops!! If any W2k user have experienced simillar problem/ have suggestions, Pl. let me know. thanking you in advance. Regards sahu PS: If any W2k user wish to see the struct or any other file pl. let me know. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Dec 2002 14:06:02 +0800 From: "liu wan" Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== "liu wan" submitted the following contribution: ==== Dear Dr. A. Postnikov Thank you Liu >From: "A. Postnikov" >Reply-To: wien@zeus.theochem.tuwien.ac.at >To: wien@zeus.theochem.tuwien.ac.at >Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" >Date: Fri, 27 Dec 2002 17:35:45 +0100 (MEZ) > >==== >"A. Postnikov" >submitted the following contribution: >==== > >Addressing the "mistery" of changing C/A in "optimize": > >Without a fresh look into the "optimize" script - that used to be >quite straightforward - I'd guess that the option of changing >C/A assumes you have tetragonal (or, hex or rhombo) structure, >i.e., lattice parameters A A C, that's why the script forces >B=A in your case. This makes sense because >if your structure is orthorhombic the script doesn't know >what you want to do with the third parameter - keep it fixed? >Scale along with A? Or with C? That is an example of situation >where the user has better to understand what he/she is doing. >For optimizing the structure you'd need to vary all three >parameters in some way, for each trial volume, that makes >TWO independent parameters to vary, and not just C/A. >A foolproof advice: prepare a sequence of struct files >by hand, varying the parameters in a way (and within limits) >that make sense for your structure, for example changing >A and B independently so as to keep A*B*C=const, >then fit the total energy as function of these two variables to find >the local minimum for the given volume, refine if necessary, etc. >And don't forget, if you have internal coordinates you must >in principle vary them simultaneously... > >Hopefully it helps, > >Andrei Postnikov > +---------- Dr. habil. Andrei Postnikov ----- apostnik@uos.de >----------+ > | Universitaet Osnabrueck - Fachbereich Physik, D-49069 Osnabrueck, >Germany | > +---------- Tel. +49-541-9692377 ------- Fax +49-541-9692351 >----------+ > > > ==== > > "liu wan" > > submitted the following contribution: > > ==== > > > > Dear Dr. Gilles Hug > > > > Thank you very much for your reply! > > > > Yes, the program use the initial.struct as the origin file. My initial >file > > has a=10.836754, b=9.571427l and c=17.740615, and I set the change of >c/a is > > 1.5% and 3.0%, but from the file coa___1.5.struct, and coa___3.0.struct, >I > > found that a=b in these two file!!! And the c/a=1.637 in inital.struct, >but > > is 1.661 in coa___1.5.struct and c/a is 1.686 in coa___3.0.struct! I >want to > > know the rule of changing c/a in "OPTIMIZE". > > > > Best wish > > > > liu > > > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== _________________________________________________________________ MSN 8 with e-mail virus protection service: 3 months FREE*. http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Dec 2002 19:08:55 +0800 From: =?gb2312?B?1dQg1r684Q==?= Subject: [none] ==== =?gb2312?B?1dQg1r684Q==?= submitted the following contribution: ==== Dear sir: I want to know the detail choices in the "init_lapw" of TiO2, which supplied by WIEN2k. Because I can't get the same result that supported by the TiO2.scf file of the example TiO2. In addition, can you give me a ferromagnetic surface calculation example which includes the main file and detail choice in initialization, such as Fe(100) or (110) surface. Thank you very much in advance. Best regards. J.Zhao 28/12/2002/ _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 28 Dec 2002 07:08:01 -0800 (PST) From: sayede adlane Subject: Re: [WIEN]: question about c/a in "OPTIMIZE" ==== sayede adlane submitted the following contribution: ==== Hi, I guess that you have to update your optimize and w2web. Doing that you can use the "new" optimize script to vary c/a or b/a with v=cst for orthorhombic structure. Adlane Best wish - --- liu wan wrote: > ==== > "liu wan" > submitted the following contribution: > ==== > > Dear Dr. A. Postnikov > > Thank you > > Liu > > >From: "A. Postnikov" > >Reply-To: wien@zeus.theochem.tuwien.ac.at > >To: wien@zeus.theochem.tuwien.ac.at > >Subject: Re: [WIEN]: question about c/a in > "OPTIMIZE" > >Date: Fri, 27 Dec 2002 17:35:45 +0100 (MEZ) > > > >==== > >"A. Postnikov" > >submitted the following contribution: > >==== > > > >Addressing the "mistery" of changing C/A in > "optimize": > > > >Without a fresh look into the "optimize" script - > that used to be > >quite straightforward - I'd guess that the option > of changing > >C/A assumes you have tetragonal (or, hex or rhombo) > structure, > >i.e., lattice parameters A A C, that's why the > script forces > >B=A in your case. This makes sense because > >if your structure is orthorhombic the script > doesn't know > >what you want to do with the third parameter - keep > it fixed? > >Scale along with A? Or with C? That is an example > of situation > >where the user has better to understand what he/she > is doing. > >For optimizing the structure you'd need to vary all > three > >parameters in some way, for each trial volume, that > makes > >TWO independent parameters to vary, and not just > C/A. > >A foolproof advice: prepare a sequence of struct > files > >by hand, varying the parameters in a way (and > within limits) > >that make sense for your structure, for example > changing > >A and B independently so as to keep A*B*C=const, > >then fit the total energy as function of these two > variables to find > >the local minimum for the given volume, refine if > necessary, etc. > >And don't forget, if you have internal coordinates > you must > >in principle vary them simultaneously... > > > >Hopefully it helps, > > > >Andrei Postnikov > > +---------- Dr. habil. Andrei Postnikov ----- > apostnik@uos.de > >----------+ > > | Universitaet Osnabrueck - Fachbereich Physik, > D-49069 Osnabrueck, > >Germany | > > +---------- Tel. +49-541-9692377 ------- Fax > +49-541-9692351 > >----------+ > > > > > ==== > > > "liu wan" > > > submitted the following contribution: > > > ==== > > > > > > Dear Dr. Gilles Hug > > > > > > Thank you very much for your reply! > > > > > > Yes, the program use the initial.struct as the > origin file. My initial > >file > > > has a=10.836754, b=9.571427l and c=17.740615, > and I set the change of > >c/a is > > > 1.5% and 3.0%, but from the file > coa___1.5.struct, and coa___3.0.struct, > >I > > > found that a=b in these two file!!! And the > c/a=1.637 in inital.struct, > >but > > > is 1.661 in coa___1.5.struct and c/a is 1.686 in > coa___3.0.struct! I > >want to > > > know the rule of changing c/a in "OPTIMIZE". > > > > > > Best wish > > > > > > liu > > > > > > >==== > >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > >To (un)subscribe send mail to > >majordomo@zeus.theochem.tuwien.ac.at > >==== > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 3 months > FREE*. > http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU= > > http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 16:04:08 +0800 From: =?gb2312?B?1dQg1r684Q==?= Subject: [none] ==== =?gb2312?B?1dQg1r684Q==?= submitted the following contribution: ==== Dear sir: I want to know the detail choices in the "init_lapw" of TiO2, which supplied by WIEN2k. Because I can't get the same result that supported by the TiO2.scf file of the example TiO2. In addition, can you give me a ferromagnetic surface calculation example which includes the main file and detail choice in initialization, such as Fe(100) or (110) surface. Thank you very much in advance. Best regards. J.Zhao 28/12/2002/ _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 10:03:35 +0100 (MET) From: Peter Blaha Subject: [WIEN]: Re: your mail ==== Peter Blaha submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---2105530234-832121234-1041239015=:19613 Content-Type: TEXT/PLAIN; charset=US-ASCII > I want to know the detail choices in the "init_lapw" of TiO2, which > supplied > by WIEN2k. Because I can't get the same result that supported by the > TiO2.scf file of the example TiO2. What means "not the same results" ?? Small differences are possible since the code (and some input-defaults) have changed. > In addition, can you give me a ferromagnetic surface calculation example > which includes the main file and detail choice in initialization, such as > Fe(100) or (110) surface. For Fe(100) try the new "supercell" program. Fe(110) you must create yourself, but I include a 5-layer W(110) struct file for you. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- - ---2105530234-832121234-1041239015=:19613 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="w_110_5l.struct" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="w_110_5l.struct" VGl0bGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ1hZIExBVFRJ Q0UsTk9ORVFVSVYuIEFUT01TOiAzNjVfQ21tbSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KTU9ERSBPRiBDQUxDPVJFTEEg dW5pdD1ib2hyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICA2LjA1NjU3NSAgOC41NjUyODIgMzQuMjYx MTYyIDkwLjAwMDAwMCA5MC4wMDAwMDAgOTAuMDAwMDAwICAgICAgICAgICAg ICAgICAgIA0KQVRPTT0gLTE6IFg9MC4wMDAwMDAwMCBZPTAuMDAwMDAwMDAg Wj0wLjAwMDAwMDAwDQogICAgICAgICAgTVVMVD0gMSAgICAgICAgICBJU1BM SVQ9IDgNClcgMSAgICAgICAgTlBUPSAgNzgxICBSMD0wLjAwMDUwMDAwIFJN VD0gICAgMi4wMDAwICAgWjogNzQuMCAgICAgICAgICAgICAgICAgICANCkxP Q0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAw MDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAw IDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAu MDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0yOiBYPTAuNTAwMDAwMDAgWT0w LjAwMDAwMDAwIFo9MC44NzUwMDAwMA0KICAgICAgICAgIE1VTFQ9IDIgICAg ICAgICAgSVNQTElUPSA4DQogICAgICAtMjogWD0wLjUwMDAwMDAwIFk9MC4w MDAwMDAwMCBaPTAuMTI1MDAwMDANClcgMiAgICAgICAgTlBUPSAgNzgxICBS MD0wLjAwMDUwMDAwIFJNVD0gICAgMi4wMDAwICAgWjogNzQuMCAgICAgICAg ICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6ICAgIDEuMDAwMDAwMCAw LjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAgICAgICAgICAgICAwLjAw MDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAgICAgICAgICAgICAgICAg ICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAwMDANCkFUT009IC0zOiBY PTAuMDAwMDAwMDAgWT0wLjAwMDAwMDAwIFo9MC43NTAwMDAwMA0KICAgICAg ICAgIE1VTFQ9IDIgICAgICAgICAgSVNQTElUPSA4DQogICAgICAtMzogWD0w LjAwMDAwMDAwIFk9MC4wMDAwMDAwMCBaPTAuMjUwMDAwMDANClcgMyAgICAg ICAgTlBUPSAgNzgxICBSMD0wLjAwMDUwMDAwIFJNVD0gICAgMi4wMDAwICAg WjogNzQuMCAgICAgICAgICAgICAgICAgICANCkxPQ0FMIFJPVCBNQVRSSVg6 ICAgIDEuMDAwMDAwMCAwLjAwMDAwMDAgMC4wMDAwMDAwDQogICAgICAgICAg ICAgICAgICAgICAwLjAwMDAwMDAgMS4wMDAwMDAwIDAuMDAwMDAwMA0KICAg ICAgICAgICAgICAgICAgICAgMC4wMDAwMDAwIDAuMDAwMDAwMCAxLjAwMDAw MDANCiAgIDggICAgICBOVU1CRVIgT0YgU1lNTUVUUlkgT1BFUkFUSU9OUw0K IDEgMCAwIDAuMDAwMDAwMA0KIDAgMSAwIDAuMDAwMDAwMA0KIDAgMCAxIDAu MDAwMDAwMA0KICAgICAgIDENCi0xIDAgMCAwLjAwMDAwMDANCiAwLTEgMCAw LjAwMDAwMDANCiAwIDAgMSAwLjAwMDAwMDANCiAgICAgICAyDQotMSAwIDAg MC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMCAwLTEgMC4wMDAwMDAw DQogICAgICAgMw0KIDEgMCAwIDAuMDAwMDAwMA0KIDAtMSAwIDAuMDAwMDAw MA0KIDAgMC0xIDAuMDAwMDAwMA0KICAgICAgIDQNCi0xIDAgMCAwLjAwMDAw MDANCiAwLTEgMCAwLjAwMDAwMDANCiAwIDAtMSAwLjAwMDAwMDANCiAgICAg ICA1DQogMSAwIDAgMC4wMDAwMDAwDQogMCAxIDAgMC4wMDAwMDAwDQogMCAw LTEgMC4wMDAwMDAwDQogICAgICAgNg0KIDEgMCAwIDAuMDAwMDAwMA0KIDAt MSAwIDAuMDAwMDAwMA0KIDAgMCAxIDAuMDAwMDAwMA0KICAgICAgIDcNCi0x IDAgMCAwLjAwMDAwMDANCiAwIDEgMCAwLjAwMDAwMDANCiAwIDAgMSAwLjAw MDAwMDANCiAgICAgICA4DQo= - ---2105530234-832121234-1041239015=:19613-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 10:24:24 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: The problem about Etop and Ebottom ==== Peter Blaha submitted the following contribution: ==== > In uplapw1.error,there is something like: > 'SELECT' - no energy limits found for L= 1 > 'SELECT' - E-bottom 1.97000 E-top -200.00000 Read the "faq" pages at www.wien2k.at 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 11:26:05 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: MPI parallel ==== Peter Blaha submitted the following contribution: ==== > I have a problem in running MPI parallel job(54 atom cell, 1 k-point, > .machines file in MPI parallel format). initialization is correct(ie > correct struct and other files). The struct file seems to be correct, but it is still not well set up. You left all RMT values at the default of 2.0, but your Na crystal has very large distances. It will save an order of magnitude when you increase RMT from 2.0 to e.g. 2.8 bohr (see the faq page about setting RMTs at www.wien2k.at). > lapw0:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 longhorn1:1 > 1:longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 longhorn1:1 > longhorn1:1 longhorn1:1 > granularity:1 > (8 processors for laow0 and 8 processors for 1 k-point MPI parallel) > > I launched the job on SP4. I don't know what you are doing and it is impossible to say much. If you specified "shared memory machine" during siteconfig, it does not use "rsh" and a .rhosts file is not necessary. If you did not, maybe your system does not allow rsh at all ?? When using poe it does not really use the .machines file. I.e. the details of how many machines are used do not come from .machines, but from the number of processors specified for this poe job. Right? Only to tell WIEN2k that it should use mpi-parallel jobs you must specify the "mpi-syntax" in the .machines file. > files. No error message like I was getting before. BUT at lapw1 -up it > spends enormous amount of time. I waited for 24 hours but nothing is > written to Na.output1_up and does not stop with any error. It seems it It should write to Na.output1up_1 !??? Reduce RKmax (Na.in1) and run x lapw1 -up and x lapw1 -up -p in two different batch jobs. It should create Na.output1up and Na.output1up_1. You get an idea of the timing from the 1-processor job and the parallel job should be faster. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 15:40:02 -0500 From: "Dadi Dai" Subject: [WIEN]: Bandstructure, Error Message ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0121_01C2B019.B7A3C6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I used the program "spaghetti" as a step toward generating = bandstructure. But I met an error message as shown at the end of this = email. The version of "spaghett" was downloaded on Nov. 5, which seems = to be the latest version. Could anyone help me figure out where the problem is? Thank you very much! Dadi Dai Attached: the message that the "spaghett" gave: x spaghetti -up number of k-points read in case.vector=3D 101 k-point nr 41 not treated with irrep k-point nr 42 not treated with irrep k-point nr 43 not treated with irrep k-point nr 44 not treated with irrep k-point nr 45 not treated with irrep k-point nr 46 not treated with irrep k-point nr 47 not treated with irrep k-point nr 48 not treated with irrep k-point nr 49 not treated with irrep k-point nr 50 not treated with irrep k-point nr 51 not treated with irrep k-point nr 52 not treated with irrep k-point nr 53 not treated with irrep k-point nr 54 not treated with irrep k-point nr 55 not treated with irrep k-point nr 56 not treated with irrep k-point nr 57 not treated with irrep k-point nr 58 not treated with irrep k-point nr 59 not treated with irrep k-point nr 60 not treated with irrep k-point nr 61 not treated with irrep k-point nr 101 not treated with irrep band 8 char-min/max: 1.00000000000000002E-2, 5.98699999999999996E-2 band 9 char-min/max: 1.00000000000000002E-2, 5.98680000000000045E-2 band 10 char-min/max: 1.00000000000000002E-2, = 5.98680000000000045E-2 band 11 char-min/max: 1.00000000000000002E-2, = 5.98680000000000045E-2 band 12 char-min/max: 1.00000000000000002E-2, = 5.98700000000000065E-2 band 13 char-min/max: 5.98419999999999994E-2, = 5.98580000000000084E-2 band 14 char-min/max: 5.98419999999999994E-2, = 5.98580000000000084E-2 band 15 char-min/max: 5.98500000000000074E-2, = 5.98700000000000065E-2 band 16 char-min/max: 5.98500000000000074E-2, = 5.98700000000000065E-2 band 17 char-min/max: 5.98600000000000035E-2, = 5.98660000000000095E-2 band 18 char-min/max: 5.98600000000000035E-2, = 5.98660000000000095E-2 band 19 char-min/max: 5.98600000000000035E-2, = 5.98660000000000095E-2 band 20 char-min/max: 5.98620000000000055E-2, = 5.98680000000000045E-2 lib-4212 : UNRECOVERABLE library error An internal WRITE tried to write beyond the end of an internal file. Encountered during a sequential formatted WRITE to an internal file = (character v ariable) IOT Trap Abort (core dumped) 0.5u 0.9s 0:01 98% 0+0k 2+0io 0pf+0w - ------=_NextPart_000_0121_01C2B019.B7A3C6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I used the program "spaghetti" as a step toward generating=20 bandstructure.  But I met an error message as shown at the end of = this=20 email.  The version of "spaghett" was downloaded on Nov. 5, which = seems to=20 be the latest version.
 
Could anyone help me figure out where the problem is?
 
Thank you very much!
 
Dadi Dai
 
Attached: the message that the "spaghett" gave:
 
x spaghetti -up <return>

 number of k-points read in case.vector=3D = 101
 k-point=20 nr  41  not treated with irrep
 k-point nr  = 42  not=20 treated with irrep
 k-point nr  43  not treated with=20 irrep
 k-point nr  44  not treated with = irrep
 k-point=20 nr  45  not treated with irrep
 k-point nr  = 46  not=20 treated with irrep
 k-point nr  47  not treated with=20 irrep
 k-point nr  48  not treated with = irrep
 k-point=20 nr  49  not treated with irrep
 k-point nr  = 50  not=20 treated with irrep
 k-point nr  51  not treated with=20 irrep
 k-point nr  52  not treated with = irrep
 k-point=20 nr  53  not treated with irrep
 k-point nr  = 54  not=20 treated with irrep
 k-point nr  55  not treated with=20 irrep
 k-point nr  56  not treated with = irrep
 k-point=20 nr  57  not treated with irrep
 k-point nr  = 58  not=20 treated with irrep
 k-point nr  59  not treated with=20 irrep
 k-point nr  60  not treated with = irrep
 k-point=20 nr  61  not treated with irrep
 k-point nr  = 101  not=20 treated with irrep
  band 8   char-min/max:=20 1.00000000000000002E-2,  5.98699999999999996E-2
  band=20 9   char-min/max: 1.00000000000000002E-2, =20 5.98680000000000045E-2
  band 10   char-min/max:=20 1.00000000000000002E-2,  5.98680000000000045E-2
  band=20 11   char-min/max: 1.00000000000000002E-2, =20 5.98680000000000045E-2
  band 12   char-min/max:=20 1.00000000000000002E-2,  5.98700000000000065E-2
  band=20 13   char-min/max: 5.98419999999999994E-2, =20 5.98580000000000084E-2
  band 14   char-min/max:=20 5.98419999999999994E-2,  5.98580000000000084E-2
  band=20 15   char-min/max: 5.98500000000000074E-2, =20 5.98700000000000065E-2
  band 16   char-min/max:=20 5.98500000000000074E-2,  5.98700000000000065E-2
  band=20 17   char-min/max: 5.98600000000000035E-2, =20 5.98660000000000095E-2
  band 18   char-min/max:=20 5.98600000000000035E-2,  5.98660000000000095E-2
  band=20 19   char-min/max: 5.98600000000000035E-2, =20 5.98660000000000095E-2
  band 20   char-min/max:=20 5.98620000000000055E-2,  5.98680000000000045E-2
 
lib-4212 : UNRECOVERABLE library error
  An internal WRITE = tried to=20 write beyond the end of an internal file.
 
Encountered during a sequential formatted WRITE to an internal file = (character v
ariable)
IOT Trap
Abort (core dumped)
0.5u 0.9s = 0:01=20 98% 0+0k 2+0io 0pf+0w
 - ------=_NextPart_000_0121_01C2B019.B7A3C6F0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 23:42:59 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Bandstructure, Error Message ==== Peter Blaha submitted the following contribution: ==== > I used the program "spaghetti" as a step toward generating bandstructure. But I met an error message as shown at the end of this email. > > x spaghetti -up > > number of k-points read in case.vector= 101 > k-point nr 41 not treated with irrep > band 20 char-min/max: 5.98620000000000055E-2, 5.98680000000000045E-2 > > lib-4212 : UNRECOVERABLE library error > An internal WRITE tried to write beyond the end of an internal file. > > Encountered during a sequential formatted WRITE to an internal file (character v > ariable) I'm not sure about this, but it seems you have run irrep and/or lapw2 -qtl with a different k-mesh before. Remove all *irrep* files (and maybe also case.qtlup/dn) before running spaghetti (or rerun x irrep -up/dn ) Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 30 Dec 2002 17:56:00 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: test ==== "Dr. B.R.Sahu" submitted the following contribution: ==== testing.... sorry for inconvience. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 10:14:40 +0100 (MET) From: Peter Blaha Subject: [WIEN]: Re: MPI ==== Peter Blaha submitted the following contribution: ==== > 2) I tried the 54 atom supercell with " x lapw1 -up -p" using the > jobscript(1 processor) > > _______________________________________________________________ > #!/usr/bin/csh > #@ job_name = na > #@ output =$(job_name).o$(jobid) > #@ error = $(job_name).o$(jobid) > #@ initialdir = /gpfs/utexas/ph/phaa406/Na.mpi > #@ job_type = parallel > #@ environment = COPY_ALL; MP_SHARED_MEMORY=yes; > #@ resources = ConsumableCpus(1) ConsumableMemory(1gb) > #@ notify_user = sahu@matter3.ph.utexas.edu > #@ node = 1 > #@ tasks_per_node = 1 > #@ class = interactive > #@ notification=error > #@ wall_clock_limit = 1:15:00 > #@ notification=error > #@ notification = complete > #@ queue > ../w2k/x lapw1 -up -p > _________________________________________________~ > > and .machines file > > 1:longhorn1:1 > granularity:1 > > It does produce Na.mpi.output1up_1 in 16 seconds. With this machines file it will use the sequential lapw1. But you could keep task_per_node=1, but in .machines use: 1:longhorn1:1 longhorn1:1 This machines file will force lapw1para to use the poe command and the lapw1_mpi executable, but since the loadleveler ignores any -p xx directives and just uses "task_per_node", it will run the mpi-executable on just one processor. llsubmit produces output and error file *.out and *.err. Is there any message? Another test: For those short runtimes try to run interactively, i.e. execute at the commandline: x lapw1 -up x lapw1 -up -p (with a 2-processor "mpi" .machines file) Any system messages ? > 54 atom supercell atom works fine with k-point parallel mode. No problem. > But in this case I need to choose some finite number of k-points(instead > of 1 k-point) But its the efficiency compared to MPI scripts need to be > checked for the supercell case(with same number of k-points). You can trust me, that for a metallic supercell like yours with such short runtimes the k-point parallel version is by orders of magnitude more efficient!!!! And metallic Na requires many k-points!!!! > If I remember correctly, on SP3 you could run the MPI script without any > problem.am I right? Yes of course. We use wien2k on our SP3 regularely, but I also know that it is used on SP4 in mpi-parallel mode (for matrixsizes up to 15000 !!!) > On SP4, normally the "poe" command preceeds the executables for example > "poe ./wien2k_executable". "poe" calls proper parallel environment > like mpirun, communication routines used during compilation etc. > but in the above I did not use "poe" command and just > ./wien2k_executables -p. > > For checking I tried with poe preceeding ./wien_executables. > ie poe ../w2k/x lapw1 -up -p I guess I explained before: Using x lapw1 -p will call a shell script "lapw1para" which analyses .machines and then issues a "poe lapw1 lapw1.def ... " command. So you must not use poe together with "x", but you could in principle (for testing) use poe with a WIEN-executable. To learn more about that edit lapw1para and put -xf in the first line. This will log all its actions and you will also see the required poe command. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 18:31:07 +0300 (MSK) From: Alexander Korlyukov Subject: [WIEN]: plots of laplacian of electron density ==== Alexander Korlyukov submitted the following contribution: ==== Dear Wien2k users. May I obtain plots of laplacian using aim program? In userguide this possibility is not mentioned. Hovewer, when I saw the documentation concerning aim I found file titled "ToDo" (unfortunately in Spanish) in which is spoken (as I understood spanish text) that aim program can produce plots of laplacian. Details of such procedure is not clear for me because my knowledge of Spanish is bad. Sincerely, A. A. Korlyukov ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 10:38:20 -0500 From: "Dadi Dai" Subject: Re: [WIEN]: Bandstructure, Error Message ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_00A0_01C2B0B8.BC86B110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dr. Blaha, Thanks for your reply! I have tried all of your suggestions, but I = still have the same error message. Could you please give me any futher = comments on how to solve this problem? Thank you! Dadi Dai - ----- Original Message -----=20 From: "Peter Blaha" To: Sent: Monday, December 30, 2002 5:42 PM Subject: Re: [WIEN]: Bandstructure, Error Message > =3D=3D=3D=3D > Peter Blaha > submitted the following contribution: > =3D=3D=3D=3D >=20 > > I used the program "spaghetti" as a step toward generating = bandstructure. > But I met an error message as shown at the end of this email. > > > > x spaghetti -up > > > > number of k-points read in case.vector=3D 101 > > k-point nr 41 not treated with irrep > > band 20 char-min/max: 5.98620000000000055E-2, = 5.98680000000000045E-2 > > > > lib-4212 : UNRECOVERABLE library error > > An internal WRITE tried to write beyond the end of an internal = file. > > > > Encountered during a sequential formatted WRITE to an internal file = (character v > > ariable) >=20 > I'm not sure about this, but it seems you have run irrep and/or lapw2 = - -qtl > with a different k-mesh before. >=20 > Remove all *irrep* files (and maybe also case.qtlup/dn) before running > spaghetti (or rerun x irrep -up/dn ) >=20 > Regards >=20 > P.Blaha - ------=_NextPart_000_00A0_01C2B0B8.BC86B110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear = Dr.=20 Blaha,
 
Thanks for your reply!  I have = tried all of=20 your suggestions, but I still have the same error message.  Could = you=20 please give me any futher comments on how to solve this = problem?
 
Thank you!
 
Dadi Dai
 
----- Original Message -----
From: "Peter Blaha" <pblaha@theochem.tuwien.ac.at>
To: <wien@zeus.theochem.tuwien.ac.at>
Sent: Monday, December 30, 2002 5:42=20 PM
Subject: Re: [WIEN]: Bandstructure, = Error=20 Message

> =3D=3D=3D=3D
> Peter Blaha <pblaha@theochem.tuwien.ac.at>
> submitted the following contribution:
> = =3D=3D=3D=3D
>=20
> > I used the program "spaghetti" as a step toward generating = bandstructure.
> But I met an error message as shown at the end of = this=20 email.
> >
> > x spaghetti -up <return>
>=20 >
> >  number of k-points read in case.vector=3D = 101
>=20 >  k-point nr  41  not treated with irrep
>=20 >   band 20   char-min/max: = 5.98620000000000055E-2, =20 5.98680000000000045E-2
> >
> > lib-4212 : = UNRECOVERABLE=20 library error
> >   An internal WRITE tried to write = beyond=20 the end of an internal file.
> >
> > Encountered = during a=20 sequential formatted WRITE to an internal file (character v
> > = ariable)
>
> I'm not sure about this, but it seems you have = run=20 irrep and/or lapw2 -qtl
> with a different k-mesh before.
> =
>=20 Remove all *irrep* files (and maybe also case.qtlup/dn) before = running
>=20 spaghetti (or rerun x irrep -up/dn )
>
> Regards
> =
>=20             &= nbsp;           &n= bsp;           &nb= sp;=20 P.Blaha
 - ------=_NextPart_000_00A0_01C2B0B8.BC86B110-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 17:16:06 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: plots of laplacian of electron density ==== Peter Blaha submitted the following contribution: ==== > May I obtain plots of laplacian using aim program? > In userguide this possibility is not mentioned. > Hovewer, when I saw the documentation concerning aim I found file titled > "ToDo" (unfortunately in Spanish) in which is spoken (as I understood > spanish text) that aim program can produce plots of laplacian. Details of > such procedure is not clear for me because my knowledge of Spanish is bad. I suggest you use lapw0: Put "potential option"= 36 and R2V in case.in0. x lapw0 case.r2v contains in the "XC-potential" the laplacian of rho. Use lapw5 for plotting (replace clmval by r2v file). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 13:10:55 -0500 From: "Dadi Dai" Subject: Re: [WIEN]: Bandstructure, Error Message ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0124_01C2B0CE.0D30D1D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dr. Blaha, In the file SRC_spaghetti/spag.f Line 431: write(label,878) (jatom_list(j),j=3D1,jatom) where "label" is defined as character*12 in the line 23 of the same = file. I guess the trouble comes here, because "write" should be followed by a = file unit number instead of a string. Could you please let me know how this line should be revised? Thanks! Dadi Dai - ----- Original Message -----=20 From: "Peter Blaha" To: Sent: Monday, December 30, 2002 5:42 PM Subject: Re: [WIEN]: Bandstructure, Error Message > =3D=3D=3D=3D > Peter Blaha > submitted the following contribution: > =3D=3D=3D=3D >=20 > > I used the program "spaghetti" as a step toward generating = bandstructure. > But I met an error message as shown at the end of this email. > > > > x spaghetti -up > > > > number of k-points read in case.vector=3D 101 > > k-point nr 41 not treated with irrep > > band 20 char-min/max: 5.98620000000000055E-2, = 5.98680000000000045E-2 > > > > lib-4212 : UNRECOVERABLE library error > > An internal WRITE tried to write beyond the end of an internal = file. > > > > Encountered during a sequential formatted WRITE to an internal file = (character v > > ariable) >=20 > I'm not sure about this, but it seems you have run irrep and/or lapw2 = - -qtl > with a different k-mesh before. >=20 > Remove all *irrep* files (and maybe also case.qtlup/dn) before running > spaghetti (or rerun x irrep -up/dn ) >=20 > Regards >=20 > P.Blaha - ------=_NextPart_000_0124_01C2B0CE.0D30D1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Dr. Blaha,
 
In the file = SRC_spaghetti/spag.f
 
Line 431:
write(label,878)=20 (jatom_list(j),j=3D1,jatom)
 
where "label" is defined as = character*12 in the=20 line 23 of the same file.
 
I guess the trouble comes here, because = "write"=20 should be followed by a file unit number instead of a = string.
 
Could you please let me know how this = line should=20 be revised?
 
Thanks!
 
Dadi Dai
 
----- Original Message -----
From: "Peter Blaha" <pblaha@theochem.tuwien.ac.at>
To: <wien@zeus.theochem.tuwien.ac.at>
Sent: Monday, December 30, 2002 5:42=20 PM
Subject: Re: [WIEN]: Bandstructure, = Error=20 Message

> =3D=3D=3D=3D
> Peter Blaha <pblaha@theochem.tuwien.ac.at>
> submitted the following contribution:
> = =3D=3D=3D=3D
>=20
> > I used the program "spaghetti" as a step toward generating = bandstructure.
> But I met an error message as shown at the end of = this=20 email.
> >
> > x spaghetti -up <return>
>=20 >
> >  number of k-points read in case.vector=3D = 101
>=20 >  k-point nr  41  not treated with irrep
>=20 >   band 20   char-min/max: = 5.98620000000000055E-2, =20 5.98680000000000045E-2
> >
> > lib-4212 : = UNRECOVERABLE=20 library error
> >   An internal WRITE tried to write = beyond=20 the end of an internal file.
> >
> > Encountered = during a=20 sequential formatted WRITE to an internal file (character v
> > = ariable)
>
> I'm not sure about this, but it seems you have = run=20 irrep and/or lapw2 -qtl
> with a different k-mesh before.
> =
>=20 Remove all *irrep* files (and maybe also case.qtlup/dn) before = running
>=20 spaghetti (or rerun x irrep -up/dn )
>
> Regards
> =
>=20             &= nbsp;           &n= bsp;           &nb= sp;=20 P.Blaha
 - ------=_NextPart_000_0124_01C2B0CE.0D30D1D0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 31 Dec 2002 19:47:05 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MINI ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers I wish use the "min_lapw" script for internal parameter optimization. I browsed through the mail-digest for previous queries. and also gone through the usersguide and FAQ on minimization of forces. A] I found the following command: min_lapw -I -s 1 -i 30 -j run(sp)_lapw -I -fc 1 -p The meaning of -I and/or -fc is clear in runsp_lapw command. -i 30 is to do maximum 30 geometry optimization steps(defalut is 50). and by default, 20 iteration scf steps will be done (in parallel due to -p switch) for a particular geometry optimization step ie for each geometry optimization step(maximum 30 above),20 scf cycles will be done. At the last step of geometry optimization, -I in runsp_lapw switch "TOT" to "FOR" in case.in2(c) (to take into account the incomplete basis set correction or pulay force correction).Is the interpretation correct? But what does -I - -s 1 infront of min_lapw means. B] In the case.inM file : NEWT 1.0 #(NOSE, NEWT, BFGS, MOLD, tolf (a4,f5.2)) 5.0 5.0 5.0 0.8 # Atom1 (NOSE, MOLD:Masse, delta t, T, nose-frequency) 5.0 5.0 5.0 0.8 # Atom2 (NEWT: 1,2,3:delta, 4:eta(1=MOLD)) 5.0 5.0 5.0 0.8 # Atom3 (BFGS, NEWT: [ 1 || 2 || 3 ] = 0 constraint) the number of atoms for which one wish to perform geometry optimization is total number of atoms in the case.struct file OR just number of inequivalant atoms? If BFGS scheme is used for optimization instead of damped Newton scheme then a) friction parameter "eta" should be = 1 ie no friction. is it correct? Or we always have some friction in both schemes. b) tolf determines when geometry optimization stops but -fc 1(ie 1 mRy/bohr) also means geometry optimization stops when this condition is met. Is -fc 1mRy/bohr means when individual component of force on a given atom is less than this value then geometry optimizatin stops OR the total(sum of components) force on a given atom should be less than this value for stopping the geometry optimization criteria? then what does tolf in case.inM does since we already have -fc? is the value -fc 1 overrides the value specified by tolf in case.inM?am I missing something here? c) delta(i) (i =x, y, z) are small increments to the coordinates of each atom(taken from case.struct or case.struct_mini file). that means for each geometry optimizatinon step, these increments are added to the coordinates from the case.strut file in 1st geometry iteration (or case.struct_mini in subsequent iterations) and a chosen optimization scheme is then used for finding the forces and resultant new coordinates. Is it correct? thanking you in advance for answers/suggestions. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 1 Jan 2003 10:35:42 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Bandstructure, Error Message ==== Peter Blaha submitted the following contribution: ==== > In the file SRC_spaghetti/spag.f > > Line 431: > write(label,878) (jatom_list(j),j=1,jatom) > > where "label" is defined as character*12 in the line 23 of the same file. > > I guess the trouble comes here, because "write" should be followed by a file unit number instead of a string. > > Could you please let me know how this line should be revised? This line is ok. One can do a "write" to a character variable. I guess your insp file is wrong (last lines where eventually some fat-band parameters are specified). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 2 Jan 2003 12:42:29 +0100 From: Stefaan Cottenier Subject: Re: [WIEN]: MINI ==== Stefaan Cottenier submitted the following contribution: ==== > ==== > "Dr. B.R.Sahu" > submitted the following contribution: > ==== > > A] I found the following command: > > min_lapw -I -s 1 -i 30 -j run(sp)_lapw -I -fc 1 -p > >(...) > > Is the interpretation correct? Yes. > But what does -I -s 1 infront of min_lapw means. The -I tells that mini should forget the history of previous changes of the internal parameters. It should be used when you start mini for the first time, or when you have changed your case.inM and want to restart with these other values. Use -NI instead when you want to continue the minimization if it has stopped too early (e.g. because -i 30 was reached) but has no errors or problems otherwise. The -s 1 tells that it should save the clm* and scf file at every change of positions, with -s 5 this is only after each 5th change of position, etc. > B] In the case.inM file : > > NEWT 1.0 #(NOSE, NEWT, BFGS, MOLD, tolf (a4,f5.2)) > 5.0 5.0 5.0 0.8 # Atom1 (NOSE, MOLD:Masse, delta t, T, > nose-frequency) > 5.0 5.0 5.0 0.8 # Atom2 (NEWT: 1,2,3:delta, 4:eta(1=MOLD)) > 5.0 5.0 5.0 0.8 # Atom3 (BFGS, NEWT: [ 1 || 2 || 3 ] = 0 constraint) > > the number of atoms for which one wish to perform geometry optimization > is total number of atoms in the case.struct file OR just number of > inequivalant atoms? The number of inequivalent ones. > If BFGS scheme is used for optimization instead of damped Newton scheme > then > > a) friction parameter "eta" should be = 1 ie no friction. is it correct? > Or we always have some friction in both schemes. Eta=1 is no friction. This is useless for minimization, as the atoms will continue to oscillate forever. The MOLD keyword for molecular dynamics is effictively NEWT with zero friction. > b) tolf determines when geometry optimization stops but -fc 1(ie 1 > mRy/bohr) also means geometry optimization stops when this condition is > met. > > Is -fc 1mRy/bohr means when individual component of force on a given atom > is less than this value then geometry optimizatin stops OR the total(sum > of components) force on a given atom should be less than this value for > stopping the geometry optimization criteria? I'm not sure, but it should be easy to test. > then what does tolf in case.inM does since we already have -fc? is the > value -fc 1 overrides the value specified by tolf in case.inM?am I > missing something here? tolf in case.inM tells when the mini scf cycle should stop, i.e. when the forces on all atoms are close enough to zero. -fc tells when the regular electronic scf cycle should stop, i.e. when all forces are sufficiently stable (but not necessarily zero). > c) delta(i) (i =x, y, z) are small increments to the coordinates of each > atom(taken from case.struct or case.struct_mini file). that means for each > geometry optimizatinon step, these increments are added to the coordinates > from the case.strut file in 1st geometry iteration (or case.struct_mini > in subsequent iterations) and a chosen optimization scheme > is then used for finding the forces and resultant new coordinates. Is it > correct? Almost. The forces are determined by a regular electronic scf calculation, the minimization scheme determines the new positions from the the forces and the old positions. Stefaan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 2 Jan 2003 14:33:37 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: MINI ==== "Kevin Jorissen" submitted the following contribution: ==== . > > > b) tolf determines when geometry optimization stops but -fc 1(ie 1 > > mRy/bohr) also means geometry optimization stops when this condition is > > met. > > > > Is -fc 1mRy/bohr means when individual component of force on a given atom > > is less than this value then geometry optimizatin stops OR the total(sum > > of components) force on a given atom should be less than this value for > > stopping the geometry optimization criteria? Tolf is compared to the total force on an atom in a converged calculation. (given in case.scfm (and copied to case.scf)). So optimization stops when all atoms have total forces smaller than tolf mRy. fc is used only within one step of the optimization, as already explained by Stefaan Cottenier (it is the equivalent of -ec 0.0001, eg.). fc 1 does not mean that SCF runs until the force is smaller than 1 mRy, but until the size of the force is converged to within 1. (I don't know whether total or separate components are compared to determine force convergence. Components seem to be more logical?). [By the way, you may have noticed that in the last cycle of an scf-calculation, the force is a lot different from the previous cycles - even though the calculation is said to be converged w.r.t. forces. This is because a certain contribution to the forces which is not important for the convergence is calculated only in the last iteration. Nothing to worry about.] Kevin Jorissen kevin.jorissen@ua.ac.be ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 2 Jan 2003 13:52:09 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: initso script ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers thanks to Prof. Cottenier and Kevin Jorissen for clarifying MINI queries. Is it possible for me to know as how to come out of k-point generation cycle while initializing the run for SO using initso_lapw script?b'cause once the number of k-points is chosen, and kgen -so is run by the script, it asks again Do you want to rerun kgen ? (y/N) If I say, No or N or n, It stops with the error if: Badly formed number and If I say yes or Y or y, it continues and again asks the same thing. Does the initialization script initso_lapw needs modification? thanks for your attention/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 2 Jan 2003 14:27:22 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: runsp_script ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers, 1) While running SO+ORB for a spin-polarized system using runsp_lapw - -orb -so, I encountered an error in the 2nd scf cycle: ____________________________________________________________ in cycle 2 ETEST: 106.6573260000000000 CTEST: 1.8484003 hup: Command not found. STOP LAPW0 END STOP ORB END STOP ORB END if: Badly formed number.---> it stops here with this message. I checked the "runsp_script". The end of the section orb: ____________________________________________---- orb: foreach i (dmatup dmatdn dmatud ) if (-e $file.$i"_old" ) rm $file.$i"_old" if (-e $file.$i ) cp $file.$i $file.$i"_old" #save this cycle for next end if ( -e $file.scforbup ) rm $file.scforbup if ( -e $file.scforbdn ) rm $file.scforbdn if ( -e $file.scforbdu ) rm $file.scforbdu if ( "$orb" != "-orb" ) goto lapw1 if ( $?orbc ) goto lapw1 if (! -e $file.dmatup || -z $file.dmatup ) goto lapw1 #foreach i ( vorbup vorbdn vorbdu ) # if (-e $file.$i ) \ # cp $file.$i $file.$i"_old" #save last cycle #end testinput $file.inorb error_input total_exec orb -up $para total_exec orb -dn $para if ( "$so" == "-so" && -s $file.dmatud ) then total_exec orb -du $para endif ______________________________________ It is trying to calculate orb -du $para if -so switch and case.dmatud exists. I checked that file case.dmatud is created in the first iteration by x lapwdm in addition to case.dmatup and case.dmatdn and also it is SO calculation. but as soon as the control goes to if ( "$so" == "-so" && -s $file.dmatud ) it stops with the message: if: Badly formed number. The procedure I followed is: _________________________________________________________________ I first did the spinpolarized scf calculation without SO and orbital potentials ie just runsp_lapw.proper convergence achieved. To add SO and orbital potential starting with this: a) initso_lapw --> it created a the case.inso and other case.*_so files including proper struct file(the case.*_so files and case.struct_so are copied to corresponding case.* files) b) prepared the proper case.indmc and case.inorb file. c) finally "runsp_lapw -orb -so. ______________________________________ I contacted Prof. Novak regarding this(I couldnot put this qurey that time on w2k mailing list due to problem in accessing w2k server. All my mails to w2k mailing list that time returned but it is workig now!!) and thanks to him he suggested that the problem might be connected with the nondiagonal term of the orbital potential ()and there seems to be some bug there. He gave me his own shell script "joborb"(equivalant to runsp_lapw -so - -orb) and suggested me to first do 1 iteration only without -orb switch in lapwso(so that case.vorbup and case.vorbdn is first produced in -orb - -up/dn later in the one iteration cycle) and then add again -orb switch to lapwso run the cycle for required number of iterations(say 40).Now since case.vorbup/dn files are there these will be used by lapwso -orb. I didnot encounter any problem so far. However the convergnce conditions(:DIS, :ENE, :FOR, :MMI0XX etc) are to be monitered manually now!! Also he mentioned that Prof. Peter Blaha removed this term from the scripts running WIEN some time ago, but perhaps some remnant remained. I downloaded the latest w2k and the above error is from this latest download. but I dont know whether It is taken care of now. 2) If I have a completed run (but not converged, say with 20 iteration) with PRATT mixing scheme, then can I switch to BROYD mixing scheme(by changing PRATT to BROYD and FACTOR to say 0.4 in case.inm file) without deleting any files from the PRATT mixing scheme run and continuing with BROYD for convergence? thanks in advance for your attention and suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 3 Jan 2003 13:37:29 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MIXER ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users 1) Yesterday I sent an qurey regaring change from PRATT to BROYD scheme. If any w2kuser had a simillar situation and has an answer, pl. let me know. I also had an query about intiso_lapw and runsp_lapw script. I repeat the mixing qurery only. If I have a completed run (but not converged, say with 20 iteration) with PRATT mixing scheme, then if I wish to switch to BROYD mixing scheme(by changing PRATT to BROYD and FACTOR to say 0.4 in case.inm file) do I have to delete/save any file before I start the run again with BROYD mixing scheme. 2) I observed the following: When I have a run , spin-polarized, SO+ORB starting from scratch, even if the case.inm and case.inorb file both has BROYD scheme with FACTOR 0.4, the case.scf file has the written "PRATT MIXING SCHEME WITH 0.400"!!! I monitored it for few iteration, BROYD is not used at all. However, for just spinpolarized(runsp) run OR spinpolarized with spin-orbit(runsp -so), it correctly picks up BROYD from case.inm file. Does this mean there is some problem with -orb while calling MIXER? so even if BROYD is specified in case.inm/case.inorb, PRATT will be picked up by default? thanking you in advance for your suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #50 **************************** From: owner-wien-digest@theochem.tuwien.ac.at (wien-digest) To: wien-digest@theochem.tuwien.ac.at Subject: wien-digest V2002 #51 Reply-To: wien Sender: owner-wien-digest@theochem.tuwien.ac.at Errors-To: owner-wien-digest@theochem.tuwien.ac.at Precedence: bulk wien-digest Sunday, January 12 2003 Volume 2002 : Number 051 ---------------------------------------------------------------------- Date: Fri, 03 Jan 2003 19:22:44 -0300 From: Gabriela Fernanda Cabeza Subject: [WIEN]: Compiling TELNES ==== Gabriela Fernanda Cabeza submitted the following contribution: ==== Dear Wien users, When recompiling TELNES on a Linux box with g77 (recommended) i got the following error file (compile.msg) at SRC_telnes directory: - --------------------------------------------------------------------------- g77 -O -c telnes.f telnes.f: In subroutine `firstcase': telnes.f:2080: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:2085: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f: In subroutine `secondcase': telnes.f:2143: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:2148: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] make: *** [telnes.o] Error 1 - --------------------------------------------------------------------------- Has anybody had the same errors? Thank you very much in advance for every hint. Kind regards Dra. Gabriela F. Cabeza Profesora Adjunta Dpto. de Física - Universidad Nacional del Sur Avda. Alem 1253, (B8000CPB) Bahía Blanca - Argentina tel: 54-291- 4595141- 54-291-4595101, int. 2821 fax: 54-291-4595142 e-mail: gcabeza@criba.edu.ar ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 3 Jan 2003 19:51:35 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: MINI ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers while using case.inM file for min_lapw, Is there any guideline for choosing delta(i) valuesfor say BFGS or NEW scheme and not molecular dynamics? does it depend upon the type of atoms which are to be moved? or anything else?b'cause we may achieve the the chosen "tolf" value in smallar number of geometry optimization steps by tuning the values of delta(i) numbers in case.inM before starting the min_lapw. thanking you in advance for suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 4 Jan 2003 08:40:49 -0800 (PST) From: Hadi Arabi Subject: [WIEN]: force minimizung ==== Hadi Arabi submitted the following contribution: ==== Dear wien user I work on Re-123 high temperature superconductor materials which has 13 atoms in unit cell.In order to start analysise we have to minimize the forces upon the atoms which end up with the following amount of forces in Z-direction: Force on atom No.2 =0.239 Force on atom No.4 =0.495 Force on atom No.5=-0.241 Force on atom No.6=0.54 force on atom No.7 = 0.34 The forces on the rest of the atoms are zero. My question is: Can I start analysis with this kind of forces on atom? Because I tried to change the positions of the atoms to reduce the forces, but some of them reduce and some other again increase. What can I do for this problem? Best regard Hadi __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sat, 4 Jan 2003 20:49:34 -0500 (EST) From: Dadi Dai Subject: [WIEN]: Why does LDA+U stop at the second cycle? ==== Dadi Dai submitted the following contribution: ==== I wish to do LDA+U calculation for Cu4O3. I used "runsp -orb", and the calculation stopped at the beginning of the second cycle. I don't know why and hope to get some help. The error message is: ....................cycle 1................... STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPW2 END STOP LAPW2 END STOP lapwdm END STOP lapwdm END STOP CORE END STOP CORE END STOP MIXER END ..............cycle 2.................. STOP LAPW0 END 1525-001 The READ statement on the file Cu4O3.dmatup cannot be completed because the end of the file was reached. The program will stop. I found the file "uporb.error" that shows "Error in Vorb". The :log file shows: > (runsp) options: -orb -i 40 -cc 0.0001 Fri Jan 3 15:56:23 EST 2003> (x) lapw0 Fri Jan 3 15:57:02 EST 2003> (x) lapw1 -up -orb Fri Jan 3 16:11:31 EST 2003> (x) lapw1 -dn -orb Fri Jan 3 16:25:58 EST 2003> (x) lapw2 -up Fri Jan 3 16:27:31 EST 2003> (x) lapw2 -dn Fri Jan 3 16:29:00 EST 2003> (x) lapwdm -up Fri Jan 3 16:29:05 EST 2003> (x) lapwdm -dn Fri Jan 3 16:29:09 EST 2003> (x) lcore -up Fri Jan 3 16:29:10 EST 2003> (x) lcore -dn Fri Jan 3 16:29:11 EST 2003> (x) mixer Fri Jan 3 16:29:16 EST 2003> (x) lapw0 Fri Jan 3 16:29:57 EST 2003> (x) orb -up The Cu4O3.inorb that I used is: 1 2 0 BROYD 0.25 1 1 2 2 1 2 1 0.55127 0.055127 U,J 0.55127 0.055127 U,J The Cu4O3.indm that I used is: - -9.0 2 1 1 2 1 1 2 0 0 I wonder if the inputs are correct. Could anyone help me? Thank you very much! Dadi Dai ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 12:42:45 +0800 From: "yulihua" Subject: [WIEN]: case.in2 for electron density plots ==== "yulihua" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0054_01C2B581.1CD0CD90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpEZWFyIEFsbDoNCiAgICAgDQogICAgICAgICAgIFdoZW4gY2FsY3VsYXRlIHRoZSBlbGVjdHJv biBkZW5zaXR5ICwgSSBjaGFuZ2UgdGhlIEVNSU4gdG8gLTEuMCB0byBlbGltaW5hdGUgc29tZSBs b3dlciBzZW1pY29yZSBzdGF0ZXMgKGZvciBleGFtcGxlIFRpIDNzIDNwIGluIFRpQyksICB3aGV0 aGVyIEkgbXVzdCBjaGFuZ2UgdGhlIG5lIFsgbnVtYmVyIG9mIGVsZWN0cm9ucyAocGVyIHVuaXQg Y2VsbCkgaW4gdGhlIGVuZXJneSByYW5nZSwgIHNhaWQgaW4gdGhlIHVzZXJndWlkZSBzZWN0aW9u IDcuNF0gLCBiZWNhdXNlIGluIHRoYXQgZW5lcmd5IHJhbmdlIEkgY2hvb3NlLCB0aGUgbmUgaXMg ZGlmZmVyZW50IGZyb20gdGhlIHNpdHVhdGlvbiBmb3Igc2NmIGNhbGN1bGF0aW9uIC4NCiAgICAg ICAgICAgSSB0cnkgdG8gZGVjcmVhc2UgdGhlIG5lLCBvYnRhaW4gdGhlIGRpZmVyZW50IHJlc3Vs dCBvZiBlbGVjdHJvbiBkZW5zaXR5ICwgYW5kIGZvciB0aGUgVGlDIGV4YW1wbGUgLCB0aGUgdXNl cmd1aWRlIGRvbid0IHNheSB0byBjaGFuZ2UgdGhlIG5lIHZhbHVlLiAgV2hldGhlciBtdXN0IGNo YW5nZSB0aGUgbmUgdmFsdWU/DQoNCg0KdGhhbmtzDQoNCg0K - ------=_NextPart_000_0054_01C2B581.1CD0CD90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDUyMi4xODAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+RGVhciBBbGw6PC9ESVY+DQo8RElW PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gY2FsY3VsYXRl IA0KdGhlJm5ic3A7ZWxlY3Ryb24gZGVuc2l0eSAsJm5ic3A7SSBjaGFuZ2UgdGhlIEVNSU4gdG8g LTEuMCB0byBlbGltaW5hdGUgc29tZSANCmxvd2VyIHNlbWljb3JlIHN0YXRlcyAoZm9yIGV4YW1w bGUgVGkgM3MgM3AgaW4gVGlDKSwmbmJzcDsgd2hldGhlciBJIG11c3QgY2hhbmdlIA0KdGhlIG5l Jm5ic3A7WyBudW1iZXIgb2YgZWxlY3Ryb25zIChwZXIgdW5pdCBjZWxsKSBpbiB0aGUgZW5lcmd5 IHJhbmdlLCZuYnNwOyANCnNhaWQgaW4gdGhlIHVzZXJndWlkZSBzZWN0aW9uIDcuNF0mbmJzcDss IGJlY2F1c2UgaW4mbmJzcDt0aGF0IGVuZXJneSByYW5nZSBJIA0KY2hvb3NlLCB0aGUgbmUgaXMg ZGlmZmVyZW50IGZyb20gdGhlJm5ic3A7c2l0dWF0aW9uIGZvciBzY2YgDQpjYWxjdWxhdGlvbiZu YnNwOy48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdHJ5IHRvIA0KZGVjcmVhc2UgdGhlIG5lLCBvYnRhaW4g dGhlIGRpZmVyZW50IHJlc3VsdCBvZiBlbGVjdHJvbiBkZW5zaXR5ICwgYW5kIGZvciB0aGUgDQpU aUMgZXhhbXBsZSAsIHRoZSB1c2VyZ3VpZGUgZG9uJ3Qgc2F5IHRvIGNoYW5nZSB0aGUgbmUgdmFs dWUuJm5ic3A7IFdoZXRoZXIgbXVzdCANCmNoYW5nZSB0aGUgbmUgdmFsdWU/PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+dGhhbmtzPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1M Pg0K - ------=_NextPart_000_0054_01C2B581.1CD0CD90-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 09:12:42 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: force minimizung ==== "Kevin Jorissen" submitted the following contribution: ==== Your forces are very small. You should be able to analyze your system this way. kind regards, Kevin Jorissen. - ----- Original Message ----- From: "Hadi Arabi" To: Cc: Sent: Saturday, January 04, 2003 5:40 PM Subject: [WIEN]: force minimizung > ==== > Hadi Arabi > submitted the following contribution: > ==== > > Dear wien user > I work on Re-123 high temperature superconductor > materials which has 13 atoms in unit cell.In order to > start analysise we have to minimize the forces upon > the atoms which end up with the following amount of > forces in Z-direction: > Force on atom No.2 =0.239 > Force on atom No.4 =0.495 > Force on atom No.5=-0.241 > Force on atom No.6=0.54 > force on atom No.7 = 0.34 > The forces on the rest of the atoms are zero. > My question is: > Can I start analysis with this kind of forces on atom? > Because I tried to change the positions of the atoms > to reduce the forces, but some of them reduce and some > other again increase. What can I do for this problem? > Best regard > Hadi > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 06 Jan 2003 16:49:23 +0800 From: "liu wan" Subject: [WIEN]: question about how to use OPTIC ==== "liu wan" submitted the following contribution: ==== Dear All I try to calculated the optical properties of a semi-conductor. But I find that the reult in the case.joint is: Some position is very large and the other position is zero. What is wrong? 2 Energy [eV] Im_eps_xx Im_eps_zz 0.00000 0.84051298E+89 0.00000000E+00 0.01361 0.17131700E-07 0.00000000E+00 0.02721 0.10498127+277 0.00000000E+00 0.04082 0.22762560E-16 0.00000000E+00 0.05442 0.66295283E-08 0.00000000E+00 0.06803 0.15973640+272 0.00000000E+00 0.08163 0.21894908E-16 0.00000000E+00 0.09524 0.21233672-152 0.00000000E+00 0.10885 0.44776644+218 0.00000000E+00 0.12245 0.51962383E+46 0.00000000E+00 0.13606 0.46566129E-09 0.00000000E+00 0.14966 0.00000000E+00 0.00000000E+00 0.16327 0.00000000E+00 0.00000000E+00 0.17687 0.00000000E+00 0.00000000E+00 Best wish Liu _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?page=features/virus ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 10:47:36 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Compiling TELNES ==== "Kevin Jorissen" submitted the following contribution: ==== People have had problems like this before (though I think it's been a long time since I read about it, maybe there's more in the mail digest). Try replacing all the real statements by double precisions, i.e. DBLE(blabla) instead of REAL(blabla). You will probably be able to compile the program afterwards. kind regards, Kevin Jorissen kevin.jorissen@ua.ac.be - ----- Original Message ----- From: "Gabriela Fernanda Cabeza" To: Sent: Friday, January 03, 2003 11:22 PM Subject: [WIEN]: Compiling TELNES > ==== > Gabriela Fernanda Cabeza > submitted the following contribution: > ==== > > Dear Wien users, > > When recompiling TELNES on a Linux box with g77 (recommended) i got the > following > error file (compile.msg) at SRC_telnes directory: > > -------------------------------------------------------------------------- - - > > g77 -O -c telnes.f > telnes.f: In subroutine `firstcase': > telnes.f:2080: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f:2085: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f: In subroutine `secondcase': > telnes.f:2143: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f:2148: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > make: *** [telnes.o] Error 1 > > -------------------------------------------------------------------------- - - > > Has anybody had the same errors? > > Thank you very much in advance for every hint. > Kind regards > > > > > Dra. Gabriela F. Cabeza > Profesora Adjunta > Dpto. de Física - Universidad Nacional del Sur > Avda. Alem 1253, (B8000CPB) Bahía Blanca - Argentina > tel: 54-291- 4595141- 54-291-4595101, int. 2821 > fax: 54-291-4595142 > e-mail: gcabeza@criba.edu.ar > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 10:56:04 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Compiling TELNES ==== "Kevin Jorissen" submitted the following contribution: ==== Hello again, I found this in the archives, first a question by Nitya Nath Shukla, a reply by Joachim Luitz, and a comment by some guy named Andrew. In case you are using an old wien version, why not upgrade to WIEN2k? It's faster, has more features, and you'll get the hang of it in no time. The telnes part is still the same as in wien97. good luck! Kevin Jorissen kevin.jorissen@ua.ac.be Date: Mon, 19 Jun 2000 17:13:27 +0530 (IST) From: Nitya Nath Shukla phd phy Subject: [WIEN]: Errors in compilation ==== Nitya Nath Shukla phd phy submitted the following contribution: ==== Respected Sir, I am getting this error in compilation. I am using Linux Redhat 6.1 OS. g77 -O -c kram.f kram.f: In program `kram': kram.f:233: write(12,113) xe(i),(real(eps(i,j)),imag(eps(i,j)),j=1,ncol) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] kram.f:234: write(13,113) xe(i),(real(sig(i,j)),imag(sig(i,j)),j=1,ncol) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] kram.f:235: write(14,113) xe(i),(real(sig(i,j))*sigf1/sigf,j=1,ncol), ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] make: *** [kram.o] Error 1 g77 -O -c telnes.f telnes.f: In subroutine `cspech': telnes.f:1857: + + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1869: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1875: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1878: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1881: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1890: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1893: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1900: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1903: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1907: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1910: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1915: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:1918: + REAL (Factor3 * Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f: In subroutine `firstcase': telnes.f:2080: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:2085: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f: In subroutine `secondcase': telnes.f:2143: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:2148: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] make: *** [telnes.o] Error 1 Is this problem of compiles or somthing else... With regards.. Nitya Nath ************************************************************** Nitya Nath Shukla HOSTEL: C-209,Hall - 5, I.I.T. KANPUR-208016 Physics Deptt. Phone : 0512 - 597115 Indian Institute Of Technology 0512 - 597315 Kanpur - UP. Email- nitsu@mailcity.com INDIA - nitya@iitk.ac.in Pin - 208016 Resi: 1313,Ratan Lal Nagar Kanpur - 208022 Phone:(0512)-280445 ************************************************************ ANSWER I guess you are using an older version of WIEN. In WIEN97.9 these statements have been changed to DBLE, which should compile on all F77 compilers. You can also change the REAL(...) statements to DBLE(...) by hand in the routines kram.f and telnes.f > Is this problem of compiles or somthing else... Compilation, indeed. Best regards Joachim Luitz "Recursion n.: See Recursion. -- Random Shack Data Processing Dictionary " - - -- --------------------------------------------------------------------- | Dipl.-Ing. Joachim Luitz | j.luitz@tuwien.ac.at | | Vienna University of Technology | http://www.tuwien.ac.at/theochem | | Inst. of Physical and | Tel: +43 1 58801-15679 | | Theoretical Chemistry | Fax: +43 1 58801-15698 | | Getreidemarkt 9/156 | | | A-1060 Wien/AUSTRIA | private: jluitz@music.at | --------------------------------------------------------------------- COMMENT telnes.f: In subroutine `firstcase': telnes.f:2080: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f:2085: + REAL(Factor1*Factor2*Factor3*Factor4) ^ Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] telnes.f: In subroutine `secondcase': telnes.f:2143: + REAL(Factor1*Factor2*Factor3*Factor4) ^ - - -------------------------------------------------------------------------- - -- Changing these explicitely to DREAL seems to solve this problem. Sorry about the trouble! Cheers, Andrew - ----- Original Message ----- From: "Gabriela Fernanda Cabeza" To: Sent: Friday, January 03, 2003 11:22 PM Subject: [WIEN]: Compiling TELNES > ==== > Gabriela Fernanda Cabeza > submitted the following contribution: > ==== > > Dear Wien users, > > When recompiling TELNES on a Linux box with g77 (recommended) i got the > following > error file (compile.msg) at SRC_telnes directory: > > -------------------------------------------------------------------------- - - > > g77 -O -c telnes.f > telnes.f: In subroutine `firstcase': > telnes.f:2080: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f:2085: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f: In subroutine `secondcase': > telnes.f:2143: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > telnes.f:2148: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f g77 M CMPAMBIG] > make: *** [telnes.o] Error 1 > > -------------------------------------------------------------------------- - - > > Has anybody had the same errors? > > Thank you very much in advance for every hint. > Kind regards > > > > > Dra. Gabriela F. Cabeza > Profesora Adjunta > Dpto. de Física - Universidad Nacional del Sur > Avda. Alem 1253, (B8000CPB) Bahía Blanca - Argentina > tel: 54-291- 4595141- 54-291-4595101, int. 2821 > fax: 54-291-4595142 > e-mail: gcabeza@criba.edu.ar > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 06 Jan 2003 05:16:26 -0500 From: "michel certier" Subject: [WIEN]: parallel execution problem in dual PIV ==== "michel certier" submitted the following contribution: ==== Dear wien users Happy New year !!! I met somme problem to execut a parallel job for cubic system with 35 k-point on dual machine, after 1 iteration the program stop and I get the following message: LAPW0 END LAPW1 END LAPW1 END LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END SUMPARA END SUMPARA END CORE END MIXER END in cycle 2 ETEST: 0 CTEST: 0 PGFIO-F-231/formatted read/unit=8/error on data conversion. File name = test.clmsum formatted, sequential access record = 2223 In source file lapw0.F, at line number 404 cat: No match. My .machines files is : granularity:1 17:localhost 18:localhost The program run well in serial mode. Can some one give me a solution to this problem. Thank's - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 13:20:47 +0100 From: Veerle Vanhoof Subject: [WIEN]: Problems with crystalstructure ==== Veerle Vanhoof submitted the following contribution: ==== - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear wien2k user, When I try to make a crystalstructure consisting of 29 Ag-atoms and 3=20 Co-atoms, all positioned in a supercell (8 fcc-cubes placed to form a=20 supercube with as latticeconstantes twice the ones of Ag-fcc) and the Co'= s=20 positioned at coordinates (0, 0, 0), (0.25, 0.25, 0), (0.5, 0, 0.5), or o= n=20 equivalent positions, sgroup suggests a "better" struct-file. But when I=20 accept this new struct-file there appears to be an inconsistency in the=20 suggested structure.=20 *.outputsgroup starts with the following warningmessage: "warning: !!! Struct file is not consistent with space group found." Ignoring this inconsistency and using an RK_max of 5.0 runs but ends up w= ith=20 forces that diverge rather than converge for almost all inequivalent atom= s. A typical example of this divergence: atom 1 x-component: 5.597 / 5.925 / 6.614 / 7.687 / 8.836 / 10.310 / 11.8= 68 /=20 13.518 / 15.612 / 12.750 / 21.586 / 24.271 / 28.551 / 31.127 / 44.334 Almost all the other atoms behave like atom 1, the exceptions (1 or 2 ato= ms)=20 had already very low forces to start with: atom 23 x-component: 0.383 / 0.374 / 0.405 / 0.462 / 0.462 / 0.478 / 0.55= 4 /=20 0.541 / 0.564 / 1.728 / 0.695 / 0.442 / 0.891 / 0.961 / 0.897=20 z-component: 0.303 / 0.294 / 0.328 / 0.378 / 0.396 / 0.422 / 0.= 513 /=20 0.522 / 0.591 / 1.680 / 0.545 / 0.166 / 0.574 / 0.544 / 0.247 But the components that, more or less, converge are already fixed (veloci= ty 0)=20 in name.inM. I have made 7 other calculations with the 3th Co on a different=20 (nonequivalent) position without any problems at all. It's only this=20 configuration that gives these problems. The used *.struct-, *.inst-file, *.outputsgroup and *.inM-file are in=20 attachement. Does somebody know what the problem can be?=20 Thanks a lot! Veerle Vanhoof Institute for nuclear and radiation fysics Department of Physics Catholic University of Leuven Belgium - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL Content-Type: text/plain; charset="us-ascii"; name="agcork5.inst" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agcork5.inst" Co 1 Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,0.0 N 4,-1,1.0 N 4,-1,1.0 N Co 1 Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,0.0 N 4,-1,1.0 N 4,-1,1.0 N Co 1 Ar 3 5 3, 2,2.0 N 3, 2,2.0 N 3,-3,3.0 N 3,-3,0.0 N 4,-1,1.0 N 4,-1,1.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N Ag 1 Kr 3 5 4, 2,2.0 N 4, 2,2.0 N 4,-3,3.0 N 4,-3,3.0 N 5,-1,1.0 N 5,-1,0.0 N **** End of Input **** End of Input - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL Content-Type: text/plain; charset="us-ascii"; name="agcork5.inM" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agcork5.inM" NEWT 1.0 #(NOSE, NEWT, BFGS, MOLD, tolf (a4,f5.2)) 1.0 1.0 0.0 0.8 # Atom1 (NOSE, MOLD:Masse, delta t, T, nose-frequency) 1.0 1.0 0.0 0.8 # Atom2 (NEWT: 1,2,3:delta, 4:eta(1=MOLD)) 0.0 0.0 0.0 0.8 # Atom3 (BFGS, NEWT: [ 1 || 2 || 3 ] = 0 constraint) 1.0 1.0 0.0 0.8 # Atom4 1.0 1.0 0.0 0.8 # Atom5 0.0 0.0 0.0 0.8 # Atom6 1.0 1.0 0.0 0.8 # Atom7 0.0 0.0 0.0 0.8 # Atom8 1.0 1.0 1.0 0.8 # Atom9 1.0 0.0 1.0 0.8 # Atom10 1.0 1.0 0.0 0.8 # Atom11 1.0 1.0 0.0 0.8 # Atom12 1.0 0.0 1.0 0.8 # Atom13 0.0 0.0 0.0 0.8 # Atom14 1.0 1.0 0.0 0.8 # Atom15 1.0 1.0 0.0 0.8 # Atom16 1.0 1.0 0.0 0.8 # Atom17 1.0 1.0 0.0 0.8 # Atom18 1.0 1.0 0.0 0.8 # Atom19 1.0 1.0 0.0 0.8 # Atom20 1.0 0.0 1.0 0.8 # Atom21 1.0 0.0 1.0 0.8 # Atom22 0.0 0.0 0.0 0.8 # Atom23 0.0 0.0 0.0 0.8 # Atom24 - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL Content-Type: text/plain; charset="us-ascii"; name="agcork5.struct" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agcork5.struct" AgCo P LATTICE,NONEQUIV. ATOMS:24 6 Pm RELA 22.024507 22.024507 22.024507 90.000000 90.000000 90.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Co1 NPT= 781 R0=0.00010000 RMT= 2.2500 Z: 27.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.25000000 Y=0.25000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Co2 NPT= 781 R0=0.00010000 RMT= 2.2500 Z: 27.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.00000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Co3 NPT= 781 R0=0.00010000 RMT= 2.2500 Z: 27.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -4: X=0.50000000 Y=0.00000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag1 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -5: X=0.00000000 Y=0.50000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag2 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -6: X=0.00000000 Y=0.00000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag3 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -7: X=0.50000000 Y=0.50000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag4 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -8: X=0.50000000 Y=0.00000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag5 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -9: X=0.25000000 Y=0.00000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -9: X=0.25000000 Y=0.00000000 Z=0.75000000 Ag6 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-10: X=0.75000000 Y=0.00000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -10: X=0.75000000 Y=0.00000000 Z=0.75000000 Ag7 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-11: X=0.75000000 Y=0.25000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag8 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-12: X=0.25000000 Y=0.75000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag9 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-13: X=0.00000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -13: X=0.00000000 Y=0.25000000 Z=0.75000000 Ag10 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-14: X=0.00000000 Y=0.75000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -14: X=0.00000000 Y=0.75000000 Z=0.75000000 Ag11 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-15: X=0.75000000 Y=0.75000000 Z=0.00000000 MULT= 1 ISPLIT= 8 Ag12 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-16: X=0.25000000 Y=0.25000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag13 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-17: X=0.25000000 Y=0.75000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag14 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-18: X=0.75000000 Y=0.25000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag15 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-19: X=0.75000000 Y=0.75000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag16 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-20: X=0.25000000 Y=0.50000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -20: X=0.25000000 Y=0.50000000 Z=0.75000000 Ag17 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-21: X=0.75000000 Y=0.50000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -21: X=0.75000000 Y=0.50000000 Z=0.75000000 Ag18 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-22: X=0.50000000 Y=0.25000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -22: X=0.50000000 Y=0.25000000 Z=0.75000000 Ag19 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-23: X=0.50000000 Y=0.75000000 Z=0.25000000 MULT= 2 ISPLIT= 8 -23: X=0.50000000 Y=0.75000000 Z=0.75000000 Ag20 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM=-24: X=0.50000000 Y=0.50000000 Z=0.50000000 MULT= 1 ISPLIT= 8 Ag21 NPT= 781 R0=0.00010000 RMT= 2.4000 Z: 47.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 2 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 1 1 0 0 0.0000000 0 1 0 0.0000000 0 0-1 0.0000000 2 - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL Content-Type: text/plain; charset="us-ascii"; name="agcork5.outputsgroup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agcork5.outputsgroup" warning: !!! Struct file is not consistent with space group found. - ---------------------------------------------------------------------- Bravais lattice: Monoclinic primitive a b c 22.02450700 22.02450700 22.02450700 alpha beta gamma 90.00000000 90.00000000 90.00000000 ===== Decomposition of new basis vectors over input basis ===== 1.000000 0.000000 0.000000 <--- 1 0.000000 1.000000 0.000000 <--- 2 0.000000 0.000000 1.000000 <--- 3 ==== Number of atoms in cell: 32 ==== Atom positions: 0.00000000 0.00000000 0.00000000 Co1 0.25000000 0.25000000 0.00000000 Co2 0.00000000 0.50000000 0.50000000 Co3 0.50000000 0.00000000 0.00000000 Ag1 0.00000000 0.50000000 0.00000000 Ag2 0.00000000 0.00000000 0.50000000 Ag3 0.50000000 0.50000000 0.00000000 Ag4 0.50000000 0.00000000 0.50000000 Ag5 0.25000000 0.00000000 0.25000000 Ag6 0.25000000 0.00000000 0.75000000 Ag6 0.75000000 0.00000000 0.25000000 Ag7 0.75000000 0.00000000 0.75000000 Ag7 0.75000000 0.25000000 0.00000000 Ag8 0.25000000 0.75000000 0.00000000 Ag9 0.00000000 0.25000000 0.25000000 Ag10 0.00000000 0.25000000 0.75000000 Ag10 0.00000000 0.75000000 0.25000000 Ag11 0.00000000 0.75000000 0.75000000 Ag11 0.75000000 0.75000000 0.00000000 Ag12 0.25000000 0.25000000 0.50000000 Ag13 0.25000000 0.75000000 0.50000000 Ag14 0.75000000 0.25000000 0.50000000 Ag15 0.75000000 0.75000000 0.50000000 Ag16 0.25000000 0.50000000 0.25000000 Ag17 0.25000000 0.50000000 0.75000000 Ag17 0.75000000 0.50000000 0.25000000 Ag18 0.75000000 0.50000000 0.75000000 Ag18 0.50000000 0.25000000 0.25000000 Ag19 0.50000000 0.25000000 0.75000000 Ag19 0.50000000 0.75000000 0.25000000 Ag20 0.50000000 0.75000000 0.75000000 Ag20 0.50000000 0.50000000 0.50000000 Ag21 ==== Number of nonequivalent sorts: 24 ==== Nonequivalent atoms, point group for each sort: ==== Sort number: 1 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.00000000 0.00000000 0.00000000 Co1 Sort number: 2 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.25000000 0.25000000 0.00000000 Co2 Sort number: 3 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.00000000 0.50000000 0.50000000 Co3 Sort number: 4 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.50000000 0.00000000 0.00000000 Ag1 Sort number: 5 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.00000000 0.50000000 0.00000000 Ag2 Sort number: 6 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.00000000 0.00000000 0.50000000 Ag3 Sort number: 7 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.50000000 0.50000000 0.00000000 Ag4 Sort number: 8 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.50000000 0.00000000 0.50000000 Ag5 Sort number: 9 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.25000000 0.00000000 0.25000000 Ag6 0.25000000 0.00000000 0.75000000 Ag6 Sort number: 10 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.75000000 0.00000000 0.25000000 Ag7 0.75000000 0.00000000 0.75000000 Ag7 Sort number: 11 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.75000000 0.25000000 0.00000000 Ag8 Sort number: 12 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.25000000 0.75000000 0.00000000 Ag9 Sort number: 13 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.00000000 0.25000000 0.25000000 Ag10 0.00000000 0.25000000 0.75000000 Ag10 Sort number: 14 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.00000000 0.75000000 0.25000000 Ag11 0.00000000 0.75000000 0.75000000 Ag11 Sort number: 15 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.75000000 0.75000000 0.00000000 Ag12 Sort number: 16 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.25000000 0.25000000 0.50000000 Ag13 Sort number: 17 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.25000000 0.75000000 0.50000000 Ag14 Sort number: 18 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.75000000 0.25000000 0.50000000 Ag15 Sort number: 19 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.75000000 0.75000000 0.50000000 Ag16 Sort number: 20 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.25000000 0.50000000 0.25000000 Ag17 0.25000000 0.50000000 0.75000000 Ag17 Sort number: 21 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.75000000 0.50000000 0.25000000 Ag18 0.75000000 0.50000000 0.75000000 Ag18 Sort number: 22 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.50000000 0.25000000 0.25000000 Ag19 0.50000000 0.25000000 0.75000000 Ag19 Sort number: 23 Names of point group: 1 1 C1 New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 2 0.50000000 0.75000000 0.25000000 Ag20 0.50000000 0.75000000 0.75000000 Ag20 Sort number: 24 Names of point group: m m Cs New basis vectors for this point group: 1.0000 0.0000 0.0000 <--- 1 0.0000 1.0000 0.0000 <--- 2 0.0000 0.0000 1.0000 <--- 3 Atom positions: 1 0.50000000 0.50000000 0.50000000 Ag21 ====================================================================== Number and name of space group: 6 (P m) [unique axis c] - - Short - Full - Schoenflies - names of point group: m m Cs Number of symmetry operations: 2 Operation: 1 1.0 0.0 0.0 0.000 0.0 1.0 0.0 0.000 0.0 0.0 1.0 0.000 Operation: 2 1.0 0.0 0.0 0.000 0.0 1.0 0.0 0.000 0.0 0.0 -1.0 0.000 ============================================================ Note that shift vectors for this space group are defined only up to the vector { X, Y, 0 }. Here X and Y can take any values. ===== Number of possible shift vectors: 2 ===== ===== List of shift vectors: 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 List of shifted cells: Cell #1 Shift vector: 0.0000 0.0000 0.5000 Nonequivalent atoms : 0.00000000 0.00000000 0.50000000 Co1 0.25000000 0.25000000 0.50000000 Co2 0.00000000 0.50000000 0.00000000 Co3 0.50000000 0.00000000 0.50000000 Ag1 0.00000000 0.50000000 0.50000000 Ag2 0.00000000 0.00000000 0.00000000 Ag3 0.50000000 0.50000000 0.50000000 Ag4 0.50000000 0.00000000 0.00000000 Ag5 0.25000000 0.00000000 0.75000000 Ag6 0.25000000 0.00000000 0.25000000 Ag6 0.75000000 0.00000000 0.75000000 Ag7 0.75000000 0.00000000 0.25000000 Ag7 0.75000000 0.25000000 0.50000000 Ag8 0.25000000 0.75000000 0.50000000 Ag9 0.00000000 0.25000000 0.75000000 Ag10 0.00000000 0.25000000 0.25000000 Ag10 0.00000000 0.75000000 0.75000000 Ag11 0.00000000 0.75000000 0.25000000 Ag11 0.75000000 0.75000000 0.50000000 Ag12 0.25000000 0.25000000 0.00000000 Ag13 0.25000000 0.75000000 0.00000000 Ag14 0.75000000 0.25000000 0.00000000 Ag15 0.75000000 0.75000000 0.00000000 Ag16 0.25000000 0.50000000 0.75000000 Ag17 0.25000000 0.50000000 0.25000000 Ag17 0.75000000 0.50000000 0.75000000 Ag18 0.75000000 0.50000000 0.25000000 Ag18 0.50000000 0.25000000 0.75000000 Ag19 0.50000000 0.25000000 0.25000000 Ag19 0.50000000 0.75000000 0.75000000 Ag20 0.50000000 0.75000000 0.25000000 Ag20 0.50000000 0.50000000 0.00000000 Ag21 - --------------Boundary-00=_NYKADNVGGDOGX0XT3IVL-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 05:20:08 -0800 (PST) From: romdhani hedi Subject: Re: [WIEN]: Compiling TELNES ==== romdhani hedi submitted the following contribution: ==== - --- Gabriela Fernanda Cabeza wrote: > ==== > Gabriela Fernanda Cabeza > submitted the following contribution: > ==== > > Dear Wien users, > > When recompiling TELNES on a Linux box with g77 > (recommended) i got the > following > error file (compile.msg) at SRC_telnes directory: > > - --------------------------------------------------------------------------- > > g77 -O -c telnes.f > telnes.f: In subroutine `firstcase': > telnes.f:2080: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f > g77 M CMPAMBIG] > telnes.f:2085: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f > g77 M CMPAMBIG] > telnes.f: In subroutine `secondcase': > telnes.f:2143: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f > g77 M CMPAMBIG] > telnes.f:2148: > + REAL(Factor1*Factor2*Factor3*Factor4) > ^ > Ambiguous use of intrinsic `REAL' at (^) [info -f > g77 M CMPAMBIG] > make: *** [telnes.o] Error 1 > > - --------------------------------------------------------------------------- > > Has anybody had the same errors? > > Thank you very much in advance for every hint. > Kind regards > > > > > Dra. Gabriela F. Cabeza > Profesora Adjunta > Dpto. de Física - Universidad Nacional del Sur > Avda. Alem 1253, (B8000CPB) Bahía Blanca - Argentina > tel: 54-291- 4595141- 54-291-4595101, int. 2821 > fax: 54-291-4595142 > e-mail: gcabeza@criba.edu.ar > > ==== Dear Gabriela, please replace "real" with "dreal" in kram.f and telnes.f subroutines. With best regards. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 05:43:10 -0800 (PST) From: romdhani hedi Subject: Re: [WIEN]: Problems with crystalstructure ==== romdhani hedi submitted the following contribution: ==== - --- Veerle Vanhoof wrote: > Dear wien2k user, > > When I try to make a crystalstructure consisting of > 29 Ag-atoms and 3 > Co-atoms, all positioned in a supercell (8 fcc-cubes > placed to form a > supercube with as latticeconstantes twice the ones > of Ag-fcc) and the Co's > positioned at coordinates (0, 0, 0), (0.25, 0.25, > 0), (0.5, 0, 0.5), or on > equivalent positions, sgroup suggests a "better" > struct-file. But when I > accept this new struct-file there appears to be an > inconsistency in the > suggested structure. > *.outputsgroup starts with the following > warningmessage: > "warning: !!! Struct file is not consistent with > space group found." > > Ignoring this inconsistency and using an RK_max of > 5.0 runs but ends up with > forces that diverge rather than converge for almost > all inequivalent atoms. > A typical example of this divergence: > > atom 1 x-component: 5.597 / 5.925 / 6.614 / 7.687 / > 8.836 / 10.310 / 11.868 / > 13.518 / 15.612 / 12.750 / 21.586 / 24.271 / 28.551 > / 31.127 / 44.334 > > Almost all the other atoms behave like atom 1, the > exceptions (1 or 2 atoms) > had already very low forces to start with: > > atom 23 x-component: 0.383 / 0.374 / 0.405 / 0.462 / > 0.462 / 0.478 / 0.554 / > 0.541 / 0.564 / 1.728 / 0.695 / 0.442 / 0.891 / > 0.961 / 0.897 > z-component: 0.303 / 0.294 / 0.328 / 0.378 > / 0.396 / 0.422 / 0.513 / > 0.522 / 0.591 / 1.680 / 0.545 / 0.166 / 0.574 / > 0.544 / 0.247 > > But the components that, more or less, converge are > already fixed (velocity 0) > in name.inM. > > I have made 7 other calculations with the 3th Co on > a different > (nonequivalent) position without any problems at > all. It's only this > configuration that gives these problems. > > The used *.struct-, *.inst-file, *.outputsgroup and > *.inM-file are in > attachement. > > Does somebody know what the problem can be? > > Thanks a lot! > > Veerle Vanhoof > Institute for nuclear and radiation fysics > Department of Physics > Catholic University of Leuven > Belgium > > > Co 1 > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,3.0 N > 3,-3,0.0 N > 4,-1,1.0 N > 4,-1,1.0 N > Co 1 > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,3.0 N > 3,-3,0.0 N > 4,-1,1.0 N > 4,-1,1.0 N > Co 1 > Ar 3 5 > 3, 2,2.0 N > 3, 2,2.0 N > 3,-3,3.0 N > 3,-3,0.0 N > 4,-1,1.0 N > 4,-1,1.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > Ag 1 > Kr 3 5 > 4, 2,2.0 N > 4, 2,2.0 N > 4,-3,3.0 N > 4,-3,3.0 N > 5,-1,1.0 N > 5,-1,0.0 N > **** End of Input > **** End of Input > > NEWT 1.0 #(NOSE, NEWT, BFGS, MOLD, tolf > (a4,f5.2)) > 1.0 1.0 0.0 0.8 # Atom1 (NOSE, MOLD:Masse, > delta t, T, nose-frequency) > 1.0 1.0 0.0 0.8 # Atom2 (NEWT: 1,2,3:delta, > 4:eta(1=MOLD)) > 0.0 0.0 0.0 0.8 # Atom3 (BFGS, NEWT: [ 1 || 2 > || 3 ] = 0 constraint) > 1.0 1.0 0.0 0.8 # Atom4 > 1.0 1.0 0.0 0.8 # Atom5 > 0.0 0.0 0.0 0.8 # Atom6 > 1.0 1.0 0.0 0.8 # Atom7 > 0.0 0.0 0.0 0.8 # Atom8 > 1.0 1.0 1.0 0.8 # Atom9 > 1.0 0.0 1.0 0.8 # Atom10 > 1.0 1.0 0.0 0.8 # Atom11 > 1.0 1.0 0.0 0.8 # Atom12 > 1.0 0.0 1.0 0.8 # Atom13 > 0.0 0.0 0.0 0.8 # Atom14 > 1.0 1.0 0.0 0.8 # Atom15 > 1.0 1.0 0.0 0.8 # Atom16 > 1.0 1.0 0.0 0.8 # Atom17 > 1.0 1.0 0.0 0.8 # Atom18 > 1.0 1.0 0.0 0.8 # Atom19 > 1.0 1.0 0.0 0.8 # Atom20 > 1.0 0.0 1.0 0.8 # Atom21 > 1.0 0.0 1.0 0.8 # Atom22 > 0.0 0.0 0.0 0.8 # Atom23 > 0.0 0.0 0.0 0.8 # Atom24 > > > AgCo > > P LATTICE,NONEQUIV. ATOMS:24 6 Pm > > RELA > > 22.024507 22.024507 22.024507 90.000000 90.000000 > 90.000000 > ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Co1 NPT= 781 R0=0.00010000 RMT= 2.2500 > Z: 27.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -2: X=0.25000000 Y=0.25000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Co2 NPT= 781 R0=0.00010000 RMT= 2.2500 > Z: 27.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -3: X=0.00000000 Y=0.50000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Co3 NPT= 781 R0=0.00010000 RMT= 2.2500 > Z: 27.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -4: X=0.50000000 Y=0.00000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag1 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -5: X=0.00000000 Y=0.50000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag2 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -6: X=0.00000000 Y=0.00000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag3 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -7: X=0.50000000 Y=0.50000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag4 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -8: X=0.50000000 Y=0.00000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag5 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM= -9: X=0.25000000 Y=0.00000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -9: X=0.25000000 Y=0.00000000 Z=0.75000000 > Ag6 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-10: X=0.75000000 Y=0.00000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -10: X=0.75000000 Y=0.00000000 Z=0.75000000 > Ag7 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-11: X=0.75000000 Y=0.25000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag8 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-12: X=0.25000000 Y=0.75000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag9 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-13: X=0.00000000 Y=0.25000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -13: X=0.00000000 Y=0.25000000 Z=0.75000000 > Ag10 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-14: X=0.00000000 Y=0.75000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -14: X=0.00000000 Y=0.75000000 Z=0.75000000 > Ag11 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-15: X=0.75000000 Y=0.75000000 Z=0.00000000 > MULT= 1 ISPLIT= 8 > Ag12 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-16: X=0.25000000 Y=0.25000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag13 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-17: X=0.25000000 Y=0.75000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag14 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-18: X=0.75000000 Y=0.25000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag15 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-19: X=0.75000000 Y=0.75000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag16 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-20: X=0.25000000 Y=0.50000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -20: X=0.25000000 Y=0.50000000 Z=0.75000000 > Ag17 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-21: X=0.75000000 Y=0.50000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -21: X=0.75000000 Y=0.50000000 Z=0.75000000 > Ag18 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-22: X=0.50000000 Y=0.25000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -22: X=0.50000000 Y=0.25000000 Z=0.75000000 > Ag19 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-23: X=0.50000000 Y=0.75000000 Z=0.25000000 > MULT= 2 ISPLIT= 8 > -23: X=0.50000000 Y=0.75000000 Z=0.75000000 > Ag20 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > ATOM=-24: X=0.50000000 Y=0.50000000 Z=0.50000000 > MULT= 1 ISPLIT= 8 > Ag21 NPT= 781 R0=0.00010000 RMT= 2.4000 > Z: 47.0 > LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > 0.0000000 0.0000000 1.0000000 > 2 NUMBER OF SYMMETRY OPERATIONS > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0 1 0.0000000 > 1 > 1 0 0 0.0000000 > 0 1 0 0.0000000 > 0 0-1 0.0000000 > 2 > > warning: !!! Struct file is not consistent with > space group found. > > - ---------------------------------------------------------------------- > > Bravais lattice: Monoclinic primitive > > a b c > 22.02450700 22.02450700 22.02450700 > alpha beta gamma > 90.00000000 90.00000000 90.00000000 > > > ===== Decomposition of new basis vectors over input > basis ===== > 1.000000 0.000000 0.000000 <--- 1 > 0.000000 1.000000 0.000000 <--- 2 > 0.000000 0.000000 1.000000 <--- 3 > > ==== Number of atoms in cell: 32 > ==== Atom positions: > > 0.00000000 0.00000000 0.00000000 > Co1 > > 0.25000000 0.25000000 0.00000000 > Co2 > > 0.00000000 0.50000000 0.50000000 > Co3 > > 0.50000000 0.00000000 0.00000000 > Ag1 > > 0.00000000 0.50000000 0.00000000 > Ag2 > > 0.00000000 0.00000000 0.50000000 > Ag3 > > 0.50000000 0.50000000 0.00000000 > Ag4 > > 0.50000000 0.00000000 0.50000000 > Ag5 > > 0.25000000 0.00000000 0.25000000 > Ag6 > 0.25000000 0.00000000 0.75000000 > Ag6 > > 0.75000000 0.00000000 0.25000000 > Ag7 > 0.75000000 0.00000000 0.75000000 > Ag7 > > 0.75000000 0.25000000 0.00000000 > Ag8 > > 0.25000000 0.75000000 0.00000000 > Ag9 > > 0.00000000 0.25000000 0.25000000 > Ag10 > 0.00000000 0.25000000 0.75000000 > Ag10 > > 0.00000000 0.75000000 0.25000000 > Ag11 > 0.00000000 0.75000000 0.75000000 > Ag11 > > 0.75000000 0.75000000 0.00000000 > Ag12 > > 0.25000000 0.25000000 0.50000000 > Ag13 > > 0.25000000 0.75000000 0.50000000 > Ag14 > > 0.75000000 0.25000000 0.50000000 > Ag15 > > 0.75000000 0.75000000 0.50000000 > Ag16 > > 0.25000000 0.50000000 0.25000000 > Ag17 > 0.25000000 0.50000000 0.75000000 > Ag17 > > 0.75000000 0.50000000 0.25000000 > Ag18 > 0.75000000 0.50000000 0.75000000 > Ag18 > > 0.50000000 0.25000000 0.25000000 > Ag19 > 0.50000000 0.25000000 0.75000000 > Ag19 > > 0.50000000 0.75000000 0.25000000 > Ag20 > 0.50000000 0.75000000 0.75000000 > Ag20 > > 0.50000000 0.50000000 0.50000000 > Ag21 > > ==== Number of nonequivalent sorts: 24 > ==== Nonequivalent atoms, point group for each sort: > ==== > > Sort number: 1 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.00000000 0.00000000 0.00000000 > Co1 > > Sort number: 2 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.25000000 0.25000000 0.00000000 > Co2 > > Sort number: 3 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.00000000 0.50000000 0.50000000 > Co3 > > Sort number: 4 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.50000000 0.00000000 0.00000000 > Ag1 > > Sort number: 5 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.00000000 0.50000000 0.00000000 > Ag2 > > Sort number: 6 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.00000000 0.00000000 0.50000000 > Ag3 > > Sort number: 7 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.50000000 0.50000000 0.00000000 > Ag4 > > Sort number: 8 > Names of point group: m m Cs > New basis vectors for this point group: > 1.0000 0.0000 0.0000 <--- 1 > 0.0000 1.0000 0.0000 <--- 2 > 0.0000 0.0000 1.0000 <--- 3 > > Atom positions: 1 > 0.50000000 0.00000000 0.50000000 > Ag5 > === message truncate Dear Veerle, your atoms are equivalent in *.inst but inequivalent in *.struct, why ? Thanks __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 22:31:31 +0800 From: joshua xie Subject: [WIEN]: a problem ==== joshua xie submitted the following contribution: ==== the scf scycle stop when excuting lapw1 with following error: ** Error in Parallel LAPW1 ** LAPW1 STOPPED at Mon Jan 6 22:10:26 CST 2003 ** check ERROR FILES! 'SELECT' - no energy limits found for L= 1 'SELECT' - E-bottom -2.99000 E-top -200.00000 'SELECT' - no energy limits found for L= 1 'SELECT' - E-bottom -2.99000 E-top -200.00000 I hope someone would give me some hints to solve the problem. Thank you all in advance! ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 15:44:40 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Problems with crystalstructure ==== "Kevin Jorissen" submitted the following contribution: ==== > Dear Veerle, > your atoms are equivalent in *.inst but inequivalent > in *.struct, why ? > Thanks > There are 24 atoms in her struct and 24 in her inst, what do you mean? kind regards, Kevin Jorissen > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 10:13:00 -0500 From: Fred Nastos Subject: Re: [WIEN]: question about how to use OPTIC ==== Fred Nastos submitted the following contribution: ==== Liu, It is difficult (impossible?) to diagnose your error. What semiconductor is this, and what is its calculated bandgap? What was your procedure after the SCF calculation? Did you produce a bandstructure also? It helps if you can produce a proper bandstructure, as a check on your scf calculation. On January 6, 2003 03:49 am, liu wan wrote: > ==== > "liu wan" > submitted the following contribution: > ==== > > Dear All > > I try to calculated the optical properties of a semi-conductor. But I find > that the reult in the case.joint is: Some position is very large and the > other position is zero. What is wrong? > > 2 > Energy [eV] Im_eps_xx Im_eps_zz > > 0.00000 0.84051298E+89 0.00000000E+00 > 0.01361 0.17131700E-07 0.00000000E+00 > 0.02721 0.10498127+277 0.00000000E+00 > 0.04082 0.22762560E-16 0.00000000E+00 > 0.05442 0.66295283E-08 0.00000000E+00 > 0.06803 0.15973640+272 0.00000000E+00 > 0.08163 0.21894908E-16 0.00000000E+00 > 0.09524 0.21233672-152 0.00000000E+00 > 0.10885 0.44776644+218 0.00000000E+00 > 0.12245 0.51962383E+46 0.00000000E+00 > 0.13606 0.46566129E-09 0.00000000E+00 > 0.14966 0.00000000E+00 0.00000000E+00 > 0.16327 0.00000000E+00 0.00000000E+00 > 0.17687 0.00000000E+00 0.00000000E+00 > > Best wish > > Liu > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* > http://join.msn.com/?page=features/virus > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 06 Jan 2003 17:13:37 +0200 From: "B. Yanchitsky" Subject: Re: [WIEN]: Problems with crystalstructure ==== "B. Yanchitsky" submitted the following contribution: ==== > When I try to make a crystalstructure consisting of 29 Ag-atoms and 3 > Co-atoms, all positioned in a supercell (8 fcc-cubes placed to form a > supercube with as latticeconstantes twice the ones of Ag-fcc) and the Co's > positioned at coordinates (0, 0, 0), (0.25, 0.25, 0), (0.5, 0, 0.5), or on > equivalent positions, sgroup suggests a "better" struct-file. But when I > accept this new struct-file there appears to be an inconsistency in the > suggested structure. > *.outputsgroup starts with the following warningmessage: > "warning: !!! Struct file is not consistent with space group found." > > Ignoring this inconsistency and using an RK_max of 5.0 runs but ends up with > forces that diverge rather than converge for almost all inequivalent atoms. > A typical example of this divergence: Dear Veerle, This is a bug in sgroup and the warning is incorrect. sgroup must not generate any warnings treating any struct file which is a result of sgroup output. After a quick look, it seems that your struct file is correct. The problem is that sgroup believes (incorrectly) that your input structure is specified as unique axis b setting (alpha=gamma=90) and this is a reason for the incorrect warning. Thank you for this report, Best regards, Bogdan Yanchitsky ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 16:14:54 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: a problem ==== "Kevin Jorissen" submitted the following contribution: ==== - ----- Original Message ----- From: "joshua xie" To: Sent: Monday, January 06, 2003 3:31 PM Subject: [WIEN]: a problem > ==== > joshua xie > submitted the following contribution: > ==== > > the scf scycle stop when excuting lapw1 with following error: > > > ** Error in Parallel LAPW1 > ** LAPW1 STOPPED at Mon Jan 6 22:10:26 CST 2003 > ** check ERROR FILES! > 'SELECT' - no energy limits found for L= 1 > 'SELECT' - E-bottom -2.99000 E-top -200.00000 > 'SELECT' - no energy limits found for L= 1 > 'SELECT' - E-bottom -2.99000 E-top -200.00000 > > > I hope someone would give me some hints to solve the problem. Have you read the users guide? There's useful information in the section describing the program LAPW1 and its input. I believe there's also faq on the wien2k-website, and the mailing list digests might be helpful, too. If you have exhausted these sources, please provide us with more detailed information concerning your calculation and we will try to help you to the best of our abilities. kind regards, Kevin Jorissen kevin.jorissen@ua.ac.be > Thank you all in advance! > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 16:49:05 +0100 From: Veerle Vanhoof Subject: Re: [WIEN]: Problems with crystalstructure ==== Veerle Vanhoof submitted the following contribution: ==== > > When I try to make a crystalstructure consisting of 29 Ag-atoms and 3 > > Co-atoms, all positioned in a supercell (8 fcc-cubes placed to form a > > supercube with as latticeconstantes twice the ones of Ag-fcc) and the > > Co's positioned at coordinates (0, 0, 0), (0.25, 0.25, 0), (0.5, 0, 0.5), > > or on equivalent positions, sgroup suggests a "better" struct-file. But > > when I accept this new struct-file there appears to be an inconsistency > > in the suggested structure. > > *.outputsgroup starts with the following warningmessage: > > "warning: !!! Struct file is not consistent with space group found." > > > > Ignoring this inconsistency and using an RK_max of 5.0 runs but ends up > > with forces that diverge rather than converge for almost all inequivalent > > atoms. A typical example of this divergence: > > Dear Veerle, > > This is a bug in sgroup and the warning is incorrect. sgroup must not > generate any warnings treating any struct file which is a result of sgroup > output. After a quick look, it seems that your struct file is correct. The > problem is that sgroup believes (incorrectly) that your input structure is > specified as unique axis b setting (alpha=gamma=90) and this is a reason > for the incorrect warning. So the inconsistency sgroup mentions can't be the reason for the divergence of the forces. What can then be the cause of it? Thanks Veerle Vanhoof - -- Veerle Vanhoof IKS - KULeuven Celestijnenlaan 200 D B-3001 Leuven BELGIUM Phone: +32 (0)16 32 71 45 Fax: +32 (0)16 32 79 85 email: Veerle.Vanhoof@fys.kuleuven.ac.be ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 11:07:51 -0500 From: "Dadi Dai" Subject: [WIEN]: Why does LDA+U stop at the second cycle? ==== "Dadi Dai" submitted the following contribution: ==== I wish to do LDA+U calculation for Cu4O3. I used "runsp -orb", and the calculation stopped at the beginning of the second cycle. I don't know why and hope to get some help. The error message is: ....................cycle 1................... STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPW2 END STOP LAPW2 END STOP lapwdm END STOP lapwdm END STOP CORE END STOP CORE END STOP MIXER END ..............cycle 2.................. STOP LAPW0 END 1525-001 The READ statement on the file Cu4O3.dmatup cannot be completed because the end of the file was reached. The program will stop. I found the file "uporb.error" that shows "Error in Vorb". The :log file shows: > (runsp) options: -orb -i 40 -cc 0.0001 Fri Jan 3 15:56:23 EST 2003> (x) lapw0 Fri Jan 3 15:57:02 EST 2003> (x) lapw1 -up -orb Fri Jan 3 16:11:31 EST 2003> (x) lapw1 -dn -orb Fri Jan 3 16:25:58 EST 2003> (x) lapw2 -up Fri Jan 3 16:27:31 EST 2003> (x) lapw2 -dn Fri Jan 3 16:29:00 EST 2003> (x) lapwdm -up Fri Jan 3 16:29:05 EST 2003> (x) lapwdm -dn Fri Jan 3 16:29:09 EST 2003> (x) lcore -up Fri Jan 3 16:29:10 EST 2003> (x) lcore -dn Fri Jan 3 16:29:11 EST 2003> (x) mixer Fri Jan 3 16:29:16 EST 2003> (x) lapw0 Fri Jan 3 16:29:57 EST 2003> (x) orb -up The Cu4O3.inorb that I used is: 1 2 0 BROYD 0.25 1 1 2 2 1 2 1 0.55127 0.055127 U,J 0.55127 0.055127 U,J The Cu4O3.indm that I used is: - -9.0 2 1 1 2 1 1 2 0 0 I wonder if the inputs are correct. Could anyone help me? Thank you very much! Dadi Dai ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 11:10:27 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: hello ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2kusers Last time, I had sent queries regarding the scripts "runsp_lapw", "initso_lapw" and MIXER & MINI. If you have an suggestions/can answer pl. let me know. thanking in advance for your help. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 08:45:12 -0800 (PST) From: romdhani hedi Subject: Re: [WIEN]: Problems with crystalstructure ==== romdhani hedi submitted the following contribution: ==== - --- Kevin Jorissen wrote: > ==== > "Kevin Jorissen" > submitted the following contribution: > ==== > > > Dear Veerle, > > your atoms are equivalent in *.inst but > inequivalent > > in *.struct, why ? > > Thanks > > > > There are 24 atoms in her struct and 24 in her inst, > what do you mean? > > kind regards, > > Kevin Jorissen > > > > __________________________________________________ ****************************************************** there are 24 atoms in both files. In *.inst for example all Ag atoms are indexed by Ag1, but in *.struct they are indexed by Ag1, Ag2,....which make inequivalent. Thanks __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 06 Jan 2003 18:48:45 +0200 From: "B. Yanchitsky" Subject: Re: [WIEN]: Problems with crystalstructure ==== "B. Yanchitsky" submitted the following contribution: ==== > So the inconsistency sgroup mentions can't be the reason for the divergence of > the forces. > What can then be the cause of it? > Yes, i think that the warning message can't be responsible for the divergence. But unfortunately i don't know actually where may be a reason for this instability. In any case, one thing is quite clear - it's necessary to make sure that you have well calculated forces (small Rkmax, or a small number of k-points may result in bad forces). Best regards, Bogdan ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 18:41:26 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: Why does LDA+U stop at the second cycle? ==== Peter Blaha submitted the following contribution: ==== > I wish to do LDA+U calculation for Cu4O3. I used "runsp -orb", and the > calculation stopped at the beginning of the second cycle. I don't know > why and hope to get some help. > The Cu4O3.inorb that I used is: > 1 2 0 > BROYD 0.25 > 1 1 2 > 2 1 2 > 1 > 0.55127 0.055127 U,J > 0.55127 0.055127 U,J Do you have the latest versions ? Use PRATT 1.0 (the defaults) and not BROYD. Did you remove the case.vorbdu file in the runsp_lapw script as was discussed in the mailing list some weeks ago. Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 15:16:36 -0300 (ART) From: RUBEN WEHT Subject: Re: [WIEN]: Why does LDA+U stop at the second cycle? ==== RUBEN WEHT submitted the following contribution: ==== Dear Dadi Dai, Please note you have an error in the *.indm file > The Cu4O3.indm that I used is: > -9.0 > 2 > 1 1 2 > 1 1 2 <<<<<<<<<--------- > 0 0 You are calculating the density matrix for the same orbital twice. Also consider the suggestion given by Peter regarding case.vorbdu file. (I think the same is valid for a question posted by Dr. Sahu same weeks ago...). Best, Ruben *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 4754-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 4754-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Mon, 6 Jan 2003 15:26:36 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: runsp_lapw ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Prof Blaha In connection with your answer to the qurey on w2k-list "Why does LDA+U stop at .....", does it answer my qurey on runsp_lapw -so -orb which I put last week? In the runsp_script(latest download, 3rd week of Dec 2002). the case.vorbdu is already commented: #foreach i ( vorbup vorbdn vorbdu ) # if (-e $file.$i ) \ # cp $file.$i $file.$i"_old" #save last cycle #end but slightly below there is if ( "$so" == "-so" && -s $file.dmatud ) then total_exec orb -du $para do you mean to say we have to comment these two lines also? PRATT in case.inorb means BROYD doesnot work for -orb. If case.inm contain BROYD but case.inorb contain PRATT, orbital charge densities will be mixed using PRATT scheme (mixer is invoked during -orb run) but the final charge densities at the end of cycle will be done by BROYD scheme and case.scf file should contain BROYD instead of PRATT. is it right? Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 7 Jan 2003 01:41:41 -0300 (ART) From: RUBEN WEHT Subject: Re: [WIEN]: runsp_lapw ==== RUBEN WEHT submitted the following contribution: ==== This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - --1621681473-1344807548-1041914453=:18432 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Dr. Sahu, please try with the runsp_lapw file I have attached. It has the lines that calculated vorbdu cancelled. Best, Ruben > Dear Prof Blaha > In connection with your answer to the qurey on w2k-list "Why does > LDA+U stop at .....", does it answer my qurey on runsp_lapw -so -orb which > I put last week? > > In the runsp_script(latest download, 3rd week of Dec 2002). > > the case.vorbdu is already commented: > > #foreach i ( vorbup vorbdn vorbdu ) > # if (-e $file.$i ) \ > # cp $file.$i $file.$i"_old" #save last cycle > #end > > but slightly below there is > > if ( "$so" == "-so" && -s $file.dmatud ) then > total_exec orb -du $para > > do you mean to say we have to comment these two lines also? > > PRATT in case.inorb means > BROYD doesnot work for -orb. > > If case.inm contain BROYD but case.inorb contain PRATT, orbital charge > densities will be mixed using PRATT scheme (mixer is invoked during -orb > run) but the final charge densities at the end of cycle will be done by > BROYD scheme and case.scf file should contain BROYD instead of PRATT. is > it right? > > Regards > sahu > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > - -- *====================================================================* | Ruben Weht | ruweht@cnea.gov.ar | | Departmento de Fisica - CNEA | Tel: (54-11) 4754-7104 | | Avda. General Paz y Constituyentes | Fax: (54-11) 4754-7121 | | 1650 - San Martin - ARGENTINA | | *====================================================================* - --1621681473-1344807548-1041914453=:18432 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=runsp_lapw Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=runsp_lapw IyEvYmluL2NzaCAtZg0KaHVwDQp1bmFsaWFzIHJtDQoNCnNldCBuYW1lICA9 ICQwDQpzZXQgYmluICAgPSAkbmFtZTpoCQkjZGlyZWN0b3J5IG9mIFdJRU4t ZXhlY3V0YWJsZXMNCmlmICEoLWQgJGJpbikgc2V0IGJpbiA9IC4NCnNldCBu YW1lICA9ICRuYW1lOnQgCQkjbmFtZSBvZiB0aGlzIHNjcmlwdC1maWxlDQpz ZXQgbG9nZmlsZSA9IDpsb2cNCnNldCB0bXAgICA9ICg6JG5hbWUpCQkjdGVt cG9yYXJ5IGZpbGVzDQoNCnNldCBzY3JhdGNoID0gICAgICAgICAgICAgICAg ICAgIyBzZXQgZGlyZWN0b3J5IGZvciB2ZWN0b3JzIGFuZCBoZWxwIGZpbGVz DQppZiAoJD9TQ1JBVENIKSB0aGVuICAgICAgICAgICAgICAjaWYgZW52cm9u bWVudCBTQ1JBVENIIGlzIHNldA0KIHNldCBzY3JhdGNoPWBlY2hvICRTQ1JB VENIICB8IHNlZCAtZSAncy9cLyQvLydgLyAjc2V0ICRzY3JhdGNoIHRvIHRo YXQgdmFsdWUgIA0KZW5kaWYgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQojLS0tPiBmdW5jdGlvbnMgJiBzdWJyb3V0aW5lcw0KYWxpYXMJdGVzdGlu cHV0CSdzZXQgZXJyaW49IlwhOjEiO2lmICghIC1lIFwhOjEgfHwgLXogXCE6 MSkgZ290byBcIToyJw0KYWxpYXMJdGVzdHN0YXR1cwknaWYgKCRzdGF0dXMp IGdvdG8gZXJyb3InDQphbGlhcwl0ZXN0ZXJyb3IJJ2lmICggLWUgXCE6MS5l cnJvciAmJiAhIC16IFwhOjEuZXJyb3IpIGdvdG8gZXJyb3InDQphbGlhcwl0 ZXN0c3RvcAknaWYgKFwhOjEgPT0gJHN0b3BhZnRlciApIGdvdG8gc3RvcCcN CmFsaWFzICAgY2xlYW5kYXlmaWxlICAgICdncmVwIC12ICJcWyIgJGRheWZp bGUgPi50bXA7J1wNCiAgICAgICAgICAgICAgICAgICAgICAgICdtdiAudG1w ICRkYXlmaWxlJw0KYWxpYXMJb3V0cHV0CQknc2V0IGRhdGUgPSBgZGF0ZSAr IiglVCkiYDsnXA0KCQkJJ3ByaW50ZiAiPiAgICVzXHQlcyAiICJcIToqIiAi JGRhdGUiID4+ICRkYXlmaWxlJw0KDQphbGlhcwlleGVjCQknKCRiaW4veCAg XCE6KikgPj4gJGRheWZpbGU7J1wNCgkJCSd0ZXN0c3RhdHVzJw0KDQphbGlh cwl0b3RhbF9leGVjCSdvdXRwdXQgXCE6KjsnXA0KCQkJJ2V4ZWMgXCE6Kjsn XA0KICAgICAgICAgICAgICAgICAgICAgICAgJ2NsZWFuZGF5ZmlsZTsnXA0K CQkJJ3Rlc3RlcnJvciBcIToxOydcDQoJCQkndGVzdGVycm9yIHVwXCE6MTsn XA0KCQkJJ3Rlc3RlcnJvciBkblwhOjE7J1wNCgkJCSd0ZXN0c3RvcCBcITox Jw0KYWxpYXMJVE9UdG9GT1IJJ3NlZCAicy9UT1QvRk9SLyIgXCE6MSA+ICR0 bXA7J1wNCgkJCSdtdiAkdG1wIFwhOjEnDQphbGlhcwlGT1J0b1RPVAknc2Vk ICJzL0ZPUi9UT1QvIiBcIToxID4gJHRtcDsnXA0KCQkJJ212ICR0bXAgXCE6 MScNCg0KIy0tLT4gZGVmYXVsdCBwYXJhbWV0ZXJzDQpzZXQgY2N1dAk9IDAu MDAwMCAJI3VwcGVyIGxpbWl0IGZvciBjaGFyZ2UgY29udmVyZ2VuY2UNCnNl dCBmY3V0CT0gMCAJIAkjdXBwZXIgbGltaXQgZm9yIGZvcmNlIGNvbnZlcmdl bmNlDQpzZXQgZWN1dAk9IDAuMDAwMQkjdXBwZXIgbGltaXQgZm9yIGVuZXJn eSBjb252ZXJnZW5jZQ0Kc2V0IGl0ZXIJPSAyMAkjbWF4aW11bSBudW1iZXIg b2YgaXRlcmF0aW9ucw0Kc2V0IHJpdGVyCT0gMjAJI3Jlc3RhcnQgYWZ0ZXIg JHJpdGVyIGl0ZXJhdGlvbnMNCnNldCBzdG9wYWZ0ZXIJCSNzdG9wIGFmdGVy ICRzdG9wYWZ0ZXINCnNldCBuZXh0CQkjc2V0IC0+IHN0YXJ0IGN5Y2xlIHdp dGggJG5leHQNCnNldCBxbGltaXQgPSAwLjA1ICAgICAgICNzZXQgLT4gd3Jp dGVzIEUtTCBpbiBuZXcgaW4xIHdoZW4gcWxpbWl0IGlzIGZ1bGZpbGxlZA0K c2V0IGluMW5ldyA9IDk5OQ0Kc2V0IHBhcmENCnNldCBub2hucw0Kc2V0IG5v aG5zMSA9IDANCnNldCBpdA0Kc2V0IGl0MA0Kc2V0IHNvDQpzZXQgb3JiDQp1 bnNldCBvcmJjDQp1bnNldCBkbQ0Kc2V0IGN0ZXN0PSgwIDAgMCkNCnNldCBl dGVzdD0oMCAwIDApDQoNCiMtLS0+IGRlZmF1bHQgZmxhZ3MNCnVuc2V0IHJl bm9ybQ0KdW5zZXQgaW4xb3JpZw0KdW5zZXQgZm9yY2UJCSNzZXQgLT4gZm9y Y2UtY2FsY3VsYXRpb24gYWZ0ZXIgc2VsZi1jb25zaXN0ZW5jeQ0KdW5zZXQg Zl9ub3RfY29udg0KdW5zZXQgaGVscAkJI3NldCAtPiBoZWxwIG91dHB1dA0K dW5zZXQgY29tcGxleAkJI3NldCAtPiBjb21wbGV4IGNhbGN1bGF0aW9uDQp1 bnNldCBpbml0CQkjc2V0IC0+IHN3aXRjaGVzIGluaXRpYWxseSBzZXQgdG8g dG90YWwgZW5lcmd5IGNhbGMuDQoNCiMtLS0+IGhhbmRsaW5nIG9mIGlucHV0 IG9wdGlvbnMNCmVjaG8gIj4gICAoJG5hbWUpIG9wdGlvbnM6ICRhcmd2Igk+ PiAkbG9nZmlsZQ0KYWxpYXMgc2IgJ3NoaWZ0OyBicmVha3N3JwkjZGVmaW5p dGlvbiB1c2VkIGluIHN3aXRjaA0Kd2hpbGUgKCQjYXJndikNCiAgc3dpdGNo ICgkMSkNCiAgY2FzZSAtW0h8aF06DQogICAgc2V0IGhlbHA7IHNiDQogIGNh c2UgLXNvOg0KICAgIHNldCBzbyA9IC1zbzsgc2INCiAgY2FzZSAtbm9obnM6 DQogICAgc2V0IG5vaG5zID0gLW5vaG5zOyBzaGlmdDsgc2V0IG5vaG5zMSA9 ICQxO3NiDQogIGNhc2UgLWRtOg0KICAgIHNldCBkbTsgc2INCiAgY2FzZSAt b3JiOg0KICAgIHNldCBvcmIgPSAtb3JiOyBzYg0KICBjYXNlIC1vcmJjOg0K ICAgIHNldCBvcmJjDQogICAgc2V0IG9yYiA9IC1vcmI7IHNiDQogIGNhc2Ug LWl0Og0KICAgIHNldCBpdCA9IC1pdDsgc2INCiAgY2FzZSAtaXQwOg0KICAg IHNldCBpdCA9IC1pdDsgc2V0IGl0MCA9IC1pdDsgc2INCiAgY2FzZSAtcDoN CiAgICBzZXQgcGFyYSA9IC1wOyBzYg0KICBjYXNlIC1JOg0KICAgIHNldCBp bml0OyBzYg0KICBjYXNlIC1lOiANCiAgICBzaGlmdDsgc2V0IHN0b3BhZnRl ciA9ICQxOyBzYg0KICBjYXNlIC1jYzogDQogICAgc2hpZnQ7IHNldCBjY3V0 ID0gJDE7IHNldCBmY3V0ID0gMDsgc2V0IGVjdXQ9MDsgc2INCiAgY2FzZSAt ZWM6IA0KICAgIHNoaWZ0OyBzZXQgZWN1dCA9ICQxOyBzZXQgZmN1dCA9IDA7 IHNldCBjY3V0PTA7IHNiDQogIGNhc2UgLWZjOiANCiAgICBzaGlmdDsgc2V0 IGZfbm90X2NvbnY7IHNldCBmY3V0ID0gJDE7IHNldCBlY3V0ID0gMDsgc2V0 IGNjdXQ9MDsgc2INCiAgY2FzZSAtcWw6IA0KICAgIHNoaWZ0OyBzZXQgcWxp bWl0ID0gJDE7ICBzYg0KICBjYXNlIC1pbjFuZXc6IA0KICAgIHNoaWZ0OyBz ZXQgaW4xbmV3ID0gJDE7ICBzYg0KICBjYXNlIC1pbjFvcmlnOg0KICAgIHNl dCBpbjFvcmlnOyBzYg0KICBjYXNlIC1yZW5vcm06IA0KICAgIHNldCByZW5v cm07IHNldCBuZXh0PW1peGVyOyAgc2INCiAgY2FzZSAtaToNCiAgICBzaGlm dDsgc2V0IGl0ZXIgID0gJDE7IHNiDQogIGNhc2UgLXI6DQogICAgc2hpZnQ7 IHNldCByaXRlciA9ICQxOyBzYg0KICBjYXNlIC1zOg0KICAgIHNoaWZ0OyBz ZXQgbmV4dCAgPSAkMTsgc2INCiAgZGVmYXVsdDogDQogICAgZWNobyAiRVJS T1I6IG9wdGlvbiAkMSBkb2VzIG5vdCBleGlzdFwhIjsgc2INCiAgZW5kc3cN CmVuZA0KaWYgKCQ/aGVscCkgZ290byBoZWxwDQogIA0KIy0tLT4gcGF0aC0g YW5kIGZpbGUtbmFtZXMNCnNldCBmaWxlICAgID0gYHB3ZGANCnNldCBmaWxl ICAgID0gJGZpbGU6dAkJI3RhaWwgb2YgZmlsZS1uYW1lcw0Kc2V0IGRheWZp bGUgPSAkZmlsZS5kYXlmaWxlCSNtYWluIG91dHB1dC1maWxlDQoNCiMtLS0+ IHN0YXJ0aW5nIG91dA0KaWYgKCRuZXh0ICE9ICIiKSBnb3RvIHN0YXJ0CSNz dGFydCB3aXRoIG9wdGlvbmFsIHByb2dyYW0NCnNldCBuZXh0ID0gbGFwdzAJ CSNkZWZhdWx0IHN0YXJ0IHdpdGggbHN0YXJ0DQoNCmlmICEoLWUgJGZpbGUu Y2xtc3VtKSB0aGVuDQogICBpZiAoLWUgJGZpbGUuY2xtc3VtX29sZCkgdGhl bg0KICAgIGNwICRmaWxlLmNsbXN1bV9vbGQgJGZpbGUuY2xtc3VtDQogICBl bHNlDQogICAgIGVjaG8gJ25vJyAkZmlsZScuY2xtc3VtKF9vbGQpIGZpbGUg Zm91bmQsIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3IgbGFwdzAgXCEnDQogICAg IGVjaG8gJ25vJyAkZmlsZScuY2xtc3VtKF9vbGQpIGZpbGUgZm91bmQsIHdo aWNoIGlzIG5lY2Vzc2FyeSBmb3IgbGFwdzAgXCEnXA0KCT4+JGRheWZpbGUN CiAgICAgZ290byBlcnJvcg0KICAgZW5kaWYNCmVuZGlmDQoNCnN0YXJ0OgkJ CQkjaW5pdGFsaXphdGlvbiBvZiBpbjItZmlsZXMNCmlmICgkP2luaXQpIHRo ZW4NCiAgZm9yZWFjaCBpICgkZmlsZS5pbjIqKQ0KICAgIHNlZCAiMXMvW0Et Wl0uLi4uL1RPVCAgLyIgJGkgPiAkdG1wDQogICAgbXYgJHRtcCAkaQ0KICBl bmQNCmVuZGlmDQoNCnNldCBpY3ljbGU9MQ0KDQpzZXQgcml0ZXJfc2F2ZT0k cml0ZXINCnByaW50ZiAiXG5cbkNhbGN1bGF0aW5nICRmaWxlIGluIGBwd2Rg XG5vbiBgaG9zdG5hbWVgIiAgPiAkZGF5ZmlsZQ0KcHJpbnRmICJcblxuICAg IHN0YXJ0IFx0KCVzKSAiICJgZGF0ZWAiCT4+ICRkYXlmaWxlDQplY2hvICAi d2l0aCAkbmV4dCAoJGl0ZXIvJHJpdGVyIHRvIGdvKSIJPj4gJGRheWZpbGUN CmdvdG8gJG5leHQNCg0KY3ljbGU6CQkJCQkjYmVnaW4gb2Ygc2MtY3ljbGUN Cm5vaHVwIGVjaG8gaW4gY3ljbGUgJGljeWNsZSAiICAgRVRFU1Q6ICRldGVz dFszXSAgIENURVNUOiAkY3Rlc3RbM10iDQpodXANCg0KbGFwdzA6DQp0ZXN0 aW5wdXQJJGZpbGUuaW4wIGVycm9yX2lucHV0DQp0b3RhbF9leGVjCWxhcHcw ICRwYXJhDQoNCmlmICgkZmN1dCA9PSAiMCIpIGdvdG8gb3JiDQoNCiMtLS0+ IHRlc3Qgb2YgZm9yY2UtY29udmVyZ2VuY2UgZm9yIGFsbCBmb3JjZXMNCmlm ICEoLWUgJGZpbGUuc2NmKSBnb3RvIG9yYg0Kc2V0IG5hdG9tID0gYGdyZXAg VU5JVENFTEwgJGZpbGUub3V0cHV0MCB8YXdrICd7cHJpbnQgJE5GfSdgDQpz ZXQgaWF0b20gPSAxDQpzZXQgZnRlc3QgPSAoMSAwKQ0Kd2hpbGUgKCRpYXRv bSA8PSAkbmF0b20pIAkJI2N5Y2xlIG92ZXIgYWxsIGF0b21zIA0KICBpZiAo JGlhdG9tIDw9IDkpIHRoZW4NCiAgICAgIHNldCB0ZXN0ID0gKGAkYmluL3Rl c3Rjb252IC1wIDpGT1IwJGlhdG9tIC1jICRmY3V0YCkJDQogIGVsc2UNCiAg ICAgIHNldCB0ZXN0ID0gKGAkYmluL3Rlc3Rjb252IC1wIDpGT1IkaWF0b20g LWMgJGZjdXRgKQkNCiAgZW5kaWYNCiAgaWYgICEoJHRlc3RbMV0pIHNldCBm dGVzdFsxXSA9IDANCiAgc2V0IGZ0ZXN0WzJdID0gJHRlc3RbMl0NCiAgc2V0 IGZ0ZXN0ICAgID0gKCRmdGVzdCAkdGVzdFszXSAkdGVzdFs0XSkNCiAgQCBp YXRvbSArKw0KZW5kDQplY2hvICI6Rk9SQ0UgY29udmVyZ2VuY2U6ICAkZnRl c3RbMS1dIgkJCT4+ICRkYXlmaWxlDQoNCmlmICgkZnRlc3RbMV0pIHRoZW4J CQkjZm9yY2UgY29udmVyZ2VuY2VkDQogIGlmICgkbm9obnMgPT0gJy1ub2hu cycpIHRoZW4JCQkjZm9yY2UgY29udmVyZ2VuY2VkDQogICAgICBzZXQgbm9o bnMgDQogICAgICBlY2hvICJOT0hOUyBkZWFjdGl2YXRlZCBieSBGT1JDRSBj b252ZXJnZW5jZSIJCT4+ICRkYXlmaWxlDQogIGVsc2UNCiAgICAgIHNldCBp dGVyID0gMQ0KICAgICAgdW5zZXQgZl9ub3RfY29udiANCiAgICAgIGZvcmVh Y2ggaSAoJGZpbGUuaW4yKikNCiAgICAgICAgVE9UdG9GT1IgJGkJCQkJI3N3 aXRjaCBGT1ItbGFiZWwNCiAgICAgIGVuZA0KICBlbmRpZg0KZW5kaWYNCg0K b3JiOg0KZm9yZWFjaCBpIChkbWF0dXAgZG1hdGRuICkNCiAgaWYgKC1lICRm aWxlLiRpICkgY3AgJGZpbGUuJGkgJGZpbGUuJGkiX29sZCIJCSNzYXZlIHRo aXMgY3ljbGUgZm9yIG5leHQNCmVuZA0KDQppZiAoIC1lICRmaWxlLnNjZm9y YnVwICkgcm0gJGZpbGUuc2Nmb3JidXAgDQppZiAoIC1lICRmaWxlLnNjZm9y YmRuICkgcm0gJGZpbGUuc2Nmb3JiZG4gDQppZiAoICIkb3JiIiAhPSAiLW9y YiIgKSBnb3RvIGxhcHcxDQppZiAoICQ/b3JiYyApIGdvdG8gbGFwdzENCmlm ICghIC1lICRmaWxlLmRtYXR1cCB8fCAteiAkZmlsZS5kbWF0dXAgKSBnb3Rv IGxhcHcxDQojZm9yZWFjaCBpICggdm9yYnVwIHZvcmJkbiB2b3JiZHUgKQ0K IyAgaWYgKC1lICRmaWxlLiRpICkgXA0KIyAgY3AgJGZpbGUuJGkgJGZpbGUu JGkiX29sZCIJCSNzYXZlIGxhc3QgY3ljbGUNCiNlbmQNCnRlc3RpbnB1dAkk ZmlsZS5pbm9yYiBlcnJvcl9pbnB1dA0KdG90YWxfZXhlYwlvcmIgLXVwICRw YXJhDQp0b3RhbF9leGVjCW9yYiAtZG4gJHBhcmENCg0KbGFwdzE6DQp0ZXN0 aW5wdXQJJGZpbGUuaW4xIGxhcHcxYw0KaWYgKC1lIC5mdWxsZGlhZykgdGhl bg0KICBlY2hvICIgICAgZnVsbCBkaWFnb25hbGl6YXRpb24gZm9yY2VkIg0K ICBzZXQgaXQwDQogIHJtIC5mdWxsZGlhZw0KZW5kaWYNCiNnZW5lcmF0ZXMg aW4xLWZpbGUgZnJvbSA6RVBML0VQSCBpbiBjYXNlLnNjZjIgDQojICBpZiAo JGljeWNsZSA9PSAkaW4xbmV3KSBybSAkZmlsZS5icm95ZDEgJGZpbGUuYnJv eWQyIA0KICBpZiAoJGljeWNsZSA+PSAkaW4xbmV3ICkgdGhlbg0KICAgIGlm ICghIC1lICRmaWxlLmluMV9vcmlnICkgY3AgJGZpbGUuaW4xICRmaWxlLmlu MV9vcmlnDQogICAgd3JpdGVfaW4xX2xhcHcgLXVwIC1xbCAkcWxpbWl0ID4+ ICRkYXlmaWxlDQogICAgaWYoJHN0YXR1cyA9PSAwICkgY3AgJGZpbGUuaW4x bmV3ICRmaWxlLmluMQ0KICBlbmRpZg0KaWYoJD9pbjFvcmlnKSB0aGVuDQog ICAgaWYgKCAtZSAkZmlsZS5pbjFfb3JpZyApIGNwICRmaWxlLmluMV9vcmln ICRmaWxlLmluMQ0KICAgIHVuc2V0IGluMW9yaWcNCmVuZGlmDQppZiAoICIk c28iID09ICItc28iICkgdGhlbg0KICB0b3RhbF9leGVjCWxhcHcxICRpdDAg LXVwICRwYXJhICRub2hucw0KZWxzZQ0KICB0b3RhbF9leGVjCWxhcHcxICRp dDAgLXVwICRwYXJhICRub2hucyAkb3JiDQplbmRpZg0KICBpZiAoJGljeWNs ZSA+PSAkaW4xbmV3ICkgdGhlbg0KICAgIHdyaXRlX2luMV9sYXB3IC1kbiAt cWwgJHFsaW1pdCA+PiAkZGF5ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCAp IGNwICRmaWxlLmluMW5ldyAkZmlsZS5pbjENCiAgZW5kaWYNCmlmICggIiRz byIgPT0gIi1zbyIgKSB0aGVuDQogIHRvdGFsX2V4ZWMJbGFwdzEgJGl0MCAt ZG4gJHBhcmEgJG5vaG5zDQplbHNlDQogIHRvdGFsX2V4ZWMJbGFwdzEgJGl0 MCAtZG4gJHBhcmEgJG5vaG5zICRvcmINCmVuZGlmDQpzZXQgaXQwID0gJGl0 DQoNCmxhcHdzbzoNCmlmICggLWUgJGZpbGUuc2Nmc28gKSBybSAkZmlsZS5z Y2ZzbyANCmlmICggIiRzbyIgPT0gIi1zbyIgKSB0aGVuDQogICB0ZXN0aW5w dXQJJGZpbGUuaW5zbyBlcnJvcl9pbnB1dA0KICAgdG90YWxfZXhlYyBsYXB3 c28gLXVwICRvcmIgJHBhcmENCiAgIGlmICggIiRwYXJhIiAhPSAiLXAiICkg dGhlbg0KICAgICBjcCAkZmlsZS5lbmVyZ3lkdW0gJGZpbGUuZW5lcmd5ZHVt dXANCiAgICAgY3AgJGZpbGUuZW5lcmd5ZHVtICRmaWxlLmVuZXJneWR1bWRu DQogICBlbmRpZg0KICAgZ290byBsYXB3MmMNCmVuZGlmDQoNCmxhcHcyOg0K dGVzdGlucHV0CSRmaWxlLmluMiBlcnJvcl9pbnB1dA0KdG90YWxfZXhlYwls YXB3MiAtdXAgJHBhcmENCnRvdGFsX2V4ZWMJbGFwdzIgLWRuICRwYXJhDQoN CmxhcHdkbToNCmlmICggLWUgJGZpbGUuc2NmZG11cCApIHJtICRmaWxlLnNj ZmRtdXAgDQppZiAoIC1lICRmaWxlLnNjZmRtZG4gKSBybSAkZmlsZS5zY2Zk bWRuDQppZiAoICIkb3JiIiAhPSAiLW9yYiIgKSBnb3RvIGxhcHcxcw0KaWYg KCAkP29yYmMgKSBnb3RvIGxhcHcxcw0KdGVzdGlucHV0CSRmaWxlLmluZG0g ZXJyb3JfaW5wdXQNCnRvdGFsX2V4ZWMJbGFwd2RtIC11cCAkcGFyYQ0KdG90 YWxfZXhlYwlsYXB3ZG0gLWRuICRwYXJhDQoNCmxhcHcxczoNCmlmICggJGl0 ID09ICItaXQiICkgdGhlbg0KICB0b3VjaCAke3NjcmF0Y2h9JGZpbGUudmVj dG9yLm9sZA0KICBmb3JlYWNoIGkgKCR7c2NyYXRjaH0kZmlsZS52ZWN0b3Iq Lm9sZCkNCiAgICBybSAkaQ0KICBlbmQNCiAgZm9yZWFjaCBpICggJHtzY3Jh dGNofSRmaWxlLnZlY3RvciogKQ0KICBpZiAoISAteiAkaSkgbXYgJGkgJGku b2xkDQogIGVuZA0KZW5kaWYNCnRlc3RpbnB1dAkkZmlsZS5pbjFzIGxjb3Jl DQp0b3RhbF9leGVjCWxhcHcxIC1zYyAtdXAgJHBhcmEgJG5vaG5zICRvcmIN CnRvdGFsX2V4ZWMJbGFwdzEgLXNjIC1kbiAkcGFyYSAkbm9obnMgJG9yYg0K DQpsYXB3MnM6DQp0ZXN0aW5wdXQJJGZpbGUuaW4ycyBlcnJvcl9pbnB1dA0K dG90YWxfZXhlYwlsYXB3MiAtc2MgLXVwICRwYXJhDQp0b3RhbF9leGVjCWxh cHcyIC1zYyAtZG4gJHBhcmENCmdvdG8gbGNvcmUNCg0KbGFwdzFjOg0KdGVz dGlucHV0CSRmaWxlLmluMWMgZXJyb3JfaW5wdXQNCmlmICgtZSAuZnVsbGRp YWcpIHRoZW4NCiAgZWNobyAiICAgIGZ1bGwgZGlhZ29uYWxpemF0aW9uIGZv cmNlZCINCiAgc2V0IGl0MA0KICBybSAuZnVsbGRpYWcNCmVuZGlmDQojZ2Vu ZXJhdGVzIGluMS1maWxlIGZyb20gOkVQTC9FUEggaW4gY2FzZS5zY2YyIA0K IyAgaWYgKCRpY3ljbGUgPT0gJGluMW5ldykgcm0gJGZpbGUuYnJveWQxICRm aWxlLmJyb3lkMiANCiAgaWYgKCRpY3ljbGUgPj0gJGluMW5ldyApIHRoZW4N CiAgICBpZiAoISAtZSAkZmlsZS5pbjFjX29yaWcgKSBjcCAkZmlsZS5pbjFj ICRmaWxlLmluMWNfb3JpZw0KICAgIHdyaXRlX2luMV9sYXB3IC11cCAtYyAt cWwgJHFsaW1pdCA+PiAkZGF5ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCAp IGNwICRmaWxlLmluMWNuZXcgJGZpbGUuaW4xYw0KICBlbmRpZg0KaWYoJD9p bjFvcmlnKSB0aGVuDQogICAgaWYgKCAtZSAkZmlsZS5pbjFjX29yaWcgKSBj cCAkZmlsZS5pbjFjX29yaWcgJGZpbGUuaW4xYw0KICAgIHVuc2V0IGluMW9y aWcNCmVuZGlmDQppZiAoICIkc28iID09ICItc28iICkgdGhlbg0KIHRvdGFs X2V4ZWMJbGFwdzEgJGl0MCAtYyAtdXAgJHBhcmEgJG5vaG5zIA0KZWxzZQ0K IHRvdGFsX2V4ZWMgICAgIGxhcHcxICRpdDAgLWMgLXVwICRwYXJhICRub2hu cyAkb3JiDQplbmRpZg0KICBpZiAoJGljeWNsZSA+PSAkaW4xbmV3ICkgdGhl bg0KICAgIHdyaXRlX2luMV9sYXB3IC1kbiAtYyAtcWwgJHFsaW1pdCA+PiAk ZGF5ZmlsZQ0KICAgIGlmKCRzdGF0dXMgPT0gMCApIGNwICRmaWxlLmluMWNu ZXcgJGZpbGUuaW4xYw0KICBlbmRpZg0KaWYgKCAiJHNvIiA9PSAiLXNvIiAp IHRoZW4NCiB0b3RhbF9leGVjCWxhcHcxICRpdDAgLWMgLWRuICRwYXJhICRu b2hucyANCmVsc2UNCiB0b3RhbF9leGVjICAgICBsYXB3MSAkaXQwIC1jIC1k biAkcGFyYSAkbm9obnMgJG9yYg0KZW5kaWYNCg0Kc2V0IGl0MCA9ICRpdA0K DQpsYXB3c29jOg0KaWYgKCAtZSAkZmlsZS5zY2ZzbyApIHJtICRmaWxlLnNj ZnNvIA0KaWYgKCAiJHNvIiA9PSAiLXNvIiApIHRoZW4NCiAgIHRlc3RpbnB1 dAkkZmlsZS5pbnNvIGVycm9yX2lucHV0DQogICB0b3RhbF9leGVjIGxhcHdz byAtdXAgLWMgJG9yYiAkcGFyYQ0KICAgaWYgKCAiJHBhcmEiICE9ICItcCIg KSB0aGVuDQogICAgIGNwICRmaWxlLmVuZXJneWR1bSAkZmlsZS5lbmVyZ3lk dW11cA0KICAgICBjcCAkZmlsZS5lbmVyZ3lkdW0gJGZpbGUuZW5lcmd5ZHVt ZG4NCiAgIGVuZGlmDQplbmRpZg0KDQpsYXB3MmM6DQp0ZXN0aW5wdXQJJGZp bGUuaW4yYyBlcnJvcl9pbnB1dA0KdG90YWxfZXhlYwlsYXB3MiAtYyAtdXAg JHNvICRwYXJhDQp0b3RhbF9leGVjCWxhcHcyIC1jIC1kbiAkc28gJHBhcmEN Cg0KbGFwd2RtYzoNCmlmICggLWUgJGZpbGUuc2NmZG11cCApIHJtICRmaWxl LnNjZmRtdXAgDQppZiAoIC1lICRmaWxlLnNjZmRtZG4gKSBybSAkZmlsZS5z Y2ZkbWRuDQp0ZXN0aW5wdXQJJGZpbGUuaW4yYyBlcnJvcl9pbnB1dA0KaWYg KCAhICQ/ZG0gKSB0aGVuIA0KIGlmICggIiRvcmIiICE9ICItb3JiIiApIGdv dG8gbGFwdzFjcw0KIGlmICggJD9vcmJjICkgZ290byBsYXB3MWNzDQplbmRp Zg0KdGVzdGlucHV0CSRmaWxlLmluZG1jIGVycm9yX2lucHV0DQp0b3RhbF9l eGVjCWxhcHdkbSAtdXAgJHBhcmEgJHNvIC1jDQppZiAoICIkc28iICE9ICIt c28iICkgdGhlbg0KdG90YWxfZXhlYwlsYXB3ZG0gLWRuICRwYXJhIC1jDQpl bmRpZg0KDQpsYXB3MWNzOg0KaWYgKCAkaXQgPT0gIi1pdCIgKSB0aGVuDQog IHRvdWNoICR7c2NyYXRjaH0kZmlsZS52ZWN0b3Iub2xkDQogIGZvcmVhY2gg aSAoJHtzY3JhdGNofSRmaWxlLnZlY3Rvcioub2xkKQ0KICAgIHJtICRpDQog IGVuZA0KICBmb3JlYWNoIGkgKCAke3NjcmF0Y2h9JGZpbGUudmVjdG9yKiAp DQogIGlmICghIC16ICRpKSBtdiAkaSAkaS5vbGQNCiAgZW5kDQplbmRpZg0K dGVzdGlucHV0CSRmaWxlLmluMWNzIGxjb3JlDQp0b3RhbF9leGVjCWxhcHcx IC1jIC1zYyAtdXAgJHBhcmEgJG5vaG5zICRvcmINCnRvdGFsX2V4ZWMJbGFw dzEgLWMgLXNjIC1kbiAkcGFyYSAkbm9obnMgJG9yYg0KDQpsYXB3MmNzOg0K dGVzdGlucHV0CSRmaWxlLmluMmNzIGVycm9yX2lucHV0DQp0b3RhbF9leGVj CWxhcHcyIC1jIC1zYyAtdXAgJHBhcmENCnRvdGFsX2V4ZWMJbGFwdzIgLWMg LXNjIC1kbiAkcGFyYQ0KDQpsY29yZToNCnRlc3RpbnB1dAkkZmlsZS5pbmMg c2NmDQp0b3RhbF9leGVjCWxjb3JlIC11cA0KdG90YWxfZXhlYwlsY29yZSAt ZG4NCg0Kc2NmOg0KZm9yZWFjaCBpICggMCBvcmJ1cCBvcmJkbiAxdXAgMWRu IHNvIDJ1cCAyZG4gZG11cCBkbWRuIDFzdXAgMXNkbiAyc3VwIDJzZG4gY3Vw IGNkbiApDQogIGlmICgtZSAkZmlsZS5zY2YkaSkgdGhlbg0KICAgICAgaWYg KCIkaSIgIT0gImRtZG4iIHx8ICIkc28iICE9ICItc28iKSBjYXQgJGZpbGUu c2NmJGkgID4+ICRmaWxlLnNjZg0KICBlbmRpZg0KZW5kDQpmb3JlYWNoIGkg KGNsbXN1bSBjbG11cCBjbG1kbiB2c3B1cCB2c3BkbiB2bnN1cCB2bnNkbiAp DQogIGlmICgtZSAkZmlsZS4kaSApIGNwICRmaWxlLiRpICRmaWxlLiRpIl9v bGQiCQkjc2F2ZSBsYXN0IGN5Y2xlDQplbmQNCg0KbWl4ZXI6DQp0ZXN0aW5w dXQJJGZpbGUuaW5tIGVycm9yX2lucHV0DQp0b3RhbF9leGVjCW1peGVyDQpj YXQgJGZpbGUuc2NmbSA+PiAkZmlsZS5zY2YNCg0KaWYoJD9yZW5vcm0pIHRo ZW4NCiAgIHVuc2V0IHJlbm9ybQ0KICAgcm0gJGZpbGUuYnJveSoNCmVuZGlm DQoNCm1peGVyX3ZyZXNwOg0KdGVzdGlucHV0ICAgICAgICRmaWxlLmlubV92 cmVzcCBlbmVyZ3l0ZXN0DQp0b3RhbF9leGVjICAgICAgbWl4ZXJfdnJlc3AN CiN0b3RhbF9leGVjICAgICAgaW50MTYNCg0KZW5lcmd5dGVzdDoNCiMtLS0+ IG91dHB1dCBlbmVyZ2llcw0KI3NldCBFRiA9IGBncmVwICdGIEUgUicgJGZp bGUuc2NmMiAgICB8YXdrICd7cHJpbnRmKCIlLjVmIiwgJE5GKX0nYA0KI3Nl dCBFVCA9IGBncmVwICdBTCBFTicgJGZpbGUub3V0cHV0bSB8YXdrICd7cHJp bnRmKCIlLjVmIiwgJE5GKX0nYA0KI2NhdCA8PCB0aGVlbmQJCQkJPj4gJGRh eWZpbGUNCiNFRiAgJEVGDQojRVQgICRFVA0KI3RoZWVuZA0KI2VjaG8gJEVU IAkJCQk+ICRmaWxlLmZpbk0NCg0KIy0tLT4gdGVzdCBvZiBlbmVyZ3kgY29u dmVyZ2VuY2UNCiNpZiAoJGVjdXQgPT0gIjAiKSBnb3RvIGNoYXJnZXRlc3QN CnNldCBldGVzdCA9IChgJGJpbi90ZXN0Y29udiAtcCA6RU5FIC1jICRlY3V0 YCkJDQp0ZXN0c3RhdHVzDQplY2hvICI6RU5FUkdZIGNvbnZlcmdlbmNlOiAg JGV0ZXN0WzEtM10iCQk+PiAkZGF5ZmlsZQ0KaWYgKCRldGVzdFsxXSkgdGhl bg0KICBpZiAoJG5vaG5zID09ICctbm9obnMnKSB0aGVuDQogICAgICBzZXQg bm9obnMgDQogICAgICBlY2hvICJOT0hOUyBkZWFjdGl2YXRlZCBieSBFTkVS R1kgY29udmVyZ2VuY2UiCQk+PiAkZGF5ZmlsZQ0KICBlbHNlDQogICAgICBz ZXQgaXRlciA9IDENCiAgZW5kaWYNCmVuZGlmDQoNCmNoYXJnZXRlc3Q6DQoj aWYgKCRjY3V0ID09ICIwIikgZ290byBuZXh0aXRlcg0Kc2V0IGN0ZXN0ID0g KGAkYmluL3Rlc3Rjb252IC1wIDpESVMgLWMgJGNjdXRgKQkNCnRlc3RzdGF0 dXMNCmVjaG8gIjpDSEFSR0UgY29udmVyZ2VuY2U6ICAkY3Rlc3RbMS0zXSIJ CT4+ICRkYXlmaWxlDQppZiAoJGN0ZXN0WzFdKSB0aGVuDQogIGlmICgkbm9o bnMgPT0gJy1ub2hucycpIHRoZW4NCiAgICAgIHNldCBub2hucyANCiAgICAg IGVjaG8gIk5PSE5TIGRlYWN0aXZhdGVkIGJ5IENIQVJHRSBjb252ZXJnZW5j ZSIJCT4+ICRkYXlmaWxlDQogIGVsc2UNCiAgICAgIHNldCBpdGVyID0gMQ0K ICBlbmRpZg0KZW5kaWYNCg0KIy0tLT4gb3V0cHV0IGZvcmNlcw0KI2dyZXAg J0ZUT1QnICRmaWxlLm91dHB1dG18YXdrICd7cHJpbnQgIkZUICIsJDIsJDQs JDUsJDZ9J1wNCiMJCQkJCT4+ICRkYXlmaWxlDQojZ3JlcCAnRlRPVCcgJGZp bGUub3V0cHV0bXxhd2sgJ3twcmludCAkNCwkNSwkNn0nIFwNCiMJCQkJCT4+ ICRmaWxlLmZpbk0JDQoNCm5leHRpdGVyOg0KQCAgaXRlciAtLQ0KQCByaXRl ciAtLQ0KQCBub2huczEgLS0NCkAgaWN5Y2xlICsrDQoNCiMtLS0+IG5vaG5z DQppZiAoISAkbm9obnMxICkgdGhlbg0KICBzZXQgbm9obnMNCiAgZWNobyAi Tk9ITlMgZGVhY3RpdmF0ZWQiIAkJCT4+ICRkYXlmaWxlDQplbmRpZg0KDQoj LS0tPiByZXN0YXJ0DQppZiAoISAkcml0ZXIgJiYgLWUgJGZpbGUuYnJveWQx KSB0aGVuDQogIGVjaG8gIiAgICByZXN0YXJ0IiAJCQk+PiAkZGF5ZmlsZQ0K ICBybSAkZmlsZS5icm95ZDEgJGZpbGUuYnJveWQyDQogIHNldCByaXRlcj0k cml0ZXJfc2F2ZQ0KZW5kaWYNCg0KZm9yZWFjaCBpICgkdG1wKQkJCSNkZWxl dGUgdGVtcG9yYXJ5IGZpbGVzDQogIGlmICgtZSAkaSkgcm0gJGkNCmVuZA0K DQojb3V0cHV0CQljeWNsZQ0KcHJpbnRmICIlc1xuXG4iICIkaXRlci8kcml0 ZXIgdG8gZ28iIAk+PiAkZGF5ZmlsZQ0KaWYgKC1lIC5zdG9wKSBnb3RvIHN0 b3AxDQoNCmlmICgkaXRlcikgZ290byBjeWNsZQkJCSNlbmQgb2Ygc2MtY3lj bGUNCg0KaWYgKCAkP2Zfbm90X2NvbnYgKSB0aGVuDQogICAgICBwcmludGYg IlxuPiAgIEZPUkNFUyBOT1QgQ09OVkVSR0VEXG4iCQkJPj4gJGRheWZpbGUg ICAgDQogICAgICBleGl0IDMNCmVuZGlmDQoNCnN0b3A6CQkJCQkjbm9ybWFs IGV4aXQNCnByaW50ZiAiXG4+ICAgc3RvcFxuIgkJCT4+ICRkYXlmaWxlDQpl eGl0IDAgDQoNCnN0b3AxOgkJCQkJI25vcm1hbCBleGl0DQpwcmludGYgIlxu PiAgIHN0b3AgZHVlIHRvIC5zdG9wIGZpbGVcbiIJCQk+PiAkZGF5ZmlsZQ0K aWYgKC1lIC5zdG9wKSBybSAuc3RvcA0KZXhpdCAwIA0KDQplcnJvcl9pbnB1 dDoJCQkJCSNlcnJvciBleGl0CQ0KcHJpbnRmICJcbj4gICBzdG9wIGVycm9y OiB0aGUgcmVxdWlyZWQgaW5wdXQgZmlsZSAkZXJyaW4gZm9yIHRoZSBuZXh0 IHN0ZXAgY291bGQgbm90IGJlIGZvdW5kXG4iCQk+PiAkZGF5ZmlsZQ0KZXhp dCAxDQoNCmVycm9yOgkJCQkJI2Vycm9yIGV4aXQJDQpwcmludGYgIlxuPiAg IHN0b3AgZXJyb3JcbiIJCT4+ICRkYXlmaWxlDQpleGl0IDENCg0KaGVscDoJ CQkJCSNoZWxwIGV4aXQgDQpjYXQgPDwgdGhlZW5kIA0KDQpQUk9HUkFNOgkk MA0KDQpQVVJQT1NFOglydW5uaW5nIHRoZSBzcGlucG9sYXJpemVkIHNjZi1j eWNsZSBpbiBXSUVODQoJCXRvIGJlIGNhbGxlZCB3aXRoaW4gdGhlIGNhc2Ut ZGlyZWN0b3J5DQoJCWhhcyB0byBiZSBsb2NhdGVkIGluICckV0lFTlJPT1Qn IGRpcmVjdG9yeQ0KDQpVU0FHRToJCSRuYW1lIFtPUFRJT05TXSBbRkxBR1Nd DQoNCk9QVElPTlM6DQotY2MgTElNSVQgLT4JY2hhcmdlIGNvbnZlcmNlbmNl IExJTUlUICgkY2N1dCkNCi1lYyBMSU1JVCAtPgllbmVyZ3kgY29udmVyY2Vu Y2UgTElNSVQgKCRlY3V0IFJ5KQ0KLWZjIExJTUlUIC0+CWZvcmNlICBjb252 ZXJjZW5jZSBMSU1JVCAoJGZjdXQgbVJ5L2EudS4pDQotZSBQUk9HUkFNIC0+ CWV4aXQgYWZ0ZXIgUFJPR1JBTSAoJHN0b3BhZnRlcikNCi1pIE5VTUJFUiAt PiAJbWF4LiBOVU1CRVIgKCRpdGVyKSBvZiBpdGVyYXRpb25zDQotcyBQUk9H UkFNIC0+IAlzdGFydCB3aXRoIFBST0dSQU0gKCRuZXh0KQ0KLXIgTlVNQkVS IC0+IAlyZXN0YXJ0IGFmdGVyIE5VTUJFUiAoJHJpdGVyKSBpdGVyYXRpb25z IChybSAqLmJyb3lkKikNCi1ub2hucyBOVU1CRVIgLT5kbyBub3QgdXNlIEhO UyBmb3IgTlVNQkVSIGl0ZXJhdGlvbnMgDQotcWwgTElNSVQgLT4gICAgc2Vs ZWN0IExJTUlUICgkcWxpbWl0KSBhcyBtaW4uY2hhcmdlIGZvciBFLUwgc2V0 dGluZyBpbiBuZXcgaW4xDQotaW4xbmV3IE4gLT4gICAgdXNlICJuZXciIGlu MSBmaWxlIGFmdGVyIE4gaXRlciAocmV3cml0ZSBpbjEgdXNpbmcgc2NmIGlu Zm8pDQoNCkZMQUdTOg0KLWgvLUggLT4JaGVscA0KLUkgICAgLT4Jd2l0aCBp bml0aWFsaXphdGlvbiBvZiBpbjItZmlsZXMgdG8gIlRPVCIgDQotcCAgICAt PiAgICAgICAgcnVuIGstcG9pbnRzIGluIHBhcmFsbGVsIChuZWVkcyAubWFj aGluZSBmaWxlIFtzcGVlZDpuYW1lXSkNCi1zbyAgIC0+CXJ1biBTQ0YgaW5j bHVkaW5nIHNwaW4tb3JiaXQgY291cGxpbmcNCi1kbSAgIC0+CWNhbGN1bGF0 ZSB0aGUgZGVuc2l0eSBtYXRyaXggKHdoZW4gLXNvIGlzIHNldCwgYnV0IC1v cmIgaXMgbm90KQ0KLWl0ICAgLT4gICAgICAgIHVzZSBpdGVyYXRpdmUgZGlh Z29uYWxpemF0aW9uIGFmdGVyIGZpcnN0IGN5Y2xlDQotaXQwICAtPgl1c2Ug aXRlcmF0aXZlIGRpYWdvbmFsaXphdGlvbiAoYWxzbyBpbiBmaXJzdCBjeWNs ZSkNCi1vcmIgIC0+ICAgICAgICB1c2UgTERBK1UsIE9QIG9yIEItZXh0IGNv cnJlY3Rpb24gDQotb3JiYyAtPiAgICAgICAgdXNlIExEQStVIGNvcnJlY3Rp b24sIGJ1dCB3aXRoIGNvbnN0YW50IFYtbWF0cml4IA0KLXJlbm9ybS0+ICAg ICAgIHN0YXJ0IHdpdGggbWl4ZXIgYW5kIHJlbm9ybWFsaXplIGRlbnNpdHkN Ci1pbjFvcmlnLT4gICAgICB1c2UgY2FzZS5pbjFfb3JpZyBmaWxlIChhZnRl ciBhIHByZXZpb3VzIC1pbjFuZXcpDQoJCQ0KQ09OVFJPTCBGSUxFUzoNCi5z dG9wCQlzdG9wIGFmdGVyIFNDRiBjeWNsZQ0KLmZ1bGxkaWFnCWZvcmNlIGZ1 bGwgZGlhZ29uYWxpemF0aW9uDQoNCkVOVklST05NRU5UIFZBUklCTEVTOg0K U0NSQVRDSCAgICAgICAgIGRpcmVjdG9yeSAgd2hlcmUgdmVjdG9ycyBhbmQg aGVscCBmaWxlcyBzaG91bGQgZ28NCg0KdGhlZW5kDQoNCmV4aXQgMQ0KDQoN Cg== - --1621681473-1344807548-1041914453=:18432-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 7 Jan 2003 08:23:06 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: runsp_lapw ==== Peter Blaha submitted the following contribution: ==== > In connection with your answer to the qurey on w2k-list "Why does > LDA+U stop at .....", does it answer my qurey on runsp_lapw -so -orb which > I put last week? Maybe. > if ( "$so" == "-so" && -s $file.dmatud ) then > total_exec orb -du $para > > do you mean to say we have to comment these two lines also? Should not be necessary, but does not harm. > PRATT in case.inorb means > BROYD doesnot work for -orb. > > If case.inm contain BROYD but case.inorb contain PRATT, orbital charge > densities will be mixed using PRATT scheme (mixer is invoked during -orb > run) but the final charge densities at the end of cycle will be done by > BROYD scheme and case.scf file should contain BROYD instead of PRATT. is > it right? It means that the density matrices (*dmat*) are now also mixed in "mixer" and thus must not be mixed at all in "orb". This is achieved by PRATT 1.0 in case.inorb (which is the default). Regards 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 7 Jan 2003 10:13:27 +0100 From: "Kevin Jorissen" Subject: Re: [WIEN]: Problems with crystalstructure ==== "Kevin Jorissen" submitted the following contribution: ==== Only inequivalent atoms are listed in the inst-file. There is only one entry for each class of equivalent atoms! kind regards, Kevin Jorissen. - ----- Original Message ----- From: "romdhani hedi" To: Sent: Monday, January 06, 2003 5:45 PM Subject: Re: [WIEN]: Problems with crystalstructure > ==== > romdhani hedi > submitted the following contribution: > ==== > > > --- Kevin Jorissen wrote: > > ==== > > "Kevin Jorissen" > > submitted the following contribution: > > ==== > > > > > Dear Veerle, > > > your atoms are equivalent in *.inst but > > inequivalent > > > in *.struct, why ? > > > Thanks > > > > > > > There are 24 atoms in her struct and 24 in her inst, > > what do you mean? > > > > kind regards, > > > > Kevin Jorissen > > > > > > > __________________________________________________ > ****************************************************** > there are 24 atoms in both files. In *.inst for > example all Ag atoms are indexed by Ag1, but in > *.struct they are indexed by Ag1, Ag2,....which make > inequivalent. > Thanks > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 07 Jan 2003 06:02:07 -0500 From: "michel certier" Subject: Re: [WIEN]: parallel execution problem in dual PIV ==== "michel certier" submitted the following contribution: ==== dear wien users i posted a message about a problem of parallel execution in dual PIV with 2 proc : "> Dear wien users Happy New year !!! > I met somme problem to execut a parallel job for cubic system with 35 k-point on dual machine, after 1 iteration the program stop and I get the following message: > > LAPW0 END > LAPW1 END > LAPW1 END > LAPW2 - FERMI; weighs written > LAPW2 END > LAPW2 END > SUMPARA END > SUMPARA END > CORE END > MIXER END > in cycle 2 ETEST: 0 CTEST: 0 > PGFIO-F-231/formatted read/unit=8/error on data conversion. > File name = test.clmsum formatted, sequential access record = 2223 > In source file lapw0.F, at line number 404 > cat: No match. > My .machines files is : > > granularity:1 > 17:localhost > 18:localhost > The program run well in serial mode. > Can some one give me a solution to this problem. > Thank's " I have change my number of kpoint to 56-k to have an homogen number of k-point in each proc and its run but I get many warning in my scf files with a big fluctuation in energy until a convergence. Have any one an idea !!! Thanks one more - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Tue, 7 Jan 2003 11:42:05 -0800 (PST) From: yanming Ma Subject: [WIEN]: For help ==== yanming Ma submitted the following contribution: ==== - --0-997329679-1041968525=:94367 Content-Type: text/plain; charset=us-ascii Dear Wien2k users, I am trying to calculate the electric momentum density. But I do not know which code I should use. Does someone know which code can calculate electric momentum density? please let me know. Thanks very much. Best Wishes! Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-997329679-1041968525=:94367 Content-Type: text/html; charset=us-ascii

Dear Wien2k users,

I am trying to calculate the electric momentum density. But I do not know which code I should use. Does someone know which code can calculate electric momentum density? please let me know.  Thanks very much.

Best Wishes!



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-997329679-1041968525=:94367-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 8 Jan 2003 08:43:18 +0100 (MET) From: Peter Blaha Subject: Re: [WIEN]: parallel execution problem in dual PIV ==== Peter Blaha submitted the following contribution: ==== > "> Dear wien users Happy New year !!! > > I met somme problem to execut a parallel job for cubic system with 35 k-point on dual machine, after 1 iteration the program stop and I get the following message: > > > > LAPW0 END > > LAPW1 END > > LAPW1 END > > LAPW2 - FERMI; weighs written > > LAPW2 END > > LAPW2 END > > SUMPARA END > > SUMPARA END > > CORE END > > MIXER END > > in cycle 2 ETEST: 0 CTEST: 0 > > PGFIO-F-231/formatted read/unit=8/error on data conversion. > > File name = test.clmsum formatted, sequential access record = 2223 > > In source file lapw0.F, at line number 404 > > cat: No match. > > My .machines files is : > > > > granularity:1 > > 17:localhost > > 18:localhost > > The program run well in serial mode. > > Can some one give me a solution to this problem. > > Thank's " > I have change my number of kpoint to 56-k to have an homogen number of k-point in each proc and its run but I get many warning in my scf files with a big fluctuation in energy until a convergence. Have any one an idea !!! Most likely you did not "save_lapw" your first calculations, before you restarted the job again. Old *broyd* files can lead to wrong clmsum files, an old scf file to large total energy fluctuations. 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@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ - -------------------------------------------------------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 08 Jan 2003 12:10:59 +0100 From: marc Subject: [WIEN]: SRC_supercell ==== marc submitted the following contribution: ==== Dear Wien2k users, I had a problem in compiling wien2k on SGI. The following error occured: SRC_supercell/compile.msg:make: file `Makefile' line 72: Syntax error Any idea? Best regards, Marc. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Wed, 8 Jan 2003 11:51:08 -0600 (CST) From: "Dr. B.R.Sahu" Subject: [WIEN]: hello ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear W2k users I donot know whether I was clear or not in my queries about MINI, MIXER and initso_lapw which I put last week to w2k mailing list. my query about runsp_lapw -so -orb is not yet clear. however,I am trying the "runsp_lapw" script provided by Reuben Weht yesterday in which "vorbdu" commands are either modified or taken out altogether. It is assured, everything is correct(ie the input files, procedure etc.) I put other queries briefly again: a) about MIXER: If say 20 iterations are done with PRATT scheme and I wish to switch to BROYD then what files to be saved/deleted before I start to continue the scf with BROYD so that MIXER use now BROYD and not PRATT for mixing OR start straightaway start the run with BROYD without saving/deleting any files. b)about MINI: how to select delta(i) values in case.inM file while doing geometry minimization with BFGS or NEWT? I feel, by properly tuning these values, one can save the number of gemoetry optimization steps and convergence will be faster as the atoms are moved by this increment using the forces calculated in the scf run. Is there any guidelines OR it's simply a guess and luck. c) about initso_lapw: during initializing the run for SOC, one need to' select the number of k-point. But the "number of k-point selection" prompt is never ending!! If I say "no" to the selection again, it stops with "if:bad number" message. do we need to modify initso_lapw script? and I then have to copy all the case.*_so files 'by hand' to corresponding case.* files before starting the scf cycle with SOC. Thanking you in advance dor suggestion/s. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 07:47:27 +0400 From: "Mohamed Elzain" Subject: Re: [WIEN]: SRC_supercell ==== "Mohamed Elzain" submitted the following contribution: ==== Sir I am not sure if the error you encountered is similar to the one I had. I had an error in the [read(*,*), vac(i)] in the main file. There shouldn't be a coma between read and var. - ----- Original Message ----- From: "marc" To: Sent: Wednesday, January 08, 2003 3:10 PM Subject: [WIEN]: SRC_supercell > ==== > marc > submitted the following contribution: > ==== > > Dear Wien2k users, > > I had a problem in compiling wien2k on SGI. > The following error occured: > > SRC_supercell/compile.msg:make: file `Makefile' line 72: Syntax error > > Any idea? > > Best regards, > > Marc. > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 09 Jan 2003 09:29:01 +0100 From: Ad Ettema Subject: [WIEN]: Spin orbit interaction ==== Ad Ettema submitted the following contribution: ==== L.S., Has any one experience with the spin orbit interaction parameters in file case.inso ? I am calculating the case of Cu2O which has a spin orbit split valence band maximum in gamma. An attempt to put in the appropriate parameters in the case.inso file did not lead to this fundamental splitting. Does anyone know a listing of so parameters published somewhere? - -- Dr A.R.H.F. Ettema Delft University of Technology Department of Physics Lorentzweg 1 2628 CJ Delft Tel : +31 15 2782481 Fax : +31 15 2781413 Email: ettema@tn.tudelft.nl Web: http://www.em.tudelft.nl/ad_ettema.htm ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 14:35:08 +0100 From: "Marc Willinger" Subject: AW: [WIEN]: SRC_supercell ==== "Marc Willinger" submitted the following contribution: ==== Thank's very much! I removed the commas, but additionally I had to deleted the following command in the Makefile, in line 72: $(PREOBJS): Makefile Honestly, I don't know if deleting that line was wise - but it seems to work now. regards, Marc Willinger ==== "Mohamed Elzain" submitted the following contribution: ==== Sir I am not sure if the error you encountered is similar to the one I had. I had an error in the [read(*,*), vac(i)] in the main file. There shouldn't be a coma between read and var. > Dear Wien2k users, > > I had a problem in compiling wien2k on SGI. > The following error occured: > > SRC_supercell/compile.msg:make: file `Makefile' line 72: Syntax error > > Any idea? > > Best regards, > > Marc. > > > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 09 Jan 2003 21:59:27 +0800 From: "liu wan" Subject: [WIEN]: Question about how to use "XCrySDen" software ==== "liu wan" submitted the following contribution: ==== Dear All I want using the XCrySDen to creat the k-list for the energy bandstructure plots. But I has some questions about how to use XCrySDen. (1) There are primitive Brillouin Zone and conventional Brillouin Zone, which one I will use? (2) How to set the "ISS" value? Use the default one? Would you please explain the means of ISS? CXZ LATTICE,NONEQUIV. ATOMS: 6 12 B2/m MODE OF CALC=RELA 32.888800 19.759000 7.704420 90.000000 90.000000104.440000 When I try to get the k-path of above-file, I get following k-list file: X0 0 0 0***** 2.0-7.00 1.50 k-list generated by XCrySDen ***** 0 0***** 2.0 ***** 0 0***** 2.0 ***** 0 0***** 2.0 ***** 0 0***** 2.0 ***** 0 0***** 2.0 ***** 0 0***** 2.0 ***** 0 0***** 2.0 X1 ***** 0 0***** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 ***** 0********** 2.0 I don't know what is wrong? Best wish Liu Best wish Liu _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 10:33:25 -0500 From: Fred Nastos Subject: Re: [WIEN]: Spin orbit interaction ==== Fred Nastos submitted the following contribution: ==== > I am calculating the case of Cu2O which has a spin orbit split valence > band maximum in gamma. An attempt to put in the appropriate parameters > in the case.inso file did not lead to this fundamental splitting. > Does anyone know a listing of so parameters published somewhere? Being a first-principles code, there aren't really any parameters to play with (I'm not talking about LDA+U of course). In every system (only about five simple ones mind you) te WIEN code has given the split-off band due to spin-orbit interaction, and when there is no-inversion symmetry there is also spin-spin splitting. Since the spin-orbit interaction is strongly influenced by the symmetry, are you sure your structure file is correct? If you are looking into the case.output files for the band energies, the spin-orbit energies are in case.outputso. ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 08:22:54 -0800 (PST) From: yanming Ma Subject: [WIEN]: Question about the parallelization ==== yanming Ma submitted the following contribution: ==== - --0-1892235412-1042129374=:30847 Content-Type: text/plain; charset=us-ascii Dear Wien2k Users, I was puzzled by the K point and fine grained parallelization in Wien2k. As I know, for some small cases, I should use K-point parallel, while for some extremely large cases, I should use fine grained parallel. When I compile the wien2k code in SGI tp0 machine if i chose the fine grained parallelization option, does that mean all my parallel calculation should be in fine grained parallelization? Or it depends on how to make the .machines file. (1) .machine file as the following should be k_point parallelization if i try to use 4 CPUs. 1:tp0:1 1:tp0:1 1:tp0:1 1:tp0:1 (2).machine file as the following should be fine grained parallelization if i try to use 4 CPUs. lapw0:tp0:4 1:tp0:4 Are the described aboves correct? I will appreciate highly your answer. Yanming Ma Ph.D Steacie Institute for Molecular Sciences, National Research Councils of Canada, Ottawa, Ontario K1A 0R6 Canada - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1892235412-1042129374=:30847 Content-Type: text/html; charset=us-ascii

Dear Wien2k Users,

I was puzzled by the K point and fine grained parallelization in Wien2k. As I know, for some small cases, I should use K-point parallel, while for some extremely large cases, I should use fine grained parallel. 
When I compile the  wien2k code in SGI tp0 machine  if i chose the fine grained parallelization option, does that mean all my parallel calculation should be in fine grained parallelization? Or it depends on how to make the .machines file.
(1) .machine file as the following should be k_point parallelization if i try to use 4 CPUs.
1:tp0:1
1:tp0:1
1:tp0:1
1:tp0:1
(2).machine file as the following should be fine grained parallelization if i try to use 4 CPUs.
lapw0:tp0:4
1:tp0:4

Are the described aboves correct?

I will appreciate highly your answer.

 



Yanming Ma Ph.D
Steacie Institute for Molecular Sciences,
National Research Councils of Canada,
Ottawa, Ontario
K1A 0R6
Canada


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1892235412-1042129374=:30847-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 12:08:22 -0800 (PST) From: Ting Su Subject: [WIEN]: compiling errors ==== Ting Su submitted the following contribution: ==== - --0-1163648082-1042142902=:30008 Content-Type: text/plain; charset=us-ascii Dear WIENers, I would strongly appreciate for any advice on the following compiling errors: make PARALLEL='-DParallel' lapw0_mpi \ FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw0' pgf90 -Mfreeform -fast -Kieee -DParallel -c modules.F PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) 0 inform, 0 warnings, 1 severes, 0 fatal for begend make[1]: *** [modules.o] Error 1 make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \ ./lapw1c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw1' modules.F: COMPLEX version extracted pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 33) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 51) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallelmatrices PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 119) 0 inform, 0 warnings, 1 severes, 0 fatal for barrier PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 129) 0 inform, 0 warnings, 1 severes, 0 fatal for close_parallel make[1]: *** [modules.o] Error 1 make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \ ./lapw2c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw2' pgf90 -Mfreeform -fast -Kieee -DParallel -c reallocate.f modules.F: COMPLEX version extracted pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 41) 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel make[1]: *** [modules.o] Error 1 Thank you very much! Tony - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1163648082-1042142902=:30008 Content-Type: text/html; charset=us-ascii

Dear WIENers,

I would strongly appreciate for any advice on the following compiling errors:

make PARALLEL='-DParallel' lapw0_mpi \
  FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel''
make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw0'
pgf90 -Mfreeform -fast -Kieee -DParallel -c modules.F
PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20)
  0 inform,   0 warnings,   1 severes, 0 fatal for init_parallel
PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43)
  0 inform,   0 warnings,   1 severes, 0 fatal for begend
make[1]: *** [modules.o] Error 1

make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \
  ./lapw1c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel''
make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw1'
modules.F: COMPLEX version extracted
pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F
PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 33)
  0 inform,   0 warnings,   1 severes, 0 fatal for init_parallel
PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 51)
  0 inform,   0 warnings,   1 severes, 0 fatal for init_parallelmatrices
PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 119)
  0 inform,   0 warnings,   1 severes, 0 fatal for barrier
PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 129)
  0 inform,   0 warnings,   1 severes, 0 fatal for close_pa! rallel
make[1]: *** [modules.o] Error 1

make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \
  ./lapw2c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel''
make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw2'
pgf90 -Mfreeform -fast -Kieee -DParallel -c reallocate.f
modules.F: COMPLEX version extracted
pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F
PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 41)
  0 inform,   0 warnings,   1 severes, 0 fatal for init_parallel
make[1]: *** [modules.o] Error 1

Thank you very much!

Tony


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-1163648082-1042142902=:30008-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 19:05:13 -0600 (CST) From: "Dr. B.R.Sahu" Subject: Re: [WIEN]: Question about the parallelization ==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Ma During compilation, if you dont choose the option for fine grained parallalization, it will create only files for single processor(ie lapw0, lapw1(c), lapw2 etc) and script for k-pt parallelization run lapw0para, lapw1para etc. If you choose the optiion for fine grained paralleliztion then in addition to the above files, the files for MPI parallel run like lapw0_mpi, lapw1_mpi and lapw2_mpi will be created. Now, whether the scripts run(sp)_lapw and other script pick up lapw*para or lapw*_mpi during the run depends on the structure of the .machines file as you mentioned. 1) the format of your k-point parallelization file is correct provided you have 4 k-points to distribute over four cpus(in your case tp0) and the cpu's have all same speed.For efficiency, only if we have more k-points then the processors or cpus then only we use k-point parallelization. but imagine a case where you have a very large system say a supercell containing large number of atoms say more than 40 and you expect it to be metallic, for example. In such cases, you need large number k-points to sample the BZ so k-point parallelization is again useful. 2) fine grained parallelization file is to be slightly modified: lapw0:tp0:1 tp0:1 tp0:1 tp0:1 1:tp0:1 tp0:1 tp0:1 tp0:1 it means lapw0_mpi will use 4 processors each having same speed and your sysetm has 1 k-point and lapw1_mpi runs on 4 processors in parallel. Fine grained parallel will be computationally efficient if you have large system(ie large number of atoms) and small number of k-points(1 or 2). that's what UG says. I myself have not tested so far the MPI parallel code, as it is giving some problem. I am already in contact with Prof. Blaha regarding this. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Thu, 9 Jan 2003 20:43:58 -0600 (CST) From: Bing Zhou Subject: [WIEN]: SCF stopped at lapw2 ==== Bing Zhou submitted the following contribution: ==== Dear All: My calculation was stopped at the lapw2 of the fouth SCF cycle, the following information is in the file lapw2.error: 'LAPW2' - can't open unit: 5 'LAPW2' - filename: tug-new.in2 'LAPW2' - status: old form: formatted Could you please help me with that? Thanks! Bing Zhou Dept. of Geological Sc. The Univ. of Manitoba Canada R3T 2N2 Tel: (204)474-8395 ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 09:15:05 +0100 From: Torsten Andersen Subject: Re: [WIEN]: compiling errors ==== Torsten Andersen submitted the following contribution: ==== Dear Ting Su, install MPI... and make the compiler aware of where it is - it can't find the header file. Best regards, Torsten Andersen. Ting Su wrote: > Dear WIENers, > > I would strongly appreciate for any advice on the following compiling > errors: > > make PARALLEL='-DParallel' lapw0_mpi \ > FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' > make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw0' > pgf90 -Mfreeform -fast -Kieee -DParallel -c modules.F > PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 20) > 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel > PGF90-S-0017-Unable to open include file: mpif.h (modules.F: 43) > 0 inform, 0 warnings, 1 severes, 0 fatal for begend > make[1]: *** [modules.o] Error 1 > > make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \ > ./lapw1c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' > make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw1' > modules.F: COMPLEX version extracted > pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F > PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 33) > 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel > PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 51) > 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallelmatrices > PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 119) > 0 inform, 0 warnings, 1 severes, 0 fatal for barrier > PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 129) > 0 inform, 0 warnings, 1 severes, 0 fatal for close_pa! rallel > make[1]: *** [modules.o] Error 1 > > make PARALLEL='-DParallel' TYPE='COMPLEX' TYPE_COMMENT='\!_COMPLEX' \ > ./lapw2c_mpi FORT=pgf90 FFLAGS=' -Mfreeform -fast -Kieee '-DParallel'' > make[1]: Entering directory `/net/hulk/home4/hbsu/WIEN2k/SRC_lapw2' > pgf90 -Mfreeform -fast -Kieee -DParallel -c reallocate.f > modules.F: COMPLEX version extracted > pgf90 -Mfreeform -fast -Kieee -DParallel -c modules_tmp_.F > PGF90-S-0017-Unable to open include file: mpif.h (modules_tmp_.F: 41) > 0 inform, 0 warnings, 1 severes, 0 fatal for init_parallel > make[1]: *** [modules.o] Error 1 > > Thank you very much! > > Tony > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Mail Plus > - > Powerful. Affordable. Sign up now > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 09:12:54 +0100 From: Torsten Andersen Subject: Re: [WIEN]: SCF stopped at lapw2 ==== Torsten Andersen submitted the following contribution: ==== Dear Bing, probably either the initialisation failed - no case.in2 or case.in2c exist, or inversion symmetry is not present - in which case you should have a case.in2c and run the complex version. If you are sure that what you do is correct, you can copy case.in2c to case.in2 and run it again. Best regards, Torsten. Bing Zhou wrote: >==== >Bing Zhou >submitted the following contribution: >==== > >Dear All: > >My calculation was stopped at the lapw2 of the fouth SCF cycle, the >following information is in the file lapw2.error: > >'LAPW2' - can't open unit: 5 >'LAPW2' - filename: tug-new.in2 >'LAPW2' - status: old form: formatted > >Could you please help me with that? > >Thanks! > > >Bing Zhou >Dept. of Geological Sc. >The Univ. of Manitoba >Canada R3T 2N2 >Tel: (204)474-8395 > >==== >WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at >To (un)subscribe send mail to >majordomo@zeus.theochem.tuwien.ac.at >==== > > - -- Dr. Torsten Andersen Department of Physics, Condensed Matter Theory Group, Uppsala University UU-WWW: http://www.fysik4.fysik.uu.se/ TA-WWW: http://deep.at/myspace News on TA-WWW: Two publ. articles on ab initio nonlinear magneto-optics ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 11:15:30 +0100 From: Ad Ettema Subject: Re: [WIEN]: Spin orbit interaction ==== Ad Ettema submitted the following contribution: ==== Dear Fred thanks for helping me here. I think you gave the right hints. Ad Fred Nastos wrote: > ==== > Fred Nastos > submitted the following contribution: > ==== > > >>I am calculating the case of Cu2O which has a spin orbit split valence >>band maximum in gamma. An attempt to put in the appropriate parameters >>in the case.inso file did not lead to this fundamental splitting. >>Does anyone know a listing of so parameters published somewhere? >> > > Being a first-principles code, there aren't really any parameters to play with > (I'm not talking about LDA+U of course). In every system (only about five > simple ones mind you) te WIEN code has given the split-off band due to > spin-orbit interaction, and when there is no-inversion symmetry there > is also spin-spin splitting. Since the spin-orbit interaction is strongly > influenced by the symmetry, are you sure your structure file is correct? > If you are looking into the case.output files for the band energies, the > spin-orbit energies are in case.outputso. > > ==== > WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at > To (un)subscribe send mail to > majordomo@zeus.theochem.tuwien.ac.at > ==== > > - -- Dr A.R.H.F. Ettema Delft University of Technology Department of Physics Lorentzweg 1 2628 CJ Delft Tel : +31 15 2782481 Fax : +31 15 2781413 Email: ettema@tn.tudelft.nl Web: http://www.em.tudelft.nl/ad_ettema.htm ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 08:43:00 -0500 From: "Dadi Dai" Subject: [WIEN]: Why bandstructure is not consistent with DOS? ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_004E_01C2B884.481980E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was studying the bandstructure of Cu4O3. I used w2web to generate the = bandstructure and DOS. In DOS figure, no DOS at E(F) level. In = bandstructure figure, however, a few bands cross the E(F) level. I have = inserted the E(F) value in case.insp file. Could anyone help me figure out where the problem might be? Thank you very much! Dadi Dai P.S.=20 Long time ago, when I was using old version of wien2k, I didn't have = such a problem as long as I entered the correct E(F) in the case.insp = file. Now, I checked the data carefully and has given the correct E(F) = in the case.insp file, but I still have the problem. - ------=_NextPart_000_004E_01C2B884.481980E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was studying the bandstructure of = Cu4O3.  I=20 used w2web to generate the bandstructure and DOS.  In DOS figure, = no DOS at=20 E(F) level.  In bandstructure figure, however, a few bands cross = the E(F)=20 level.  I have inserted the E(F) value in case.insp = file.
 
Could anyone help me figure out where = the problem=20 might be?
 
Thank you very much!
 
Dadi Dai
 
P.S.
 
Long time ago, when I was using old = version of=20 wien2k, I didn't have such a problem as long as I entered the correct = E(F) in=20 the case.insp file.  Now, I checked the data carefully and has = given the=20 correct E(F) in the case.insp file, but I still have the = problem.
 
 - ------=_NextPart_000_004E_01C2B884.481980E0-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 14:55:05 +0100 From: Georg Madsen Subject: Re: [WIEN]: Why bandstructure is not consistent with DOS? ==== Georg Madsen submitted the following contribution: ==== It could be you are using a bad k-mesh for the DOS. Try a non-shifted k-mesh with more points. Also, ghostwiev displays the figures from spaghetti slightly wrong. I have no idea why, but try printing it. Georg Quoting Dadi Dai : > I was studying the bandstructure of Cu4O3. I used w2web to generate the > bandstructure and DOS. In DOS figure, no DOS at E(F) level. In > bandstructure figure, however, a few bands cross the E(F) level. I have > inserted the E(F) value in case.insp file. > > Could anyone help me figure out where the problem might be? > > Thank you very much! > > Dadi Dai > > P.S. > > Long time ago, when I was using old version of wien2k, I didn't have such a > problem as long as I entered the correct E(F) in the case.insp file. Now, I > checked the data carefully and has given the correct E(F) in the case.insp > file, but I still have the problem. > > - ---------------------------- Georg Madsen Dept. of Inorganic Chemistry University of Aarhus DK-8000 Århus C Denmark Tlf: +45 8942 3880 Fax: +45 8619 6199 - ---------------------------- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 09:37:45 -0500 From: "Dadi Dai" Subject: Re: [WIEN]: Why bandstructure is not consistent with DOS? ==== "Dadi Dai" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_0067_01C2B88B.EE58D800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Georg Madsen, Thank you very much for your reply. Actually DOS figure may be more = reasonable, because no DOS appears at E(f) and experimentally the system = is insulating. =20 I tried to print out the bandstructure, and the print-out is same as = what I saw on the screen.=20 So, could you or anyone else give me further helps? Thank you very much! Dadi Dai P.S. I have attached the two figures with my questions in my email sent = to wien2k mailing list yesterday, but I don't know why I haven't seen my = post so far. So I resent my questions today, without attaching the = figures. - ----- Original Message -----=20 From: "Georg Madsen" To: Sent: Friday, January 10, 2003 8:55 AM Subject: Re: [WIEN]: Why bandstructure is not consistent with DOS? > =3D=3D=3D=3D > Georg Madsen > submitted the following contribution: > =3D=3D=3D=3D >=20 > It could be you are using a bad k-mesh for the DOS. Try a non-shifted = k-mesh > with more points. >=20 > Also, ghostwiev displays the figures from spaghetti slightly wrong. I = have no > idea why, but try printing it. >=20 > Georg >=20 > Quoting Dadi Dai : >=20 > > I was studying the bandstructure of Cu4O3. I used w2web to generate = the > > bandstructure and DOS. In DOS figure, no DOS at E(F) level. In > > bandstructure figure, however, a few bands cross the E(F) level. I = have > > inserted the E(F) value in case.insp file. > >=20 > > Could anyone help me figure out where the problem might be? > >=20 > > Thank you very much! > >=20 > > Dadi Dai > >=20 > > P.S.=20 > >=20 > > Long time ago, when I was using old version of wien2k, I didn't have = such a > > problem as long as I entered the correct E(F) in the case.insp file. = Now, I > > checked the data carefully and has given the correct E(F) in the = case.insp > > file, but I still have the problem. > >=20 > >=20 >=20 >=20 > ---------------------------- > Georg Madsen > Dept. of Inorganic Chemistry > University of Aarhus > DK-8000 =C5rhus C > Denmark > Tlf: +45 8942 3880 > Fax: +45 8619 6199 > ---------------------------- - ------=_NextPart_000_0067_01C2B88B.EE58D800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear = Georg=20 Madsen,
 
Thank you very much for your = reply.  Actually=20 DOS figure may be more reasonable, because no DOS appears at E(f) and=20 experimentally the system is insulating. 
 
I tried to print out the bandstructure, = and the=20 print-out is same as what I saw on the screen. 
 
So, could you or anyone else give = me further=20 helps?
 
Thank you very much!
 
Dadi Dai
 
P.S.  I have=20 attached the two figures with my questions in my email sent to = wien2k=20 mailing list yesterday, but I don't know why I haven't seen my post so=20 far.  So I resent my questions today, without attaching the=20 figures.
 
----- Original Message -----
From: "Georg Madsen" <georg@chem.au.dk>
To: <wien@zeus.theochem.tuwien.ac.at>
Sent: Friday, January 10, 2003 8:55 = AM
Subject: Re: [WIEN]: Why bandstructure = is not=20 consistent with DOS?

> =3D=3D=3D=3D
> Georg Madsen <georg@chem.au.dk>
> submitted=20 the following contribution:
> =3D=3D=3D=3D
>
> It = could be you are=20 using a bad k-mesh for the DOS. Try a non-shifted k-mesh
> with = more=20 points.
>
> Also, ghostwiev displays the figures from = spaghetti=20 slightly wrong. I have no
> idea why, but try printing it.
> =
>  Georg
>
> Quoting Dadi Dai <dai@unity.ncsu.edu>:
>=20
> > I was studying the bandstructure of Cu4O3.  I used = w2web to=20 generate the
> > bandstructure and DOS.  In DOS figure, no = DOS at=20 E(F) level.  In
> > bandstructure figure, however, a few = bands=20 cross the E(F) level.  I have
> > inserted the E(F) value = in=20 case.insp file.
> >
> > Could anyone help me figure = out where=20 the problem might be?
> >
> > Thank you very = much!
>=20 >
> > Dadi Dai
> >
> > P.S.
> = >=20
> > Long time ago, when I was using old version of wien2k, I = didn't=20 have such a
> > problem as long as I entered the correct E(F) = in the=20 case.insp file.  Now, I
> > checked the data carefully and = has=20 given the correct E(F) in the case.insp
> > file, but I still = have the=20 problem.
> >
> >
>
>
>=20 - ----------------------------
> Georg Madsen
> Dept. of = Inorganic=20 Chemistry
> University of Aarhus
> DK-8000 =C5rhus C
> = Denmark
> Tlf: +45 8942 3880
> Fax: +45 8619 6199
>=20 - ----------------------------
 - ------=_NextPart_000_0067_01C2B88B.EE58D800-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 07:00:52 -0800 (PST) From: yanming Ma Subject: Re: [WIEN]: Question about the parallelization ==== yanming Ma submitted the following contribution: ==== - --0-186897195-1042210852=:37002 Content-Type: text/plain; charset=us-ascii Dear Dr. B.R. Sahu, Thanks very much for your reply. I got the point. Thanks again. Yanming Ma "Dr. B.R.Sahu" wrote:==== "Dr. B.R.Sahu" submitted the following contribution: ==== Dear Ma During compilation, if you dont choose the option for fine grained parallalization, it will create only files for single processor(ie lapw0, lapw1(c), lapw2 etc) and script for k-pt parallelization run lapw0para, lapw1para etc. If you choose the optiion for fine grained paralleliztion then in addition to the above files, the files for MPI parallel run like lapw0_mpi, lapw1_mpi and lapw2_mpi will be created. Now, whether the scripts run(sp)_lapw and other script pick up lapw*para or lapw*_mpi during the run depends on the structure of the .machines file as you mentioned. 1) the format of your k-point parallelization file is correct provided you have 4 k-points to distribute over four cpus(in your case tp0) and the cpu's have all same speed.For efficiency, only if we have more k-points then the processors or cpus then only we use k-point parallelization. but imagine a case where you have a very large system say a supercell containing large number of atoms say more than 40 and you expect it to be metallic, for example. In such cases, you need large number k-points to sample the BZ so k-point parallelization is again useful. 2) fine grained parallelization file is to be slightly modified: lapw0:tp0:1 tp0:1 tp0:1 tp0:1 1:tp0:1 tp0:1 tp0:1 tp0:1 it means lapw0_mpi will use 4 processors each having same speed and your sysetm has 1 k-point and lapw1_mpi runs on 4 processors in parallel. Fine grained parallel will be computationally efficient if you have large system(ie large number of atoms) and small number of k-points(1 or 2). that's what UG says. I myself have not tested so far the MPI parallel code, as it is giving some problem. I am already in contact with Prof. Blaha regarding this. Regards sahu ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== - --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-186897195-1042210852=:37002 Content-Type: text/html; charset=us-ascii

Dear Dr. B.R. Sahu,

Thanks very much for your reply. I got the point. Thanks again.

Yanming Ma

 "Dr. B.R.Sahu" <sahu@matter3.ph.utexas.edu> wrote:

====
"Dr. B.R.Sahu"
submitted the following contribution:
====


Dear Ma

During compilation, if you dont choose the option for fine grained
parallalization, it will create only files for single processor(ie lapw0,
lapw1(c), lapw2 etc) and script for k-pt parallelization run lapw0para,
lapw1para etc. If you choose the optiion for fine grained paralleliztion
then in addition to the above files, the files for MPI parallel run like
lapw0_mpi, lapw1_mpi and lapw2_mpi will be created.

Now, whether the scripts run(sp)_lapw and other script pick up lapw*para
or lapw*_mpi during the run depends on the structure of the .machines
file as you mentioned.

1) the format of your k-point parallelization file is correct provided you
have 4 k-points to distribute over four cpus(in your case tp0) and the
cpu's hav! e all same speed.For efficiency, only if we have more k-points
then the processors or cpus then only we use k-point parallelization. but
imagine a case where you have a very large system say a supercell
containing large number of atoms say more than 40 and you expect it to be
metallic, for example.
In such cases, you need large number k-points to sample
the BZ so k-point parallelization is again useful.

2) fine grained parallelization file is to be slightly modified:

lapw0:tp0:1 tp0:1 tp0:1 tp0:1
1:tp0:1 tp0:1 tp0:1 tp0:1

it means lapw0_mpi will use 4 processors each having same speed and your
sysetm has 1 k-point and lapw1_mpi runs on 4 processors in parallel.

Fine grained parallel will be computationally efficient if you have large
system(ie large number of atoms) and small number of k-points(1 or 2).
that's what UG says.

I myself have not tested so far the MPI parallel code, as it is giving
some problem.! I am already in contact with Prof. Blaha regarding this.



Regards
sahu



====
WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at
To (un)subscribe send mail to
majordomo@zeus.theochem.tuwien.ac.at
====


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now - --0-186897195-1042210852=:37002-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 12:05:01 -0500 From: "michel certier" Subject: [WIEN]: spin-orbit ==== "michel certier" submitted the following contribution: ==== Dear wien users. I am looking for some sampel of spi-orbit calculation. And I am wondering if it's possible (true !!) to do optimization with normal scf and run the final (optimized structure) calulation with spin-orbit option. Thank's - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Fri, 10 Jan 2003 12:04:46 -0500 From: "michel certier" Subject: [WIEN]: spin-orbit ==== "michel certier" submitted the following contribution: ==== Dear wien users. I am looking for some sampel of spi-orbit calculation. And I am wondering if it's possible (true !!) to do optimization with normal scf and run the final (optimized structure) calulation with spin-orbit option. Thank's - -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ Date: Sun, 12 Jan 2003 11:44:04 +0800 From: "liu wan" Subject: [WIEN]: Question about lapw1 ==== "liu wan" submitted the following contribution: ==== This is a multi-part message in MIME format. - ------=_NextPart_000_4015_3003_2e6f Content-Type: text/plain; format=flowed Dear All I try to calculate the electronic structure of ZrMoO. The lapw1 is OK, print "STOP LAPW1 END statement executed", and the lapw1.error is empty. But the ZrMoO.vector file is also empty! Why the lapw1 had been execute, but the vector file had not been written? Best wish Liu _________________________________________________________________ Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - ------=_NextPart_000_4015_3003_2e6f Content-Type: text/plain; name="ZrMoO.inst"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ZrMoO.inst" Zr Kr 2 5 4, 2,2.0 N 4, 2,0.0 N 5,-1,1.0 N 5,-1,1.0 N Zr Kr 2 5 4, 2,2.0 N 4, 2,0.0 N 5,-1,1.0 N 5,-1,1.0 N Mo Kr 3 5 4, 2,2.0 N 4, 2,1.0 N 4,-3,2.0 N 4,-3,0.0 N 5,-1,1.0 N 5,-1,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N O He 3 5 2,-1,1.0 N 2,-1,1.0 N 2, 1,1.0 N 2, 1,1.0 N 2,-2,2.0 N 2,-2,0.0 N **** End of Input **** End of Input - ------=_NextPart_000_4015_3003_2e6f Content-Type: text/plain; name="ZrMoO.struct"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ZrMoO.struct" ZrMo2O8-alpha H LATTICE,NONEQUIV. ATOMS: 7 163 P-31c MODE OF CALC=RELA 18.857703 18.857703 21.701365 90.000000 90.000000120.000000 ATOM= -1: X=0.00000000 Y=0.00000000 Z=0.00000000 MULT= 2 ISPLIT= 4 -1: X=0.00000000 Y=0.00000000 Z=0.50000000 Zr NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 40.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -2: X=0.33333300 Y=0.66666700 Z=0.97520000 MULT= 4 ISPLIT= 4 -2: X=0.66666700 Y=0.33333300 Z=0.02480000 -2: X=0.66666700 Y=0.33333300 Z=0.47520000 -2: X=0.33333300 Y=0.66666700 Z=0.52480000 Zr NPT= 781 R0=0.00001000 RMT= 2.0000 Z: 40.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -3: X=0.32980000 Y=0.33750000 Z=0.14778000 MULT=12 ISPLIT= 8 -3: X=0.67020000 Y=0.66250000 Z=0.85222000 -3: X=0.66250000 Y=0.99230000 Z=0.14778000 -3: X=0.33750000 Y=0.00770000 Z=0.85222000 -3: X=0.33750000 Y=0.32980000 Z=0.64778000 -3: X=0.66250000 Y=0.67020000 Z=0.35222000 -3: X=0.00770000 Y=0.67020000 Z=0.14778000 -3: X=0.99230000 Y=0.32980000 Z=0.85222000 -3: X=0.67020000 Y=0.00770000 Z=0.64778000 -3: X=0.32980000 Y=0.99230000 Z=0.35222000 -3: X=0.99230000 Y=0.66250000 Z=0.64778000 -3: X=0.00770000 Y=0.33750000 Z=0.35222000 Mo NPT= 781 R0=0.00001000 RMT= 1.6000 Z: 42.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -4: X=0.16000000 Y=0.15000000 Z=0.09700000 MULT=12 ISPLIT= 8 -4: X=0.84000000 Y=0.85000000 Z=0.90300000 -4: X=0.85000000 Y=0.01000000 Z=0.09700000 -4: X=0.15000000 Y=0.99000000 Z=0.90300000 -4: X=0.15000000 Y=0.16000000 Z=0.59700000 -4: X=0.85000000 Y=0.84000000 Z=0.40300000 -4: X=0.99000000 Y=0.84000000 Z=0.09700000 -4: X=0.01000000 Y=0.16000000 Z=0.90300000 -4: X=0.84000000 Y=0.99000000 Z=0.59700000 -4: X=0.16000000 Y=0.01000000 Z=0.40300000 -4: X=0.01000000 Y=0.85000000 Z=0.59700000 -4: X=0.99000000 Y=0.15000000 Z=0.40300000 O NPT= 781 R0=0.00010000 RMT= 1.3500 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -5: X=0.33400000 Y=0.50600000 Z=0.09230000 MULT=12 ISPLIT= 8 -5: X=0.66600000 Y=0.49400000 Z=0.90770000 -5: X=0.49400000 Y=0.82800000 Z=0.09230000 -5: X=0.50600000 Y=0.17200000 Z=0.90770000 -5: X=0.50600000 Y=0.33400000 Z=0.59230000 -5: X=0.49400000 Y=0.66600000 Z=0.40770000 -5: X=0.17200000 Y=0.66600000 Z=0.09230000 -5: X=0.82800000 Y=0.33400000 Z=0.90770000 -5: X=0.66600000 Y=0.17200000 Z=0.59230000 -5: X=0.33400000 Y=0.82800000 Z=0.40770000 -5: X=0.82800000 Y=0.49400000 Z=0.59230000 -5: X=0.17200000 Y=0.50600000 Z=0.40770000 O NPT= 781 R0=0.00010000 RMT= 1.3500 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -6: X=0.52300000 Y=0.35200000 Z=0.12990000 MULT=12 ISPLIT= 8 -6: X=0.47700000 Y=0.64800000 Z=0.87010000 -6: X=0.64800000 Y=0.17100000 Z=0.12990000 -6: X=0.35200000 Y=0.82900000 Z=0.87010000 -6: X=0.35200000 Y=0.52300000 Z=0.62990000 -6: X=0.64800000 Y=0.47700000 Z=0.37010000 -6: X=0.82900000 Y=0.47700000 Z=0.12990000 -6: X=0.17100000 Y=0.52300000 Z=0.87010000 -6: X=0.47700000 Y=0.82900000 Z=0.62990000 -6: X=0.52300000 Y=0.17100000 Z=0.37010000 -6: X=0.17100000 Y=0.64800000 Z=0.62990000 -6: X=0.82900000 Y=0.35200000 Z=0.37010000 O NPT= 781 R0=0.00010000 RMT= 1.3500 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 ATOM= -7: X=0.31700000 Y=0.34500000 Z=0.29090000 MULT=12 ISPLIT= 8 -7: X=0.68300000 Y=0.65500000 Z=0.70910000 -7: X=0.65500000 Y=0.97200000 Z=0.29090000 -7: X=0.34500000 Y=0.02800000 Z=0.70910000 -7: X=0.34500000 Y=0.31700000 Z=0.79090000 -7: X=0.65500000 Y=0.68300000 Z=0.20910000 -7: X=0.02800000 Y=0.68300000 Z=0.29090000 -7: X=0.97200000 Y=0.31700000 Z=0.70910000 -7: X=0.68300000 Y=0.02800000 Z=0.79090000 -7: X=0.31700000 Y=0.97200000 Z=0.20910000 -7: X=0.97200000 Y=0.65500000 Z=0.79090000 -7: X=0.02800000 Y=0.34500000 Z=0.20910000 O NPT= 781 R0=0.00010000 RMT= 1.3500 Z: 8.0 LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 12 NUMBER OF SYMMETRY OPERATIONS - -1 1 0 0.0000000 - -1 0 0 0.0000000 0 0 1 0.0000000 1 - -1 0 0 0.0000000 0-1 0 0.0000000 0 0-1 0.0000000 2 0 1 0 0.0000000 - -1 1 0 0.0000000 0 0-1 0.0000000 3 0-1 0 0.0000000 1-1 0 0.0000000 0 0 1 0.0000000 4 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000 5 1-1 0 0.0000000 1 0 0 0.0000000 0 0-1 0.0000000 6 1 0 0 0.0000000 1-1 0 0.0000000 0 0-1 0.5000000 7 - -1 1 0 0.0000000 0 1 0 0.0000000 0 0-1 0.5000000 8 0 1 0 0.0000000 1 0 0 0.0000000 0 0 1 0.5000000 9 1-1 0 0.0000000 0-1 0 0.0000000 0 0 1 0.5000000 10 0-1 0 0.0000000 - -1 0 0 0.0000000 0 0-1 0.5000000 11 - -1 0 0 0.0000000 - -1 1 0 0.0000000 0 0 1 0.5000000 12 - ------=_NextPart_000_4015_3003_2e6f-- ==== WIEN Mailing list: wien@zeus.theochem.tuwien.ac.at To (un)subscribe send mail to majordomo@zeus.theochem.tuwien.ac.at ==== ------------------------------ End of wien-digest V2002 #51 ****************************