Re: [Wien] structeditor for creating a surface
It is up to you, how thick (how many layers) you want to make your slab. The thicker the better, but soon you will run out of computer power. PS: For a (001) surface the programx supercell is probably easier to use. There you would be asked for the number of cells along x,y,z and with 1x1x2 (3,4,5..) you can create slabs with different thickness. PS: On 06/27/2013 03:48 AM, Madhav Ghimire wrote: Dear Robert and wien2k users, I am creating a surface using structeditor program which required octave enironment, I came across sr=makesurface(s,n,ind,depth,vac) which creates surface for a given unitcell where: s input structure n normal vector (in lattice coordinates) ind an index of an atom which should be in (0 0 0) *depth thickness of the material* vac thickness of the vacuum layer example: sr=makesurface(s,[0 0 1],1,30.0,20.0) Now my doubt is: How shall I realize the thickness of the particular material (for example Fe) I mean can I choose it manually (any number) or I need to know the proper thickness of the material. If so, can anyone help where I can find the thickness information of the material. Thanks in advance Madhav ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] structeditor for creating a surface
Dear Prof. Blaha, Thanks. Using x supercell, I could generate a 001 surface of Fe . But my current case is for 111 surface with 5 layers which is difficult to create using x supercell. In my current structure, I need to create a vacuum of 20 Ang. on the fifth layer. So I was not sure whether the thickness of the material [30.0] selection in sr=makesurface (s,1,30.0,20.0) is OK for Fe. It will be great if you could confirm sr=makesurface (s,1,30.0,20.0) on structeditor is OK. Best regards Madhav On Thu, Jun 27, 2013 at 3:27 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: It is up to you, how thick (how many layers) you want to make your slab. The thicker the better, but soon you will run out of computer power. PS: For a (001) surface the programx supercell is probably easier to use. There you would be asked for the number of cells along x,y,z and with 1x1x2 (3,4,5..) you can create slabs with different thickness. PS: On 06/27/2013 03:48 AM, Madhav Ghimire wrote: Dear Robert and wien2k users, I am creating a surface using structeditor program which required octave enironment, I came across sr=makesurface(s,n,ind,depth,**vac) which creates surface for a given unitcell where: s input structure n normal vector (in lattice coordinates) ind an index of an atom which should be in (0 0 0) *depth thickness of the material* vac thickness of the vacuum layer example: sr=makesurface(s,[0 0 1],1,30.0,20.0) Now my doubt is: How shall I realize the thickness of the particular material (for example Fe) I mean can I choose it manually (any number) or I need to know the proper thickness of the material. If so, can anyone help where I can find the thickness information of the material. Thanks in advance Madhav __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha --**--** -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/** theochem/ http://info.tuwien.ac.at/theochem/ --**--** -- __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Bader Analysis for charge transfer
Dear Wien2k users, I am trying to analyse charge transfer in DyAl2. I ran the AIM program, the case.inaim and case.outputaim are as follows: *case1:* *case.inaim* SURF 1 20 0.0 1.5707963267949 20 0.7853980 2.35619 0.07 0.8 4 1.65 0.1 3 3 3 IRHO WEIT 30 END *Case.outputaim* RHOINTE (Quadrature)0.3870539: VOLUME 123.720711 RHTOT for IND-ATOM 1Z=66.0 CHARGE: 65.01531973 0.98468027 it shows charge transfer of 0.98468027 e- *in case 2:* in case.inaim, in 2nd line I replaced 1 by 3 (for Al) *case.outputaim* RHOINTE (Quadrature)1.05493994: VOLUME 109.659051 RHTOT for IND-ATOM 3Z=13.0 CHARGE: 13.08344247 -0.08344247 The results shows that the charge transfer is from Dy to Al. The the total charge transfer is not zero. Is these results are correct or not? Kindly help me to understand these results. Structure file is also enclosed herewith. With regards, -- Alpa Dashora DyAl2.struct Description: Binary data ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] structeditor for creating a surface
Hello Madhav, The thickness of the slab will vary depending on the interplanar distance for that surface. Usually you can do this more accurately by using an expression based on the bulk lattice constants. For instance: bulk = loadstruct(...) surface = makesurface(bulk,1,bulk.a(3)/2,20.0) where bulk.a(3) will be half the lattice constant in the z direction. You may have to add 0.001 or something so that it does not cut off the uppermost atoms (most likely there's a smaller or greater than somewhere that could benefit from an equals sign). So surface = makesurface(bulk,1,bulk.a(3)/2+0.001,20.0) Also make sure your number of atoms is always correct since for more exotic surfaces sometimes the structeditor eats a few atoms somewhere at the bottom of the slab where the 001 direction used to be... Which is then usually easily fixed by making a bit thicker slab and removing layers again. Regards, Michael Sluydts Op 27/06/2013 8:44, Madhav Ghimire schreef: Dear Prof. Blaha, Thanks. Using x supercell, I could generate a 001 surface of Fe . But my current case is for 111 surface with 5 layers which is difficult to create using x supercell. In my current structure, I need to create a vacuum of 20 Ang. on the fifth layer. So I was not sure whether the thickness of the material [30.0] selection in sr=makesurface (s,1,30.0,20.0) is OK for Fe. It will be great if you could confirm sr=makesurface (s,1,30.0,20.0) on structeditor is OK. Best regards Madhav On Thu, Jun 27, 2013 at 3:27 PM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: It is up to you, how thick (how many layers) you want to make your slab. The thicker the better, but soon you will run out of computer power. PS: For a (001) surface the programx supercell is probably easier to use. There you would be asked for the number of cells along x,y,z and with 1x1x2 (3,4,5..) you can create slabs with different thickness. PS: On 06/27/2013 03:48 AM, Madhav Ghimire wrote: Dear Robert and wien2k users, I am creating a surface using structeditor program which required octave enironment, I came across sr=makesurface(s,n,ind,depth,vac) which creates surface for a given unitcell where: s input structure n normal vector (in lattice coordinates) ind an index of an atom which should be in (0 0 0) *depth thickness of the material* vac thickness of the vacuum layer example: sr=makesurface(s,[0 0 1],1,30.0,20.0) Now my doubt is: How shall I realize the thickness of the particular material (for example Fe) I mean can I choose it manually (any number) or I need to know the proper thickness of the material. If so, can anyone help where I can find the thickness information of the material. Thanks in advance Madhav ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 tel:%2B43-1-58801-165300 FAX: +43-1-58801-165982 tel:%2B43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] structeditor for creating a surface
Exactly like this. And then: look at your structure (xcrysden or VESTA or ..), count the number of generated layers, check if all atoms are there, . On 06/27/2013 09:18 AM, Michael Sluydts wrote: Hello Madhav, The thickness of the slab will vary depending on the interplanar distance for that surface. Usually you can do this more accurately by using an expression based on the bulk lattice constants. For instance: bulk = loadstruct(...) surface = makesurface(bulk,1,bulk.a(3)/2,20.0) where bulk.a(3) will be half the lattice constant in the z direction. You may have to add 0.001 or something so that it does not cut off the uppermost atoms (most likely there's a smaller or greater than somewhere that could benefit from an equals sign). So surface = makesurface(bulk,1,bulk.a(3)/2+0.001,20.0) Also make sure your number of atoms is always correct since for more exotic surfaces sometimes the structeditor eats a few atoms somewhere at the bottom of the slab where the 001 direction used to be... Which is then usually easily fixed by making a bit thicker slab and removing layers again. Regards, Michael Sluydts Op 27/06/2013 8:44, Madhav Ghimire schreef: Dear Prof. Blaha, Thanks. Using x supercell, I could generate a 001 surface of Fe . But my current case is for 111 surface with 5 layers which is difficult to create using x supercell. In my current structure, I need to create a vacuum of 20 Ang. on the fifth layer. So I was not sure whether the thickness of the material [30.0] selection in sr=makesurface (s,1,30.0,20.0) is OK for Fe. It will be great if you could confirm sr=makesurface (s,1,30.0,20.0) on structeditor is OK. Best regards Madhav On Thu, Jun 27, 2013 at 3:27 PM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: It is up to you, how thick (how many layers) you want to make your slab. The thicker the better, but soon you will run out of computer power. PS: For a (001) surface the programx supercell is probably easier to use. There you would be asked for the number of cells along x,y,z and with 1x1x2 (3,4,5..) you can create slabs with different thickness. PS: On 06/27/2013 03:48 AM, Madhav Ghimire wrote: Dear Robert and wien2k users, I am creating a surface using structeditor program which required octave enironment, I came across sr=makesurface(s,n,ind,depth,vac) which creates surface for a given unitcell where: s input structure n normal vector (in lattice coordinates) ind an index of an atom which should be in (0 0 0) *depth thickness of the material* vac thickness of the vacuum layer example: sr=makesurface(s,[0 0 1],1,30.0,20.0) Now my doubt is: How shall I realize the thickness of the particular material (for example Fe) I mean can I choose it manually (any number) or I need to know the proper thickness of the material. If so, can anyone help where I can find the thickness information of the material. Thanks in advance Madhav ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 tel:%2B43-1-58801-165300 FAX: +43-1-58801-165982 tel:%2B43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at:http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Bader Analysis for charge transfer
Are you sure that the that and phi meshes are ok ?? 20 0.0 1.5707963267949 20 0.7853980 2.35619 In particular phi looks very special (can be ok for a certain site-symmetry), but is dangerous, if you do not understand the meaning. Without symmetry, theta should run from 0-pi and phi from 0-2pi If you have eg. a mirror-plane normal to z at the corresponding atomic site (check outputs) you can restrict theta to pi/2. Note, this can be different for different atoms in your cell. In addition, check the 20. It might be too low, but should not lead to such large errors. Make sure your density is well converged (RKmax). Otherwise discontinuities at RMT could produce wrong integration basins. And finally: in rare cases, non-nuclear maxima could occur, so that some charge is in a basin (atomic region) where no atom is located... On 06/27/2013 08:49 AM, alpa dashora wrote: Dear Wien2k users, I am trying to analyse charge transfer in DyAl2. I ran the AIM program, the case.inaim and case.outputaim are as follows: *case1:* _case.inaim_ SURF 1 20 0.0 1.5707963267949 20 0.7853980 2.35619 0.07 0.8 4 1.65 0.1 3 3 3 IRHO WEIT 30 END _Case.outputaim_ RHOINTE (Quadrature)0.3870539: VOLUME 123.720711 RHTOT for IND-ATOM 1Z=66.0 CHARGE: 65.01531973 0.98468027 it shows charge transfer of 0.98468027 e- *in case 2:* in case.inaim, in 2nd line I replaced 1 by 3 (for Al) _case.outputaim_ RHOINTE (Quadrature)1.05493994: VOLUME 109.659051 RHTOT for IND-ATOM 3Z=13.0 CHARGE: 13.08344247 -0.08344247 The results shows that the charge transfer is from Dy to Al. The the total charge transfer is not zero. Is these results are correct or not? Kindly help me to understand these results. Structure file is also enclosed herewith. With regards, -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] structeditor for creating a surface
Dear Michael Prof. Blaha, The information you provided are really helpful. My doubt are clear now. Thanks Madhav On Thu, Jun 27, 2013 at 4:30 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: Exactly like this. And then: look at your structure (xcrysden or VESTA or ..), count the number of generated layers, check if all atoms are there, . On 06/27/2013 09:18 AM, Michael Sluydts wrote: Hello Madhav, The thickness of the slab will vary depending on the interplanar distance for that surface. Usually you can do this more accurately by using an expression based on the bulk lattice constants. For instance: bulk = loadstruct(...) surface = makesurface(bulk,1,bulk.a(3)/**2,20.0) where bulk.a(3) will be half the lattice constant in the z direction. You may have to add 0.001 or something so that it does not cut off the uppermost atoms (most likely there's a smaller or greater than somewhere that could benefit from an equals sign). So surface = makesurface(bulk,1,bulk.a(3)/**2+0.001,20.0) Also make sure your number of atoms is always correct since for more exotic surfaces sometimes the structeditor eats a few atoms somewhere at the bottom of the slab where the 001 direction used to be... Which is then usually easily fixed by making a bit thicker slab and removing layers again. Regards, Michael Sluydts Op 27/06/2013 8:44, Madhav Ghimire schreef: Dear Prof. Blaha, Thanks. Using x supercell, I could generate a 001 surface of Fe . But my current case is for 111 surface with 5 layers which is difficult to create using x supercell. In my current structure, I need to create a vacuum of 20 Ang. on the fifth layer. So I was not sure whether the thickness of the material [30.0] selection in sr=makesurface (s,1,30.0,20.0) is OK for Fe. It will be great if you could confirm sr=makesurface (s,1,30.0,20.0) on structeditor is OK. Best regards Madhav On Thu, Jun 27, 2013 at 3:27 PM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pblaha@theochem.**tuwien.ac.atpbl...@theochem.tuwien.ac.at wrote: It is up to you, how thick (how many layers) you want to make your slab. The thicker the better, but soon you will run out of computer power. PS: For a (001) surface the programx supercell is probably easier to use. There you would be asked for the number of cells along x,y,z and with 1x1x2 (3,4,5..) you can create slabs with different thickness. PS: On 06/27/2013 03:48 AM, Madhav Ghimire wrote: Dear Robert and wien2k users, I am creating a surface using structeditor program which required octave enironment, I came across sr=makesurface(s,n,ind,depth,**vac) which creates surface for a given unitcell where: s input structure n normal vector (in lattice coordinates) ind an index of an atom which should be in (0 0 0) *depth thickness of the material* vac thickness of the vacuum layer example: sr=makesurface(s,[0 0 1],1,30.0,20.0) Now my doubt is: How shall I realize the thickness of the particular material (for example Fe) I mean can I choose it manually (any number) or I need to know the proper thickness of the material. If so, can anyone help where I can find the thickness information of the material. Thanks in advance Madhav __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**atWien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.**tuwien.ac.atWien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/**w...@zeus.theochem.tuwien.ac.** at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha --**--** -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 tel:%2B43-1-58801-165300 FAX: +43-1-58801-165982 tel:%2B43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:blaha@theochem.tuwien.**ac.at bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/**theochem/http://info.tuwien.ac.at/theochem/ --**--** -- __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at
Re: [Wien] Bader Analysis for charge transfer
Dear prof. Blaha, Thank you for your reply. Now it is essay for me to understand the input file. I have used the value of theta as 0-pi and phi as 0-2pi. I also used the different values of ntheta and nphi as 40 and 60 (in two separate run ). The calculated charge transfer is as follows: for Gd: Z=66.0 CHARGE: 65.06579522 0.93420478 for Al Z=13.0 CHARGE: 13.46671803 -0.46671803 The results shows that the 0.934 electrons from Gd are transferred to 2 Al atoms (0.467 on each atom). Now the charge is converge. Please suggest, these results are alright or not? for the different values of ntheta and nphi (40 and 60), no significant change in charge transfer is observed. thanks in advance. On Thu, Jun 27, 2013 at 1:10 PM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: Are you sure that the that and phi meshes are ok ?? 20 0.0 1.5707963267949 20 0.7853980 2.35619 In particular phi looks very special (can be ok for a certain site-symmetry), but is dangerous, if you do not understand the meaning. Without symmetry, theta should run from 0-pi and phi from 0-2pi If you have eg. a mirror-plane normal to z at the corresponding atomic site (check outputs) you can restrict theta to pi/2. Note, this can be different for different atoms in your cell. In addition, check the 20. It might be too low, but should not lead to such large errors. Make sure your density is well converged (RKmax). Otherwise discontinuities at RMT could produce wrong integration basins. And finally: in rare cases, non-nuclear maxima could occur, so that some charge is in a basin (atomic region) where no atom is located... On 06/27/2013 08:49 AM, alpa dashora wrote: Dear Wien2k users, I am trying to analyse charge transfer in DyAl2. I ran the AIM program, the case.inaim and case.outputaim are as follows: *case1:* _case.inaim_ SURF 1 20 0.0 1.5707963267949 20 0.7853980 2.35619 0.07 0.8 4 1.65 0.1 3 3 3 IRHO WEIT 30 END _Case.outputaim_ RHOINTE (Quadrature)0.3870539: VOLUME 123.720711 RHTOT for IND-ATOM 1Z=66.0 CHARGE: 65.01531973 0.98468027 it shows charge transfer of 0.98468027 e- *in case 2:* in case.inaim, in 2nd line I replaced 1 by 3 (for Al) _case.outputaim_ RHOINTE (Quadrature)1.05493994: VOLUME 109.659051 RHTOT for IND-ATOM 3Z=13.0 CHARGE: 13.08344247 -0.08344247 The results shows that the charge transfer is from Dy to Al. The the total charge transfer is not zero. Is these results are correct or not? Kindly help me to understand these results. Structure file is also enclosed herewith. With regards, -- Alpa Dashora __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha --**--** -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/** theochem/ http://info.tuwien.ac.at/theochem/ --**--** -- __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Bader Analysis for charge transfer
Probably ok. At least they look consistent. On 06/27/2013 11:21 AM, alpa dashora wrote: Dear prof. Blaha, Thank you for your reply. Now it is essay for me to understand the input file. I have used the value of theta as 0-pi and phi as 0-2pi. I also used the different values of ntheta and nphi as 40 and 60 (in two separate run ). The calculated charge transfer is as follows: for Gd: Z=66.0 CHARGE: 65.06579522 0.93420478 for Al Z=13.0 CHARGE: 13.46671803 -0.46671803 The results shows that the 0.934 electrons from Gd are transferred to 2 Al atoms (0.467 on each atom). Now the charge is converge. Please suggest, these results are alright or not? for the different values of ntheta and nphi (40 and 60), no significant change in charge transfer is observed. thanks in advance. On Thu, Jun 27, 2013 at 1:10 PM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: Are you sure that the that and phi meshes are ok ?? 20 0.0 1.5707963267949 20 0.7853980 2.35619 In particular phi looks very special (can be ok for a certain site-symmetry), but is dangerous, if you do not understand the meaning. Without symmetry, theta should run from 0-pi and phi from 0-2pi If you have eg. a mirror-plane normal to z at the corresponding atomic site (check outputs) you can restrict theta to pi/2. Note, this can be different for different atoms in your cell. In addition, check the 20. It might be too low, but should not lead to such large errors. Make sure your density is well converged (RKmax). Otherwise discontinuities at RMT could produce wrong integration basins. And finally: in rare cases, non-nuclear maxima could occur, so that some charge is in a basin (atomic region) where no atom is located... On 06/27/2013 08:49 AM, alpa dashora wrote: Dear Wien2k users, I am trying to analyse charge transfer in DyAl2. I ran the AIM program, the case.inaim and case.outputaim are as follows: *case1:* _case.inaim_ SURF 1 20 0.0 1.5707963267949 20 0.7853980 2.35619 0.07 0.8 4 1.65 0.1 3 3 3 IRHO WEIT 30 END _Case.outputaim_ RHOINTE (Quadrature)0.3870539: VOLUME 123.720711 RHTOT for IND-ATOM 1Z=66.0 CHARGE: 65.01531973 0.98468027 it shows charge transfer of 0.98468027 e- *in case 2:* in case.inaim, in 2nd line I replaced 1 by 3 (for Al) _case.outputaim_ RHOINTE (Quadrature)1.05493994: VOLUME 109.659051 RHTOT for IND-ATOM 3Z=13.0 CHARGE: 13.08344247 -0.08344247 The results shows that the charge transfer is from Dy to Al. The the total charge transfer is not zero. Is these results are correct or not? Kindly help me to understand these results. Structure file is also enclosed herewith. With regards, -- Alpa Dashora _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha --__--__-- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/__theochem/ http://info.tuwien.ac.at/theochem/ --__--__-- _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha
Re: [Wien] no energy limits found for l=0
If you are claiming you can run with RKmax 8, but not with 9, there are only 2 ways: used only RKmax=8 set the sphere sizes better. But without details nobody can help. PS: Who says that for the bandstructure of topological half-heuslers RKmax=9 is needed ??? Rkmax is a function of the type of atom (and of the property/accuracy you want to investigate), but not of a crystal structure. On 06/27/2013 11:46 AM, Saba Sabeti wrote: Dear Dr. Blaha, Thanks for your consideration and reply, Yes, I'm calculating the band structure of some topological half-heuslers that as far as I know for them RKmax=9 (at least) is needed. Do you think is there any other way for removing the error instead of reducing RKmax? regards --Saba *From:* Peter Blaha pbl...@theochem.tuwien.ac.at *To:* A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at *Sent:* Wednesday, 26 June 2013, 23:33 *Subject:* Re: [Wien] no energy limits found for l=0 Are you sure you need RKmax=9 ??? For cells with very different RMTs for different atoms this may lead to QTL-B errors. On 06/26/2013 08:05 PM, Saba Sabeti wrote: Dear all users, Greetings, I would be so thankful if you guide me in solving my problem. I have encountered to this error :***FORTRAN STOP L2main- QTL-B*, while running scf of a topological supercell considering SO coupling I could remove it by reducing mixing factor from 0.2 to 0.1, while running the scf again, this time I encountered another error in cycle 4 that shows this one: *no energy limits found for l=0* Although this error also is removable via reducing RKmax from 9 to 8, since I need it to be 9, let me now if there is any other way to remove this error? best regards --Saba ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at mailto:bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] kgen issue in 13.1
I notice that the new wien2k 13.1 spends a lot of time (=up to 1 minute) in kgen. This appears to be due to a large fort.10 file that is written by create_filehf.f in SRC_kgen (it is 40 Mb for a simple test case). This fort.10 file is not present when wien2k 12.1 is used. Is this the desired behaviour, or was perhaps a write statement not commented away? Thanks, Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] kgen issue in 13.1
This should happen only if you specifyx kgen -hf However, checking the source I found that createhf is not set to .false. as a default and since we changed an if statement from .eq. to .eqv., it might be that it leads to this behavior on some computers (not on mine with latest ifort). Anyway, a proper fix is to insert ! createhf = .false. as first executable statement inSRC_kgen/main.f (line 125) I will update and put it in the download area. On 06/27/2013 02:31 PM, Stefaan Cottenier wrote: I notice that the new wien2k 13.1 spends a lot of time (=up to 1 minute) in kgen. This appears to be due to a large fort.10 file that is written by create_filehf.f in SRC_kgen (it is 40 Mb for a simple test case). This fort.10 file is not present when wien2k 12.1 is used. Is this the desired behaviour, or was perhaps a write statement not commented away? Thanks, Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] survey results
One week ago, a two-question survey was posted on this mailing list. Here comes the result and a discussion/interpretation of the data. The goal of the survey was to collect quantitative information on the following hypothesis: In the transition from code development to code usage, inevitable some awareness and knowledge about fine (?) details gets lost. Developers tend to think that users know more than they actually do. While users tend to think that there are less hidden subtleties than there actually are. It might well be that grey intermediate area of supposed/lacking knowledge is far larger than either of both parties thinks it is. The discussion of one week ago about the relation between RKmax and Rmt offered an opportunity to collect some data to examine this hypothesis. The topic was one about which an experienced user could think: You can't use wien2k properly if you don't know this. While a 'general user' could think: I can survive without this. 34 people filled out the survey. Less than the 100 I hoped for, but nevertheless sufficient for meaningful conclusions. The results can be found for a while at https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf (attachment too large for this list). 1/3 of the respondents say they could have given the right answer on the RKmax question themselves. 2/3 say this was new for them. As one can expect that users who have no clue at all about the topic are less likely to take part in the survey, it seems fair to conclude that 75% or more of the wien2k community was not aware about this RKmax issue. A number that might surprise some people. Whereas the first question of the survey roughly probes 'understanding', the second question of the survey asked about 'experience' (measured as the amount of years someone has been using wien2k). Slightly less than one half of the respondents were relatively new users (3y), the other half were quite to very much experienced (3y, 7y). It is interesting to correlate the answers on both questions in a knowledge-vs-experience graph (3th page of https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf ) : It is reassuring to observe in this correlation that roughly spoken understanding seems to increase as a function of experience (or time). Nevertheless, even in the category of the most experienced users (7y), there are still almost twice as many who were not aware of the RKmax issue than those who were (26% vs. 15%). This is only a rough observation, that does not pretend to be a statistically significant scientific study. It does point to a trend, however. The bottom line: is there anything all of us, as a community, can do to improve the knowledge transfer towards 'general users'? Feel free to discuss this on this mailing list, and in particular, to post suggestions. Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] kgen issue in 13.1
Indeed, this works fine. Thanks, Stefaan On 27/06/2013 15:00, Peter Blaha wrote: This should happen only if you specifyx kgen -hf However, checking the source I found that createhf is not set to .false. as a default and since we changed an if statement from .eq. to .eqv., it might be that it leads to this behavior on some computers (not on mine with latest ifort). Anyway, a proper fix is to insert ! createhf = .false. as first executable statement inSRC_kgen/main.f (line 125) I will update and put it in the download area. On 06/27/2013 02:31 PM, Stefaan Cottenier wrote: I notice that the new wien2k 13.1 spends a lot of time (=up to 1 minute) in kgen. This appears to be due to a large fort.10 file that is written by create_filehf.f in SRC_kgen (it is 40 Mb for a simple test case). This fort.10 file is not present when wien2k 12.1 is used. Is this the desired behaviour, or was perhaps a write statement not commented away? Thanks, Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Very minor glitches in Wien2k_13
They don't matter with ifort, but could with some other compilers (maybe): SRC_lapw1/lopw.f(128) # in first line should be ! SRC_nmr c3fft.frc Line 207 is #endif without any #if and the file is of the wrong type (not .F or .frc90) make_charge.frc Line 159 has too many ) at the end make_fopvec_green.frc Line 33 the same SRC_structureeditor/SRC_readwrite rwoctave.f Line 156, 161 the same -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Emax in case.in1
The determination of Emax in case.in1 seems to have been changed from a fixed value at 2.5 Ry to a dynamic value determined as E_fermi plus a default 1.5 Ry: K-VECTORS FROM UNIT:4 -10.0 1.518 emin / de (emax=Ef+de) / nband This 1.5 Ry might be too small, as it makes reappear inconveniences that had disappeared when the old fixed default of 1.5 Ry was increased to 2.5 Ry. For instance, the DOS of non-magnetic bcc-Fe is calculated only up to E_Fermi (=0.62 Ry). Increasing the default 'de' to 2.0 (?) would prevent this. Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Emax in case.in1
Hmm. I can verify the problem. The question is: it nonmagnetic bcc Fe an exception ? Does this happen for any more-atomic unit cells, which one would use in usual research work ?? At least in my tests the new setting is a good compromise and in particular with the dynamic range it is much more flexible then the old fixed value. I'm reluctant to follow this suggestion because of large scale computations, where the vector-files can grow to extremely large sizes and a larger Emax makes these files even larger. Am 27.06.2013 18:25, schrieb Stefaan Cottenier: The determination of Emax in case.in1 seems to have been changed from a fixed value at 2.5 Ry to a dynamic value determined as E_fermi plus a default 1.5 Ry: K-VECTORS FROM UNIT:4 -10.0 1.518 emin / de (emax=Ef+de) / nband This 1.5 Ry might be too small, as it makes reappear inconveniences that had disappeared when the old fixed default of 1.5 Ry was increased to 2.5 Ry. For instance, the DOS of non-magnetic bcc-Fe is calculated only up to E_Fermi (=0.62 Ry). Increasing the default 'de' to 2.0 (?) would prevent this. Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] survey results
I've updatedhttp://www.wien2k.at/reg_user/faq/rkmax.html Maybe it helps if I put a link in w2web in the initialization section next to the RKmax input/editing ? (But which experienced user is using w2web for intialization ?) Am 27.06.2013 16:49, schrieb Stefaan Cottenier: One week ago, a two-question survey was posted on this mailing list. Here comes the result and a discussion/interpretation of the data. The goal of the survey was to collect quantitative information on the following hypothesis: In the transition from code development to code usage, inevitable some awareness and knowledge about fine (?) details gets lost. Developers tend to think that users know more than they actually do. While users tend to think that there are less hidden subtleties than there actually are. It might well be that grey intermediate area of supposed/lacking knowledge is far larger than either of both parties thinks it is. The discussion of one week ago about the relation between RKmax and Rmt offered an opportunity to collect some data to examine this hypothesis. The topic was one about which an experienced user could think: You can't use wien2k properly if you don't know this. While a 'general user' could think: I can survive without this. 34 people filled out the survey. Less than the 100 I hoped for, but nevertheless sufficient for meaningful conclusions. The results can be found for a while at https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf (attachment too large for this list). 1/3 of the respondents say they could have given the right answer on the RKmax question themselves. 2/3 say this was new for them. As one can expect that users who have no clue at all about the topic are less likely to take part in the survey, it seems fair to conclude that 75% or more of the wien2k community was not aware about this RKmax issue. A number that might surprise some people. Whereas the first question of the survey roughly probes 'understanding', the second question of the survey asked about 'experience' (measured as the amount of years someone has been using wien2k). Slightly less than one half of the respondents were relatively new users (3y), the other half were quite to very much experienced (3y, 7y). It is interesting to correlate the answers on both questions in a knowledge-vs-experience graph (3th page of https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf ) : It is reassuring to observe in this correlation that roughly spoken understanding seems to increase as a function of experience (or time). Nevertheless, even in the category of the most experienced users (7y), there are still almost twice as many who were not aware of the RKmax issue than those who were (26% vs. 15%). This is only a rough observation, that does not pretend to be a statistically significant scientific study. It does point to a trend, however. The bottom line: is there anything all of us, as a community, can do to improve the knowledge transfer towards 'general users'? Feel free to discuss this on this mailing list, and in particular, to post suggestions. Stefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Very minor glitches in Wien2k_13
Done. Updates on the web. Am 27.06.2013 17:28, schrieb Laurence Marks: They don't matter with ifort, but could with some other compilers (maybe): SRC_lapw1/lopw.f(128) # in first line should be ! SRC_nmr c3fft.frc Line 207 is #endif without any #if and the file is of the wrong type (not .F or .frc90) make_charge.frc Line 159 has too many ) at the end make_fopvec_green.frc Line 33 the same SRC_structureeditor/SRC_readwrite rwoctave.f Line 156, 161 the same -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] scratch folder in k-point parallel calculation
I'm working on a cluster with many nodes. Each node has its own /scratch folder which cannot be accessed by other nodes. My own data folder is accessible to all nodes. When the WIEN2k scratch folder is set to './', everything works fine except that all the data write/read are done in my own data folder which slows down the system. When the WIEN2k scratch folder is set to '/scratch', then the scratch files such as case.vector_ created on one node would not be visible to the other. This would not be a problem for lapw1 -p and lapw2 -p if each node sticks to certain k points and searches for scratch files related to these k-points. Is there a way of configuring WIEN2k to work in this manner? Yundi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] scratch folder in k-point parallel calculation
I'm working on a cluster with many nodes. Each node has its own /scratch folder which cannot be accessed by other nodes. My own data folder is accessible to all nodes. When the WIEN2k scratch folder is set to './', everything works fine except that all the data write/read are done in my own data folder which slows down the system. When the WIEN2k scratch folder is set to '/scratch', then the scratch files such as case.vector_ created on one node would not be visible to the other. This would not be a problem for lapw1 -p and lapw2 -p if each node sticks to certain k points and searches for scratch files related to these k-points. Is there a way of configuring WIEN2k to work in this manner? The k-point parallelization scheme works exactly in this way (mpi parallelization is different). STefaan ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] scratch folder in k-point parallel calculation
I forgot to add that after lapw2, all the output files should be written to a shared folder (not to scratch folder of each node) so that sumpara -p could access all the output files. In the version that I'm using (11.0), it seems that lapw1 is not executed locally. Yundi On Thu, Jun 27, 2013 at 1:37 PM, Yundi Quan yq...@ucdavis.edu wrote: -- Forwarded message -- From: Stefaan Cottenier stefaan.cotten...@ugent.be Date: Thu, Jun 27, 2013 at 1:33 PM Subject: Re: [Wien] scratch folder in k-point parallel calculation To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at I'm working on a cluster with many nodes. Each node has its own /scratch folder which cannot be accessed by other nodes. My own data folder is accessible to all nodes. When the WIEN2k scratch folder is set to './', everything works fine except that all the data write/read are done in my own data folder which slows down the system. When the WIEN2k scratch folder is set to '/scratch', then the scratch files such as case.vector_ created on one node would not be visible to the other. This would not be a problem for lapw1 -p and lapw2 -p if each node sticks to certain k points and searches for scratch files related to these k-points. Is there a way of configuring WIEN2k to work in this manner? The k-point parallelization scheme works exactly in this way (mpi parallelization is different). STefaan __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] scratch folder in k-point parallel calculation
If you are talking about a mixed (MPI k-parallel) job, there are suggestions in FAQs: http://www.wien2k.at/reg_user/faq/pbs.html I use SGE scheduler and the following parallel_options file: setenv USE_REMOTE 0 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN mpiexec -machinefile _HOSTS_ -n _NP_ _EXEC_ Eventually, it works with the local SCRATCH directory. I can share a submission script for the mixed MPI+k parallel job, if needed. Oleg On 13-06-27 4:46 PM, Yundi Quan wrote: I forgot to add that after lapw2, all the output files should be written to a shared folder (not to scratch folder of each node) so that sumpara -p could access all the output files. In the version that I'm using (11.0), it seems that lapw1 is not executed locally. Yundi On Thu, Jun 27, 2013 at 1:37 PM, Yundi Quan yq...@ucdavis.edu mailto:yq...@ucdavis.edu wrote: -- Forwarded message -- From: *Stefaan Cottenier* stefaan.cotten...@ugent.be mailto:stefaan.cotten...@ugent.be Date: Thu, Jun 27, 2013 at 1:33 PM Subject: Re: [Wien] scratch folder in k-point parallel calculation To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at mailto:wien@zeus.theochem.tuwien.ac.at I'm working on a cluster with many nodes. Each node has its own /scratch folder which cannot be accessed by other nodes. My own data folder is accessible to all nodes. When the WIEN2k scratch folder is set to './', everything works fine except that all the data write/read are done in my own data folder which slows down the system. When the WIEN2k scratch folder is set to '/scratch', then the scratch files such as case.vector_ created on one node would not be visible to the other. This would not be a problem for lapw1 -p and lapw2 -p if each node sticks to certain k points and searches for scratch files related to these k-points. Is there a way of configuring WIEN2k to work in this manner? The k-point parallelization scheme works exactly in this way (mpi parallelization is different). STefaan _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] scratch folder in k-point parallel calculation
Hi, Oleg, Thanks for you advice. Yundi On Thu, Jun 27, 2013 at 8:08 PM, Yundi Quan yq...@ucdavis.edu wrote: -- Forwarded message -- From: Oleg Rubel oru...@lakeheadu.ca Date: Thu, Jun 27, 2013 at 7:46 PM Subject: Re: [Wien] scratch folder in k-point parallel calculation To: wien@zeus.theochem.tuwien.ac.at If you are talking about a mixed (MPI k-parallel) job, there are suggestions in FAQs: http://www.wien2k.at/reg_user/**faq/pbs.htmlhttp://www.wien2k.at/reg_user/faq/pbs.html I use SGE scheduler and the following parallel_options file: setenv USE_REMOTE 0 setenv MPI_REMOTE 0 setenv WIEN_GRANULARITY 1 setenv WIEN_MPIRUN mpiexec -machinefile _HOSTS_ -n _NP_ _EXEC_ Eventually, it works with the local SCRATCH directory. I can share a submission script for the mixed MPI+k parallel job, if needed. Oleg On 13-06-27 4:46 PM, Yundi Quan wrote: I forgot to add that after lapw2, all the output files should be written to a shared folder (not to scratch folder of each node) so that sumpara -p could access all the output files. In the version that I'm using (11.0), it seems that lapw1 is not executed locally. Yundi On Thu, Jun 27, 2013 at 1:37 PM, Yundi Quan yq...@ucdavis.edu mailto:yq...@ucdavis.edu wrote: -- Forwarded message -- From: *Stefaan Cottenier* stefaan.cotten...@ugent.be mailto:Stefaan.Cottenier@**ugent.be stefaan.cotten...@ugent.be Date: Thu, Jun 27, 2013 at 1:33 PM Subject: Re: [Wien] scratch folder in k-point parallel calculation To: A Mailing list for WIEN2k users w...@zeus.theochem.tuwien.ac.** at wien@zeus.theochem.tuwien.ac.at mailto:wien@zeus.theochem.**tuwien.ac.atwien@zeus.theochem.tuwien.ac.at I'm working on a cluster with many nodes. Each node has its own /scratch folder which cannot be accessed by other nodes. My own data folder is accessible to all nodes. When the WIEN2k scratch folder is set to './', everything works fine except that all the data write/read are done in my own data folder which slows down the system. When the WIEN2k scratch folder is set to '/scratch', then the scratch files such as case.vector_ created on one node would not be visible to the other. This would not be a problem for lapw1 -p and lapw2 -p if each node sticks to certain k points and searches for scratch files related to these k-points. Is there a way of configuring WIEN2k to work in this manner? The k-point parallelization scheme works exactly in this way (mpi parallelization is different). STefaan __**___ Wien mailing list w...@zeus.theochem.tuwien.ac._**_at mailto:Wien@zeus.theochem.**tuwien.ac.atWien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wienhttp://ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__**w...@zeus.theochem.tuwien.ac._** _at/index.htmlhttp://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/**w...@zeus.theochem.tuwien.ac.** at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
