Re: [SIESTA-L]
Hi, When you increase the energy shift then you decrease the cutoff radii, so the energy increases. The behaviour of your plot is exactly what you should expect. What you should converge is the total energy of your condensed system, formed by multiple atoms. In that situation the energy should converge (with a tolerance of a few mev) with respect to the energy shift. Best regards, Eduardo On 03/11/2008, at 19:13, Xu Lu wrote: Dear Eduardo and all: Thank you very much for your reply. Here I give you one of my input files and other information: = start of input file= SystemNamecarbon atom # Descriptive name of the system SystemLabel C-atom# Short name for naming files # Species and atoms NumberOfSpecies1 NumberOfAtoms 1 %block ChemicalSpeciesLabel 1 6 C %endblock ChemicalSpeciesLabel # Basis (TZP) %block PAO.Basis # Define Basis set C 2# Species label, number of l-shells n=2 0 3 # n, l, Nzeta 0.0000.000 0.000 1.0001.000 1.000 n=2 1 3 P 1 # n, l, Nzeta, Polarization, NzetaPol 0.0000.000 0.000 1.0001.000 1.000 %endblock PAO.Basis PAO.EnergyShift 10 meV xc.functional LDA# Default value xc.authors PZ # Default value MeshCutoff 300. Ry OccupationFunction MP ElectronicTemperature 100 K # SCF options MaxSCFIterations 150 # Maximum number of SCF iter DM.NumberPulay 5 DM.MixingWeight 0.20 # New DM amount for next SCF cycle DM.Tolerance 1.d-4 # Tolerance in maximum difference # between input and output DM # Atomic coordinates AtomicCoordinatesFormat Ang %block AtomicCoordinatesAndAtomicSpecies 0.0.0. 1 %endblock AtomicCoordinatesAndAtomicSpecies === end of input file= You can also have a look at a plot of my total energy convergence results with respect to energy shift. https://www.msu.edu/~luxu/singlecarbon-data.png It seems hard to achieve Self-Consistency at zero electronic temperature, I used electron temperature at 100.0 K and MP (Methfessel-Paxton)occupation function and I hope this set up is not the reason of problems. Thank you again for your kind helps! Sincerely yours, Xu Lu == Xu Lu --- Physics and Astronomy Department 4240 Biomedical Physical Sci. Bldg Michigan State University East Lansing, MI 48824-2320 USA (517)884-5672 (office) (517)4205973 (mobile) (517)353-4500 (FAX) http://www.msu.edu/~luxu == Eduardo Anglada writes: Hi, Could you please post your results and the input fdf? The energy should converge. Best Eduardo On 01/11/2008, at 15:23, Xu Lu wrote: Dear all : I have a problem in calculating the energy of single atom. The energy will drop linearly with respect to decreasing of energy shift. It seems that the energy does not converge with respect to energy shift. What is the problem with single atom calculation ? Do I need to consider the energy shift convergence in this calculation.
Re: [SIESTA-L] Crazy SCF with vanadium
Could you please post your V pseudo? The mesh cutoff doesn't vary the scf, it only controls the rippling of energy/forces. This rippling is due to the FFT aliasing of those magnitudes (orbs^2,neutral atom potential, core charge for non linear core corrections) which are projected into the grid. As the aliasing is constant (ie during the scf the atoms don't move with respect to the grid) the mesh cutoff shouldn't play any role. Best regards, Eduardo On 04/11/2008, at 18:05, Joachim Fürst wrote: Hi, Thank you for your advices. I have also cut the system down to only a 100 atoms or so, without any improvement. I have a pretty good idea about V position, what is less known to me is the distortion of the sheet. I have done runs with 220 Ry mesh, but no change. I will try very high temperature as a final try. Thansk again. Joachim -Original Message- From: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Verissimo Alves Sent: 4. november 2008 17:42 To: SIESTA-L@listserv.uam.es Subject: Re: [SIESTA-L] Crazy SCF with vanadium 631 atoms? whew... Thee could be a few things that might help. One thing is to set an electronic temperature higher than the default (about 25 meV). Even though you say you have raised the temperature (which I assume to be the electronic temperature), how high have you raised? Maybe you'll have to set it to a really high value for your calculation to converge initially, after which you'll be able to lower it gradually, in steps of about 10 meV and re-relaxing everything again. Another thing that helps convergence is that V atoms are in a good initial position. My personal experience is that when the initial positions of the atoms are way off the equilibrium ones, scf can be problematic, especially if you have d electrons (in my case I have Ni slabs). Supposing that V atoms would be adsorbed over the graphene surface, you could try doing an initial relaxation with the Harris functional - which would overcome scf convergence problems in a first step. It will most probably not give very reliable results, but it could help in determining an initial set of positions which could be not too off from equilibrium. Make a test with a V atom over a 32-atom graphene sheet to compare the outcomes of full scf relaxation and a Harris functional calculation; if it gives decent results, you could try doing this to your larger sheet. Finally, I would use a larger MeshCutoff. It might help to improve SCF convergence. Try at least 220-250 Ry. Best of luck, Marcos Vous avez écrit / You have written / Lei ha scritto / Você escreveu... Joachim Fürst Dear all, I am doing a relaxation with vanadium on graphene, and the scf loop goes crazy: siesta: iscfEharris(eV) E_KS(eV)FreeEng(eV) dDmax Ef(eV) siesta:1 -97094.38150 -99070.91635 -99070.91635 39.07032 -4.23154 timer: Routine,Calls,Time,% = IterSCF1 882.442 95.03 elaps: Routine,Calls,Wall,% = IterSCF1 223.031 94.74 siesta:2 -97140.17446 -99051.35598 -99051.50902 34.72834 -4.20753 siesta:3 -97226.76276 -98965.36619 -98965.50463 35.42815 -4.12217 siesta:4 -94936.08243 -99371.74467 -99371.89250 35.10492 -4.22078 siesta:5 -90678.74567 -99715.25553 -99715.47141 24.75070 -4.07217 siesta:6 -86315.83616 -100050.89144 -100051.12562 36.83745 -3.67364 siesta:7 -97702.64129 -98510.48955 -98510.724571051.40098 -3.89029 -And it only gets worse after more iterations. I have tried almost all thinkable combinations of Pulay mixing, mixing rate etc, but without success. I have also increased temperature, disabled spin, changed energyshift, tried different basis sets for all elementsNo luck at all! Sometimes I can get it to converge, but then after a CG step or two it goes nuts again. If I leave out vanadium, the problem disappears. I have used this vanadium PS many times in different calculations, but have never come across this issue until now. Have you got any ideas? I have listed my .fdf file below (the long list of coordinates is left out). Hope you have some good advice. Thanks! NumberOfSpecies: 3 NumberOfAtoms: 631 LatticeConstant 1.0 Ang %block LatticeVectors 55. 0. 0. 0. 8. 0 0.0. 36.84 %endblock LatticeVectors %block ChemicalSpeciesLabel 1 6 C_pbe 2 1 H 3 23 V %endblock ChemicalSpeciesLabel AtomicCoordinatesFormat Ang %block AtomicCoordinatesAndAtomicSpecies 40.470458 0.00 0.000196 1 39.049818 0.00 0.000213 1 36.210059 -0.01 0.000237 1 0.709653 0.00 0.000252 1 . . %endblock AtomicCoordinatesAndAtomicSpecies %block kgrid_Monkhorst_Pack 1 0 0 0.0 0 1 0 0.0 0 0 1 0.0 %endblock kgrid_Monkhorst_Pack DM.UseSaveDM T #SaveTotalPotential T #SaveRho T #SaveElectrostaticPotential T #MD.UseSaveXV T
Re: [SIESTA-L] Bulk cohesion energy
Hi, At the beginning of each SIESTA run, during the generation of the atomic orbitals, the number of basis functions for each species is written. Best Eduardo On 03/11/2008, at 21:05, Roberto Veiga wrote: Where in the output can I find the number of basis functions? Roberto From: Oleksandr Voznyy [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Monday, November 3, 2008 3:41:53 PM Subject: Re: [SIESTA-L] Bulk cohesion energy I did like that: E=E(Fe-bulk)-E(Fe-isolated) and I obtained 4.80 eV This doesn't mean anything yet. It's the same as fitting pseudopotential to obtain better lattice constant. So I think that in this case the BSSE correction is negligible. Try it before saying it. The single atom vs atom in the bulk is the situation when one would expect the strongest BSSE.
Re: [SIESTA-L] Bulk cohesion energy
Hola, You sum the multiplication of the number of basis functions of each species by the number of atoms of that species. You should take into account more than the atoms explicitly defined in your input. Best, Eduardo On 04/11/2008, at 11:38, Roberto Veiga wrote: Thank you, Eduardo. How do I obtain the total number of basis functions for a condensed system? Should I take into account more than the atoms explicitly defined in my input? Roberto From: Eduardo Anglada [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Tuesday, November 4, 2008 9:45:34 AM Subject: Re: [SIESTA-L] Bulk cohesion energy Hi, At the beginning of each SIESTA run, during the generation of the atomic orbitals, the number of basis functions for each species is written. Best Eduardo On 03/11/2008, at 21:05, Roberto Veiga wrote: Where in the output can I find the number of basis functions? Roberto From: Oleksandr Voznyy [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Monday, November 3, 2008 3:41:53 PM Subject: Re: [SIESTA-L] Bulk cohesion energy I did like that: E=E(Fe-bulk)-E(Fe-isolated) and I obtained 4.80 eV This doesn't mean anything yet. It's the same as fitting pseudopotential to obtain better lattice constant. So I think that in this case the BSSE correction is negligible. Try it before saying it. The single atom vs atom in the bulk is the situation when one would expect the strongest BSSE.
Re: [SIESTA-L]
Hi, Could you please post your results and the input fdf? The energy should converge. Best Eduardo On 01/11/2008, at 15:23, Xu Lu wrote: Dear all : I have a problem in calculating the energy of single atom. The energy will drop linearly with respect to decreasing of energy shift. It seems that the energy does not converge with respect to energy shift. What is the problem with single atom calculation ? Do I need to consider the energy shift convergence in this calculation.
Re: [SIESTA-L] Plrho compilation problem
reference to `iargc_' collect2: ld returned 1 exit status make: *** [denchar] Error 1 - Which vendor provided the f95 compiler? Once you know the vendor take a look at: /home/bias/siesta-2.0.1/Src/f2kcli_manual.txt In that file you can find howto compile the f2kcli module. Best, Eduardo *** I'm fairly confused now which compiler to use for using Siesta and Utils. Note: Siesta works fine now :) Thanks, Regards, From: Eduardo Anglada [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Thursday, October 30, 2008 9:55:07 AM Subject: Re: [SIESTA-L] Plrho compilation problem Hello You have to use the same compiler for the utils and for siesta. Could you please post the error message? Best, Eduardo On 29/10/2008, at 18:17, Johnny Dry wrote: Hello Siesta users, I'm using: * Mandriva Linux 2008 * g95 compiler * Siesta 2.0.1 I've compiled these packages: * Siesta * Utils from Andre Postnikov (xv2xsf, ...) * General Utils (eig2dos, gnubands, ...) * xCrysDen package * JMol package using g95 Fortran compiler. I can now run Siesta and simulate the first two examples. And I can see the atoms in both xCrysDen and Jmol. As a next step, I tried to investigate electron density, total energy, wavefunctions, etc using plrho. So, I tried firstly using g95 (GNU Fortran) but it did not work for pgplot. Then, I've downloaded Intel Fortran Compiler and F77 compiler and tried the following with both of these compilers: * Downloaded and compiled pgplot5.2 (With g77 it is straightforward, and with ifc, I've modified the makefile (cheated it:))) * Tried to install plrho, but I couldn not in either case. So, the question is, Which compiler is ideal for this system to install pgplot and plrho? I've read some threads in the mail list, but could not have them working:( Any help is appreciated. Regards, John
Re: [SIESTA-L] Multigrig solver for Poisson Equation
Hi, As far as I know It is not being distributed. Best, Eduardo On 29/10/2008, at 12:48, José Eduardo Padilha de Sousa wrote: Hi All. In a recent article about SIESTA (J. Phys.: Condens. Matter 20 (2008) 064208), I read that a multigrid solver for the Poisson equation on the grid has been implemented [reference 22 in the article]. Did anybody now where I can found a subroutine that do this, until this version of Siesta implementation is not available? Thanks. Padilha This message was sent using IFUSP Webmail - USP/Sao Paulo/Brazil.
Re: [SIESTA-L] plstm problem
Hi, Try with: a.out input Best, Eduardo On 30/10/2008, at 5:18, Руслан Жачук wrote: Dear SIESTA users, I am using OpenSUSE Linux 10.3 and installed following packages to compile SIESTA utilities: 1) gcc-fortran (4.2) //The system GNU Compiler 2) gcc42-fortran (4.2.1_20070724) //The GNU Fortran Compiler and Support Files 3) libgfortran 42 (4.2.1_20070724) //The GNU Fortran Compiler Runtime Library Then I tried to compile plstm.f using command: gfortran plstm.f I got 2 warning messages about using GOTO command which is obsolete. Ok, at least no errors. I got executable a.out Then I generated h2o.LDOS file from examples given in SIESTA. I tried to make STM image using command: a.out input But it seems doing nothing - program is in memory, but it does not generate any output, not on hard disk, nor in Terminal window. And program does not finish. The input file I used is: --begin of file--- h2o ldos constant-height 1 unformatted --end of file- Please, help me, as I am migrating from AIMPRO to SIESTA and new to this stuff. Ruslan
Re: [SIESTA-L] Plrho compilation problem
Hello You have to use the same compiler for the utils and for siesta. Could you please post the error message? Best, Eduardo On 29/10/2008, at 18:17, Johnny Dry wrote: Hello Siesta users, I'm using: * Mandriva Linux 2008 * g95 compiler * Siesta 2.0.1 I've compiled these packages: * Siesta * Utils from Andre Postnikov (xv2xsf, ...) * General Utils (eig2dos, gnubands, ...) * xCrysDen package * JMol package using g95 Fortran compiler. I can now run Siesta and simulate the first two examples. And I can see the atoms in both xCrysDen and Jmol. As a next step, I tried to investigate electron density, total energy, wavefunctions, etc using plrho. So, I tried firstly using g95 (GNU Fortran) but it did not work for pgplot. Then, I've downloaded Intel Fortran Compiler and F77 compiler and tried the following with both of these compilers: * Downloaded and compiled pgplot5.2 (With g77 it is straightforward, and with ifc, I've modified the makefile (cheated it:))) * Tried to install plrho, but I couldn not in either case. So, the question is, Which compiler is ideal for this system to install pgplot and plrho? I've read some threads in the mail list, but could not have them working:( Any help is appreciated. Regards, John
Re: [SIESTA-L] Qtot convergence pb is back
Hola Roberto, Then the problem is that your compiler does buffering I/O. As the buffer isn't full there is no flush of the communication channel and the slave siesta waits forever. Almost all the compilers have an option which turns off the buffering. Best, Eduardo On 22/10/2008, at 12:50, R.C.Pasianot wrote: Hi Eduardo, Sorry for my missleading use of run, should have said call instead: It is the 2nd call to siesta_forces (within a series between siesta_launch and siesta_quit) that doesn't work. And the problem's only with my new Linux box; older ones run fine ... :/ . Best, Roberto Dear Roberto, Do you mean that restarting doesn't work? If this is the problem, remove the *.forces and *.coords files. Best, Eduardo 1st CALL siesta: iscf Eharris(eV) E_KS(eV) FreeEng(eV) dDmax Ef(eV) siesta:1 -62761.6906 -62761.6902 -62761.6902 0.0007 -2.8547 timer: Routine,Calls,Time,% = IterSCF12967.293 93.61 elaps: Routine,Calls,Wall,% = IterSCF1 496.914 93.59 siesta: E_KS(eV) = -62761.6902 2nd CALL siesta: iscf Eharris(eV) E_KS(eV) FreeEng(eV) dDmax Ef(eV) siesta:1 -62232.7174 -62761.6903 -62765.8366 0.1123 -2.8559 siesta:2 -62232.7194 -62761.7688 -62765.9673 0.1089 -2.8559 siesta: WARNING: Qtot, Tr[D*S] = 587.00 565.368007 siesta:3 -62232.7922 -62764.3826 -62768.5811 0.0955 -2.8548
Re: [SIESTA-L] Pseudo_for_C
Dear Alexandre, Why do you fix the radius of all the channels to the same value? In principle the matching radius is different for each angular momentum channel. Best regards, Eduardo On 15/10/2008, at 16:00, Alexandre Lebon wrote: Dear Siesta users, I am meeting some difficulty at creating a gga pseudo for C that include relativistic effects. In fact, I get an inconsistent behaviour in the log derivative for the channel l=0. The problem vanishes if I switch off the r flag. Here are some pieces of .inp files: 1. The .inp file without r flag pg C TM2 Pseudopotencial GS ref tm2 3.00 Cpb 0 14 20 2.00 21 2.00 32 0.00 43 0.00 1.25 1.25 1.25 1.25 0.0 0.00 123456789012345678901234567890123456789012345678901234567890 ALL LOG DEV OK 2. same .inp file with r flag pg C TM2 Pseudopotencial GS ref tm2 3.00 Cpbr 0 14 20 2.00 21 2.00 32 0.00 43 0.00 1.25 1.25 1.25 1.25 0.0 0.00 123456789012345678901234567890123456789012345678901234567890 LOG DEV BAD FOR L=0 3. .inp file rc was increased to 1.50 r flag present pg C TM2 Pseudopotencial GS ref tm2 3.00 Cpbr 0 14 20 2.00 21 2.00 32 0.00 43 0.00 1.50 1.50 1.50 1.50 0.0 0.00 123456789012345678901234567890123456789012345678901234567890 LOG DEV TROUBLE FOR L=0 4. .inp file rc=1.25 r flag present rpc added and set to 0.5 pg C TM2 Pseudopotencial GS ref tm2 3.00 Cpbr 0 14 20 2.00 21 2.00 32 0.00 43 0.00 1.25 1.25 1.25 1.25 0.0 0.50 123456789012345678901234567890123456789012345678901234567890 LOG DEV TROUBLE FOR L=0 Does anyone have a clue to solve this problem? By the way is it important? Thanks in advance for any answer. Alexandre
Re: [SIESTA-L] Gap in ZnO
On 11/10/2008, at 9:52, Subhra Kulshrestha wrote: Dear users, I am also facing the same problem in computing the band structure of f-band materials. They are semiconducting but the band structure calculated from LDA, LSDA, GGA, GGA+spin gives metallic behaviour. I want to get it calculated by LSDA+U or any other method with +U. Is this facility of +U implemented in SIESTA ? It will be included in a future version of Siesta. I don't know when it will be released. Best, Eduardo Thanks, Subhra Kulshrestha --- On Fri, 10/10/08, N H [EMAIL PROTECTED] wrote: From: N H [EMAIL PROTECTED] Subject: Re: [SIESTA-L] Gap in ZnO To: SIESTA-L@listserv.uam.es Date: Friday, 10 October, 2008, 4:54 PM Dear David ... I dont know what is your referencial, but the error in the band gap is neither exclusive for SIESTA norfor ZnO. This is a problem known as band-gap error which affect DFT calculations because instead what happens for post HF methods, the Ex correlation functionals are not exact. Well... u can try to get better results using hybrid functionals or LDA + U ( in this case the error will still be there, but smaller ). By the way ... this subject was treated in this list already and u can check for more information in the archieves ! Cheers NH On Fri, Oct 10, 2008 at 12:18 PM, cornil david [EMAIL PROTECTED] wrote: Dear SIESTA users I'm trying to reproduce band structure diagram for ZnO but results are very bad as the gap (witch is normaly around 3 eV ) are not reproduce in the diagramm that I've obtained. I've generate pseudo for a PBE calculation for Zn and O and used the blocks kgrid Monkhorst Pack and bandlines with DZP basis. I've checked in the mailing list archive but I've not found a solution to my problem. Is someone can help me and say me what is missing ? Does the problem come from pseudo, basis or form other keywords ? Thanks for help, Here's a copy of my input SystemLabel ZnO NumberOfAtoms4 NumberOfSpecies 2 %block ChemicalSpeciesLabel 1 30 Zn 28 O %endblock ChemicalSpeciesLabel LatticeConstant 1.0 Ang %block LatticeParameters 3.25 3.25 5.6 90.00 90.00 60.00 %endblock LatticeParameters AtomicCoordinatesFormat NotScaledCartesianAng %block AtomicCoordinatesAndAtomicSpecies 0.0 0.0 0.01 0.0 0.0 1.690002 1.60500 1.08000 2.605001 1.60500 1.08000 4.559002 %endblock AtomicCoordinatesAndAtomicSpecies MeshCutoff 170.0 Ry PAO.BasisSizeDZP MaxSCFIterations 300 DM.Tolerance 5.d-4 DM.NumberPulay 10 DM.MixingWeight 0.01 SolutionMethod diagon XC.authorsPBE XC.functional GGA %block k_grid_Monkhorst_Pack 4 0 0 0.5 0 4 0 0.5 0 0 1 0.5 %endblock k_grid_Monkhorst_Pack BandlinesScale ReciprocalLatticeVectors %block BandLines 1 0.000 0.000 0.500 A 39 0.000 0.500 0.500 L 19 0.000 0.500 0.000 M 39 0.000 0.000 0.000 \Gamma 19 0.000 0.000 0.500 A 50 0.330 0.330 0.500 H 19 0.330 0.330 0.000 K 50 0.000 0.000 0.000 \Gamma MeshCutoff 170.0 Ry PAO.BasisSizeDZP MaxSCFIterations 300 DM.Tolerance 5.d-4 DM.NumberPulay 10 DM.MixingWeight 0.01 SolutionMethod diagon XC.authorsPBE XC.functional GGA %block k_grid_Monkhorst_Pack 4 0 0 0.5 0 4 0 0.5 0 0 1 0.5 %endblock k_grid_Monkhorst_Pack BandlinesScale ReciprocalLatticeVectors %block BandLines 1 0.000 0.000 0.500 A 39 0.000 0.500 0.500 L 19 0.000 0.500 0.000 M 39 0.000 0.000 0.000 \Gamma 19 0.000 0.000 0.500 A 50 0.330 0.330 0.500 H 19 0.330 0.330 0.000 K 50 0.000 0.000 0.000 \Gamma %endblock BandLines LongOutput .true. WriteKpoints.true. WriteCoorXmol .true. WriteCoorStep .true. WriteCoorCerius .true. Diag.DivideAndConquer .false. SaveRho .true. SaveDeltaRho .true. SaveElectrostaticPotential .true. SaveTotalPotential .true. SaveIonicCharge .true. SaveTotalCharge .true. Be the first one to try the new Messenger 9 Beta! Click here.
Re: [SIESTA-L] pair correlation function and self diffusion
Dear Karim, It is possible, but you have to construct the program yourself. Best, Eduardo On 11/10/2008, at 14:44, karim rezouali wrote: Dear SIESTA users, Is it possible to calculate the following parameters using the SIESTA code? 1. Pair correlation function 2. the self diffusion coefficients thanks before, Karim
Re: [SIESTA-L] the use of plrho!
Hi, You have to compile plrho exactly (with the same compiler and options) the same as the siesta you are going to use. If you mix compilers and/or options it won't work. Best, Eduardo On 07/10/2008, at 14:59, zhiyong wang wrote: hi,all siesta users: I have compiled the plrho in my computer,and it works well with the results which have computed with my computer,but when I use the plrho to deal with the results which come from another computer,I cannot get anything except for the following error: At line 72 of file iorho.f Fortran runtime error: Invalid argument can you help me?thank you in advance!
Re: [SIESTA-L] LDOS and broadening
Hi, David is correct, you have to decrease the electronic temperature. If you encounter any difficulties send me a message. Best regards, Eduardo On 03/10/2008, at 19:40, David Strubbe wrote: I think the LDOS is broadened by the electronic temperature, so maybe you have to decrease that. David Strubbe UC Berkeley On Fri, Oct 3, 2008 at 7:00 AM, Oleksandr Voznyy [EMAIL PROTECTED] wrote: Hi, I'm trying to study the small nanocrystal and need to visualize separate energy levels of it, which are spaced by ~50meV (only Gamma point is used obviously). Here is a part from EIG file: -4.477 -4.39768 -4.35551 -4.33129 here is the gap -3.83119 -3.80327 -3.76139 -3.72478 The problem is that when I try to plot LDOS in the range of energies from -4.1 to -4 (i.e. ~0.2eV from real levels), it is still non-zero. So it would be impossible to plot the LDOS of separate levels separated by only 0.05eV. Is there any broadening used to calculate LDOS? And how to avoid it? Sincerely, Alexander
Re: [SIESTA-L] Problem with optimization using variable cell]
Hi Arun, This problem happens from time to time. It's quite frustrating because I haven't been able to reproduce it, so I don't have any clue. What happens if you restart? Does the output include the cell vectors of the last step? Maybe they can be found in the XV file. The crash happens during the calculation of the mesh, which depends on the lattice vectors. Best regards, Eduardo On 11/09/2008, at 7:55, Arun Kumar Manna wrote: Dear all, I am facing problem with optimization using MD variable cell true. It shows the following error in output file after few CG steps: For one case: InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 34560 x 32768 x 36864 = 0 And for an another case: InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 180 x 160 x 250 = 720 InitMesh: MESH = 62208 x 60750 x 65536 = 167772160 Could someone help me regarding this?. Thanks, Arun
Re: [SIESTA-L] Question about finding barrier height
Hi Kamaram! Do you need so many planes? The calculation is going to be very long! If you need the LDOS you should include the following option in the input fdf: %block LocalDensityOfStates Emin Emax units %endblock LocalDensityOfStates The Emin and Emax (Emin Emax) specify the interval of energies for the calculation of the DOS and LDOS. The relevant section of the manual is: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/manual-2.0/node24.html#3002 Regards, Eduardo On 29/09/2008, at 14:23, Kamaram Munira wrote: I have a unit cell that has 100 plane of Magnesium Oxide sandwiched between 100 planes of Nickel in the z direction. The unit cell is x,y periodic. What is the best way to find out the barrier height created by MgO. plot LDOS? Thanks -Kamaram --- Kamaram Munira Graduate Research Assistant Charles Brown Department of Electrical Engineering University of Virginia Charlottesville, VA-22903.
Re: [SIESTA-L] Can anyone solve the problem on downloading SIESTA?
Dear Adrian, We are really sorry, we're trying to solve this issue. If you can't wait I will send it to you (or anybody else). Best regards, Eduardo On 30/09/2008, at 5:24, Adrain Zhou wrote: Dear all, I can not download SIESTA code from http://www.uam.es/departamentos/ciencias/fismateriac/siesta/. Some other people and I had reported the downloading prbolem before. Can anyone help us solve this problem? Many thanks! Regards, Adrian ___ 雅虎邮箱，您的终生邮箱！ http://cn.mail.yahoo.com/
Re: [SIESTA-L] mpi error with siesta 2.0.x using intel compilers on infiniband
Hi, Are you able to run (successfully) scalapack and blacs tests? Maybe the problem has nothing to do with siesta, it looks like a communication problem. Regards, Eduardo On 23/09/2008, at 4:30, M Bharat Kumar wrote: Hello All, When trying to run simulations using siesta on our new cluster, I am not able to complete the simulations because of mpi errors. I tried both siesta 2.0 and siesta 2.0.1. The compilers are icc and ifort. I tried using scalapack and blacs routines suppplied in intel mkl libraries as well as self-compiled scalapack and blacs. Also I tried mvapich2-1.03, mvapich2-1.2RC2, and intel mpi 3.1. Whatever combination I am trying, the program is stopping in the middle of simulation with errors like Warning! Rndv Receiver is receiving (7168 32128) less than as expected Warning! Rndv Receiver is receiving (7168 32128) less than as expected Fatal error in MPI_Bcast: Message truncated, error stack: MPI_Bcast(1144): MPI_Bcast(buf=0xc92c9d0, count=1, dtype=USERvector, root=0, comm=0xc406) failed MPIR_Bcast(228): MPIDI_CH3U_Post_data_receive_found(439): Message from rank 0 and tag 2 truncated; 32128 bytes received but buffer size is 7168 Fatal error in MPI_Bcast: Message truncated, error stack: MPI_Bcast(1144): MPI_Bcast(buf=0x14fb740, count=1, dtype=USERvector, root=0, comm=0xc406) failed MPIR_Bcast(228): MPIDI_CH3U_Post_data_receive_found(439): Message from rank 0 and tag 2 truncated; 32128 bytes received but buffer size is 7168 rank 11 in job 4 master_45552 caused collective abort of all ranks exit status of rank 11: killed by signal 9 Thinking that the error may be due to stack size, I set ulimit-s 256000 and also tried using -heap_arrays flag, but with no success. Some one please point out the source of error. Thanks, Bharat
Re: [SIESTA-L] Queries about reliability of SIESTA under LDA
Dear Nidhi, On 24/09/2008, at 8:50, Nidhi Sharma wrote: Dear Users, I have computed the high pressure properties and electronic structure calculations of a semiconducting heavy earth compounds with LDA and non-relativistic, alongwith polarization orbitals : perturbative polarization. I got underestimated results on phase transition and enrergy gap by an amount of 2-3 %, which seems to be within the limits of DFT - LDA. Is it necessary that LDA not capable to describe the strong correlations in heavy earth compounds with f electrons if one doesnot include spin effect during calculations ? Does it mean that we might have got the right answer for a wrong reason using SIESTA with LDA ? If so, what may be the causes ? Maybe there is error cancellation, have you studied the literature? In my limited experience with f electrons the results are reasonable. Regards, Eduardo May someone answer these queries for my satisfaction ? Thanks in anticipation, Nidhi Unlimited freedom, unlimited storage. Get it now
Re: [SIESTA-L] simulation of metal alloy liquid
Dear Chol-Jun Yu, Siesta can do this kind of molecular dynamics simulations. In the input fdf file you should include the following options: WriteMDhistory WriteMDXmol At the end of the simulation there will be two output files: SystemLabel.MD - contains positions and velocities at every time step. SystemLabel.MDE - Energy, temperature, etc also at every time step. SystemLabel.XV - coordinates in xmol format By default the MD and MDE are binary files. If you change routine iomd they can be written in ascii. The relevant section of the manual is: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/manual-2.0/node41.html Regards, Eduardo On 12/09/2008, at 8:52, Chol-Jun Yu wrote: Dear SIESTA users, I would like to ask whether we can get the reasonable results of metal alloy liquid (at high temperature, e.g. 1500 K) by using SIESTA or not. I want to compare the radial distribution function g(r) and structure factor S(q) between classical MD (EAM-MD) and ab initio MD. To do so, we have to perform NPT ensemble MD simulation by means of e.g. Nose-Parrinello-Rahman algorithm. In such simulation, can we get the positions (ANI file) and velocities (?) of atoms at every time step? If so, could you teach me the necessary and reasonable input parameters, and/or related references? Thank you so much in advance. With best regards, Chol-Jun -- Chol-Jun Yu Computational Materials Engineering (CME) Institute of Minerals Engineering (GHI) Center for Computational Engineering Science (CCES) RWTH Aachen University (RWTH) Jülich-Aachen Research Alliance (JARA) D-52064 Aachen, Mauerstrasse 5, Tel: +49-241-8094989 Fax: +49-241-80695097
Re: [SIESTA-L] mpi error with siesta 2.0.x using intel compilers oninfiniband
On 02/10/2008, at 17:58, Bharat wrote: Hi Eduardo, Thanks. scalapack and blacs work fine. Anyhow I figured its a problem with mvapich2. With openmpi, I could run the problematic input files successfully. Great!! On Thu, 02 Oct 2008 01:52:42 -0600, Eduardo Anglada [EMAIL PROTECTED] wrote: Hi, Are you able to run (successfully) scalapack and blacs tests? Maybe the problem has nothing to do with siesta, it looks like a communication problem. Regards, Eduardo On 23/09/2008, at 4:30, M Bharat Kumar wrote: Hello All, When trying to run simulations using siesta on our new cluster, I am not able to complete the simulations because of mpi errors. I tried both siesta 2.0 and siesta 2.0.1. The compilers are icc and ifort. I tried using scalapack and blacs routines suppplied in intel mkl libraries as well as self-compiled scalapack and blacs. Also I tried mvapich2-1.03, mvapich2-1.2RC2, and intel mpi 3.1. Whatever combination I am trying, the program is stopping in the middle of simulation with errors like Warning! Rndv Receiver is receiving (7168 32128) less than as expected Warning! Rndv Receiver is receiving (7168 32128) less than as expected Fatal error in MPI_Bcast: Message truncated, error stack: MPI_Bcast(1144): MPI_Bcast(buf=0xc92c9d0, count=1, dtype=USERvector, root=0, comm=0xc406) failed MPIR_Bcast(228): MPIDI_CH3U_Post_data_receive_found(439): Message from rank 0 and tag 2 truncated; 32128 bytes received but buffer size is 7168 Fatal error in MPI_Bcast: Message truncated, error stack: MPI_Bcast(1144): MPI_Bcast(buf=0x14fb740, count=1, dtype=USERvector, root=0, comm=0xc406) failed MPIR_Bcast(228): MPIDI_CH3U_Post_data_receive_found(439): Message from rank 0 and tag 2 truncated; 32128 bytes received but buffer size is 7168 rank 11 in job 4 master_45552 caused collective abort of all ranks exit status of rank 11: killed by signal 9 Thinking that the error may be due to stack size, I set ulimit-s 256000 and also tried using -heap_arrays flag, but with no success. Some one please point out the source of error. Thanks, Bharat -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [SIESTA-L] Hybrid functional calcualtion
Hi, I'm really sorry but the PBE0 functional is not implemented in SIESTA. Regards, Eduardo On 01/08/2008, at 7:54, Adrain Zhou wrote: Dear all, Is there anybody has experience with hybrid functional (PBE0) calcualtion? Could you please tell me how is the performance? Do I use only PBE atom pseudopotential file? Regards, Adrian ___ 雅虎邮箱，您的终生邮箱！ http://cn.mail.yahoo.com/
Re: [SIESTA-L] Help with compilation error
Hi Tom, There is a problem in Makefile or arch.make files, the make program doesn't know how to compile a given file, and it call the c compiler without any input. Regards, Eduardo On 10/08/2008, at 4:08, Thomas Sadowski wrote: Hello all, I am attempting to compile parallel siesta on an Itanium2 using the Intel MKL libraries for BLAS and LAPACK, BLACS and ScaLAPACK with Intel compilers and am recieving the following error mpif90 -Vaxlib -c -O2 -tpp2 io.f mpif90 -Vaxlib -c -O2 -tpp2 spin_init.f mpif90 -Vaxlib -c -O2 -tpp2-DMPI coor.F mpif90 -Vaxlib -c -O2 -tpp2 atm_transfer.f mpif90 -Vaxlib -c -O2 -tpp2-DMPI broadcast_basis.F mpif90 -Vaxlib -c -O2 -tpp2-DMPI eggbox.F mpif90 -Vaxlib -c -O2 -tpp2 dsyevds.f mpif90 -Vaxlib -c -O2 -tpp2 zheevds.f mpif90 -Vaxlib -c -O2 -tpp2-DMPI optical.F mpif90 -Vaxlib -c -O2 -tpp2 phirphi_opt.f mpif90 -Vaxlib -c -O2 -tpp2-DMPI reoptical.F mpif90 -Vaxlib -c -O2 -tpp2-DMPI transition_rate.F mpif90 -Vaxlib -c -O2 -tpp2-DMPI initparallel.F mpif90 -Vaxlib -c -O2 -tpp2 setspatial.f mpif90 -Vaxlib -c -O2 -tpp2-DMPI setatomnodes.F mpif90 -Vaxlib -c -O2 -tpp2 uncell.f mpif90 -Vaxlib -c -O2 -tpp2 cart2frac.f mpif90 -Vaxlib -c -O2 -tpp2 obc.f mpif90 -Vaxlib -c -O2 -tpp2 m_history.f90 mpif90 -Vaxlib -c -O2 -tpp2-DMPI on_subs.F cc -o .o cc: no input files make: *** [.o] Error 1 Has anyone seen this error before? If so how did you resolve it? Thanks in advance -Tom Get Windows Live and get whatever you need, wherever you are. Start here.
Re: [SIESTA-L] Strange mpi problem
Hi Lakee, I think you have a problem with you openmpi setup, it tries to use infiniband, but it can't find any network cards so it uses standard ethernet. What I recommend is: 1) Check the tests and examples of openmpi. 2) Compile and test Blacs. If the test fail SIESTA will fail, so don't proceed with siesta installation until blacs works. 3) Idem for scalapack 4) Go for siesta compilation. Regards, Eduardo On 24/08/2008, at 5:43, Lakee Johnson wrote: Hi, Tom, I tried it. The problem is still there. Lakee 2008/8/24 Thomas Sadowski [EMAIL PROTECTED] That might be your problem...Try linking against libmpi_f90.a -Tom Date: Sat, 23 Aug 2008 10:13:43 +0800 From: [EMAIL PROTECTED] Subject: Re: [SIESTA-L] Strange mpi problem To: SIESTA-L@listserv.uam.es Hi, Dear Tom, I tried mpirun -np 4 siesta input.fdf output.out . What I get is the following: libibverbs: Fatal: couldn't read uverbs ABI version. -- [0,1,0]: OpenIB on host node1 was unable to find any HCAs. Another transport will be used instead, although this may result in lower performance. -- libibverbs: Fatal: couldn't read uverbs ABI version. -- [0,1,1]: OpenIB on host node1 was unable to find any HCAs. Another transport will be used instead, although this may result in lower performance. -- [node1:11756] *** An error occurred in MPI_Comm_group [node1:11757] *** An error occurred in MPI_Comm_group [node1:11757] *** on communicator MPI_COMM_WORLD [node1:11757] *** MPI_ERR_COMM: invalid communicator [node1:11757] *** MPI_ERRORS_ARE_FATAL (goodbye) [node1:11756] *** on communicator MPI_COMM_WORLD [node1:11756] *** MPI_ERR_COMM: invalid communicator [node1:11756] *** MPI_ERRORS_ARE_FATAL (goodbye) From the FAQ of openmpi official site, it seems that we should use the option --mca btl tcp,self for TCP network? My machines are also x86-64 architecture with RedHat Enterprise Linux 4. The compiler is pgi-7.1.4. My configure options are: ./configure --prefix=/usr/local/math_library/pgi-7.1.4/openmpi-1.2.6 CC=cc CXX=c++ F77=pgf90 F90=pgf90 FC=pgf90 CFLAGS=-O2 FFLAGS=-O2 Do you think there is anything wrong here, please? By the way, when I compile BLACS and scalapack, in the lib directory of openmpi-1.2.6, I can not see the file libmpich.a, but I can see it in both mpich2 and mvapich2. So I set MPILIB in Bmake.inc of BLACS and SMPLIB in SLmake.inc of scalapack to openmpi-1.2.6/lib/libmpi.la, since only this file looks similar to libmpich.a. Is it wrong here, please? I will appreciate it very much if you can send your log file for configuring openmpi, the Bmake.inc and SLmake.inc. Sincerely, Lakee 2008/8/23 Thomas Sadowski [EMAIL PROTECTED] Lakee, Glad to hear everything worked well with MVAPICH. In regards to OpenMPI, I am confused. You are running on a machine with eight CPUs correct? Why supply a host file then? Try it without the -hostfile filename. Typically, my routines are input mpirun -np 4 siesta input.fdf output.out If this still doesn't work, it may have to do with how you configured OpenMPI. The machines I run SIESTA on are x86_64 architecture with SuSE 10.x. OpenMPI was compiled with Intel Fortran, C compilers. I can send the log file, if necessary -Tom Date: Fri, 22 Aug 2008 22:47:25 +0800 From: [EMAIL PROTECTED] Subject: Re: [SIESTA-L] Strange mpi problem To: SIESTA-L@listserv.uam.es Hello, Dear Tom, Thank you so much for your experience and suggestion. I also have tried MVAPICH and OpenMPI today. For me, MVAPICH also works very well! :-) However, OpenMPI does not work for more than 1 processor. Every time after I run the command: mpirun --mca btl tcp,self -np 4 --hostfile hostfile siesta input.fdf output I always got the following error message [node1:10222] *** An error occurred in MPI_Comm_group [node1:10222] *** on communicator MPI_COMM_WORLD [node1:10222] *** MPI_ERR_COMM: invalid communicator [node1:10222] *** MPI_ERRORS_ARE_FATAL (goodbye) [node1:10223] *** An error occurred in MPI_Comm_group [node1:10223] *** on communicator MPI_COMM_WORLD [node1:10223] *** MPI_ERR_COMM: invalid communicator [node1:10223] *** MPI_ERRORS_ARE_FATAL (goodbye) [node1:10224] *** An error occurred in MPI_Comm_group [node1:10224] *** on communicator MPI_COMM_WORLD [node1:10224] *** MPI_ERR_COMM: invalid communicator [node1:10224] *** MPI_ERRORS_ARE_FATAL (goodbye) [node1:10225] *** An error occurred in MPI_Comm_group [node1:10225] *** on communicator MPI_COMM_WORLD [node1:10225] *** MPI_ERR_COMM: invalid communicator [node1:10225] *** MPI_ERRORS_ARE_FATAL (goodbye) [node1:10219] [0,0,0] ORTE_ERROR_LOG: Timeout in file base/ pls_base_orted_cmds.c at line 275 [node1:10219]
Re: [SIESTA-L] Blue Gene arch.make
Hi, I've asked a person who runs siesta in Blue Gene and this is her arch.make. She had to compile scalapack by hand. SIESTA_ARCH=XLF 32bits PARALLEL # FC= mpixlf90 #xlf90_r # FFLAGS_DEBUG= -g FFLAGS= -O5 -qarch=440d -qtune=440 COMP_LIBS= RANLIB=echo # NETCDF_LIBS= NETCDF_INTERFACE= DEFS_CDF= # MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=/bgl/BlueLight/ppcfloor/bglsys/include/ MPI_LIBS= #-lblacsgm DEFS_MPI= -WF,-DMPI SCALAPACK=/gpfs/home2/mfs/lib/libscalapack.a BLACS1=/bgl/local/lib/blacs_MPI-BGL-0.a BLACS2=/bgl/local/lib/blacsF77init_MPI-BGL-0.a BLACS3=/bgl/local/lib/blacsCinit_MPI-BGL-0.a LAPACK=/bgl/local/lib/liblapack.rts.a BLAS= -L/bgl/local/lib -lblas.rts LIBS= $(SCALAPACK) $(BLACS2) $(BLACS3) $(BLACS1) $(LAPACK) $(BLAS) SYS=xlf DEFS= $(DEFS_MPI) $(DEFS_CDF) FREE_F90=-qsuffix=f=f90 # .F90.o: $(FC) -qsuffix=cpp=F90 -c $(INCFLAGS) $(FFLAGS) $(DEFS) $ .f90.o: $(FC) -qsuffix=f=f90 -c $(INCFLAGS) $(FFLAGS) $ .F.o: $(FC) -qsuffix=cpp=F -c $(INCFLAGS) -qfixed $(FFLAGS) $(DEFS) $ .f.o: $(FC) -qsuffix=f=f -qfixed -c $(INCFLAGS) $(FFLAGS) $
Re: [SIESTA-L] Work function of Si
Hi, Please take a look at this previous posting by Javier Junquera. He has written a nice review about the subject http://www.mail-archive.com/siesta-l@listserv.uam.es/msg00627.html Best regards, Eduardo On 18/07/2008, at 20:34, zubaer wrote: Hi, I wanted to calculate the workfunction of a Si (001) surface using SaveTotalPotential and SaveElectrostaticPotential and then macroave.x utility. I checked the convergence in terms of slab layer and vacuum thicknesses. Finding the vacuum level and subtracting the fermi energy obtained from scf file, I got the value 5.51eV, which is way higher compared to the experimental value of 4.85eV. Could you suggest what things I need to check to make a better estimate. I appreciate any helps. Thanks, Zubaer
Re: [SIESTA-L] Electric field
Hi Luis, I think it is the middle point of the vector defined by the electric field in the %block Efield, by I'm not sure. Best, Eduardo On 15/07/2008, at 22:47, Luis Agapito wrote: Thanks Eduardo, Any idea of the SIESTA criteria for choosing the position of the discontinuity point of the zigzag profile? Luis From: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta [mailto:[EMAIL PROTECTED] On Behalf Of Eduardo Anglada Sent: Tuesday, July 15, 2008 7:35 AM To: SIESTA-L@listserv.uam.es Subject: Re: [SIESTA-L] Electric field Hello Luis, Siesta solves the Poisson equation using ffts, so the zig-zag potential due the electric field is allowed in the directions where there is vacuum. But siesta doesn't introduce a fictitious dipole charge (as far as I know). Maybe if you change the cell geometry and the values of the electric field you will be able to simulate the system you are interested in. Best, Eduardo On 11/07/2008, at 21:22, Luis Agapito wrote: Hello All, I’m applying electric field (z direction) to a slab (x-y plane). From the local potential profile, I can see that Siesta (version 2.0.1) applies a fictitious charge dipole layer to generate the field. In my calculation, Siesta automatically located that charge dipole layer within the slab. How can I control the position (in the z axis) of this layer, placing it within the vacuum region? The reference to the method of implementing the electric field would be helpful too. Thanks Luis
Re: [SIESTA-L] Electric field
Hello Luis, Siesta solves the Poisson equation using ffts, so the zig-zag potential due the electric field is allowed in the directions where there is vacuum. But siesta doesn't introduce a fictitious dipole charge (as far as I know). Maybe if you change the cell geometry and the values of the electric field you will be able to simulate the system you are interested in. Best, Eduardo On 11/07/2008, at 21:22, Luis Agapito wrote: Hello All, I’m applying electric field (z direction) to a slab (x-y plane). From the local potential profile, I can see that Siesta (version 2.0.1) applies a fictitious charge dipole layer to generate the field. In my calculation, Siesta automatically located that charge dipole layer within the slab. How can I control the position (in the z axis) of this layer, placing it within the vacuum region? The reference to the method of implementing the electric field would be helpful too. Thanks Luis
Re: [SIESTA-L] Ag pseudopotential
Hi, You can find the translation of abinit's pseudos into siesta psf format here: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/periodictable-intro.html Regards, Eduardo On 13/07/2008, at 14:56, Tafoughalt Mohand Akli wrote: Dear SIESTA users, I need a pseudopotential for Ag. I hope that someone among you, has already worked on Silver. and have an optimized one for Ag. thanks in advance
Re: [SIESTA-L] Memory problem when running Siesta in parallel
Hi, As the system is so small (only 1 atom) you shouldn't parallelize over bands, instead try over kpoints (diag.parallelOverK). Best, Eduardo On 02/07/2008, at 21:35, Kamaram Munira wrote: Hi, I am getting another error now * Maximum dynamic memory allocated = 1 MB siesta: === Begin CG move = 0 === outcoor: Atomic coordinates (Ang): 0.0.0. 1 Co 1 superc: Internal auxiliary supercell: 9 x 9 x 9 = 729 superc: Number of atoms, orbitals, and projectors:729 10935 11664 iodm: Reading Density Matrix from files InitMesh: MESH =30 x30 x30 = 27000 InitMesh: Mesh cutoff (required, used) = 600.000 629.128 Ry * Maximum dynamic memory allocated =42 MB forrtl: severe (41): insufficient virtual memory Image PCRoutineLineSource siesta 087E3E4B Unknown Unknown Unknown siesta 087E346B Unknown Unknown Unknown siesta 087A353E Unknown Unknown Unknown siesta 087708D4 Unknown Unknown Unknown siesta 0879066A Unknown Unknown Unknown siesta 080FF229 Unknown Unknown Unknown siesta 0816B158 Unknown Unknown Unknown siesta 0804C525 Unknown Unknown Unknown libc.so.6 0038AE23 Unknown Unknown Unknown siesta 0804C461 Unknown Unknown UnknownOn Wed, 2 Jul 2008 11:41:30 +0200 I am working on intel clusters with mpich2. I attached the necessary files. Thanks -Kam Eduardo Anglada [EMAIL PROTECTED] wrote: Hi, This error also happens with intel fortran compiler. Kamaram, could you send me a copy of the fdf and pseudos? Also I need the compilation options you used. Regards, Eduardo On 27/06/2008, at 19:18, Marcos Verissimo Alves wrote: Hm, this seems to be a complicated error. Googling malloc(): memory corruption: shows that it happens for many different softwares. Usually people make implicit that this is due to a system upgrade (when the glibc changes) and the old code is linked to an older glibc. The solution everyone gives is: rebuild your code so that it links against the new glibc. Have you upgraded your linux lately, having run the parallel version successfully before? If this is the problem, re-compiling siesta could be an option. Also, check if the compiler you have is compatible with the glibc you have. Marcos Vous avez écrit / You have written / Lei ha scritto / Você escreveu... Kamaram Munira siesta: Atomic forces (eV/Ang): *** glibc detected *** malloc(): memory corruption: 0x086d9ff8 *** Tot0.030.000.00 Max0.02 Res0.01sqrt( Sum f_i^2 / 3N ) Max0.02constrained siesta: Stress tensor (static) (eV/Ang**3): 0.0688800.000.00 0.000.0688800.00 0.000.000.074825 siesta: Pressure (static): -113.53402281 kBar siesta: Stress tensor (total) (eV/Ang**3): 0.0688800.000.00 0.000.0688800.00 0.000.000.074825 siesta: Pressure (total): -113.53402281 kBar mulliken: Atomic and Orbital Populations: Species: Au Atom Qatom Qorb 6s 6s 5dxy5dyz5dz25dxz 5dx2- y2 5dxy 5dyz5dz25dxz5dx2-y2 forrtl: error (76): Abort trap signal Image PCRoutineLineSource siesta 083CDB7F Unknown Unknown Unknown siesta 083CD19F Unknown Unknown Unknown siesta 0838D376 Unknown Unknown Unknown siesta 0835A70C Unknown Unknown Unknown siesta 0835E431 Unknown Unknown Unknown libpthread.so.000BF1888 Unknown Unknown Unknown libc.so.6 00883199 Unknown Unknown Unknown libc.so.6 008B54EA Unknown Unknown Unknown libc.so.6 008BC64C Unknown Unknown Unknown libc.so.6 008BE0B1 Unknown Unknown Unknown siesta 08300184 Unknown Unknown Unknown Stack trace terminated abnormally. Can someone tell me how to fix this? Thanks -Kam --- Kamaram Munira Graduate Research Assistant Charles Brown Department of Electrical Engineering University of Virginia Charlottesville, VA-22903. -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Unité de Physico-Chimie et de Physique des
Re: [SIESTA-L] Cobalt
Hi Marcos, Sorry, i should have answered before. Yes, it is a rule of thumb. Best, Eduardo On 25/06/2008, at 15:37, Marcos Verissimo Alves wrote: Eduardo, The confinement of about 100 Ry is a rule of thumb, or would it strongly depend on the system? Marcos Vous avez écrit / You have written / Lei ha scritto / Você escreveu... Eduardo Anglada Hi, That's the problem, there is no ultimate systematic scheme. My recommendation: Start optimizing the energyshift parameter. Once the energy is converged with respect to this parameter then you can optimize the splitnorm of the multiple zetas. For the soft confining parameters you can use a value between 100-150 Ryd for the strength and a radious which is 1.5 Bohr shorter than the first zeta. Regards, Eduardo On 19/06/2008, at 16:22, Noah, Meg A wrote: How do you determine the 'best' PAO.Basis? Thank you in advance. From: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta on behalf of Eduardo Anglada Sent: Thu 6/19/2008 9:50 AM To: SIESTA-L@listserv.uam.es Subject: Re: [SIESTA-L] Cobalt This is the best Co basis that I have used: %block PAO.Basis Co 3 0.0 n=4 0 2 E 150.0 4.5 6.5 4.5 1.0 1.0 n=4 1 1 E 100.0 4.5 6.5 1.0 n=3 2 2 E 100.0 4.5 6.5 4.5 1.0 1.0 %endBlock Pao.Basis The pseudo is attached to this message. -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Unité de Physico-Chimie et de Physique des Matériaux (PCPM) Université Catholique de Louvain 1 Place Croix du Sud, B-1348 Louvain-la-Neuve Belgique -- Gort, Klaatu barada nikto. Klaatu barada nikto. Klaatu barada nikto.
Re: [SIESTA-L] Memory problem when running Siesta in parallel
Hi, This error also happens with intel fortran compiler. Kamaram, could you send me a copy of the fdf and pseudos? Also I need the compilation options you used. Regards, Eduardo On 27/06/2008, at 19:18, Marcos Verissimo Alves wrote: Hm, this seems to be a complicated error. Googling malloc(): memory corruption: shows that it happens for many different softwares. Usually people make implicit that this is due to a system upgrade (when the glibc changes) and the old code is linked to an older glibc. The solution everyone gives is: rebuild your code so that it links against the new glibc. Have you upgraded your linux lately, having run the parallel version successfully before? If this is the problem, re-compiling siesta could be an option. Also, check if the compiler you have is compatible with the glibc you have. Marcos Vous avez écrit / You have written / Lei ha scritto / Você escreveu... Kamaram Munira siesta: Atomic forces (eV/Ang): *** glibc detected *** malloc(): memory corruption: 0x086d9ff8 *** Tot0.030.000.00 Max0.02 Res0.01sqrt( Sum f_i^2 / 3N ) Max0.02constrained siesta: Stress tensor (static) (eV/Ang**3): 0.0688800.000.00 0.000.0688800.00 0.000.000.074825 siesta: Pressure (static): -113.53402281 kBar siesta: Stress tensor (total) (eV/Ang**3): 0.0688800.000.00 0.000.0688800.00 0.000.000.074825 siesta: Pressure (total): -113.53402281 kBar mulliken: Atomic and Orbital Populations: Species: Au Atom Qatom Qorb 6s 6s 5dxy5dyz5dz25dxz5dx2- y2 5dxy 5dyz5dz25dxz5dx2-y2 forrtl: error (76): Abort trap signal Image PCRoutineLineSource siesta 083CDB7F Unknown Unknown Unknown siesta 083CD19F Unknown Unknown Unknown siesta 0838D376 Unknown Unknown Unknown siesta 0835A70C Unknown Unknown Unknown siesta 0835E431 Unknown Unknown Unknown libpthread.so.000BF1888 Unknown Unknown Unknown libc.so.6 00883199 Unknown Unknown Unknown libc.so.6 008B54EA Unknown Unknown Unknown libc.so.6 008BC64C Unknown Unknown Unknown libc.so.6 008BE0B1 Unknown Unknown Unknown siesta 08300184 Unknown Unknown Unknown Stack trace terminated abnormally. Can someone tell me how to fix this? Thanks -Kam --- Kamaram Munira Graduate Research Assistant Charles Brown Department of Electrical Engineering University of Virginia Charlottesville, VA-22903. -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Unité de Physico-Chimie et de Physique des Matériaux (PCPM) Université Catholique de Louvain 1 Place Croix du Sud, B-1348 Louvain-la-Neuve Belgique -- Gort, Klaatu barada nikto. Klaatu barada nikto. Klaatu barada nikto. Translation: Gort, Google is your friend. Google is your friend. Google is your friend.
Re: [SIESTA-L] SIC
Dear Ebrahim, I'm really sorry but it is not distributed. Regards, Eduardo On 06/06/2008, at 13:09, eb na wrote: Dear Siesta community, could anybody tell me if the SIC correction which has been implemented and reported in PRB 75, 045101, is already implemented in any Siesta distributed versions. Regards, Ebrahim Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang.
Re: [SIESTA-L] EHarris NaN error
Hi, Try to reduce the compilers optimization level, it seems to be very aggressive. Regards, Eduardo On 05/06/2008, at 11:14, Sharat Chandra wrote: Hi I am using version 2.01 with all the updates and I am trying to run CG minimization on a large system with 720 atoms (Fe, Ti and C) a single k-point over 20 nodes. SIESTA stops in the start of the 0th CG iteration itself. The error output is given below, which is same as that of the previous mails given below (Aug, 2007) (NaN for Eharris): .. .. .. siesta: k-grid: Supercell and displacements siesta: k-grid:1 0 0 0.000 siesta: k-grid:0 1 0 0.000 siesta: k-grid:0 0 1 0.000 * Maximum dynamic memory allocated = 3 MB siesta: == Begin CG move = 0 == outcell: Unit cell vectors (Ang): 20.0650000.000.00 0.00 20.0650000.00 0.000.00 20.065000 outcell: Cell vector modules (Ang) : 20.065000 20.065000 20.065000 outcell: Cell angles (23,13,12) (deg): 90. 90. 90. outcell: Cell volume (Ang**3): 8078.2538 InitMesh: MESH = 150 x 150 x 150 = 3375000 InitMesh: Mesh cutoff (required, used) = 150.000 154.456 Ry * Maximum dynamic memory allocated = 420 MB stepf: Fermi-Dirac step function siesta: Program's energy decomposition (eV): siesta: Eions =394756.861520 siesta: Ena = 10757.737201 siesta: Ekin=479459.103590 siesta: Enl = -333928.545988 siesta: DEna=-0.000218 siesta: DUscf = 0.00 siesta: DUext = 0.00 siesta: Exc = -252350.406817 siesta: eta*DQ = 0.00 siesta: Emadel = 0.00 siesta: Ekinion = 0.00 siesta: Eharris = NaN siesta: Etot= -490818.973751 siesta: FreeEng = -490818.973751 siesta: iscf Eharris(eV) E_KS(eV) FreeEng(eV) dDmax Ef(eV) siesta:1 NaN-490818.9738 -490818.9738 2.1486 -5.7582 timer: Routine,Calls,Time,% = IterSCF18360.857 87.18 elaps: Routine,Calls,Wall,% = IterSCF11534.874 95.55 p1_30945: p4_error: interrupt SIGSEGV: 11 p0_30885: p4_error: interrupt SIGSEGV: 11 p0_30885: (2604.082031) net_send: could not write to fd=4, errno = 32 Thanks. Sharat Chandra --- On Thu, 2/8/07, Sterling Paramore [EMAIL PROTECTED] wrote: From: Sterling Paramore [EMAIL PROTECTED] Subject: Re: [SIESTA-L] problem with more than 1 processor To: SIESTA-L@listserv.uam.es Date: Thursday, 2 August, 2007, 4:54 PM I've been getting the same problem with si64 test (worked fine for the h2o and h2o_orderN tests). If anyone has any ideas, I'd appreciate it too. On 7/16/07, Sen [EMAIL PROTECTED] wrote: Dear all, I am facing a problem with a parallel run with more than 1 processor, as some NaN crop up as follows: --- stepf: Fermi-Dirac step function siesta: Program's energy decomposition (eV): siesta: Eions = 632.268962 siesta: Ena = 196.529067 siesta: Ekin= 210.978067 siesta: Enl =18.109265 siesta: DEna= 0.00 siesta: DUscf = 0.00 siesta: DUext = 0.00 siesta: Exc = -97.757098 siesta: eta*DQ = 0.00 siesta: Emadel = 0.00 siesta: Ekinion = 0.00 siesta: Eharris = NaN siesta: Etot= -304.409662 siesta: FreeEng = -304.409662 siesta: iscf Eharris(eV) E_KS(eV) FreeEng(eV) dDmax Ef(eV) siesta:1 NaN -304.4097 -304.4097 NaN -2.1196 timer: Routine,Calls,Time,% = IterSCF1 14.145 81.10 elaps: Routine,Calls,Wall,% = IterSCF1 1.806 79.81 siesta: E_KS(eV) = NaN siesta: E_KS - E_eggbox = NaN However, everything goes fine with a single processor. Could you please suggest me why I am getting NaN even for 2 processors? Thanks in advance, Arijit -- Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups/bestofyahoo/
Re: [SIESTA-L] WARNING: Qtot
Dear Reza, There is a bug in siesta, it can't calculate a system with only 1 orbital ... Regards, Eduardo On 04/06/2008, at 2:28, reza behnam wrote: Dear Edan, Thank you for your advises. According to Eduardo`s and your advises I set the PAO.Basis as DZP and it worked. But why?just because in SZ for H-atom the splitting for 1s orbital has no meaning or other reasons? Regards, Reza Eduardo M. R. Benam Visiting Professor, Department of Physics and Astronomy, University of British Colombia, Vancouver, Canada. - Original Message From: Edan Scriven [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Tuesday, May 27, 2008 9:21:30 PM Subject: Re: [SIESTA-L] WARNING: Qtot Some thoughts, hope they help! I've crashed SIESTA before while trying to run calculations on one atom. I don't remember if my error was the same as yours, but my problem was that I was trying to run it on multiple cpus. The problem went away with the same input on one cpu. Take out everything from your .fdf that you don't actually need, which'll help diagnose the problem. For example, you don't need the band structure section for an isolated atom. Take out the lattice constant and let SIESTA calculate its own (it'll pick something that guarantees your basis functions fall off to zero before the cell boundary). Come to think of it, you can comment out every line from # MD options on. Once you've minimised your .fdf, you can mess around with one line at a time to find the one that's causing trouble. Try other systems a step up in complexity, e.g. water or methane, and see if your problem persists. This is also a way to test the sanity of your pseudopotentials, but won't help you with the one atom, multiple cpus thing. Good luck! Edan.
Re: [SIESTA-L] compile error of parallel version
Hi, You have to use mpiifort for blacs, scalapack and siesta. Regards, Eduardo / On 28/05/2008, at 15:32, Chol-Jun Yu wrote: Dear Eduardo, I used mpif77 as compiler for blacs and scalapack, and mpiifort for siesta, which you can see in attaches. Still the undefined ... borders me. Could you give me again comments? With kind regards, Chol-Jun Eduardo Anglada wrote: Hi, You compiled blacs and scalapack with gfortran or g77, while siesta was compiled with ifort (intel fortran). You shouldn't mix compilers. Regards, Eduardo On 28/05/2008, at 9:11, Chol-Jun Yu wrote: Hello, during the compilation of parallel version, the following errors were appeared, ... cdiag.o: In function `cdiag': /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:234: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:235: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:243: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:244: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:246: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:321: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/cdiag.F:325: undefined reference to `blacs_gridinfo_' rdiag.o: In function `rdiag': /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:226: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:227: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:235: undefined reference to `blacs_get_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:236: undefined reference to `blacs_gridinit_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:238: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:304: undefined reference to `blacs_gridinfo_' /rwthfs/rz/cluster/home/cy849828/siesta-2.0.1/Src/rdiag.F:306: undefined reference to `blacs_gridinfo_' /home/cy849828/scalapack-1.8.0/libscalapack.a(pxerbla.o): In function `pxerbla_': pxerbla.f:(.text+0x3c): undefined reference to `s_wsfe' pxerbla.f:(.text+0x52): undefined reference to `do_fio' pxerbla.f:(.text+0x68): undefined reference to `do_fio' pxerbla.f:(.text+0x79): undefined reference to `do_fio' pxerbla.f:(.text+0x8d): undefined reference to `do_fio' pxerbla.f:(.text+0x94): undefined reference to `e_wsfe' /home/cy849828/scalapack-1.8.0/libscalapack.a(pdgemr.o): In function `Cpdgemr2do': ... I have attached the arch.make file. Any comment will be thankful. Chol-Jun -- Chol-Jun Yu Computational Materials Engineering (CME) Institute of Minerals Engineering (GHI) Center for Computational Engineering Science (CCES) RWTH Aachen University (RWTH) Jülich-Aachen Research Alliance (JARA) D-52064 Aachen, Mauerstrasse 5, Tel: +49-241-8094989 Fax: +49-241-80695097 # # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez- Portal # and J.M.Soler, 1996-2006. # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--Intel FPP= FPP_OUTPUT= FC=mpiifort RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS= ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLAS_LIBS=-lblas LAPACK_LIBS=-llapack BLACS_LIBS=/home/cy849828/BLACS/LIB/blacs_MPI-LINUX-0.a SCALAPACK_LIBS=/home/cy849828/scalapack-1.8.0/libscalapack.a COMP_LIBS=dc_lapack.a NETCDF_LIBS= NETCDF_INTERFACE= LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $ (NETCDF_LIBS) #SIESTA needs an F90 interface to MPI #This will give you SIESTA's own implementation #If your compiler vendor offers an alternative, you may change #to it here. MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=. #Dependency rules are created by autoconf according to whether #discrete preprocessing is necessary or not. .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $ .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $ .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $ .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $ -- Chol-Jun Yu Computational Materials Engineering (CME) Institute of Minerals Engineering (GHI) Center for Computational Engineering Science (CCES) RWTH Aachen University (RWTH) Jülich-Aachen Research Alliance (JARA) D-52064 Aachen, Mauerstrasse 5, Tel: +49-241-8094989 Fax: +49-241
Re: [SIESTA-L] ghost atoms: labels
Dear Andrei, Siesta uses the species number in order to identify the different species, there is no subrutine which lets you identify a species by it's label so it's quite safe to use the same label for several species. But it can be very error prone, so I recommend to have different labels for different species. Regards, Eduardo On 28/05/2008, at 17:15, [EMAIL PROTECTED] wrote: Dear Siesta users, I have a specific question concerning introducing ghost atoms. As we add them, we add new species whose Z values are negative. What about the labels of these species: should we better use new ones (that means we'll need pseudopot files with these new labels, and new entries in the PAO.basis block), or would it be safe to allow real and ghost atoms to share the same labels? I see that the corresponding calculation goes on without changing the labels, so that obviously every species is identified by its species number, so that the non-uniqueness of labels is not prohibited. I just wonder whether this might be potentially dangerous (like, something is identified by its label and not species number). Thanks, Andrei Postnikov
Re: [SIESTA-L] negative value for MESH
Dear Swaroop, Which are the values of the mesh in the previous CG steps? Are they very different? Maybe we can guess what is going on. Regards, Eduardo On 23/05/2008, at 14:24, M.Sairam Swaroop wrote: Dear Eduardo We have compiled siesta with a 64 bit compiler and we have allowed for a variable cell CG minimization. siesta was able to diagonalize the hamiltonian in the first CG step. We need these many k-points due to the periodicity in the system. Are there any issues with variable cell calculations and mesh rebuilding. please do help us out. If there are any other inputs that i should provide then please so let me know. regards swaroop
Re: [SIESTA-L] negative value for MESH
Clearly there is something wrong going on. Can you send me (privately) the hole output (including the output files with coordinates and cell) Best, Eduardo On 23/05/2008, at 18:26, M.Sairam Swaroop wrote: Dear Eduardo After you mentioned i noticed tha the mesh does not change ... i have grepped the InitMesh: MESH = from my output file and here is the output InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH = 180 x 160 x 384 =11059200 InitMesh: MESH =153600 x145800 x182250 = -1886683136 I really do not understand what is going on ... another anamoly that i see is that i have supplied the following lattice vectors as the input block LatticeVectors 14.9828910.0006800.015378 0.000589 12.947787 -0.003033 0.031384 -0.007147 30.441943 %endblock LatticeVectors but for CG =0 i get the following in the output file outcell: Unit cell vectors (Ang): 14.700.000.00 0.00 12.7305800.00 0.000.00 30.00 I notice that the job crashed when the cell vector became more then the input specified ie grep outcell: Cell vector modules (Ang) : *.out outcell: Cell vector modules (Ang) : 14.70 12.730580 30.00 outcell: Cell vector modules (Ang) : 14.917065 12.920354 30.024935 outcell: Cell vector modules (Ang) : 14.905544 12.910281 30.023611 outcell: Cell vector modules (Ang) : 14.919716 12.900398 30.139252 outcell: Cell vector modules (Ang) : 14.942395 12.884584 30.324281 outcell: Cell vector modules (Ang) : 14.928030 12.894601 30.207079 outcell: Cell vector modules (Ang) : 14.801968 13.042322 30.402947 outcell: Cell vector modules (Ang) : 14.896749 12.931255 30.255680 outcell: Cell vector modules (Ang) : 14.904436 12.918676 30.309642 outcell: Cell vector modules (Ang) : 14.916736 12.898548 30.395983 outcell: Cell vector modules (Ang) : 14.908514 12.912003 30.338265 outcell: Cell vector modules (Ang) : 14.982899 12.947787 30.441960 Could you help me out with what is going on here. regards swaroop
Re: [SIESTA-L] Total energy vs. Energy Shift convergence
Dear Roberto, Maybe what you are seeing is the rippling of the energy/forces due to the aliasing (wrap around errors) of the fft. The orbitals (squared) and neutral atom potential are projected into the grid so if you change them this error can introduce noise in the convergence of the total energy/forces. The neutral atom potential of carbon usually is very hard in reciprocal space, so you have to increase a lot the mesh cutoff. You could try with a mesh cutoff which is twice as big as the one you are using right now. Best, Eduardo On 15/05/2008, at 15:04, Roberto Sapiens wrote: Hi: I've been doing some calculations on graphene ribbons and got interested in knowing how the total energy converges as the energy shift varies. I had an assumption that the smaller the energy shift the lower the total energy, which I confirmed doing such a calculation for small molecules and isolated atoms. On the other hand, I found, for the ribbon (a 1D periodic system), that the minimum for the total energy occurs for an energy shift around 0.05 eV. Why such a difference? With my best regards, Roberto
Re: [SIESTA-L] Regarding some error in optical properties
On 21/05/2008, at 12:53, Subhra Kulshrestha wrote: Dear Users, I have computed the optical properties of Si by using two program input.f and optical.f in the directory siesta-2.0.1/Util/Optical and the program is successfully run for Si but as I run the calculation for LaAs the file e2.dat successfully generated but when everytime when I type the command$./optical e2.dat it is showing the error as follows Do you want to include a Drude term? This is typically needed for metals if yes: enter 1, if no: enter 0 What did you answer, 0 or 1? invalid integer: read unexpected character apparent state: unit 5 (unnamed) last format: list io lately reading direct formatted external IO Aborted Please guide me where I have done a mistake ? My .fdf file is as follows SystemName LaAs SystemLabel LaAs NumberOfAtoms 2 NumberOfSpecies 2 %block ChemicalSpeciesLabel 1 57La 2 33As %endblock ChemicalSpeciesLabel PAO.BasisType split PAO.BasisSize DZP PAO.EnergyShift 0.1eV PAO.SplitNorm 0.2000 %block PAO.Basis # Define Basis set La 2# Species label, number of l-shells n=6 0 2 P 1 # n, l, Nzeta, Polarization, NzetaPol 0.000 0.000 1.000 1.000 n=5 2 2 # n, l, Nzeta 0.000 0.000 1.000 1.000 As 2# Species label, number of l-shells n=4 0 2 P 1 # n, l, Nzeta, Polarization, NzetaPol 0.000 0.000 1.000 1.000 n=4 1 2 # n, l, Nzeta 0.000 0.000 1.000 1.000 %endblock PAO.Basis LatticeConstant 6.124 Ang %block LatticeVectors 0.0 0.50.5 0.5 0.00.5 0.5 0.50.0 %endblock LatticeVectors %block GeometryConstraints routine constr %endblock GeometryConstraints MeshCutoff112.0 Ry # SCF options MaxSCFIterations100 # Maximum number of SCF iter DM.MixingWeight 0.3 # New DM amount for next SCF cycle DM.Tolerance 1.d-4 # Tolerance in maximum difference DM.NumberPulay 8 # Number of pulay mixing steps DM.UseSaveDM .false. # tells if already existing density matrix is to be used or not OpticalCalculation .true. Optical.EnergyMaximum 10 Ry %block Optical.Mesh 10 10 10 %endblock Optical.Mesh Optical..Broaden 0.02 Ry Optical.PolarizationType Polycrstal %block Optical.Vector 1.0 1.0 0.0 %block Optical.Vector WriteCoorXmol WriteMullikenPop 1 WriteForces .true. ElectronicTemperature30 meV xc.functionalLDA xc..authors CA # WriteCoorStep.true. #AtomCoorFormatOut Ang SolutionMethod Diagon# OrderN or Diagon AtomicCoordinatesFormat Fractional %block AtomicCoordinatesAndAtomicSpecies 0. 0. 0. 1 0.5000 0.5000 0.5000 2 %endblock AtomicCoordinatesAndAtomicSpecies MD.TypeOfRun CG # Type of dynamics: MD.NumCGsteps 580 # Number of CG steps for MD.MaxCGDispl 0.4Ang # Maximum atomic displacement MD.MaxForceTol0.01 eV/Ang # Tolerance in the maximum MD.MaxStressTol 0.1 GPa MD.VariableCell .true. %block kgrid_Monkhorst_Pack 8000.0 0800.0 0080.0 %endblock kgrid_Monkhorst_Pack %block ProjectedDensityOfStates -20.00 10.00 0.2 500 eV %endblock ProjectedDensityOfStates WriteKpoints ..true. WriteEigenvalues .true. WriteKbands .true. WriteBands .true. %block BandLines 1 1.00 1.00 1.00 L 25 2.00 2.00 2.00 \Gamma 25 2.00 0.00 0.00 X 25 2.00 1.00 0.00 W 25 1..00 1.00 1.00 L 25 1.00 1.00 0.00 K 25 0.00 0.00 0.00 \Gamma %endblock BandLines Thanks and Regards, Subhra Kulshrestha Project Fellow (UGC), Condensed MatterTheory Group School of Studies in Physics Jiwaji University, GWALIOR - 474011 (M.P.), INDIA Chocoholics' paradise! Enter here.
Re: [SIESTA-L] Wrong Results with pathscale compiler
Dear Philipp, Currently we are working with pathscale for a solution of your problem. Once we know how to compile siesta with the latest version of the pathscale compilers I will provide the arch.make. For the other versions of pathscale compiler use the arch.make provided by Pablo Aguado. Best regards, Eduardo On 09/05/2008, at 9:46, Dipl.-Phys. Philipp Plänitz wrote: # # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal # and J.M.Soler, 1996-2006. # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # MPIdir = /opt/mpi/path/mpich2-1.0.6p1 .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--unknown FPP= FPP_OUTPUT= FC=$(MPIdir)/bin/mpif90 RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g -Wl,-R/opt/compiler/pathscale/lib/3.1 #FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DCDF FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS=-static -m64 -ipa ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLACSdir = /opt/applications/blacs/BLACS_pathf90_mpich2-1.0.6p1/ LIB BLAS_LIBS=/opt/math/acml-4.0.1-pathscale/lib/libacml.a #LAPACK_LIBS=/opt/math/acml-4.0.1-pathscale/lib/libacml.a BLACS_LIBS=$(BLACSdir)/blacsCinit_MPI-LINUX-0.a $(BLACSdir)/blacsF77init_MPI-LINUX-0.a $(BLACSdir)/blacs_MPI-LINUX-0.a SCALAPACK_LIBS=/opt/applications/scalapack/scalapack-1.8.0_path- mpich2-1.0.6p1-acml/libscalapack.a #COMP_LIBS=libnetcdf_f90.a #NETCDF_LIBS=/usr/lib/libnetcdf.a LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $(NETCDF_LIBS) #SIESTA needs an F90 interface to MPI #This will give you SIESTA's own implementation #If your compiler vendor offers an alternative, you may change #to it here. #MPI_INTERFACE=/opt/mpi/path/mpich2-1.0.6p1/lib/libmpi_f90.a MPI_INTERFACE=libmpi_f90.a #MPI_INTERFACE=MPI/Interfaces.o MPI_INCLUDE=/opt/mpi/path/mpich2-1.0.6p1/src/include/ #Dependency rules are created by autoconf according to whether #discrete preprocessing is necessary or not. .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $ .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $ .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $ .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $ --- GWT-TUD GmbH - Geschäftsstelle Chemnitz Projektgruppe Materialberechnungen Annaberger Straße 240 09125 Chemnitz Telefon: 0371 5347591 Email:[EMAIL PROTECTED] Internet: http://www.matcalc.de Geschäftsführer: Dr. Reinhard Kretzschmar, Reinhard Sturm Die GWT-TUD GmbH ist eingetragen beim Amtsgericht Dresden - HRB: 13 840
Re: [SIESTA-L] Convergence test for the mesh cut-off and k-point
Hi, For the mesh cutoff change the meshcutoff variable from the default of 100 Ry to 500 in steps of 100 Ry, if the energy converges (also take a look at the forces) you are done with the grid. If it is not converged you should continue increasing the mesh cutoff. If you reach a very huge value (800-1000 Ry) then you should take a look at your orbitals, neutral atom potential and non linear core corrections (if exist in your pseudo). Their FFT should give you a hint of the grid, as the energy/ forces don't converge because of their wrap around errors (FFT aliasing). Remember that the square of the orbitals is what is projected into the grid. For the k-points I recommend that you use the kgrid_cutoff described in Moreno and Soler PRB 45, 13891 (1992). It will calculate the best k-grid for the symmetry of your system. Start from some small value (around 2-3 Bohr) and continue increasing it until the energy is converged (or the calculation takes so much time that is not feasible). Best regards, Eduardo On 07/05/2008, at 8:52, Nidhi Sharma wrote: Hi to all, Will anybody please guide me how to perform the convergence test for mesh-cut-off and k-point (Mohnkorst-Pack scheme)? For this what changes should make in the .fdf file ? Thanks, Nidhi Bring your gang together. Do your thing. Find your favourite Yahoo! Group.
Re: [SIESTA-L] determining Fermi energy
I'm sorry, I should have answered before!
I think that your pseudocode is right. That is
what siesta does in order to obtain the position of the
Fermi level.
Best regards,
Eduardo
On 02/05/2008, at 20:03, David Strubbe wrote:
Ebrahim,
No I never received any response, but I recently examined the code
in fermid.F to find out what is going on. As far as I can tell,
SIESTA definitely puts the Fermi energy in the gap, but the position
inside the gap is not meaningful. The algorithm to find the Fermi
energy is like this in pseudocode:
E = (highest energy level + lowest energy level) / 2;
do
{
Q = sum of occupancies of energy levels less than E
if Q Qtot : E = (E + highest energy level) / 2;
if Q Qtot : E = (E + lowest energy level) / 2;
} while (Q != Qtot);
Fermi energy = E.
Anywhere in the gap, assuming the electronic temperature isn't very
high, will give the same Q. So where the Fermi level ends up is
just determined by where the highest and lowest energy bands are,
and hence which energy in the gap is tried first. There is no
physical meaning to the position of the Fermi energy within the gap
in SIESTA.
If I have misunderstood anything here, please correct me, developers.
David Strubbe
UC Berkeley
On Fri, May 2, 2008 at 2:31 AM, eb na [EMAIL PROTECTED] wrote:
Hi David,
I'm interested to know if you have got any answer to your question.
I have the same problem.
other codes like ABINIT put the Fermi energy simply at the valence
band edge but in Siesta it has a value within the gap!
I wounder how the DFT could give any information of the exact value
of the Fermi energy?
looking forward to hear from you
regards,
Ebrahim Nadimi
TU Chemnitz, Germany
David Strubbe [EMAIL PROTECTED] schrieb:
Hello all,
Can someone tell me how SIESTA determines the Fermi energy for a
system with a gap?
David Strubbe
UC Berkeley
Beginnen Sie den Tag mit den neuesten Nachrichten. Machen Sie Yahoo!
zu Ihrer Startseite!
Re: [SIESTA-L] Overestimation of optimized lattice constant for SmTe
On 03/05/2008, at 12:39, Nidhi Sharma wrote: Hi to all, I am trying to compute the energy for different lattice constant to get the E vs V graph (in B1 phase of Smte using LDA). For this I have selected the range from 5.5 to 7.5 Ang in steps of 0.05. After Murnaghan fit optimize lattice consatnt comes out to be 6.87 Ang (Expt =6.594 Ang) and bulk modulus 38.3 GPa. (Expt = 40 GPa). I have also changed the different step size and the range but every time the optimized lattice constant is overestimated. Is it worth using this data for calculation ? Is it possible that some times lattice constant overestimates the experimental value ? Yes, definitively is possible! If I were you I would check with another basis set (smaller eshift, different split norm) and with a GGA functional. Regards, Eduardo If not then please guide us where I am wrong ? Regards, Nidhi Best Jokes, Best Friends, Best Food. Get all this and more on Best of Yahoo! Groups.smte.fdf
Re: [SIESTA-L] multiple-zeta
Hi, If you are using the latest version of siesta you should use another diagonalization scheme. Try changing the following options (they are fdf booleans: .true. or .false. )in your fdf: Diag.AllInOne(default false, change to true) DivideConquer (default true, change to false) Diag.NoExpert (default false, change to true) Cheers, Eduardo On 05/05/2008, at 10:36, Alexandre Lebon wrote: Dear Siesta Users, I got the following error message: siesta: == Begin CG move = 0 == outcoor: Atomic coordinates (Ang): -2.53300.0. 1 Fe 1 1.64000.0. 2 H 2 0.0.0. 1 Fe 3 outcell: Unit cell vectors (Ang): 15.000.000.00 0.00 15.000.00 0.000.00 15.00 outcell: Cell vector modules (Ang) : 15.00 15.00 15.00 outcell: Cell angles (23,13,12) (deg): 90. 90. 90. outcell: Cell volume (Ang**3): 3375. InitMesh: MESH = 180 x 180 x 180 = 5832000 InitMesh: Mesh cutoff (required, used) = 350.000 397.983 Ry * Maximum dynamic memory allocated = 345 MB Error in Cholesky factorisation in rdiag Stopping Program from Node:0 PS: Read file FeFeH_axial.error for stderr output of this job. With the fdf file, that I have attached to this e-mail. Is any one has met the same problem or know how to solve it. Thanks in advance, Alexandre fehfe.fdf
Re: [SIESTA-L] cell optimization with fixed angles
Hi, Yes it is possible, but you should write your own constraint subroutine. Take a look at the example in Src/constr.f Regards Eduardo On 06/05/2008, at 10:52, eb na wrote: Hello dear Siesta community, How can I optimize the atomic coordinates and cell sizes while keeping the cell angles constant. Is this feature already implemented in Siesta ? Best regards, Ebrahim Nadimi Lesen Sie Ihre E-Mails jetzt einfach von unterwegs..
Re: [SIESTA-L] Pseudopotential and basis for Co
Hi Ali, In the webpage there are LDA GGA pseudos, but I have no basis sets. http://www.uam.es/departamentos/ciencias/fismateriac/siesta/periodictable-intro.html Regards, Eduardo
Re: [SIESTA-L] Bromine pseudo
Hi Roberto, I attach the output of Bromine pseudo generation using the Fritz Habber Institute (fhi) code. The input was taken from Abinit's LDA/GGA databases. The translation of the output of fhi to siesta leads to ghost states (siesta uses a different definition of the local part of the pseudo) but most probably you can use the radii as an initial guess. Good luck, Eduardo Br-GGA.out Description: Binary data Br-LDA.out Description: Binary data On 15/04/2008, at 14:44, Roberto Sapiens wrote: Has anyone generated a pseudo for bromine? Regards, Roberto
Re: [SIESTA-L] Converging a cluster of Ni Atoms
Hi, Why are you using the split gauss option? Have you checked the resulting gaussians? Do they decay to zero? Regarding the convergence, if the Harris Energy is converged, you could try to stop the calculation and restart it (reading the coordinates and density matrix). It many situations this speeds up a lot the convergence. The method is not very scientific but usually, when Harris energy is converged, works. Regards, Eduardo On 13/04/2008, at 19:01, Kamaram Munira wrote: I have a cluster of 105 Nickel atoms. I am having trouble converging the DM. The dMax converges to around 0.02 to 0.03 range and just stays in that range. I don't know how to reach dMax of 10e-4 Here is what I am doing DM.UseSaveDM .true. DM.MixingWeight 0.001 MaxSCFIterations 50 DM.NumberPulay 8# this one wouldn't help for the first CG steps DM.NumberKick 40 DM.KickMixingWeight 0.1 WriteCoorXmol .true. #DM.MixSCF1 .true. Diag.DivideAndConquer false PAO.BasisType splitgauss PAO.BasisSize DZ xc.functional LDA # Exchange-correlation functional xc.authors CA# Exchange-correlation version MeshCutoff 225 Ry. Any help would be much appreciated. Thanks -Kamaram --- Kamaram Munira Graduate Research Assistant University of Virginia Charlottesville, VA-22903.
Re: [SIESTA-L] Is there a psf for La
Hi! This message is not related to the pseudo of La! So please use a new subject line Can we see the arch.make? It contains all the compiler, libraries related stuff Regards, Eduardo On 10/04/2008, at 14:13, Pablo A. Denis wrote: Dear Siesta user, I have recently installed Ubuntu 7.1 on a core 2 duo machine. I would like to know if somebody has installed siesta on it? I have been able to install ifort and mkl but when I try to compile the atom program or siesta the congifure.log tells me that he cannot created the executable variables. I have installed all the packages recommended at the ubuntu site (g+ + build essential, 32bit libs etc.). So I guess that the problem may be related with the bash.bahsrc (I have added the path of ifort and mkl to the bash.bashrc and .bashrc) Any cluet? Many thanks! Pablo
Re: [SIESTA-L] Valence configuration of samarium
1.000 n=5 1 2 # n, l, Nzeta 0.000 0.000 1.000 1.000 %endblock PAO.Basis Your Te might be OK (or not); at least no obvious faults. it will display the following message reinit: reinit: System Label: SmTe --- initatom: Reading input for the pseudopotentials and atomic orbitals -- Species number: 1 Label: Sm Atomic number: 62 Species number: 2 Label: Te Atomic number: 52 Ground state valence configuration: 6s02 4f06 Reading pseudopotential information in formatted form from Sm.psf Ground state valence configuration: 5s02 5p04 Reading pseudopotential information in formatted form from Te.psf Bad format of (n), l, nzeta line in PAO.Basis Stopping Program from Node: 0 This is probably because you promised 2 functions in the basis block for Sm but passed only one (6s). Make it consistent. If I include the 4f6 in basis set it will make the net charge 8 and behave as a semi core. This net charge is not exactly your worry. It simply gives you the number of electrons provided by the atom in question to the valence band, in does not yet make from Sm a 8+ ion. Similarly, you can choose the Te configuration either as 5s2 5p4 5d0 (6 valence electrons) or 5s2 5p4 4d10 (16 valence electrons), it is still the same atom. Only, you'll have different number of bands. I repeate, the decision to put Sm 4f in the core or in the valence is only your - difficult, but free - choice. Now we come to Te. If I use a already generated pseudo file of Te which include 5s2, 5p4, 4d0 and 4f0 But how can 4d0 is possible although it contains 10 electrons. This is a misprint in the head line of the Te pseudo. It was generated with 4d10 in the core and 5d as valence states. (Ask Eduardo Anglada). When I use this file then we get results but band gap in B1 phase is ~10eV which is quite far from the expt 0.67eV. This can be due to anything. (In fact an absence of Sm5d in the basis is a good candidate). Try to look not only at the band gap value (which will be wrong anyway) but at the density of states, positioning of different groups of valence bands. The band structure of RE chalcogenides is well known. Please help me how can i resolve the problem of valence charge . I don't see there is a problem, in fact. The (technical) problem is - if you want to remove 4f from the valence - how to declare them as core, even as this shell is not fully occupied. But by default, you can go ahead with 4f as valence states (in BOTH basis and pseudopotential). Then you'll see that the positioning of the 4f is wrong, and start to think how bad this is for the problem your have to solve, and what to do about it. This is not a SIESTA problem, but one which appeared before in other DFT calculations. Good luck, Andrei Postnikov Share files, take polls, and make new friends - all under one roof. Click here.
Re: [SIESTA-L] ANNOUNCE: LDA GGA pseudo databases
Dear users, I've uploaded the new version of the database. Now each pseudo has it's own web page with info about the matching radii, occupations, plots of the pseudos, and, if present the core charge density with its corresponding radius. As always any comments/suggestions are really welcome. Best, Eduardo On 12/03/2008, at 18:22, Eduardo Anglada wrote: Dear Users of Siesta, There is a new collection of pseudopotentials available for SIESTA! I have translated the LDA/GGA pseudos in the Fritz-Haber-Instute (FHI) format of ABINIT's database found in http://www.abinit.org/Psps/?text=psps so now they can be used with SIESTA. The database can be found In the siesta web page: http://www.uam.es/siesta Follow the link Pseudos Basis in the left menu. I would like to thank the ABINIT team for sharing their pseudos with the community. If you encounter any problems feel free to post them in the list. Best regards, Eduardo
[SIESTA-L] Mailing list archives
Dear Users of Siesta, There is a new interface to the archives of this mailing list: http://www.mail-archive.com/siesta-l@listserv.uam.es/ It's much more easier to use than the current version and it is english. The siesta team would like to thank the www.mail-archive.com for storing all the messages. Regards, Eduardo
Re: [SIESTA-L] Mailing list archives
On 02/04/2008, at 15:37, lan haiping wrote: should we subscribe to it again ? No, it is a copy of all the previous messages. Now it is easier to look for useful info, the search feature is much more useful. Eduardo Best On Wed, Apr 2, 2008 at 12:47 PM, Eduardo Anglada [EMAIL PROTECTED] wrote: Dear Users of Siesta, There is a new interface to the archives of this mailing list: http://www.mail-archive.com/siesta-l@listserv.uam.es/ It's much more easier to use than the current version and it is english. The siesta team would like to thank the www.mail-archive.com for storing all the messages. Regards, Eduardo -- Hai-Ping Lan Department of Electronics , Peking University , Bejing, 100871 [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [SIESTA-L] Geometry Optimization
Hi, You should specify: MD.TypeOfRun CG (conjugate gradients relaxation) MD.NumCGSteps 100 (a maximum of 100 steps will be calculated. Of course if the forces are relaxed before the 100 steps are calculated then siesta will stop) The relavant section of the manual is: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/manual-2.0/node20.html Regards Eduardo On 27/03/2008, at 18:00, Sanjay Bidasaria wrote: Hi all, I am a new user of Siesta and started with the test examples. So I am working with a Niobium Dimer and trying to find the relaxed coordinates of the atoms. But it is just giving me the input coordinates only. I don't know what parameters to change for the relaxation. Thanks. Sanjay. Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Re: [SIESTA-L] regarding problem
Dear Sonia, It is discribed in: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/manual-2.0/node23.html Regards, Eduardo On 01/04/2008, at 13:21, Sonia Mehra wrote: der siesta users, Can anyone tell me that how to control the bandlines i.e. what type of changes can be done in*.fdf file to get the proper bandstructure 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here.
Re: [SIESTA-L] hello
Dear Sonia, There are several talks in: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/tutorials.html (you can find the talks and the exercises) which describe siesta basis sets. Also maybe you can post which is the element you are interested in. Regards, Eduardo On 28/03/2008, at 11:45, Sonia Mehra wrote: Dear Siesta users, Can anyone tell m e how to generate the basis set? how to write all type of specifications in that like polarisation. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [SIESTA-L] ANNOUNCE: LDA GGA pseudo databases
Dear Reza, It's a typo error, you can safely add the 7 electrons, the pseudo was calculated with them. Regards, Eduardo On 25/03/2008, at 18:45, reza behnam wrote: Dear Eduardo, Thank you for for your reply. In fact I made a mistake in downloading Co and i could download it, but the number of 3d electrons in the Psf file was zero (3d 00.00). Is this a problem? Can I simply add 7 electrons to 3d orbital of the downloaded psf file? Thanks, Reza - Original Message From: Eduardo Anglada [EMAIL PROTECTED] To: SIESTA-L@listserv.uam.es Sent: Tuesday, March 25, 2008 5:15:33 AM Subject: Re: [SIESTA-L] ANNOUNCE: LDA GGA pseudo databases Dear Reza, Which one did you download? Best, Eduardo Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [SIESTA-L] ANNOUNCE: LDA GGA pseudo databases
Dear Reza, Which one did you download? Best, Eduardo
Re: [SIESTA-L] Species not found error message - Parallel siesta.
Hi, Maybe the line with the number of spices is missing? post your input so we can take a look. Regards Eduardo On 15/03/2008, at 15:00, Kamaram Munira wrote: I have successfully run Siesta in serial mode till now. Recently, I am trying to run the parallel version and I get a error message that Species not found even though I have the Chemical and Species Block in my fdf file. I know I am getting the error from Chemical.f file. How do I go about fixing it. Any help would be much appreciated. Thanks -Kamaram --- Kamaram Munira Graduate Research Assistant University of Virginia Charlottesville, VA-22903.
Re: [SIESTA-L] pseudo database; Zn configuration
Dear Andrei, On 13/03/2008, at 20:36, Andrei Postnikov wrote: Many thanks for Eduardo Anglada for uploading the ABINIT pseudos! Just two related questions: 1. Does somebody know whether there s a way to see from the .psf file if the core correction is included, and with which radius? Just now there is no way, but I have all the info, of course you can ask for it. Please use the mailing list as it may be useful for someone else. I'm extending the info on the databases so it will be available. 2. I just noticed by chance that the configuration line in the .psf for Zn 4s 2.00 r= 2.43/4p 0.00 r= 2.37/3d 0.00 r= 2.09/4f 0.00 r= 2.82/ (in both LDA and GGA) is somehow contradictory, as it should be either 3d10 (in the real world), or 4d0 (in the ideal one). The configurations given for Cd and Hg do correctly contain 4d10.0 and 5d10.0, respectively. I tested the Zn pseudopot with the radii as given above, and 3d10.0; in fact it is quite good. What is the origin of the above misprint? Can it be corrected? That is a typo error! I'm working on it. I'm really sorry. Best regards, Eduardo
[SIESTA-L] ANNOUNCE: LDA GGA pseudo databases
Dear Users of Siesta, There is a new collection of pseudopotentials available for SIESTA! I have translated the LDA/GGA pseudos in the Fritz-Haber-Instute (FHI) format of ABINIT's database found in http://www.abinit.org/Psps/?text=psps so now they can be used with SIESTA. The database can be found In the siesta web page: http://www.uam.es/siesta Follow the link Pseudos Basis in the left menu. I would like to thank the ABINIT team for sharing their pseudos with the community. If you encounter any problems feel free to post them in the list. Best regards, Eduardo
Re: [SIESTA-L] Error in compiling( libfdf.a module could not be located, perhaps)
Hi, Your system lacks the basic development utils needed to build a library. Search the documentation and install them. Regards, Eduardo On 01/02/2008, at 12:58, vikas sharma wrote: I get the following error when run the make command in Src directory. (cd fdf ; make module) ar cru libfdf.a fdf.o fdf_mod.o parse.o sh: ar: not found *** Error code 1 make: Fatal error: Command failed for target `libfdf.a` Current working directory /~/Src/fdf *** Error code 1 make: Fatal error: Command failed for target 'libfdf.a' Kindly help me to resolve this problem. Regards, Vikas Sharma, Research Scholar, Physics Department, IIT Delhi, New Delhi-16, India. Why delete messages? Unlimited storage is just a click away.
Re: [SIESTA-L] Oxygen (triplet)
Hi Roberto, I think your only option is to use the DM.InitSpinAF and DM.InitSpin block. Take a look at the manual in: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/ manual-2.0/node18.html#2854 Regards, Eduardo On 09/10/2007, at 22:03, Roberto Veiga wrote: Hi: I'm gonna do some spin polarized calculations in which molecular oxygen is adsorbed onto a surface. I'd like to know how to represent triplet oxygen (as initial state) in the Siesta's input. Regards, Roberto -- If I have seen farther than others it is because of a myopia surgery.
Re: [SIESTA-L] How to visualize mesh points and potential on the mesh?
Dear Jingbin, The wsxm software reads directly any output of siesta. It's designed for the RHO and LDOS, but the format is the same for all the output of siesta, maybe you have to rename the other files. wsxm is free and can be found in: http://www.nanotec.es/ It only works in MS-windows. In linux/mac you have to use a tool which converts the output to another format. In the utils subdir you can find the grid2cube.f program which translates siesta output to the cube format, which is understood by many visualizers. Regards, Eduardo On 08/10/2007, at 21:33, Jingbin Li wrote: Dear Siesta users, I am wondering if there is a tool that can visualize siesta space mesh? Or the potential on the 3D mesh points(say rectangular mesh). If not directly, which file should I look into to find the related information? Thanks. Any suggestions are welcomed. Best, Jingbin
Re: [SIESTA-L] How to calculate band-structure in SIESTA
Hi, Siesta is different and I think more powerful: you obtain the bands in a single run. The calculation is performed with the desired accuracy (you specify the k-sampling with the MonkhorstPack block or the kgrid_cutoff parameter) and at the end of the calculation if there is a BandLines block siesta saves the requested bands. The relevant section of the manual can be found in: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/ manual-2.0/node17.html Look for the BandLines block. Regards, Eduardo On 08/10/2007, at 15:24, Hui Tang wrote: Hi, Can anyone tell me the correct way to do band structure in SIESTA? In other plane-wave codes (like PWSCF), the band-structure is calculated from a non-selfconsistent calculation using a converged charge density from a previous selfconsistent calculation. I wonder if it's the same case for SIESTA. I didn't find any relevant information on non-selfconsistent calculation with SIESTA. Any help is appreciated! Thanks, --- Hui Tang Dept. of Applied Physics Yale University
[SIESTA-L] How to define a ion?
Begin forwarded message: From: Eduardo Anglada [EMAIL PROTECTED] Date: 8 de octubre de 2007 11:16:41 GMT+02:00 To: Edgar Martinez Guerra [EMAIL PROTECTED] Subject: Re: [SIESTA-L] How to define a ion? Dear Egar, You should create a new pseudo. In the basis block you control the size of the basis set. Regards, Eduardo On 07/10/2007, at 2:42, Edgar Martinez Guerra wrote: For all users of SIESTA: I want to calculate a system which one of its atoms is a ion. What is the correct?, to specify it on basis block or modify the pseudo of the ion? or both thing? I would thank you any help. Edgar Martinez Message sent using Telaen Webmail 1.2.0-beta1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [SIESTA-L] potential
Hi! remove the -L infront of the library path: ifort plrho.f -L/usr/X11R6/lib/libX11.a /share/apps/pgplot/ libpgplot.a -o plrho If the pglopt library was not compiled with ifort then you should include the other compiler libraries. Regards, Eduardo On 30/06/2007, at 8:51, Cherry Y. Yates wrote: finally I downloaded a pgplot, compiled and installed it. Then I used the following commamd: ifort plrho.f -L/usr/X11R6/lib/libX11.a -L/share/apps/pgplot/ libpgplot.a -o plrho but I got the following errors: /tmp/ifortRI8dCZ.o(.text+0xc9a): In function `MAIN__': : undefined reference to `pgopen_' /tmp/ifortRI8dCZ.o(.text+0xcb9): In function `MAIN__': : undefined reference to `pgqcol_' /tmp/ifortRI8dCZ.o(.text+0xcd0): In function `MAIN__': : undefined reference to `pgscir_' /tmp/ifortRI8dCZ.o(.text+0xd03): In function `MAIN__': : undefined reference to `pgenv_' /tmp/ifortRI8dCZ.o(.text+0xdd3): In function `MAIN__': : undefined reference to `pgqvsz_' /tmp/ifortRI8dCZ.o(.text+0xdff): In function `MAIN__': : undefined reference to `pgqvp_' /tmp/ifortRI8dCZ.o(.text+0xf23): In function `MAIN__': : undefined reference to `pgsvp_' /tmp/ifortRI8dCZ.o(.text+0xf4a): In function `MAIN__': : undefined reference to `pgswin_' /tmp/ifortRI8dCZ.o(.text+0x1216): In function `MAIN__': : undefined reference to `pgpixl_' /tmp/ifortRI8dCZ.o(.text+0x121d): In function `MAIN__': : undefined reference to `pgclos_' /tmp/ifortRI8dCZ.o(.text+0x20a7): In function `redblu_': : undefined reference to `pgqcir_' /tmp/ifortRI8dCZ.o(.text+0x2172): In function `redblu_': : undefined reference to `pgscr_' /tmp/ifortRI8dCZ.o(.text+0x21b7): In function `grays_': : undefined reference to `pgqcir_' /tmp/ifortRI8dCZ.o(.text+0x22a7): In function `grays_': : undefined reference to `pgscr_' /tmp/ifortRI8dCZ.o(.text+0x3f2f): In function `pltr3d_': : undefined reference to `pgqwin_' /tmp/ifortRI8dCZ.o(.text+0x3f4e): In function `pltr3d_': : undefined reference to `pgqvsz_' Need your help! Thanks, Cherry --- Cherry Y. Yates [EMAIL PROTECTED] wrote: I actually found plrho can do the job. But I cannot compile it, and it complains could not find -lpgplot library. Anyone knows what is that pgplot library??? Cherry --- Cherry Y. Yates [EMAIL PROTECTED] wrote: Dear SIESTA, I have made a .VT file. Do you know how to plot them? How to make a .cube file from it? Thanks, Cherry __ __ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 __ __ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC __ __ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front
Re: [SIESTA-L] Symmetries
Dear Zoya, Siesta is designed for very large systems where, usually, the number of symmetries is very small, so it can't use them Regards, Eduardo On 13/06/2007, at 9:05, Zoya Shah wrote: Dear everyone I just have a question regarding symmetries. Is it possible to use the advantage of symmetries of molecules and particles in order to reduce the number of particles in SIESTA? If so, have any of you done this before? Best regards Zoya
Re: [SIESTA-L] parallel calculation with GGA method
Dear Helean, Try to increase the meshcutoff to something more reasonable: 100-150 Ry Regards, Eduardo On 02/06/2007, at 10:47, Mu J. Helien wrote: Dear Siesta users, I compiled the parallel version of siesta code sucessfully, but it seems that it can't run normally with GGA method. For the pseudopotential was generated by means of GGA-PBE method, I defined XC.functional GGA and XC.authors PBE in the .fdf file. But it can't work and the following is the error information in the output file: InitMesh: MESH =30 x24 x24 = 17280 InitMesh: Mesh cutoff (required, used) =10.00012.406 Ry rank 1 in job 51 mitp4.emsl.pnl.gov_58106 caused collective abort of all ranks exit status of rank 1: killed by signal 9 However, if I delete the above definitions, then the job can run normally. It seems that there is something wrong with the parallel calculation with GGA method. I wonder if someone has ever met such problem and can give me some suggestions on how to solve such problem. Thank you very much. Helean
Re: [SIESTA-L] How to set up these parameters in SIESTA
Dear C. H. Hu, The Prefactor could be around 150 and the Inner radious could be 3/4 of the cutoff radious. Regards, Eduardo On 14/05/2007, at 9:03, Chaohao Hu wrote: Dear Siesta users, How to set up the PrefactorSoft and InnerRadsoft inputing parameters when considering the new soft confinement potential in the basis sets? I can also obtain the satisfactory results even though I do not consider this scheme in my present work. I have no much experience on it, please you give me the more details. Thanks in advance. Best regards, C. H. Hu
Re: [SIESTA-L] pw vs. localized basis and pseudopotentials
This is José M. Soler answer to this question: Dear Nichols: The basis set and the pseudopotentials are completely independent things: - If you have no l=d pseudo projector, but you use l=d basis functions, they will feel only the local part of the pseudopotential, exactly like in a PW program (the SIESTA local part of the pseudopotential is rather non-standard, but this is a separate issue and not very relevant in practice). - If you have no l=d basis, but you use a l=d pseudo projector, it will still act on the l=s,p functions of neighbor atoms. If these were very rich, they might 'in principle' represent the l=d part of the wavefunction around the atom. In summary: there is no difference on how the pseudopotentials act in SIESTA and PW codes. If the wavefunctions are the same (though expanded in different basis) the results are the same. Best wishes, Jose M. Soler Hi, This is a conceptual question about basis sets (pw vs. localized basis) and pseudopotentials as implemented in SIESTA. The best way to ask my question is by a very simple example. Consider Si where L = d states are important. In SIESTA, contributions from L= d states require L=d basis functions _plus_ the d-pseudopotential. As opposed to a code like ABINIT, where the PW have this variational freedom builtin. One would get contributions from L=d states, even without the d-pseudopotential. (One can do a PDOS per angular momentum and see this.) So in SIESTA, unless you actually have L=d basis functions including the d-pseudopotential would _not_ do anything. Or to put it another way, does the d-pseudopotential act on the basis functions of different symmetry in the localized basis set? Thanks, -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O)
Re: [SIESTA-L] implementation question about MeshCutoff
Hi Nichols, The grid used for the calculation of the two center integrals (calculated in matel.f) is fixed to 2000Ry, while the one used for the three center integrals is set by the user using MeshCutoff. They are completely independent. My question is about SIESTA and how the MeshCutoff is used. The charge density is on a grid and Fourier contributions of the *density* up to E_cutoff are represented. This is equal to four times the E_cutoff used in the PW codes to represent the *basis* functions (i.e. planewaves). In Siesta the density is written as a combination of pseudo atomic orbitals (squared!) which are projected into that grid, so i think the comparison is misleading. In the main Siesta paper you have a comparison which I think is more fair. Regards, Eduardo
Re: [SIESTA-L] Compilation error, How to start siesta programming
Dear Murali, Dear all, I have been trying to compile Siesta using f95 compiler and was not successful. Recently, i received help from one of the users to use g95 or gfortran compiler. As i used it, i could compile it successfully but when i started to run some programs that are available in Tests directory, i was successful in some cases while in most others, it gave the error of Fortran runtime error: Allocating negative dynamic error. That behavior is really strange, I've just compiled Siesta with g95 and it works. Maybe your compiler version is old. Also you can use the following compiler flags: -Wall -fbounds-check -ftrace=full When i had run program on fe, i got the results but when i tried to run h2o, h2oZ and most other examples in the Test directory, it resulted in runtime error. Please help me to overcome this error as i am not able to run the programs properly. My second question is that i am trying very new to do coding in siesta and so, i am asking you the steps in which i have to start and the files that are required to run any new program. Take a look at the Tests directory, it contains all the files needed to perform several simulations. Is it sufficient to go through the siesta manual before i embark on programming. Kindly tell me what are the steps needed to start programming in siesta. Well, if you want to develop a new extension to siesta you should start getting familiar with the different parts of the program: sparse matrix (hamiltonian, overlap), how the different matrix elements are calculated (matel.f, dhscf.f), how the orbitals are generated (atom.f) etc. Without more details I can't provide more information. Regards, Eduardo Thank you all very much Yours T.Murali Krishna Here’s a new way to find what you're looking for - Yahoo! Answers
Re: [SIESTA-L] Geo-Optimization
Dear Neil, In order to optimize geometry you must use the variable MD.TypeOfRun CG The Zmatrix is a way (there are others) to provide the atomic positions. The relevant part of the siesta manual is: http://www.uam.es/departamentos/ciencias/fismateriac/siesta/ manual-2.0/node20.html Regards, Eduardo On 03/04/2007, at 6:54, Neil Dixon wrote: Dear Friends, I am a new user of SIESTA.I want to know how to Optimize Geometry of a system by using SIESTA.I have got a very faint idea about Zmatrix and Constraints.are those commands deals with Geometry optimization?if so just tell me in few words,how this thing is done? please help me. Regards, Neil Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Re: [SIESTA-L] memory problem
Dear Saswata, I think you don't have enough free memory. Regards, Eduardo
Re: [SIESTA-L] Format of .XV file
Dear You Lin, Yes, they are bohr/fs. The XV uses the internal units of siesta: Ry, Bohr, fs. Regards, Eduardo On 08/03/2007, at 16:29, You Lin wrote: Hi, dear siesta developers: I'm trying to make change to .XV file. It looks like there's no document about its format. Then I made a guess: The first three lines must be the cell shape and cell velocity. Fourth line looks like number of atoms. The following lines are positions and velocities of each atom. Now the problem is the unit. It looks like the cell shape and atom positions are in the unit of Bohr. But how about the velocities? Are they in the unit of Bohr/fs? Thanks for clarifications. Sincerely, Physics explains everything! -- You Lin You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 Tel: (813) 974-8233 [Office] Fax: (813) 974-5813 Homepage: http://shell.cas.usf.edu/~ylin
Re: [SIESTA-L] Molecular system
Dear You Lin, Siesta is really efficient treating empty space, so you should increase the vacuum size until there is no change in, for example, the total energy. Regards, Eduardo On 03/03/2007, at 19:44, You Lin wrote: Dear siesta collegues: My simulated system is molecular system with a lot of empty space. I have to keep the empty space for the simulation. Is there efficient way to treating this? Thanks, Sincerely, Physics explains everything! -- You Lin You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 Tel: (813) 974-8233 [Office] Fax: (813) 974-5813 Homepage: http://shell.cas.usf.edu/~ylin
Re: [SIESTA-L] gen basis
On 06/03/2007, at 10:30, bipul rakshit wrote: hello siesta users, can any body tell me what is the exact way of using the gen basis programme. here i am sending the Sn.psf and Sn.fdf file I use the script as follows: i am in the directory of Sn sh ../gen-basis.sh Sn.fdf Sn.psf and then i got the following error ../gen-basis.sh[46]: ../../../../Src/gen-basis: not found. In the 46th line of gen-basis.sh script introduce the correct location of gen-basis. Eduardo
Re: [SIESTA-L] Wavefunctions
Dear Nilolaos, The numerical atomic orbitals can be found in the ORB* files which siesta produces in the directory where it is run. The radial part of the orbitals (phi (r)) are stored as r, phi(r)/r**l where l is the quantum number of each one. The ORB* files are named following this procedure: ORB.Sl.z.name Where l is the quantum number, z indicates which of the zetas and name the name you specify in the ChemicalSpeciesLabel. If you need any more information feel free to ask (in the list, please). Regards, Eduardo
Re: [SIESTA-L] DSTEDC parameter number 8 - illegal value
Dear Lindsay, In which platform and which compiler are you using? Regards, Eduardo On 07/03/2007, at 16:36, Lindsay Shuller wrote: Dear Siesta users, I am new to the Siesta program and have compiled the version siesta2.0. I'm trying to do some test runs (following the manual), but I continually get the following error in my *.out file DSTEDC parameter number 8 had an illegal value. Any advice? Thanks! Lindsay Shuller
Re: [SIESTA-L] radial and angular parts of basis functions
On 13/02/2007, at 3:22, Andrey V. Semichaevsky wrote: Hi Andrey, You're right, phiatm and rphiatm are the interface to the basis functions. Am I correct to say that phiatm.f is going to give me an implicitly angularly-dependent basis function if I call this function for various values of vector r? Thanks. You have to specify the species index and the index of the orbital you're interested: subroutine phiatm(is,io,r,phi,grphi) integer, intent(in) :: is ! Species index integer, intent(in) :: io ! Orbital index (within atom) ! IO 0 = Basis orbitals ! IO = 0 = Local screened pseudopotential ! IO 0 = Kleynman-Bylander projectors real(dp), intent(in) :: r(3)! Point vector, relative to atom real(dp), intent(out) :: phi ! Basis orbital, KB projector, or ! local pseudopotential real(dp), intent(out) :: grphi(3)! Gradient of BO, KB proj, or Loc ps Regards, Eduardo
Re: [SIESTA-L] Segmentation fault for SIESTA version 2.0.1 MPI
On 09/02/2007, at 13:29, Rainer WILCKE wrote:
Hello,
Those tests aren't ment to be run in parallel, they are for
the serial version.
It's true that siesta should give an error message.
Regards,
Eduardo
Hello,
I am trying to create a MPI-version of SIESTA 2.0.1 at the ESRF for
Claudio
Ferrero (SIESTA username cferrero84).
The program is supposed to run on 64-bit Opteron computers with
Suse 9.0.
For the compilation, I used the Intel Fortran compiler version
9.1.041 with
Intel's (cluster) MKL library version 9.0 and Intel's MPI library
version 2.0.
The configuration for the compilation was relatively easy, taking
SIESTA's
example architecture file Sys/intel9-cmkl8-mpi.make as a base.
Note: during the compilation, there were several warnings:
fortcom: Warning: siesta_cmlsubs.F90, line 13: Only rename
information from the
ONLY qualifiers for this external module will be processed since
all entities
from the external module have been declared public [FLIB_WXML]
Use flib_wxml, only: xmlf_t ! help pgf95...
--^
fortcom: Warning: xcmod.F, line 124: The extra characters in the
format
specification will be ignored ['('xc:
',i4,7x,a3,5x,a10,3x,f5.3,8x,f5.3))']
write(6,'(''xc: '',i4,7x,a3,5x,a10,3x,f5.3,8x,f5.3))')
---^
fortcom: Warning: siesta.F, line 2328: The extra characters in the
format
specification will be ignored ['(/,a,6f12.2))']
write(6,'(/,a,6f12.2))')
-^
but the compilation continued and produced an executable.
When I then ran the executable (using mpdboot and mpiexec), I
got errors in
the bessel test, depending on the number of nodes used: e.g. with
2 or 4
nodes, the test finished successfully, but with 6 or 8 I got a
segmentation
fault.
Re-compiling the code with the compiler options -CB -traceback
produced the
following output on the screen:
Running bessel test...
== Copying pseudopotential file for H...
== Copying pseudopotential file for O...
== Running SIESTA as mpiexec -np 6 /scisoft/users/wilcke/swdev/
siesta/siest
a-2.0.1/Src/siesta
forrtl: severe (408): fort: (2): Subscript #2 of the array PSI has
value 1 which
is greater than the upper bound of 0
Image PCRoutineLine
Source
siesta 00FF1EE2 Unknown Unknown
Unknown
siesta 00FEFBE6 Unknown Unknown
Unknown
siesta 00FC4018 Unknown Unknown
Unknown
siesta 00F8A8BE Unknown Unknown
Unknown
siesta 00F8AB02 Unknown Unknown
Unknown
siesta 004CA8BB diagg_149
diagg.F
siesta 004905C1 diagon_ 250
diagon.F
siesta 007B70A5 MAIN__ 1390
siesta.F
siesta 00409A3A Unknown Unknown
Unknown
libc.so.6 002A961B5C9E Unknown Unknown
Unknown
siesta 0040996A Unknown Unknown
Unknown
make: *** [completed] Error 152
Looking at diagg.F line 149, psi is used as an input argument
to rdiag()
call rdiag( Haux, Saux, nuotot, nuo, nuotot, eo(1,ispin),
. psi(1,1,ispin), neigwanted, iscf, ierror )
thus the second array index is indeed 1. psi is an input
argument to the
diagg() routine with the dimensions psi(nuotot,maxuo,nspin).
All these
dimensions are themselves input arguments to diagg().
diagg() is in turn called by diagon(). In this routine, psi
is allocated
by a call to re_alloc() with the size npsi, which in turn is
defined as
npsi = 2 * (2*nuotot) * (2*maxuo)
Both nuotot and maxuo are input arguments to diagon() (as is
nspin).
diagon() is called by the SIESTA main program. In the call, the
diagon()
input argument maxuo (the second dimension of psi and therefore
the one
causing the problem as it is 0) is called no_l.
no_l is used quite a bit in the main program before the call to
diagon(),
but it gets set in the GetNodeOrbs() call (line 531 in file
siesta.F).
In the subroutine GetNodeOrbs() (file parallelsubs.f) the
corresponding
input argument is called NOrbNode. For debugging, I put some write
statements in this routine (see code below). The resulting output
is in the
file bessel.out, which is also listed below.
From this (look at the end of the file), it can be seen that under
certain
circumstances NOrbNode can be set to 0 by GetNodeOrbs(). In
this case, it
is when Node is 5. Afterwards, this 0 gets used as second
dimension for
psi, which is addressed with a second array index 1, and the
segmentation
fault results.
I have tried to understand how and why NOrbNode can be set to
0. The way
I see it, the problem is with the
Re: [SIESTA-L] Help: About gen-basis in siesta-2.0
Dear You Lin, Siesta reads the pseudopotential in semilocal form and computes the non-local projectors (Kleiman-Bylander), so if you specify use.basis true then siesta reads from the files all the information it needs. If you have just started using siesta I recommend the standard procedure for basis set generation. Set: a) The basis size with the variable PAO.Basissize b) The energy shift (PAO.EnergyShift). Regards, Eduardo I have difficulty understanding how basis is defined in siesta. For example, in the manual, section 7.3 -- User.Basis (logical): If true, the basis, KB projector, and other information is read from files Atomlabel.ion, where Atomlabel is the atomic species label specified in block ChemicalSpeciesLabel. These files can be generated by a previous SIESTA run or (one by one) by the standalone program GEN-BASIS. No pseudopotential files are necessary. -- --- I'm confused by this since basis generation doesn't seem to have any info about pseudopotential. Could somebody help?
Re: [SIESTA-L] Compilation :: Need Help
Hi, I attach an arch.make for the serial and parallel versions. Both of them use the intel compiler and cmkl. If you encounter any difficulties feel free to post them to the list. Regards, Eduardo arch.make-intel-opteron Description: Binary data arch.make-intel-opteron-parallel Description: Binary data On 10/01/2007, at 15:22, S Gowtham wrote: Hi, Sincere apologies if such a message has already been posted to this list. I have been trying to compile parallel version of SIESTA 1.3/2.0 for a while but with no luck. Our system is a 16-node beowulf cluster running ROCKS 4.x with Red Hat Enterprise Linux 4.x. These have Pentium 4 architecture and we have Intel (FC, CC, MKL, CMKL), PGI, MPICH2 (compiled against both Intel and PGI) compilers. We have used these compilers to successfully compile (and run) several different programs (parallel VASP with Intel, serial Gaussian03 with PGI, etc.) to reproduce test results and thus we know for a fact that these compilers have been installed and do work properly. My request is the following: Can some one, who has successfully compiled parallel version of SIESTA (1.3 or 2.0) on Pentium 4 architecture, please send me the required files (arch.make and Makefile)? Reading from the manual, I understand that the parallel version also requires BLAS, BLACS, LAPACK, SCALAPACK, etc. As such, makefiles to get these working will also be of great help. Thanks, in advance, for your time and efforts, Regards, gowtham -- S Gowtham http://phy.mtu.edu/~sgowtham
Re: [SIESTA-L]
On nov 15, 2006, at 12:57 PM, SuiYang wrote: Dear SuiYang, ¿Do you have the intel cluster math kernel library? ¿Do you have the intel mpi? If not ¿is it possible that you install them? If it is not possible to install them I will give you the detailed, step by step, instructions. Regards, Eduardo Dear SIESTA users: I am a complete starter on parallel computing.And I have a basic question about installation and the first run: SIESTA needs to install external libraries before parallel compiling, however, I don't know what's the proper sequence to install those libraries(MPI, BLACS SCALAPACK), and how to configure the installation for the further siesta compiling.Could anyone guide me to set up my first parallel system? ( Here is my system configuration if needed: CPU :Pentium 4 Memory: 1 GB Operating System: Red Hat Linux 9.0 Fortran Compiler : Intel Fortran Compiler 9.0 ) Thanks in advance! Best wishes. SuiYang 2006-11-15
Re: [SIESTA-L] Au 6s pseudopotential
On nov 14, 2006, at 11:42 PM, Haiying He wrote: Dear Haiying, I don't have such a pseudo. My shortest convination of pseudo/basis set for gold is: %Block PAO.Basis Au 3 0.23116 n=6 0 2 E15.16639 3.56453 4.26384 1.58867 1.0 1.0 n=6 1 1 E12.99165 4.28424 4.96033 1.0 n=5 2 2 E11.34190 4.01987 4.89172 2.59723 1.0 1.0 %EndBlock PAO.Basis Aucarelnc ATM3 27-AUG-98 Troullier- Martins 6s 1.00r r= 2.32/6p 0.00r r= 2.32/5d10.00r r= 2.32/5f 0.00r r= 2.32 If you find a good pseudo with only the 6s in the valence please post it in the list. Regards, Eduardo Dear siesta users, I am working on a system including a large number of Au atoms (in bulk configuration). Does anyone have an Au pseudopotential with only 6s electron in the valence? I have tried with tm2 (improved Troullier-Martins), but without success so far. I cannot get a pseudopotential reproducing the equilibrium lattice constant of Au bulk. The total energy of the Au bulk continued to decrease far below the experimental equilibrium lattice constant. I noticed the generated pseudopotential is too attractive, but I don't know how to overcome this. Any suggestion will also be greatly appreciated. Thanks in advance. Best regards Haiying -- Haiying He Department of Physics Michigan Technological University Houghton, MI 49931
Re: Fwd: [SIESTA-L] about siesta-as-a-subroutine problem
Si en el fdf pones writexml (o un label equivalente, no me acuerdo) funcionara Edu Jose: Es algo que está ya en la lista de bug-fixes. Hasta que salga la 2.0.1 puedes arreglarlo a mano siguiendo las instrucciones que siguen. Saludos, Alberto Inicio del mensaje reenviado: De: Alberto Garcia [EMAIL PROTECTED] Fecha: 13 de octubre de 2006 15:25:29 GMT+02:00 Para: SIESTA-L@listserv.uam.es Asunto: Re: [SIESTA-L] about siesta-as-a-subroutine problem Responder a: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta; [EMAIL PROTECTED] Jian: The routines for CML output are not initialized correctly when TypeOfRun Forces is used. By fixing this I was able to run a siesta as subroutine calculation successfully. Please add the lines marked with + to siesta.F in the context provided, recompile, and try again: --- orig/Src/siesta.F +++ mod/Src/siesta.F @@ -789,6 +789,10 @@ endif case (7) call phonon_set_coords(istep,xa,ucell) +case (8) + write(6,'(28( ),a,i6)') 'Begin Server step = ',istep + if (cml_p) call cmlStartStep(mainXML, type='FS', index=istep) + end select write(6,'(2a)') '', .'==' Best regards, Alberto On 10/13/06, Jian ZHOU [EMAIL PROTECTED] wrote: Dear all, I am recently writing a small program to test the siesta-as-a-subroutine function, but have encountered some strange problems. It seems that the siesta has receive the coordinate, and even run for some minutes, however, it can not return the force data. In fact, the program hang after in the fsiesta.f90: ! Read forces from pipe iu = p(ip)%iuf read(iu,*) message It does not give error or exit, it just hang. The siesta has exit without finishing the job, since the siesta outputing is not complete. When I go through the siesta.F and iopipes.F90, I find that the forcesToPipe subroutine has been called, but I do not know why the fsiesta.f90 can not read these forces from the forces pipe. It is surprising that if I add a stop just after the call forcesToPipe( na_u, Etot, cfa, cstress ) in siesta.F, it return the forces successfully. Therefore, it seems that there are something wrong after the siesta write the forces to the pipe?? I also run the FmixMD program in the Util, the same thing happens. Does anyone experience this problem. BTW, I am using the redhat base 64bit linux and compile the siesta with pgf90. This is how I call the siesta: call siesta_units( 'Ang', 'eV' ) call siesta_launch( label , 1 ) print*, ' siesta launched ' call siesta_forces( label, na, xa, cell, energy, fa, stress) print*, ' siesta_fores end' call siesta_quit( label ) print*, ' siesta quit' Of course, all these array has been initialized. Thank you! Best wishes, jian -- Mensaje enviado mediante una herramienta Webmail integrada en *El Rincon*: - https://rincon.uam.es --
Re: [SIESTA-L] About unoccupied channels in the basis set
On oct 27, 2006, at 3:58 PM, Marcos Verissimo Alves wrote: Hi Marcos, What you are describing are semicore states: several shells with the same l quantum number but different n quantum number. All of them share the same pseudopotential, but each resulting orbital is orthogonalized to those with a lower n quantum number. If you have tons of free time look for nsm (number of semicore shells) and nnodes (how many nodes the orbital has) in atom.f. As you know already, for each atom with semicorestates there must be an entry in the PAO.Basis block. Regards, Eduardo Hai-Ping, I know how to include extra shells in siesta basis sets; with that, no problem. My problem is to know which pseudopotential siesta will use for these extra shells - which have no corresponding pseudo in the psf file, due to limitations of the Troullier-Martins generation procedure. Cheers, Marcos Hi Marcos, you could define pao-basis with keywords PAO.Basis . in this block, you may include some shells you like to define regards, hai-ping On 10/27/06, Marcos Verissimo Alves [EMAIL PROTECTED] wrote: Dear all, I have a doubt about the inclusion of unoccupied channels in the basis set, particularly in the case of Carbon. I generated a pseudo for C with 2s, 2p 3d and 4f channels. Now, I'd like to include 3s channels ** in the basis set **, so as to make the basis more complete. However, when the Troullier-Martins pseudo is generated, the only s-channel that can be generated is the 2s one. So, how exactly is Siesta going to treat the 3s channels in the basis set? I know it is possible, but I don't understand exactly how. By the way, Martins et al have published, some time ago, a method to generate pseudos with same l-channel but different n quantum number (eg, the 2s and 3s channels mentioned above). If such a pseudo is formatted such that siesta understands it, can it be used? Cheers, Marcos -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Condensed Matter and Statistical Physics Sector International Centre for Theoretical Physics Trieste, Italy I have become so addicted to vi that I try to exit OpenOffice by typing :wq! -- Dr. Marcos Verissimo Alves Post-Doctoral Fellow Condensed Matter and Statistical Physics Sector International Centre for Theoretical Physics Trieste, Italy I have become so addicted to vi that I try to exit OpenOffice by typing :wq!
Re: [SIESTA-L] any comment for NODAT
On oct 24, 2006, at 2:53 PM, 박준호 wrote: Hi, The NODAT preprocessor variable was used to configure the precision of several variables related to the paralelization. In SIESTA 2.0 is deprecated and can be removed from the arch.make. Regards, Eduardo. Hi, All In source code, there is a variable named NODAT. What is the role of “NODAT”? It this defined or undefined? How to know or How to change, where is it defined? Regards, Joonho
Re: [SIESTA-L] Follow-up on NaN error with parallel version of Siesta 2.0
Hi Derek, I haven't tried with lam-mpi, but with intel mpi there are problems if you link with a blacs compiled for mpi 1.2 while using mpi 2 (lam-mpi implements almost all of mpi 2). The problem is in one of the include files of the c interface of blacs, so it can be really difficult to detect while using a fortran only application. In order to link with mkl I'm using the following: GUIDE=/opt/intel/cmkl/8.1.1/lib/em64t/libguide.a SCALAPACK=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_scalapack.a #Pay attention to the intelmpi20 suffix of blacs: BLACS=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_blacs_intelmpi20.a VML=/opt/intel/fce/9.1/lib/libsvml.a LAPACK=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_lapack.a BLAS=/opt/intel/cmkl/8.1.1/lib/em64t/libmkl_em64t.a LIBS=$(SCALAPACK) $(BLACS) $(LAPACK) $(BLAS) $(GUIDE) $(VML) -lpthread Also if nuotot is only 24 then the system is really small, maybe there are no orbitals in a given node and it produces the NaN. Good luck, and please post your findings! Eduardo On oct 5, 2006, at 5:32 PM, Derek A. Stewart wrote: Hi everyone, Just a quick follow up on the NaN errors I have been running into with Siesta 2.0. It looks like the error occurs in the cdiag subroutine (cdiag.F) when pzheevd is called to solve the standard eigenvalue problem. I have tried changing the parameters of the run (i.e. DivideConquer, Set2D), but similar problems occur. This means it is probably a problem with the scalapack library. Has anyone successfully compiled the parallel version of Siesta with lam-mpi 7.1.1 with intel compilers version 8 or 9? If they have, I would be interested in comparing your Bmake, SLmake input files for BLACS and SCALAPACK with what I am using. Thanks, Derek On 10/4/06, Derek A. Stewart [EMAIL PROTECTED] wrote: Hi all, I have been trying to get the parallel version of Siesta 2.0 to run with the intel compilers (version 8.1, MKL math libraries) and lam-mpi (7.1.1). I have no problems compiling the parallel version of siesta. However, when I run a calculation, I run into a problem which I have traced to the diagk.F file. Evidently the psi matrix psi(2,nuotot,nuo) which provides auxiliary space for the eigenvectors has NaN entries for nuo=1,2. The other entries (nuo=3-24) are fine. This can probably be traced to the cdiag subroutine called in this file and I am working on this. Has anyone run into this problem before? For my compilation, it appears to occur for general input files. The run has no problems for the serial case. Thanks, Derek ### Derek Stewart, Ph. D. 250 Duffield Hall Cornell Nanoscale Facility stewart (at) cnf.cornell.edu (607) 255-2856
Re: [SIESTA-L] siesta compilation problem
Hi John, I attach an arch.make for sgi-altix. It uses the system blacs and scalapack optimized by sgi. Regards, Eduardo arch.make-sgi Description: Binary data On sep 26, 2006, at 1:46 AM, John B. Baba wrote: Hi all: Thanks lan and Marcos replay, I also try to compile siesta1.3 parallel using mpi and f90 in sgi, I following their suggestions, and log out all the options about netCDF. But I also get some errors, I do not know the reason, Does anyone know the reasons? Following is the error messages: *** a\ -L/usr/lib64 -lscs_mp -lmpi ld64: ERROR 33 : Unresolved text symbol blacs_get_ -- 1st referenced by cdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: ERROR 33 : Unresolved text symbol blacs_gridinit_ -- 1st referenced by cdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: ERROR 33 : Unresolved text symbol blacs_gridexit_ -- 1st referenced by cdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: ERROR 33 : Unresolved text symbol descinit_ -- 1st referenced by cdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: ERROR 33 : Unresolved text symbol pzhegvx_ -- 1st referenced by cdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: ERROR 33 : Unresolved text symbol pdsygvx_ -- 1st referenced by rdiag.o. Use linker option -v to see when and which objects, archives and dsos are loaded. ld64: INFO152: Output file removed because of error. Following is my arch.make file: # # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez- Portal # and J.M.Soler, 1996-2006. # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # SIESTA_ARCH=sgi64-mpi_fermat # # This file seems to work for SGI systems using 64-bit compiled # Scalapack and Blacs libraries from netlib, and *some version* (perhaps # SGI's own?) of MPI. # # Note that the Scalapack and Blacs library files must be linked from # their standard places to the building directory... # # Note that the locations of the libraries are configured for the # Fermat system of the CSAR service at Manchester. Details must # changed for other machines accordingly. # FC=f90 -64 # FFLAGS= -O3 INCFLAGS = -I/usr/local/netcdf-3.5.1/include netcdf.inc #FFLAGS= -O scalar2,pipeline2,aggress -eA FFLAGS_DEBUG= -g -O0 RANLIB=echo # #NETCDF_LIBS=-L/usr/local/netcdf-3.5.1/lib -lnetcdf #NETCDF_INTERFACE= #DEFS_CDF=-DCDF # MPI_INTERFACE=libmpi_f90.a #MPI_INTERFACE= MPI_INCLUDE=/usr/include DEFS_MPI=-DMPI # #LIBS= -lscalapack -lblacs -lpblas -ltools \ # /usr/local/unsupported/numerical/lib64/blacsCinit_MPI- O2K_64-0.a \ # /usr/local/unsupported/numerical/lib64/blacs_MPI- O2K_64-0.a \ # -lscs -lcomplib.sgimath -lmpi #LIBS= -ltools \ # -lscs_mp -lcomplib.sgimath -lmpi LIBS= -L/usr/lib64 \ -lscs_mp -lmpi SYS=bsd DEFS= $(DEFS_CDF) $(DEFS_MPI) # .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(DEFS) $ .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $ .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(DEFS) $ .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $ ##
Re: [SIESTA-L] fundamental siesta parallel compilation question
On sep 6, 2006, at 7:07 PM, Marcel Mohr wrote: Hi Marcel, You should use the same compiler. If you change from one to another the compilation is going to be a nightmare. It is possible but really, really tricky. Regards, Eduardo Hello all I am trying to compile Siesta and required packages (BLACS, scalapack) from scratch. However do I have to use the SAME Fortran compiler for all packages? Or can I use GNU f77 for BLACS scalapack and LaheyFujitsu lf95 for mpi and SIESTA ? Kind regards Marcel Mohr
Re: [SIESTA-L] Problem about compilering siesta
Dear Sir, There is a l_fce_pc_8.1* compiler. You can obtain a copy from your premier account at intel.com Regards, Eduardo On Wed, 2005-06-15 at 10:07 +0800, Mingsu Si wrote: Dear Sir, There is no l_fce_pc_8.1* compiler. In the web of Intel they say l_fc_pc_8.1* support em64t CPU. Where do I obtain the l_fce_pc_8.1* compiler? Regards Mingsu Si Dear Sir, Your compiler does not support em64t. You need l_fce_pc_8.1* (notice the e after fc!) Regards, Eduardo
Re: [SIESTA-L] Problem about compilering siesta
Dear Sir,
Your compiler does not support em64t. You need l_fce_pc_8.1* (notice the
e after fc!)
Regards,
Eduardo
On Sun, 2005-06-12 at 11:50 +0800, Mingsu Si wrote:
Dear Sir.
I changed the single quotes around the brackets by double quotes in the
atom.f file.
Then I compile it. There is no error when copiling the atom.f file. But at
last it occures
error as following:
ifort -o siesta \
..
..
/opt/intel/mkl721/lib/em64t/libmkl_lapack.a: could not read symbols: File
format not recognized
make: *** [siesta] Error1.
The software and hardware I use as following:
l_fc_pc_8.1.024.tar
l_mkl_p_7.2.1.003.tar
Redhat Linux As
IBM X236 I06 cpu Xeon 3.2 em64t
Now how can I do?
Dear Mingsu Si,
This problem was discussed previously in this forum. A simple
solution: Change the single quotes around the brackets by double quotes
and it probably it will compile successfully.
Regards.-
simingsu wrote:
Dear Mr Eduardo Anglada
I have just started to compile the SIESTA code with Intel ifort 8.1
compiler and MKL 7.2.1 libraries. The problem is that it is not able to
compile atom.f file. The errors printed out are given below:
#
ifort -c -w -mp -tpp7 -O3 atom.f
fortcom: Error: atom.f, line 4485: Unbalanced parentheses
. nsm=1,nsemic(l)+1-(cnfigtb(l,nsemic(l)+1,is)-config(l)))
^
fortcom: Error: atom.f, line 4484: Syntax error, found ',' when
expecting one of: :
. (cnfigtb(l,nsm,is),sym(l),'(',qPAO(l,nsm),')',
--^
fortcom: Error: atom.f, line 4484: Syntax error, found ''' when
expecting one of: ( * :: , IDENTIFIER CHAR_CON_KIND_PARAM
CHAR_NAM_KIND_PARAM CHARACTER_CONSTANT ...
. (cnfigtb(l,nsm,is),sym(l),'(',qPAO(l,nsm),')',
--^
compilation aborted for atom.f (code 1)
make: *** [atom.o] Error 1
#
What can I do?
Mingsu Si
Lanzhou University
June 10 2005
Re: [SIESTA-L] Problem about compilering siesta
You don't provide too much info, in this kind of reports the operating system and cpu kind is really appreciated. The compiler is saying it doesn't understand the symbols format of the em64t lapack (mkl intel) library. Most probably you are compiling in another architecture. There are several possibilities, the easier ones are: i) You are compiling on a 32 bit PC: then you need the lapack (mkl) library in the 32 bit directory: /opt/intel/mkl721/lib/32/limkl_lapack.a: ii) You are compiling on an itanium2: /opt/intel/mkl721/lib/64/limkl_lapack.a: Regards, Eduardo On Wed, 2005-06-08 at 15:11 +0800, simingsu wrote: Dear all, In the course of compilering siesta, I met the following problem. ifor siesta -o / . . /opt/intel/mkl721/lib/em64t/limkl_lapack.a: could not read symbols: File format not recognized Make: *** [siesta] Error 1 What can I do to solve this problem? simingsu [EMAIL PROTECTED] 2005-06-08
Re: [SIESTA-L] Implementation of MD in Siesta
Dear Benjamin, Siesta uses classical MD. In fact we have developed a new algorithm. If you are interested the reference is: http://dx.doi.org/10.1103/PhysRevE.68.055701 Efficient mixed-force first-principle molecular dynamics E. Anglada, J. Junquera and J. M. Soler, Phys. Rev. E *68*, 055701 (2003). arXiv: cond-ma/0305704 http://arxiv.org/abs/cond-mat/0305704 Regards, Eduardo
Re: [SIESTA-L] polarized PAO !!
Dear Imad, The problem is in the 4 after Ga. It should be a 3 as you only provide 3 shells. The fourth (corresponding to the polarization orbital) will be added automatically by siesta. Regards, Eduardo %block PAO.Basis Ga 3 n=3 2 2 0.00 0.00 n=4 0 2 0.00 0.00 n=4 1 2 0.00 0.00 2 1 P 1 0.00 %endblock PAO.Basis
